Updating with Docker
Found yet another feature about Docker that I like, but it does come with caveats. And that is updating images and containers.
Last night I stumbled across a post indicating the Home Assistant had been updated. Herein comes the first caveat, and it is a small one. There was no indicating in Docker that my image was out of date. While a notification would be good, it makes a bit of sense. Firstly, the UI I'm using is Portainer, not actually part of Docker itself. Docker itself has no dedicated UI. It is also meant for production environments. Upgrading on a whim isn't really a smart idea.
Still, given how well Docker can manage updates, it would be nice.
Next, another caveat. Upgrading a Docker container can illuminate all of the things you did wrong initially. Why? Because you don't actually update a container. You delete it and create a new one. Luckily between good scripts/instructions and playing around, I've generally figured out already what makes sense. And I've followed some best practices here because the same thing applies if you want to move an image elsewhere, and I've been thinking that my desktop is a waste of power for a lot of the things I'm running.
In short, if you're not using named Docker volumes or mapping directories, you're going to need to do more work to get your upgrade working, if you haven't screwed yourself over. That being said, it really doesn't take long for you to stumbled across numerous warnings to mount volumes in the Docker containers. Worst case scenario is your data is in the old container. Best case scenario, the container automatically created an unnamed volume. If there is an unnamed volume you it sounds like you can just remap to the new container.
Last caveat; all of this means you need to hold onto the yaml files or commands you used to load the container originally. THIS is probably the #1 nuisance of the whole thing. I've been keeping these. Again, because I might move stuff off of my desktop and onto a lower power device. I could probably rebuild them easily enough with the information from Portainer. This also means, if you had to run anything in the console afterwards, you'll need to do that again as well.
That sounds like a decent number of caveats. And they sound pretty annoying. So, how can I possibly still be happy about this? Well, once you have the annoying stuff dealt with, you have something special. I didn't delete my old Home Assistant container. I stopped it, and renamed it. Then, I spun up a new one, pointing at the volumes from the first install. I could have even duplicated the volumes had I been afraid upgrading might cause issues.
Now, I have the new version up and running. But, if something breaks, or something is missing, I can shut down the new install, revert back to the old and either stay there or try and figure out what is missing/broken. I'll probably keep the old container in the system but inactive for a week or so. And, when I'm feeling comfortable with the upgrade, I'll nuke it.
Some of the containers I'm running, I may not bother upgrading. MQTT for example. I didn't use named volumes there and it created 2 non-persistent volumes. That being said, there isn't really anything that would go through MQTT that I would need to maintain. I'm not worried about persisting messages and I didn't change anything from the default config. So, in theory I could just nuke it, and throw a new one back out there and never know the different.
Plex has volumes mapped from folders, including configs and media. SQL has volumes mapped for data, though right now it just holds my HA history so I don't care. Next Cloud has named volumes. And, we've already talked about HA.
In short, while there is a bit to learn about upgrading containers. Once you know what to do and you have your containers configured properly to facilitate it, you should find that you can easily test out an upgrade without worry.
My personal recommendation (for home Docker builds as opposed to enterprise) is, rather than named volumes in docker, mount your volumes to known folders on the local filesystem. This makes it the easiest to find and maintain the data. In an enterprise environment, you're not likely to be mounting things like movie collections, or documents or things which already have places on a hard drive, so in that case, using named volumes is better as they'll all be in one place.
For a home build, there are 2 things. As hinted above, you're likely to want to mount to existing folders for some stuff anyway. And so, rather than storing the rest where Docker wants to store it, it makes sense to organize it on the hard drive in a way that makes sense to you personally. That will increase the odds that you take advantage of it.
Anyway, conclusion here is, Docker is pretty cool. I'm more than a little tempted to see what it would take to build a Ubuntu image, add a desktop environment and rdp software and then remote into it. From a dev perspective, it makes the ultimate sand boxed dev environment.
Last night I stumbled across a post indicating the Home Assistant had been updated. Herein comes the first caveat, and it is a small one. There was no indicating in Docker that my image was out of date. While a notification would be good, it makes a bit of sense. Firstly, the UI I'm using is Portainer, not actually part of Docker itself. Docker itself has no dedicated UI. It is also meant for production environments. Upgrading on a whim isn't really a smart idea.
Still, given how well Docker can manage updates, it would be nice.
Next, another caveat. Upgrading a Docker container can illuminate all of the things you did wrong initially. Why? Because you don't actually update a container. You delete it and create a new one. Luckily between good scripts/instructions and playing around, I've generally figured out already what makes sense. And I've followed some best practices here because the same thing applies if you want to move an image elsewhere, and I've been thinking that my desktop is a waste of power for a lot of the things I'm running.
In short, if you're not using named Docker volumes or mapping directories, you're going to need to do more work to get your upgrade working, if you haven't screwed yourself over. That being said, it really doesn't take long for you to stumbled across numerous warnings to mount volumes in the Docker containers. Worst case scenario is your data is in the old container. Best case scenario, the container automatically created an unnamed volume. If there is an unnamed volume you it sounds like you can just remap to the new container.
Last caveat; all of this means you need to hold onto the yaml files or commands you used to load the container originally. THIS is probably the #1 nuisance of the whole thing. I've been keeping these. Again, because I might move stuff off of my desktop and onto a lower power device. I could probably rebuild them easily enough with the information from Portainer. This also means, if you had to run anything in the console afterwards, you'll need to do that again as well.
That sounds like a decent number of caveats. And they sound pretty annoying. So, how can I possibly still be happy about this? Well, once you have the annoying stuff dealt with, you have something special. I didn't delete my old Home Assistant container. I stopped it, and renamed it. Then, I spun up a new one, pointing at the volumes from the first install. I could have even duplicated the volumes had I been afraid upgrading might cause issues.
Now, I have the new version up and running. But, if something breaks, or something is missing, I can shut down the new install, revert back to the old and either stay there or try and figure out what is missing/broken. I'll probably keep the old container in the system but inactive for a week or so. And, when I'm feeling comfortable with the upgrade, I'll nuke it.
Some of the containers I'm running, I may not bother upgrading. MQTT for example. I didn't use named volumes there and it created 2 non-persistent volumes. That being said, there isn't really anything that would go through MQTT that I would need to maintain. I'm not worried about persisting messages and I didn't change anything from the default config. So, in theory I could just nuke it, and throw a new one back out there and never know the different.
Plex has volumes mapped from folders, including configs and media. SQL has volumes mapped for data, though right now it just holds my HA history so I don't care. Next Cloud has named volumes. And, we've already talked about HA.
In short, while there is a bit to learn about upgrading containers. Once you know what to do and you have your containers configured properly to facilitate it, you should find that you can easily test out an upgrade without worry.
My personal recommendation (for home Docker builds as opposed to enterprise) is, rather than named volumes in docker, mount your volumes to known folders on the local filesystem. This makes it the easiest to find and maintain the data. In an enterprise environment, you're not likely to be mounting things like movie collections, or documents or things which already have places on a hard drive, so in that case, using named volumes is better as they'll all be in one place.
For a home build, there are 2 things. As hinted above, you're likely to want to mount to existing folders for some stuff anyway. And so, rather than storing the rest where Docker wants to store it, it makes sense to organize it on the hard drive in a way that makes sense to you personally. That will increase the odds that you take advantage of it.
Anyway, conclusion here is, Docker is pretty cool. I'm more than a little tempted to see what it would take to build a Ubuntu image, add a desktop environment and rdp software and then remote into it. From a dev perspective, it makes the ultimate sand boxed dev environment.
Comments
Post a Comment