You’d place your compose file in the working dir /var/lib/sonarr. Depending on what tag you’ve set for the image in the compose file, it would be autoupdated, or stay fixed. E.g. lscr.io/linuxserver/sonarr:latest would get autoupdated whereas lscr.io/linuxserver/sonarr:4.0.10 would keep the container at version 4.0.10. If you want to update from 4.0.10, you’d have to change it in the compose file.
Did you use docker compose file or just run a command to start the container?
Edit: I always use compose files. For that you can do the following:
docker compose pull
docker compose down
docker compose up -d
You don’t technically need the stop, but I’ve found once or twice in the past where it was good to stop because of image dependencies that I forgot to put in my compose.
For running a command directly I found this website that seems to summarize it pretty well I think:
I see someone mention watchtower, while not a bad thing, I just prefer to manually update. This helps to ensure any breaking changes don’t break my system. Especially with something like Immich at it’s had a lot of them recently as they work towards stable. I just generally subscribe to their release and do updates as necessary.
Podman supports auto updating natively by setting a label.
I use systemd service files for running containers, but you can add the same label on the command line or in quadlet files.
I just setup Jellyfin on docker the other day for the first time.
It just occurred to me that I don’t know how to update docker.
Any advice?
no need for
docker compose down
.pull && up
is enoughAlso depends on how you specified image in the docker. If it has no version or latest as version it will update otherwise it may be fixed
You could use a systemd unit file:
[Unit] Description=docker_compose_systemd-sonarr After=docker.service Requires=docker.service [Service] TimeoutStartSec=0 WorkingDirectory=/var/lib/sonarr ExecStartPre=-/usr/bin/docker compose kill --remove-orphans ExecStartPre=-/usr/bin/docker compose down --remove-orphans ExecStartPre=-/usr/bin/docker compose rm -f -s -v ExecStartPre=-/usr/bin/docker compose pull ExecStart=/usr/bin/docker compose up Restart=always RestartSec=30 [Install] WantedBy=multi-user.target
You’d place your compose file in the working dir
/var/lib/sonarr
. Depending on what tag you’ve set for the image in the compose file, it would be autoupdated, or stay fixed. E.g.lscr.io/linuxserver/sonarr:latest
would get autoupdated whereaslscr.io/linuxserver/sonarr:4.0.10
would keep the container at version4.0.10
. If you want to update from4.0.10
, you’d have to change it in the compose file.Check out Watchtower! Auto-update your containers. Don’t forget to set WATCHTOWER_CLEANUP to true, or your disk will be filled with old images.
Thanks! I’ll check that out, I’m really loving how quick and easy docker has been so far.
Oh this looks great! Thanks for the suggestion
I couldn’t figure out watchtower. I just made a script to pull and restart and scheduled it to run daily at midnight.
Did you use docker compose file or just run a command to start the container?
Edit: I always use compose files. For that you can do the following:
You don’t technically need the stop, but I’ve found once or twice in the past where it was good to stop because of image dependencies that I forgot to put in my compose.
For running a command directly I found this website that seems to summarize it pretty well I think:
https://www.cherryservers.com/blog/how-to-update-docker-image
Yes, I used docker compose. Do I need to do anything to clean up with this method?
Now that you mention it, I always do a
docker system prune -f
This will clean up old images that are no longer used. I setup an alias command in Linux to do all of those commands.
I just named it docker_update and saved it in my ~/.bashrc
I see someone mention watchtower, while not a bad thing, I just prefer to manually update. This helps to ensure any breaking changes don’t break my system. Especially with something like Immich at it’s had a lot of them recently as they work towards stable. I just generally subscribe to their release and do updates as necessary.
And there are breaking changes in this Jellyfin release.
If you set up using compose and don’t have the version pinned:
dockee compose down && docker compose pull jellyfin && docker compose up -d
What about if I am using Podman and have the container as a systemd unit file?
Podman supports auto updating natively by setting a label.
I use systemd service files for running containers, but you can add the same label on the command line or in quadlet files.
https://wiki.exu.li/linux/podman#auto-update-container