Today we’re pleased to announce the availability of Docker Engine 1.3. With over 750 commits from 45 contributors, this release includes new capabilities as well as lots of quality enhancements. You can get more details in the release notes, but we’ll highlight four of the new features here.
Tech Preview: Digital Signature Verification
First up, in this release, the Docker Engine will now automatically verify the provenance and integrity of all Official Repos using digital signatures. Official Repos are Docker images curated and optimized by the Docker community to be the best building blocks for assembling distributed applications. A valid signature provides an added level of trust by indicating that the Official Repo image has not been tampered with.
With Official Repos representing one out of every five downloads from the Docker Hub Registry, this cryptographic verification will provide users with an additional assurance of security. Furthermore, it represents the first of several features we’ll be shipping in the coming months for both publishers and consumers of repos, features that will support publisher authentication, image integrity and authorization, PKI management, and more. Watch this space.
Note that this feature is still work in progress: for now, if an official image is corrupted or tampered with, Docker will issue a warning but will not prevent it from running. And non-official images are not verified either. This will change in future versions as we harden the code and iron out the inevitable usability quirks. Until then, please don’t rely on this feature for serious security, just yet.
Inject new processes with docker exec
Next, when developing an application, you sometimes need to look at it while it’s running. A number of tools, like nsinit and nsenter, have sprung up to help developers debug their Dockerized apps, but these are additional tools to find, learn, and manage. Similarly, some users have taken to running an init process to spawn sshd along with their app to allow them access, which creates risk and overhead.
To make debugging easier, we’re introducing docker exec, which allows a user to spawn a process inside their Docker container via the Docker API and CLI. For example…
$ docker exec ubuntu_bash -it bash
…will create a new Bash session inside the container ubuntu_bash.
To be clear, by providing this we’re not changing our recommended approach of “one app per container.” Instead, we’re responding to users who’ve told us they sometimes need helper processes around the app. That’s what `docker exec` is about.
Tune container lifecycles with docker create
The docker run <image name> command creates a container and spawns a process to run it. Many users have asked to break this apart for finer-grained management of their container lifecycles. The docker create command makes this possible. So for example…
$ docker create -t -i fedora bash 6d8af538ec541dd581ebc2a24153a28329acb5268abe5ef868c1f1a261221752
…creates a writable container layer (and prints the container’s ID to STDOUT), but doesn’t run it. You could then do the following…
$ docker start -a -i 6d8af538ec5 bash-4.2#
…to run the container. That is, docker create gives the user and/or process supervisors the flexibility to use the docker start and docker stop CLI commands to manage the container’s lifecycle.
Security Options
With this release we’ve added a new flag to the CLI, --security-opt, that allows users to set custom SELinux and AppArmor labels and profiles. For example, suppose you had a policy that allowed a container process to listen only on Apache ports. Assuming you had defined this policy in svirt_apache, you could apply it to the container as follows:
$ docker run --security-opt label:type:svirt_apache -i -t centos \ bash
One of benefits of this feature is that users will be able to run docker-in-docker without having to use docker run --privileged on those kernels supporting SELinux or AppArmor. Not giving the running container all the host access and rights as --privileged significantly reduces the surface area of potential threats.
boot2docker: Shared directories on Mac OS X
Using Docker on Mac OS X has become much easier since we incorporated boot2docker, but the experience has had some usability quirks. With this release we are addressing the most common issue: sharing directories between your Mac and your containers. Using Docker 1.3 with the corresponding version of boot2docker, host-mounted volumes now work the way you expect them to.
For example, this command:
$ docker run -v /Users/bob/myapp/src:/src [...]
Will mount the directory /Users/bob/myapp/src from your Mac into the container. This makes it much easier to use Docker for a continuous development flow, where you benefit from a predictable containerized development environment, but don’t want to rebuild a new container every time you change a line in your source code. If you are using Fig for your development workflow, for example, the benefits are immediately obvious.
Note that there are still some limitations: for example this feature is limited to boot2docker’s virtualbox configuration, cannot be managed dynamically, and only works for directories in /Users . But we are receiving exciting contributions to improve volume management, so expect this area to improve drastically in the next few releases.
—
We hope that gives you a glimpse into Docker Engine 1.3. For more details, please check-out the GitHub 1.3 milestone issues and pull requests. We look forward to your feedback!
Happy hacking,
– The Docker Team
Learn More
- Download boot2docker for Mac or Windows
- New to Docker? Try our 10 min online tutorial
- Share images, automate builds, and more with a free Docker Hub account
- Read the Docker Engine 1.3 Release Notes
- GitHub 1.3 milestone issues and pull requests
“Identity Penguin” cartoon by Laurel.