Author Archives: Docker Core Engineering
Author Archives: Docker Core Engineering
Today we released Docker CE 17.06 with new features, improvements, and bug fixes. Docker CE 17.06 is the first Docker version built entirely on the Moby Project, which we announced in April at DockerCon. You can see the complete list of changes in the changelog, but let’s take a look at some of the new features.
We also created a video version of this post here:
The biggest feature in 17.06 CE is that multi-stage builds, announced in April at DockerCon, have come to the stable release. Multi-stage builds allow you to build cleaner, smaller Docker images using a single Dockerfile.
Multi-stage builds work by building intermediate images that produce an output. That way you can compile code in an intermediate image and use only the output in the final image. So for instance, Java developers commonly use Apache Maven to compile their apps, but Maven isn’t required to run their app. Multi-stage builds can result in a substantial image size savings:
REPOSITORY TAG IMAGE ID CREATED SIZE maven Continue reading
Today we’re releasing Docker 1.13 with lots of new features, improvements and fixes to help Docker users with New Year’s resolutions to build more and better container apps. Docker 1.13 builds on and improves Docker swarm mode introduced in Docker 1.12 and has lots of other fixes. Read on for Docker 1.13 highlights.
Docker 1.13 adds Compose-file support to the `docker stack deploy` command so that services can be deployed using a `docker-compose.yml` file directly. Powering this is a major effort to extend the swarm service API to make it more flexible and useful.
Deploying a multi-host, multi-service stack is now as simple as:
docker stack deploy --compose-file=docker-compose.yml my_stack
Ever been bitten by the dreaded
Error response from daemon: client is newer than server problem because your Docker CLI was updated, but you still need to use it with older Docker engines?
Docker’s mission is to build tools of mass innovation, starting with a programmable layer for the Internet that enables developers and IT operations teams to build and run distributed applications. As part of this mission, we have always endeavored to contribute software plumbing toolkits back to the community, following the UNIX philosophy of building small loosely coupled tools that are created to simply do one thing well. As Docker adoption has grown from 0 to 6 billion pulls, we have worked to address the needs of a growing and diverse set of distributed systems users. This work has led to the creation of many infrastructure plumbing components that have been contributed back to the community.
It started in 2014 with libcontainer and libnetwork. In 2015 we created runC and co-founded OCI with an industry-wide set of partners to provide a standard for container runtimes, a reference implementation based on libcontainer, and notary, which provides the basis for Docker Content Trust. From there we added containerd, a daemon to control runC, built for performance and density. Docker Engine was refactored so that Docker 1.11 is built on top of containerd and runC, providing benefits Continue reading
We wanted to thank everyone in the community for helping us achieve this great milestone of making Docker 1.12 generally available for production environments. Docker 1.12 adds the largest and most sophisticated set of features into a single release since the beginning of the Docker project. Dozens of engineers, both Docker employees and external contributors, have made substantial contributions to every aspect of 1.12 orchestration including core algorithms, integration into the Docker Engine, documentation and testing.
We’re very grateful to the community, which has helped us with feedback, bug reports and new ideas. We couldn’t have done it without the help in particular of the tens of thousands of Docker for Mac and Windows beta users who have been testing our 1.12 features since DockerCon in June. We’ve seen contributions ranging from bash tab completion to UX up-and-down votes that helped us understand what users want most. Compared to what we unveiled at DockerCon, we’ve ended up with significant improvements in the swarm node join workflow (it’s simpler), error reporting (easier to view), UX improvements (more logical), networking (fixed reliability issues) etc.
The core team also wanted to give a Continue reading
Three years ago, Docker made an esoteric Linux kernel technology called containerization simple and accessible to everyone. Today, we are doing the same for container orchestration.
Container orchestration is what is needed to transition from deploying containers individually on a single host, to deploying complex multi-container apps on many machines. It requires a distributed platform, independent from infrastructure, that stays online through the entire lifetime of your application, surviving hardware failure and software updates. Orchestration is at the same stage today as containerization was 3 years ago. There are two options: either you need an army of technology experts to cobble together a complex ad hoc system, or you have to rely on a company with a lot of experts to take care of everything for you as long as you buy all hardware, services, support, software from them. There is a word for that, it’s called lock-in.
Docker users have been sharing with us that neither option is acceptable. Instead, you need a platform that makes orchestration usable by everyone, without locking you in. Container orchestration would be easier to implement, more portable, secure, resilient, and faster if it was built into the platform.
Starting with Docker 1.12, Continue reading