What we collectively refer to as "containers" and software like Docker are just tools that take advantage of various facilities provided by the OS which allow one to isolate/restrict various resources like CPU, memory, network, visibility of other processes, filesystem access, fs layering and namespacing, provide traffic shaping, etc.<p>These isolation features go back a really long time in various OS's, but only in the last few years have they seen mass adoption, which, alas is running a bit ahead of any effort to make it a formal standard or anything even close to that.<p>And so the way you would create a "container" on Linux is very different from the way you'd do that on FreeBSD or Solaris or Windows. Docker was one of the first pieces of software to facilitate that on Linux (where it was and still is far from trivial), along with the whole docker image dockerhub ecosystem, etc. But ultimately what Docker does amounts to the right commands (or system calls) done, and you can have the same effect without Docker (there's even a nice Docker talk on youtube somewhere that shows how to do what Docker does without it from the command line).<p>IMHO in the developer community at large few people care to understand the operating system intimately, and even fewer people know stuff like cgroups or the tc command on Linux, and that's primarily why Docker is so popular - you don't need to know any of it.<p>I think it'd be nice if people stopped using "Docker" and "container" interchangeably, and if a set of tools emerged which would be more part of the OS distribution and less a separate concept/brand/company/whatever and was more or less uniform across, at least the Un*x-like OSs.
Reminds me of the Mesos Unified Containerizer. Very good stuff. The docker client is wonderful for developers, but the docker engine is the bane of operations. The bugs in it are not fun. My favorite one was in docker 1.6.0. When you did:<p><pre><code> docker exec -it $container bash
</code></pre>
It caused a Nil pointer dereference and crashed the daemon. All of the other running containers then would die as a result.<p>Awesome.
Nomad will run your apps in containers without docker: <a href="https://www.nomadproject.io/docs/drivers/exec.html" rel="nofollow">https://www.nomadproject.io/docs/drivers/exec.html</a><p>The Java driver does slightly less containerization, but there's also a QEMU/KVM driver if you need more isolation than containers offer.<p>Edit: Noticed someone mentioned LXC: initial LXC support will hopefully make it into the upcoming 0.5 release: <a href="https://github.com/hashicorp/nomad/pull/1699" rel="nofollow">https://github.com/hashicorp/nomad/pull/1699</a><p>(Sorry for the shill, I recently joined the Nomad team and am pretty excited!)
I've a hard time positioning this along side the effort to support rkt in Kubernetes. Would OCID be necessary because there's too much Docker-only code to interface with the container runtime in Kubernetes?<p>I think I expected rkt to be fully OCI compatible in the future but it looks like Kubernetes itself needs to be able to interface with OCI runtimes and there's work to be done in that area? The Docker integration cuts too deep currently?
Since this has turn into a generic "What's up with containers" post:<p>What is wrong with LXC/LXD/Juju by Ubuntu?<p>I haven't used that latter two (I haven't taken the time to learn them) but LXC is a breeze. Set up a bridge on a host, and start creating containers! Isolated, with resource management capabilities available. LXD is the orchestration at scale component.<p>It's Linux specific, and it's more of a lightweight VM than a one-click-app like Docker images seem to be. Maybe that's the difference.
Is anyone here running Docker or Kubernetes in production?
If so, what parts of your stack are running inside of it, versus what parts are running elsewhere in VMs or bare metal?
The content is ripped off from <a href="http://thenewstack.io/oci-building-way-kubernetes-run-containers-without-docker/" rel="nofollow">http://thenewstack.io/oci-building-way-kubernetes-run-contai...</a>
Somebody please point to the original article