Our presence at Microsoft Build is more than just a showcase — it’s a portal to the future of application development. Visit our booth to interact with Docker experts, experience live demos, and explore the powerful capabilities of Docker Desktop and other Docker products. Whether you’re new to Docker or looking to deepen your expertise, our team is ready to help you unlock new opportunities in your development projects.

Sessions featuring Docker

• Optimizing the Microsoft Developer Experience with Docker: Dive into our partnership with Microsoft and learn how to leverage Docker in Azure, Windows, and Dev Box environments to streamline your development processes. This session is your key to mastering the inner loop of development with efficiency and innovation.
• Shifting Test Left with Docker and Microsoft: Learn how to address app quality challenges before the continuous integration stage using Tescontainers Cloud and Docker Debug. Discover how these tools aid in rapid and effective debugging, enabling you to streamline the debugging process for both active and halted containers and create testing efficiencies at scale.
• Securing Dockerized Apps in the Microsoft Ecosystem: Learn about Docker’s integrated tools for securing your software supply chain in Microsoft environments. This session is essential for developers aiming to enhance security and compliance while maintaining agility and innovation.
• Innovating the SDLC with Insights from Docker CTO Justin Cormack: In this interview, Docker’s CTO will share insights on advancing the SDLC through Docker’s innovative toolsets and partnerships. Watch Thursday 1:45pm PT from the Microsoft Build stage or our Featured Partner page. 
• Introducing the Next Generation of Windows on ARM: Experience a special session featuring Docker CTO Justin Cormack as he discusses Docker’s role in expanding the Windows on ARM64 ecosystem, alongside a Microsoft executive.

Where to find us

You can also visit us at Docker booth #FP29 to get hands-on experience and view demos of some of our newest solutions.

If you cannot attend in person, the MSBuild online experience is free. Explore our Microsoft Featured Partner page.

We hope you’ll be able to join us at Microsoft Build — in person or online — to explore how Docker and Microsoft are revolutionizing application development with innovative, secure, and AI-enhanced solutions. Whether you attend in person or watch the sessions on-demand, you’ll gain essential insights and skills to enhance your projects. Don’t miss this chance to be at the forefront of technology. We are eager to help you navigate the exciting future of AI-driven applications and look forward to exploring new horizons of technology together.

Learn more

• Explore our Microsoft Featured Partner page.
• New to Docker? Create an account. 
• Learn how Docker Build Cloud in Docker Desktop can accelerate builds.
• Secure your supply chain with Docker Scout in Docker Desktop.
• Start testing with Testcontainers Cloud.
• Subscribe to the Docker Newsletter.

Today at Microsoft Ignite, Microsoft’s Anthony Cangialosi and Sagar Lankala shared how Microsoft Dev Box and Docker Desktop can release developers’ reliance on physical workstations and intricate, hard-to-deploy application infrastructures. This collaborative effort focuses on streamlining onboarding to new projects while bolstering security and efficiency.

Consider the positive impact: 

• Improved developer productivity: Before this collaboration, setting up the development environment consumed valuable developer time. Now, with Docker and Microsoft’s collaboration, the focus shifts to boosting developer efficiency and productivity and concentrating on meaningful work rather than setup and configuration tasks.
• Streamlined administration: Previously, developers had to individually download Docker Desktop as a crucial part of their dev toolkit. Now, it’s possible to pre-configure and install Desktop, streamlining administrative tasks.
• Security at scale: Previously, acquiring necessary assets meant developers had to navigate internal or external sources. With our solution, you can ensure the requisite images/apps are readily available, enhancing security protocols.

Together, we’re delivering a turnkey solution designed to empower individual developers, small businesses, and enterprise development teams. This initiative is poised to expedite project onboarding, facilitating quick dives into new endeavors with unparalleled ease. Join us on this journey toward enhanced efficiency, productivity, and a smoother development experience.

We invite you to navigate to the Azure Marketplace to download the Docker Desktop-Dev Box compatible image and start developing in the cloud with a native experience. Additionally, this image can be activated with your current subscription, or you can buy a Docker Business subscription directly on Azure Marketplace.

Learn more

• Read New capabilities help simplify and streamline the experience with Microsoft Dev Box.
• Sign up for the Docker Desktop in Dev Box Preview.
• Purchase Docker Desktop Business Subscriptions through Azure Marketplace.
• Get the latest release of Docker Desktop.
• Have questions? The Docker community is here to help.
• New to Docker? Get started.

In May we announced the partnership between Docker and Microsoft to make it easier to deploy containerized applications from the Desktop to the cloud with Azure Container Instances (ACI). We are happy to let you know that all users of Docker Desktop now have the ACI experience available to them by default, allowing them to easily use existing Docker commands to deploy and manage containers running in ACI. 

As part of this I want to also call out a thank you to the MSFT team who have worked with us to make this all happen! That is a big thank you to Mike Morton, Karol Zadora-Przylecki, Brandon Waterloo, MacKenzie Olson, and Paul Yuknewicz.

Getting started with Docker and ACI 

As a new starter, to get going all you will need to do is upgrade your existing Docker Desktop to the latest stable version (2.5.0.0 or later), store your image on Docker Hub so you can deploy it (you can get started with Hub here) and then lastly you will need to create an ACI context to deploy it to. 

We have done a few blog posts now on the different types of things you can achieve with the ACI integration. 

• Getting started locally using Docker & ACI 
• Paul’s blog over at MSFT on getting started with Docker & ACI
• Deploying a Minecraft server & using volumes with ACI 
• Deploying to ACI as part of Github actions for CD 
• Docker & ACI integration into VSCode
• Dockers docs on the integration 

If you have other questions on the experience or would like some other guides then drop us a message in the Compose CLI repo so we can update our docs. 

What’s new in V1.0 

Since the last release of the CLI we have added a few new commands to make it easier to manage your working environment and also make it simpler for you to understand what you can clear up to save you money on resources you are not using.

To start we have add a volume inspect command alongside the volume create to allow you better management of your volumes: 

We are also very excited by our new top level prune command to allow you to better clear up your ACI working environment and manage your costs. 

docker prune --help

We have also added in a couple of interesting flags in here, we have the —dry-run flag to let you see what would be cleared up:

As you can see, this also lets you know the amount of compute resources you will be reclamining as well. At the end of a development session being able to do a force prune allows you to remove ‘all the things you have run’, giving you the confidence you won’t have left something running and get an unexpected bill. 

Lastly we have started to add a few more flags in based on your feedback, a couple of examples of these are the addition of the --format json and --quiet in commands ps, context ls, compose ls, compose ps, volume ls to output json or single IDs.

We are really excited about the new experience we have built with ACI, if you have any feedback on the experience or have ideas for other backends for the Compose CLI please let us know via our Public Roadmap

With Docker focusing on developers, we’ve been doubling down on the parts of Docker that developers love, like Desktop, Hub, and of course Compose. Millions of developers all over the world use Compose to develop their applications and love its simplicity but there was no simple way to get these applications running in the cloud.

Docker is working to make it easier to get code running in the cloud in two ways. First we moved the Compose specification into a community project. This will allow Compose to evolve with the community so that it may better solve more user needs and ensure that it is agnostic of runtime platform. Second, we’ve been working with Amazon and Microsoft on CLI integrations for Amazon ECS and Microsoft ACI that allow you to use docker compose up to deploy Compose applications directly to the cloud.

While implementing these integrations, we wanted to make sure that existing CLI commands were not impacted. We also wanted an architecture that would make it easy to add new backends and provide SDKs in popular languages. We achieved this with the following architecture:

The Node SDK and Compose CLI parts of this diagram are what we have open sourced today. This architecture is not final and we plan to merge the Compose CLI with the existing CLI at a later time.

Depending on the Docker Context that the user selects, the Compose CLI switches which backend is used for the command or API call. This allows us to pass commands which use existing contexts to the existing CLI transparently. The backend interface abstraction allows the implementation of a backend for any container runtime so that users can get the same Docker CLI UX they know and love for it along with the new APIs and SDK.

The Compose CLI can serve a gRPC API to provide similar functionality to that of the CLI commands. We chose to use gRPC as this allows us to generate high quality SDKs in popular languages like Node.js, Python, and Golang. While we currently only provide a Node SDK that supports single container management on ACI, there are plans to add Compose support, extend it to ECS and other backends, and add other language SDKs in the near future. The Node SDK is already used by VS Code to implement its Docker experience on ACI.

This work wouldn’t have been possible without help from our partners at Microsoft and AWS who helped us build the best possible experience for their respective platforms. Our team has enjoyed working with all of you! From Microsoft we’d specifically like to thank Mike Morton, Karol Zadora-Przylecki, Brandon Waterloo, MacKenzie Olson, and Paul Yuknewicz. From AWS we’d like to thank Carmen Puccio, David Killmon, Sravan Rengarajan, Uttara Sridhar, and David Duffey.

These tools are currently in beta so feedback and pull requests are welcome!

• Compose CLI source: https://github.com/docker/compose-cli
• Node SDK source: https://github.com/docker/node-sdk

To get started working with Compose in the Cloud you can download Docker Desktop here, get a free Hub account to deploy your images from here. Once you have you image saved to Docker Hub you will be able to deploy it to either ECS or ACI, to find out more about how to do this:

• Read about how to use the Amazon ECS integration here: https://docs.docker.com/engine/context/ecs-integration/
• Read about how to use the Microsoft ACI integration here: https://docs.docker.com/engine/context/aci-integration/

This means that these developers will be able to take advantage of WSL 2 and Docker’s integration, allowing developers to store their code within their WSL 2 distro and run the Docker CLI from within this distro. This removes the need to access files stored on the Windows host and provides significant performance improvements for users.

To find out more about using Docker Desktop with WSL 2, check out Simon’s full tips and tricks article. If you want to learn more about how Docker developed the WSL 2 backend you can have a look through our history of the integration or learn more about the implementation details of the backend check out one of Simon’s other blog posts. 

If you are enjoying Docker Desktop but have ideas of what we could do to make it better then please give us feedback. You can let us know what features you want to see next via our roadmap, including voting up GPU support for WSL 2. Or if you are new to Docker, download Docker Desktop and get started with WSL 2 today.

At Docker we are making the Developer Experience (DX) more simple. As an extension of that we want to provide the same beloved Docker experience that developers use daily and integrate it with the cloud. Microsoft’s Azure ACI provided an awesome platform to do just that.

In this tutorial, we take a look at running single containers and multiple containers with Compose in Azure ACI. We’ll walk you through setting up your docker context and even simplifying logging into Azure. At the end of this tutorial, you will be able to use familiar Docker commands to deploy your applications into your own Azure ACI account.

Prerequisites

To complete this tutorial, you will need:

• Docker installed on your development machine. You can download and install Docker Desktop Edge version 2.3.3.0 or later from the links below:
  • Docker Desktop for Mac
  • Docker Desktop for Windows
• Docker Hub account. Get your free account here.
• An Azure account. Sign up for free.
• Git installed on your development machine.
• An IDE or text editor to use for editing files. I would recommend VSCode

Run Docker Container on ACI

The integration with Azure ACI is very similar to working with local containers. The development teams have thought very deeply about the developer experience and have tried to make the UX for working with ACI as close as possible to working with local containers.

Let’s run a simple Nginx web server on Azure ACI.

Log into Azure

You do not need to have the Azure CLI installed on your machine to run Docker images in ACI. Docker takes care of everything.

The first thing you need to do is to login to Azure.

$ docker login azure

This will open a browser window which will allow you to login to Azure.

Select your account and login. Once you are logged in, you can close the browser window.

Azure ACI Context

Docker has the concept of a context. You can think of a context as a place where you can run docker containers.It’s a little more complicated than this but this is a good enough description for now. In this tutorial, we use our local context and the new ACI context.

Let’s first take a look at what contexts we currently have on our local development machine. Run the following command to see a list of contexts.

$ docker context list
NAME                TYPE                DESCRIPTION                               DOCKER ENDPOINT               KUBERNETES ENDPOINT                                 ORCHESTRATOR

default *           moby                Current DOCKER_HOST based configuration   unix:///var/run/docker.sock   https://kubernetes.docker.internal:6443 (default)   swarm

Depending on if you have already created another context, you should only see one context. This is the default context that points to your local Docker engine labeled as “moby”. You can identify the current context that will be used for docker commands by the “*” beside the name of the active context.

Now let’s create an ACI context that we can run containers with. We’ll use the create aci command to create our context. 

Let’s take a look at the help for creating an aci context.

$ docker context create aci --help
Create a context for Azure Container Instances

Usage:
  docker context create aci CONTEXT [flags]

Flags:
      --description string       Description of the context
  -h, --help                     help for aci
      --location string          Location (default "eastus")
      --resource-group string    Resource group
      --subscription-id string   Location

Global Flags:
      --config DIRECTORY   Location of the client config files DIRECTORY (default "/Users/peter/.docker")
  -c, --context string     context
  -D, --debug              enable debug output in the logs
  -H, --host string        Daemon socket(s) to connect to

Underneath the Flags section of the help, you can see that we have the option to set the location, resource-group, and subscription-id.

You can pass these flags into the create command. If you do not, the docker cli will ask you these questions in interactive mode. Let’s do that now.

$ docker context create aci myaci

The first thing the cli will ask is what subscription you would like to use. If you only have one then docker will use that one.

Using only available subscription : Azure subscription 1 (b3c07e4a-774e-4d8a-b071-xxxxxxxxxxxx)

Now we need to select the resource group we want to use. You can either choose one that has been previously created or choose “create a new resource group”. I’ll choose to create a new one.

Resource group "c3eea3e7-69d3-4b54-83cb-xxxxxxxxxxxx" (eastus) created

Okay, our aci context is set up. Let’s list our contexts.

$ docker context list

You should see the ACI context you just created.

Run Containers on ACI

Now that we have our ACI context set up, we can now run containers in the cloud. There are two ways to tell Docker which context you want your commands to be applied to. 

The first is to pass the –context flag. The other is to tell Docker which context we want to use with all subsequent commands by switching contexts. For now, let’s use the –context flag.

$ docker --context myaci run -d --name web -p 80:80 nginx
[+] Running 2/2
 ⠿ web                         Created                                                                           
 ⠿ single--container--aci      Done                                                                                
web

Here you can see that Docker interacted with ACI and created a container instance named “web” and started a single instance.

Open your Azure portal and navigate to container instances.

We can also run Docker CLI commands that you are already familiar with such as ps and logs.

Switch Contexts

Let’s take a look at our running containers. But before we do that let’s switch our active context to the ACI context we setup above so we do not have to keep typing –context with every command.

$ docker context use myaci

Now let’s run the ps command without passing the –context flag.

$ docker ps
CONTAINER ID        IMAGE               COMMAND             STATUS              
PORTS
web                            nginx                                                              Running             52.224.73.190:80->80/tcp

Nice, since we told Docker to use the myaci context, we see a list of containers running in our Azure account and not on our local machine.

Let’s make sure our container is running. Copy the IP address of the container from the above ps output and paste it into your browser address bar. You can see our Nginx web server running!

Like I mentioned above, we can also take a look at the container’s logs. 

$ docker logs web

To stop and remove the container, run the following command.

$ docker rm web

BOOM!

That was pretty easy and the integration is smooth. With a few docker commands that you are already familiar with and a couple new ones, we were able to run a container in ACI from our development machine pretty quickly and simply.

But we’re not done!

Docker Compose

We can also run multiple containers using Docker Compose. With the ACI integration, we now have the ability to run compose commands from the docker cli against ACI. Let’s do that next.

Fork the Code Repository

I’m using a simple Python Flask application that logs timestamps to a Redis database. Let’s fork the repository and then clone the git repository to your local machine.

Open your favorite browser and navigate to: https://github.com/pmckeetx/timestamper

Click on the “fork” button in the top right corner of the window. This will make a “copy” of the demo repository into your GitHub account.

On your forked version of the repository, click the green “Code” button and copy the github url.

Open up a terminal on your local machine and run the following git command to clone the repository to your local development machine.

Make sure you replace the <<github username>> with your GitHub username.

git clone git@github.com:<<github username>>/timestamper.git

Build and Run Locally

Make sure you are in the root directory for the timestamper project and follow the following steps to build the images and start the application with Docker Compose.

First we need to add your Docker ID to the image in our docker-compose.yml file. Open the docker-compose.yml file in an editor and replace <<username>> with your Docker ID.

Next, we need to make sure we are using the local Docker context.

$ docker context use default

Now we can build and start our application using docker-compose.

$ docker-compose up --build
Building frontend
Step 1/7 : FROM python:3.7-alpine
 ---> 6ca3e0b1ab69
Step 2/7 : WORKDIR /app
...
frontend_1  |  * Running on http://0.0.0.0:5000/ (Press CTRL+C to quit)
frontend_1  |  * Restarting with stat
frontend_1  |  * Debugger is active!
frontend_1  |  * Debugger PIN: 622-764-646

Docker will build our timestamper image and then run the Redis database and our timestamper containers.

Navigate to http://localhost:5000 and click the Timestamp! button a couple of times.

Compose on ACI

Now let’s run our application on ACI using the new docker compose integration.

We’ll first need to push our image to Docker Hub so ACI can pull the image and run it. Run the following command to push your image to your Docker Hub account.

$ docker-compose push
Pushing frontend (pmckee/timestamper:latest)...
The push refers to repository [docker.io/pmckee/timestamper]
6e899582609b: Pushed
...
50644c29ef5a: Layer already exists
latest: digest: sha256:3ce2607f101a381b36beeb0ca1597cce9925d17a0f826cac0f7e0365386a3042 size: 2201

Now that our image is on Hub, we can use compose to run the application on ACI.

First let’s switch to our ACI context.

$ docker context use myaci

Remember, to see a list of contexts and which is being used, you can run the list contexts command.

$ docker context list

Okay, now that we are using the ACI context, let’s start our application in the cloud.

$ docker compose up
[+] Running 3/3
 ⠿ timestamper     Created
 ⠿ frontend        Done
 ⠿ backend         Done

Let’s verify that our application is up and running. To get the IP address of our frontend, let’s list our running containers.

$ docker ps
CONTAINER ID           IMAGE                COMMAND             STATUS              PORTS

timestamper_frontend       pmckee/timestamper                       
Running             40.71.234.128:5000->5000/tcp

timestamper_backend         redis:alpine                             
Running

Copy the IP address and port listed above and paste into your favorite browser.

Let’s take a look at the logs for our Redis container.

$ docker logs timestamper_backend
1:C 13 Jul 2020 18:21:12.044 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
...
1:M 13 Jul 2020 18:21:12.046 # Server initialized
1:M 13 Jul 2020 18:21:12.047 * Ready to accept connections

Yes, sir! That is a Redis container running in ACI! Pretty cool.

After you play around a bit, you can take down the compose application by running compose down.

$ docker compose down

Conclusion

We saw how simple it is now to run a single container or run multiple containers using Compose on Azure with our ACI integration. If you want to help influence or suggest features, you can do that on our public Roadmap.

If you want to learn more about Compose and all the cool things that are happening around the OpenSource initiative, please checkout Awesome Compose and the OpenSource Compose specification. 

The new Docker and Microsoft ACI experience allows developers to easily move between working locally and in the Cloud with ACI; using the same Docker CLI experience used today! We have done this by expanding the existing docker context command to now support ACI as a new backend. We worked with Microsoft to target ACI as we felt its performance and ‘zero cost when nothing is running’ made it a great place to jump into running containers in the cloud.

ACI is a Microsoft serverless container solution for running a single Docker container or a service composed of a group of multiple containers defined with a Docker Compose file. Developers can run their containers in the cloud without needing to set up any infrastructure and take advantage of features such as mounting Azure Storage and GitHub repositories as volumes. For production cases, you can leverage Docker commands inside of an automated CI/CD flow.

Thanks to this new ACI context, you can now easily run a single container in Microsoft ACI using the docker run command but also multi-container applications using the docker compose up command.

This new experience is now available as part of Docker Desktop Edge 2.3.2 . To get started, simply download the latest Edge release or update if you are already on Desktop Edge.

Create an ACI context

Once you have the latest version, you will need to get started by logging into an Azure account. If you don’t have one you can sign up for one with $200 of credit for 30 days to try out the experience here. Once you have an account you can get started in the Docker CLI by logging into Azure: 

This will load up the Azure authentication page allowing you to login using your credentials and Multi-Factor Authentication (MFA). Once you have authenticated you will see a login succeeded in the CLI, you are now ready to create your first ACI context. To do this you will need to use the docker context create aci command. You can either pass in an Azure subscription and resource group to the command or use the interactive CLI to choose them, or even create a resource group. For this example I will deploy to my default Resource Group.

My context is then created and I can check this using docker context ls

Single Container Application Example

Before I use this context, I am now going to test my application locally to check everything is working as expected. I am just going to use a very simple web server with a static HTML web page on.

I start by building my image and then running it locally:

Getting ready to run my container on ACI, I now push my image to Dockerhub using docker push bengotch/simplewhale and then change my context using docker context use myacicontext. From that moment, all the subsequent commands we will execute will be run against this ACI context.

I can check no containers are running in my new context using docker ps. Now to run my container on ACI I only need to  repeat the very same  docker run command as earlier. I can see my container is running and use the IP address to access my container running in ACI!

I can now remove my container using docker rm. Note that once the command has been executed, nothing is running on ACI and all resources are removed from ACI – resulting in no ongoing cost.

Multi-Container Application Example

With the new Docker ACI experience we can also deploy multi-container applications using Docker Compose. Let’s take a look at a simple 3 part application with a Java backend, Go frontend and postgres DB:

To start, I swap to my default (local) context and run a docker-compose up to run my app locally. 

I then check to see that I can access it and see it running locally:

Now I swap over to my ACI context using docker context use myacicontext and run my app again. This time I can use the new syntax docker compose up (note the lack of a ‘-’ between docker and compose).

And I can then go and see if this is working using its public IP address:

I have now run both my single container locally and in the cloud, along with running my multi-container app locally and in the cloud – all using the same artifacts and using the same Docker experience that I know and love!

Try out the new experience!

To try out the new experience, download the latest version of Docker Desktop Edge today, you can raise bugs on our beta repo and let us know what other features you would like to see integrated by adding an issue to the Docker Roadmap!

One of the biggest developments for developers using Windows 10 is the release of WSL 2 (Windows Subsystem for Linux). Instead of using a translation layer to convert Linux kernel calls into Windows calls, WSL 2 now offers its own isolated Linux kernel running on a thin version of the Hyper-V hypervisor. Check out Simon Ferquel’s session on WSL 2 as well as Paul Yuknewicz’s session on apps running in Azure. Be sure to check out these valuable sessions on using Docker with Microsoft tools and technologies.

Docker Desktop + WSL 2 Integration Deep Dive

Simon Ferquel – Docker

Simon’s session provides a deep dive on how Docker Desktop on Windows works with WSL 2 to provide a better developer experience. This presentation will give you a better understanding of how Docker Desktop and WSL 2 architectures fit together and the challenges we faced with the integration.

Become a Docker Power User with Microsoft Visual Studio Code

Brian Christner – 56K.Cloud

Docker Captain, Brian Christner, does an excellent job on showing you how to unlock the full potential of using Microsoft Visual Studio Code (VS Code) and Docker Desktop to turn you into a Docker Power User. He covers and expands on utilizing the VS Code Docker plugin to take your project and Docker skills to the next level. This session has some very good demos including learning how to bootstrap new projects, quickly write Dockerfiles utilizing templates, build, run, and interact with containers all from VS Code.

From Fortran on the Desktop to Kubernetes in the Cloud: A Windows Migration Story

Elton Stoneman – Sixeyed Consulting

Elton is a Docker Captain and a Microsoft Azure MVP. Moving legacy Windows apps to the cloud is a very hot topic amongst IT shops that are looking to some obvious approaches to modernization. Elton walks through the processes and practicalities of taking an older Windows app, making it run in containers with Kubernetes, and then building a simple API wrapper to host the whole stack as a cloud-based SaaS product. 

Deep Dive: Developing Containerized Apps for Azure

Paul Yuknewicz – Microsoft

Join Paul from the MS product team for a closer look into building modern cloud applications using VS Code, Docker Desktop, WSL2 and more. In this demo-rich session, Paul talks about how containers make modern applications better, the stages of moving to the cloud, and covers developer tools needed including sneak peaks of future Microsoft tools that enhance developer productivity. 

If you are ready to get started with Docker, we offer free plans for individual developers and teams just starting out. Get started with Docker today.

Do you remember the first time you used Docker? I do. It was about six years ago and like many folks at the time it looked like this:

docker run -it redis

I was not using Redis at the time but it seemed like a complicated enough piece of software to put this new technology through its paces. A quick Docker image pull and it was up and running. It seemed like magic. Shortly after that first Docker command I found my way to Docker Compose. At this point I knew how to run Redis and the docs had an example Python Flask application. How hard could it be to put the two together?

version: '3'
services:
  web:
    build: .
    ports:
      - "5000:5000"
  redis:
    image: “redis”

I understood immediately how Docker could help me shorten my developer “commute.” All the time I spent doing something else just to get to the work I wanted to be doing. It was awesome! 

As time passed, unfortunately my commute started to get longer again. Maybe I needed to collaborate with a colleague or get more resources then I had locally. Ok, I can run Docker in the cloud, let me see how I can get a Docker Engine. Am I going to use another tool, set up one manually, automate the whole thing? What about updates? Maybe I should use one of the managed container services? Well then I’d have to use a different CLI and perhaps a different file format. That would be totally different from what I’m using locally. Seeing my commute bloat substantially, my team and I began to work on a solution and went on a path to find collaborators with the cloud service providers.  

I am excited to finally be able to talk about the result of a collaborative set of ideas that we’ve been working on for a year to once again shorten your developer commute. Docker is expanding our strategic partnership with Microsoft and integrating the Docker experience you already know and love with Azure Container Instances (ACI). 

What does that mean for you? The same workflow in Docker Desktop and with the Docker CLI and the tools you already have with all the container compute you could want. No infrastructure to manage. No clusters to provision. When it is time to go home, docker rm will stop all the meters. We will be giving an early preview of this work on stage at DockerCon tomorrow; so please register here and watch the keynote. 

Let me give you a sense of how simple the process will be. You will even be able to log into Azure directly from the Docker CLI so you can connect to your Azure account. The login experience will feel very familiar, and odds are you have used it before for other services:

docker login azure

Once you are logged in, you just need to tell Docker that you want to use something besides the local engine. This is my favorite part– it is where in my opinion the magic lives. About a year ago we introduced Docker Context. Originally, it let you switch between engines (local or remote), Swarm, and Kubernetes. When it launched, I thought we needed to make this happen for any service that can run a container. If you want to shorten a developer’s commute, this is the way to do it.

docker context create aci-westus aci --aci-subscription-id xxx --aci-resource-group yyy --aci-location westus

All you need is a set of Azure credentials. If you have an Azure resource group you want to use you will be able to select it or we can create one for you. Once you have your Docker Context, you can tell Docker to switch to using it by default.

docker context use aci-westus

Once you have the context selected, it is just Docker. You can run individual containers. And you can run multiple containers with Docker Compose; look at Awesome Compose to find a compose file to try out. Or fire up Visual Studio Code and get back to doing what you wanted to do– writing code. As part of this strategic partnership with Microsoft, we are working closing with the Visual Studio Code teams to make sure the Docker experience is awesome.

Docker and Microsoft’s partnership has a long history. I am proud to be able to talk about what I have been working on for the last year. Together we are working on getting a beta ready for release in the second half of 2020. You can register for the beta here. 

For more information, check out this blog post by Paul Yuknewicz, Group Product Manager, Azure Developer Tools or read the press release.

If there are other providers you would like to see come on board to bring the simplicity of the Docker experience to the cloud, then please let us know on our public roadmap.  I am looking forward to telling you more about what else we have been working on soon!

Docker Enterprise Edition Preview

To experiment with the new Docker and Windows features, a preview build of Docker is required. Here’s how to install it on Windows Server 1709 (this will also work on Insider builds):

Install-Module DockerProvider
    Install-Package Docker -ProviderName DockerProvider -RequiredVersion preview

To run Docker Windows containers in production on any Windows Server version, please stick to Docker EE 17.06.

Docker Linux Containers on Windows

A key focus of Windows Server version 1709 is support for Linux containers on Windows. We’ve already blogged about how we’re supporting Linux containers on Windows with the LinuxKit project.

To try Linux Containers on Windows Server 1709, install the preview Docker package and enable the feature. The preview Docker EE package includes a full LinuxKit system (all 13MB of it) for use when running Docker Linux containers.

[Environment]::SetEnvironmentVariable("LCOW_SUPPORTED", "1", "Machine")
    Restart-Service Docker

To disable, just remove the environment variable:

[Environment]::SetEnvironmentVariable("LCOW_SUPPORTED", $null, "Machine")
    Restart-Service Docker

Docker Linux containers on Windows is in preview, with ongoing joint development by Microsoft and Docker. Linux Containers is also available on Windows 10 version 1709 (“Creators Update 2”).

Docker ingress mode service publishing on Windows

Parity with Linux service publishing options has been highly requested by Windows customers. Adding support for service publishing using ingress mode in Windows Server 1709 enables use of Docker’s routing mesh, allowing external endpoints to access a service via any node in the swarm regardless of which nodes are running tasks for the service.

These networking improvements also unlock VIP-based service discovery when using overlay networks so that Windows users are not limited to DNS Round Robin.

Check out the corresponding post on the Microsoft Virtualization blog for details on the improvements.

Named pipes in Windows containers

A common and powerful Docker pattern is to run Docker containers that use the Docker API of the host that the container is running on, for example to start more Docker containers or to visualize the containers, networks and volumes on the Docker host. This pattern lets you ship, in a container, software that manages or visualizes what’s going on with Docker. This is great for building software like Docker Universal Control Plane.

Running Docker on Linux, the Docker API is usually hosted on Unix domain socket, and since these are in the filesystem namespace, sockets can be bind-mounted easily into containers. On Windows, the Docker API is available on a named pipe. Previously, named pipes where not bind-mountable into Docker Windows containers, but starting with Windows 10 and Windows Server 1709, named pipes can now bind-mounted.

Jenkins CI is a neat way to demonstrate this. With Docker and Windows Server 1709, you can now:

1. Run Jenkins in a Docker Windows containers (no more hand-installing and maintaining Java, Git and Jenkins on CI machines)
2. Have that Jenkins container build Docker images and run Docker CI/CD jobs on the same host

I’ve built a Jenkins sample image (Windows Server 1709 required) that uses the new named-pipe mounting feature. To run it, simple start a container, grab the initial password and visit port 8080. You don’t have to setup any Jenkins plugins or extra users:

> docker run -d -p 8080:8080 -v \\.\pipe\docker_engine:\\.\pipe\docker_engine friism/jenkins
    3c90fdf4ff3f5b371de451862e02f2b7e16be4311903649b3fc8ec9e566774ed
    > docker exec 3c cmd /c type c:\.jenkins\secrets\initialAdminPassword
    <password>

Now create a simple freestyle project and use the “Windows Batch Command” build step. We’ll build my fork of the Jenkins Docker project itself:

git clone --depth 1 --single-branch --branch add-windows-dockerfile https://github.com/friism/docker-3 %BUILD_NUMBER%
    cd %BUILD_NUMBER%
    docker build -f Dockerfile-windows -t jenkins-%BUILD_NUMBER% .
    cd ..
    rd /s /q %BUILD_NUMBER%

Hit “Build Now” and see Jenkins (running in a container) start to build a CI job to build a container image on the very host it’s running on!

Smaller Windows base images

When Docker and Microsoft launched Windows containers last year, some people noticed that Windows container base images are not as small as typical Linux ones. Microsoft has worked very hard to winnow down the base images, and with 1709, the Nanoserver download is now about 70MB (200MB expanded on the filesystem).

One of the things that’s gone from the Nanoserver Docker image is PowerShell. This can present some challenges when authoring Dockerfiles, but multi-stage builds make it fairly easy to do all the build and component assembly in a Windows Server Core image, and then move just the results into a nanoserver image. Here’s an example showing how to build a minimal Docker image containing just the Docker CLI:

# escape=`
    FROM microsoft/windowsservercore as builder
    SHELL ["powershell", "-Command", "$ErrorActionPreference = 'Stop'; $ProgressPreference = 'SilentlyContinue';"]
    RUN Invoke-WebRequest -Uri https://download.docker.com/win/static/test/x86_64/docker-17.09.0-ce-rc1.zip -OutFile 'docker.zip'
    RUN Expand-Archive -Path docker.zip -DestinationPath .

    FROM microsoft/nanoserver
    COPY --from=builder ["docker\\docker.exe", "C:\\Program Files\\docker\\docker.exe"]
    RUN setx PATH "%PATH%;C:\Program Files\docker"
    ENTRYPOINT ["docker"]

You now get the best of both worlds: Easy-to-use, full-featured build environment and ultra-small and minimal runtime images that deploy and start quickly, and have minimal exploit surface area. Another good example of this pattern in action are the .NET Core base images maintained by the Microsoft .NET team.

Summary

It’s hard to believe that Docker Windows containers GA’d on Windows Server 2016 and Windows 10 just one year ago. In those 12 months, we’ve seen lots of adoption by the Docker community and lots of uptake with customers and partners. The latest release only adds more functionality to smooth the user experience and brings Windows overlay networking up to par with Linux, with smaller container images and with support for bind-mounting named pipes into containers.

To learn more about Docker solutions for IT:

• Learn more about Docker for Windows
• Visit IT Starts with Docker and sign up for ongoing alerts
• Learn more about Docker Enterprise Edition
• Sign up for upcoming webinars

Exciting new things for #Docker with @Windows Server 1709
Click To Tweet