You still haven't answered my question; how do you update? Yes on one server. If you ssh into that server or poke around on it, how do you rebuild it if aws kills your instance, or if your data center catches fire?
Re; version pinning that's cool - both methods work.
For updates, of course it's automated that's the whole point.
> That's ubuntu, not debian. Very different approach to non-security updates.
Actually this is a really interesting point; I don't want to be a sysadmin, I want to run my applications. I don't want to be aware of the platform differences. I actually didn't know that ubuntu and debian handled updates differently. They both expose the same interface to package management. Features like that are exactly why developers like me should be deploying docker containers to DO's app platforms for $5 a month, and not running VPS's
> If you ssh into that server or poke around on it
Just don't do any manual poking. You can't (really) do that with docker containers, and you shouldn't do it on a random server.
On a virgin server I generally do this to install my application, and I do it with a simple script (you could also use orchestration tools, but that's overkill for <10 servers) because I am even too lazy to enter five commands:
That server will now automatically install security updates, but I need to manually tell it to install/update anything else (because I like it that way). My application, which sometimes is just a package that contains some haproxy/nginx config (if I run the server as a reverse proxy) is installed from my own repository, so I can update the way I'd update anything else on that server. You really shouldn't do anything on that server besides telling it to update (if you haven't set that to be fully automatic).
There's time-tested orchestration tools if you want to automate anything of the above. For some applications I have my build server poke a server that'll make the application on each other server update.
> I don't want to be aware of the platform differences.
I can understand that position, to a degree. But even with docker you'll be using some OS, or package manager repos, (generally) in your container.
If you use the docker repositories however, you're pretty much at the mercy of the update practices of individual packages, whereas with systems like debian you know what you're getting - which for debian is stable, but sometimes not up-to-date packages. And if you build debian-based containers, you should still be aware of this.
In any case it's really worth it to understand how dpkg/apt works and how debian packages work. It's not complicated and can be done in a day or two. You're already using them anyways.
It may also help you better understand exactly what niche docker is filling and you won't have smartasses like myself tilting their heads at you when you list something a typical linux system does (and sometimes does better) as a value proposition for docker.
Basically docker replaces and improves upon what people used to do with VM images. That's what it's competing with in the sysadmin world. It's not directly competing with debian/apt/dpkg/whatever, even though it makes some of their features redundant. It may make working with the latter more forgiving, because you can fiddle with a Dockerfile until it creates something that works, but it doesn't replace them.
Automated updates are great until one is installed that is incompatible with what you actually want to run. Now it's 3 in the morning and you have to find an old version of some package to fix your service.
Obviously protection from this problem isn't something Kube alone provides but it's still a problem with the container-less setup you're describing. Flatpack could be an alternative.
While we're on security - thinking simply installing your program via apt and running it in your VM is in any way compatible to containers in terms of the security benefit is simply wrong. In a container you'd getting filesystem isolation and capability restrictions OOTB. Via some program in apt you're going to have to deal with something like apparmor and a variety of other tools to get something even compatible to a Kube pod with default configs.
> Basically docker replaces and improves upon what people used to do with VM images.
This trivializes the feature set docker actually has.
Re; version pinning that's cool - both methods work.
For updates, of course it's automated that's the whole point.
> That's ubuntu, not debian. Very different approach to non-security updates.
Actually this is a really interesting point; I don't want to be a sysadmin, I want to run my applications. I don't want to be aware of the platform differences. I actually didn't know that ubuntu and debian handled updates differently. They both expose the same interface to package management. Features like that are exactly why developers like me should be deploying docker containers to DO's app platforms for $5 a month, and not running VPS's