archive/theorangeone.net-legacy
1
Fork 0
Code Activity

Update docker-hub-rss link

Browse source 
RIP now.sh
This commit is contained in:
Jake Howard 2020-08-18 20:20:30 +01:00
parent 51bd6bd77c
commit 50b5b98d63
Signed by: jake
GPG key ID: 57AFB45680EDD477
1 changed files with 2 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
content/posts/keeping-docker-containers-updated.md
View file

@ -17,7 +17,7 @@ So, how can we deal with this?
Well, the obvious way to deal with this is to just keep on top of your tags. When a new version comes out, update the tag in your `docker-compose.yml`, `docker-compose pull`, and then restart the container (`docker-compose down && docker-compose up -d`). This is simple, and robust, and means nothing will update without you knowing. Well, the obvious way to deal with this is to just keep on top of your tags. When a new version comes out, update the tag in your `docker-compose.yml`, `docker-compose pull`, and then restart the container (`docker-compose down && docker-compose up -d`). This is simple, and robust, and means nothing will update without you knowing.
The downside is that this is obviously quite a lot of work. There are projects which [expose RSS feeds from docker hub](https://docker-hub-rss.now.sh/), but you've still got to go manually update each container and issue a `docker-compose pull`etc. The downside is that this is obviously quite a lot of work. There are projects which [expose RSS feeds from docker hub](https://docker-hub-rss.theconnman.vercel.app/), but you've still got to go manually update each container and issue a `docker-compose pull`etc.
Here are some examples of the changes needed: Here are some examples of the changes needed:
@ -45,7 +45,7 @@ So, here's a workflow:
1. Pin your containers as you need them, as loosely as you're comfortable with. If you don't actually care what version it's using, and are confident it can update itself, pin `latest`. If you need a specific patch version for _reasons_, pin that. If you're unsure, pin the latest major version, as anything below it shouldn't have breaking changes, and should be backwards compatible. 1. Pin your containers as you need them, as loosely as you're comfortable with. If you don't actually care what version it's using, and are confident it can update itself, pin `latest`. If you need a specific patch version for _reasons_, pin that. If you're unsure, pin the latest major version, as anything below it shouldn't have breaking changes, and should be backwards compatible.
2. Use `watchtower` to keep these pins up to date. This ensures `latest` always means `latest`, and that specific pins always reflect upstream, which makes rebuilding easier. 2. Use `watchtower` to keep these pins up to date. This ensures `latest` always means `latest`, and that specific pins always reflect upstream, which makes rebuilding easier.
3. Have some way of knowing when new versions are released. Whether that's via [DockerHub RSS](https://docker-hub-rss.now.sh/), [GitHub releases](https://github.community/t/rss-feeds-for-github-projects/292), or something else, it doesn't matter. 3. Have some way of knowing when new versions are released. Whether that's via [DockerHub RSS](https://docker-hub-rss.theconnman.vercel.app/), [GitHub releases](https://github.community/t/rss-feeds-for-github-projects/292), or something else, it doesn't matter.
4. When new versions are released, bump the pinned version in your `docker-compose.yml` (or alike), and re-deploy (`pull`, `down`, `up -d`). 4. When new versions are released, bump the pinned version in your `docker-compose.yml` (or alike), and re-deploy (`pull`, `down`, `up -d`).
With this, you'll have a container setup which reasonably matches the package management workflow you're used to, with a couple niceties around auto updating. Only the packages you want to automatically update will automatically update, and the rest you can update when you're notified of updates. With this, you'll have a container setup which reasonably matches the package management workflow you're used to, with a couple niceties around auto updating. Only the packages you want to automatically update will automatically update, and the rest you can update when you're notified of updates.