My slides and the code I used for the Introduction to Docker talk most recently done at http://newcodecamp.com are available in my github profile at https://github.com/panmanphil/introduction-to-docker
Thanks to all who came! One of the most interesting parts of the talk, helped by the smart people in the room who asked great questions, were the questions about when it is appropriate to use Docker or not. Docker is most often talked about in relationship to microservices, the architectural pattern where you split your application or system into many small, independent services, For this it is easy to say Docker is a great match. Lots of small applications running on a cluster of docker hosts is what it was built for. Another really useful thing is to use docker as an alternative to installing tons of software on your development box, or even on your servers. The files in a Docker image are completely isolated from the host and can be cleanly added and removed at will. You don’t have to create a linux, windows, macox, other versions of your software if people expect to use it via docker.
In the “Docker all the things” camp, you would hear the call to move everything this way, something you hear anyway when a new technology is early in the hype curve. I can say that in my experience so far, there have been some real wins running things in containers:
- small myql instances used for small apps
- redis running locally for development
- riak running locally was much easier to test in docker
On the other hand, while it may have been easier to run jenkins locally in docker, running jenkins in docker at AWS has not been a clear winner: a dedicated host may have made more sense, perhaps setup with vagrant and bash or even ansible (which I now know enough about to say that, thanks Mike Putnam!). The image is over 1GB in size, and it consumes all the memory and cpu the host has available to run Jenkins and one agent. If we could get the image size down, running multiple agents in Docker might make sense though. Life is trade offs, no?
This is really the next phase of my longer term evaluation of Docker, to understand and to be able to more clearly express when it’s great, good and terrible to use Docker.