Getting to Docker 1.0

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:

  1. Producing a complete set of user tools and documents
  2. Reducing Docker to a stable core and providing a stable API around the stable core
  3. Extending the tested and approved environments for Docker
  4. 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.

docker_1.0

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

  • August 8:  Introduce this new architectural approach to the community
  • August 15:  Provide a developer preview
  • Mid-August: Release Docker 0.6, the last significant release under the current Docker architecture
  • Late August:  Public preview release of Docker 0.8 — with the new architecture
  • Early September: All functionality in Docker 0.6 is available in the Docker 0.8 branch
  • Mid September: Address any pull requests received since 0.6 release
  • Mid-late September: Docker 0.8 release candidate one
  • October: Docker 0.8, production ready release with the new architecture, certified on 3.8 kernels
  • Late October/Early November; Docker 0.8 certified on RHEL, CentOS

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

15 Responses to “Getting to Docker 1.0”

  1. jason

    “Since Ubuntu 12.04 and later meets those requirements, today we generally recommend and test on Ubuntu.”

    It looks to me like the required kernel (3.8) doesn’t show up in Ubuntu releases until 13.04.

    Reply
    • Jerome Petazzoni

      Hi Jason,

      Ubuntu 12.04 actually does have 3.8; it’s a pretty recent update but it’s there.
      At least on our 12.04 instances on Amazon, after an “apt-get update” we see the package “linux-image-3.8.0-27-generic” which is golden for Docker.

      HTH :)

      Reply
      • Michael Chang

        Rather than installing the linux-image-3.8.0-xx-generic package directly, users should be directed to install the linux-lts-raring metapackage on Ubuntu 12.04 LTS to make sure they get updated 3.8 series kernels.

        Reply
        • Quinten Krijger

          Yup.
          I have tested 12.04 linux-lts-raring and that works like a charm.

          Reply
    • Mike Zupan

      Yes 3.8 is on 12.04

      linux-image-3.8.0-27-generic – Linux kernel image for version 3.8.0 on 64 bit x86 SMP

      Reply
  2. Forbin

    Great stuff! Does “extending the tested and approved environments for Docker” include support for 32bit environments? That’s currently the biggest blocker for our group being able to use Docker.

    Reply
  3. kdobson

    Might have been my tweet (25th July), so I’ll follow up and say I haven’t deployed it to production (yet!). I *thought* there was a performance degradation from using it, but subsequently turned out to be odd latency between Rackspace Cloud instances and Amazon’s RDS.

    So at the moment we’re using a boring old VPS, but as we scale I’d hope to roll out load-balanced docker containers : )

    Reply
  4. Rsync Net

    Hello,

    I am wondering about the connection, or lack thereof, between the hashed signifiers that you see when you list your containers with ‘docker ps -a’ and the hashed signifiers that I see inside the /var/lib/docker/containers … AFAICT, they don’t match up or link up in any way … I cannot look at an entry from ‘ps -a’ and connect it to a directory (or directories) inside of /var/lib/docker/containers. Am I missing something ?

    I’d like there to be some coherency there – like some ability to glance into the raw directories, without being helped by docker command output, and know what dir was what and who belonged to whom…

    Reply
    • Nick

      They match up perfectly, they’re just truncated for clarity.

      Try `docker ps -notrunc`

      Reply
      • Rsync Net

        I see. Thank you for mentioning the –notrunc option as that makes the relationship clear.

        What about the image ID that I see in the ‘docker images’ output – that appears to be unrelated, yes ?

        I know this seems picky, but I think it would be nice if the directories inside of /var/lib/docker/containers were not *just* hashes, but had either the image ID or the name of the image prepended to the directory name… Right now, if I want to destroy all of the directories related to a particular image, I need to do a ps –notrunc, and then correlate the output of that to the image I am targeting, and then cross reference that to the directory hashes … all of which is largely impossible if I am dealing with an archive sitting on some other system, possibly not even a linux system.

        OTOH, I feel like there could be a simple and elegant way to append slightly more information to the dir names, in addition to just the hash, that lets you see both parent/child relationship (what sequence the directories go in) and what dirs belong to what image, etc.

        Again, think of manipulating these images on a non-linux system where docker is not available at all – you don’t have ps output to correlate and you can’t see the ‘images’ list …

        Reply
        • Quinten Krijger

          /var/lib is not really an interface of docker. Are you requesting as a user, or as a docker developer?

          Deletion functionality is in the API. docker rm and docker rmi. So as a user, you don’t have to know about the existence of /var/lib at all!

          think of manipulating these images on a non-linux system where docker is not available at all
          The article clearly states that docker indeed is supported only on linux with a 3.8+ kernel… ?

          Reply
  5. Erik

    Seems like #2 and #4 are the only ones actually required for it to be production-ready. #1 and #3 are nice-to-haves.

    Reply
  6. Linux Mint Czech - Prípravy stabilnej verzie Docker 1.0 at Linux-Mint-Czech

    [...] stabilnej verzie Docker 1.0 sú v plnom prúde, príde asi v októbri 2013. Domovská stránka zaujímavého open-source [...]

    Reply
  7. Thijs

    Great work and thanks for the clarity on the roadmap. I really look forward to the RHEL/CentOS support! All the other points mentioned also make total sense (small core, pluggable components etc).

    Reply

Leave a Reply