Modernization Hub

Modernization and Improvement
Modernizing .NET Apps for IT Pros Part 3

Modernizing .NET Apps for IT Pros Part 3

Hey, how you doing? I’m Elton and this is
the third part of the Docker MTA series, Modernizing .NET Apps for IT Pros. In
Part 2 I showed you how to migrate a .NET 3.5 app running on a Windows
Server 2003 VM to Docker, using Image2Docker. You can use the exact same
approach for ASP.NET apps using .NET 2.0, through to .NET 4, where the source
is Windows Server 2003, 2008, 2012 or 2016. One of the big operational benefits in
moving to Docker is the ease of deployment. In this video I’m going to
show you the upgrade workflow, which is fast automated and safe – and it’s the
same for application updates as it is for Windows updates. I’ll show you how to
tag images so you can have different versions of your app, how to store your
images in a private registry, and how to update your applications by running a
new container from a new image. I finished the last video by running my
.NET 3.5 app in a Docker container on Windows 10. The image for that container
is stored on my laptop right now, so before I can run the app on other
machines I need to share the image. You share Docker images on a registry and
there are lots of registry servers to choose from. You can use Docker Hub for
open source apps, Docker Cloud for private apps and Docker Store for
commercial apps. I’m using Docker Trusted Registry which is a private registry you
can run in your own data center or in a virtual private cloud. Docker Trusted
Registry – DTR for short – has a rich authorization model. I’ve created an
organization for all the images related to the newsletter app and in that org
I have several teams. You can set permissions for accessing images on the
teams, so here DBAs have read and write access to the database image, but only
read access to the web application image. That means users in the DBA team can
push new versions of the database image to the registry, and they can pull the
application image to run it for testing but they can’t push new versions of the
app image. My account is in the admin group, so I can push and pull both the
app and database images. `docker image ls` tells me the images that I have
locally. To push the image to the registry I need to give it a tag which
includes the registry domain. `docker image tag` adds a new name to an existing
image. My original image reference has the repository name, the image name and a
version number. I’m adding my registry domain `` to the start of the
image reference. Now I need to authenticate with `docker login` using my
credentials for DTR, and to upload the image I run `docker image push` using the
new tag. When all the layers have uploaded I can see the image listed in
DTR, and now that’s available to download and run in any other environment. I have
a VM running in Azure using Microsoft’s Windows Server 2016 with
Containers machine image, which comes with docker
installed. This VM doesn’t have IIS or .NET 3.5, but I can still use it to run
my traditional app because all those dependencies are now bundled in the
Docker image. I’ll log in to the same private registry and pull the
application image. This is going to be a test environment, so I’ll also pull the
database image so I can run SQL Server in a container. I won’t start
the app by running individual containers, instead I’ve got a Docker Compose file
which I’ll use to run the whole application. Docker Compose is a tool for
defining multi-container applications, configuring them with the same options
that you use when you run individual containers. I have the database
definition here and the web app here. To start the whole app I run `docker-compose up -d` which starts both containers in the background – and that’s it. My app is
deployed to the test environment now and back on my laptop I can browse to the VM
in the cloud and use the application. This app is using exactly the same
Docker images so the behavior is the same as when I run it locally. I can add
a new set of user details and back in the VM, check the container logs and see
the output. This is how the deployment process works in Docker – you build the
image, push it to a registry and then use the same image to run your app in
different environments. When you deploy your app to production you’re running a
container from the same image that’s been tested and approved in all the QA
environments. The image I’m using as the base for my application is a public
image with ASP.NET 3.5 already configured. It’s tagged to a specific
release of Windows, and when Microsoft provide Windows patches they also push
updated versions of their Docker images. The way to apply Windows updates to an
app running in a container is to build a new image from the latest Windows base
image, and then replace your container with a new container from the new image.
My app is currently based on revision 1198 and if I check on Docker Store, there
is a later version available. 1480 will have hotfixes and
security patches, so to update Windows I just changed the FROM line in
the docker file to use the 1480 tag, and then build the image. I’ll use the same
image name so I can push this image up to my DTR repository, but I’ll use a
different version number in the tag. The very first instruction in the Dockerfile has changed now, so that breaks the cache for the rest of the layers and
Docker will execute all the instructions in the build. When it completes,
I push the image in the same way and here’s how it looks in DTR: the same
repository, but a new version of the application. To update
my test environment all I need to do is change the image version in the
Docker Compose file, specifying v3 instead of v2. Now I can repeat the
`docker-compose up` command. Docker Compose checks the desired state in the compose
file against the containers which are currently running. It sees that the
database definition is unchanged, so it leaves that container running. But the
web app definition has changed, so it stops the current container and starts a
new one. This is the update procedure when you have a single server running
apps on Docker. It’s fast, simple and safe and is easy to automate in a
continuous deployment pipeline, so there are no manual steps to deploy
application updates or to roll out Windows updates, to all your apps. Using a
single server does mean some downtime while the app is updated. In the few
seconds when the old container is stopped and the new one is being started,
there’s nothing running to process requests. But Docker supports zero
downtime updates in high availability environments, where you have multiple
servers running in a Docker cluster and I’ll show you that in the next video. At the start of this video I had my app
running in a Docker container on my laptop. Now I have the app running on a
server in the cloud using the exact same Docker image that I’ve tested locally. The image is stored in a private registry where I have fine-grained
control over who can access it, and Docker Trusted Registry has many more
features than I’ve had time to cover – like automated scanning for security
issues in your images, web hooks for triggering your own workflows, and
policies for automatically promoting images between repositories. Moving my
traditional app to Docker has made it easy to then move it to the cloud, using
a simple system test environment that just took a few minutes to create. In the
next video I’ll look at running that app in a more advanced staging environment,
with multiple docker servers running in a cluster. I’ll show you how Docker swarm
gives you zero downtime updates and how you can easily scale your app up and
down using containers. That’s coming in Part 4 of Modernizing .NET Apps for IT

3 comments on “Modernizing .NET Apps for IT Pros Part 3

  1. Thank you so much. Very beautiful. We can reduce lot of virtualization footprint with this approach. Request you to provide Docker containerization for Java apps.

Leave a Reply

Your email address will not be published. Required fields are marked *