4 ms·

> if you can take the time to understand VMs then you can (and should, IMO) take the time to understand how containers work as well I don't see it as VMs vs co

> if you can take the time to understand VMs then you can (and should, IMO) take the time to understand how containers work as well I don't see it as VMs vs containers. We have a good devops process to deploy onto our instances, so we rarely have resource clashes you mention (ports/directories) because none of that is ever configured manually. All our infrastructure is derived from 'scripts', so it hasn't been a problem at all. Aside from python, I see no advantage in containerizing any of our processes at all. As for debugging, I always forget how infuriating it is, till in the heat of the moment I have to open up a shell into someone's badly made docker image and try to use common tools to help diagnose a problem (ps, nslookup, dig, all) all missing from the wonderful little container. It's like being on a big navy ship, stranded in the ocean because the engines broke down, but everyone left all the tools back at the base. Yay!

hardwaresofton 7y ago
> I don't see it as VMs vs containers. It's not? I didn't mean to pit them against each other in competition, I'm saying that if VMs are worth learning about and taking the time time to understand, so are containers. It doesn't have to be zero sum. > We have a good devops process to deploy onto our instances, so we rarely have resource clashes you mention (ports/directories) because none of that is ever configured manually. All our infrastructure is derived from 'scripts', so it hasn't been a problem at all. It seems like it was a class of problems that you have fixed with "good devops process". I'd argue that it probably was a problem at once point, and you improved your devops process to make sure it wasn't. > Aside from python, I see no advantage in containerizing any of our processes at all. Well I don't know your infrastructure so I'm can't comment on that. I doubt that python is the only thing you run that could benefit from containerization (which again, means limiting access to system resources through namespaces and cgroups), but if you say so then I have no choice but to believe that it's the case. > As for debugging, I always forget how infuriating it is, till in the heat of the moment I have to open up a shell into someone's badly made docker image and try to use common tools to help diagnose a problem (ps, nslookup, dig, all) all missing from the wonderful little container. Sounds like you could use some more of that "good devops process" you had when you set up the deploy machinery. Also, the fact that all of that stuff is missing from the container is actually beneficial from a security point of view -- the same inconvenience you're experiencing is the same inconvenience an intruder would experience first before breaking out of the container (assuming they had the skill to do that). This means that you have another chance to catch them downloading and/or running `ps`/`nslookup`/`bash` or whatever tooling and flag the suspicious behavior. Whether you're in a VM or not, containers are another line of defense, and that's almost certainly a good thing.
- gerbilly 7y ago
  > It seems like it was a class of problems that you have fixed with "good devops process". I'd argue that it probably was a problem at once point, and you improved your devops process to make sure it wasn't. It certainly was but we fixed it and it's not a problem anymore. > Sounds like you could use some more of that "good devops process" you had when you set up the deploy machinery. Yeah, there are people within my group that want to 'modernize' things and put them into containers willy nilly for no real reason. We have already solved all the difficult problems that containers are supposed to 'save' us from. Many of the proposed containers would just be a single statically linked binary with a config file. Why? FYI, our stuff is hosted internally, so security considerations are not such a big deal. To hear these container advocates, you'd think that till they came around no one ever managed to use linux. I'm fully expecting linux userland tools to go away, to be replaced by custom 'distributions' with only a kernel and a docker API soon.
  - hardwaresofton 7y ago
    > I'm fully expecting linux userland tools to go away, to be replaced by custom 'distributions' with only a kernel and a docker API soon. They're already here! - CoreOS Container Linux (now owned by Redhat)[0] - RancherOS[1] - Kubic[2] (more focused on running Kubernetes, but same idea) There are also tools like Linuxkit[3] which focus on helping you actually build images that run the containers you want and nothing else @ startup, which is pretty cool I think. [0]: https://coreos.com/os/docs/latest/ https://coreos.com/os/docs/latest/ [1]: https://rancher.com/rancher-os/ https://rancher.com/rancher-os/ [2]: https://kubic.opensuse.org/ https://kubic.opensuse.org/ [3]: https://github.com/linuxkit/linuxkit https://github.com/linuxkit/linuxkit

hardwaresofton 7y ago

> I don't see it as VMs vs containers. It's not? I didn't mean to pit them against each other in competition, I'm saying that if VMs are worth learning about and taking the time time to understand, so are containers. It doesn't have to be zero sum. > We have a good devops process to deploy onto our instances, so we rarely have resource clashes you mention (ports/directories) because none of that is ever configured manually. All our infrastructure is derived from 'scripts', so it hasn't been a problem at all. It seems like it was a class of problems that you have fixed with "good devops process". I'd argue that it probably was a problem at once point, and you improved your devops process to make sure it wasn't. > Aside from python, I see no advantage in containerizing any of our processes at all. Well I don't know your infrastructure so I'm can't comment on that. I doubt that python is the only thing you run that could benefit from containerization (which again, means limiting access to system resources through namespaces and cgroups), but if you say so then I have no choice but to believe that it's the case. > As for debugging, I always forget how infuriating it is, till in the heat of the moment I have to open up a shell into someone's badly made docker image and try to use common tools to help diagnose a problem (ps, nslookup, dig, all) all missing from the wonderful little container. Sounds like you could use some more of that "good devops process" you had when you set up the deploy machinery. Also, the fact that all of that stuff is missing from the container is actually beneficial from a security point of view -- the same inconvenience you're experiencing is the same inconvenience an intruder would experience first before breaking out of the container (assuming they had the skill to do that). This means that you have another chance to catch them downloading and/or running `ps`/`nslookup`/`bash` or whatever tooling and flag the suspicious behavior. Whether you're in a VM or not, containers are another line of defense, and that's almost certainly a good thing.

gerbilly 7y ago
> It seems like it was a class of problems that you have fixed with "good devops process". I'd argue that it probably was a problem at once point, and you improved your devops process to make sure it wasn't. It certainly was but we fixed it and it's not a problem anymore. > Sounds like you could use some more of that "good devops process" you had when you set up the deploy machinery. Yeah, there are people within my group that want to 'modernize' things and put them into containers willy nilly for no real reason. We have already solved all the difficult problems that containers are supposed to 'save' us from. Many of the proposed containers would just be a single statically linked binary with a config file. Why? FYI, our stuff is hosted internally, so security considerations are not such a big deal. To hear these container advocates, you'd think that till they came around no one ever managed to use linux. I'm fully expecting linux userland tools to go away, to be replaced by custom 'distributions' with only a kernel and a docker API soon.
- hardwaresofton 7y ago
  > I'm fully expecting linux userland tools to go away, to be replaced by custom 'distributions' with only a kernel and a docker API soon. They're already here! - CoreOS Container Linux (now owned by Redhat)[0] - RancherOS[1] - Kubic[2] (more focused on running Kubernetes, but same idea) There are also tools like Linuxkit[3] which focus on helping you actually build images that run the containers you want and nothing else @ startup, which is pretty cool I think. [0]: https://coreos.com/os/docs/latest/ https://coreos.com/os/docs/latest/ [1]: https://rancher.com/rancher-os/ https://rancher.com/rancher-os/ [2]: https://kubic.opensuse.org/ https://kubic.opensuse.org/ [3]: https://github.com/linuxkit/linuxkit https://github.com/linuxkit/linuxkit