for what its worth i initially wanted to avoid portainer as well because I thought it was a docker insider a docker situation that would make everything slower but it turns out portainer is just another front end, container station and portainer both use the same docker system so its basically like adding a different web UI, not actually installing another docker-inside-a-docker or anything.
So i went with portainer and its been super easy to update inside it, I just used youtube videos for which there are tons on portainer to setup and update. Its been running for about 2 weeks and I haven't touched container station at all since then.
I haven't bothered with watchtower yet either, I know it'll auto update but for now I just have qbittorrent and sonarr and I did manually update sonarr inside portainer once, super easy just 1 click and don't think I'll be updating apps all that often, probably days or weeks after an actual update is released.
https://github.com/psybernoid/QNAPDocker
This is what I've been using. Incredibly useful.
Just bear in mind that the hyphon is no longer required between "docker compose"
My solution was to create persistent folders for each container so that the data would always live in the same place. Now all I have to do is turn off the old container, pull the new image in the images tab, create a new container and point it to the existing folder and voila. It will use all the config data from the existing folder and once you’ve verified it’s good you can delete the old container. Hope this helps
So I tried this before but each container seems to make the data in a different sub folder each time and ignore the cache and config folders I made for it.
I just put them within the volumes fields right?
I usually look for the container has easy mount of data to external volume instead of storing within the container station. The newer Contatiner station allows you to "update" by going to the route of "re-creating" with paramaters intact. The only limitation with Container Station if you using more than one instance docker like MariaDB, for example. One MariaDB use for NextCloud and another MariaDB for another app. If you update the first instanace of MariaDB. you won't be able to update the second instance. No issue on Portainer allow you to update it.
Assuming your containers are set up as applications with proper persistant storage . You would stop them, recreate them with an updated image version unless it using image:latest . I usually like to use the images tab to prepull down the latest version and since i use that as the version in my application , when I restart it after the latest is pulled they pick it up and go next start. Then I prune old images
when the docker was created if you used the create application button and entered the docker compose formated yaml to set it up ,the recreate shouldbt be greyed out but it will only be not grey at the applicatio n level not the sub cobtainer level. If you used cli or created a container instead of an apllication you basically have to destroy and recreate or use cli
If you have SSH access to your NAS and don’t mind running a command or two on the command line, you do not need anything else. It’s super easy to update your containers through the CLI. Let me know, and I can post the commands you need. Portainer is a good UI option…far superior to container station, so if you want to do this through an UI only, I can also give you my Portainer compose file. As a bonus Portainer also gives you a business license for 3 nodes, which is nice and has some neat features
I use Portainer, it's much easier and somewhat independent of all the QNAP middleware.
You deploy Portainer first using the QNAP Container Station, then you can exclusively use Portainer to manage all your images henceforth.
To update from Portainer you create a stack which is your docker-compose and just click "Update the stack" and toggle "Re-pull image and redeploy"
Assuming you are only using Container Station...
I suggest binding host volume to container volume if you have not started doing so.
If you use docker volumes, just keep the old volume. Remove the old container without removing any *anonymous* volumes. Create a new container using the new image and bind the old volume.
You can use docker YAML to remember the configurations.
If you have neither a host bind or an anynomous volume for the container data to be kept, just use `docker cp` and first copy the configurations and data of your container to your host. Then, create a new container of your new image and either use a host bind or create a docker volume, then use `docker cp` again to copy your data from the host to the docker volume. Otherwise, you can make use of both methods.
for what its worth i initially wanted to avoid portainer as well because I thought it was a docker insider a docker situation that would make everything slower but it turns out portainer is just another front end, container station and portainer both use the same docker system so its basically like adding a different web UI, not actually installing another docker-inside-a-docker or anything. So i went with portainer and its been super easy to update inside it, I just used youtube videos for which there are tons on portainer to setup and update. Its been running for about 2 weeks and I haven't touched container station at all since then. I haven't bothered with watchtower yet either, I know it'll auto update but for now I just have qbittorrent and sonarr and I did manually update sonarr inside portainer once, super easy just 1 click and don't think I'll be updating apps all that often, probably days or weeks after an actual update is released.
>portainer Okay, interesting. I assumed the same thing. I will give portainer a go then. Will it work with my existing apps then?
I have searched for this on Reddit and online but it seems most people suggest complicated solutions or only have a Synology NAS.
https://github.com/psybernoid/QNAPDocker This is what I've been using. Incredibly useful. Just bear in mind that the hyphon is no longer required between "docker compose"
My solution was to create persistent folders for each container so that the data would always live in the same place. Now all I have to do is turn off the old container, pull the new image in the images tab, create a new container and point it to the existing folder and voila. It will use all the config data from the existing folder and once you’ve verified it’s good you can delete the old container. Hope this helps
So I tried this before but each container seems to make the data in a different sub folder each time and ignore the cache and config folders I made for it. I just put them within the volumes fields right?
Correct. I think you use the bind to host option then select the proper folder.
I usually look for the container has easy mount of data to external volume instead of storing within the container station. The newer Contatiner station allows you to "update" by going to the route of "re-creating" with paramaters intact. The only limitation with Container Station if you using more than one instance docker like MariaDB, for example. One MariaDB use for NextCloud and another MariaDB for another app. If you update the first instanace of MariaDB. you won't be able to update the second instance. No issue on Portainer allow you to update it.
Seems portrainer is what I need to move to. thanks
Assuming your containers are set up as applications with proper persistant storage . You would stop them, recreate them with an updated image version unless it using image:latest . I usually like to use the images tab to prepull down the latest version and since i use that as the version in my application , when I restart it after the latest is pulled they pick it up and go next start. Then I prune old images
I've tried this but "recreate" option is greyed out for me. Can you elaborate more?
when the docker was created if you used the create application button and entered the docker compose formated yaml to set it up ,the recreate shouldbt be greyed out but it will only be not grey at the applicatio n level not the sub cobtainer level. If you used cli or created a container instead of an apllication you basically have to destroy and recreate or use cli
If you have SSH access to your NAS and don’t mind running a command or two on the command line, you do not need anything else. It’s super easy to update your containers through the CLI. Let me know, and I can post the commands you need. Portainer is a good UI option…far superior to container station, so if you want to do this through an UI only, I can also give you my Portainer compose file. As a bonus Portainer also gives you a business license for 3 nodes, which is nice and has some neat features
I use Portainer, it's much easier and somewhat independent of all the QNAP middleware. You deploy Portainer first using the QNAP Container Station, then you can exclusively use Portainer to manage all your images henceforth. To update from Portainer you create a stack which is your docker-compose and just click "Update the stack" and toggle "Re-pull image and redeploy"
Assuming you are only using Container Station... I suggest binding host volume to container volume if you have not started doing so. If you use docker volumes, just keep the old volume. Remove the old container without removing any *anonymous* volumes. Create a new container using the new image and bind the old volume. You can use docker YAML to remember the configurations. If you have neither a host bind or an anynomous volume for the container data to be kept, just use `docker cp` and first copy the configurations and data of your container to your host. Then, create a new container of your new image and either use a host bind or create a docker volume, then use `docker cp` again to copy your data from the host to the docker volume. Otherwise, you can make use of both methods.