Read on to check out the highlights from this release.

Improved local image analysis

Container image security presents challenges such as dependency awareness, vulnerability awareness, and practical remediation in day-to-day reality. Since Docker Desktop 4.14, we’ve consistently added features to help you understand your images and their vulnerabilities. Improvements in 4.17 were designed with developers in mind to address software supply chain security. 

We’re pleased to announce Early Access to the new Docker Scout service. Docker Scout provides visibility into vulnerabilities and recommendations for quick remediation. Now you can use Docker Scout to analyze and remediate vulnerabilities on local images in Docker Desktop and the Docker CLI. 

Check out the Docker Scout documentation to learn more about how to get started.

What can you do with Docker Scout?

• Image analysis results: Filter images based on vulnerability information, look for specific vulnerabilities, or confirm when vulnerabilities have been remediated. You’ll see results based on the layer in which a vulnerability is introduced, so you know exactly where the alert is coming from.

• Remediation advice: Get guidance on available remediation options. Docker Scout shows you the recommended remediation path depending on the layer of the vulnerability. Docker Scout also shows a preview before you resolve anything, so you know how many vulnerabilities will be resolved by a specific update.

• Remote registries: You can use Docker Desktop to view and pull images from Artifactory repositories to analyze them.

• Command-line interface: As of Docker Desktop 4.17, the docker scan command is deprecated and replaced with a command for Docker Scout – docker scout. Read the release notes for more detail. 

Update to Docker Desktop 4.17 to access these new features and take them for a test run. You can also provide feedback directly in Docker Desktop by navigating to the images tab and selecting Give feedback. We look forward to hearing from you!  

A new way to publish Docker Extensions

We are excited to introduce a new way to publish a Docker Extension. When submitting an extension to the Marketplace, you now have two publishing options:

• Docker Reviewed
• Self-Published – New!

Self-Published extensions are automatically validated. If all validation checks pass, it is published on the Extensions Marketplace and accessible to all users within a few hours. Self-Published is the fastest way to get developers the tools they need and to get feedback from them as you work to evolve and polish your extension. 

Developers can identify self-published extensions in the Extensions Marketplace by the not reviewed label. Extensions that are manually reviewed by the Docker Extensions team have a reviewed label, as shown in the following screenshot. 

We are excited about the increased reach and accessibility the new self-publishing workflow brings to both Docker Extension publishers and users. 

If you have an idea for an extension that isn’t already in the Extensions Marketplace, you can submit it to our ideas discussion board. 

Let us know what you think

Thanks for using Docker Desktop! Learn more about what’s in store with our public roadmap on GitHub, and let us know what other features you’d like to see.

Check out the release notes for a full breakdown of what’s new in Docker Desktop 4.17.

Docker Desktop 4.16 is our first release of the new year and we’re excited to kick off 2023 with a bang. In this release, Docker Extensions moved from beta to GA. The Docker Extensions feature connects the Docker toolchain to your application development and deployment workflows. To make using Docker Extensions easier, we added the ability to search, install, and uninstall extensions right from the search bar. Also, we’re excited to announce that we’ve improved the performance of our image analysis — it’s 4x faster and requires 76% less memory (YAY!).

Let’s check out some highlights from Docker Desktop 4.16.

Docker Extensions now GA

In May 2022, Docker introduced Docker Extensions as a way to connect the Docker toolchain to application development and deployment workflows. And with Docker Desktop 4.16, Docker Extensions and the Docker Extensions SDK are now generally available on all platforms.

The Docker Extensions feature allows you to augment Docker Desktop with debugging, testing, security, networking, and many more functionalities. You can even build custom add-ons using the Extensions SDK.

Since its launch, the Extensions Marketplace has expanded from 15 initial extensions to over 30 — with more on the way. 

To help you get the most out of extensions, we’ve also:

• Improved discoverability with search, categories, listing the number of installs, and more.
• Added the Extensions Marketplace on Docker Hub so you can search extensions and images.
• Created a Build section in Docker Desktop to make it simpler for you to create your own.
• Made sharing new extensions easier with a Share button so you can share your extension with URL.
• And more!

Over the coming months, you can expect new functionality for Docker Extensions and the Docker Extensions SDK.

Performance improvements to image analysis

Now you can analyze an image for vulnerabilities up to 4x faster — and use up to 76% less memory while you do it. Rolling out as part of Docker Desktop 4.16, these performance improvements can make a big difference when you’re dealing with larger (5GB+) images.

To perform an analysis, select any image in the Images tab. You’ll automatically kick off an analysis so you can learn about vulnerabilities in your base images and dependencies.

Thanks to everyone who reached out and worked with us to make these performance improvements. Please keep the feedback coming!

Quick search now GA

In Docker Desktop 4.15, we launched an experimental quick search that brings the Hub experience into your local workflow so you can find, pull, and run any public or private remote images on Hub. We had a great response from the community, and quick search is now GA.

Launch Docker Desktop 4.16, and you’ll find lots of great features to jump right into your work without leaving Docker Desktop.

Search for local containers or compose apps

Now you can quickly find containers or compose apps on your local system. And once you find them, you can perform quick actions right from the search, including start, stop, delete, view logs, or start an interactive terminal session with a running container. You can even get a quick overview of the environment variables. 

Search for public Docker Hub images, local images, and images from remote repositories

Search through all images at your disposal, including Docker Hub and remote repositories, then filter by type to quickly narrow down the results. Depending on the category, you’ll have a variety of different quick actions to choose from:

• Docker Hub public images: Pull the image by tag, run it (which also pulls the image as the first step), view documentation, or go to Docker Hub for more details. 
• Local images: Run a new container using the image and get an overview of which containers use it.
• Remote images: Pull by tag or get quick info, like the last updated date, size, or vulnerabilities. 

Find new extensions easier with quick search

Now when you search in Docker Desktop, Docker Extensions will be included in the search results. From here, you can learn more about the extension and install it with a single click.

Check out the tips in the footer of the search module for more shortcuts and ways to use it. As always, we’d appreciate your feedback on the experience and suggestions for improvement.

Let us know what you think

Thanks for using Docker Desktop! Learn more about what’s in store with our public roadmap on GitHub, and let us know what other features you’d like to see.

Check out the release notes for a full breakdown of what’s new in Docker Desktop 4.16.

Over the last year, Docker has helped advance the work of the OCI to make it more readily available to more users. It started in December 2015, when we introduced containerd ™, a daemon to control runC. This was part of our effort to break out Docker into small reusable components. With this release, Docker Engine is now built on containerd, so everyone who is using Docker is now using OCI. We’re proud of the progress we’ve made on the OCI with the 40+ members to continue the work to standardize container technology.

Besides this mind-blowing piece of technological trivia that I’m sure will impress your friends at parties, what difference does it make to you? Well, short answer is: nothing… yet! Nevertheless, let me convince you that this is still something you should be excited about.

This is among the biggest technical refactorings the Engine has gone through, and our priority for 1.11 was to get the integration right, without changing the command-line interface or API. However, this lays the technical groundwork for significant user-facing improvements.

Stability and performance

With the containerd integration comes an impressive cleanup of the Docker codebase and a number of historical bugs being fixed. In general, splitting Docker up into focused independent tools mean more focused maintainers, and ultimately better quality software.

Performance-wise, we were extremely careful in making sure 1.11 would not be any slower despite the extra inter-processes communications. We’re pleased to say that it is faster at creating containers concurrently than its predecessor, and although we made a deliberate choice of favoring correctness first, you can expect more performance improvements in the future.

Creating an ecosystem for container execution backends

runC is the first implementation of the Open Containers Runtime specification and the default executor bundled with Docker Engine. Thanks to the open specification, future versions of Engine will allow you to specify different executors, thus enabling the ecosystem of alternative execution backends without any changes to Docker itself. By separating out this piece, an ecosystem partner can build their own compliant executor to the specification, and make it available to the user community at any time – without being dependent on the Engine release schedule or wait to be reviewed and merged into the codebase.

What does this mean for you? This gives you choice: the runtime is now pluggable. Following  the Docker principle of batteries included but swappable, Docker Engine will ship with runC available as the default with the ability to choose from a variety of container executors that are for specific platforms or have different security and performance features. By separating out the thing that runs containers from the Engine, this opens up new possibilities. As an example, 1.11 is a huge step toward allowing Engine restarts/upgrades without restarting the containers, improving the availability of containers. This is probably one of the most requested features by Docker users. In fact, with this new architecture, you will even be able to restart containerd and your containers will keep running.

But wait, there’s more!

In addition to this huge architectural change, as usual we have also added a bunch of features in Engine, Compose, Swarm, Machine, and Registry.

Engine 1.11

• DNS round robin load balancing: It’s now possible to load balance between containers with Docker’s networking. If you give multiple containers the same alias, Docker’s service discovery will return the addresses of all of the containers for round-robin DNS.
• VLAN support (experimental): VLAN support has been added for Docker networks in the experimental channel, so you can integrate better with existing networking infrastructure.
• IPv6 service discovery: Engine’s DNS-based service discovery system can now return AAAA records.
• Yubikey hardware image signing: A few months ago we added the ability to sign images with hardware Yubikeys in the experimental channel of Docker. This is now available in the stable release. Read more about how it works in this blog post.
• Labels on networks and volumes: You can now attach arbitrary key/value data to networks and volumes, in the same way you could with containers and images.
• Better handling of low disk space with device mapper storage: The dm.min_free_space option has been added to make device mapper fail more gracefully when running out of disk space.
• Consistent status field in docker inspect: This is a little thing, but really handy if you use the Docker API. docker inspect now has a Status field, a single consistent value to define a container’s state (running, stopped, restarting, etc). Read more in the pull request.

See the release notes for full details.

Compose 1.7

• --build option for docker-compose up: This is a shorthand for the common pattern of running docker-compose build and then docker-compose up. Compose doesn’t build on every run by default in case your build is slow, but if you’ve got a quick build, running this every time will ensure your environment is always up to date.
• docker-compose exec command: Mirroring the docker exec command.

See the release notes for full details.

Swarm 1.2

• Container rescheduling no longer experimental: In the previous version of Swarm, we added support for rescheduling containers when a node dies. This is now considered stable so you can safely use it in production.

• Better errors when containers can’t be scheduled: For example, when a constraint fails, the constraints will be printed out so you can easily see what went wrong.

See the release notes for full details.

Machine 0.7

In this version of Machine, the Microsoft Azure driver now uses the new Azure APIs and is easier to authenticate. See Azure’s blog post for more details. There are also a bunch of other improvements in this release – take a look at the full release notes for details.

Registry 2.4

• Garbage collection: A tool has been added so system administrators can clean up the data from images that have been deleted by users. For more details, see the garbage collector docs.
• Faster and more stable S3 driver: The S3 storage driver is now implemented on top of the official Amazon S3 SDK, which has major performance and stability goodness.

See the release notes for full details.

Download and try out Docker 1.11

The easiest way to try out all of this stuff in development is to download Docker Toolbox. For other platforms, check out the installation instructions.

All of this stuff is also available in Docker for Mac and Windows, the new way to use Docker in development, currently in private beta. Sign up to get a chance to try it out early.

Announcing #Docker 1.11: First runtime built on #containerd and based on OCI technology
Click To Tweet

Learn More about Docker

• New to Docker? Try our 10 min online tutorial
• Share images, automate builds, and more with a free Docker Hub account
• Read the Docker 1.11 Release Notes
• Subscribe to Docker Weekly
• Sign up for upcoming Docker Online Meetups
• Attend upcoming Docker Meetups
• Watch DockerCon EU 2015 videos
• Start contributing to Docker

So we started the containerd project to move the container supervision out of the core Docker Engine and into a separate daemon. containerd has full support for starting OCI bundles and managing their lifecycle. This allows users to replace the runc binary on their system with an alternate runtime and get the benefits of still using Docker’s API.

So why another project? Why are you all busy refactoring things instead of fixing real issues? Well…

containerd improves on parallel container start times so if you need to launch multiple containers as fast as possible you should see improvements with this release. On my laptop, I can launch 100 containers in 1.64 seconds. That is 60 containers per second. When starting a container most of the time is spent within syscalls and system level operations. It does not make sense to launch all 100 containers concurrently since the majority of the startup time is mostly spent waiting on hardware/kernel to complete the operations. containerd uses events to schedule container start requests and various other operations lock free. It has a configurable limit to how many containers it will start concurrently, by default we have it set at 10 workers. This allows you to make as many API requests as you want and containerd will start containers as fast as it can without totally overwhelming the system.

containerd’s API is very simple. We decided to build it with gRPC for performance as well as the ability to easily create client libraries. The basic request to start a container via the API is to only provide the path to the OCI bundle and the ID for the container. By keeping the API simple we minimize the changes in the API when new features are added.

We also have very minimal state in containerd. After the container has exited Docker will delete the generated bundle and any runtime state will be gone. This allows us to separate container runtime state on disk to only live as long as the container is running.

You should start to see more features like live migration and the ability to reattach to running containers so that Docker can be upgraded without affecting your containers in future releases of Docker as a result of this integration.

Give containerd a try with the latest Docker Engine 1.11 release. To install on your laptop, download Docker Toolbox. For other platforms, check out the installation instructions.

Check out the @Docker #containerd integration, a daemon to control runC – post by @crosbymichael
Click To Tweet

Learn More about Docker

• New to Docker? Try our 10 min online tutorial
• Share images, automate builds, and more with a free Docker Hub account
• Read the Docker 1.11 Release Notes
• Subscribe to Docker Weekly
• Sign up for upcoming Docker Online Meetups
• Attend upcoming Docker Meetups
• Watch DockerCon EU 2015 videos
• Start contributing to Docker