4 ms·

I’ve managed to resist the hype and still not ever used docker for anything ... I still really struggle to understand what the practical benefits to this kind

I’ve managed to resist the hype and still not ever used docker for anything ... I still really struggle to understand what the practical benefits to this kind of containerization actually are ... It seems like people reach for it because they want to have some kind of “compile target” into which they can stick “all the things” their application needs to run — which is supposed to then help them “deploy” into their development environment or onto their production infrastructure in a way that serves the goal that the applications within the image should behave the “same way” in either location ... but does anything about this kind of container abstraction actually help with doing this? Don’t you still inevitably end up having to manage assumptions about the differences between these environments in order to make this work in practice (oh if you are in development environment make sure you don’t actually submit payment to stripe, if you are deploying to this cloud provider make sure you get secrets from <here> instead of <here> ...) ...? Do you actually get any good abstractions out of the container which empower better solutions to deployment challenges? “I don’t have to think about which hosts the (random) http client used in my application is configured to talk to because I can just magically retarget it at the container level by manipulating networking configuration” — is that a thing — does it actually work? To my understanding the extent to which you _can_ do that requires you to write your application a certain way with a crazy service discovery layer like istio — and you’ve got to make sure you build your application completely to use service discovery fabric ... but if you built your application to use a service discovery fabric do you gain anything extra by also using docker at that point ...? And what about the impact to developer ergonomics? Is it easy and smooth to use debuggers to quickly edit code running in an image ...? Do people regularly run production docker images locally to debug production application issues ...? Are there solutions that allow one to say, attach to a remote qa testers chrome instance and then automatically attach debugger to the set of production containers handling the requests associated with that browser ...? Those are the kind of features I want ... I’m not sure exactly if the containerization abstraction model would really help me get there or just create another set of configuration knobs that _also_ have to be correctly aligned for me to get the right environment specific behaviors out of my application ...

e40 7y ago
> I still really struggle to understand what the practical benefits to this kind of containerization actually are ... Here's why I started using it years ago. I had a CentOS 6 machine that I wanted to run Plex, Subsonic and Transmission on, but I couldn't, because they had different (EDIT: and conflicting) requirements for various packages. I might have been able to hack it, but it was looking really tricky. Enter Docker. I have all three running in separate Docker containers. And it just works. I've never hand a single problem. I made a yum exception for the Docker packages I use, so I can control when they are updated, which is about once a year. The alternative was to build a new box that met all the requirements, but that seemed like a big waste of resources (electricity and my money).
- chrisan 7y ago
  If you didn't have that requirement of conflicting packages, would you still have used docker? Isn't once a year update a large security risk?
  - Spivak 7y ago
    One would hope they're still taking security updates but on CentOS I kind of doubt they bothered to implement that level of granularity.
  - e40 7y ago
    I probably wouldn't have, had there been no package conflicts. As for security risk on the yearly update: all the services are only locally accessible. None are exposed to anyone but me. I do apply CentOS updates daily, though. My only risk in an attacker on my LAN, and I think I have that locked down well.
clintonb 7y ago
The biggest benefit for edX, which is where I started using Docker and gained the most experience, was being able to get developers up and running with our key services in a couple hours as opposed to days. Everything is scripted, and ephemeral. Broke something? Refresh the environment. Want to try a new configuration? Build a new image. This was not as easy in our previous Vagrant devstack. > Don’t you still inevitably end up having to manage assumptions about the differences between these environments in order to make this work in practice...? Yes, and I would do that regardless of my deploy target. If you follow the Twelve-Factor App methodology [1], your settings are always in a config file or passed in as environment variables. If you're using external services (e.g. Stripe) while developing set the appropriate variables to your test credentials. > Do you actually get any good abstractions out of the container which empower better solutions to deployment challenges? “I don’t have to think about which hosts the (random) http client used in my application is configured to talk to because I can just magically retarget it at the container level by manipulating networking configuration” The solution to this problem is the same regardless of whether you use Docker or a cloud provider. Use a load balancer to direct traffic to a group of hosts responding to a specific port. > And what about the impact to developer ergonomics? Admittedly, debugging is not perfect (at least not with my Docker Compose setup in PyCharm). That said, there are debuggers that attach to Docker containers. [1] https://12factor.net/ https://12factor.net/

e40 7y ago

> I still really struggle to understand what the practical benefits to this kind of containerization actually are ... Here's why I started using it years ago. I had a CentOS 6 machine that I wanted to run Plex, Subsonic and Transmission on, but I couldn't, because they had different (EDIT: and conflicting) requirements for various packages. I might have been able to hack it, but it was looking really tricky. Enter Docker. I have all three running in separate Docker containers. And it just works. I've never hand a single problem. I made a yum exception for the Docker packages I use, so I can control when they are updated, which is about once a year. The alternative was to build a new box that met all the requirements, but that seemed like a big waste of resources (electricity and my money).

chrisan 7y ago
If you didn't have that requirement of conflicting packages, would you still have used docker? Isn't once a year update a large security risk?
- Spivak 7y ago
  One would hope they're still taking security updates but on CentOS I kind of doubt they bothered to implement that level of granularity.
- e40 7y ago
  I probably wouldn't have, had there been no package conflicts. As for security risk on the yearly update: all the services are only locally accessible. None are exposed to anyone but me. I do apply CentOS updates daily, though. My only risk in an attacker on my LAN, and I think I have that locked down well.

clintonb 7y ago

The biggest benefit for edX, which is where I started using Docker and gained the most experience, was being able to get developers up and running with our key services in a couple hours as opposed to days. Everything is scripted, and ephemeral. Broke something? Refresh the environment. Want to try a new configuration? Build a new image. This was not as easy in our previous Vagrant devstack. > Don’t you still inevitably end up having to manage assumptions about the differences between these environments in order to make this work in practice...? Yes, and I would do that regardless of my deploy target. If you follow the Twelve-Factor App methodology [1], your settings are always in a config file or passed in as environment variables. If you're using external services (e.g. Stripe) while developing set the appropriate variables to your test credentials. > Do you actually get any good abstractions out of the container which empower better solutions to deployment challenges? “I don’t have to think about which hosts the (random) http client used in my application is configured to talk to because I can just magically retarget it at the container level by manipulating networking configuration” The solution to this problem is the same regardless of whether you use Docker or a cloud provider. Use a load balancer to direct traffic to a group of hosts responding to a specific port. > And what about the impact to developer ergonomics? Admittedly, debugging is not perfect (at least not with my Docker Compose setup in PyCharm). That said, there are debuggers that attach to Docker containers. [1] https://12factor.net/ https://12factor.net/