Coretainers

Most people, if not everyone, have seen the .NET Core demo’s in a Docker container on Linux by now. Some may even have experimented with Windows containers and the full fledged .NET framework as I showed at the SDN Event in September.
The thing is, that if you haven’t looked at containers by now, you’re in for a treat. Where it used to be quite hard to figure everything out for yourself, Microsoft announced a new way of integrating today and are taking it to the next level in Visual Studio 2017. Especially when you combine the power of containers with the flexibility of .NET Core.

Docker made easy

The combination of .NET Core and containers is very powerful. It gives a small iamge, which runs anywhere. You can literally ship your ‘machine’ and today it became even easier.
Starting with Visual Studio 2017, when you create a web application, you can enable Docker support from the box:

If you have Docker for Windows installed, you can get going. If not, install it first.
This will automatically generate several files for you:

• Dockerfile (where it all starts)
• docker-compose.yml (compose your containers, more on this in a future post)
• docker-compose.ci.build.yml (instructions for a CI build)

This will be all you need to get going. Really, that’s it. Just press ‘F5’ (or click the debug button, which now conventiently says ‘Docker’).
Visual Studio will now start building your application and put it into a container. The best part here is that it will link your source files on disk into the container by using volumes. If you inspect the docker-compose.vs.debug.yml file, you can clearly see the line that says:

- .:/app

what this line does, is that it links the current directory to the /app directory within the container. This means you can edit your code (and views) live, refresh your browser and it’ll update the app that you’re running within the container. The best thing is though, you can set breakpoints and they work just as though it was an application running on your local dev machine.

Mind you: if your debug experience didn’t go quite as planned and you run into an error. You might just see something like this in the output window:

ERROR: for awesomewebapp Cannot create container for service awesomewebapp: D: drive is not shared. Please share it in Docker for Windows Settings

Although the error message is quite verbose nowadays, right-click the Docker icon in your taskbar and go to settings. Now on the ‘Shared Drives’ tab, you can share the disk where your application resides.

Publish to Azure

Now where it get’s really awesome, is that starting today you can publish your container to Azure with a few simple clicks. If you right-click your project, you can press ‘Publish’. We all know this action from years of publishing web applications through WebDeploy - and we all know what joy that brought ;-)
We then got the ability to quickly select ‘host in Azure’ when we created the project and now we have this:

The settings are simple:

• Provide a unique name for your app
• Select an Azure Subscription
• Select a resource group, or create one
• Select or create an App Service Plan
• Select or create a Docker registry

I’m assuming you’re familiar with Azure terms such as the resource group and service plan, but the last one deserves a bit of explanation. A Docker registry is like a repository where your containers are stored. You can have both private and public registries - DockerHub being the most famous one. By default this will create a private registry where you can store the different versions of your container.

Press the ‘create’ button. Visual Studio and Azure will do the rest for you, it’s that simple.

Mind you: make sure that both your app service plan and registry are in the same Azure region. As of writing this post, only West US is supported. You can select the region from the ‘Services’ tab and then pressing the gears next to the app service or registry you’re creating.

Result

After pushing the ‘create’ button, my container got published to Azure and I’m able to access it from my browser. And although this is of course an awesome way to publish your application, this is probably not what you want from a DevOps perspective. You want to be able to make a change to the app, commit and push your changes to the repo and have an automated build/release pipeline to put your changes in production… and you can!
That’s what another new option in VS2017 does for you:

More on this feature in a later post though. For now, experiment with the containers and new features you have and I’ll show you how to automatically create a CI/CD pipeline from right within Visual Studio in a future post.