In there you will find the following entry. Alternatively, you may wish to separate it first by going to /etc/rsyslog.d and editing nf with your favourite text editor. In default config, cron will send some logs to the default syslog. Choose or create a target log file The system default cron log Once up and running, if doing a daily pull this should not be an issue with one or two at a time. When doing this recently I crashed a server (with 8 pending images) and had to reboot, and pull each image individually. Warning: If you have never done this or it's been a long time, it can smash a small server running a pull on everything, when all have a pending image.
#Docker run image compose cmmand update
Manually run the pull and, (if it's clean) the update at the command line. Test before automatingĪs I recently found out, it's a good idea to back up your server (this was a Lightsail snapshot in my case) before starting, and to run a pull manually at the command line before committing a cron job. At least for me, this sequence didn't seem to break things.Īdditionally I am adding a "restart" to the compose commands as I have had issues in the past with wordpress image updates.
I think the best approach is to update the image, confirm the WP version that's in it, then as the version does not seem to auto update inside the app, afterwards update on the WP panel. If it's Wordpressįor Wordpress, check the image you have in your compose is the latest, and is the same "theme" (fpm, Apache, Alpine etc). This is your judgement - set your tags to something appropriate. If I was to have image: ghost or image: ghost:latest I would be auto updated to version 3 without knowing it. Using this tag should always pull the latest version 2 which is the risk level I am happy with. For example, my image entry for the Ghost container has image: ghost:2-alpine because I do not want uncontrolled updates beyond version 2 without testing first. Setting image tags in the compose fileįor this to be effective, the docker-compose.yaml file must have considered tags for the images. Subsequently, I found that a better way to update is simply a docker-compose pull -no-parallel followed by a docker-compose up -d, so I am setting out to automate it. When I connected in to the systems to remediate, often all that was needed was a docker-compose up -d and everything would start working again. It seems like a great package, but I found I was having outages (such as site hangs, or "too many redirects") when updated images were loaded and docker restarted, as Docker Compose was being left behind. When I started on this road, I initially set up Watchtower. My objective is to have a small script run daily which pulls any new Docker image versions and runs a docker-compose update, capturing the output to a log.