The Curious Case of Linux Containers
medium.com
The Curious Case of Linux Containers
1–10 of 27 posts
Re: The Curious Case of Linux Containers
#2We solve all of those use cases in our cluster management system of which Docker is a key enabling component, except for point 5, though we do have other components that require multiple steps to provision. I bet we could run Hadoop if we needed it.
It's easy to point at Docker and say it's a trivial wrapper around some technologies that have been around for years and call everyone crazy for buying into the 'Docker is going to change the (sysadmin) world' hype. Of course in essence it's pretty trivial, many things are.
Docker, and Docker-like systems really are changing the sysadmin world. Easily formalised software environments is what this hype is about, and the fact that the Docker community isn't really looking at the stateful service problem right, doesn't mean they're not enabled by Docker either.
To me, and to many 'devops' (i.e. developers rolling into sysadmin roles) Docker was eye-opening. We reduced our chef scripts by 80%, and thus our headaches by 95%. It's saving us months of ops work. If you were a seasoned sysadmin and rolling your eyes at the fact that we were rolling out application level services in the same chef codebase we were setting up our system environments with, then yeah you already were better than us. But as far as I could tell the way we used to do it really was the status quo, at least in the startup/small it business world.
Re: The Curious Case of Linux Containers
#3Many of the author's desires are handled in SmartOS (https://www.joyent.com/blog/triton-docker-and-the-best-of-al...)
Re: The Curious Case of Linux Containers
#4Many of the author's desires are handled in SmartOS ( https://www.joyent.com/blog/triton-docker-and-the-best-of-al... )
And OpenShift: https://enterprise.openshift.com/
Re: The Curious Case of Linux Containers
#5Many of the author's desires are handled in SmartOS ( https://www.joyent.com/blog/triton-docker-and-the-best-of-al... )
And OpenShift: https://enterprise.openshift.com/
I'll pile on!
Cloud Foundry is another opensource PaaS: https://www.cloudfoundry.org/learn/features/
(Disclaimer: I work for Pivotal, which donates the majority of engineering effort to Cloud Foundry)
Re: The Curious Case of Linux Containers
#6Author's terminology seems muddled. The first bullet is correct, but only on a technicality, and it fails to point out that strictly there is no "Linux container," only an emergent and weakly cohesive combination of features that as an artifact create a so-called Linux container (as opposed to being a well-defined atomic unit/OS resource). The third bullet equivocates archive formats with application containers.
Re: The Curious Case of Linux Containers
#7What I find curious about all the container discussions and narrative is the strange lack of context. Sure discuss Docker but also discuss namespaces, cgroups, overlayfs, aufs, and all the other critical enabling technologies where a lot of major problems with containers exist and will be solved. For instance user namespaces, cgroups are not namespace aware, how to integrate overlayfs or aufs so they can be mounted by user namespaces seamlessly.
Surely these projects and developers need support and focus. Or else it become mere marketing for companies that have the funds or ability to market themselves. Do we just talk about libvirt without context or understanding of kvm and xen, how would that be useful or meaningful?
An ‘immutable container’ is nothing but launching a copy of a container enabled by overlay file systems like aufs or overlayfs, a ‘stateless’ container is a bind mount to the host. Using worlds like stateless, immutable or idempotent just obscures simple underlying technologies and prevents wider understanding of core Linux technologies that need to be highlighted and supported. How is this a sustainable development model?
Docker chooses to run containers without an init. The big problem here is most if not all apps you want to run in a container are not designed to work in an init less environment and require daemons, services, logging, cron and when run beyond a single host, ssh and agents. This adds a boatload of additional complexity for users before you can even deploy your apps, and a lot of effort is expended is just managing the basic process of running apps and managing their state in this context.
Contrast that with LXC containers which have a normal init and can manage multiple processes enabling for instance your VM workloads to move seamlessly to containers without any extra engineering. Any orchestration, networking, distributed storage you already use will work obviating the need for reinventing. That’s a huge win and a huge use case that makes deployment simple and slices all the complexity, but if you listen to the current container narrative and the folks pushing a monoculture and container standards it would appear there are no alternatives and running init less containers is the only ‘proper’ way to use containers, never mind the additional complexity may only make sense for specific use cases.
Re: The Curious Case of Linux Containers
#8We solve all of those use cases in our cluster management system of which Docker is a key enabling component, except for point 5, though we do have other components that require multiple steps to provision. I bet we could run Hadoop if we needed it. It's easy to point at Docker and say it's a trivial wrapper around some technologies that have been around for years and call everyone crazy for buying into the 'Docker i…
Someone once said that the public cloud was never about virtualization but rather automation. I would contend that the container revolution we're going through now isn't really about containers but ultimately distributed system platforms. And if it changes the way many have traditionally approached problems great!
My main point is that we're really just at the beginning of all of this. I'm not picking on Docker (I'm actually embracing containers) but rather pointing out that many of these next gen solutions are only tackling the basic use cases right now. While I'm excited there is so much more work left to be done. Implementing many of these solutions still requires a bunch of engineering effort and I'd like to see more turnkey solutions. The developer end is definitely getting easier and more productive but the operational end is getting more complex and still not solving some use cases everyone has. How many different ways can different companies implement HA MySQL for example?!
There are tons of other platforms out there that have recognized and solved many of this class of problems for years but the Cloud and microservices are actually starting to make this worse as adoption skyrockets. Platforms are not really a new thing, we went through this with JVM Platforms a ~decade ago, Heroku style PaaS ~five years ago, and now containers + cloud today.
I guess this is what progress looks like :)
Re: The Curious Case of Linux Containers
#9What I find curious about all the container discussions and narrative is the strange lack of context. Sure discuss Docker but also discuss namespaces, cgroups, overlayfs, aufs, and all the other critical enabling technologies where a lot of major problems with containers exist and will be solved. For instance user namespaces, cgroups are not namespace aware, how to integrate overlayfs or aufs so they can be mounted b…
Docker chooses to run containers without an init.
I don't think Docker chooses one way or the other, and people do run Docker with an init: http://phusion.github.io/baseimage-docker/
Re: The Curious Case of Linux Containers
#10What I find curious about all the container discussions and narrative is the strange lack of context. Sure discuss Docker but also discuss namespaces, cgroups, overlayfs, aufs, and all the other critical enabling technologies where a lot of major problems with containers exist and will be solved. For instance user namespaces, cgroups are not namespace aware, how to integrate overlayfs or aufs so they can be mounted b…
> Docker chooses to run containers without an init. The big problem here is most if not all apps you want to run in a container are not designed to work in an init less environment and require daemons, services, logging, cron and when run beyond a single host, ssh and agents.
Do this not confuse init with a process supervisor?