ucphhpc / docker-migrid

Containerized MiG
GNU General Public License v2.0
3 stars 7 forks source link

logrotate inside docker #27

Closed Bjarke42 closed 10 months ago

Bjarke42 commented 10 months ago

Logrotate should not be running inside the docker container and meddling with files that are outside the container itself.

We would like an option so that if you want logrotate to be active from inside the container you can set it in env file, example:

ENABLE_LOGROTATE=true

Default should be that logrotate is not enabled.

A work around for now is, everytime you start migrid, execute the following:

docker exec -it migrid /bin/bash -c "rm /etc/cron.daily/logrotate"
benibr commented 10 months ago

I agree, logrotate is not a thing that should run inside the migrid container, each container should hold as few services as possible. It should either be run in a seperate container or the admin could run it "somewhere else" on the host.

jonasbardino commented 10 months ago

Thanks for your feedback - a good point. Yet, the docker wrapping of migrid belongs in docker-migrid, so let's continue the discussion and work there.

jonasbardino commented 10 months ago

Oops, I did not mean to close the issue here, sorry.

jonasbardino commented 10 months ago

The log handling could definitely use some love in the docker-migrid setup. On bare metal we run services and logrotate on a monolithic setup, which makes it easy to signal apache and migrid services to hang-up and reopen logs after rotation. Obviously that does not map as easily to the separation and multi-container setup with mounted log files here.

For now I've added a ENABLE_LOGROTATE option as suggested to effectively remove the /etc/cron.daily/logrotate file during build, unless the option is explicitly set to True. Furthermore I've added a LOGROTATE_MIGRID option, which enables the migrid logrotate conf to actually handle the state/log/*.log and state/log/*.out files when it and ENABLE_LOGROTATE is set to True. It should be noted that the latter is still work in progress, since the postrotate handlers need to be adjusted to properly handle the distributed and manually launched services in docker.

If/when handling rotation outside the containers you should beware that individual services using those log files still need to be told about it. Either by sending them a HUP signal to have them gracefully reload or by completely restarting the containers.

Bjarke42 commented 10 months ago

I have tested both edda and sif with

ENABLE_LOGROTATE=False
LOGROTATE_MIGRID=False

And the logrotate file is not present. So i will close this