Landing a Rocket on a Container Ship, Docker and appc

Docker, initially released in about two years ago, in March 2013, has quickly gained popularity.  The ability of the platform, to make your applications easily portable and deployable, is attractive to many organizations.  Docker has grown from a container engine to a full featured product, which is evident with the purchase Docker just made of SocketPlane.  Networking of containers is a key component to enable them to communicate with each other and other parts of the infrastructure they are deployed in.  Docker has continued to evolve beyond more that a simple container engine.

When CoreOS, an extremely light weight Linux distrubution which lends itself perfectly to the deployment of Docker announced Rocket, their own container runtime environment, many were shocked.  Why would CoreOS suddenly try to play inside a space that had helped them gain so much traction?  What many overlooked was the second part of the Rocket announcement, which was the announcement of the App Container specification.

Rocket, of course, is the main implementation of the App Container spec (also known as appc).  As of Rocket v0.3.2, the ability to download and run Docker images exists, however it doesn’t quite work both ways.  CoreOS is seeking to change this, by entering a pull request to enable this, and hopefully give Docker the ability to run the appc images, or ACIs (not to be confused with Cisco’s ACI).

The rather exciting conversations that happened around the pull request have many people wondering what will come next.  There are definitely strong thoughts on both the Docker and Rocket side of things.  What is most important about this is that it is the core of open source development because it is driven by the community leading products where they need it to go.

It all comes down to four very important words:  Composable.  Secure.  Decentralized.  Open.  These are the core tenets of what appc and Rocket are being built around.  There will undoubtedly be some interesting twists and turns ahead for the container ecosystem, and CoreOS with Rocket will certainly be leading the charge on some of the big news ahead.

(Delta IV Heavy on the launch pad, aka a really big Rocket, photo by me)

Why Rocket?

This is the important question.  We have to think about the use-case we are applying Rocket to.  Docker answered a lot of concerns that came up as people looked at LXC as a potential platform.  Similarly, Rocket answers a lot of concerns that are also being raised around Docker and the management of the container ecosystem.  The fact that the Rocket project was even started is a huge testament to the strength of the open source community, further justification of the level of disruption that Docker has brought to the application world.  SocketPlane is a big feather in the cap for Docker though, so if you are thinking about Rocket, it’s important to understand why you should.

The Spec document for appc has some great example use-cases as well as lots of documentation about the App Container structure.  If you want the full docs on how to run Rocket and App Container, you can follow along with the online docs, which are updated continuously as the features improve.  While getting started with Rocket follows a similar method as getting started with Docker, there is a major key difference.  One of the first things you’ll do with your Rocket install is trusting the CoreOS public key before you get started downloading images.   This reiterates the point that that appc is attempting to be security minded from its inception.

Rocket is still very early in development, but I, for one, can’t wait to see what’s coming next.  The good news is that if you want to run CoreOS (and you should), that you can still run Docker with full support, or you can also embrace Rocket and App Container as well.  Choice is a wonderful thing, and can be a driving force of innovation for both Docker and Rocket.

Melissa Palmer

Melissa is an Independent Technology Analyst & Content Creator, focused on IT infrastructure and information security.  She is a VMware Certified Design Expert (VCDX-236) and has spent her career focused on the full IT infrastructure stack.