In this blog post, we’ll show you how Docker Plugins make portability of stateful microservices possible with Flocker and Weave. There are many reasons why you’d need to move a stateful microservice between servers. The hosts it is running on might die. Or you might need to move to a more powerful machine.
The image above is of a stateful app which stores the location of the Docker logos on the screen in Redis. Read on to learn about the stack that makes it possible to relocate the Redis server to another host and have the app carry on working!
The Docker plugins team
Since December last year it has been a pleasure and a privilege to work closely with the team who worked on the new Docker plugins mechanism. So I’d like to start this post by giving a huge shout out to all the amazing people who made it possible. This truly was a team effort!
- Solomon and the Docker core team: @solomonstre, @calavera, @icecrime, @crosbymichael, @cpuguy83 and @chanezon
- Jeff Lindsay from Glider Labs: @progrium
- The team at Weaveworks: @monadic, @squaremobius and @errordeveloper
- My colleagues on the ClusterHQ Labs team: @kai_davenport and @robhaswell
What are Docker plugins?
As per our guest blog post on the Docker blog, Docker plugins are third party extensions to Docker that can be loaded at runtime.
Using them is as simple as adding the following arguments to a
docker run command after installing the plugins:
How did we get to this point?
If you’ve been following our work on Docker plugins and the Powerstrip project you’ll see that together with our friends listed above we’ve pioneered the composability of prototypical Docker extensions.
It’s pretty cool therefore that with the official launch of the new Docker plugins mechanism, we can finally demo that same composability with official Docker plugins against the new experimental branch of Docker.
In February I said that if we could throw Powerstrip away in 6 months then it would have done its job in enabling Docker to be more extensible. We’re proud to be able to say, 4 months later, that we can do just that, with the announcement of Docker plugins in the experimental channel, which Alexis, Jeff and I got the chance to demo on stage at DockerCon.
(NB: I believe Powerstrip will still be useful for prototyping new Docker extension points, such as API extensions and ones we haven’t even thought of yet.)
Why is composability of Docker plugins important?
Well, at least four things are needed to get Docker into more production environments:
- Composition: being able to describe a multi-container app as a set of connected containers (Docker Compose)
- Scheduling: being able to deploy multiple containers across multiple hosts (Docker Swarm, Mesosphere etc)
- Networking: enabling containers on different hosts to connect to eachother with service discovery (Weave, Calico, Docker Networking etc)
- Storage: having stateful containers (e.g. databases, queues, key-value stores) be able to write some bytes to a filesystem on one node, and later get rescheduled to another host, and still have their data (Flocker)
So we can now demo the complete Docker platform with all of these components working smoothly together!
Now, in case you missed it at DockerCon, we’re proud to be able to show you the same demo of Flocker and Weave we did back in February, done without Powerstrip and with added Compose + Swarm goodness.
Video from DockerCon
- Skip forwards to 10:29 to see the demo.