Trying out new .NET Core Alpine Docker Images

I blogged recently about optimizing .NET and ASP.NET Docker files sizes. .NET Core 2.0 has previously been built on a Debian image but today there is preview image with .NET Core 2.1 nightlies using Alpine. You can read about the announcement here abou…

Docker ContainersI blogged recently about optimizing .NET and ASP.NET Docker files sizes. .NET Core 2.0 has previously been built on a Debian image but today there is preview image with .NET Core 2.1 nightlies using Alpine. You can read about the announcement here about this new Alpine preview image. There's also a good rollup post on .NET and Docker.

They have added two new images:

  • 2.1-runtime-alpine
  • 2.1-runtime-deps-alpine

Alpine support is part of the .NET Core 2.1 release. .NET Core 2.1 images are currently provided at the microsoft/dotnet-nightly repo, including the new Alpine images. .NET Core 2.1 images will be promoted to the microsoft/dotnet repo when released in 2018.

NOTE: The -runtime-deps- image contains the dependancies needed for a .NET Core application, but NOT the .NET Core runtime itself. This is the image you'd use if your app was a self-contained application that included a copy of the .NET Core runtime. This is apps published with -r [runtimeid]. Most folks will use the -runtime- image that included the full .NET Core runtime. To be clear:

- The runtime image contains the .NET Core runtime and is intended to run Framework-Dependent Deployed applications - see sample

- The runtime-deps image contains just the native dependencies needed by .NET Core and is intended to run Self-Contained Deployed applications - see sample

It's best with .NET Core to use multi-stage build files, so you have one container that builds your app and one that contains the results of that build. That way you don't end up shipping an image with a bunch of SDKs and compilers you don't need.

NOTE: Read this to learn more about image versions in Dockerfiles so you can pick the right tag and digest for your needs. Ideally you'll pick a docker file that rolls forward to include the latest servicing patches.

Given this docker file, we build with the SDK image, then publish, and the result is about 219megs.

FROM microsoft/dotnet:2.0-sdk as builder  


RUN mkdir -p /root/src/app/dockertest
WORKDIR /root/src/app/dockertest

COPY dockertest.csproj .
RUN dotnet restore ./dockertest.csproj

COPY . .
RUN dotnet publish -c release -o published

FROM microsoft/dotnet:2.0.0-runtime

WORKDIR /root/
COPY --from=builder /root/src/app/dockertest/published .
ENV ASPNETCORE_URLS=http://+:5000
EXPOSE 5000/tcp
CMD ["dotnet", "./dockertest.dll"]

Then I'll save this as Dockerfile.debian and build like this:

> docker build . -t shanselman/dockertestdeb:0.1 -f dockerfile.debian

With a standard ASP.NET app this image ends up being 219 megs.

Now I'll just change one line, and use the 2.1 alpine runtime

FROM microsoft/dotnet-nightly:2.1-runtime-alpine

And build like this:

> docker build . -t shanselman/dockertestalp:0.1 -f dockerfile.alpine

and compare the two:

> docker images | find /i "dockertest"

shanselman/dockertestalp 0.1 3f2595a6833d 16 minutes ago 82.8MB
shanselman/dockertestdeb 0.1 0d62455c4944 30 minutes ago 219MB

Nice. About 83 megs now rather than 219 megs for a Hello World web app. Now the idea of a microservice is more feasible!

Please do head over to the GitHub issue here https://github.com/dotnet/dotnet-docker-nightly/issues/500 and offer your thoughts and results as you test these Alpine images. Also, are you interested in a "-debian-slim?" It would be halfway to Alpine but not as heavy as just -debian.

Lots of great stuff happening around .NET and Docker. Be sure to also check out Jeff Fritz's post on creating a minimal ASP.NET Core Windows Container to see how you can squish .(full) Framework applications running on Windows containers as well. For example, the Windows Nano Server images are just 93 megs compressed.


Sponsor: Get the latest JetBrains Rider preview for .NET Core 2.0 support, Value Tracking and Call Tracking, MSTest runner, new code inspections and refactorings, and the Parallel Stacks view in debugger.



© 2017 Scott Hanselman. All rights reserved.
     

Docker and Linux Containers on Windows, with or without Hyper-V Virtual Machines

Containers are lovely, in case you haven’t heard. They are a nice and clean way to get a reliable and guaranteed deployment, no matter the host system. If I want to run my my ASP.NET Core application, I can just type “docker run -p 5000:80 shanselman/…

Containers are lovely, in case you haven't heard. They are a nice and clean way to get a reliable and guaranteed deployment, no matter the host system.

If I want to run my my ASP.NET Core application, I can just type "docker run -p 5000:80 shanselman/demos" at the command line, and it'll start up! I don't have any concerns that it won't run. It'll run, and run well.

Some containers naysayers say , sure, we could do the same thing with Virtual Machines, but even today, a VHD (virtual hard drive) is rather an unruly thing and includes a ton of overhead that a container doesn't have. Containers are happening and you should be looking hard at them for your deployments.

docker run shanselman/demos

Historically on Windows, however, Linux Containers run inside a Hyper-V virtual machine. This can be a good thing or a bad thing, depending on what your goals are. Running Containers inside a VM gives you significant isolation with some overhead. This is nice for Servers but less so for my laptop. Docker for Windows hides the VM for the most part, but it's there. Your Container runs inside a Linux VM that runs within Hyper-V on Windows proper.

HyperV on Windows

With the latest version of Windows 10 (or 10 Server) and the beta of Docker for Windows, there's native Linux Container support on Windows. That means there's no Virtual Machine or Hyper-V involved (unless you want), so Linux Containers run on Windows itself using Windows 10's built in container support.

For now you have to switch "modes" between Hyper V and native Containers, and you can't (yet) run Linux and Windows Containers side by side. The word on the street is that this is just a point in time thing, and that Docker will at some point support running Linux and Windows Containers in parallel. That's pretty sweet because it opens up all kinds of cool hybrid scenarios. I could run a Windows Server container with an .NET Framework ASP.NET app that talks to a Linux Container running Redis or Postgres. I could then put them all up into Kubernetes in Azure, for example.

Once I've turned Linux Containers on Windows on within Docker, everything just works and has one less moving part.

Linux Containers on Docker

I can easily and quickly run busybox or real Ubuntu (although Windows 10 already supports Ubuntu natively with WSL):

docker run -ti busybox sh

More useful even is to run the Azure Command Line with no install! Just "docker run -it microsoft/azure-cli" and it's running in a Linux Container.

Azure CLI in a Container

I can even run nyancat! (Thanks Thomas!)

docker run -it supertest2014/nyan

nyancat!

Speculating - I look forward to the day I can run "minikube start --vm-driver="windows" (or something) and easily set up a Kubernetes development system locally using Windows native Linux Container support rather than using Hyper-V Virtual Machines, if I choose to.


Sponsor: Why miss out on version controlling your database? It’s easier than you think because SQL Source Control connects your database to the same version control tools you use for applications. Find out how.


© 2017 Scott Hanselman. All rights reserved.
     

Optimizing ASP.NET Core Docker Image sizes

There is a great post from Steve Laster in 2016 about optimizing ASP.NET Docker Image sizes. Since then Docker has added multi-stage build files so you can do more in one Dockerfile…which feels like one step even though it’s not. Containers are about…

ASP.NET Core on KubernetesThere is a great post from Steve Laster in 2016 about optimizing ASP.NET Docker Image sizes. Since then Docker has added multi-stage build files so you can do more in one Dockerfile...which feels like one step even though it's not. Containers are about easy and reliable deployment, and they're also about density. You want to use as little memory as possible, sure, but it also is nice to make them as small as possible so you're not spending time moving them around the network. The size of the image file can also affect startup time for the container. Plus it's just tidy.

I've been building a little 6 node Raspberry Pi (ARM) Kubenetes Cluster on my desk - like you do - this week, and I noticed that my image sizes were a little larger than I'd like. This is a bigger issue because it's a relatively low-powered system, but again, why carry around x unnecessary megabytes if you don't have to?

Alex Ellis has a great blog on building .NET Core apps for Raspberry Pi along with a YouTube video. In his video and blog he builds a "Console.WriteLine()" console app, which is great for OpenFaas (open source serverless platform) but I wanted to also have ASP.NET Core apps on my Raspberry Pi k8s cluster. He included this as a "challenge" in his blog, so challenge accepted! Thanks for all your help and support, Alex!

ASP.NET Core on Docker (on ARM)

First I make a basic ASP.NET Core app. I could do a Web API, but this time I'll do an MVC one with Razor Pages. To be clear, they are the same thing just with different starting points. I can always add pages or add JSON to either, later.

I start with "dotnet new mvc" (or dotnet new razor, etc). I'm going to be running this in Docker, managed by Kuberenetes, and while I can always change the WebHost in Program.cs to change how the Kestrel web server starts up like this:

WebHost.CreateDefaultBuilder(args)

.UseUrls(http://*:5000;http://localhost:5001;https://hostname:5002)

For Docker use cases it's easier to change the listening URL with an Environment Variable. Sure, it could be 80, but I like 5000. I'll set the ASPNETCORE_URLS environment variable to http://+:5000 when I make the Dockerfile.

Optimized MultiStage Dockerfile for ASP.NET

There's a number of "right" ways to do this, so you'll want to think about your scenarios. You'll see below that I'm using ARM (because Raspberry Pi) so if you see errors running your container like "qemu: Unsupported syscall: 345" then you're trying to run an ARM image on x86/x64. I'm going to be building an ARM container from Windows but I can't run it here. I have to push it to a container registry and then tell my Raspberry Pi cluster to pull it down and THEN it'll run, over there.

Here's what I have so far. NOTE there are some things commented out, so be conscious. This is/was a learning exercise for me. Don't you copy/paste unless you know what's up! And if there's a mistake, here's a GitHub Gist of my Dockerfile for you to change and improve.

It's important to understand that .NET Core has an SDK with build tools and development kits and compilers and stuff, and then it has a runtime. The runtime doesn't have the "make an app" stuff, it only has the "run an app stuff." There is not currently an SDK for ARM so that's a limitation that we are (somewhat elegantly) working around with the multistage build file. But, even if there WAS an SDK for ARM, we'd still want to use a Dockerfile like this because it's more efficient with space and makes a smaller image.

Let's break this down. There are two stages. The first FROM is the SDK image that builds the code. We're doing the build inside Docker - which is lovely, and  great reliable way to do builds.

PRO TIP: Docker is smart about making intermediate images and doing the least work, but it's useful if we (the authors) do the right thing as well to help it out.

For example, see where we COPY the .csproj over and then do a "dotnet restore"? Often you'll see folks do a "COPY . ." and then do a restore. That doesn't allow Docker to detect what's changed and you'll end up paying for the restore on EVERY BUILD.

By making this two steps - copy the project, restore, copy the code, this means your "dotnet restore" intermediate step will be cached by Docker and things will be WAY faster.

After you build, you'll do a publish. If you know the destination like I do (linux-arm) you can do a RID (runtime id) publish that is self-contained with -r linux-arm (or debian, or whatever) and you'll get a complete self-contained version of your app.

Otherwise, you can just publish your app's code and use a .NET Core runtime image to run it. Since I'm using a complete self-contained build for this image, it would be overkill to ALSO include the .NET runtime. If you look at the Docker hub for Microsoft/dotnet You'll see images called "deps" for "dependencies." Those are images that sit on top of debian that include the things .NET needs to run - but not .NET itself.

The stack of images looks generally like this (for example)

  • FROM debian:stretch
  • FROM microsoft/dotnet:2.0-runtime-deps
  • FROM microsoft/dotnet:2.0-runtime

So you have your base image, your dependencies, and your .NET runtime. The SDK image would include even more stuff since it needs to build code. Again, that's why we use that for the "as builder" image and then copy out the results of the compile and put them in another runtime image. You get the best of all worlds.

FROM microsoft/dotnet:2.0-sdk as builder  


RUN mkdir -p /root/src/app/aspnetcoreapp
WORKDIR /root/src/app/aspnetcoreapp

#copy just the project file over
# this prevents additional extraneous restores
# and allows us to re-use the intermediate layer
# This only happens again if we change the csproj.
# This means WAY faster builds!
COPY aspnetcoreapp.csproj .
#Because we have a custom nuget.config, copy it in
COPY nuget.config .
RUN dotnet restore ./aspnetcoreapp.csproj

COPY . .
RUN dotnet publish -c release -o published -r linux-arm

#Smaller - Best for apps with self-contained .NETs, as it doesn't include the runtime
# It has the *dependencies* to run .NET Apps. The .NET runtime image sits on this
FROM microsoft/dotnet:2.0.0-runtime-deps-stretch-arm32v7

#Bigger - Best for apps .NETs that aren't self-contained.
#FROM microsoft/dotnet:2.0.0-runtime-stretch-arm32v7

# These are the non-ARM images.
#FROM microsoft/dotnet:2.0.0-runtime-deps
#FROM microsoft/dotnet:2.0.0-runtime

WORKDIR /root/
COPY --from=builder /root/src/app/aspnetcoreapp/published .
ENV ASPNETCORE_URLS=http://+:5000
EXPOSE 5000/tcp
# This runs your app with the dotnet exe included with the runtime or SDK
#CMD ["dotnet", "./aspnetcoreapp.dll"]
# This runs your self-contained .NET Core app. You built with -r to get this
CMD ["./aspnetcoreapp"]

Notice also that I have a custom nuget.config, so if you do also you'll need to make sure that's available at build time for dotnet restore to pick up all packages.

I've included by commented out a bunch of the FROMs in the second stage. I'm using just the ARM one, but I wanted you to see the others.

Once we have the code we build copied into our runtime image, we set our environment variable so our all listens on port 5000 internally (remember that from above?) Then we run our app. Notice that you can run it with "dotnet foo.dll" if you have the runtime, but if you are like me and using a self-contained build, then you'll just run "foo."

To sum up:

  • Build with FROM microsoft/dotnet:2.0-sdk as builder
  • Copy the results out to a runtime
  • Use the right runtime FROM for you
    • Right CPU architecture?
    • Using the .NET Runtime (typical) or using a self-contained build (less so)
  • Listening on the right port (if a web app)?
  • Running your app successfully and correctly?

Optimizing a little more

There are a few pre-release "Tree Trimming" tools that can look at your app and remove code and binaries that you are not calling. I included Microsoft.Packaging.Tools.Trimming as well to try it out and get even more unused code out of my final image by just adding a package to my project.

Step 8/14 : RUN dotnet publish -c release -o published -r linux-arm /p:LinkDuringPublish=true

---> Running in 39404479945f
Microsoft (R) Build Engine version 15.4.8.50001 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

Trimmed 152 out of 347 files for a savings of 20.54 MB
Final app size is 33.56 MB
aspnetcoreapp -> /root/src/app/aspnetcoreapp/bin/release/netcoreapp2.0/linux-arm/aspnetcoreapp.dll
Trimmed 152 out of 347 files for a savings of 20.54 MB
Final app size is 33.56 MB

If you run docker history on your final image you can see exactly where the size comes from. If/when Microsoft switches from a Debian base image to an Alpine one, this should get even smaller.

C:\Users\scott\Desktop\k8s for pi\aspnetcoreapp>docker history c60

IMAGE CREATED CREATED BY SIZE COMMENT
c6094ca46c3b 3 minutes ago /bin/sh -c #(nop) CMD ["dotnet" "./aspnet... 0B
b7dfcf137587 3 minutes ago /bin/sh -c #(nop) EXPOSE 5000/tcp 0B
a5ba51b91d9d 3 minutes ago /bin/sh -c #(nop) ENV ASPNETCORE_URLS=htt... 0B
8742269735bc 3 minutes ago /bin/sh -c #(nop) COPY dir:cc64bd3b9bacaeb... 56.5MB
28c008e38973 3 minutes ago /bin/sh -c #(nop) WORKDIR /root/ 0B
4bafd6e2811a 4 hours ago /bin/sh -c apt-get update && apt-get i... 45.4MB
<missing> 3 weeks ago /bin/sh -c #(nop) CMD ["bash"] 0B
<missing> 3 weeks ago /bin/sh -c #(nop) ADD file:8b7cf813a113aa2... 85.7MB

Here is the evolution of my Dockerfile as I made changes and the final result got smaller and smaller. Looks like 45 megs trimmed with a little work or about 20% smaller.

C:\Users\scott\Desktop\k8s for pi\aspnetcoreapp>docker images | find /i "aspnetcoreapp"

shanselman/aspnetcoreapp 0.5 c6094ca46c3b About a minute ago 188MB
shanselman/aspnetcoreapp 0.4 083bfbdc4e01 12 minutes ago 196MB
shanselman/aspnetcoreapp 0.3 fa053b4ee2b4 About an hour ago 199MB
shanselman/aspnetcoreapp 0.2 ba73f14e29aa 4 hours ago 207MB
shanselman/aspnetcoreapp 0.1 cac2f0e3826c 3 hours ago 233MB

Later I'll do a blog post where I put this standard ASP.NET Core web app into Kubernetes using this YAML description and scale it out on the Raspberry Pi. I'm learning a lot! Thanks to Alex Ellis and Glenn Condron and Jessie Frazelle for their time!


Sponsor: Create powerful Web applications to manage each step of a document’s life cycle with DocuVieware HTML5 Viewer and Document Management Kit. Check our demos to acquire, scan, edit, annotate 100+ formats, and customize your UI!



© 2017 Scott Hanselman. All rights reserved.
     

.NET and Docker

“Container Ship” by NOAA's National Ocean Service is licensed under CC BY 2.0.NET and .NET Core (and Windows!) have been getting better and better with Docker. I run Docker for Windows as it supports both Linux Containers and Windows Containers. They have both a Stable and Edge channel. The Edge (Beta) channel is regularly updated and, as a rule, gets better and better in the year I’ve been running it.

As a slightly unrelated side note, I’m also running Docker on my Synology NAS with a number of containers, as well as .NET Core (my Nas is an Intel chip), Minecraft Server, Plex Server, and CrashPlan.

NOTE: Docker for Windows requires 64bit Windows 10 Pro and Microsoft Hyper-V. Please see What to know before you install for a full list of prerequisites.

The .NET Team at Microsoft has been getting their dockerfiles in order and organized. It can seem initially the opposite, with lots of cryptic tags and names, but there’s a clear method you can read about here.

They publish their Docker images in a few different repositories on Docker Hub. It’s important to segment images so that they are easier to find, both on the Docker Hub website as well as with the docker search command.

There’s also some samples at:

The samples are super easy to try out – STOP READING AND TRY THIS NOW. 😉

I’m always impressed with a nice asynchronous ASCII Progress bar. I’m easy to impress. This is a “hello world” sample with a surprise ASCII art. I won’t spoil for you.

C:\Users\scott\Desktop> docker run microsoft/dotnet-samples
Unable to find image 'microsoft/dotnet-samples:latest' locally
latest: Pulling from microsoft/dotnet-samples
10a267c67f42: Downloading [========> ] 9.19MB/52.58MB
7e1a7ec87c21: Downloading [======================> ] 10.8MB/18.59MB
923d0cd2ed37: Download complete
7c523004cf83: Downloading [=========> ] 6.144MB/33.07MB
f3582118a43a: Waiting
c27ef6b597a0: Waiting

All the images are managed and maintained on GitHub so you can get involved if you’re not digging the images or files.

One interesting thing to point out is the difference between dev images and production images, as well as images you’d use in CI/CD (Build Server) situations to build other images. Here are some examples from GitHub:

Development

  • dotnetapp-dev – This sample is good for development and building since it relies on the .NET Core SDK image. It performs dotnet commands on your behalf, reducing the time it takes to create Docker images (assuming you make changes and then test them in a container, iteratively).

Production

  • dotnetapp-prod – This sample is good for production since it relies on the .NET Core Runtime image, not the larger .NET Core SDK image. Most apps only need the runtime, reducing the size of your application image.
  • dotnetapp-selfcontained – This sample is also good for production scenarios since it relies on an operating system image (without .NET Core). Self-contained .NET Core apps include .NET Core as part of the app and not as a centrally installed component in a base image.
  • dotnetapp-current – This sample demonstrates how to configure an application to use the .NET Core 1.1 image. Both the .csproj and the Dockerfile have been updated to depend on .NET Core 1.1. This sample is the same as dotnetapp-prod with the exception of relying on a later .NET Core version.
  • aspnetapp – This samples demonstrates a Dockerized ASP.NET Core Web App

There’s great Docker support in VS Code, Visual Studio 2017, and Visual Studio for Mac (the Preview channel). With VS and Docker on Windows you can even F5 (debug) into a Linux Container.

Some of you may have .NET Framework apps running in Virtual Machines that you’d love to get moved over to a container infrastructure. There’s a tool called Image2Docker that Docker maintains that might help. It helps migrate VMs to Containers. Check out the Image2Docker DockerCon talk or read Docker’s Convert ASP.NET Web Servers To Docker with ImageDocker to learn more.

“Container Ship” by NOAA’s National Ocean Service is licensed under CC BY 2.0


Sponsor: Check out Seq: simple centralized logging, on your infrastructure, with great support for ASP.NET Core and Serilog. Download version 4.0.


© 2017 Scott Hanselman. All rights reserved.
     

“Container Ship” by NOAA's National Ocean Service is licensed under CC BY 2.0.NET and .NET Core (and Windows!) have been getting better and better with Docker. I run Docker for Windows as it supports both Linux Containers and Windows Containers. They have both a Stable and Edge channel. The Edge (Beta) channel is regularly updated and, as a rule, gets better and better in the year I've been running it.

As a slightly unrelated side note, I'm also running Docker on my Synology NAS with a number of containers, as well as .NET Core (my Nas is an Intel chip), Minecraft Server, Plex Server, and CrashPlan.

NOTE: Docker for Windows requires 64bit Windows 10 Pro and Microsoft Hyper-V. Please see What to know before you install for a full list of prerequisites.

The .NET Team at Microsoft has been getting their dockerfiles in order and organized. It can seem initially the opposite, with lots of cryptic tags and names, but there's a clear method you can read about here.

They publish their Docker images in a few different repositories on Docker Hub. It’s important to segment images so that they are easier to find, both on the Docker Hub website as well as with the docker search command.

There's also some samples at:

The samples are super easy to try out - STOP READING AND TRY THIS NOW. ;)

I'm always impressed with a nice asynchronous ASCII Progress bar. I'm easy to impress. This is a "hello world" sample with a surprise ASCII art. I won't spoil for you.

C:\Users\scott\Desktop> docker run microsoft/dotnet-samples

Unable to find image 'microsoft/dotnet-samples:latest' locally
latest: Pulling from microsoft/dotnet-samples
10a267c67f42: Downloading [========> ] 9.19MB/52.58MB
7e1a7ec87c21: Downloading [======================> ] 10.8MB/18.59MB
923d0cd2ed37: Download complete
7c523004cf83: Downloading [=========> ] 6.144MB/33.07MB
f3582118a43a: Waiting
c27ef6b597a0: Waiting

All the images are managed and maintained on GitHub so you can get involved if you're not digging the images or files.

One interesting thing to point out is the difference between dev images and production images, as well as images you'd use in CI/CD (Build Server) situations to build other images. Here are some examples from GitHub:

Development

  • dotnetapp-dev - This sample is good for development and building since it relies on the .NET Core SDK image. It performs dotnet commands on your behalf, reducing the time it takes to create Docker images (assuming you make changes and then test them in a container, iteratively).

Production

  • dotnetapp-prod - This sample is good for production since it relies on the .NET Core Runtime image, not the larger .NET Core SDK image. Most apps only need the runtime, reducing the size of your application image.
  • dotnetapp-selfcontained - This sample is also good for production scenarios since it relies on an operating system image (without .NET Core). Self-contained .NET Core apps include .NET Core as part of the app and not as a centrally installed component in a base image.
  • dotnetapp-current - This sample demonstrates how to configure an application to use the .NET Core 1.1 image. Both the .csproj and the Dockerfile have been updated to depend on .NET Core 1.1. This sample is the same as dotnetapp-prod with the exception of relying on a later .NET Core version.
  • aspnetapp - This samples demonstrates a Dockerized ASP.NET Core Web App

There's great Docker support in VS Code, Visual Studio 2017, and Visual Studio for Mac (the Preview channel). With VS and Docker on Windows you can even F5 (debug) into a Linux Container.

Some of you may have .NET Framework apps running in Virtual Machines that you'd love to get moved over to a container infrastructure. There's a tool called Image2Docker that Docker maintains that might help. It helps migrate VMs to Containers. Check out the Image2Docker DockerCon talk or read Docker’s Convert ASP.NET Web Servers To Docker with ImageDocker to learn more.

“Container Ship” by NOAA's National Ocean Service is licensed under CC BY 2.0


Sponsor: Check out Seq: simple centralized logging, on your infrastructure, with great support for ASP.NET Core and Serilog. Download version 4.0.



© 2017 Scott Hanselman. All rights reserved.
     

ZEIT now deployments of open source ASP.NET Core web apps with Docker

ZEIT is a new cloud service and “now” is the name of their deployment tool. ZEIT World is their DNS service. If you head over to https://zeit.co/ you’ll see a somewhat cryptic animated gif that shows how almost impossibly simple it is to deploy a web app with ZEIT now.

ZEIT works with .NET Core and ASP.NET

You can make a folder, put an index.html (for example) in it and just run “now.” You’ll automatically get a website with an autogenerated name and it’ll be live. It’s probably the fastest and easiest deploy I’ve ever seen. Remember when Heroku (then Azure, then literally everyone) started using git for deployment? Clearly being able to type “now” and just get a web site on the public internet was the next step. (Next someone will make “up” which will then get replaced with just pressing ENTER on an empty line! 😉 )

Jokes aside, now is clean and easy. I appreciate their organizational willpower to make an elegant and simple command line tool. I suspect it’s harder than it looks to keep things simple.

All of their examples use JavaScript and node.js, but they also support Docker, which means they support open source ASP.NET Core on .NET Core! But do they know they do? 😉 Let’s find out.

And more importantly, how easy is it? Can I take a site from concept to production in minutes? Darn tootin’ I can.

First, make a quick ASP.NET Core app. I’ll use the MVC template with Bootstrap.

C:\Users\scott\zeitdotnet>dotnet new mvc
Content generation time: 419.5337 ms
The template "ASP.NET Core Web App" created successfully.

I’ll do a quick dotnet restore to get the packages for my project.

C:\Users\scott\zeitdotnet>dotnet restore
Restoring packages for C:\Users\scott\zeitdotnet\zeitdotnet.csproj...
Generating MSBuild file C:\Users\scott\zeitdotnet\obj\zeitdotnet.csproj.nuget.g.props.
Generating MSBuild file C:\Users\scott\zeitdotnet\obj\zeitdotnet.csproj.nuget.g.targets.
Writing lock file to disk. Path: C:\Users\scott\zeitdotnet\obj\project.assets.json
Restore completed in 2.93 sec for C:\Users\scott\zeitdotnet\zeitdotnet.csproj.

NuGet Config files used:
C:\Users\scott\AppData\Roaming\NuGet\NuGet.Config
C:\Program Files (x86)\NuGet\Config\Microsoft.VisualStudio.Offline.config

Feeds used:
https://api.nuget.org/v3/index.json
C:\LocalNuGet
C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\

Now I need to add a Dockerfile. I’ll make one in the root that looks like this:

FROM microsoft/aspnetcore
LABEL name="zeitdotnet"
ENTRYPOINT ["dotnet", "zeitdotnet.dll"]
ARG source=.
WORKDIR /app
EXPOSE 80
COPY $source .

Note that I could have ZEIT build my app for me if I used the aspnetcore Dockerfile that includes the .NET Core SDK, but that would not only make my deployment longer, it would also make my docker images a LOT larger. I want to include JUST the .NET Core runtime in my image, so I’ll build and publish locally.

ZEIT now is going to need to see my Dockerfile, and since I want my app to include the binaries (I don’t want to ship my source in the Docker image up to ZEIT) I need to mark my Dockerfile as “Content” and make sure it’s copied to the publish folder when my app is built and published.

<ItemGroup>
  <None Remove="Dockerfile" />
</ItemGroup>
<ItemGroup>
  <Content Include="Dockerfile">
    <CopyToOutputDirectory>Always</CopyToOutputDirectory>
  </Content>
</ItemGroup>

I’ll add this my project’s csproj file. If I was using Visual Studio, this is the same as right clicking on the Properties of the Dockerfile, setting it to Content and then “Always Copy to Output Directory.”

Now I’ll just build and publish to a folder with one command:

C:\Users\scott\zeitdotnet>dotnet publish
Microsoft (R) Build Engine version 15.1.548.43366
Copyright (C) Microsoft Corporation. All rights reserved.

zeitdotnet -> C:\Users\scott\zeitdotnet\bin\Debug\netcoreapp1.1\zeitdotnet.dll

And finally, from the .\bin\Debug\netcoreapp1.1\ folder I run “now.” (Note that I’ve installed now and signed up for their service, of course.)

C:\Users\scott\zeitdotnet\bin\Debug\netcoreapp1.1\publish>now
> Deploying ~\zeitdotnet\bin\Debug\netcoreapp1.1\publish
> Ready! https://zeitdotnet-gmhcxevqkf.now.sh (copied to clipboard) [3s]
> Upload [====================] 100% 0.0s
> Sync complete (196.18kB) [2s]
> Initializing…
> Building
> ▲ docker build
> ---> 035a0a1401c3
> Removing intermediate container 289b9e4ce5d9
> Step 6 : EXPOSE 80
> ---> Running in efb817308333
> ---> fbac2aaa3039
> Removing intermediate container efb817308333
> Step 7 : COPY $source .
> ---> ff009cfc48ea
> Removing intermediate container 8d650c1867cd
> Successfully built ff009cfc48ea
> ▲ Storing image
> ▲ Deploying image
> Deployment complete!

Now has put the generated URL in my clipboard (during deployment you’ll get redirected to a lovely status page) and when it’s deployed I can visit my live site. But, that URL is not what I want. I want to use a custom URL.

I can take one of my domains and set it up with ZEIT World’s DNS but I like DNSimple (ref).

I can add my domain as an external one after adding a TXT record to my DNS to verify I own it. Then I setup a CNAME to point my subdomain to alias.zeit.co.

C:\Users\scott\Desktop\zeitdotnet>now alias https://zeitdotnet-gmhcxevqkf.now.sh http://zeitdotnet.hanselman.com
> zeitdotnet.hanselman.com is a custom domain.
> Verifying the DNS settings for zeitdotnet.hanselman.com (see https://zeit.world for help)
> Verification OK!
> Provisioning certificate for zeitdotnet.hanselman.com
> Success! Alias created:
https://zeitdotnet.hanselman.com now points to https://zeitdotnet-gmhcxevqkf.now.sh [copied to clipboard]

And that’s it. It even has a nice SSL certificate that they applied for me. It doesn’t terminate to SSL all the way into the docker container’s Kestral web server, but for most things that aren’t banking it’ll be just fine.

All in all, a lovely experience. Here’s my Hello World ASP.NE Core app running in ZEIT and deployed with now  at http://zeitdotnet.hanselman.com (if you are visiting this long after this was published, this sample MAY be gone.)

I am still learning about this (this whole exercise was about 30 total minutes and asking Glenn Condron a docker question) so I’m not clear how this would work in a large multi-container deployment, but as long as your site is immutable (don’t write to the container’s local disk!) ZEIT says it will scale your single containers. Perhaps docker-compose support is coming?


Sponsor: Did you know VSTS can integrate closely with Octopus Deploy? Join Damian Brady and Brian A. Randell as they show you how to automate deployments from VSTS to Octopus Deploy, and demo the new VSTS Octopus Deploy dashboard widget. Register now!


© 2017 Scott Hanselman. All rights reserved.
     

ZEIT is a new cloud service and "now" is the name of their deployment tool. ZEIT World is their DNS service. If you head over to https://zeit.co/ you'll see a somewhat cryptic animated gif that shows how almost impossibly simple it is to deploy a web app with ZEIT now.

ZEIT works with .NET Core and ASP.NET

You can make a folder, put an index.html (for example) in it and just run "now." You'll automatically get a website with an autogenerated name and it'll be live. It's probably the fastest and easiest deploy I've ever seen. Remember when Heroku (then Azure, then literally everyone) started using git for deployment? Clearly being able to type "now" and just get a web site on the public internet was the next step. (Next someone will make "up" which will then get replaced with just pressing ENTER on an empty line! ;) )

Jokes aside, now is clean and easy. I appreciate their organizational willpower to make an elegant and simple command line tool. I suspect it's harder than it looks to keep things simple.

All of their examples use JavaScript and node.js, but they also support Docker, which means they support open source ASP.NET Core on .NET Core! But do they know they do? ;) Let's find out.

And more importantly, how easy is it? Can I take a site from concept to production in minutes? Darn tootin' I can.

First, make a quick ASP.NET Core app. I'll use the MVC template with Bootstrap.

C:\Users\scott\zeitdotnet>dotnet new mvc

Content generation time: 419.5337 ms
The template "ASP.NET Core Web App" created successfully.

I'll do a quick dotnet restore to get the packages for my project.

C:\Users\scott\zeitdotnet>dotnet restore

Restoring packages for C:\Users\scott\zeitdotnet\zeitdotnet.csproj...
Generating MSBuild file C:\Users\scott\zeitdotnet\obj\zeitdotnet.csproj.nuget.g.props.
Generating MSBuild file C:\Users\scott\zeitdotnet\obj\zeitdotnet.csproj.nuget.g.targets.
Writing lock file to disk. Path: C:\Users\scott\zeitdotnet\obj\project.assets.json
Restore completed in 2.93 sec for C:\Users\scott\zeitdotnet\zeitdotnet.csproj.

NuGet Config files used:
C:\Users\scott\AppData\Roaming\NuGet\NuGet.Config
C:\Program Files (x86)\NuGet\Config\Microsoft.VisualStudio.Offline.config

Feeds used:
https://api.nuget.org/v3/index.json
C:\LocalNuGet
C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\

Now I need to add a Dockerfile. I'll make one in the root that looks like this:

FROM microsoft/aspnetcore

LABEL name="zeitdotnet"
ENTRYPOINT ["dotnet", "zeitdotnet.dll"]
ARG source=.
WORKDIR /app
EXPOSE 80
COPY $source .

Note that I could have ZEIT build my app for me if I used the aspnetcore Dockerfile that includes the .NET Core SDK, but that would not only make my deployment longer, it would also make my docker images a LOT larger. I want to include JUST the .NET Core runtime in my image, so I'll build and publish locally.

ZEIT now is going to need to see my Dockerfile, and since I want my app to include the binaries (I don't want to ship my source in the Docker image up to ZEIT) I need to mark my Dockerfile as "Content" and make sure it's copied to the publish folder when my app is built and published.

<ItemGroup>
  <None Remove="Dockerfile" />
</ItemGroup>
<ItemGroup>
  <Content Include="Dockerfile">
    <CopyToOutputDirectory>Always</CopyToOutputDirectory>
  </Content>
</ItemGroup>
I'll add this my project's csproj file. If I was using Visual Studio, this is the same as right clicking on the Properties of the Dockerfile, setting it to Content and then "Always Copy to Output Directory."

Now I'll just build and publish to a folder with one command:

C:\Users\scott\zeitdotnet>dotnet publish

Microsoft (R) Build Engine version 15.1.548.43366
Copyright (C) Microsoft Corporation. All rights reserved.

zeitdotnet -> C:\Users\scott\zeitdotnet\bin\Debug\netcoreapp1.1\zeitdotnet.dll

And finally, from the .\bin\Debug\netcoreapp1.1\ folder I run "now." (Note that I've installed now and signed up for their service, of course.)

C:\Users\scott\zeitdotnet\bin\Debug\netcoreapp1.1\publish>now

> Deploying ~\zeitdotnet\bin\Debug\netcoreapp1.1\publish
> Ready! https://zeitdotnet-gmhcxevqkf.now.sh (copied to clipboard) [3s]
> Upload [====================] 100% 0.0s
> Sync complete (196.18kB) [2s]
> Initializing…
> Building
> ▲ docker build
> ---> 035a0a1401c3
> Removing intermediate container 289b9e4ce5d9
> Step 6 : EXPOSE 80
> ---> Running in efb817308333
> ---> fbac2aaa3039
> Removing intermediate container efb817308333
> Step 7 : COPY $source .
> ---> ff009cfc48ea
> Removing intermediate container 8d650c1867cd
> Successfully built ff009cfc48ea
> ▲ Storing image
> ▲ Deploying image
> Deployment complete!

Now has put the generated URL in my clipboard (during deployment you'll get redirected to a lovely status page) and when it's deployed I can visit my live site. But, that URL is not what I want. I want to use a custom URL.

I can take one of my domains and set it up with ZEIT World's DNS but I like DNSimple (ref).

I can add my domain as an external one after adding a TXT record to my DNS to verify I own it. Then I setup a CNAME to point my subdomain to alias.zeit.co.

C:\Users\scott\Desktop\zeitdotnet>now alias https://zeitdotnet-gmhcxevqkf.now.sh http://zeitdotnet.hanselman.com

> zeitdotnet.hanselman.com is a custom domain.
> Verifying the DNS settings for zeitdotnet.hanselman.com (see https://zeit.world for help)
> Verification OK!
> Provisioning certificate for zeitdotnet.hanselman.com
> Success! Alias created:
https://zeitdotnet.hanselman.com now points to https://zeitdotnet-gmhcxevqkf.now.sh [copied to clipboard]

And that's it. It even has a nice SSL certificate that they applied for me. It doesn't terminate to SSL all the way into the docker container's Kestral web server, but for most things that aren't banking it'll be just fine.

All in all, a lovely experience. Here's my Hello World ASP.NE Core app running in ZEIT and deployed with now  at http://zeitdotnet.hanselman.com (if you are visiting this long after this was published, this sample MAY be gone.)

I am still learning about this (this whole exercise was about 30 total minutes and asking Glenn Condron a docker question) so I'm not clear how this would work in a large multi-container deployment, but as long as your site is immutable (don't write to the container's local disk!) ZEIT says it will scale your single containers. Perhaps docker-compose support is coming?


Sponsor: Did you know VSTS can integrate closely with Octopus Deploy? Join Damian Brady and Brian A. Randell as they show you how to automate deployments from VSTS to Octopus Deploy, and demo the new VSTS Octopus Deploy dashboard widget. Register now!



© 2017 Scott Hanselman. All rights reserved.
     

Exploring ASP.NET Core with Docker in both Linux and Windows Containers

In May of last year doing things with ASP.NET and Docker was in its infancy. But cool stuff was afoot. I wrote a blog post showing how to publish an ASP.NET 5 (5 at the time, now Core 1.0) app to Docker. Later in December of 2015 new tools like Docker Toolbox and Kitematic made things even easier. In May of 2016 Docker for Windows Beta continued to move the ball forward nicely.

I wanted to see how things are looking with ASP.NET Core, Docker, and Windows here in October of 2016.

I installed these things:

Docker for Windows is really nice as it automates setting up Hyper-V for you and creates the Docker host OS and gets it all running. This is a big time saver.

Hyper-V manager

There’s my Linux host that I don’t really have to think about. I’ll do everything from the command line or from Visual Studio.

I’ll say File | New Project and make a new ASP.NET Core application running on .NET Core.

Then I right click and Add | Docker Support. This menu comes from the Visual Studio Tools for Docker extension. This adds a basic Dockerfile and some docker-compose files. Out of the box, I’m all setup to deploy my ASP.NET Core app to a Docker Linux container.

ASP.NET Core in a Docker Linux Container

Starting from my ASP.NET Core app, I’ll make sure my base image (that’s the FROM in the Dockerfile) is the base ASP.NET Core image for Linux.

FROM microsoft/aspnetcore:1.0.1
ENTRYPOINT ["dotnet", "WebApplication4.dll"]
ARG source=.
WORKDIR /app
EXPOSE 80
COPY $source .

Next, since I don’t want Docker to do the building of my application yet, I’ll publish it locally. Be sure to read Steve Lasker’s blog post “Building Optimized Docker Images with ASP.NET Core” to learn how to have one docker container build your app and the other run it it. This optimizes server density and resource.

I’ll publish, then build the images, and run it.

>dotnet publish

>docker build bin\Debug\netcoreapp1.0\publish -t aspnetcoreonlinux

>docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
aspnetcoreonlinux latest dab2bff7e4a6 28 seconds ago 276.2 MB
microsoft/aspnetcore 1.0.1 2e781d03cb22 44 hours ago 266.7 MB

>docker run -it -d -p 85:80 aspnetcoreonlinux
1cfcc8e8e7d4e6257995f8b64505ce25ae80e05fe1962d4312b2e2fe33420413

>docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
1cfcc8e8e7d4 aspnetcoreonlinux "dotnet WebApplicatio" 2 seconds ago Up 1 seconds 0.0.0.0:85->80/tcp clever_archimedes

And there’s my ASP.NET Core app running in Docker. So I’m running Windows, running Hyper-V, running a Linux host that is hosting Docker containers.

What else can I do?

ASP.NET Core in a Docker Windows Container running Windows Nano Server

There’s Windows Server, there’s Windows Server Core that removes the UI among other things and there’s Windows Nano Server which gets Windows down to like hundreds of megs instead of many gigs. This means there’s a lot of great choices depending on what you need for functionality and server density. Ship as little as possible.

Let me see if I can get ASP.NET Core running on Kestrel under Windows Nano Server. Certainly, since Nano is very capable, I could run IIS within the container and there’s docs on that.

Michael Friis from Docker has a great blog post on building and running your first Docker Windows Server Container. With the new Docker for Windows you can just right click on it and switch between Linux and Windows Containers.

Docker switches between Mac and Windows easily

So now I’m using Docker with Windows Containers. You may not know that you likely already have Windows Containers! It was shipped inside Windows 10 Anniversary Edition. You can check for Containers in Features:

Add Containers in Windows 10

I’ll change my Dockerfile to use the Windows Nano Server image. I can also control the ports that ASP.NET talks on if I like with an Environment Variable and Expose that within Docker.

FROM microsoft/dotnet:nanoserver
ENTRYPOINT ["dotnet", "WebApplication4.dll"]
ARG source=.
WORKDIR /app
ENV ASPNETCORE_URLS http://+:82
EXPOSE 82
COPY $source .

Then I’ll publish and build…

>dotnet publish
>docker build bin\Debug\netcoreapp1.0\publish -t aspnetcoreonnano

Then I’ll run it, mapping the ports from Windows outside to the Windows container inside!

NOTE: There’s a bug as of this writing that affects how Windows 10 talks to Containers via “NAT” (Network Address Translation) such that you can’t easily go http://localhost:82 like you (and I) want to. Today you have to hit the IP of the container directly. I’ll report back once I hear more about this bug and how it gets fixed. It’ll show up in Windows Update one day. The workaround is to get the IP address of the container from docker like this:  docker inspect -f “{{ .NetworkSettings.Networks.nat.IPAddress }}” HASH

So I’ll run my ASP.NET Core app on Windows Nano Server (again, to be clear, this is running on Windows 10 and Nano Server is inside a Container!)

>docker run -it -d -p 88:82 aspnetcoreonnano
afafdbead8b04205841a81d974545f033dcc9ba7f761ff7e6cc0ec8f3ecce215

>docker inspect -f "{{ .NetworkSettings.Networks.nat.IPAddress }}" afa
172.16.240.197

Now I can hit that site with 172.16.240.197:82. Once that bug above is fixed, it’ll get hit and routed like any container.

The best part about Windows Containers is that they are fast and lightweight. Once the image is downloaded and build on your machine, you’re starting and stopping them in seconds with Docker.

BUT, you can also isolate Windows Containers using Docker like this:

docker run --isolation=hyperv -it -d -p 86:82 aspnetcoreonnano

So now this instance is running fully isolated within Hyper-V itself. You get the best of all worlds. Speed and convenient deployment plus optional and easy isolation.

ASP.NET Core in a Docker Windows Container running Windows Server Core 2016

I can then change the Dockerfile to use the full Windows Server Core image. This is 8 gigs so be ready as it’ll take a bit to download and extract but it is really Windows. You can also choose to run this as a container or as an isolated Hyper-V container.

Here I just change the FROM to get a Windows Sever Core with .NET Core included.

FROM microsoft/dotnet:1.0.0-preview2-windowsservercore-sdk
ENTRYPOINT ["dotnet", "WebApplication4.dll"]
ARG source=.
WORKDIR /app
ENV ASPNETCORE_URLS http://+:82
EXPOSE 82
COPY $source .

NOTE: I hear it’s likely that the the .NET Core on Windows Server Core images will likely go away. It makes more sense for .NET Core to run on Windows Nano Server or other lightweight images. You’ll use Server Core for heavier stuff. If you REALLY want to have .NET Core on Server Core you can make your own Dockerfile and easily build and image that has the things you want.

Then I’ll publish, build, and run again.

>docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
aspnetcoreonnano latest 7e02d6800acf 24 minutes ago 1.113 GB
aspnetcoreonservercore latest a11d9a9ba0c2 28 minutes ago 7.751 GB

Since containers are so fast to start and stop I can have a complete web farm running with Redis in a Container, SQL in another, and my web stack in a third. Or mix and match.

>docker ps
CONTAINER ID IMAGE COMMAND PORTS NAMES
d32a981ceabb aspnetcoreonwindows "dotnet WebApplicatio" 0.0.0.0:87->82/tcp compassionate_blackwell
a179a48ca9f6 aspnetcoreonnano "dotnet WebApplicatio" 0.0.0.0:86->82/tcp determined_stallman
170a8afa1b8b aspnetcoreonnano "dotnet WebApplicatio" 0.0.0.0:89->82/tcp agitated_northcutt
afafdbead8b0 aspnetcoreonnano "dotnet WebApplicatio" 0.0.0.0:88->82/tcp naughty_ramanujan
2cf45ea2f008 a7fa77b6f1d4 "dotnet WebApplicatio" 0.0.0.0:97->82/tcp sleepy_hodgkin

Conclusion

Again, go check out Michael’s article where he uses Docker Compose to bring up the ASP.NET Music Store sample with SQL Express in one Windows Container and ASP.NET Core in another as well as Steve Lasker’s blog (in fact his whole blog is gold) on making optimized Docker images with ASP.NET Core.

IMAGE ID            RESPOSITORY                   TAG                 SIZE
0ec4274c5571 web optimized 276.2 MB
f9f196304c95 web single 583.8 MB
f450043e0a44 microsoft/aspnetcore 1.0.1 266.7 MB
706045865622 microsoft/aspnetcore-build 1.0.1 896.6 MB

Steve points out a number of techniques that will allow you to get the most out of Docker and ASP.NET Core.

The result of all this means (IMHO) that you can use ASP.NET Core:

  • ASP.NET Core on Linux

    • within Docker containers
    • in any Cloud
  • ASP.NET Core on Windows, Windows Server, Server Core, and Nano Server.
    • within Docker windows containers
    • within Docker isolated Hyper-V containers

This means you can choose the level of feature support and size to optimize for server density and convenience. Once all the tooling (the Docker folks with Docker for Windows and the VS folks with Visual Studio Docker Tools) is baked, we’ll have nice debugging and workflows from dev to production.

What have you been doing with Docker, Containers, and ASP.NET Core? Sound off in the comments.


Sponsor: Thanks to Redgate this week! Discover the world’s most trusted SQL Server comparison tool. Enjoy a free trial of SQL Compare, the industry standard for comparing and deploying SQL Server schemas.


© 2016 Scott Hanselman. All rights reserved.
     

In May of last year doing things with ASP.NET and Docker was in its infancy. But cool stuff was afoot. I wrote a blog post showing how to publish an ASP.NET 5 (5 at the time, now Core 1.0) app to Docker. Later in December of 2015 new tools like Docker Toolbox and Kitematic made things even easier. In May of 2016 Docker for Windows Beta continued to move the ball forward nicely.

I wanted to see how things are looking with ASP.NET Core, Docker, and Windows here in October of 2016.

I installed these things:

Docker for Windows is really nice as it automates setting up Hyper-V for you and creates the Docker host OS and gets it all running. This is a big time saver.

Hyper-V manager

There's my Linux host that I don't really have to think about. I'll do everything from the command line or from Visual Studio.

I'll say File | New Project and make a new ASP.NET Core application running on .NET Core.

Then I right click and Add | Docker Support. This menu comes from the Visual Studio Tools for Docker extension. This adds a basic Dockerfile and some docker-compose files. Out of the box, I'm all setup to deploy my ASP.NET Core app to a Docker Linux container.

ASP.NET Core in a Docker Linux Container

Starting from my ASP.NET Core app, I'll make sure my base image (that's the FROM in the Dockerfile) is the base ASP.NET Core image for Linux.

FROM microsoft/aspnetcore:1.0.1

ENTRYPOINT ["dotnet", "WebApplication4.dll"]
ARG source=.
WORKDIR /app
EXPOSE 80
COPY $source .

Next, since I don't want Docker to do the building of my application yet, I'll publish it locally. Be sure to read Steve Lasker's blog post "Building Optimized Docker Images with ASP.NET Core" to learn how to have one docker container build your app and the other run it it. This optimizes server density and resource.

I'll publish, then build the images, and run it.

>dotnet publish


>docker build bin\Debug\netcoreapp1.0\publish -t aspnetcoreonlinux

>docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
aspnetcoreonlinux latest dab2bff7e4a6 28 seconds ago 276.2 MB
microsoft/aspnetcore 1.0.1 2e781d03cb22 44 hours ago 266.7 MB

>docker run -it -d -p 85:80 aspnetcoreonlinux
1cfcc8e8e7d4e6257995f8b64505ce25ae80e05fe1962d4312b2e2fe33420413

>docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
1cfcc8e8e7d4 aspnetcoreonlinux "dotnet WebApplicatio" 2 seconds ago Up 1 seconds 0.0.0.0:85->80/tcp clever_archimedes

And there's my ASP.NET Core app running in Docker. So I'm running Windows, running Hyper-V, running a Linux host that is hosting Docker containers.

What else can I do?

ASP.NET Core in a Docker Windows Container running Windows Nano Server

There's Windows Server, there's Windows Server Core that removes the UI among other things and there's Windows Nano Server which gets Windows down to like hundreds of megs instead of many gigs. This means there's a lot of great choices depending on what you need for functionality and server density. Ship as little as possible.

Let me see if I can get ASP.NET Core running on Kestrel under Windows Nano Server. Certainly, since Nano is very capable, I could run IIS within the container and there's docs on that.

Michael Friis from Docker has a great blog post on building and running your first Docker Windows Server Container. With the new Docker for Windows you can just right click on it and switch between Linux and Windows Containers.

Docker switches between Mac and Windows easily

So now I'm using Docker with Windows Containers. You may not know that you likely already have Windows Containers! It was shipped inside Windows 10 Anniversary Edition. You can check for Containers in Features:

Add Containers in Windows 10

I'll change my Dockerfile to use the Windows Nano Server image. I can also control the ports that ASP.NET talks on if I like with an Environment Variable and Expose that within Docker.

FROM microsoft/dotnet:nanoserver

ENTRYPOINT ["dotnet", "WebApplication4.dll"]
ARG source=.
WORKDIR /app
ENV ASPNETCORE_URLS http://+:82
EXPOSE 82
COPY $source .

Then I'll publish and build...

>dotnet publish

>docker build bin\Debug\netcoreapp1.0\publish -t aspnetcoreonnano

Then I'll run it, mapping the ports from Windows outside to the Windows container inside!

NOTE: There's a bug as of this writing that affects how Windows 10 talks to Containers via "NAT" (Network Address Translation) such that you can't easily go http://localhost:82 like you (and I) want to. Today you have to hit the IP of the container directly. I'll report back once I hear more about this bug and how it gets fixed. It'll show up in Windows Update one day. The workaround is to get the IP address of the container from docker like this:  docker inspect -f "{{ .NetworkSettings.Networks.nat.IPAddress }}" HASH

So I'll run my ASP.NET Core app on Windows Nano Server (again, to be clear, this is running on Windows 10 and Nano Server is inside a Container!)

>docker run -it -d -p 88:82 aspnetcoreonnano

afafdbead8b04205841a81d974545f033dcc9ba7f761ff7e6cc0ec8f3ecce215

>docker inspect -f "{{ .NetworkSettings.Networks.nat.IPAddress }}" afa
172.16.240.197

Now I can hit that site with 172.16.240.197:82. Once that bug above is fixed, it'll get hit and routed like any container.

The best part about Windows Containers is that they are fast and lightweight. Once the image is downloaded and build on your machine, you're starting and stopping them in seconds with Docker.

BUT, you can also isolate Windows Containers using Docker like this:

docker run --isolation=hyperv -it -d -p 86:82 aspnetcoreonnano

So now this instance is running fully isolated within Hyper-V itself. You get the best of all worlds. Speed and convenient deployment plus optional and easy isolation.

ASP.NET Core in a Docker Windows Container running Windows Server Core 2016

I can then change the Dockerfile to use the full Windows Server Core image. This is 8 gigs so be ready as it'll take a bit to download and extract but it is really Windows. You can also choose to run this as a container or as an isolated Hyper-V container.

Here I just change the FROM to get a Windows Sever Core with .NET Core included.

FROM microsoft/dotnet:1.0.0-preview2-windowsservercore-sdk

ENTRYPOINT ["dotnet", "WebApplication4.dll"]
ARG source=.
WORKDIR /app
ENV ASPNETCORE_URLS http://+:82
EXPOSE 82
COPY $source .

NOTE: I hear it's likely that the the .NET Core on Windows Server Core images will likely go away. It makes more sense for .NET Core to run on Windows Nano Server or other lightweight images. You'll use Server Core for heavier stuff. If you REALLY want to have .NET Core on Server Core you can make your own Dockerfile and easily build and image that has the things you want.

Then I'll publish, build, and run again.

>docker images

REPOSITORY TAG IMAGE ID CREATED SIZE
aspnetcoreonnano latest 7e02d6800acf 24 minutes ago 1.113 GB
aspnetcoreonservercore latest a11d9a9ba0c2 28 minutes ago 7.751 GB

Since containers are so fast to start and stop I can have a complete web farm running with Redis in a Container, SQL in another, and my web stack in a third. Or mix and match.

>docker ps

CONTAINER ID IMAGE COMMAND PORTS NAMES
d32a981ceabb aspnetcoreonwindows "dotnet WebApplicatio" 0.0.0.0:87->82/tcp compassionate_blackwell
a179a48ca9f6 aspnetcoreonnano "dotnet WebApplicatio" 0.0.0.0:86->82/tcp determined_stallman
170a8afa1b8b aspnetcoreonnano "dotnet WebApplicatio" 0.0.0.0:89->82/tcp agitated_northcutt
afafdbead8b0 aspnetcoreonnano "dotnet WebApplicatio" 0.0.0.0:88->82/tcp naughty_ramanujan
2cf45ea2f008 a7fa77b6f1d4 "dotnet WebApplicatio" 0.0.0.0:97->82/tcp sleepy_hodgkin

Conclusion

Again, go check out Michael's article where he uses Docker Compose to bring up the ASP.NET Music Store sample with SQL Express in one Windows Container and ASP.NET Core in another as well as Steve Lasker's blog (in fact his whole blog is gold) on making optimized Docker images with ASP.NET Core.

IMAGE ID            RESPOSITORY                   TAG                 SIZE

0ec4274c5571 web optimized 276.2 MB
f9f196304c95 web single 583.8 MB
f450043e0a44 microsoft/aspnetcore 1.0.1 266.7 MB
706045865622 microsoft/aspnetcore-build 1.0.1 896.6 MB

Steve points out a number of techniques that will allow you to get the most out of Docker and ASP.NET Core.

The result of all this means (IMHO) that you can use ASP.NET Core:

  • ASP.NET Core on Linux
    • within Docker containers
    • in any Cloud
  • ASP.NET Core on Windows, Windows Server, Server Core, and Nano Server.
    • within Docker windows containers
    • within Docker isolated Hyper-V containers

This means you can choose the level of feature support and size to optimize for server density and convenience. Once all the tooling (the Docker folks with Docker for Windows and the VS folks with Visual Studio Docker Tools) is baked, we'll have nice debugging and workflows from dev to production.

What have you been doing with Docker, Containers, and ASP.NET Core? Sound off in the comments.


Sponsor: Thanks to Redgate this week! Discover the world’s most trusted SQL Server comparison tool. Enjoy a free trial of SQL Compare, the industry standard for comparing and deploying SQL Server schemas.



© 2016 Scott Hanselman. All rights reserved.
     

Publishing an ASP.NET 5 app to Docker on Linux with Visual Studio

Docker Apps are mostly portableIt’s early days, but this is a nice preview of the possibilities of things to come. I often use LEGO bricks in the way of an analogy when talking about software systems. I like the idea of choice, flexibility, and plug-ability. Choosing your language, operating system, deployment method and style, etc are all important.

There is a preview of an extension for Visual Studio 2015 (the release candidate at the time of this writing) that adds Docker support. If you have VS2015 RC you can get the Docker Extension here. You can certainly manage things from the command line, but I think as you go through this post you’ll appreciate the convenience of this extension.

NOTE: It’s also worth pointing out that there is a Windows client command line for Docker as well. You can “choco install dockerand read about it here.

The Brief What’s Docker Explanation

If you aren’t familiar with Docker, here’s the super basics.

  • Virtual Machines: You likely know what a virtual machine is. It’s the whole operating system, the whole computer, virtualized. If you have a 10 megabyte app you want to run, you may end up putting it in a 10 gigabyte virtual machine and carrying it around. That gives great security and isolation as your app is all alone on its own private VM, but it’s a little overkill. Now you want to deploy 100 apps, and you’ve got space, CPU, and other things to think about. VMs also start slow and have to be actively maintained.
  • Docker/Linux Containers (and Windows containers “Docker for Windows Server”): Containers let you share most of that 10 gigabytes of support software between lots of apps, giving you less isolation but also using a LOT fewer resources. Containers start fast and the underlying shared resources are what’s maintained and kept up to date.

Docker also is a way to package up an app and push it out in a reliable and reproducible way. So you can say that Docker is a technology, but also a philosophy and a process.

Docker will work on Windows and Linux

Docker and Visual Studio

Once you have the Docker for Visual Studio 2015 extension (preview) installed, go ahead and make an ASP.NET 5 app. Right click the project and hit Publish.

Publishing to Docker from Visual Studio

Note the Docker Containers section that’s been added? You still have PAAS (Platform as a Service) and can also publish to VMs within Azure as well. Select Docker and you’ll be here:

Selecting a Docker VM

We’ll make a new VM to host our Docker stuff. This VM will have be the host for our containers. Today it’ll be an Ubuntu LTS VM. Note that the dialog includes all the setup for Docker, ports, certs, etc. I could use existing VMs, of course.

Making a Docker VM

If you don’t have a VM, then the initial create takes a while (5-10 min or more) so hang back. If you already have one, or the one you created is ready, then march on.

Visual Studio put in all our Docker details

Make special note of the Dockerfile option. You’ll usually want to select your own manually created Dockerfile, assuming you’re doing more than just a Hello World like I am.

The ASP.NET Dockerfile is up on GitHub: https://github.com/aspnet/aspnet-docker and in the Docker registry: https://registry.hub.docker.com/u/microsoft/aspnet/

In the build window you’ll see lots of docker-related output. Here’s a snipped version for flavor.

VERBOSE: Replacing tokens in Dockerfile: C:UsersScottAppDataLocalTempPublishTempapprootsrcWebApplication6PropertiesPublishProfilesDockerfile
VERBOSE: Package output path: C:UsersScottAppDataLocalTempPublishTemp
VERBOSE: DockerHost: tcp://hanseldocker.cloudapp.net:2376
VERBOSE: DockerImageName: webapplication6
VERBOSE: DockerPublishHostPort: 80
VERBOSE: DockerPublishContainerPort: 80
VERBOSE: DockerAuthOptions: --tls
VERBOSE: DockerAppType: Web
VERBOSE: DockerBuildOnly: False
VERBOSE: DockerRemoveConflictingContainers: True
VERBOSE: LaunchSiteAfterPublish: True
VERBOSE: SiteUrlToLaunchAfterPublish:
VERBOSE: Querying for conflicting containers which has the same port mapped to the host...
Executing command [docker --tls -H tcp://hanseldocker.cloudapp.net:2376 ps -a | select-string -pattern ":80->" | foreach { Write-Output $_.ToString().split()[0] }]
VERBOSE: Building Docker image: webapplication6
Executing command [docker --tls -H tcp://hanseldocker.cloudapp.net:2376 build -t webapplication6 -f "C:UsersScottAppDataLocalTempPublishTempapprootsrcWebApplication6PropertiesPublishProfilesDockerfile" "C:UsersScottAppDataLocalTempPublishTemp"]
VERBOSE: time="2015-05-27T10:59:06-07:00" level=warning msg="SECURITY WARNING: You are building a Docker image from Windows against a Linux Docker host. All files and directories added to build context will have '-rwxr-xr-x' permissions. It is recommended to double check and reset permissions for sensitive files and directories."
VERBOSE: Sending build context to Docker daemon 28.01 MB
VERBOSE: Step 0 : FROM microsoft/aspnet:vs-1.0.0-beta4
VERBOSE: vs-1.0.0-beta4: Pulling from microsoft/aspnet
VERBOSE: e5c30fef7918: Pulling fs layer
VERBOSE: e5c30fef7918: Pull complete
VERBOSE: e5c30fef7918: Already exists
VERBOSE: Digest: sha256:27fbe2377b5d4e66c4aaf3c984ef03d22afbfee3d4e78e10ff38cac7ff162d2e
VERBOSE: Status: Downloaded newer image for microsoft/aspnet:vs-1.0.0-beta4
VERBOSE: ---> e5c30fef7918
VERBOSE: Step 1 : ADD . /app
VERBOSE: ---> cf1f788321b3
VERBOSE: Removing intermediate container dd345cdcc5d9
VERBOSE: Step 2 : WORKDIR /app/approot/src/WebApplication6
VERBOSE: ---> Running in f22027140233
VERBOSE: ---> 7eabc0da4645
VERBOSE: Removing intermediate container f22027140233
VERBOSE: Step 3 : ENTRYPOINT dnx . Kestrel --server.urls http://localhost:80
VERBOSE: ---> Running in 4810324d32a5
VERBOSE: ---> e0a7ad38eb34
VERBOSE: Removing intermediate container 4810324d32a5
VERBOSE: Successfully built e0a7ad38eb34
The Docker image "webapplication6" was created successfully.
VERBOSE: Starting Docker container: webapplication6
Executing command [docker --tls -H tcp://hanseldocker.cloudapp.net:2376 run -t -d -p 80:80 webapplication6]
Docker container started with ID: 6d4820044df200e87f08cb5becbec879d1b58fcab73145ca3aa99a424c162054
To see standard output from your application, open a command line window and execute the following command:
docker --tls -H tcp://hanseldocker.cloudapp.net:2376 logs --follow 6d4820044df200e87f08cb5becbec879d1b58fcab73145ca3aa99a424c162054
VERBOSE: received -1-byte response of content type text/html; charset=utf-8
Executing command [Start-Process -FilePath "http://hanseldocker.cloudapp.net/"]
Publish completed successfully.

The interesting parts are the calls to dnx (the .NET Execution host), the warning that I started on Windows and I’m going to Linux, as well as the fact that we’re using the “microsoft/aspnet” docker image.

ASP.NET in a Linux Docker Container

It worked great. I’m looking forward a cross-platform cross-tools choice-filled future. Finally, there’s a great 7 part video series here called “Docker for .NET Developers” that you should check out on Channel 9.


Sponsor: Big thanks to Atalasoft for sponsoring the blog and feed this week! If your company works with documents, definitely check out Atalasoft’s developer tools for web & mobile viewing, capture, and transformation. They’ve got free trials and a remarkable support team, too.


© 2015 Scott Hanselman. All rights reserved.
     

Docker Apps are mostly portableIt's early days, but this is a nice preview of the possibilities of things to come. I often use LEGO bricks in the way of an analogy when talking about software systems. I like the idea of choice, flexibility, and plug-ability. Choosing your language, operating system, deployment method and style, etc are all important.

There is a preview of an extension for Visual Studio 2015 (the release candidate at the time of this writing) that adds Docker support. If you have VS2015 RC you can get the Docker Extension here. You can certainly manage things from the command line, but I think as you go through this post you'll appreciate the convenience of this extension.

NOTE: It's also worth pointing out that there is a Windows client command line for Docker as well. You can "choco install docker" and read about it here.

The Brief What's Docker Explanation

If you aren't familiar with Docker, here's the super basics.

  • Virtual Machines: You likely know what a virtual machine is. It's the whole operating system, the whole computer, virtualized. If you have a 10 megabyte app you want to run, you may end up putting it in a 10 gigabyte virtual machine and carrying it around. That gives great security and isolation as your app is all alone on its own private VM, but it's a little overkill. Now you want to deploy 100 apps, and you've got space, CPU, and other things to think about. VMs also start slow and have to be actively maintained.
  • Docker/Linux Containers (and Windows containers "Docker for Windows Server"): Containers let you share most of that 10 gigabytes of support software between lots of apps, giving you less isolation but also using a LOT fewer resources. Containers start fast and the underlying shared resources are what's maintained and kept up to date.

Docker also is a way to package up an app and push it out in a reliable and reproducible way. So you can say that Docker is a technology, but also a philosophy and a process.

Docker will work on Windows and Linux

Docker and Visual Studio

Once you have the Docker for Visual Studio 2015 extension (preview) installed, go ahead and make an ASP.NET 5 app. Right click the project and hit Publish.

Publishing to Docker from Visual Studio

Note the Docker Containers section that's been added? You still have PAAS (Platform as a Service) and can also publish to VMs within Azure as well. Select Docker and you'll be here:

Selecting a Docker VM

We'll make a new VM to host our Docker stuff. This VM will have be the host for our containers. Today it'll be an Ubuntu LTS VM. Note that the dialog includes all the setup for Docker, ports, certs, etc. I could use existing VMs, of course.

Making a Docker VM

If you don't have a VM, then the initial create takes a while (5-10 min or more) so hang back. If you already have one, or the one you created is ready, then march on.

Visual Studio put in all our Docker details

Make special note of the Dockerfile option. You'll usually want to select your own manually created Dockerfile, assuming you're doing more than just a Hello World like I am.

The ASP.NET Dockerfile is up on GitHub: https://github.com/aspnet/aspnet-docker and in the Docker registry: https://registry.hub.docker.com/u/microsoft/aspnet/

In the build window you'll see lots of docker-related output. Here's a snipped version for flavor.

VERBOSE: Replacing tokens in Dockerfile: C:UsersScottAppDataLocalTempPublishTempapprootsrcWebApplication6PropertiesPublishProfilesDockerfile

VERBOSE: Package output path: C:UsersScottAppDataLocalTempPublishTemp
VERBOSE: DockerHost: tcp://hanseldocker.cloudapp.net:2376
VERBOSE: DockerImageName: webapplication6
VERBOSE: DockerPublishHostPort: 80
VERBOSE: DockerPublishContainerPort: 80
VERBOSE: DockerAuthOptions: --tls
VERBOSE: DockerAppType: Web
VERBOSE: DockerBuildOnly: False
VERBOSE: DockerRemoveConflictingContainers: True
VERBOSE: LaunchSiteAfterPublish: True
VERBOSE: SiteUrlToLaunchAfterPublish:
VERBOSE: Querying for conflicting containers which has the same port mapped to the host...
Executing command [docker --tls -H tcp://hanseldocker.cloudapp.net:2376 ps -a | select-string -pattern ":80->" | foreach { Write-Output $_.ToString().split()[0] }]
VERBOSE: Building Docker image: webapplication6
Executing command [docker --tls -H tcp://hanseldocker.cloudapp.net:2376 build -t webapplication6 -f "C:UsersScottAppDataLocalTempPublishTempapprootsrcWebApplication6PropertiesPublishProfilesDockerfile" "C:UsersScottAppDataLocalTempPublishTemp"]
VERBOSE: time="2015-05-27T10:59:06-07:00" level=warning msg="SECURITY WARNING: You are building a Docker image from Windows against a Linux Docker host. All files and directories added to build context will have '-rwxr-xr-x' permissions. It is recommended to double check and reset permissions for sensitive files and directories."
VERBOSE: Sending build context to Docker daemon 28.01 MB
VERBOSE: Step 0 : FROM microsoft/aspnet:vs-1.0.0-beta4
VERBOSE: vs-1.0.0-beta4: Pulling from microsoft/aspnet
VERBOSE: e5c30fef7918: Pulling fs layer
VERBOSE: e5c30fef7918: Pull complete
VERBOSE: e5c30fef7918: Already exists
VERBOSE: Digest: sha256:27fbe2377b5d4e66c4aaf3c984ef03d22afbfee3d4e78e10ff38cac7ff162d2e
VERBOSE: Status: Downloaded newer image for microsoft/aspnet:vs-1.0.0-beta4
VERBOSE: ---> e5c30fef7918
VERBOSE: Step 1 : ADD . /app
VERBOSE: ---> cf1f788321b3
VERBOSE: Removing intermediate container dd345cdcc5d9
VERBOSE: Step 2 : WORKDIR /app/approot/src/WebApplication6
VERBOSE: ---> Running in f22027140233
VERBOSE: ---> 7eabc0da4645
VERBOSE: Removing intermediate container f22027140233
VERBOSE: Step 3 : ENTRYPOINT dnx . Kestrel --server.urls http://localhost:80
VERBOSE: ---> Running in 4810324d32a5
VERBOSE: ---> e0a7ad38eb34
VERBOSE: Removing intermediate container 4810324d32a5
VERBOSE: Successfully built e0a7ad38eb34
The Docker image "webapplication6" was created successfully.
VERBOSE: Starting Docker container: webapplication6
Executing command [docker --tls -H tcp://hanseldocker.cloudapp.net:2376 run -t -d -p 80:80 webapplication6]
Docker container started with ID: 6d4820044df200e87f08cb5becbec879d1b58fcab73145ca3aa99a424c162054
To see standard output from your application, open a command line window and execute the following command:
docker --tls -H tcp://hanseldocker.cloudapp.net:2376 logs --follow 6d4820044df200e87f08cb5becbec879d1b58fcab73145ca3aa99a424c162054
VERBOSE: received -1-byte response of content type text/html; charset=utf-8
Executing command [Start-Process -FilePath "http://hanseldocker.cloudapp.net/"]
Publish completed successfully.

The interesting parts are the calls to dnx (the .NET Execution host), the warning that I started on Windows and I'm going to Linux, as well as the fact that we're using the "microsoft/aspnet" docker image.

ASP.NET in a Linux Docker Container

It worked great. I'm looking forward a cross-platform cross-tools choice-filled future. Finally, there's a great 7 part video series here called "Docker for .NET Developers" that you should check out on Channel 9.


Sponsor: Big thanks to Atalasoft for sponsoring the blog and feed this week! If your company works with documents, definitely check out Atalasoft's developer tools for web & mobile viewing, capture, and transformation. They've got free trials and a remarkable support team, too.


© 2015 Scott Hanselman. All rights reserved.