3 ms·

> See: chef, configuration management and various deployment services A chef script is basically the automation of "I need to copy every library of the OS and

by mbesto 11y ago

> See: chef, configuration management and various deployment services A chef script is basically the automation of "I need to copy every library of the OS and every line of code for the kernel and redeploy it every time I add a node?" I'm sorry if you didn't pick up on my implied remark. Two problems are then introduced when automating those actions: (1) it doesn't negate the fact that I need to store and deploy a 700M sized OS layer every time I want to add a node (which takes minutes, not seconds with non-containerized configs) and (2) maintaining config scripts can (not always) be painful (version control, rollbacks, etc) > unless you have very specific use cases. > Containers are like sandboxes with significant overhead for applications Again, do you have experience using containers? You seem awfully dismissive ("you're doing it wrong!") in a way that suggests that you might not entirely understand how they actually work...

jacquesm 11y ago
I'm not dismissive enough to have already committed elsewhere in this thread to re-do a bit of experimentation I did about a year ago on using containers and at the time the performance overhead was such that I failed to see the use case, but since this is a fast moving field it won't hurt me one bit to update my knowledge. In a nutshell: running a 'standard' combo of apache and a DB server as well as some auxiliary bits and pieces inside 'containers' a year ago gave significant overhead compared to running those without the containers. I'll re-do this and I'll probably do a write-up because the subject is interesting. This comment and follow up (https://news.ycombinator.com/item?id=9567623 https://news.ycombinator.com/item?id=9567623) are by people using this tech in production right now and their experience echos mine (but they're very far down the line compared to where I stopped). Besides that particular use case (where performance and isolation are the key components to be looked at) some interesting points have been made in this thread which has shifted my stance on container use depending on what the situation is. So I don't think it is valid to classify me as 'awfully dismissive'. FWIW I have not used containers in production (yet) but I'll be more than happy to if I can figure out where and how they can bring me an advantage, which is pretty much how I approach all tools.
15thandwhatever 11y ago
What I do on our app servers is create a new user for each app (via configuration management). That gives me both environment separation (A needs Ruby 1.9, B needs Ruby 2.0), resource accounting on a per-app basis, and a repeatable foundation in case I need to re-deploy the server or spin up new instances.
- vidarh 11y ago
  That is only true if you use no parts (e.g. shared libraries etc.) of the host environment. That guarantee that you're not inadvertently depending on something on the host system that might change is what containers give you.

by mbesto 11y ago

jacquesm 11y ago

I'm not dismissive enough to have already committed elsewhere in this thread to re-do a bit of experimentation I did about a year ago on using containers and at the time the performance overhead was such that I failed to see the use case, but since this is a fast moving field it won't hurt me one bit to update my knowledge. In a nutshell: running a 'standard' combo of apache and a DB server as well as some auxiliary bits and pieces inside 'containers' a year ago gave significant overhead compared to running those without the containers. I'll re-do this and I'll probably do a write-up because the subject is interesting. This comment and follow up (https://news.ycombinator.com/item?id=9567623 https://news.ycombinator.com/item?id=9567623) are by people using this tech in production right now and their experience echos mine (but they're very far down the line compared to where I stopped). Besides that particular use case (where performance and isolation are the key components to be looked at) some interesting points have been made in this thread which has shifted my stance on container use depending on what the situation is. So I don't think it is valid to classify me as 'awfully dismissive'. FWIW I have not used containers in production (yet) but I'll be more than happy to if I can figure out where and how they can bring me an advantage, which is pretty much how I approach all tools.

15thandwhatever 11y ago

What I do on our app servers is create a new user for each app (via configuration management). That gives me both environment separation (A needs Ruby 1.9, B needs Ruby 2.0), resource accounting on a per-app basis, and a repeatable foundation in case I need to re-deploy the server or spin up new instances.

vidarh 11y ago
That is only true if you use no parts (e.g. shared libraries etc.) of the host environment. That guarantee that you're not inadvertently depending on something on the host system that might change is what containers give you.