CoreOS have opened a pull-request to Docker which contains a proof-of-concept modification to enable Docker to run appc app container images (ACIs). At the same time CoreOS have also released a new version of Rocket that supports the native running of Docker images.
Rocket is an application container runtime that fully implements the current state of the CoreOS App Container (appc) specification. Rocket provides a command-line interface that can be used to download, verify and run appc compliant ACIs. The latest v0.3.2. release of Rocket has added the capability to also download and run Docker container images directly from the public Docker Hub or any other Docker Registry.
The native execution of Docker images on Rocket is enabled by leveraging the docker2aci library, which performs a straightforward conversion between images in the Docker format and appc container specification format. The docker2aci library provides functionality to download all of the layers of a Docker image and squash them into an ACI image, or alternatively generate one ACI for each layer and set the correct dependencies.
At the same time as adding Docker support to Rocket, CoreOS have also opened a pull-request to Docker via the project’s Github repository, which enables Docker to run appc ACIs within the specified constraints. The CoreOS blog states that this is a proof of concept implementation, and the primary goal of this pull-request is to start a conversation about closer integration between the Docker and appc communities.
This is a simple functional PR that includes many of the essential features of the image spec. Docker API operations such as image list, run image by appc image ID and more work as expected and integrate with the native Docker experience. As a simple example, downloading and running an etcd ACI works seamlessly with the addition of [a] patchset
Brandon Philips, CTO of CoreOS, has also opened an issue in the Docker Github project entitled “Proposal: App Container (appc) as a Runtime Option in the Docker Engine”, with the stated goal of seeking feedback on whether any modifications are required to the appc spec in order to allow the native execution of compliant images within Docker.
The CoreOS initiated pull-request to the Docker project was opened by Jonathan Boulle, a senior software engineer at CoreOS. The pull-request has attracted several comments from both Docker and Rocket supporters, including Solomon Hykes, the founder and CTO of Docker. Hykes primarily questioned the benefits to users of adding appc ACIsupport to Docker:
[…] it makes no sense for the user to have to deal with 2 incompatible universes of images with the same tool. It creates artificial constraints and solves zero problems. These 2 formats are almost completely identical, and the differences will only diminish as we progress on our respective roadmaps.
Several comments on the open pull-request voiced support for the concepts demonstrated in the proposed implementation. Blake La Pierre stated that using a single tool to manage multiple container image formats could be beneficial for users:
If one format has advantages over another, it would be nice to be able to use that new format without having to use yet another application, rewrite scripts, test scripts, etc. It seems there could be an advantage to being able to run multiple formats. As a user, pretty much the last thing I want to be dealing with is trying to figure out how start a program.
Another Github user, ‘ncoghlan’, compared current container runtime implementations with existing Linux package management systems, and suggested that a container runtime should not be required to support all image formats:
This PR is like giving yum the ability to install deb packages or apt-get the ability to install RPMs, rather than working on making it easier for software publishers to easily provide both formats, so we as end users can choose the ecosystem we prefer without needing to worry about the competition as part of the day-to-day operation of our systems.
Sebastiann van Stijn suggested that the portability of container images could be enabled via tools that allow format conversion, which is the approach CoreOS has currently taken to enable Docker support within Rocket:
If App Container/CoreOS wants to bring support for ACI to Docker, implementing a counterpart to docker2aci (as suggested by @jcfr) is a good alternative that would directly benefit users that have a need to run ACI images on Docker.
Github user ‘ncoghlan’ also suggested that if users require container image format interoperability then this may be easier to implement within a higher level container orchestration system, such as Kubernetes.
Kubernetes currently has an open issue to ‘introduce container runtime abstraction’ and add support for runtime implementations, such as Rocket. The Apache Mesos cluster manager also has an open ticket in the project’s Jira issue tracker entitled ‘Consider a C++ implementation of CoreOS AppContainer spec’.
Several comments on the Docker pull-request, including those by Vidar Hokstad, suggested that even if the code contained within the pull-request is not suitable for integration with the current Docker application, there may be elements that could be used to begin discussion towards a shared approach for the ACI and Docker image formats:
even if this PR is not suitable, together with the associated proposal it provides workable example code of how to achieving this. I would hope that that at least gets a serious look. For starters, there are elements there that ought to be fairly simple and possible to to agree on a shared approach with ACI/Rocket, such as a content signature.
CoreOS Rocket v0.3.2. can be obtained from the Rocket Github repository, and installation and execution instructions for Rocket can be found in the associated README.md. The appc specification can be found in the CoreOS Github repository. Docker are also currently working on a Docker Image Specification v1.0.0., which can be found in the project’s Github repository
The pull-request to Docker that was opened by the CoreOS team can be found in the project's Github repository. CoreOS is encouraging developers to contribute, and there is a ‘help wanted’ label on the Github project issue list for both Rocket and the appc spec.
