Update: the text and the examples do not match?
I addressed the example:
Actualy It should be already working like this.
The Dockerfile of the image has symlinks that point to /dev/stdout and /dev/stderr:
&& ln -sf /dev/stdout /var/log/nginx/access.log \
&& ln -sf /dev/stderr /var/log/nginx/error.log \
If a volume is mounted into /var/log/nginx, the original content from the image will be invisible, and whatever is in the volume will replace the content of the folder.
If nginx complains about those missing files, you can add a custom script into
/docker-entrypoint.d that can create the files for you.
If the example was just to argue that the current behavior is different, then yes you are right and it can not be changed by configuration.
You could create and put a custom script into the
/docker-entrypoint.d directory, which checks if /var/log/nginx is a mountpoint and if so creates the empty files (if not existing) and then “tail” them as a background process to the console. Though, this is a rather unclean solution and will probably result in zombi porcesses when the container is finished. At this point it seems more reliable to introduce a process supervisor like s6-overlay to handle this cleanly.
Ignore the blurred content… it is possible to create a custom image that’s able to do so.
Several logs can be specified on the same configuration level.
Thus, you could add a custom script in
/docker-entrypoint.d that either modifies the nginx.conf based on /var/log/nginx beeing mounted or not. Declare two
access_log declarations (the default to /var/log/nginx/access.log and the other to /dev/stdout), then use sed in your custom script to comment out the
access_log /dev/stdout one if /var/log/nginx is not mounted, as in this case the default one will already send the output to /dev/stdout.