Working with Containers

Integrating Azure Container Registry for Container Image management

Rohit Tatachar — Tue, 10 Oct 2017 12:07:24 GMT

As part of our Enterprise readiness for the Container based program, one key component is to integrate with a Container Registry (in our case the Azure Container Registry) which is a private repository of you Docker based Container Images. Integrating ACR into your CI/CD process further helps creating a secure End-End dev-ops model for Enterprise readiness. What is a Container Registry? Azure Container Registry is a managed Docker registry service based on the open-source Docker Registry 2.0. Create and maintain Azure container registries to store and manage your private Docker container images. Use container registries in Azure with your existing container development and deployment pipelines, and draw on the body of Docker community expertise. Some of the Advantages to ACR over other registries are below, for more details visit https://azure.microsoft.com/en-us/services/container-registry/:

Manage different types of Containers
Provides a private Repo accessible only to your Org
Repo instance available in same region/Datacenter as your data hence reducing latency

Key Concepts

Registry - Create one or more container registries in your Azure subscription. Each registry is backed by a standard Azure storage account in the same location. A fully qualified registry name has the form myregistry.azurecr.io.
Managed Registry - A tier that offers additional capabilities for registries in three SKUs - Basic, Standard, and Premium. The images in these SKUs are stored in Storage Accounts managed by the Azure Container Registries service, which improves reliability and enables new features.
Repository - A registry contains one or more repositories, which are groups of container images. Azure Container Registry supports multilevel repository namespaces. This feature enables you to group collections of images related to a specific app, or a collection of apps to specific development or operational teams. For example: rtrappscontainerregistry.azurecr.io/[Offerin]/[ServiceLine]/[Service]/[App Name]:[Build ID]
Image - Stored in a repository, each image is a read-only snapshot of a Docker container. Azure container registries can include both Windows and Linux images. You control image names for all your container deployments. Use standard Docker commands to push images into a repository, or pull an image from a repository.

Steps to Create ACR 1) Login to Azure Portal https://portal.azure.com/ 2) Click on “+” 3) Select ‘Azure container registry’ then Select it 4) In the ‘Azure Container Registry’ blade, enter the following information. Then click on ‘Create’ a) Registry name: A globally unique top-level domain name for your specific registry. In this example, the registry name is ‘myazurecontainerregistry1’, but substitute a unique name of your own. The name can contain only letters and numbers. b) Resource group: Select an existing resource group or type the name for a new one. c) Location: Select an Azure datacenter location where the service is available, such as South Central US. d) Admin user: If you want, enable an admin user to access the registry. You can change this setting after creating the registry. Steps to pull and push an image in Azure Container Registry 1) Open PowerShell shell as Administrator 2) Run below command to login to Azure Container Registry docker login myazurecontainerregistry1.azurecr.io -u demouser -p myPassword 3) Create a tag of the image to be pushed into Azure Container Registry The following command creates an alias of the image, with a fully qualified path to your registry. docker tag myApp myazurecontainerregistry1.azurecr.io/samples/myApp 4) Push the image to your Azure Container Registry docker push myazurecontainerregistry1.azurecr.io/samples/myApp 5) Pull the image from Azure Container Registry docker pull myazurecontainerregistry1.azurecr.io/samples/myApp

Optimizing legacy workloads using Containers

Rohit Tatachar — Tue, 03 Oct 2017 11:38:04 GMT

This blog links to another article that covers some of the optimization and related benefits that can be accrued by moving your legacy and older work load to Containers along with the direct benefits of modernization and agility. https://www.microsoft.com/itshowcase/blog/optimizing-microsoft-legacy-apps-containers/

Pre-Req Considerations and Quick Start guide to Containerizing legacy apps

Rohit Tatachar — Tue, 03 Oct 2017 11:17:28 GMT

Considerations: Some of the things to consider when looking at candidate legacy applications for Containerization

1	High	What are pre-requisites required to setup app into new box?
2	Medium	Which - .NET Frameworks Version required for app?
3	Medium	Does app use Authentication/Authorization? [Ad, AAD, custom...]
4	Medium	Does app use Session State / Data Persistence?
5	High	Does app do any kind of logging - Centralized/File system, Windows event log?
6	High	Does app use certificates?
7	High	Does app uses - Commercial/Professional Software (e.g. SharePoint, SQL Server, SAP, Oracle, Site core)?
8	Low	Does app has - Strict security / compliance requirements? (Need clarification on this questions)
9	Medium	Does app use Multiple disks?
10	Medium	Does app use Multiple web apps or virtual directory?
11	Medium	Does app require specific Registry Settings?
12	Medium	Does app utilize File Shares?
13	Medium	Does app require specific NTFS file/folder permissions?
14	Medium	Does app require Registering GAC / ActiveX components?
15	Medium	Does app require any 3rd party component like SMTP etc.?
16	Medium	Does app need DNS/IP mapping?
17	Medium	Does app require Multiple domain support?
19	Medium	Does app require Scheduled Task Support?
20	High	Does app have dependency? what are upstream/downstream apps?

Steps to Containerize an application

Copy the working bits to the folder.
Create a file and save it as “dockerfile”. * Without any extension.
Take the image you want to built for the docker file. “FROM microsoft/aspnet”
Copy the compiled files to the image “ADD .// "c:/inetpub/wwwroot/"”
Set the powershell as default shell for running the subsequent commands.
Install the IIS feature if required.
If required to enable or disable any property use the powershell commands.RUN Set-WebConfigurationProperty -filter /system.webServer/security/authentication/windowsAuthentication -name enabled -value true -PSPath IIS:\ ;
RUN Set-WebConfigurationProperty -filter /system.WebServer/security/authentication/AnonymousAuthentication -name enabled -value false -PSPath IIS:\ ;
If you want to add any user as the administrator you can use the command
If need to edit any registry use the commands like
RUN New-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\lsa -Name DisableLoopbackCheck -Value 1 -PropertyType DWORD -Force | Out-Null
Start the web service in the application..
RUN New-Website -Name 'Webapp' -Port 8086 \
-PhysicalPath 'c:\inetpub\wwwroot\WebApp' -ApplicationPool '.NET v4.5'
To expose the port from the container you can use EXPOSE 8086
If you want to execute some common script you want to start every time a container start
ENTRYPOINT ["Powershell", "C:/entrypoint.ps1"]
Where entrypoint.ps1 can be a file consisting of all the powershell commands required to run in the container for server setup
All this command can be composed into a single docker file and store it with the compiled code.\
After creation of the docker file create the image

Using the Windows EventViewer GUI to view Eventlogs in Containers

MarkBrianWest — Fri, 18 Aug 2017 16:45:00 GMT

If you work with legacy apps (or maybe some not so legacy apps) in containers then you know about what a pain it is to read the all important event log. In this post I'll present a passable pattern that is good enough for occasional use, like when initially deploying or diagnosing an in-production failure. Right up front: This is not ideal but it's not bad and it works. It's WAY better than viewing events in the Container CLI like I presented in here. If anybody knows how to remote the EventLog viewer right into the container please let me know and I'll update with credits. The sequence is:

We create a container with a shared volume and access the CLI on the container.
On the container CLI we do whatever stuff we need to do, for instance maybe install and start up a Windows Service.
Using the wevtutil utility, we snap a copy of the event log in which we are interested to a file on the shared volume.
We return to the container host to access the event log file and view in the EventViewer GUI
Repeat snap-read as necessary as you would do in the regular course of diagnostics

[on container host] Open a Powershell sesion Create a share directory mkdir c:\shared Create container with shared volume pointing to the c:\shared directory docker run -it --name winservcoret2 -v c:\shared:c:\shared microsoft/windowsservercore Since the container was started with the -it configuration, the PowerShell session will switch to the Container console [on container] Do things that create some events, then snap a copy of the event log to a file in the shared volume. In this case we snap the application log but you can snap any log present on the container. wevtutil epl Application C:\shared\AppLogBackup.evtx [on container host] Open c:\shared\AppLogBackup.evtx directly or open it from an existing EventViewer The Eventlog Viewer will open with the snapped event log We have a number of options for filtering the events that get written to the .evtx file, for example this script which boxes on start and end dates:

$start = '1/1/2016'
$end = '1/2/2017'
function GetMilliseconds ($date) {
     $ts = New-TimeSpan -Start $date -End (Get-Date)
     [math]::Round($ts.TotalMilliseconds)
     } # end function
$startDate = GetMilliseconds(Get-Date $start)
 $endDate = GetMilliseconds(Get-Date $end)
 wevtutil epl Application test.evtx /q:"*[System[TimeCreated[timediff(@SystemTime) >= $endDate] and TimeCreated[timediff(@SystemTime) <= $startDate]]]"

Getting IIS Win Auth to Work in a Container

MarkBrianWest — Mon, 31 Jul 2017 19:45:33 GMT

As you have no doubt figured out by now, containerization of IIS apps that use Windows Authentication to authenticate users is not as simple as referring to the gMSA of the app in the credentialspec of the Docker Run command. Two new things are needed: 1) association of the Service Principal Name with the gMSA and, 2) setting the hostname of the container to the name of the gMSA. tldr version: Assuming you have a gMSA named redmond\adonconnt1 and a container host named markw2016cont5.redmond.corp.microsoft.com 1) Use Setspn like this :

setspn -c -s HTTP/markw2016cont5 redmond\adoncontt1
setspn -c -s HTTP/markw2016cont5.redmond.corp.microsoft.com redmond\adoncontt1

2) Add the -h param to the docker run command like this:

docker run -it --name winautht1 -h adoncontt1 -p 81:80 -v c:\shared:c:\shared --security-opt "credentialspec=file://adoncontt1.json" microsoft/windowsservercore:latest

* It is mandatory that the argument for the -h parameter in the docker run command (in this example 'adoncontt1') be exactly the name of the gMSA (in this example 'adoncontt1'). Full version: I'll get to this in a day or two :-)

CI/CD of Containers from Visual Studio to Service Fabric

MarkBrianWest — Thu, 08 Jun 2017 10:12:33 GMT

CI/CD is all the rage for software deployment for good reason. Docker Containers are all the rage for software packaging and distribution for good reason. When the two are combined you get much more than the sum of the parts, they come together in a very natural way that suggests that they were created to act as one. We are not going to get into the details of all that here, there is plenty of coverage of that elsewhere. In this post we will be presenting the complete sequence of steps you can take to implement full CI/CD of containers from new or legacy source in Visual Studio to production in Azure Service Fabric. We will present a step by step sequence starting from scratch, and due to certain features being available only in pre production at this time (May 23 2017) you may be better off starting from scratch yourself even if you already have a running service fabric.

Prereqs

Windows 10
Azure Subscription
Visual Studio (Preview)

Steps

Obtain a Visual Studio Online account
Install Docker for Windows
Select an Azure Subscription
Create Azure Container Repository
Log in to Azure from Powershell
Create Key Vault
Create Certificate and Key
Import Certificate to local cert store
Create a Service Fabric Cluster
Edit load balancer
Create/open app
Add Docker support
Edit ports
Add solution to source control
Add CI/CD
Verify site access
Check In

Obtain a Visual Studio Online account

A Visual Studio Team Services account will be needed to facilitate the CI/CD automation

You may skip this step if you already have a Visual Studio Team Services account

1) Contact support at your workplace for details on using an in house instance of Visual Studio Team Services or Create an individual Visual Studio Team Services account at https://www.visualstudio.com/team-services/

Install Docker for Windows

1) Obtain Docker for Windows here https://www.docker.com/docker-windows, It is recommended that you install the stable version 2) Configure to run Windows Containers

Select an Azure Subscription

You will create all of your assets there: Container repository, Key Value, Service Fabric. Certain steps in this process will fail if you try to cross Subscriptions. Select one and stick with it throughout the entire process.

Create an Azure Container Registry

This is where the CI/CD workflow will store your containers for Service Fabric to reference. 1) Open https://portal.azure.com 2) Browse to New Service and select 'Azure Container Service' 3) Select the Azure Subscription chosen to contain all assets 4) Select 'Create' and wait for completion. For more information: https://docs.microsoft.com/en-us/azure/container-registry/

Log in to Azure from Powershell

Open an Administrator Powershell session. You will refer to this frequently so leave it open throughout the entire process. 1) Log in to Azure PS Login-AzureRmAccount 2) List your subscriptions Get-AzureRmSubscription 3) Change context to the subscription selected to contain all assets Set-AzureRmContext -SubscriptionId

Create a Key Vault

This is where the CI/CD workflow will store your key (from your certificate) for Service Fabric to reference. If you already have a key vault in the selected subscription then feel free to skip over this step. 1) Create resource group for key vault (provide your own values here) PS C:\WINDOWS\system32> New-AzureRmResourceGroup -Name mwkeyvaultrg -Location 'West US'

ResourceGroupName : mwkeyvaultrg
Location  : westus
ProvisioningState : Succeeded
Tags :
ResourceId  : /subscriptions/00f885db-ef1d-4545-ad2d-64c0caf93356/resourceGroups/mwkeyvaultrg

2) Create key vault (provide your own values here)

PS C:\WINDOWS\system32> New-AzureRmKeyVault -VaultName 'mwkeyvault' -ResourceGroupName 'mwkeyvaultrg' -Location 'West US' -EnabledForDeployment

Vault   : mwkeyvault
Resource Group   : mwkeyvaultrg
Location : West US
Resource   : /subscriptions/00f885db-ef1d-4545-ad2d-64c0caf93356/resourceGroups/mwkeyvaultrg/providers/Microsoft.KeyVault/vaults/mwkeyvault
Vault  : https://mwkeyvault.vault.azure.net
Tenant ID  : 72f988bf-86f1-41af-91ab-2d7cd011db33
SKU  : Standard
Enabled For Deployment?  : True
Enabled For Template Deployment? : False
Enabled For Disk Encryption?  : False
Access Policies  :
Tenant ID  : 72f988bf-86f1-41af-91ab-2d7cd011db33
Object ID  : 41df24f8-cbe5-4635-bde3-e15c54291f99
Application ID  :
Display Name  : Mark West (markwes@microsoft.com)
Permissions to Keys  : get, create, delete, list, update, import, backup,
restore, recover
Permissions to Secrets  : get, list, set, delete, backup, restore, recover
Permissions to Certificates : get, delete, list, create, import, update,
deleteissuers, getissuers, listissuers, managecontacts, manageissuers, setissuers

Create a Certificate and Key

You need to create a certificate and key in order to all the CI/CD workflow to interact with Service Fabric. In this step we will create a self-signed certificate and place copies in the local file system and the key store created above. Fetch ServiceFabricRPHelpers.psm1 from here: https://github.com/ChackDan/Service-Fabric/tree/master/Scripts/ServiceFabricRPHelpers. Place in a directory. in the example we will use C:\temp\ServiceFabricRPHelpers. 1) Select a directory in which to store certificates, in the example we will use C:\Data\Keys. 2) Return to the Administrator Powershell session opened above 3) Create variable for the following values (provide your own values here)

PS C:\WINDOWS\system32> $ResouceGroup = "mwkeyvaultrg"
PS C:\WINDOWS\system32> $VName = "mwkeyvault"
PS C:\WINDOWS\system32> $SubID = "00f885db-ef1d-4545-ad2d-64c0caf93377"
PS C:\WINDOWS\system32> $locationRegion = "westus"
PS C:\WINDOWS\system32> $newCertName = "cloudmsserfabt1cert1"
PS C:\WINDOWS\system32> $dnsName = "cloudmsserfabt1.westus.cloudapp.azure.com"
PS C:\WINDOWS\system32> $localCertPath = "C:\Data\Keys"

Navigate to parent folder of ServiceFabricRPHelpers.psm1, import, and run Invoke-AddCertToKeyVault

PS cd C:\temp\ServiceFabricRPHelpers
PS C:\temp\ServiceFabricRPHelpers> Import-Module ".\ServiceFabricRPHelpers.psm1"
PS C:\temp\ServiceFabricRPHelpers> Invoke-AddCertToKeyVault -SubscriptionId $SubID -ResourceGroupName $ResouceGroup -Location $locationRegion -VaultName $VName -CertificateName $newCertName -CreateSelfSignedCertificate -DnsName $dnsName -OutputPath $localCertPath

cmdlet Invoke-AddCertToKeyVault at command pipeline position 1
Supply values for the following parameters:
Password: ***
Switching context to SubscriptionId 00f885db-ef1d-4545-ad2d-64c0caf93332
Ensuring ResourceGroup mwkeyvaultrg in westus
Using existing valut mwkeyvault in West US
Creating new self signed certificate at C:\Data\Keys\cloudmsserfabt1cert1.pfx
Reading pfx file from C:\Data\Keys\cloudmsserfabt1cert1.pfx
Writing secret to cloudmsserfabt1cert1 in vault mwkeyvault

Name  : CertificateThumbprint
Value : 25AF2CDFE070D84D7548DFC5382EC73DB007F947

Name  : SourceVault
Value : /subscriptions/00f885db-ef1d-4545-ad2d-64c0caf93321/resourceGroups/mwkeyvaultrg/providers/Microsoft.KeyVault/vaults/mwkeyvault

Name  : CertificateURL
Value : https://mwkeyvault.vault.azure.net:443/secrets/cloudmsserfabt1cert1/ac8bf2e94fca4d0a88cc9e76d38f3a92

*** you will be prompted for the certificate password. Supply one and DO NOT FORGET IT. It is up to you to securely store the password by whatever mechanism you choose. Copy the values for CertificateThumbprint, SourceVault, and CertificateURL. You WILL NEED THESE later. More information: https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-cluster-creation-via-arm#create-key-vault

Import Certificate to local cert store

In this step we import the certificate and key into local certificate stores. You will need to import to both the Current User Store and The Local Machine Store. In the example we will demonstrate importing to The Current User Store and leave it up to you to repeat for The Local Machine Store. 1) Navigate to the directory used to store certificates. In our case we are using C:\Data\Keys. 2) Open the certificate file, in our case we are using C:\Data\Keys\cloudmsserfabt1cert1.pfx. A certificate import wizard will open. 3) Click Next, leave as is 4) Click Next, supply password specified in the Create a Certificate and Key step above, check 'Mark this key as exportable' checkbox 5) Click Next, leave as is 6) Click Next, then click Finish If all goes well you will see a success message. If not, see https://msdn.microsoft.com/en-us/library/bb950259(v=bts.10).aspx for more information.

Create a Service Fabric Cluster

Here we create a Service Fabric Cluster to house our containerized apps. As of this date (20170606) it is mandatory to choose a prerelease version of Service Fabric in order to support the CDT (CD/CD Tooling) extension in Visual Studio and that is what we will demonstrate. When the required features go GA, you will not be required to use a pre-release version. 1) Select WindowsServer 2016-Datacenter-with-Containers in the Operating system dropdown 2) Select the Select the Azure Subscription chosen to contain all assets in the Subscription dropdown 3) Select OK 4) Optional + Recommended : Supply an Application Insights key (ref) 5) Select Manual Fabric upgrade mode 6) Select latest preview, in our case 255.255.5718.255 (preview) 7) Select OK 8) Provide the exact values of CertificateThumbprint, SourceVault, and CertificateURL that you obtained in the Create a Certificate and Key step above. 9) Select OK 10) Select Create, wait for completion

Edit load balancer

We must configure the Azure Load Balancer of the Service Fabric in order to expose the application endpoint. 1) Open the Resource Group of the Service Fabric 2) Open the Load Balancer 3) Add a Health Probe (note port 80 to match the port of the containerized application) 4) Add a load balancing rule (note port 80 in and out to match the port of the containerized application). Alternate out ports may be specified to suit your desired configuration. Note the front end address of 13.64.109.163

Create/open app

1) With Visual Studio, open an existing app or create a new one. In our case we will create a new one based on classic ASP.NET Web Forms to fit the pattern of many legacy apps 2) Build and run the app to make sure it is working

Add Docker support

1) Right click on the project to bring up the context menu 2) Select Add -> Docker Support This will add a file called Dockerfile to the project and a project called docker-compose to the solution The Dockerfile is like a make file for containers

FROM microsoft/aspnet:4.6.2
ARG source
WORKDIR /inetpub/wwwroot
COPY ${source:-obj/Docker/publish} .

The docker-compose file contains a docker-compose.yml file which describes how containers work together in an application

version: '3'
services:
aspcontserfabcicdt5:
image: aspcontserfabcicdt5
build:
context: .\aspcontserfabcicdt5
dockerfile: Dockerfile

Edit ports

We need to edit both the Dockerfile and the docker-compose.yml files in order to expose the application port to the outside network. Without this step the application endpoints will not be reachable from a client outside of the Service Fabric. 1)Edit the Dockerfile to Expose port 80

FROM microsoft/aspnet:4.6.2
ARG source
WORKDIR /inetpub/wwwroot
COPY ${source:-obj/Docker/publish} .
EXPOSE 80

2) Edit the docker-compose.yml to map internal port 80 to external port 80

version: '3'
services:   aspcontserfabcicdt5:
image: aspcontserfabcicdt5
build:
context: .\aspcontserfabcicdt5
dockerfile: Dockerfile
ports:
 - '80:80'

3) Build the solution. *** If you get this error 'Volume sharing is not enabled. Enable volume sharing in the Docker CE for Windows Settings' then you need to switch Docker to run Windows Containers. See step

Add solution to source control

1) Hover over the server stack with red X icon at the bottom Visual Studio status bar, this is the CI/CD button. If your solution is not checked into source control then a tooltip will appear as shown here 2) Add your solution to your chosen Team Services repo

Add CI/CD

1) Click on the CI/CD Button -> Configure Continuous Delivery Provide the values in the dialog. 2) First select the subscription chosen in the Select an Azure Subscription step above. All other drop downs will populate allowing you to choose the Target Host and Container registry that you created earlier. 3) The Cluster Certificate Password is the Certificate password that you provided in the Create a Certificate and Key Step above. 4) Select OK. Visual Studio will now create a CI/CD pipeline for you in Team Services 5) Carefully watch the Output Panel for progress and error messages. The example below shows a successful pipeline creation along with information about the definitions which were created. You should record this information.

Setting up CI/CD for project aspcontserfabcicdt5 to Service Fabric Cluster cloudmsprerelt3.....................................done
The continuous build delivery setup for Team Project aspcontserfabcicdt5 completed successfully. Builds are now automatically generated and deployed to Service Fabric Cluster cloudmsprerelt3 upon code updates.
Details:
Service Fabric Cluster: cloudmsprerelt3 fabric:/aspcontserfabcicdt5
VSTS Team Project Name: aspcontserfabcicdt5
VSTS Team Project: https://markwest.visualstudio.com/aspcontserfabcicdt5
Build Definition: https://tfs.app.visualstudio.com/A8ecae3e6-5faf-4e4b-93b9-904d82a94a113/_permalink/_build/index?collectionId=8ecae3e6-5faf-4e4b-93b9-904d82a94a80&projectId=6a758b34-dcef-427f-ad15-92d80759a447&definitionId=10
Release Definition: https://markwest.visualstudio.com/6a758b68-dcef-427f-ad15-92d80759a455/_release?definitionId=1

6) Team Services will attempt to build and deploy immediately. Check the status of the workflows at the URL of the VSTS Team Project indicated above. In our case this is https://markwest.visualstudio.com/aspcontserfabcicdt5 Here we see the release was successful, which implies that the build was also successful.

Verify site access

It may take Azure an hour or more to deploy load balancer changes, so the changes made in the Edit Load Balancer step above may not yet be complete. The site URL will be inaccessible until after the load balancer changes have been fully deployed (i.e. you'll just have to wait).

1) Browse to the URL of the load balancer front end address, in this case https://13.64.109.163

Check In

The set-up and validation phase is now complete. From now on, whenever you push to the repo, the Build and Release will execute automatically. To trigger a new build and release changes, just commit + sync + push. At this point the code changes are checked in and the build and release processes are underway. A really great video which covers much of the Visual Studio portion of this process can be found at Get my ASP.NET 4 app running in containers in Azure

Five tips for moving virtual machine-based apps to Windows Server Containers

MarkBrianWest — Wed, 22 Mar 2017 19:30:04 GMT

Something with which I've been involved lately showed up on IT Showcase :-) Five tips for moving virtual machine-based apps to Windows Server Containers

Visual Studio 2017 : client version 1.22 is too old

MarkBrianWest — Mon, 13 Mar 2017 16:35:13 GMT

This might come in handy when building with Containers in Visual Studio 2017 I created a containerized asp.net core app and I got this exception: "

Microsoft.DotNet.Docker.CommandLineClientException: client version 1.22 is too old. Minimum supported API version is 1.24, please upgrade your client to a newer version

." on the first build right out of the gate using just what the IDE gave me from the output of the app template. This is on a Windows 10 platform with Docker For Windows:

Microsoft Windows [Version 10.0.14393]
(c) 2016 Microsoft Corporation. All rights reserved.
C:\Windows\system32>docker-compose version
docker-compose version 1.11.2, build f963d76f
docker-py version: 2.1.0
CPython version: 2.7.13
OpenSSL version: OpenSSL 1.0.2j  26 Sep 2016

You can get the details of your environment by typing docker-compose version at the command line.

I'll spare you the details of how and why, I fixed it by changing version:'2' to version:'2.1' in the two docker-compose project files that Visual Studio adds to your solution when you enable container support: docker-compose.ci.build.yml docker-compose.yml Your mileage may vary.

Remediate Multi-tenancy Port Collision -or- How I put Multiple Container Websites is a single VM / Scaleset

MarkBrianWest — Tue, 14 Feb 2017 13:38:37 GMT

Many apps (legacy and modern) provide service interfaces on TCP ports. Many of these service interfaces expect to reside on a well-known port, for example HTTP (80) and HTTPS(443). The current implementation of Windows Containers employs a port mapping mechanism to expose ports running on the container to access from outside the container, and any other access from the network to the container is blocked. All access to the services on the container must be made via a mapped port on the container host. Obviously port numbers cannot be shared by multiple services, so each service must map to a unique port number. This is usually a blocker, especially with HTTP clients which usually expect to operate on the well-known ports. We will demonstrate how to use the Azure Load Balancer to resolve this issue.

Step by Step

In this step-by-step we will:

create two containers running IIS on a container host in Azure
configure an Azure Load Balancer to reference the web sites on the containers

Create two containers running on a single Host. - start a Powershell admin session on the container host - Create two containers docker run -it --name Site1 -p 81:80 -v c:\shared:c:\shared microsoft/dotnet-framework:4.6.2 docker run -it --name site2 -p 82:80 -v c:\shared:c:\shared microsoft/dotnet-framework:4.6.2 In this example we will assume the following IP Addresses Container Host IP: 10.138.137.183 Internal IP: Site1 : 172.28.103.94 Internal IP: Site2 : 172.28.104.223

Load Balancer Configuration (Option 1: Azure Portal)

Front End IP Pool Each Tenant should have a Virtual IP created, and DNS configured to resolve to that Front IP. In the example below we have site1 and site2 setup with their individual Public IP's assigned from the Virtual network to which the Load balancer is connected. Backend Pools In the below example we have a single VM in the backend pool. To achieve HA and Load balancing, we would create multiple VMs in the same Availability set. The backend pool would be set to this Availability set. If the same container is placed on the hosts in the Availability set. Requests will be loaded balanced across those machines. Health Probes Each site on the container host has a container listening on the hosts port. We need to setup a probe for those ports. In the example below, we have a container running on Container IP: port 80, mapped to the Host IP: Ports 81 & 82, and the host has a site on port 80. The health probes will mark those Hosts as "up" if they are responding on these ports. Load balancing Rules Each Site will need a Load balancing rule to map the Virtual IP:port tuple to the HostIP: Port. Inside the container host the Host IP: port is mapped to the Container IP: port. In the example below we also route the Virtual IP:80 to the Host:80. We then route site 1 virtual IP and port 80 to the host: port 81, and site 2 virtual IP and port 80 to the host: port 82.

Load Balancer Configuration (Option 2: Azure Powershell)

Script: https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-get-started-ilb-arm-ps ---Create Script starts--- Connect to Subscription:

Login-AzureRmAccount
Select-AzureRmSubscription -Subscriptionid "GUID of subscription"
New-AzureRmResourceGroup -Name NRP-RG -location "West US"

Create Virtual IP and Backend Pool:

$frontendIP1 = New-AzureRmLoadBalancerFrontendIpConfig -Name LB-Frontend -PrivateIpAddress 10.0.2.5 -SubnetId $vnet.subnets[0].Id
$frontendIP2 = New-AzureRmLoadBalancerFrontendIpConfig -Name LB-Frontend -PrivateIpAddress 10.0.2.5 -SubnetId $vnet.subnets[0].Id

$beaddresspool= New-AzureRmLoadBalancerBackendAddressPoolConfig -Name "BackendPool" For RDP access to hosts:

$inboundNATRule1= New-AzureRmLoadBalancerInboundNatRuleConfig -Name "RDP1" -FrontendIpConfiguration $frontendIP -Protocol TCP -FrontendPort 3441 -BackendPort 3389
$inboundNATRule2= New-AzureRmLoadBalancerInboundNatRuleConfig -Name "RDP2" -FrontendIpConfiguration $frontendIP -Protocol TCP -FrontendPort 3442 -BackendPort 3389

Create Health Probes and IB rules:

$healthProbe0 = New-AzureRmLoadBalancerProbeConfig -Name "Port80"  -Protocol tcp -Port 80 -IntervalInSeconds 15 -ProbeCount 2
$healthProbe1 = New-AzureRmLoadBalancerProbeConfig -Name "Port81"  -Protocol tcp -Port 81 -IntervalInSeconds 15 -ProbeCount 2
$healthProbe2 = New-AzureRmLoadBalancerProbeConfig -Name "Port82"  -Protocol tcp -Port 82 -IntervalInSeconds 15 -ProbeCount 2

$lbrule = New-AzureRmLoadBalancerRuleConfig -Name "Host" -FrontendIpConfiguration $frontendIP1 -BackendAddressPool $beAddressPool -Probe
$healthProbe1 -Protocol Tcp -FrontendPort 8080 -BackendPort 80

$lbrule = New-AzureRmLoadBalancerRuleConfig -Name "Site1" -FrontendIpConfiguration $frontendIP1 -BackendAddressPool $beAddressPool -Probe
$healthProbe1 -Protocol Tcp -FrontendPort 80 -BackendPort 81

$lbrule = New-AzureRmLoadBalancerRuleConfig -Name "Site2" -FrontendIpConfiguration $frontendIP2 -BackendAddressPool $beAddressPool -Probe
$healthProbe1 -Protocol Tcp -FrontendPort 80 -BackendPort 82

---Create Script ends--- ---Add Script starts--- Connect to Subscription:

Login-AzureRmAccount
Select-AzureRmSubscription -Subscriptionid "GUID of subscription"

Create Virtual IP and Health Probe:

$Subnet = Get-AzureRmVirtualNetwork -Name [vnet name]  -ResourceGroupName ERNetwork | Get-AzureRmVirtualNetworkSubnetConfig –Name "subnet-1"

Get-AzureRmLoadBalancer -Name [ilbname]  -ResourceGroupName [resource group name] | Add-AzureRmLoadBalancerFrontendIpConfig -Name "Site3" -Subnet $Subnet | Set-AzureRmLoadBalancer

$ilb = Get-AzureRmLoadBalancer -Name [ilb name] -ResourceGroupName [resource group name] $beaddresspool= get-AzureRmLoadBalancerBackendAddressPoolConfig -Name "BackendPool" -LoadBalancer $ilb

add-AzureRmLoadBalancerProbeConfig -Name "Port83"  -Protocol tcp -Port 83 -IntervalInSeconds 15 -ProbeCount 2 -LoadBalancer $ilb

$ilb | Set-AzureRmLoadBalancer Create the LB rule: $healthProbe3 = Get-AzureRmLoadBalancerProbeConfig -Name "Port83" -LoadBalancer $ilb $frontIP3 = Get-AzureRmLoadBalancerFrontendIpConfig -Name site3 -LoadBalancer $ilb

$ilb | add-AzureRmLoadBalancerRuleConfig -Name "site3" -FrontendIPConfiguration $frontIP3 -Protocol "Tcp" -FrontendPort 80 -BackendPort 83 -BackendAddressPool $beaddresspool -Probe $healthProbe3

$ilb | Set-AzureRmLoadBalancer ---Add Script ends---

Test Site Access

All three sites should be available from the network on port 80 Host Site: https://10.138.137.183:80 Container Site1: https://10.138.137.166:80 Container Site2: https://10.138.137.170:80

Manage IIS on a Container with the IIS Admin Console

MarkBrianWest — Tue, 14 Feb 2017 12:36:21 GMT

Many legacy apps are based on IIS and ship with documentation which describes deployment and management operations primarily via the IIS Manager. This console is a GUI. Windows Containers do not support any form of GUI, so all ‘local’ operations must be performed via a command line interface. We will demonstrate how to prepare containers for IIS administration via a remote instance of the IIS Manager.

Step by Step

In this step-by-step we will:

create a container based on an image with IIS already installed
add remote IIS admin support to the container
connect to the IIS admin console on the container host to the IIS Admin Service service the container

On the container host: - Open a PowerShell admin session - Start interactive container - With .net 3.5 - docker run -it --name frame35 cd\-v c:\shared:c:\shared microsoft/dotnet-framework:3.5 - with .net 4.6.2 - docker run -it --name frame46 -v c:\shared:c:\shared microsoft/dotnet-framework:4.6.2 - or start detached and then attach to container - docker run --name -d=true -v c:\shared:c:\shared microsoft/windowsservercore:latest docker attach Note: To add Active Directory support to any container, add --security-opt "credentialspec=file://.json" to the docker run command line. See for more details. i.e.

docker run -it --name frame46 -v c:\shared:c:\shared --security-opt "credentialspec=file://adoncontt1.json" microsoft/dotnet-framework:4.6.2

This will switch the console from container host to container. This is now the 'container console'. From container console: Start Admin PowerShell Powershell - Install IIS + IIS Management Install-WindowsFeature -name Web-Server -IncludeManagementTools - Install IIS Management Service Dism /online /enable-feature /featurename:IIS-ManagementService /all - Enable remote access New-ItemProperty -Path HKLM:\software\microsoft\WebManagement\Server -Name EnableRemoteManagement -Value 1 -Force --- optional - add any or all of these features ---------------------------- Import-Module Dism

Enable-WindowsOptionalFeature -Online -FeatureName IIS-WebServerRole
Enable-WindowsOptionalFeature -Online -FeatureName IIS-WebServer
Enable-WindowsOptionalFeature -Online -FeatureName IIS-CommonHttpFeatures
Enable-WindowsOptionalFeature -Online -FeatureName IIS-HttpErrors
Enable-WindowsOptionalFeature -Online -FeatureName IIS-HttpRedirect
Enable-WindowsOptionalFeature -Online -FeatureName IIS-ApplicationDevelopment
Enable-WindowsOptionalFeature -Online -FeatureName IIS-NetFxExtensibility
Enable-WindowsOptionalFeature -Online -FeatureName IIS-NetFxExtensibility45
Enable-WindowsOptionalFeature -Online -FeatureName IIS-HealthAndDiagnostics
Enable-WindowsOptionalFeature -Online -FeatureName IIS-HttpLogging
Enable-WindowsOptionalFeature -Online -FeatureName IIS-LoggingLibraries
Enable-WindowsOptionalFeature -Online -FeatureName IIS-RequestMonitor
Enable-WindowsOptionalFeature -Online -FeatureName IIS-HttpTracing
Enable-WindowsOptionalFeature -Online -FeatureName IIS-Security
Enable-WindowsOptionalFeature -Online -FeatureName IIS-URLAuthorization
Enable-WindowsOptionalFeature -Online -FeatureName IIS-RequestFiltering
Enable-WindowsOptionalFeature -Online -FeatureName IIS-IPSecurity
Enable-WindowsOptionalFeature -Online -FeatureName IIS-Performance
Enable-WindowsOptionalFeature -Online -FeatureName IIS-HttpCompressionDynamic
Enable-WindowsOptionalFeature -Online -FeatureName IIS-WebServerManagementTools
Enable-WindowsOptionalFeature -Online -FeatureName IIS-ManagementScriptingTools
Enable-WindowsOptionalFeature -Online -FeatureName IIS-IIS6ManagementCompatibility
Enable-WindowsOptionalFeature -Online -FeatureName IIS-Metabase
Enable-WindowsOptionalFeature -Online -FeatureName IIS-HostableWebCore
Enable-WindowsOptionalFeature -Online -FeatureName IIS-CertProvider
Enable-WindowsOptionalFeature -Online -FeatureName IIS-WindowsAuthentication
Enable-WindowsOptionalFeature -Online -FeatureName IIS-DigestAuthentication
Enable-WindowsOptionalFeature -Online -FeatureName IIS-ClientCertificateMappingAuthentication
Enable-WindowsOptionalFeature -Online -FeatureName IIS-IISCertificateMappingAuthentication
Enable-WindowsOptionalFeature -Online -FeatureName IIS-ODBCLogging
Enable-WindowsOptionalFeature -Online -FeatureName IIS-StaticContent
Enable-WindowsOptionalFeature -Online -FeatureName IIS-DefaultDocument
Enable-WindowsOptionalFeature -Online -FeatureName IIS-DirectoryBrowsing
Enable-WindowsOptionalFeature -Online -FeatureName IIS-WebDAV
Enable-WindowsOptionalFeature -Online -FeatureName IIS-WebSockets
Enable-WindowsOptionalFeature -Online -FeatureName IIS-ApplicationInit
Enable-WindowsOptionalFeature -Online -FeatureName IIS-ASPNET
Enable-WindowsOptionalFeature -Online -FeatureName IIS-ASPNET45
Enable-WindowsOptionalFeature -Online -FeatureName IIS-ASP
Enable-WindowsOptionalFeature -Online -FeatureName IIS-CGI
Enable-WindowsOptionalFeature -Online -FeatureName IIS-ISAPIExtensions
Enable-WindowsOptionalFeature -Online -FeatureName IIS-ISAPIFilter
Enable-WindowsOptionalFeature -Online -FeatureName IIS-ServerSideIncludes
Enable-WindowsOptionalFeature -Online -FeatureName IIS-CustomLogging
Enable-WindowsOptionalFeature -Online -FeatureName IIS-BasicAuthentication
Enable-WindowsOptionalFeature -Online -FeatureName IIS-HttpCompressionStatic
Enable-WindowsOptionalFeature -Online -FeatureName IIS-ManagementConsole
Enable-WindowsOptionalFeature -Online -FeatureName IIS-ManagementService
Enable-WindowsOptionalFeature -Online -FeatureName IIS-WMICompatibility
Enable-WindowsOptionalFeature -Online -FeatureName IIS-LegacyScripts
Enable-WindowsOptionalFeature -Online -FeatureName IIS-LegacySnapIn
Enable-WindowsOptionalFeature -Online -FeatureName IIS-FTPServer
Enable-WindowsOptionalFeature -Online -FeatureName IIS-FTPSvc
Enable-WindowsOptionalFeature -Online -FeatureName IIS-FTPExtensibility

--------------------------------- - Stop Services

net stop Iisadmin
net stop W3svc
net stop wmsvc

- Start Services

net start Iisadmin
net start W3svc
net start wmsvc

- add admin user

net user   /ADD
net localgroup administrators  /add

Open another PS admin session on the container host, this will be the new 'container host console' From container host console: - List containers Docker ps - Note containerID - Find container IP address docker inspect -f "{{ .NetworkSettings.Networks.nat.IPAddress }}" This will display the container IP address, copy it. From container host desktop: - Start IIS manager console - Select 'Connect to a Server', Connect to container IP address - Provide the and provided above in [net user /ADD] - Click on Next. You will get a certificate error dialog - Click 'View Certificate'. You will get a 'Certificate' Dialog - Click 'Install Certificate'. You will get a certificate import wizard - Select 'Local Machine', click 'Next' - Select 'Place all certificates in the following store', click 'Browse', select 'Trusted Root Certification Authorities', click 'OK', nick 'Next' Click 'Finish' - Click 'Cancel' - Click 'Next'. The screen below indicates success. Others screens may indicate error. - You may now administer the IIS service running on the container from the IIS admin console running on the container host.