[Docker] Autorun containers at startup + Autoupdate images

    • OMV 4.x (testing)

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

    • [Docker] Autorun containers at startup + Autoupdate images

      Docker-CE 17.12.0 on OMV 4.0.15-1.

      I have several container images (from LinuxServer.io) and I have several questions about them:

      - Is there any way to make them to be autostarted whenever the server boots? I see there is a restart policy field but I am not sure it will autostart it at booting.

      Do the containers or the docker plugin include an autoupdate function or should I updated them manually (creating newer images then)? I have several messages from Plex client asking to be updated to latest stable release.

      I see there is a docker image that may get what I am looking for: Watchtower (github.com/v2tec/watchtower). Is there any more simple function or is this the unique way to go?

      Thanks.
      || omv 4.0.14 | kernel 4.9.0 | omvextrasorg 4.1.0 ||
    • In the GUI, set the container restart policy to "always". If your server is up, the container will start and restart if necessary. I'm using a container with this policy and, so far, it have been flawless. If the server is running, the container is running.
      ________________________________________

      (Note the following is my opinion - others may have a different view.)

      Regarding containers with an auto update function: I would say, "use that at your own risk".

      For a container to update, it would need to be built from an updated image. I would strongly caution you about allowing your images to be updated automatically. Docker images are not unlike a Linux ISO build. While it's streamlined and incredibly fast; the image is the source for a stripped down Linux machine build that shares the kernel with the host. The new machine build is, "a container".

      While it's a conservative approach, I'd keep the original unaltered image. I'd want to download a new image separately, try it out and verify that it works, before deleting a known good source image. Along similar lines, if a new or auto-updated image doesn't work, note that the Developers are not obligated to maintain an old image archive. So, if you delete an older image that works well, or allow an auto-update process to do the same, it's possible that you might not be able to get the old image again.
      ________________________________________

      It's all about approach and, again, I'll admit that I prefer to err on the conservative side.
      Good backup takes the "drama" out of computing
      ____________________________________
      OMV 3.0.95 Erasmus
      ThinkServer TS140, 12GB ECC / 32GB USB3.0
      4TB SG+4TB TS ZFS mirror/ 3TB TS

      OMV 3.0.95 Erasmus - Rsync'ed Backup
      R-PI 2 $29 / 16GB SD Card $8 / Real Time Clock $1.86
      4TB WD My Passport $119
    • flmaxey wrote:

      In the GUI, set the container restart policy to "always". If your server is up, the container will start and restart if necessary. I'm using a container with this policy and, so far, it have been flawless. If the server is running, the container is running.
      ________________________________________

      (Note the following is my opinion - others may have a different view.)

      Regarding containers with an auto update function: I would say, "use that at your own risk".

      For a container to update, it would need to be built from an updated image. I would strongly caution you about allowing your images to be updated automatically. Docker images are not unlike a Linux ISO build. While it's streamlined and incredibly fast; the image is the source for a stripped down Linux machine build that shares the kernel with the host. The new machine build is, "a container".

      While it's a conservative approach, I'd keep the original unaltered image. I'd want to download a new image separately, try it out and verify that it works, before deleting a known good source image. Along similar lines, if a new or auto-updated image doesn't work, note that the Developers are not obligated to maintain an old image archive. So, if you delete an older image that works well, or allow an auto-update process to do the same, it's possible that you might not be able to get the old image again.
      ________________________________________

      It's all about approach and, again, I'll admit that I prefer to err on the conservative side.
      Thank you a lot for your reply.

      Yeah, maybe a server does not need to be running on bleeding edge versions. I will keep it stable.
      || omv 4.0.14 | kernel 4.9.0 | omvextrasorg 4.1.0 ||