Getting to Docker 1.0 | Docker Blog

Last week, someone posted a tweet about Docker that was both one of the funniest– and one of the scariest– we’d seen.

Ready 2 deploy @docker. Can’t wait to ignore “not production ready” warnings.

Docker is less than 6 months old, and is currently at version 0.5.1. We – and the Docker community – are still rapidly iterating. So, we make a point of saying that we’re not production ready. However, with companies like eBay, Cloudflare, and Mailgun talking about plans to use us in production, and with major projects like Deis, Flynn, and CoreOS building on top of us, getting to a “production ready” state has assumed paramount importance.

Our current goal is to release a production ready version of Docker in October.

For us, being production ready involves four main components:

Producing a complete set of user tools and documents Reducing Docker to a stable core and providing a stable API around the stable core Extending the tested and approved environments for Docker Institutionalizing Stability and Quality

1. Complete set of tools and documents

Last month, we made a major push to provide a complete set of user tools, including accurate documentation, a well-organized website, and a good set of “getting started” materials. The new site went live on July 13. Hopefully, you’ve had a chance to view and comment on the documents. Of course, producing great documentation is a never ending task, and we appreciate all feedback and suggestions.

2. Stable Core and Stable API

We are making some significant architectural changes to Docker in preparation for reaching production readiness. These changes will be invisible to the majority of Docker users; syntax won’t change, Dockerized apps will continue to work, and functionality will be preserved.  However, developing and testing on Docker will change significantly—and for the better.  Our intention is to make Docker a much more useful platform going forward for our community of developers. The changes will involve

• Shrinking the core of Docker
• Designing a stable API around the core
• Taking much of the current (and future) functionality of Docker and deploying it as plug-ins via the stable API.

These changes should have the benefit of simultaneously making Docker more stable and making it easier to extend functionality. Once we’ve made these changes, the core of Docker will change much less frequently, and will be easier to test against different platforms. By the same token, it will become significantly easier to build plug-ins to extend functionality (e.g. adding orchestration and security). Similarly, it should make it easier for us to extend Docker to support other container formats (e.g. BSD Jails, Solaris Zones, OpenVZ ) and other features like Software-Defined Networking, or hardened security through SELinux.

3. Tested and Approved Configurations

Our goal is for Docker to enable developers to build once and (finally) run anywhere. Today, we have a big asterisk next to “anywhere”. While we don’t have specific requirements around the distribution of Linux, we do require that you run a fairly recent Linux Kernel (3.8 or later) and have AUFS installed. Since Ubuntu 12.04 and later meets those requirements, today we generally recommend and test on Ubuntu.

However, we recognize the need for a much broader set of compatibility. As a stop gap, since Mac, Windows and some Linux distributions cannot natively run Docker, we have provided virtual machines for various environments, as well as instructions for running in popular public clouds such as Rackspace and AWS. We are also hard at work expanding and testing Docker on the most popular Linux distributions (including Red Hat Enterprise Linux, CentOS, Fedora, and SUSE), which involves both expanding our set of supported kernels and supporting union file systems in addition to AUFS (e.g. BTRFS)

4. Institutionalizing Stability and Quality

Beyond the specifics of our current drive to 1.0, we are working hard to institutionalize best practices around producing quality code, including: setting aggressive goals on test coverage, using test-driven development methodologies, setting high standards around outstanding bugs, implementing CI tools like buildbot, and — of course — making sure that we use Docker ourselves extensively throughout the organization. Fortunately, both the nature of Docker itself and the large and active community make it easy to expose and correct potential issues. We’ll delve into this topic further in a future post.

Schedule

With these changes, we are trying to achieve four somewhat contradictory goals. We want to make Docker production ready. We want to release the production ready version by the end of October. We want to make some significant architectural changes. And, we want to continue to support the momentum on the existing Docker line. (In any given week, we have about 20 pull requests from a community of over 100 developers). This schedule is an attempt to reconcile those goals

We appreciate the support and patience of our community as we go through this transition. As always, any and all feedback is welcome.