Announcing the Compose Specification

Docker is pleased to announce that we have created a new open community to develop the Compose Specification. This new community will be run with open governance with input from all interested parties allowing us together to create a new standard for defining multi-container apps that can be run from the desktop to the cloud. 

Docker is working with Amazon Web Services (AWS), Microsoft and others in the open source community to extend the Compose Specification to more flexibly support cloud-native platforms like Kubernetes and Amazon Elastic Container Service (Amazon ECS) in addition to the existing Compose platforms. Opening the specification will allow innovation to flourish and deliver more choices to developers, accelerating how development teams build and ship applications.

Currently used by millions of developers and with over 650,000 Compose files on GitHub, Compose has been widely embraced by developers because it is a simple cloud and platform-agnostic way of defining multi-container based applications. Compose dramatically simplifies the code to cloud process and toolchain for developers by allowing them to define a complex stack in a single file and run it with a single command. This eliminates the need to build and start every container manually, saving development teams valuable time.

Previously Compose did not have a published specification, and was tied to the implementation, and to specifics of the platforms it shipped on. Open governance will benefit the wider community of new and existing users with transparency and the ability to have input into the future direction of the specification and Compose based tools. With greater community support and engagement, Docker intends to submit the Compose Specification to an open source foundation to further enhance the level playing field and openness.

If you want to get started using Docker Compose today to try the existing features you can download Docker Desktop with Docker Compose here. Or if you are looking for some examples or ideas to get started with Compose why not check out the Awesome Compose Repo. The draft specification is available at; we are looking for contributors to the Compose Specification along with people who are interested in building tools around the specification. Docker will continue to contribute to the specification and be an active member of the community around it going forward.
The post Announcing the Compose Specification appeared first on Docker Blog.

Join our new Docker Desktop Developer Preview Program!

Docker Desktop is getting ready to celebrate its fourth birthday in June this year. We have come a long way from our first version and have big plans of what we would like to do next. As part of our future plans we are going to be kicking off a new early access program for Docker Desktop called Docker Desktop Developer Preview and we need your help!

What is this Program about and what are the benefits?

This program is for a small number of heavy Docker Desktop users who want to interact with the Docker team and impact the future of Docker Desktop for millions of users around the world.

As a member of this group we will be working with you to look at and experiment with our new features. You will get direct access to the people who are building Docker Desktop everyday. You will meet with our engineering team, product manager and community leads, to share your feedback, tell us what is working in our new features and how we could improve, and also help us really dig in when something doesn’t work quite right. 

On top of that, you will have a chance to feed directly into our roadmap and help us come up with ideas of what we should do next. 

What will I need to do?

You will be expected to run frequent bleeding edge builds of Docker Desktop and help us investigate on private builds when we are working on particular issues of features. We need you to commit to always running new versions of Desktop and update on day 1, so we make sure we get early feedback.

We may also need you to stress test all of our new features and tell us what goes wrong. You might even work directly with the engineering team to help us debug issues and get to the bottom of things. We aren’t after people who want to ‘fire and forget’ a Github issue, we want to partner with you to find and test solutions to these problems and get them shipped to millions of other users.

What type of users are we looking for?

We are looking for developers who extensively use Docker Desktop, on a daily basis, using any language or framework, who would be willing to help us on new experimental versions of Docker Desktop. Both Mac and Windows users are welcome.

For now, we would like to mostly engage with developers who have a good knowledge of Docker. You don’t need to be the most advanced user to apply, but at least be already familiar with Docker and its concepts. You’re a beginner and just started to learn Docker? Don’t worry we may open the program to you in the future.

Given our 2.4M total install base, this group of developers will be a small group; it will be around 25 people as a start. A reduced group will help us to make sure we can have a tight interaction!

Interested to join the Developer Preview Program?

If you are interested in taking part in the Docker Desktop Developer Preview program then please drop us a line through the form below. Since our plan is to have the new program live in late April, we will be accepting sign ups until the 10th of April and will be in touch with you by the 17th if you have been selected. We look forward to hearing from you!

Sign up today

And again, keep in mind that any feedback about Docker Desktop – even outside of this program – is welcomed. Feel free to drop by our public roadmap page to suggest ideas and input!
The post Join our new Docker Desktop Developer Preview Program! appeared first on Docker Blog.

Update from Docker on COVID-19 Actions

As the novel coronavirus causing COVID-19 continues to spread, Docker has been taking precautionary measures to support the health, well-being, and safety of our global team members and their families, as well as ensuring our customers and community at large can continue building and shipping apps using Docker. We are also following the World Health Organization (WHO) and the Center for Disease Control and Prevention (CDC) guidelines, as well as guidelines from local public health administrations. 

Docker has always been about community, and here are the steps we have taken to ensure employees are taken care of as well as to ensure business continuity for our users worldwide:

Protecting Employees

On March 2, 2020, we asked all global employees to cancel or postpone any non-essential, work-related travel. Additionally, on March 9, 2020, we closed all of our offices globally to employees and visitors. We are using all available technologies like our phones, Zoom, Slack, GitHub, and Confluence now that we have transitioned to a fully remote workforce. While Docker is a geographically distributed organization, we understand this is a big shift for many of our employees and, as such, we are encouraging as much flexibility around work schedules and hours as possible as we all adjust to these new circumstances.

Delivering for Our Users

Docker Hub is, by design, a highly-available cloud service which means it is accessible 24×7 for developers and teams of developers, including now during this difficult period, regardless of other limitations that may be on teams due to a pandemic. The team at Docker is well-positioned to work remotely without interruption, allowing us to be agile and adapt to changing market and other conditions.We remain focused on executing our public roadmap and continuing to deliver a unique connected experience from source code to cloud deployment for developers and development teams. 

Keeping our Community Strong – and Safe

Back in December 2019, prior to the widespread virus outbreak, we announced that DockerCon 2020 would no longer be a physical event and would instead evolve into DockerCon LIVE, a virtual event for our community taking place on May 28, 2020. This is the safest and healthiest option for our community, and we are excited to still bring everyone together to learn and share from one another.  We miss in-person meetups too, however, there are many ways to still remain connected with the Docker community including Docker Community Slack and the Docker Virtual Meetup Group. In addition, in lieu of in-person birthday meetups, we recently celebrated Docker’s 7th birthday with our community via a live show on YouTube (check out the recording here). 

And finally, we have seen a number of examples springing up on Docker Hub of how developers are using Docker to create applications, data analysis tools, and dashboards for public health research. It is very inspiring to see how global teams of developers are using Docker in the fight against this global pandemic.

Though this is a challenging time in human history, we believe that by coming together as a community and taking care of one another, we will persevere and come out of this stronger and more united. Please stay well! 
The post Update from Docker on COVID-19 Actions appeared first on Docker Blog.

Multi-Platform Docker Builds

This is a guest post from Docker Captain Adrian Mouat who is Chief Scientist at Container Solutions, a cloud-native consultancy and Kubernetes Certified Service Provider. Adrian is the author of “Using Docker,” published by O’Reilly Media. He is currently developing Trow, a container image registry designed to securely manage the flow of images in a Kubernetes cluster. Adrian is a regular conference speaker and trainer and he has spoken at several events including KubeCon EU, DockerCon, CraftConf, TuringFest and GOTO Amsterdam.

Docker images have become a standard tool for testing and deploying new and third-party software. I’m the main developer of the open source Trow registry and Docker images are the primary way people install the tool. If I didn’t provide images, others would end up rolling their own which would duplicate work and create maintenance issues.

By default, the Docker images we create run on the linux/amd64 platform. This works for the majority of development machines and cloud providers but leaves users of other platforms out in the cold. This is a substantial audience – think of home-labs built from Raspberry Pis, companies producing IoT devices, organisations running on IBM mainframes and clouds utilising low-power arm64 chips. Users of these platforms are typically building their own images or finding another solution.

So how can you build images for these other platforms? The most obvious way is simply to build the image on the target platform itself. This can work in a lot of cases, but if you’re targetting s390x, I hope you have access to an IBM mainframe (try Phil Estes, as I’ve heard he has several in his garage). More common platforms like Raspberry Pis and IoT devices are typically limited in power and are slow or incapable of building images.

So what can we do instead? There’s two more options: 1) emulate the target platform or 2) cross-compile. Interestingly, I’ve found that a blend of the two options can work best.


Let’s start by looking at the first option, emulation. There’s a fantastic project called QEMU that can emulate a whole bunch of platforms. With the recent buildx work, it’s easier than ever to use QEMU with Docker.

The QEMU integration relies on a Linux kernel feature with the slightly cryptic name of the binfmt_misc handler. When Linux encounters an executable file format it doesn’t recognise (i.e. one for a different architecture), it will check with the handler if there any “user space applications” configured to deal with the format (i.e. an emulator or VM). If there are, it will pass the executable to the application.

For this to work, we need to register the platforms we’re interested in with the kernel. If you’re using Docker Desktop this will already have been done for you for the most common platforms. If you’re using Linux, you can register handlers in the same way as Docker Desktop by running the latest docker/binfmt image e.g:

docker run –privileged –rm docker/binfmt:a7996909642ee92942dcd6cff44b9b95f08dad64

You may need to restart Docker after doing this. If you’d like a little more control over which platforms you want to register or want to use a more esoteric platform (e.g. PowerPC) take a look at the qus project.

There’s a couple of different ways to use buildx, but the easiest is probably to enable experimental features on the Docker CLI if you haven’t already – just edit ~/.docker/config.json to include the following:


"experimental": “enabled”

You should now be able to run docker buildx ls and you should get output similar to the following:

$ docker buildx ls
default docker
default default running linux/amd64, linux/arm64, linux/riscv64, linux/ppc64le, linux/s390x, linux/386, linux/arm/v7, linux/arm/v6

Let’s try building an image for another platform. Start with this Dockerfile:

FROM debian:buster

CMD uname -m

If we build it normally and run it:

$ docker buildx build -t local-build .

$ docker run –rm local-build

But if we explicitly name a platform to build for:

$ docker buildx build –platform linux/arm/v7 -t arm-build .

$ docker run –rm arm-build

Success! We’ve managed to build and run an armv7 image on an x86_64 laptop with little work. This technique is effective, but for more complex builds you may find it runs too slowly or you hit bugs in QEMU. In those cases, it’s worth looking into whether or not you can cross-compile your image.


Several compilers are capable of emitting binary for foreign platforms, most notably including Go and Rust. With the Trow registry project, we found cross-compilation to be the quickest and most reliable method to create images for other platforms. For example, here is the Dockerfile for the Trow armv7 image. The most relevant line is:

RUN cargo build –target armv7-unknown-linux-gnueabihf -Z unstable-options –out-dir ./out

Which explicitly tells Rust what platform we want our binary to run on. We can then use a multistage build to copy this binary into a base image for the target architecture (we could also use scratch if we statically compiled) and we’re done. However, in the case of the Trow registry, there are a few more things I want to set in the final image, so the final stage actually begins with:

FROM –platform=linux/arm/v7 debian:stable-slim

Because of this, I’m actually using a blend of both emulation and cross-compilation – cross-compilation to create the binary and emulation to run and configure our final image.

Manifest Lists

In the above advice about emulation, you might have noticed we used the –platform argument to set the build platform, but we left the image specified in the FROM line as debian:buster. It might seem this doesn’t make sense – surely the platform depends on the base image and how it was built, not what the user decides at a later stage?

What is happening here is Docker is using something called manifest lists. These are lists for a given image that contain pointers to images for different architectures. Because the official debian image has a manifest list defined, when I pull the image on my laptop, I automagically get the amd64 image and when I pull it on my Raspberry Pi, I get the armv7 image.

To keep our users happy, we can create manifest lists for our own images. If we go back to our earlier example, first we need to rebuild and push the images to a repository:

$ docker buildx build –platform linux/arm/v7 -t amouat/arch-test:armv7 .

$ docker push amouat/arch-test:armv7

$ docker buildx build -t amouat/arch-test:amd64 .

$ docker push amouat/arch-test:amd64

Next, we create a manifest list that points to these two separate images and push that:

$ docker manifest create amouat/arch-test:blog amouat/arch-test:amd64 amouat/arch-test:armv7
Created manifest list
$ docker manifest push amouat/arch-test:blog

Now Docker will pull and run the appropriate image for the current platform:

$ docker run amouat/arch-test:blog
Unable to find image ‘amouat/arch-test:blog’ locally
blog: Pulling from amouat/arch-test
Digest: sha256:039dd768fc0758fbe82e3296d40b45f71fd69768f21bb9e0da02d0fb28c67648
Status: Downloaded newer image for amouat/arch-test:blog

Somebody with a Raspberry Pi to hand can try running the image and confirm that it does indeed work on that platform as well!

To recap; not all users of Docker images run amd64. With buildx and QEMU, it’s possible to support these users with a small amount of extra work.

Happy Birthday, Docker!
The post Multi-Platform Docker Builds appeared first on Docker Blog.

Awesome-Compose: Application samples for project development kickoff

Software systems have become quite complex nowadays. A system may consist of several distributed services, each one providing a specific functionality and being updated independently. Starting the development of a project of such complexity is sometimes time consuming, in particular when you are not already familiar with the software stack you are going to work on. This may be because, most of the time, we need to follow rigorous steps to put together the entire project and if we make a mistake in-between, we may have to start all over again.

As a developer, getting a quick understanding of how all the stack is wired together and having an easy to manage project skeleton may be a very good incentive to use that particular stack for future projects. 

Furthermore, there are plenty of open-source software stacks that developers can use for their own setups. Providing them with a straightforward way to deploy these software stacks in order to check them out is an important matter when looking to simplify software development and allow developers to explore different options. 

To tackle this, we have put together a Github repository with application samples that can be easily deployed with Docker Compose. The repository name is awesome-compose and it contains a curated list of Compose application samples which can provide a good starting point for how to integrate different services using a Compose file and to manage their deployment with Docker Compose. 

The awesome-compose repository was created to provide a quick and simple way for developers to experience Compose-based setups with different software stacks.  Moreover, we hope that you are willing to share your best examples of compose files for different stacks that are not already in the repository or to improve the current samples for everybody to use.

The setups provided currently in the awesome-compose repository fit mainly in two categories:

Application skeletons: useful for kicking off project development. We can find different application skeletons with multiple services already wired together and ready to be launched with docker-compose;Setups with different open-source software stacks. These are not production ready, they are intended mostly for personal/home use or simply for developers to get familiar with them within their local dev environment. 

All samples in the repository are provided as they are, everybody can customize each sample according to their needs. 

We will discuss further each category and what are the benefits they can provide.

Kickoff a project with an application sample

To be able to run the samples from the repository, make sure you have already installed:

Windows or macOS: Install Docker DesktopLinux: Install Docker and then Docker Compose

Then, either git clone or download one or more samples from the awesome-compose repository.

$ git clone$ cd awesome-compose

At the root of each sample there is the docker-compose.yml. It contains the definition and the structure of the application and instructions on how to wire the components of the application.

Identify the sample that matches your requirements and open its directory. Sample’s directory names follow a very simple pattern consisting of component names separated by ‘-’. This allows us to quickly identify the sample we need for our project. For this exercise, let us use the nginx-flask-mysql sample.

There are a few simple steps to follow to get the application skeleton up and running and be able to modify it.

Deploy the application sample

Open the sample directory and run it with docker-compose:

$ cd nginx-flask-mysql$ docker-compose up -dCreating volume “nginx-flask-mysql_db-data” with default driverBuilding backendStep 1/8 : FROM python:3.8-alpine3.8-alpine: Pulling from library/python……Creating nginx-flask-mysql_db_1      … doneCreating nginx-flask-mysql_proxy_1   … doneCreating nginx-flask-mysql_backend_1 … done

Check there are three containers running, one for each service:

$ docker-compose psName                          Command        State        Ports—————————————————————————————————————————————————————————————————————————————————————————————nginx-flask-mysql_backend_1   /bin/sh -c flask run –hos …   Up>5000/tcp
nginx-flask-mysql_db_1 –def …   Up   3306/tcp, 33060/tcp
nginx-flask-mysql_proxy_1     nginx -g daemon off;          Up>80/tcp

Query port 80 of the proxy container with curl or in a web browser to have the backend pass the data from the DB:

$ curl localhost:80<div>Blog post #1</div><div>Blog post #2</div><div>Blog post #3</div><div>Blog post #4</div>

Modify and update the application sample

Let us assume that we have to change the application server, in this case being the backend service which is implemented in python using the Flask framework. The method returning the message we queried previously can be found below.

@server.route(‘/’)def listBlog():   global conn   if not conn:       conn = DBManager(password_file=‘/run/secrets/db-password’)       conn.populate_db()   rec = conn.query_titles()  response = ”  for c in rec:
    response = response + ‘<div> ‘ + c + ‘</div>’
  return response

Assume we change this method to remove the html tags:

@server.route(‘/’)def listBlog():  …  for c in rec:
    response = response + ‘ ‘ + c + ‘ ‘
  return response

As all our containers are already running, the logical workflow would be to stop the backend service, rebuild its image and re-run to get our change in. Doing this would be very inefficient during development.

We could in turn, hack the docker-compose file and add under the backend service the following setting:

backend:    build: backend    restart: always    volumes:
    – ./backend:/code    …

This would instruct Docker Compose to mount the backend source code to the container path from where it is being executed on container start.

Now, all we have to do is to restart the backend to have the changed code executed.

$ docker-compose restart backendRestarting nginx-flask-mysql_backend_1 … done

Querying again the proxy, we can observe the change:

$ curl localhost:80Blog post #1 Blog post #2 Blog post #3 Blog post #4

Cleanup deployment  and data

To remove all containers run:

$ docker-compose downStopping nginx-flask-mysql_backend_1 … doneStopping nginx-flask-mysql_db_1 … doneStopping nginx-flask-mysql_proxy_1 … doneRemoving nginx-flask-mysql_backend_1 … doneRemoving nginx-flask-mysql_db_1 … doneRemoving nginx-flask-mysql_proxy_1 … doneRemoving network nginx-flask-mysql_backnetRemoving network nginx-flask-mysql_frontnet

Adding the -v parameter to the down command ensures all data hosted by the db service is being deleted:

$ docker-compose down -v…Removing volume nginx-flask-mysql_db-data

To conclude this part, the samples provided in the awesome-compose repository may help developers to put together all the components for their project in a matter of minutes. This is most beneficial in particular for beginners in the development with containerized applications that can be managed with docker-compose.

Setups for different software stacks

The second type of samples that awesome-compose repository contains are compose files for setting up different platforms such as Nextcloud, WordPress, Gitea etc. These samples consist mostly of a Compose file defining a basic setup for each of the components. The purpose for these is to provide developers an easier introduction to different software stacks they could take a quick view at what they offer and tinker with. 

Let us consider the Nextcloud setup for the next exercise. Nextcloud is an open source file sharing platform that anyone can install for their private use. The setups in the awesome-compose repository are pieced together according to the instructions on the Nextcloud’s official image page in Docker Hub.

To deploy it, select the directory of the nextcloud sample you prefer:

$ cd nextcloud-postgres/$ lsdocker-compose.yaml

And run it with docker compose:

$ docker-compose up -dCreating network “nextcloud-postgres_default” with the default driver
Creating volume “nextcloud-postgres_db_data” with default driver
Creating volume “nextcloud-postgres_nc_data” with default driverPulling nc (nextcloud:apache)…
apache: Pulling from library/nextcloud…Creating nextcloud-postgres_nc_1 … doneCreating nextcloud-postgres_db_1 … done

Check that containers are running:

$ docker-compose psName                      Command                         State     Ports—————————————————————————————————————————————————————————————————————————————————————–nextcloud-postgres_db_1 postgres   Up        5432/tcp
nextcloud-postgres_nc_1   / apache2-for …    Up>80/tcp$ docker psCONTAINER ID   IMAGE              COMMAND                 CREATED   STATUS              PORTS                NAMESa1381bcf5b1c   nextcloud:apache   “/ apac…”  14 minutes ago   Up About a minute>80/tcp   nextcloud-postgres_nc_1ec66a5aff8ac  postgres:alpine “docker-entrypoint.s…”    14 minutes ago    Up About a minute   5432/tcp             nextcloud-postgres_db_1

In only a few minutes (depends on the internet connection) we get a nextcloud platform up and running on our local machine. Opening a browser window and going to localhost:80 should land us on the Nextcloud’s initialization page:

Similarly to the first exercise, to remove all containers run: 

$ docker-compose downStopping nextcloud-postgres_nc_1 … doneStopping nextcloud-postgres_db_1 … doneRemoving nextcloud-postgres_nc_1 … doneRemoving nextcloud-postgres_db_1 … doneRemoving network nextcloud-postgres_default

Use the -v parameter to delete the volumes where the nextcloud data gets stored. Identical steps should be followed for all other samples of useful software stacks.


Lowering the barrier in deploying different software stacks, enables more and more developers to have a look at them and potentially use them for their projects.

The awesome-compose repository was created with the purpose of aggregating compose files and application samples that may be useful to anyone interested in containerized applications.

Call for contributions

All developers already familiar with compose and that have already set up interesting stacks that may be useful to others, are highly encouraged to add them to the repository and share them.  Improvements on the current samples are also very much appreciated!
The post Awesome-Compose: Application samples for project development kickoff appeared first on Docker Blog.

#myDockerBday Discounts on Docker Captain Docker + Kubernetes Content

If your #myDockerBday celebration included wanting to learn more about Docker or Kubernetes, you are in luck. In honor of Docker’s 7th birthday, Docker Captains have extended some fantastic deals on their learning content. Take this opportunity to level up your skills and learn Docker with excellent instructors. 

Books and EBooks

Through the end of March, you can get Elton Stoneman’s Learn Docker in a Month of Lunches and/or Jeff Nickeloff’s Docker in Action 2nd Edition for 40% off using the code mtpdocker20.

Learn Docker in a Month of Lunches

Elton StonemanGo from zero to production readiness with Docker in 22 bite-sized lessons! Learn Docker in a Month of Lunches is an accessible task-focused guide to Docker on Linux, Windows, or Mac systems. In it, you’ll learn practical Docker skills to help you tackle the challenges of modern IT, from cloud migration and microservices to handling legacy systems. There’s no excessive theory or niche-use cases– just a quick-and-easy guide to the essentials of Docker you’ll use every day.

Docker in Action 2nd Edition

Jeff NickeloffDocker in Action, Second Edition teaches you the skills and knowledge you need to create, deploy, and manage applications hosted in Docker containers. This bestseller has been fully updated with new examples, best practices, and a number of entirely new chapters.

Video Courses

And through Saturday, March 28th, get the following Captain courses on Udemy for just $9.99.

Kubernetes 101

Nigel Poulton

Learn or brush up with the basics of Kubernetes. Kubernetes architecture is clearly explained, Nigel will show you how to deploy, break, self-heal, scale, and perform rolling updates on a simple application. This course is perfect in helping you master the fundamentals.Code: DOCKERBIRTHDAY

Docker Mastery

Bret Fisher

Build, test, deploy containers with the best mega-course on Docker, Kubernetes, Compose, Swarm and Registry using DevOps

Code: DOCKER_IS_7_C1

Kubernetes Mastery

Bret Fisher

Learn the latest Kubernetes features (1.16) and plugins while practicing DevOps workflows, from a container expert.

Code: DOCKER_IS_7_C4

Swarm Mastery

Bret Fisher

Build, automate and monitor a service cluster for containers using the latest open source on Linux and Windows.

Code: DOCKER_IS_7_C2

Docker for Node.js

Bret Fisher

Build, test, deploy Node for Docker, Kubernetes, Swarm, and ARM with the latest DevOps practices from a container expert.Code: DOCKER_IS_7_C3

Wait…there’s more!

Continue the celebration with Docker and the Captains by joining the:

7th Birthday Challenge. Learn some of the Docker Captain’s favorite Tips + Tricks by completing 7 hands-on exercises. Earn a virtual badge for each exercise completed.#myDockerBday Live Show. Celebrate Docker’s Birthday with a special 3-hour live show featuring exclusive conversations with the Docker team and Captains, open Q&A sessions, and prizes. To reserve a spot, sign up here. 
The post #myDockerBday Discounts on Docker Captain Docker + Kubernetes Content appeared first on Docker Blog.

First Docker GitHub Action is here!

We are happy to announce that today Docker has released its first Github Action! We’ve been working with GitHub, looking into how developers have been using GitHub Actions with Docker to set up their CI/CD workflows. The standard flows you’ll see if you look around are what you’d expect: building an image, tagging it, logging into Hub, and pushing the image. This is the workflow we’ve aimed to support with our Docker build-push action.

Simplify CI/CD workflows

At Docker traditionally much of our CI/CD workflows has been handled through Jenkins using a variety of products to set up and maintain it. For some things this is the best solution like when we are testing Docker Desktop on a whole variety of different hosts and configurations. For others it’s a bit overkill. Like many, we at Docker have been looking at how we can leverage GitHub Actions to simplify our workflows, including how we use Docker itself.

GitHub Actions already leverages Docker in a lot of its workflows. From having Docker pre-installed and configured on the cloud runners to having first class support for containerized actions allows developers to easily use the same Docker workflows they use locally to configure their repo’s CI/CD. Combined with multi-stage builds and you have a powerful environment to work with. 

Docker actions

When we started with Github Actions there were no built-in actions to handle our main build, tag and push flow so we end up with a yaml file, that can’t yet be run locally, full of bash commands. Indeed that’s exactly what you’re given if you choose the “Docker Publish” workflow template from inside GitHub. Though it’s certainly doable it’s not as easy to read and maintain as a script that just uses pre-built actions. This is likely why the community has already published a whole host of actions to do just that. Just go to the GitHub Marketplace and search for Docker actions.

Common things you’ll see beyond just the standard build/tag/push is supporting automatic tagging of images based on the branch you’re building from, logging in to private registries, and setting standard CLI arguments like the Dockerfile path.

Having looked at a number of these we decided to build our own actions off of these ideas and publish them back to the community as official Docker supported GitHub Actions. The first of these, docker/build-push-action, supports much of what has been written above and attempts to build and push images with what we consider to be best practices including:

Tagging based on the git ref (branches, tags, and PRs).Tagging with the git SHA to make it easy to grab the image in later stages of more complex CI/CD flows. For example where you need to run end-to-end tests in a large, self-hosted cluster.Labelling the image with Open Container Initiative labels using data pulled from the GitHub Actions environment.Support for build time arguments and multi-stage targets.Push filter that allows you to configure when just to build the image and when to actually push it depending on any of the data supplied by GitHub Actions and your own scripts. See the examples for one we use ourselves.

A single action approach

But why one big action instead of many small ones? One thing that came up in our discussions with GitHub is how they envisaged that users would create many small actions and chain them together using inputs and outputs but the reality looks to be the opposite. From what we had seen users have been creating big actions and handling the flows internally using inputs for configuration details.

Whilst developing our own actions we found ourselves going the same way, firstly because it’s simply easier to test that way as there currently isn’t any way to run the workflow script locally.

Also this:

– name: build  id: build  uses: docker/build-action@v1  with:     repository: myorg/myrepo    tags: v1– name: login  uses: docker/login-action@v1  with:    registry: myregistry    username: ${{ DOCKER_USERNAME }}    password: ${{ DOCKER_USERNAME }}– name: push  uses: docker/push-action@v1  with:    registry: myregistry    tags: ${{ }}

Is a bit more effort to write than:

– name: build-push  uses: docker/build-push-action@v1  with:    username: ${{ DOCKER_USERNAME }}    password: ${{ DOCKER_USERNAME }}    registry: myregistry    repository: myorg/myrepo    tags: v1

The final reason we went with the single action approach was that the logic of how the separate steps link and when they should be skipped is simple to handle in the backend based purely on a couple of inputs. Are the username and password set? Then do a login. Should we push? Then push with the tags that we built the image with. Is the registry set? Then log in to that registry, tag the images with that registry, and push to it rather than defaulting to Docker Hub.

Feedback is welcomed!

All of this is handled by the image that backs the action. The backend is a simple go program that shells out to the Docker CLI, the code for which can be found here and is built and pushed using the action itself. As always, feedback and contributions are always welcome.

If you want to try out our Docker Github Action you can find it here or if you haven’t used Github actions before you can find a guide to get started by Github here. For more news on what else to expect coming soon from Docker remember to look at our public roadmap
The post First Docker GitHub Action is here! appeared first on Docker Blog.

DockerCon LIVE with theCUBE: Call for Papers is Open

CFP Deadline: March 27th at 11:59 PM PST

The beauty of Docker is in the ways that developers are using it to positively impact their lives, industries, and day-to-day workflows. From sending rockets to space, to running some of the biggest apps on Earth, Docker helps developers build and share containerized apps – from the boring to the apps that change the world. DockerCon is the place where the community comes together to connect and share stories, best practices, and use cases. 

Back in December, we announced that DockerCon would not be a physical event but instead was evolving into a digital event. At the time, that decision was made in order to make attending DockerCon an option for any and all developers and members of the community. And now with the current state of the global COVID-19 pandemic, we are extra thankful to have already been planning for a virtual-only gathering. This change to DockerCon is the safest and healthiest option for our community, and we are excited to still bring everyone together to learn and share from one another.  

This year, DockerCon will be a virtual event on May 28th from 9am to 5pm GMT -8.  We are looking forward to delivering a more earth and budget-friendly conference while maintaining the compelling content and connections that DockerCon is known for. We think we have a format that delivers on that and uniquely taps the Docker community at large. But this certainly starts with you! Share your story by submitting a CFP to speak at DockerCon LIVE before the deadline of March 27th.


What we are looking for

We are looking for submissions on the following topics:

Developer workflows (CI/CD)Use Case: Setting up your local dev environment: Tips and TricksUse Case: How to onboard new developers – best practices Use Case: Containerizing your microservicesUse Case: Containerizing legacy appsUse Case: Using Docker to deploy machine learning modelsUnique use cases and cool appsTechnical deep dives Community StoriesOpen Source

How DockerCon LIVE works

To allow for conversation and ensure a stress-free delivery for the speaker, session talks for DockerCon LIVE will be pre-recorded and played at a specific time during the conference. Speakers will be in chat with the audience during their session and be available to answer questions. The Docker team will help speakers prepare, record and review their content. We are excited to try this format and hope that it creates a great experience for speakers (new and seasoned) and attendees alike.

First timer? Fantastic! 

Everyone has to start somewhere and a virtual conference makes it a lot less intimidating to share your knowledge. If you aren’t sure what to talk about, think about an interesting problem you’ve solved, details of your day-to-day workflow, and ask a friend what they think you should talk about. Sometimes the best topics are things that a coworker finds interesting about your skills or role. 

What’s in it for you?

Sharing is Caring: The opportunity to share your experience with the broader community in person and onlineSpeaker’s SwagSupport in preparing your talkCommunity visibility to your expertise with DockerA recording of your talk that will be posted online 

Don’t miss this great opportunity to tell your story

Submit a CFP (or two) before the March 27th deadline here:
The post DockerCon LIVE with theCUBE: Call for Papers is Open appeared first on Docker Blog.

Docker Turns 7!

Since its introduction at PyCon in 2013, Docker has changed the way the world develops applications. And over the last 7 years, we’ve loved watching developers – new and seasoned – bring their ideas to life with Docker.

As is our tradition in the Docker community, we will be celebrating Docker’s birthday month with meetups (virtual + IRL), a special hands-on challenge, cake, and swag. Join us and celebrate your #myDockerBDay and the ways Docker and this community have impacted you – from the industry you work in, to an application you’ve built; from your-day-to-day workflow to your career. 

Learn more about the birthday celebrations below and share your #myDockerBday story with us on twitter or submit it here for a chance to win some awesome Docker swag.

Docker Birthday LIVE Show on March 26th, 9am – 12pm GMT-8

Celebrate Docker’s Birthday with a special 3-hour live show featuring exclusive conversations with the Docker team and Captains, open Q&A sessions, and prizes. To reserve a spot, sign up here. 

7th Birthday Challenge

Learn some of the Docker Captain’s favorite Tips + Tricks by completing 7 hands-on exercises. Earn a virtual badge for each exercise completed.

Learn Docker with Special Deals from the Docker Captains

This month we will be sharing exclusive discounts on Docker and Kubernetes learning materials from Docker Captains. You’ll see more on our blog and on twitter for updates – stay tuned! 

Celebrate at a Local Meetup

To be updated on the status of local birthday meetups, including when they may be rescheduled for, go here and join the chapter of interest.
The post Docker Turns 7! appeared first on Docker Blog.

Helping You and Your Development Team Build and Ship Faster

I remember the first time one of my co-workers told me about Docker. There is a longer story behind it, but it ended with “it was so easy and saved me so much time.” That compelled me to install Docker and try it for myself. Yup, she was right. Easy, simple, efficient. Sometime later, at a conference, while catching up with some friends who are developers, I asked them “how are things going?” The conversation eventually led to the topic of where things are going in the container space. I asked, “what’s the biggest issue you are having right now?” I expected the response to be something Kubernetes related. I was surprised the answer was “managing all the tech that gets my code deployed and running.” 

The above sentiment is echoed by our CEO, Scott Johnston, in this post. Millions of you use Docker today (check out the Docker Index for the latest usage stats), and we are so very thankful for the vibrant Docker Community. We heard from you that easily going from code to cloud is a problem, and Scott outlined the complexities. There are many choices across packaging, inner loop, packaging, registry, CI, security, CD, and public cloud runtimes. Those choices exist at almost every step, and once you make those choices, you have to stitch them together and manage them yourself. Things are a little easier if you are “all-in” on a particular public cloud provider.

However, what if you are a developer in a small team at a startup, and need something easy, fast, and efficient? Or, if you are a developer who is part of a team in a large organization that uses multiple clouds? Not so straightforward. 

This is where Docker will be spending our effort to help. Building on the foundational Docker tools, Docker Desktop and Docker Hub, to help you, the developer, get your work from SCM to public cloud runtime in the easiest, most efficient, and cloud-agnostic way. 

How are we going to do this? By focusing on developer experience through Docker Desktop, partnering with the ecosystem, and making Docker Hub the nexus for all the integrations, configuration, and management of the application components which constitute your apps and microservices. 

First, we will be expanding on the tooling and experiences in Docker Desktop to (a) accelerate the onboarding of new developers to development team processes and workflow, (b) help new developers onboard to developing with containers, and (c) provide features that help improve team collaboration and communication.

We believe a key way to help here is providing more features for the Docker CLI and Docker Desktop UI delivered from Docker Hub. We want to help you accomplish as much as possible in your local development environment without having to jump around interfaces. We also want you to be able to access and interact with services upstream (registry, CI, deployment to runtime) without having to leave the CLI. More to come here.

In addition, we will expand Docker Hub to help you manage all the application components you generate as part of development and deployment. Containers, serverless functions, <insert YAML here>, and all the lineage and metadata which these components generate. Docker Hub will be more than just a registry.

Speaking of “more than just a registry”, we will make Docker Hub the central point for the ecosystem of tools to partner with us in delivering you a great experience. Docker Hub will provide a range of pipeline options from high abstraction/opinion options, to construct and stitch yourself. We’ve already begun talking with some great partners in the industry and are excited to bring to you what we’ve been thinking here. The overall goal is to provide you solutions here that match your level of maturity or desired level of abstraction, all in a multi-cloud and vendor-neutral way. 

Across all of the above, open source will be at the center. Compose, Engine, and Notary will continue to be big contributors to our products, especially Docker Desktop. We will continue to build on these projects with the community, and you will see us contributing to other projects as well. 

We will deliver all of this through a monthly SaaS subscription model. We want you to be able to consume on your terms. 

Finally, we very much want your participation in how we think about helping you deliver the best products to your customers. Today, for the first time at Docker, we are launching a public roadmap. You can find it here. We invite you to participate by adding new feature ideas in the issues, up-voting other feature ideas you think are great (and down-voting ones you think are not), and helping us with prioritization. We are here for you and want to make sure we are as transparent as possible, while constantly listening to your feedback. 

We look forward to working with you to help Docker help you and your customers. If you would like to engage with us, please do so!

I’ll be doing an AMA about this strategy during our #myDockerBday Live Show on March 26, 2020. RSVP with your Docker ID here or on here. I’ll be speaking at the Docker Las Vegas Meetup on March 19th, 2020. Sign up here. Save the date for our virtual conference DockerCon Live on May 28, 2020. Sign up for updates here.Find me on GitHub through our public roadmap!

Thank you! Onward. 
The post Helping You and Your Development Team Build and Ship Faster appeared first on Docker Blog.