How to "update" Docker images/container?

  • Hello,


    I'm very new to docker but since there is no SABnzb anymore I had to deal with the docker plugin. I've read some tutorials on the forum and after some tinkering I finally managed to get a SABnzb container up and running. :)


    Now I see that there is a new version of the SABnzb image but I don't find any information on how to properly "update" an image/container? I just found another thread on this forum where someone else asked the same question and was told to only update when really necessary. :huh: This doesn't answer his (and my) question. So given the situation that a docker image HAS to be updated because of a security vulnerability of the enclosed application - what do I have to do in this situation?


    I had a hard time configuring the container because some paths and variables (inside and outside of the container) are not self explaining. So I don't want to destroy my work accidentally.


    Thanks in advance for your help!

  • There's another Docker container called "Watchtower" that can update your other containers automatically for you on a set schedule and retain your configuration. I don't use it personally, but there are some discussions about it on this forum.

    • Offizieller Beitrag

    How do you update your images?

    ( @macom - Forgive me for butting in.)


    I don't auto-update either. I've seen a couple instances of flawed image updates, published by the authors of Dockers. Since I don't want to auto-update my way into a failed Docker, I manually build a new container every time using the older (outside) configuration parameters if they're compatible. (That's another reason to rebuild manually - in some cases older config files and parameters are not usable in newer containers.)


    And a new container build is done on a backup boot drive, so there's a back-out option. :)

  • Ok, now I installed Watchtower like described in this video:
    https://forum.openmediavault.o…?postID=177009#post177009


    It works (nice :) ) but per default it leaves the old Images in list. https://hub.docker.com/r/v2tec/watchtower/ mentions some options, for example --cleanup (for removing old images after updating). I tried to put it into "Extra Arguments" field right in front or behind of -v /var/run/docker.sock:/var/run/docker.sock but I get an error message when I try so save the container. Where do I have to specify those options? :?:

  • How do you update your images?

    ( @macom - Forgive me for butting in.)
    I don't auto-update either. I've seen a couple instances of flawed image updates, published by the authors of Dockers. Since I don't want to auto-update my way into a failed Docker, I manually build a new container every time using the older (outside) configuration parameters if they're compatible. (That's another reason to rebuild manually - in some cases older config files and parameters are not usable in newer containers.)


    And a new container build is done on a backup boot drive, so there's a back-out option. :)


    Generally, I don't update my containers. I update the applications themselves using the built-in updater from their web UI, but I haven't found it necessary to update the containers. Please correct me if I am at risk by not doing so. For a while, I played around with Watchtower, but it ended up feeling a bit unnecessary so I stopped using it.

    • Offizieller Beitrag

    Generally, I don't update my containers. I update the applications themselves using the built-in updater from their web UI, but I haven't found it necessary to update the containers. Please correct me if I am at risk by not doing so. For a while, I played around with Watchtower, but it ended up feeling a bit unnecessary so I stopped using it.

    The ability to update seems to vary from image to image. Some authors design their containers to be updated internally as you've described. (Plex, Emby and others.) If they're designed for it, generally, authors will state as much on their page in hub.docker.com Others, with less robust designs, "break" if they're updated in the traditional way. (And some authors will caution users not to update/upgrade in the traditional way - that they should install a new Docker image instead.)


    Either way, I view a Docker as a full (but bare bones) working Linux machine installation that happens to be "living" on my OMV boot drive. By extension, the boot drive itself with OMV, plugins, and installed Dockers becomes the baseline install to be maintained. Accordingly, I always backup my boot drive ((2 full USB thumb drive copies in fact)) before I do upgrades to the OS/OMV, Dockers, or major plugins like UrBackup.


    Cautious and Conservative? Absolutely, but it's served me well. :)

  • From my experience so far, it seems that i've been able to happily update the apps from within their respective web UIs and that has worked well (Radarr, Sonarr, NZBget etc), but, if i modify any parameters for the docker container, it then has the ability to break the updates and restore the original underlying code, so, probably best to try and update the core container itself whenever you can to save any problems.


    An example, you use the NZBget Linux build, run it, and then find there is an update. You update and all works well. You then need to tweak some intrinsic parts of that container and it reverts back to the previous version. When it then runs, it throws up some errors about commands that are now outdated etc that it reads from the later install.

    • Offizieller Beitrag

    From my experience so far, it seems that i've been able to happily update the apps from within their respective web UIs and that has worked well (Radarr, Sonarr, NZBget etc), but, if i modify any parameters for the docker container, it then has the ability to break the updates and restore the original underlying code, so, probably best to try and update the core container itself whenever you can to save any problems.


    An example, you use the NZBget Linux build, run it, and then find there is an update. You update and all works well. You then need to tweak some intrinsic parts of that container and it reverts back to the previous version. When it then runs, it throws up some errors about commands that are now outdated etc that it reads from the later install.

    Those are accurate observations. The Docker image downloaded is the base software or snapshot (depending on how one looks at it) for the creation of a container. The container created from the image can be updated internally to your hearts content, as long as you don't hit the "modify/save" buttons in the Docker GUI which resets parameters, volumes and bind points, ports, etc. That action "modify" creates a new container, from the base image, running the newly entered parameter(s). Thereafter, all modifications, updates, etc., to the original container (that are not mapped outside) are permanently lost.


    Since this is a given, I do very little with a Docker, using the Docker plugin, after a container is up and running correctly. (The old moto applies, "if it works don't fix it".) If I need to do something, I backup the boot drive as a matter of practice before tweaking anything related to a Docker. It's good to be able to back out of a change (with a known working boot drive) in the event of a fat finger error or other unintended consequence.


    @stripealipe , what are you using as a boot drive?

    • Offizieller Beitrag

    Is it safe to allow OMV to update Docker, Docker-CLI and the OMV Docker plugin while dockers are running or should all dockers be stopped before the components are updated?

    I don't know. I've never updated the Docker-CLI or the Docker Plugin, in between OMV version upgrades. If all is well and your Dockers are working right, why risk it?


    If you think it's important, this is something I'd test in a VM before updating a physical server.

  • Is it safe to allow OMV to update Docker, Docker-CLI and the OMV Docker plugin while dockers are running or should all dockers be stopped before the components are updated?

    I've had no problems doing this. It does restart the containers as part of the process.

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

  • Zitat von flmaxey

    I always backup my boot drive ((2 full USB thumb drive copies in fact))

    @flmaxey how do you proceed? Offline (shut omv down, take the sd card to a pc, image it, bring it back)? Or is there a reliable tool to do that "online", that is, from within OMV and without shutting OMV down ?

    • Offizieller Beitrag

    Or is there a reliable tool to do that "online", that is, from within OMV and without shutting OMV down ?

    Not that I've used personally, but I haven't tried the the backup plugin either (currently openmediavault backup 4.0.6). The plugin must allow for coping the OS on-line, because OMV would have to up for it to run.


    I'm not a fan of this plugin, for beginners, because most of them will not go through even one restoration process. This leads them to "think" that they have backup until something goes wrong where they may discover that they've been doing something wrong. Doing backups is questionable (nearly pointless), if the user doesn't know, for sure, that the backup can be restored.


    This is why I advocate the off-line process - it works in all details. If a user images their boot drive, verifies the image, writes the image to another drive (and verifies that), they've already gone through all the processes necessary to know how to backup and restore their OS.


    shut omv down, take the sd card to a pc, image it, bring it back

    Yes, a PC or a Laptop.


    Assuming that you're familiar with, or want to use, the off-line imaging process:
    If you're in a production environment and want to avoid down time; in a maintenance window you could shutdown, image the SD-card, and immediately boot back up on the same card. (The time involved is just reading the image, but skipping verification could have unforeseen consequences later.)
    Then, with the image file in hand, the image can be written to a 2nd card and verified at your leisure. Swapping cards (shutdown, reboot), if you want to do that, is another 3 or 4 minute process that can be done later.


    Things that can speed the imaging process:
    - Use a 16GB drive. Larger drives take longer (16GB is, probably, the best trade off for speed of imaging and longevity / wear leveling.)
    - Use faster media (A1, Class 10, etc.) If it's a thumbdrive, a USB3 drive in a USB3 port is fairly quick.

  • Zitat von flmaxey

    I advocate the off-line process - it works in all details. If a user images their boot drive, verifies the image, writes the image to another drive (and verifies that), they've already gone through all the processes necessary to know how to backup and restore their OS.

    I do agree. (Btw, due to direct involvement in the IT industry I am indeed familiar with backup, replication, disaster recovery and related concepts).


    Let's elaborate a bit.


    1) assuming to take the offline approach, a reasonable procedure could be:
    Have 2 sdcard readers on the pc.
    Clone OMV's boot card onto a second card.
    Plug the cloned card back into OMV. This way we have a minimal downtime + we check (although not "throughly") that the back medium does work.
    Make an extra copy of the original boot card on PC's disk.


    2) how about Docker containers?


    For performance, container "system-data" are ofc not kept onto the boot card, but rather on OMV-managed media
    - A "DockerFolder" to hold container images
    - An "AppData" folder to hold the various dockered apps' configs


    Question: besides what goes into the 2 above folders, is there any other Docker-related "stuff" that gets saved onto the boot card? If so, then DockerFolder & AppData folder backup "MUST" be synced with Boot Card backup!... How ?

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!