Docker has been gathering a substantial about of interest as an additional way to solve application portability and dependency hell. We’ve been enthusiastic participants in this fledgling community (Docker in OpenStack) and my work in DefCore’s Tempest in a Container (TCUP).
In OpenCrowbar, we’ve embedded Docker much deeper to solve a few difficult & critical problems: speeding up developing multi-node deployments and building the environment for the containers. Check out my OpenCrowbar does Docker video or the community demo!
Bootstrapping Docker into a DevOps management framework turns out to be non-trivial because integrating new nodes into a functioning operating environment is very different on Docker than using physical servers or a VMs. Containers don’t PXE boot and have more limited configuration options.
How did we do this? Unlike other bare metal provisioning frameworks, we made sure that Crowbar did not require DHCP+PXE as the only node discovery process. While we default to and fully support PXE with our sledgehammer discovery image, we also allow operators to pre-populate the Crowbar database using our API and make configuration adjustments before the node is discovered/created.
We even went a step farther and enabled the Crowbar dependency graph to take alternate routes (we call it the “provides” role). This enhancement is essential for dealing with “alike but different” infrastructure like Docker.
The result is that you can request Docker nodes in OpenCrowbar (using the API only for now) and it will automatically create the containers and attach them into Crowbar management. It’s important to stress that we are not adding existing containers to Crowbar by adding an agent; instead, Crowbar manages the container’s life-cycle and then then work inside the container.
Getting around the PXE cycle using containers as part of Crowbar substantially improves Ops development cycle time because we don’t have to wait for boot > discovery > reboot > install to create a clean environment. Bringing fresh Docker containers into a dev system takes seconds instead,
The next step is equally powerful: Crowbar should be able to configure the Docker host environment on host nodes (not just the Admin node as we are now demonstrating). Setting up the host can be very complex: you need to have the correct RAID, BIOS, Operating System and multi-NIC networking configuration. All of these factors must be done with a system perspective that match your Ops environment. Luckily, this is exactly Crowbar’s sweet spot!
Until we’ve got that pulled together, OpenCrowbar’s ability to use upstream cookbooks and this latest Dev/Test focused step provides remarkable out of the gate advantages for everyone build multi-node DevOps tools.
PS: It’s worth noting that we’ve already been using Docker to run & develop the Crowbar Admin server. This extra steps makes Crowbar even more Dockeriffic.
Pingback: OpenStack Update – Icehouse Release Update | Docker Blog
Pingback: Can’t Contain(erize) the Hype – is Docker real or a bubble? | Rob Hirschfeld
Pingback: OpenCrowbar.Anvil released – hammering out a gold standard in open bare metal provisioning | Rob Hirschfeld
Pingback: OpenStack – Icehouse Release Update | Docker Blog