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.
0 kommentar(er)
