3 ms·

> I disagree. How do you update manually? If your answer is ssh in and manually update, that's how you end up with a pile of different versions, and no referenc

• maccard 6y ago
  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
  • chmod775 6y ago
    > 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: 1. Add my repository 2. apt-get install my-app unattended-upgrades sshguard ... 3. config like setting the db server 4. reboot 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.
    • 6y ago