5 ms·

This is really off-base, misses the point, and is another form of the "you don't need containers" criticism which has become very tired at this point. This is

by apeace 9y ago

This is really off-base, misses the point, and is another form of the "you don't need containers" criticism which has become very tired at this point. This is mostly a critique of microservice architectures, not containers. If that were the main point I'd have little disagreement. > Someone in security is weeping for the unpatched CVEs... > ...the heavyweight app containers shipping a full operating system aren't being maintained at all... This is just wrong, it's the opposite of that. Never have I had more up-to-date operating systems, programming languages, and frameworks than when I started using containers. It's just so damn easy, especially if you use `FROM python:3` instead of `FROM python:3.6.2`. It auto-updates every time you deploy. > There is no substitute for experimentation in your real production environment; containers are orthogonal to that... They're not orthogonal to it, they're a really useful way to get very, very close to production. The maxim isn't untrue, but again, I sleep better than I ever have in my life because I know that these problems are now rare for me. The difference between my local, staging, and production is tiny. I haven't encountered such an issue in over a year. All of the problems in the article are true no matter what tools you use to build and deploy. The author focuses a lot on developers' desire to go off in a corner and build their own little world. That's still a risk if you're using Ansible or Chef. Bottom line: writing a Dockerfile is the most powerful way I've ever found to define your OS's configuration in code. Stop discouraging people from trying it just so you can make grand arguments about the types of problems every engineering team faces.

deleted 9y ago
[deleted]
DougWebb 9y ago
How does "It auto-updates every time you deploy" fit with "The difference between my local, staging, and production is tiny"? It sounds like you have little control over your dependencies, and the differences between your local, staging, and production environments are the newer versions of your dependencies which you haven't tested against. I like the idea of being able to precisely control both my code and all of my dependencies, so that I know for certain that I'm deploying exactly the same overall system that I tested. Containers are much better for that than the old way, because you could never be certain that your OS and system software were exactly the same in production as they were local and staging. But to achieve that precision, you need to use precise version numbers, and you need to install your dependencies from a local repository to be really sure.
- rowyourboat 9y ago
  > How does "It auto-updates every time you deploy" fit with "The difference between my local, staging, and production is tiny"? It builds once, and then that very container with those dependencies gets pushed through testing, staging, and production. No more changes happen after the build.
  - DougWebb 9y ago
    Ok, that definitely works, assuming you set your process up that way. In my mind, "deploy" starts with build and targets a single environment. Eg: deploy to staging, deploy to production. I've been working with too many clients these past few years who do it that way. One has a real TeamCity CI setup, but they rebuild for production too. Way back in the day, I helped push my company towards a process where build artifacts were tied to specific commit ids (SVN, back then) so that everything that reached production could be traced back through QA and Development. So, basically the process you described. No containers back then, of course, and no VMs either. We had real servers in our server farm.
    - _ix 9y ago
      I thought the very basis of continuous integration/delivery was the same build moving through various stages of readiness and environments until it’s delivered to production, automatically and continuously. In short, if it’s called continuous delivery, that’s about the only way the process could be setup with containers and still be called CD. Or am I mistaken?
- viraptor 9y ago
  I think that by "It auto-updates every time you deploy." the OP meant - every time you build an image to deploy. But that exact same image goes through testing environments. (test -> staging -> prod) Local may test with something that's a point release further, but in that case you'd find the issue when testing and pin the python to a specific 3.6.x until you resolve the problem and start rolling again. There's also nothing preventing your from building images with precise control over versions of your dependencies. You can do it in the image in the same way you'd do it anywhere else. Specify your own repos and use lock files, or whatever your language allows.
acdha 9y ago
It’s not off-base, just outside of your personal experience. This shows in your first comment about updating when you deploy: think about a large and not especially functional environment where there’s stuff written by vendors, contractors, acquisitions which have been folded into various areas, etc. They might not be deployed very frequently at all, and nobody in ops is sure which can handle a rebuild, whether the upstream images for all of those containers are still getting updates or whether upgrades will break something else, etc. They track Red Hat CVEs but not Alpine, etc. The corporate security scanner looks at the base OS but doesn’t know how to introspect containers – or it’s Red Hat’s and doesn’t know how to handle anything which doesn’t use rpm, etc. Performance is similar: containers add a layer of complexity which requires a lot of tools and practice to change – arguably for the better but many places weren’t doing so well even before the problem got harder. I still think containers are the best answer to a ton of operational needs but it’s absolutely true that better tooling is needed for a bunch of problems, and this is repeating the classic hype cycle where it’s being billed as a cure-all when in fact it’s still going to require time, staffing, and a commitment to do the job well. As an example, start with the easiest problem: say you want to prove that you’ve installed the latest OpenSSL patch. On traditional servers, this is a well solved problem. If you’re using Docker, your options are to buy a commercial offering with a support contract or, if your purchasing process is dysfunctional, build something around Clair, which has a bunch of usable but not great tools. If you’re the ops person looking at that, you’re probably thinking this just made your life worse even if there’s the promise that in some indefinite future it could get better. I’m hoping that the OSS community starts rounding out rough edges like that because it’s definitely an enterprise adoption barrier.
stuntkite 9y ago
I happened to get thrust into a large orgs ops management position 4 years ago and got to be on the bleeding edge of usable docker and kubernetes. I'm right with you on this. I was lucky enough to get to slog through this stuff hard and have been building containerized development and operations systems as a huge amount of my work ever since. I get the author's position and I think it's likely the case for most people if they are asked to "Just use containers." It takes planning, knowledge, and a pretty multiclassed skill set to put together great container operations but even from day one when I realized I could isolate node (way before nvm) it was a godsend. I barely run anything on my base system anymore. Everything I put together is now a cascading series of helm charts that easily deconstruct into bare metal deploy. The developers on my team are able to move fast with it because I stay ahead of it and make sure the tools are usable and documented before they are even thinking about them. I can take really obtuse customer integrations and quickly come up with solutions that don't create friction because of how fast I can break them and "infra as code" their way into our stack so no one has to deal with the fact that the API is garbage. I deploy things with health and liveness checks, I get reporting across the board of usage. Anything I want to flight to the world or internally is authenticated through our LDAP/Directory/GHA and I don't need a server troll to administer it. I fully understand people not wanting to use them and just stick to what they know, but containers are amazing and I use them at micro to macro scale. Like you, my code has never been so up to date. It's fun to write a glib article about how you don't like things that are happening. Great if you don't wanna learn them soup to nuts, but to dismiss their value so absolutely really misses a ton of opertunity. Even if it's many many pain in the ass weekends to get fluid with it.
- cat199 9y ago
  > I don't need a server troll to administer it. spoken like a true 'server troll' just saying...
heroprotagonist 9y ago
> It's just so damn easy, especially if you use `FROM python:3` instead of `FROM python:3.6.2`. It auto-updates every time you deploy. There's an issue with that. You're trusting whoever builds the python:3 image to actually update it and be secure. There are a couple high CVEs in python:3 image, including a 10: https://security-tracker.debian.org/tracker/CVE-2017-17458 https://security-tracker.debian.org/tracker/CVE-2017-17458 https://security-tracker.debian.org/tracker/CVE-2017-17499 https://security-tracker.debian.org/tracker/CVE-2017-17499 Then there are a bunch of other medium and low CVE, mostly from imagemagick, which is kind of a shame to include if you really don't need it. Same goes for that 10 for mercurial if that's useless to your project too. You are best off receiving a base image from a trusted source, eg, if your organization maintains a set, or there is some distribution you trust who provides just the OS. Grab the most minimal set, then add your application on top of that. Make sure you go through a check to ensure you're not adding any insecurities yourself.

by apeace 9y ago

deleted 9y ago

[deleted]

DougWebb 9y ago

How does "It auto-updates every time you deploy" fit with "The difference between my local, staging, and production is tiny"? It sounds like you have little control over your dependencies, and the differences between your local, staging, and production environments are the newer versions of your dependencies which you haven't tested against. I like the idea of being able to precisely control both my code and all of my dependencies, so that I know for certain that I'm deploying exactly the same overall system that I tested. Containers are much better for that than the old way, because you could never be certain that your OS and system software were exactly the same in production as they were local and staging. But to achieve that precision, you need to use precise version numbers, and you need to install your dependencies from a local repository to be really sure.

rowyourboat 9y ago
> How does "It auto-updates every time you deploy" fit with "The difference between my local, staging, and production is tiny"? It builds once, and then that very container with those dependencies gets pushed through testing, staging, and production. No more changes happen after the build.
- DougWebb 9y ago
  Ok, that definitely works, assuming you set your process up that way. In my mind, "deploy" starts with build and targets a single environment. Eg: deploy to staging, deploy to production. I've been working with too many clients these past few years who do it that way. One has a real TeamCity CI setup, but they rebuild for production too. Way back in the day, I helped push my company towards a process where build artifacts were tied to specific commit ids (SVN, back then) so that everything that reached production could be traced back through QA and Development. So, basically the process you described. No containers back then, of course, and no VMs either. We had real servers in our server farm.
  - _ix 9y ago
    I thought the very basis of continuous integration/delivery was the same build moving through various stages of readiness and environments until it’s delivered to production, automatically and continuously. In short, if it’s called continuous delivery, that’s about the only way the process could be setup with containers and still be called CD. Or am I mistaken?
viraptor 9y ago
I think that by "It auto-updates every time you deploy." the OP meant - every time you build an image to deploy. But that exact same image goes through testing environments. (test -> staging -> prod) Local may test with something that's a point release further, but in that case you'd find the issue when testing and pin the python to a specific 3.6.x until you resolve the problem and start rolling again. There's also nothing preventing your from building images with precise control over versions of your dependencies. You can do it in the image in the same way you'd do it anywhere else. Specify your own repos and use lock files, or whatever your language allows.

acdha 9y ago

It’s not off-base, just outside of your personal experience. This shows in your first comment about updating when you deploy: think about a large and not especially functional environment where there’s stuff written by vendors, contractors, acquisitions which have been folded into various areas, etc. They might not be deployed very frequently at all, and nobody in ops is sure which can handle a rebuild, whether the upstream images for all of those containers are still getting updates or whether upgrades will break something else, etc. They track Red Hat CVEs but not Alpine, etc. The corporate security scanner looks at the base OS but doesn’t know how to introspect containers – or it’s Red Hat’s and doesn’t know how to handle anything which doesn’t use rpm, etc. Performance is similar: containers add a layer of complexity which requires a lot of tools and practice to change – arguably for the better but many places weren’t doing so well even before the problem got harder. I still think containers are the best answer to a ton of operational needs but it’s absolutely true that better tooling is needed for a bunch of problems, and this is repeating the classic hype cycle where it’s being billed as a cure-all when in fact it’s still going to require time, staffing, and a commitment to do the job well. As an example, start with the easiest problem: say you want to prove that you’ve installed the latest OpenSSL patch. On traditional servers, this is a well solved problem. If you’re using Docker, your options are to buy a commercial offering with a support contract or, if your purchasing process is dysfunctional, build something around Clair, which has a bunch of usable but not great tools. If you’re the ops person looking at that, you’re probably thinking this just made your life worse even if there’s the promise that in some indefinite future it could get better. I’m hoping that the OSS community starts rounding out rough edges like that because it’s definitely an enterprise adoption barrier.

stuntkite 9y ago

I happened to get thrust into a large orgs ops management position 4 years ago and got to be on the bleeding edge of usable docker and kubernetes. I'm right with you on this. I was lucky enough to get to slog through this stuff hard and have been building containerized development and operations systems as a huge amount of my work ever since. I get the author's position and I think it's likely the case for most people if they are asked to "Just use containers." It takes planning, knowledge, and a pretty multiclassed skill set to put together great container operations but even from day one when I realized I could isolate node (way before nvm) it was a godsend. I barely run anything on my base system anymore. Everything I put together is now a cascading series of helm charts that easily deconstruct into bare metal deploy. The developers on my team are able to move fast with it because I stay ahead of it and make sure the tools are usable and documented before they are even thinking about them. I can take really obtuse customer integrations and quickly come up with solutions that don't create friction because of how fast I can break them and "infra as code" their way into our stack so no one has to deal with the fact that the API is garbage. I deploy things with health and liveness checks, I get reporting across the board of usage. Anything I want to flight to the world or internally is authenticated through our LDAP/Directory/GHA and I don't need a server troll to administer it. I fully understand people not wanting to use them and just stick to what they know, but containers are amazing and I use them at micro to macro scale. Like you, my code has never been so up to date. It's fun to write a glib article about how you don't like things that are happening. Great if you don't wanna learn them soup to nuts, but to dismiss their value so absolutely really misses a ton of opertunity. Even if it's many many pain in the ass weekends to get fluid with it.

cat199 9y ago
> I don't need a server troll to administer it. spoken like a true 'server troll' just saying...

heroprotagonist 9y ago

> It's just so damn easy, especially if you use `FROM python:3` instead of `FROM python:3.6.2`. It auto-updates every time you deploy. There's an issue with that. You're trusting whoever builds the python:3 image to actually update it and be secure. There are a couple high CVEs in python:3 image, including a 10: https://security-tracker.debian.org/tracker/CVE-2017-17458 https://security-tracker.debian.org/tracker/CVE-2017-17458 https://security-tracker.debian.org/tracker/CVE-2017-17499 https://security-tracker.debian.org/tracker/CVE-2017-17499 Then there are a bunch of other medium and low CVE, mostly from imagemagick, which is kind of a shame to include if you really don't need it. Same goes for that 10 for mercurial if that's useless to your project too. You are best off receiving a base image from a trusted source, eg, if your organization maintains a set, or there is some distribution you trust who provides just the OS. Grab the most minimal set, then add your application on top of that. Make sure you go through a check to ensure you're not adding any insecurities yourself.