portainer: how to update to latest version

  • Well, I've been digging and I'm sorry to say I don't think it's correct that it's necessary to bind to an external directory if using the following command to run a command in a new container:

    Code
    docker run -d -p 8000:8000 -p 9000:9000 --name=portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer:1.24.1

    The -v option creates a volume named portainer_data that's separate from the container. That's why removing the container portainer (docker rm portainer) doesn't also remove the volume. See also: https://www.ionos.com/digitalg…docker-container-volumes/


    Here's the layout on one of my servers:

  • Well, I've been digging and I'm sorry to say I don't think it's correct that it's necessary to bind to an external directory if using the following command to run a command in a new container:

    Code
    docker run -d -p 8000:8000 -p 9000:9000 --name=portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer:1.24.1

    The -v option creates a volume named portainer_data that's separate from the container. That's why removing the container portainer (docker rm portainer) doesn't also remove the volume. See also: https://www.ionos.com/digitalg…docker-container-volumes/


    Here's the layout on one of my servers:

    Where did I say it was necessary? Go back and read every post I made, I never said it was necessary. I said there was sound reason behind doing so, including if you lose your container and container data for some reason (deleting, etc.).

    Air Conditioners are a lot like PC's... They work great until you open Windows.


  • Where did I say it was necessary? Go back and read every post I made, I never said it was necessary. I said there was sound reason behind doing so, including if you lose your container and container data for some reason (deleting, etc.).

    When you say "Because if you deleted your container, when you reinstall.. there is a good chance that volume isn't going to be there. That is why you map it somewhere outside of your container with a bind mount" I think it's a legitimate conclusion from your comment that one would like to avoid doing that. But in fact there is no reason to avoid doing it, because the volume is already separate from the container. There is not "a good chance that volume isn't going to be there". Nothing chancy about it. Or legit.


    For clarity, I'm referring to avoiding doing this:

    docker run -d -p 8000:8000 -p 9000:9000 --name=portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer:1.24.1


    I just want to put the correct information out there for anyone else reading your comments and concluding there's something to avoid or there's some advantage to doing it your way. There isn't.


    BTW this isn't personal. It's technical. Let's keep it on that plane.

  • Ok, if you say so. If you lose your container data for some reason, your portainer data will be lost, because it's mapped inside of the container. My way, maps it outside of the container (I thought I was clear on this)... so it doesn't matter if the container data is lost.


    It's not personal, and it's not technical either. It's common sense.


    Oh, and just for the record...


    docker run -d -p 8000:8000 -p 9000:9000 --name=portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer:1.24.1


    Note the bold part. If you look on your root partition, you've very likely got a folder called "portainer_data", which proves my point. Since the folder didn't exist, docker-run just created it when you ran the command.

    Air Conditioners are a lot like PC's... They work great until you open Windows.


    Edited once, last by KM0201 ().

  • I'm sorry, you're just wrong on this. I showed you there are 2 separate directories for containers & volumes. I also showed that docker rm container does not delete the volume. If you looked at my postings carefully, you'd see a detailed layout of all this.


    It doesn't prove your point that the portainer_data folder was created when running the docker command. It's true that folder was created on first run, but it is not removed when the command is rerun.


    I've done all I can to make this clear. I'm done. Thanks.

  • I'm not going to read this whole thread but the plugin uses docker volume create portainer_data to create a docker volume. This volume is persistent even across the image and container being removed because it is only used by the container and not owned by the container. It is just as persistent as using a path.

    omv 5.6.13 usul | 64 bit | 5.11 proxmox kernel | omvextrasorg 5.6.2 | kvm plugin 5.1.6
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • I'm not going to read this whole thread but the plugin uses docker volume create portainer_data to create a docker volume. This volume is persistent even across the image and container being removed because it is only used by the container and not owned by the container. It is just as persistent as using a path.

    I'll take your word for it... But my experience in the past has been completely opposite, thus why I started installing it from compose to begin with. Everytime I removed portainer, all of my settings got nuked.

    Air Conditioners are a lot like PC's... They work great until you open Windows.


  • But my experience in the past has been completely opposite, thus why I started installing it from compose to begin with. Everytime I removed portainer, all of my settings got nuked.

    While I haven't experienced that, I'm not saying that a new portainer container won't change files/settings in the volume and screw something up. This should happen with a path as well though.


    If you think compose is more reliable (I use it for most things too), maybe I should switch omv-extras to use compose for portainer and yacht. It wouldn't be a hard change.

    omv 5.6.13 usul | 64 bit | 5.11 proxmox kernel | omvextrasorg 5.6.2 | kvm plugin 5.1.6
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • While I haven't experienced that, I'm not saying that a new portainer container won't change files/settings in the volume and screw something up. This should happen with a path as well though.


    If you think compose is more reliable (I use it for most things too), maybe I should switch omv-extras to use compose for portainer and yacht. It wouldn't be a hard change.

    As long as it keeps it easy for the end user.. that is the important part of the button... I think the buttons are fine as is to be perfectly honest... Even with the path limitation I've experienced

    Air Conditioners are a lot like PC's... They work great until you open Windows.


Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!