Docker Pull+Restart Script [SOLVED]

    • OMV 3.x
    • Resolved

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Docker Pull+Restart Script [SOLVED]

      Just wanted to poke out and see if anyone in their infinite wisdom has managed to script a 1)pull of the latest images, 2)stop containers, 3)remove containers, 4)start new copies of containers. This is commonly an activity that is beneficial for many containers that are set to run more non-ephemeral apps as we often do on these systems. Before I try and dig into the inner workings of the interface and how we do the copy function in the plugin to make this easier, I wanted to see if someone had happened to tackle this already.
    • Taking a poke at reviving this. Any updates? I've found it quite difficult even manually doing this process through the UI. You have to be sure to "modify" a container just to have it rebuild with the latest image. Will have to look into manually building something myself from playing around if nobody has done so already. Perhaps I'll leverage existing scripts from normal command line and adjust to use here from the GUI so it can easily be scheduled as a scheduled task.
    • I am currently working on some new features (actually I am finish, I need a minor ui tweak). I started looking into this as there is currently some thing like this requested at github. I am starting to poke around the hub API to check for new versions. I'll see what I can do with this.
      chat support at #openmediavault@freenode IRC | Spanish & English | GMT+10
      telegram.me/openmediavault broadcast channel
      openmediavault discord server
    • Aha! So you win again on another ask from me! ;)

      Anything I can do to assist in the new scripting options? If it's helpful, there was someone who responded about something similar when I first looked at a regular linux script that shared what the LimeTech UnRaid guys had. It was a script specific to their setup and the Docker plugin, but perhaps it has some similarities to help as a starting point? This was the link I was pointed to: CA Auto Update

      I hate not being code savvy enough to help, so love to find an angle I can actually contribute to.
    • The docker plugin uses the linuxserver images in their repo. If I am not mistaken those images can be updated in one button then run with same options. This works as ls maintains a file with changes.
      If you want to help start poking the hub API for dates they output for images and compare them to images locally for date also to compare.
      chat support at #openmediavault@freenode IRC | Spanish & English | GMT+10
      telegram.me/openmediavault broadcast channel
      openmediavault discord server
    • Try v2tec/watchtower or freenas/watchtower

      Watches your containers and automatically restarts them whenever their image is refreshed.
      Watchtower is an application that will monitor your running Docker containers and watch for changes to the images that those containers were originally started from. If watchtower detects that an image has changed, it will automatically restart the container using the new image.
      With watchtower you can update the running version of your containerized app simply by pushing a new image to the Docker Hub or your own image registry. Watchtower will pull down your new image, gracefully shut down your existing container and restart it with the same options that were used when it was deployed initially.

      The docker container does it automagicly.

      The post was edited 5 times, last by DeepB ().

    • @subzero79 - I was actually thinking of this from a different angle. Not necessarily relying on it being the LS.io containers, since I do use a few that are not in there. For that reason it can't just be something based on the OMV implementation of Docker. I was thinking more of raw command from the CLI using docker commands locally on the system.

      Intelligence to check if there is a new image is one piece, but I was even thinking simpler about just doing a pull of all images first, then scrap all running containers, then re-run all containers with their run mode before. This would require simply just doing something like a docker images list taking that output and piping into a docker pull command. After which the part I'm not crafty with, is being able to grab all the running containers with their associated parameters (basically the docker run command), and be able to see those temporarily to a file output. Then docker rm all the containers, and finally a docker run of all the previous containers with their full run command saved to the file.

      Although @DeepB makes a good point. I've actually seen Watchtower before, but it seems like it died out and lost any maintenance. The version he linked is one I picked up recently which looks like a port someone made of the original and has now starting maintaining with the current docker versions and could fit this need. I'll try testing this out as well and see if it causes any issues with the actual OMV docker plugin being able to recognize the current parameters if a container is re-created by this.
    • Ahh gotcha. Ok, I was thinking more about being able to regularly schedule it to happen. Especially in the case of the LS.io containers, they often see updates on a weekly basis. I just want to set a script that processes every weekend to update the containers to the new versions automatically. Well let me see how the Watchtower route goes and it made be a moot point.
    • Also a good point is that those updates rarely contain something new. They improve the building file or the startup script, which bottom line doesn't affect end user. If there is software involved then the user might benefit. I have to check if there is different exit codes when running an exiting pull image.
      chat support at #openmediavault@freenode IRC | Spanish & English | GMT+10
      telegram.me/openmediavault broadcast channel
      openmediavault discord server
    • Alright so I can positively say, this watchtower container, takes care of it! Works pretty easily. Based on this, I'd say to ignore my request for the scheduled update.

      The beauty is you can set it on a regular interval (something like a check every X seconds) or you can setup a Cron based schedule with it. This will schedule the update on a set basis - which is exactly what I was looking for. Looks to have successfully updated all my LS.io containers currently running without fail. I did find I had some extraneous stuff laying around after the updates. I had used the --cleanup parameter, but I think some of this may have been lingering from previous updates I had done manually. Love how Docker just doesn't automatically cleanup some actions. :thumbdown:

      Anyhow, due to the newer 1.13 Data Management commands (aka docker system prune) - I'm planning to just setup a cron job to run a docker system prune -f every Sunday night after the Watchtower is set to update.

      I don't remember how to get everything to run properly through using the OMV GUI, so I did have to drop down to the CLI in OMV to input the docker run command. If anyone finds it useful, this was my run command:
      sudo docker run -d -v /var/run/docker.sock:/var/run/docker.sock --restart unless-stopped --name watchtower v2tec/watchtower --cleanup --schedule "0 0 2 * * 1"
      This is telling it to run in daemon mode, mount the docker daemon inside so it can run against the API, restart always unless stopped, naming it watchtower, the repo, cleanup after pulling updates (aka rid of dangling images), and scheduled to run at 2AM on Mondays every week
    • [...]I don't remember how to get everything to run properly through using the OMV GUI, so I did have to drop down to the CLI in OMV to input the docker run command. If anyone finds it useful, this was my run command:[...]

      Read the source.

      You can provide env variables and feed the container, such as WATCHTOWER_POLL_INTERVAL, WATCHTOWER_SCHEDULE, WATCHTOWER_CLEANUP and so on.

      On OMV GUI.
    • @subzero79 - I thought that command is for each of the containers when they are run? That should specify that it is removed as soon as it stops. I don't necessarily care to bother doing that. I can just use the new prune command on a regular basis to cleanup the dead containers. Most the time, they don't have any type of local volume that matters - I run everything with local persistence that needs it.

      @DeepB - yes I knew there were environment variables as an option, I guess perhaps this is ignorance on my part, but where do you find those variables? I could see the watchtower docs outline adding in --cleanup to the run command, so how does one correlate or translate that to a specific ENV variable such as WATCHTOWER_CLEANUP?
      EDIT - Sorry I totally missed the Read source line. I started to dig into that originally, but hadn't found the ENV variable items. That's helpful to know they're there. Now I can re-create through OMV GUI. THANKS!
    • 1activegeek wrote:


      sudo docker run -d -v /var/run/docker.sock:/var/run/docker.sock --restart unless-stopped --name watchtower v2tec/watchtower --cleanup --schedule "0 0 2 * * 1"
      This is telling it to run in daemon mode, mount the docker daemon inside so it can run against the API, restart always unless stopped, naming it watchtower, the repo, cleanup after pulling updates (aka rid of dangling images), and scheduled to run at 2AM on Mondays every week
      shouldn't it be --schedule "0 2 * * 1" then?
    • disrupted wrote:

      1activegeek wrote:

      sudo docker run -d -v /var/run/docker.sock:/var/run/docker.sock --restart unless-stopped --name watchtower v2tec/watchtower --cleanup --schedule "0 0 2 * * 1"
      This is telling it to run in daemon mode, mount the docker daemon inside so it can run against the API, restart always unless stopped, naming it watchtower, the repo, cleanup after pulling updates (aka rid of dangling images), and scheduled to run at 2AM on Mondays every week
      shouldn't it be --schedule "0 2 * * 1" then?
      Not according to the Watchtower Documentation which references this cron format which does have 6 placeholders vs 5. Currently mine is running with the expression given, and runs solidly on Mondays at 2am. Been this way since my original post.