Notary v2 Project Update

Supply chain security is something that has been increasingly important to all of us in the last few years. Almost as important as the global supply chains that are having problems distributing goods around the world! There have been many attacks via the supply chain. This is where some piece of software that you use turns out to be compromised or to contain vulnerabilities that in turn compromises your production environment.

We have written about secure supply chain best practices . Docker is committed to helping you build security into your supply chain, and we are working on more tools to help you with this. We provide Docker Trusted Content, including Docker Official Images and Docker Verified Publisher images for you to use as a  trusted starting point for building your applications.

We have also been heavily involved with many community projects around supply chain security. In particular we are heavily involved in the Notary v2 project in the Cloud Native Computing Foundation (CNCF). We last wrote about this in January. This project is the next generation of the original Notary project that Docker started in 2015 and then donated to the CNCF. Notary (to simplify!) is a project for adding cryptographic signatures to container images so that you can make sure that the image someone produced is the same one that you are using, and that it has not been tampered with on the way.

Over the years we have learned a lot of things about how it is used, and the problems that have hindered wider adoption, and these are part of the community feedback into the design of Notary v2. We are looking to build a signing framework that can be used in every registry, and where signatures can be pushed and pulled with images so that you can identify that an image that you pull from your private on premise registry is the same as the Docker Official Image on Docker Hub, for example. This is one of the many use cases that are important to the community and which Notary v1 did not adequately address. We also want to make it much simpler to use, so we can have signature checks on by default for all users, rather than having opt-in signatures.

Today the project has released an early alpha prototype for further experimentation and for your feedback. Steve Lasker has written a blog post with the details. Check out the demos and please give feedback on whether these workflows fit your use cases, or how we can improve them.

Remember you can give us feedback about any aspect of our products on the Docker public roadmap. We are especially interested in your feedback around supply chain security and what you would like to see; we have had lots of really helpful feedback recently that is helping us work out where to take our products and tools.
The post Notary v2 Project Update appeared first on Docker Blog.

Screaming In the Cloud with Corey Quinn and Docker CEO Scott Johnston

On August 31st, Docker announced updates to our product subscriptions — Docker Personal, Pro, Team and Business. Our CEO Scott Johnston recently joined Corey Quinn on an episode of Screaming in the Cloud to go over all the details and discuss how the changes have been received by businesses and the broader developer community. 

The episode with Scott is titled “Heresy in the Church of Docker Desktop with Scott Johnston.” It’s a play on the title of a talk Corey once gave (“Heresy in the Church of Docker”) after he met Scott when they both worked at Puppet.

There’s a substantial discussion around Docker Desktop. Scott describes it as a unique hybrid — one that’s based on upstream open-source technologies (Docker Engine, Docker Compose, BuildKit, etc.), while also being a commercial product that’s engineered for the native environments of Mac and Windows, and soon Linux. He also recalls life before Docker Desktop when developers had to contend with complex setup, maintenance, and “tricky stuff that can go wrong” — all of which Docker Desktop handles so that developers can simply focus on building great apps.

Scott and Corey also discuss the why behind the new subscription tiers, and Docker Business in particular. A key factor was large organizations who use Docker Desktop at scale — as in hundreds and thousands of developers — requesting capabilities to help them manage those large developer environments. Another factor was the need to balance continuing investment in Docker Desktop to give organizations increased productivity, flexibility and security, while also sustainably scaling the Docker business, and still providing a generous free experience with the Docker Personal subscription.

According to Scott, the response from businesses to the updated subscriptions has been overwhelmingly positive. Not only have there turned out to be far more Docker Desktop users inside organizations than previously thought, but many companies have already proactively purchased a Docker subscription. The positive momentum is allowing Docker to accelerate items in the company’s roadmap for developers, such as Docker Desktop for Linux.

You can listen to Episode 264 of “Screaming in the Cloud,” titled “Heresy in the Church of Docker Desktop with Scott Johnston,” here.

Considering an Alternative to Docker Desktop?

Read this blog recapping Docker Captain Bret Fisher‘s video where he reminded his audience of the many things — some of them complex and subtle — that Docker Desktop does that make it such a valuable developer tool.
The post Screaming In the Cloud with Corey Quinn and Docker CEO Scott Johnston appeared first on Docker Blog.

Docker Captain Take 5 – Aurélie Vache

Docker Captains are select members of the community that are both experts in their field and are passionate about sharing their Docker knowledge with others. “Docker Captains Take 5” is a regular blog series where we get a closer look at our Captains and ask them the same broad set of questions ranging from what their best Docker tip is to whether they prefer cats or dogs (personally, we like whales and turtles over here). Today, we’re interviewing Aurélie Vache who has been a Docker Captain since 2021. She is a DevRel at OVHcloud and is based in Toulouse, France.

How/when did you first discover Docker?

I’ve been a developer (with Ops & Data sensibility) for over 15 years. I’m a former Java / JEE Developer, Ops, then Web, Full-Stack and Lead Developer.

Four years ago I was a cloud developer working on connected and autonomous vehicles projects. I discovered the magical world of cloud technologies: managed services with cloud providers, containers, orchestrator, observability, monitoring, infrastructure as code, CI/CD and real DevOps approach & culture. I fell in love with these technologies.

It was not easy to understand all the new concepts, but it was very interesting and enriching.

It was also the moment I discovered Docker. And since thenI have used Docker daily.

What is your favorite Docker command?

$ docker system prune -a

This command helped me in the past to save Jenkins agents :-D.

What is your top tip for working with Docker that others may not know?

I don’t know if it’s a “top tip” but I think it’s useful to know that containers have an exit status code and they can give us explanations about why the container has failed.

If you are interested, you can find my sketchnote about it here:

What’s the coolest Docker demo you have done/seen?

It was when a coworker showed me how he packaged his app into a Docker image, pushed it to a Docker registry, and ran it in a container, so easily. He could deploy an application anywhere, without having to install tools, dependencies, face version conflicts, and he could deploy his application in multiple environments without having to install x environments manually.

It was so magical and powerful.

What have you worked on in the past six months that you’re particularly proud of?

I have helped evangelize and democratize Docker, as well as Kubernetes and the world of containers and the cloud in general, across multiple companies. I also presented several talks entitled “Docker, Kubernetes, Istio: Tips, tricks & tools” across France.

I also created a new way to teach cloud technologies, such as Docker, through a series of sketchnotes: “Understanding Docker | Kubernetes | Istio” in a visual way. 

All technical books are written in the same way. Personally I understand more when I see diagrams, schemas, and illustrations rather than a ton of words. I have found this is helpful for other people too :-).

What do you anticipate will be Docker’s biggest announcement this year?

Honestly I don’t know. I like to be surprised ^^.

What are some personal goals for the next year with respect to the Docker community?

I plan to create a new series of videos about Docker, always in a visual way, in my YouTube channel, in order to continue to try to share and spread my knowledge in an easy way for people.

What talk would you most love to see at DockerCon 2022?

As usual, I like to be surprised, so I don’t have any expectations.

Rapid fire questions…

What new skill have you mastered during the pandemic?

During the pandemic I created a new way to explain complex and abstract concepts in a more simple and visual way, in sketchnotes, titled “Understanding xx in a visual way”. I sketched every evening and week-end, published them on Twitter and And finally, I’ve published 3 books about Kubernetes, Istio and Docker. I love to try to explain abstract complex concepts with simple illustrations and words.

Cats or Dogs?

As a child, I would have answered dog, but now I would answer cat. For a few days now I’ve had a kitten named “Sushi”!

Salty, sour or sweet?


Beach or mountains?


Your most often used emoji?

^^ or
The post Docker Captain Take 5 – Aurélie Vache appeared first on Docker Blog.

Speed up Building with Docker BuildX and Graviton2 EC2

As the expansion in arm usage continues, building your images on arm is crucial to making images available and performant across all architectures which is why we’ve invested in making it super easy to build arm and multi-arch images. In a previous blog we outlined how to build multi-arch images locally using the QEMU emulator that comes pre-packaged with Docker Desktop. In this blog we outline how to get started using a remote builder to accomplish the same goal, for our purposes we will be using an Amazon EC2 instance. In December of 2019, Amazon announced the new Amazon EC2 instances powered by AWS Graviton2 Processors that significantly improve performance over the first-generation AWS Graviton processors. Using a Graviton2 instance to build your arm images remotely will speed up the process, making it even easier to develop containers on, and for, arm servers and devices. 

We will walk through the following:

Using Graviton2 EC2 instance as a remote hostRegistering the Graviton2 EC2 instance as remote builderBuilding  the docker image on Graviton2 EC2 instanceAdding additional instances as required

To learn more about buildX and remote builders, you can visit our documentation.

Getting Started With a Remote Builder


First we’ll have to ensure that you are using a remote host instead of your local machine. Common ways to access remote Docker instances are via mTLS or SSH. Here we will use SSH for simplicity. In order to start with using a remote builder with Buildx and BuildKit on Graviton2 the host needs to be accessible through the Docker CLI, using ssh://<USERNAME>@<HOST> URL as follows:

$ docker -H ssh://me@graviton2-instance info
Context: default
Debug Mode: false
buildx: Build with BuildKit (Docker Inc., v0.6.1-65-gad9dddc3)
compose: Docker Compose (Docker Inc., v2.0.0-rc.3)
scan: Docker Scan (Docker Inc., v0.8.0)

Containers: 0
Running: 0
Paused: 0
Stopped: 0
Images: 0
Server Version: 20.10.9
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Native Overlay Diff: true
userxattr: false
Logging Driver: json-file
Cgroup Driver: cgroupfs
Cgroup Version: 1
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 5b46e404f6b9f661a205e28d59c982d3634148f8
runc version: v1.0.2-0-g52b36a2
init version: de40ad0
Security Options:
Profile: default
Kernel Version: 5.4.0-1045-aws
Operating System: Ubuntu 20.04.2 LTS
OSType: linux
Architecture: aarch64
CPUs: 2
Total Memory: 1.837GiB

Create the remote builder with Buildx

Now you can register this remote Graviton2 instance to Docker Buildx using the create command:

$ docker buildx create –name graviton2
–driver docker-container
–platform linux/arm64

–platform is specified so that this node will be preferred for arm64 builds when we add other nodes to this build cluster.

Bootstrap the builder to check and create the BuildKit container on the remote host:

$ docker buildx inspect –bootstrap –builder graviton2
#1 [internal] booting buildkit
#1 pulling image moby/buildkit:buildx-stable-1
#1 pulling image moby/buildkit:buildx-stable-1 2.2s done
#1 creating container buildx_buildkit_node1
#1 creating container buildx_buildkit_node1 1.4s done
#1 DONE 3.7s
Name: graviton2
Driver: docker-container

Name: node1
Endpoint: ssh://me@graviton2-instance
Status: running
Platforms: linux/arm64*, linux/arm/v7, linux/arm/v6

Build your image

Now we will create a simple Dockerfile:

FROM busybox as buildARG TARGETPLATFORMARG BUILDPLATFORMRUN echo “I am running on $BUILDPLATFORM, building for $TARGETPLATFORM” > /logFROM busyboxCOPY –from=build /log /logRUN cat /logRUN uname -a

And let’s build the image against our builder:

docker buildx build –builder graviton2
–push -t
–platform linux/arm64 .
#2 [internal] load .dockerignore
#2 transferring context:
#2 transferring context: 2B 0.2s done
#2 DONE 0.2s

#1 [internal] load build definition from Dockerfile
#1 transferring dockerfile: 246B 0.3s done
#1 DONE 0.4s

#3 [internal] load metadata for
#3 …

#4 [auth] library/busybox:pull token for
#4 DONE 0.0s

#3 [internal] load metadata for
#3 DONE 1.5s

#5 [build 1/2] FROM
#5 resolve 0.0s done
#5 DONE 0.0s

#5 [build 1/2] FROM
#5 sha256:7560ee4921c3fab4f1d34c83600f6f65841ec863e072374f4e8044ff01df156f 821.72kB / 821.72kB 0.1s done
#5 extracting sha256:7560ee4921c3fab4f1d34c83600f6f65841ec863e072374f4e8044ff01df156f 0.0s done
#5 DONE 0.2s

#6 [build 2/2] RUN echo “I am running on $BUILDPLATFORM, building for $TARGETPLATFORM” > /log
#6 DONE 0.1s

#7 [stage-1 2/4] COPY –from=build /log /log
#7 DONE 0.0s

#8 [stage-1 3/4] RUN cat /log
#8 0.078 I am running on $BUILDPLATFORM, building for $TARGETPLATFORM
#8 DONE 0.1s

#9 [stage-1 4/4] RUN uname -a
#9 0.081 Linux buildkitsandbox 5.4.0-1045-aws #47-Ubuntu SMP Tue Apr 13 07:04:23 UTC 2021 aarch64 GNU/Linux
#9 DONE 0.1s

#10 exporting to image
#10 exporting layers
#10 exporting layers 0.3s done
#10 exporting manifest sha256:7097ec1c09675617e2c44b5924b76f7863c4ff685c640b32dfaa1b1e8f2bc641 0.0s done
#10 exporting config sha256:d18ca92a45b563373606f0a06d0a1d2280d0c11976b1ca64dba0e567d540a3e2 0.0s done
#10 pushing layers
#10 pushing layers 0.7s done

Add other instances

You can also append other Graviton2 instances (node) to the same builder with:

docker buildx create –name graviton2
–node node2
–driver docker-container
–platform linux/arm64
–append ssh://me@graviton2-instance2

Note the –append flag to add a node to the existing graviton2 builder.

Now, you’ve built your image remotely using a Graviton2 instance! These are just some of the things you can do with buildx. We’d love your feedback on how it went and what you’d like to see us do next, you can submit it feedback to our public roadmap.
The post Speed up Building with Docker BuildX and Graviton2 EC2 appeared first on Docker Blog.

Online Machine Learning: INTO THE DEEP – Online Learning is a branch of Machine Learning that has obtained a significant interest in recent years thanks to its peculiarities that perfectly fit numerous kinds of tasks in today’s world. Let’s…

Join Docker This Month at KubeCon and the Cloud Engineering Summit

Two cloud-related conferences are coming up this month, and Docker will have speakers at both. First up, Docker CTO Justin Cormack will present at KubeCon next week. The week after that Peter McKee, Docker’s head of Developer Relations, will speak at  Pulumi Cloud Engineering Summit.

At KubeCon, Justin and co-presenter Steve Lasker of Microsoft will speak on the topic of tooling for supply chain security with special reference to the Notary project. They’ll also look at the future roadmap and the supply chain landscape. KubeCon, the flagship conference of the Cloud Native Computing Foundation, is geared toward adopters and technologists from leading open source and cloud native communities. The conference runs Oct. 11 – 15 in Los Angeles and virtually. Justin’s presentation, titled Notary: State of the Container Supply Chain, takes place Thursday, Oct. 14 at 4:30 p.m. – 5:05 p.m. Pacific.

At the Cloud Engineering Summit, Peter will team up with Uffizzi’s Josh Thurman to speak about Continuous Previews — a cousin of Continuous Integration and Continuous Deployments that allows developers to easily share new features and changes to a wide audience within their organization, thereby speeding the delivery of features to users. The Wednesday, Oct. 20 summit is a virtual day of learning for cloud practitioners that focuses on best practices for building, deploying and managing modern cloud infrastructure. Peter’s presentation, titled Continuous Previews: Using Infrastructure as Code to Continuously Share and Preview Your Application, takes place at 3:00 p.m. – 3:30 p.m. Pacific.
The post Join Docker This Month at KubeCon and the Cloud Engineering Summit appeared first on Docker Blog.

Docker Index Shows Momentum in Developer Community Activity

The latest edition of the Docker Index is in, and it shows a continued growth in activity across the Docker community. The momentum we are seeing since the last Docker Index in February 2021 edition continues to grow.

You’ll recall that we started publishing the Docker Index in early 2020 as a way to provide insight into trends in application development, mining anonymized data from millions of Docker users. Every time we’ve published the Docker Index since then (this is our fourth Docker Index post), we’ve been amazed at the findings. 

As of Aug. 31, 2021, there’s been a total of 396 billion all-time pulls on Docker Hub — up from 318 billion just six months ago and an increase of about 25% year-over-year. In addition, there were 42 billion Docker Hub Pulls in the second quarter of 2021 (calendar year), up from 30 billion in the fourth quarter of 2020, likely reflecting a continued accelerating demand for more applications as the pandemic shutdown accelerated businesses’ digital transformation efforts. Docker Trusted Content — including Docker Official Images, Docker Verified Publisher content and Docker-sponsored Open Source projects — is available at all Docker subscription levels.

These increases paint a clear picture of collaborative application development platforms as the foundation for developers who want to build, share and run modern apps.

The numbers are up across the board. The number of application container image repositories on Docker Hub reached 12.5 million, up from 8.3 million in our February Index, and representing a more than 50% year-over-year increase in the application components that developers rely on to build apps.

There are now 9 million Docker Hub accounts, up about 30% year-over-year. Docker Desktop installations have risen to 4.7 million from 3.3 million in February this year, and Docker Desktop downloads stand at 11.9 million.

Meanwhile, according to the 2021 Stack Overflow Developer Survey, based on a survey of over 83,000 software developers, Docker continues to be extremely popular among developers. Along with Git and Kubernetes, it’s among both the most loved and most wanted tools.

Over 76% said they loved Docker, behind Git (nearly 85%) and ahead of Kubernetes (over 72 %). And Docker led the pack with nearly 30% expressing an interest in developing with it.

And according to a DevOps survey by JetBrains, Docker users are three times more likely to be found working as DevOps engineers or infrastructure developers, two times more likely to be architects, and 30% more likely to serve as team leads. They are also more likely to have a senior position.

Thanks again to the entire Docker community and ecosystem for the ongoing innovation, feedback and commitment to one another that makes Docker more vibrant and relevant to the evolving and expanding needs of developers. Finally developer feedback and input is core to how we guide our investments into the Docker platform. I want to encourage you all to provide feedback and requests about what you want to see in Docker by commenting on our public roadmap.
The post Docker Index Shows Momentum in Developer Community Activity appeared first on Docker Blog.