By Originally Published On AppFog
You know what’s pretty easy nowadays? Throwing a bunch of processes onto a server running somewhere far away. Dozens. Thousands. Millions. As many as you want. This was really, exasperatingly hard just a few years ago. But Amazon Web Service, CenturyLink, and other players have come along to make this pretty painless.
But you know what’s still really hard? Making those processes completely self-contained and yet running on one kernel and manageable from a single interface. This is the problem that Docker was meant to solve.
Brief intro to Docker
Docker chose to address this problem by building a developer-friendly abstraction layer on top of Linux containers (LXC). LXC is a powerful concept, but it simply wasn’t built as an intuitive interface. It’s a pain to use and prohibitively complicated for anyone but the most adept Linux power users.
And so the idea of enabling developers of all stripes to actually use them in a way that gets rid of tons of conceptual overhead and streamlines the use of containers into an actual runtime that makes real sense amounts to a massive win over the more low-level containerization tools that already exist.
Docker takes LXC and constructs a set of basic commands around it, commands...