Acts as a single reverse proxy with SSL offloading for any number of dockerized web projects on a single server, using 2 awesome projects:
- the reverse proxy is be the only container that actually needs to expose any ports to the world.
- base image is just a regular nginx
- the only container that actually exposes anything to the outside world, both port 80 and 443
- any other Docker Web Container or Docker-Compose stack with a specific environment variables, that lands in the same bridge network, will automatically be reverse-proxied and provided with a SSL certificate from LetsEncrypt.
- has read-only access to the docker host's docker.sock
- this is how the docker host will notify this container about other containers starting or stopping
- will watch for any new container with an environment variable called "VIRTUAL_HOST"
- if any such starting container is found, it will update it's nginx.tmpl file, create a new server directive for this new container and push the changes to the proxy container
- similarly, if any such container is stopped, it will remove the corresponding entry from the server directives and push the updated config to the proxy container
- gains read-only access to ./data/proxy/certs
- will handle obtaining and renewing certificates from letsEncrypt
- also has read-only access to the docker host's docker.sock
- just like the docker-gen container, this container will be notified about any starting or stopping containers
- will watch for any new container with environment properties called "LETSENCRYPT_HOST" and "LETSENCRYPT_EMAIL"
- will check if there are certificate files for the domain name set in the "LETSENCRYPT_HOST" property of any such started container
- if none are found, it will try to obtain new certificate files for this domain, also using the "LETSENCRYPT_EMAIL" address
- if certificate files for this domain already exists, it will try to renew any certificate that would expire within 30 days every 3600 seconds
- will check if there are certificate files for the domain name set in the "LETSENCRYPT_HOST" property of any such started container
https://github.com/crazy-max/swarm-cronjob
Cron entries are stored in an array, sorted by their next activation time. Cron sleeps until the next job is due to be run. Upon waking:
- it runs each entry that is active on that second
- it calculates the next run times for the jobs that were run
- it re-sorts the array of entries by next activation time.
- it goes to sleep until the soonest job.
https://godoc.org/github.com/crazy-max/cron#hdr-Predefined_schedules
Entry | Description | Equivalent To
----- | ----------- | -------------
@yearly (or @annually) | Run once a year, midnight, Jan. 1st | 0 0 0 1 1 *
@monthly | Run once a month, midnight, first of month | 0 0 0 1 * *
@weekly | Run once a week, midnight between Sat/Sun | 0 0 0 * * 0
@daily (or @midnight) | Run once a day, midnight | 0 0 0 * * *
@hourly | Run once an hour, beginning of hour | 0 0 * * * *
@every <duration> | Schedule after <duration></duration>
For example, @every 1h30m10s
would indicate a schedule that activates after 1 hour, 30 minutes, 10 seconds, and then every interval after that.
Note: The interval does not take the job runtime into account.
For example, if a job takes 3 minutes to run, and it is scheduled to run every 5 minutes, it will have only 2 minutes of idle time between each run.