Docker Pull+Restart Script [SOLVED]

    • OMV 3.x
    • Resolved
    • subzero79 wrote:

      Docker is telling you that is not possible to use that option with restart policy.
      I understand that, and I am able to make it work when I remove --rm, but your previous comment said that I would end up with alot of dead containers without it. So how should I setup Watchtower? I thought --cleanup was doing the cleanup of dead containers?

      This is how I setup Watchtower:

      Source Code

      1. sudo docker run -d -v /var/run/docker.sock:/var/run/docker.sock --restart unless-stopped --name Watchtower v2tec/watchtower --cleanup --schedule "0 0 4 * * *"
      Right now I have a lot of dead images from the update...
    • subzero79 wrote:

      Read what @1activegeek is telling. He doesn’t care he cleans/prunes on his own script the watchtower container.
      I read that, but sadly I don't know how to setup that either.
      Do docker prune do the same thing as the --rm command?
      Why isn't it possible to use this together with --restart?

      Got this tip from another user:
      Update image in Docker?

      That didn't work for me either, as --rm=true makes the Docker crash and restart.
    • Sorry it seems there might have been some confusion. I'll elaborate:

      • Using the --rm=true feature, is a PER container flag that you would use to ensure that if for some reason you delete the container, the leftover STUFF from it doesn't linger (this is what @subzero79 was highlighting) - imagine starting a new container everyday, and having not cleaned up the old one. It happens more often than you think, and can really build up after awhile. Specifically the pesky part is the Volumes. Most people don't fully understand volumes when they learn about docker and how they linger unless you specifically try to remove them and clean them up. This helps to reduce that by removing the remnant files immediately upon stop of the container.
        • The --rm flag tells docker that as soon as this container is stopped, remove/delete it and it's volumes. Hence the idea this will ensure you don't build up leftover "hanging" file likes volumes, containers, etc.
        • The --restart tells docker that if the container is stopped for some reason (restart of host, interrupted service, etc) - it should automatically restart the container. This implies that you may actually stop the container, but want to leave it intact.
        • Your issue stems from trying to use two flags that contradict each other in their purpose. --restart says you want to be able to stop and restart a container, while --rm says you want a container to be removed/deleted as soon as it is stopped.
      • Using the Watchtower container takes care of re-building containers automatically when updates come about - so in my mind there is no need to really run this container with the --rm flag as you often don't get rid of this container anyway
      • I do use a script that cleans up all my containers, negating the need for the --rm=true flag. In my opinion, this is the better way to go as it will allow you to still prune and clean up, but not require special flags on the containers either. I thought it had been posted in this thread, but I think I posted about it somewhere else. For posterity, here is the info:
        • docker system prune -f - set this up under scheduled tasks. I run mine weekly at 3AM on Mondays. I wake up to an email from OMV on Mon morning with a report of the output by setting the Send Email flag on the task. Docker just introduced this new command not long ago. Previously the script consisted of about 3-4 lines of commands to do the same thing that Prune does now automatically.
        • I use a bunch of the LS.io containers, they mostly update on a weekly basis. So of my 12-15 or so containers (8 prob LS.io), I end up with about 2GB worth of data cleaned up every week.
    • 1activegeek wrote:

      Sorry it seems there might have been some confusion. I'll elaborate:

      • Using the --rm=true feature, is a PER container flag that you would use to ensure that if for some reason you delete the container, the leftover STUFF from it doesn't linger (this is what @subzero79 was highlighting) - imagine starting a new container everyday, and having not cleaned up the old one. It happens more often than you think, and can really build up after awhile. Specifically the pesky part is the Volumes. Most people don't fully understand volumes when they learn about docker and how they linger unless you specifically try to remove them and clean them up. This helps to reduce that by removing the remnant files immediately upon stop of the container.
        • The --rm flag tells docker that as soon as this container is stopped, remove/delete it and it's volumes. Hence the idea this will ensure you don't build up leftover "hanging" file likes volumes, containers, etc.
        • The --restart tells docker that if the container is stopped for some reason (restart of host, interrupted service, etc) - it should automatically restart the container. This implies that you may actually stop the container, but want to leave it intact.
        • Your issue stems from trying to use two flags that contradict each other in their purpose. --restart says you want to be able to stop and restart a container, while --rm says you want a container to be removed/deleted as soon as it is stopped.
      • Using the Watchtower container takes care of re-building containers automatically when updates come about - so in my mind there is no need to really run this container with the --rm flag as you often don't get rid of this container anyway
      • I do use a script that cleans up all my containers, negating the need for the --rm=true flag. In my opinion, this is the better way to go as it will allow you to still prune and clean up, but not require special flags on the containers either. I thought it had been posted in this thread, but I think I posted about it somewhere else. For posterity, here is the info:
        • docker system prune -f - set this up under scheduled tasks. I run mine weekly at 3AM on Mondays. I wake up to an email from OMV on Mon morning with a report of the output by setting the Send Email flag on the task. Docker just introduced this new command not long ago. Previously the script consisted of about 3-4 lines of commands to do the same thing that Prune does now automatically.
        • I use a bunch of the LS.io containers, they mostly update on a weekly basis. So of my 12-15 or so containers (8 prob LS.io), I end up with about 2GB worth of data cleaned up every week.

      Fantastic explanation, I now understand why it did what it did!
      I have set up a scheduled job as you explained:
      imgur.com/a/qbJ9k
      Did test it, and it cleaned up everything left over.
      By the way, did I understand the setup correctly, that this will run every night at 05.00 (24h format) or 5 AM?

      That is one hour after my Watchtower runs every night.

      Thank you for this! And sorry for the stupid questions, I see now how stupid I sound!
    • joq3 wrote:

      By the way, did I understand the setup correctly, that this will run every night at 05.00 (24h format) or 5 AM?
      From what I can see in your image - yes, looks like it's running that way. * = every, and you have stars for weekly, monthly, days, etc.

      joq3 wrote:

      That is one hour after my Watchtower runs every night.
      Yup - same way I have mine running. Watchtower runs at 2AM, cleanup at 3AM. Only difference, I run it once a week. Daily is a bit overkill in most cases unless you're actively developing or working on an under development container.

      joq3 wrote:

      Thank you for this! And sorry for the stupid questions, I see now how stupid I sound!
      Not a problem. Not stupid question - someone else I'm sure didn't understand but didn't ask. It's more an education game. If you're newer to docker, there's definitely an uphill learning curve at first. I went through it once upon a time. My biggest suggestion, take down the link for the Docker reference links. It's extremely helpful to reference their "man" pages for the docker commands. Often times I've found most of my education comes from their documentation and a little tinkering locally.
    • 1activegeek wrote:

      joq3 wrote:

      By the way, did I understand the setup correctly, that this will run every night at 05.00 (24h format) or 5 AM?
      From what I can see in your image - yes, looks like it's running that way. * = every, and you have stars for weekly, monthly, days, etc.

      joq3 wrote:

      That is one hour after my Watchtower runs every night.
      Yup - same way I have mine running. Watchtower runs at 2AM, cleanup at 3AM. Only difference, I run it once a week. Daily is a bit overkill in most cases unless you're actively developing or working on an under development container.

      joq3 wrote:

      Thank you for this! And sorry for the stupid questions, I see now how stupid I sound!
      Not a problem. Not stupid question - someone else I'm sure didn't understand but didn't ask. It's more an education game. If you're newer to docker, there's definitely an uphill learning curve at first. I went through it once upon a time. My biggest suggestion, take down the link for the Docker reference links. It's extremely helpful to reference their "man" pages for the docker commands. Often times I've found most of my education comes from their documentation and a little tinkering locally.
      Perfect!
      Yes, maybe a bit overkill, but it can run every night as the server is unused at night anyway.

      I just checked the logs of the Watchtower Docker:

      Source Code

      1. time="2017-11-08T09:32:19Z" level=info msg="First run: 2017-11-09 04:00:00 +0000 UTC"
      The same thing was in the log yesterday too. There is no confirmation that it has run?
      Can you confirm that Watchtower works somehow?

      You are right, Docker is hard to understand in the beginning, it was very confusing, but I think I understand the things I need right now :)

      Thank you!
    • I don’t recall if there is somewhere inside the container to check. I know the logs from OMV won’t tell you anything I don’t believe. I would just suggest setting up a random conainer and stopping it. Then let it do its thing and check the next day. If that stopped container is gone, it’s running. If it’s still there then you may have an issue. Alternatively if you have a container you know has an update to the image, monitor the age of that container the next morning.