3 ms·

Know what’s even faster? Configuring your local host server with the same values as your remote production server. It really isn’t that hard.

afturner 5y ago
Are you suggesting that containerization is worthless?
bhuber 5y ago
It is when your local host server is macos and your remote production server is... anything else. I'm sure the number of people running macos servers in production is quite small in proportion to linux.
rad_gruchalski 5y ago
Been there, done that. 2014: 20k lines of chef code, followed with tons of ansible yaml soup. Containers are better.
- pjmlp 5y ago
  Looking at our Kubernetes/Docker yaml, my soup tastes different but it is still a soup nonetheless.
brimble 5y ago
Cool. I need to roll back to a version from last year, with entirely different versions of daemons (PostgreSQL, et c). Then run that side-by-side with what's currently deployed. I may end up needing to git-bisect and repeat this process a half dozen times—this afternoon. I want none of those deps or configs to hang around, at all, afterward. And I'll need all that gone next week and a whole different set of services installed because I'll be helping out on some other project entirely. But then I'll come back to this and need all those things installed again. At any moment someone might have a question on something else entirely—a whole suite of services, potentially—that, ideally, I'd be able to fire up an try out locally in, at most, a few minutes, then completely eradicate when I'm done so it's not wasting disk space. What's your solution for that? A bunch of full-fat VMs configured with Ansible or something? Been there, done that, less convenient, more resource-intensive, and far noisier/cruftier than Docker (though the script-configured-VM approach is still far better than running that stuff directly on my machine[s], admittedly)
fredoliveira 5y ago
Sorry, no. Unless of course you plan on not doing anything else on your machine. Otherwise it can't be a 1:1 replica of your production environment, which defats the purpose. The reason containerization is so appealing is because it lets you have the same exact setup (to the byte) everywhere. By doing that, you build predictable environments. If your production environments don't require reproducibility that is fine. If you want to figure out what might be causing issues in production by using a setup that has the same dependencies but a different underlying base, fine. But that just won't do for lots and lots of products.

afturner 5y ago

Are you suggesting that containerization is worthless?

bhuber 5y ago

It is when your local host server is macos and your remote production server is... anything else. I'm sure the number of people running macos servers in production is quite small in proportion to linux.

rad_gruchalski 5y ago

Been there, done that. 2014: 20k lines of chef code, followed with tons of ansible yaml soup. Containers are better.

pjmlp 5y ago
Looking at our Kubernetes/Docker yaml, my soup tastes different but it is still a soup nonetheless.

brimble 5y ago

Cool. I need to roll back to a version from last year, with entirely different versions of daemons (PostgreSQL, et c). Then run that side-by-side with what's currently deployed. I may end up needing to git-bisect and repeat this process a half dozen times—this afternoon. I want none of those deps or configs to hang around, at all, afterward. And I'll need all that gone next week and a whole different set of services installed because I'll be helping out on some other project entirely. But then I'll come back to this and need all those things installed again. At any moment someone might have a question on something else entirely—a whole suite of services, potentially—that, ideally, I'd be able to fire up an try out locally in, at most, a few minutes, then completely eradicate when I'm done so it's not wasting disk space. What's your solution for that? A bunch of full-fat VMs configured with Ansible or something? Been there, done that, less convenient, more resource-intensive, and far noisier/cruftier than Docker (though the script-configured-VM approach is still far better than running that stuff directly on my machine[s], admittedly)

fredoliveira 5y ago

Sorry, no. Unless of course you plan on not doing anything else on your machine. Otherwise it can't be a 1:1 replica of your production environment, which defats the purpose. The reason containerization is so appealing is because it lets you have the same exact setup (to the byte) everywhere. By doing that, you build predictable environments. If your production environments don't require reproducibility that is fine. If you want to figure out what might be causing issues in production by using a setup that has the same dependencies but a different underlying base, fine. But that just won't do for lots and lots of products.