I may upgrade this post to my blog but before I do it would be great to hear any feedback on this subject.
I’m using an NGINX container which exposes /var/log/nginx as a volume and a Logstash container which uses this volume processes the logs into Elasticsearch.
So that’s all well and good.
What’s happening then is the logging is being done inside the container, not by a volume mounted from the host system.
Not wanting the container size to bloat due to the logs, I need them to rotate and be pruned.
NGINX installs with a logrotate conf file and for it to work all that it needs is cron.
So the container is running two processes:
NGINX
Cron
So in the Dockerfile instead of:
CMD ["nginx"]
I use a start script:
CMD ["/etc/init.d/docker-start.sh"]
Which simply starts cron, which in turn enables NGINX log rotation, and starts NGINX.
#!/bin/sh
#includes lsb functions
. /lib/lsb/init-functions
# Start cron for needed regular logrotate
CRON=`which cron`
log_daemon_msg "Starting ${CRON}"
$CRON
# Start NGINX
log_daemon_msg "Starting NGINX"
nginx
```
I don't actually have this in production only development.
I know best practice is to have a single running process inside a docker container, however, in this case, two processes seems to be a good fit.
Using the two containers this way is very portable and just drops onto the host without any "external" configuration (ie. host mounted volumes).
How does this approach grab you?
Makes good sense?
Total craziness?
Any and all feedback very much appreciated.
Cheers.
one concern with your strategy is that you are using cron vs anacron, if you deploy daily it can leave you in a bit of a bind as your daily/weekly and so on may never hit.
in discourse docker we use anacron/cron
if you are launching nginx by simply running nginx I am uncertain you will reopen files after a rotation you need to review the logrotate file, I think it counts on nginx being launched via init.d.
@rufus I am curious to see if the log driver can do the trick here, one concern with nginx is that it it piping to 2 log files (errors and access) so somehow we would need to capture that on the other end.
Definately check that it is properly sending the signal to NGINX on rotation, we has so many issues with 0 sized access.log files cause the USR1 did not get through to NGINX.