6 Docker .NET App Templates to Get You Started on Containers (Part 1)

This is the first blog of a multi-part blog series that discusses the automated deployment of .NET applications on both Linux and Windows containers. 

In this blog, we will cover the deployment of very basic ASP.NET and ASP.NET MVC applications on Linux containers using HyperForm, a deployment automation platform that simplifies the application journey to containers. The blog covers six application templates that include NGINX and Apache HTTP for reverse proxy.
 
To run and manage the simple Docker ASP.NET "Hello MVC" and "Hello Web" applications on 18 different clouds and virtualization platforms (including HyperGrid, vSphere, OpenStack, AWS, Rackspace, Microsoft Azure, Google Compute Engine, DigitalOcean, IBM SoftLayer, etc.), make sure that you either:

• Sign Up for HyperForm SaaS: http://dchq.io, or
• Download HyperForm On-Premise Standard Edition for free: http://dchq.co/hyperform-on-premise.html

Background

Containerizing enterprise applications is still a challenge mostly because existing application composition frameworks do not address complex dependencies, external integrations, or application life-cycle management tasks post-provision.

HyperForm, available in hosted and on-premise versions, addresses all of these challenges and simplifies the containerization of enterprise applications through an advanced application composition framework that extends Docker Compose supporting:

• advanced plug-ins that can be invoked at more than 20 different lifecycle stages to enable service discovery, on-the-fly containerization, and application storage automation, and
• data injection to support complex application dependencies.

The Plug-ins framework, which relies on custom scripts that can be written in BASH, PowerShell, Perl, Ruby or Python, enables advanced application deployment and facilitates quick integration with any external service — including storage, networking, or monitoring solutions.

Once an application is deployed, a user can access monitoring, alerts and notifications, continuous delivery using Jenkins, application backups, scale in/out, in-browser terminal to access the containers, log viewing, and container updates using custom plug-ins.

Why Even Bother With Containers?

Containers have been the driving force behind efforts to accelerate software development, cloud migration, and the modernization of legacy applications. The main advantages of containers are:

• Application Portability: Docker containers run exactly the same on any Linux host. This eliminates the challenge of deploying applications across different compute infrastructure (e.g. local developer machine, vSphere VM, or in the cloud).
• Higher Server Density: The lightweight nature of containers allow developers to optimize server utilization for their application workloads by running more containers on the same host while achieving the same isolation and resource allocation benefits of virtual machines.

For developers who are still wondering what the exact differences are between virtual machines and containers, here’s a list of the key differences.

Application Storage Overhead

• Virtual Machines: Each application workload runs on a separate virtual machine, which typically needs Gigabytes of OS overhead
• Containers: Containers can run in isolation on the same physical or virtual machine — in which one common OS is used for all containers. The Docker Engine overhead is pretty small — i.e. megabytes.

Instantiation

• Virtual Machines: Boot up time of both the OS and the application.
• Containers:  Application instantiation time only – i.e. time to spin up Linux processes.

Resource Allocation

• Virtual Machines: Generally rigid. Virtual CPU and Memory are typically pre-allocated to a VM and are hard to change post-provision – depending on the virtualization platform or cloud provider used.
• Containers: Generally flexible. CPU and Memory maximum limits can be defined for containers if desired (using the cpu_shares and mem_limit parameters). By default, containers can continue to consume the resources available on the underlying machine. With HyperForm, the minimum limits for CPU and Memory can also be defined – allowing users to place application workloads on machines that have enough CPU and Memory resources. You can read more about this here: http://dchq.co/docker-compose.html#docker-nodejs. 

Building The Docker Images Using microsoft/aspnet:1.0.0-rc1-final

If you have a Dockerfile in your code repository for building your latest images, then you can use HyperForm to automate the building of the Docker image as well as pushing the new images to one of the registered Docker registries.

Of course, if you're using Docker Hub, then you have the option to use the Automated Builds feature. However, if you're using a private registry, then HyperForm can provide the needed image build automation.

The ASP.NET examples used in this blog were cloned from the official Microsoft projects on GitHub:

• https://github.com/aspnet/Home/tree/dev/samples/1.0.0-rc1-final/HelloMvc
• https://github.com/aspnet/Home/tree/dev/samples/1.0.0-rc1-final/HelloWeb

Once logged in to HyperForm (either the hosted DCHQ.io or on-premise version), a user can navigate to  Automate >  Image Build and then click on the  + button to create a new Dockerfile (Git/GitHub/BitBucket) image build.
Provide the required values as follows:

• Git URL: (e.g. https://github.com/dchqinc/docker-aspnet-hellomvc.git or https://github.com/dchqinc/docker-aspnet-helloweb)
• Git Branch: This field is optional, but a user can specify a branch from a GitHub project. The default branch is master.
• Git Credentials: A user can store the credentials to a private GitHub repository securely in HyperForm. This can be done by navigating to Cloud Providers and clicking on the + to select Credentials.
• Cluster: The building of Docker images is orchestrated through the HyperForm agent. As a result, a user needs to select a cluster on which an agent will be used to execute the building of Docker images. If a cluster has not been created yet, please refer to this section to either register already running hosts or automate the provisioning of new virtual infrastructure.
• Push to Registry: A user can push the newly created image on either a public or private repository on Docker Hub, Nexus, Artifactory, or Quay. To register a Docker registry account, a user should navigate to Cloud Providers and clicking on the + to select Docker Registries
• Repository: This is the name of the repository on which the image will be pushed. For example, our image was pushed to dchq/php-example:latest
• Tag: This is the tag name that you would like to give for the new image. The supported tag names in HyperForm include:
  • {{date}} — formatted date
  • {{timestamp}} — the full time-stamp
• Cron Expression: A user can schedule the building of Docker images using out-of-box cron expressions. This facilitates daily and nightly builds for users.
• Pre-Build Plugins and Post-Build Plugins: A user can execute plug-ins on the machines used to run the image builds (e.g. installing Linux libraries or running post image build cleanup scripts).
• Who can Manage: A user can mark this build as private or share it with other users or groups.

Once the required fields are completed, a user can click  Save.

A user can then click on the Play Button to build the Docker image on-demand.

Building The YAML-Based Application Templates That Can Re-Used On Any Linux Host Running Anywhere

HyperForm is fully compatible with Docker Compose.

The platform, however, provides core (optional) enhancements to Docker Compose supporting advanced plug-ins that can be invoked at more than 20 different lifecycle stages to enable service discovery, on-the-fly containerization, and application storage automation.

It also supports cross-image environment variable bindings, automatic container IP retrieval and injection, and additional parameters like mem_min, publish_all, cluster_size, and registry_id. The service discovery framework takes care of re-configuring the load balancers and other application components when a cluster is scaled in/out or when the containers are stopped/started.

To create an application template, a user can log into HyperForm (either the hosted  DCHQ.io or on-premise version), navigate to  Blueprints >  App/Machine and then click on the  + button to create a new Docker Compose template.

We have created six application templates for the basic ASP.NET "Hello MVC" and “Hello Web” applications but with different web servers for reverse proxy and load balancing.

Docker ASP.NET Hello MVC

aspnet-mvc:
  image: dchq/aspnet-hellomvc:latest
  mem_min: 50m
  host: host1
  publish_all: true
  cluster_size: 1

Docker ASP.NET Hello MVC with Nginx

nginx:
  image: nginx:latest
  publish_all: true
  host: host1
  mem_min: 50m
  plugins:
    - !plugin
      id: 0H1Nk
      restart: true
      lifecycle: on_create, post_scale_out:aspnet-mvc, post_scale_in:aspnet-mvc
      arguments:
        # Use container_private_ip if you're using Docker networking
        - servers=server {{aspnet-mvc | container_private_ip}}:5004;
        # Use container_hostname if you're using Weave networking
        #- servers=server {{aspnet-mvc | container_hostname}}:5004;
aspnet-mvc:
  image: dchq/aspnet-hellomvc:latest
  mem_min: 100m
  host: host1
  publish_all: false
  cluster_size: 1

Docker ASP.NET Hello MVC With Apache HTTP

http-lb:
  image: httpd:latest
  publish_all: true
  mem_min: 50m
  host: host1
  plugins:
    - !plugin
      id: uazUi
      restart: true
      lifecycle: on_create, post_scale_out:aspnet-mvc, post_scale_in:aspnet-mvc
      arguments:
        # Use container_private_ip if you're using Docker networking
        - BalancerMembers=BalancerMember http://{{aspnet-mvc | container_private_ip}}:5004
        # Use container_hostname if you're using Weave networking
        #- BalancerMembers=BalancerMember http://{{aspnet-mvc | container_hostname}}:5004
aspnet-mvc:
  image: dchq/aspnet-hellomvc:latest
  mem_min: 100m
  host: host1
  publish_all: false
  cluster_size: 1

Docker ASP.NET Hello Web

aspnet:
  image: dchq/aspnet-helloweb:latest
  mem_min: 50m
  host: host1
  publish_all: true
  cluster_size: 1

Docker ASP.NET Hello Web with Nginx

nginx:
  image: nginx:latest
  publish_all: true
  host: host1
  mem_min: 50m
  plugins:
    - !plugin
      id: 0H1Nk
      restart: true
      lifecycle: on_create, post_scale_out:aspnet, post_scale_in:aspnet
      arguments:
        # Use container_private_ip if you're using Docker networking
        - servers=server {{aspnet | container_private_ip}}:5004;
        # Use container_hostname if you're using Weave networking
        #- servers=server {{aspnet | container_hostname}}:5004;
aspnet:
  image: dchq/aspnet-helloweb:latest
  mem_min: 100m
  host: host1
  publish_all: false

Docker ASP.NET Hello Web With Apache HTTP

http-lb:
  image: httpd:latest
  publish_all: true
  mem_min: 50m
  host: host1
  plugins:
    - !plugin
      id: uazUi
      restart: true
      lifecycle: on_create, post_scale_out:aspnet, post_scale_in:aspnet
      arguments:
        # Use container_private_ip if you're using Docker networking
        - BalancerMembers=BalancerMember http://{{aspnet | container_private_ip}}:5004
        # Use container_hostname if you're using Weave networking
        #- BalancerMembers=BalancerMember http://{{aspnet | container_hostname}}:5004
aspnet:
  image: dchq/aspnet-helloweb:latest
  mem_min: 100m
  host: host1
  publish_all: false
  cluster_size: 1

Now that you've got the code, stay tuned to see how to use it. Join us next time as we take you through the ins and outs of setting up Docker for your .NET apps.