4 ms·

This sounds like container kool-aid to me. One can implement exactly the same processes using regular OS management tools as with container tools. They both sti

by orev 4y ago

This sounds like container kool-aid to me. One can implement exactly the same processes using regular OS management tools as with container tools. They both still need the same information about order, testing, etc. If you’ve only ever put the effort towards doing that in a container instead of at the OS level, then obviously your container procedure will be better because you already built it. Someone who already built it at the OS level will also have similar ease. (And those containers still need to run somewhere, and that somewhere invariably has an OS involved, so you always need the OS update process no matter what your container strategy looks like). But you’re also thinking “small” in the sense that you’re only focused on your own app. I find it striking how so many developers these days have simply forgotten that they’re not the only ones who actually do tech stuff, and how limited their views are. Running IT at a company involves hundreds of applications that are not built by you. Just because they’re not the main thing you sell doesn’t mean you can ignore that they exist.

alanfranz 4y ago
"Entering" a server and running "apt dist-upgrade" probably means you've got a stateful fleet, because some package upgrade can fail, it can be performed at different time from one server to another, et cetera. Your servers should be cattle, not pet. So, you should instead create a sort of manifest/snapshot/checkpoint with all your deps pinned, and distribute that to your servers. You can do the same without containerization - you could use a fleet of machines and keep their versions pinned with a configuration management tool, but you'd still not want to manually perform an apt upgrade on your server. And manually "check that everything is fine and maybe reboot" to verify your new shared lib was loaded - you should already have a precise, reproducible, automated testing and upgrade procedure and just apply that. So, containerization is not the point here. Automation of deployment and testing procedures is. But the OP was specifically attacking containerization (as if it were the problem), and I was answering him. But, containerization is generally useful here, because the "container image" is, generally speaking, a good, well-defined artifact. So the OP's example was especially bad - telling "machine X is vulnerable to SSL bug Y" is hard, requires specific machine instance inspection: what happens if the process/server wasn't restarted and, even though package is updated, it's still using an old ssl version? On the contrary, "this is using container image version X with openssl version Y which is not vulnerable" is a very precise True/False statement, easy to inspect and verify at scale.

by orev 4y ago

alanfranz 4y ago

"Entering" a server and running "apt dist-upgrade" probably means you've got a stateful fleet, because some package upgrade can fail, it can be performed at different time from one server to another, et cetera. Your servers should be cattle, not pet. So, you should instead create a sort of manifest/snapshot/checkpoint with all your deps pinned, and distribute that to your servers. You can do the same without containerization - you could use a fleet of machines and keep their versions pinned with a configuration management tool, but you'd still not want to manually perform an apt upgrade on your server. And manually "check that everything is fine and maybe reboot" to verify your new shared lib was loaded - you should already have a precise, reproducible, automated testing and upgrade procedure and just apply that. So, containerization is not the point here. Automation of deployment and testing procedures is. But the OP was specifically attacking containerization (as if it were the problem), and I was answering him. But, containerization is generally useful here, because the "container image" is, generally speaking, a good, well-defined artifact. So the OP's example was especially bad - telling "machine X is vulnerable to SSL bug Y" is hard, requires specific machine instance inspection: what happens if the process/server wasn't restarted and, even though package is updated, it's still using an old ssl version? On the contrary, "this is using container image version X with openssl version Y which is not vulnerable" is a very precise True/False statement, easy to inspect and verify at scale.