Docker 0.5.0: external volumes, advanced networking, self hosted registry
Dear Dockers,
Today we are happy to introduce a new release of Docker. In addition to numerous stability and usability fixes, this release adds support for external volumes, advanced networking options, a vastly improved self-hosted registry, and dozens of other improvements.
- What is Docker?
- 0.5.0 summary
- External volumes
- Advanced networking
- Self-hosted registry
- What's next?
- Broader kernel support
- Cross architecture support
- Even more integrations
- Plugin API
- Better documentation
- Production-ready
- How you can help
- Hack day on July 30
Docker is a open-source application container engine. It gives developers a way to package their app and all its dependencies into a portable container which can be deployed on any modern Linux machine, virtualized or not. Containers are completely sandboxed and do not interfere with each other (think "iPhone apps for the server"), have virtually no performance overhead, and can easily be moved across machines and datacenters. Best of all, they don't depend on any language, framework or packaging system.
In 0.3 we introduced data volumes, a great mechanism for manipulating persistent data such as database files, log files, etc.
In addition to sharing volumes between containers, you can now share volumes between a container and the underlying host. This makes certain scenarios much easier, such as using a high-performance storage backend for your production database, making live development changes available to a container, etc.
To mount an external volume into a container, simply prepend the volume name with a source location:
docker run -v /mnt/data_on_host:/var/lib/couchdb shykes/couchdb
You can also initialize volumes in your container at build time, by using the VOLUME instruction in a Dockerfile.
When redirecting a port to a container, you can now specify which public port to redirect. If you don't specify a public port, Docker will revert to allocating a random public port.
For example:
-
-p 80:5000redirects public port 80 to private port 5000 -
-p 80redirects a random public port to private port 80
With 0.5 you can now specify the public port using:
-
-p 5000:80to bind the port 80 of the container to the port 5000 on the host -
-p 800:2000/udpto bind the port 2000 of the container to the port 800 on the host using udp
You can now redirect both UDP ports and TCP ports to your container. To specify a UDP port, simply add the suffix '/udp' to your port specification. For example:
-
-p 2000/udpredirects a random public UDP port to private UDP port 8000 -
-p 80:80/tcpredirects public port 80/TCP to private port 80/TCP -
-p 80:80also redirects public port 80/TCP to private port 80/TCP
This release includes major improvements to the self-hosted registry. It is now much easier to store and distribute docker images privately within your organization. You can also combine multiple registries to reflect your organization: for example, you might store your open-source images on the public registry, company-wide base images on a company-wide registry, application nightly builds in a team-specific registry, and so on.
Self-hosted registries are completely independent of the public registry: images stored on it are completely private and not publicly searchable or accessible in any way. You can control access to your registry using standard HTTP proxying and authentication.
To find out which registry an image comes from, simply look at its name: the URL of the registry is used as a prefix. For example, images.myorganization.com/ubuntu refers to an image in the images.myorganization.com registry. Image names with no URL, like ubuntu or shykes/couchdb always refer to the public registry.
To pull an image from a registry, simply include the registry url in the image name:
docker pull myregistry.mydomain.com/myapp
Conversely, to push an image to a registry, you must first tag it with the appropriate name:
# Tag to create a repository with the full registry location.
# The location (e.g. myregistry.mydomain.com) becomes
# a permanent part of the repository name
docker tag 0u812deadbeef myregistry.mydomain.com/myapp
# Push the new repository to its home location
docker push myregistry.mydomain.com/myapp
And that's it! No other configuration necessary.
We want Docker to run everywhere, and to integrate with every devops tool. Those are ambitious goals, and the only way to reach them is with the Docker community. For the community to participate fully, we need an API which allows Docker to be deeply and easily customized.
We are working on a plugin API which will make Docker very, very customization-friendly. We believe it will facilitate the integrations listed above - and many more we didn't even think about.
Let us know if you want to start playing with the API before it's generally available. And if you're in the San Francisco area, make sure to drop by our next hack day for a sneak preview!
Our goal is to make Docker run everywhere, but currently Docker requires Linux version 3.8 or higher with lxc and aufs support. If you're deploying new machines for the purpose of running Docker, this is a fairly easy requirement to meet. However, if you're adding Docker to an existing deployment, you may not have the flexibility to update and patch the kernel.
Expanding Docker's kernel support is a priority. This includes running on older kernel versions, but also on kernels with no AUFS support, or with incomplete lxc capabilities.
Our goal is to make Docker run everywhere. However currently Docker only runs on x86_64 systems. We plan on expanding architecture support, so that Docker containers can be created and used on more architectures.
We want Docker to be the secret ingredient that makes your existing tools more awesome. Thanks to this philosophy, Docker has already been integrated with Puppet, Chef, Openstack Nova, Jenkins, DotCloud sandbox, Pallet, Strider CI and even Heroku buildpacks.
Expect Docker to integrate with even more of your favorite tools going forward, including:
- Alternative storage backends such as ZFS, LVM or BTRFS
- Alternative containerization backends such as OpenVZ, Solaris Zones, BSD Jails and even plain Chroot.
- Process managers like Supervisord, Runit, Gaffer and Systemd
- Build and integration tools like Make, Maven, Scons, Jenkins, Buildbot and Cruise Control.
- Configuration management tools like Puppet, Chef and Salt
- Personal development environments like Vagrant, Boxen, Koding and Cloud9.
- Orchestration tools like Zookeeper, Mesos and Galaxy
- Infrastructure deployment tools like Openstack, Apache Cloudstack, Ganeti
We believe that great documentation is worth 10 features. We are often told that "Docker's documentation is great for a 2-month old project". Our goal is to make it great, period.
If you have feedback on how to improve our documentation, please get in touch by replying to this email, or by filing an issue. We always appreciate it!
Docker is still beta software, and not suited for production. We are working hard to get there, and we are confident that it will be possible within a few months. Stay tuned for a more detailed roadmap soon.
-
Contribute! Docker is growing faster than we can keep up! We are looking for volunteers to help improve the various components of the project - everything from documentation, packaging, project infrastructure to plugins and core components. Check out the contribution guidelines as a start.
-
Make screencasts and articles. If you do anything cool and useful with docker, record a screencast and tell us about it! This could be dockerizing an application, installing it in a specific environment, cool usage tricks, etc. We recommend ascii.io, it's insanely easy to use.
-
Dockerize your favorite tools. Docker plays well with other tools in the devops toolbox. Got a tool you want to integrate with Docker? Create a github issue and we'll help you out.
-
Join the conversation. There are insane volumes of interesting conversations going on on irc (#docker@freenode), twitter (#docker) and the google group. Whether you have a beginner question or want to discuss a point of design, never hesitate to speak up!
-
And of course all the usual ways of spreading the word - tweets, github follows, etc. etc. are always welcome.
The next Docker hack day is on Tuesday, July 30 at the dotCloud HQ in San Francisco. RSVP now at http://www.meetup.com/Docker-meetups/events/127801022/
Happy hacking! The Docker team