Systemd, ENV, latest stable Moodle #6
Conversation
- Add trailing slashes for file location to indicate directory
|
|
||
| [Service] | ||
| WorkingDirectory=/etc/moodle-docker | ||
| Type=oneshot |
There was a problem hiding this comment.
Is this a oneshot service? generally that's used for scripts that exit, but this will remain running as a service.
There was a problem hiding this comment.
docker-compose doesn't stay running, the actual containers are managed by docker
There was a problem hiding this comment.
If you remove the --detach it will stay running, that way the logs show up properly with journalctl.
There was a problem hiding this comment.
--detach is safer in prod because it saves on resources.. plus we should have a proper logging solution vs docker -> docker-compose -> journalctl
Some more notes here:
docker/compose#4266 (comment)
There was a problem hiding this comment.
FYI, I would much rather we use the 'syslog' docker logging driver and leave compose detached. This is what I'm doing for SDE, and instead of dumping logs into the compose stdout, it will send them to syslog with an appropriate container tag. Let me know if you have questions about this.
There was a problem hiding this comment.
What resources would it be using exactly? The example posted before that comment is the correct way to do this IMO. The proper logging solution is to use this as a simple service and not oneshot. If we send the logs to journald it's easy to then move them elsewhere to a centralized location.
What's the behaviour with stopping a container in a oneshot service? once docker-compose exits the oneshot service will report it's exited successfully. This could leave you in a weird state where the container is running/crashed but systemd is not aware of this.
Also what happens when docker-compose exits but the container stops right after due to an error or some other reason? In this case systemd wont print any errors and the oneshot service will report success even though the container is not running.
Another reason to make this a simple service would be then we can use the Restart and related config fields to ensure the container is brought back up if it exits for some reason.
There was a problem hiding this comment.
@adamgilbert just pointed me to this:
https://docs.docker.com/config/containers/logging/journald/#usage
Thoughts?
There was a problem hiding this comment.
Discussed further with @hrpatel, I think we are good to go with the oneshot approach.
| RemainAfterExit=yes | ||
|
|
||
| ExecStartPre=-/usr/local/bin/docker-compose --file /etc/moodle-docker/docker-compose.yml pull --quiet | ||
| ExecStart=/usr/local/bin/docker-compose --file /etc/moodle-docker/docker-compose.yml --file /etc/moodle-docker/dc.prod.yml up --detach |
There was a problem hiding this comment.
Since the container is managed with systemd we don't want to detach from the container here.
There was a problem hiding this comment.
Its cleaner to detach and let docker handle logs/output/etc.. and only use systemd to manage starting and stopping
There was a problem hiding this comment.
Why not keep it attached and let systemd handling the logging also? Then systemd can detect if the container crashes or stops for some reason. You will also be able to access the logs through docker but it's easier to use journalctl and get all logs at once.
There was a problem hiding this comment.
The syslog logging driver should dump everything to a log file, but we could also try the journald logging driver instead: https://docs.docker.com/config/containers/logging/journald/#options
| systemctl --system daemon-reload >/dev/null || true | ||
| systemctl enable moodle-docker >/dev/null || true | ||
| # Skip starting since we need to configure `.env` | ||
| #systemctl start moodle-docker >/dev/null || true |
There was a problem hiding this comment.
Should remove this line if it's not needed.
There was a problem hiding this comment.
I'm going to uncomment once I automate a couple more things:
- populate hostname dynamically (if possible) or fail back to IP
- still need to figure out a lets encrypt solution here
- auto-generate random passwords for each field in
.env
There was a problem hiding this comment.
Ah alright let's leave this part in for now then.
No description provided.