Read, Write, Speak - Azure

Running ASP.Net Core 2.0 web application on Windows Azure Virtual Machine Scaleset (VMSS)

Mahesh M Kshirsagar — Tue, 27 Mar 2018 10:13:40 GMT

Introduction

Azure Virtual Machine Scale Sets (VMSS) is a group of virtual machines (VMs) that has identical software running on them. They are great for running workloads which require high scalability and availability. It provides a great option to run a workload which needs identical virtual machines (VMs). Common example of such a workload is a stateless web front-end or web API. It provides a good balance between IaaS and PaaS model by allowing to perform infrastructure operations such as remote desktop connection to individual VM or instance and provisioning other platform components such as virtual network (VNet), Load Balancer, Public IP address, etc. Just like virtual machines, VMSS can use either Windows or Linux as it's OS. ASP.Net Core 2.0 is an open-source and cross-platform .NET framework for building modern web applications. It provides a unified platform for building web UI and APIs. It can help author applications that can be hosted on IIS, Nginx, Apache or Docker. This flexibility makes it an ideal choice for creating applications that can be hosted on Azure. This post covers creating and running a ASP.Net Core 2.0 web application running on Windows VMSS. It covers common issues and their resolutions encountered in getting ASP.Net Core 2.0 applications deployed to VMSS. Sample application code is available at github location - https://github.com/Mahesh-MSFT/VMSSDemo

Deployment options

VMSS supports 2 main deployment options. They are –

VM Extension
Custom VM Image

Many developers are already familiar with VM Extension approach for post-production operations on individual VMs. It offers a great automation experience using tools such as DSC, Chef and Puppet. This same experience can be extended to VMSS as well. Creating a custom VM image is the most elaborative experience compared to creating a VM extension. This approach mostly used by IT teams to create "golden copies" of specialized software and ticking a checkbox in their BCDR checklist. Choosing an option makes a difference in how quickly or slowly scaling can be performed. For example, if an VM extension is created, for every new VM that is added in VMSS, needs to wait before it becomes available to take traffic for extension to get provisioned and become active. This makes scaling operation taking longer. On the other hand, although creating a custom image can be arduous task, creating a new VM with custom image and adding it to scaleset is very fast. This post uses Custom VM Image option to create a new VM using that image and adding it to scaleset.

Creating the Application

ASP.Net Core 2.0 has an impressive list of features that makes a web application richer. This post uses Razor Page Handler feature to display the current web server name by making a AJAX call. This ties back nicely with VMSS where this application will be running on all the VMs making up the VMSS. It will be simply displaying web server name that is serving the page. To create a ASP.Net Core 2.0 application, click File à New in Visual Studio. I am using Visual Studio 2017 in this post, but equivalent steps can also be used in other editors like VSCode. In subsequent dialog box, choose ASP.Net Core 2.0 as the framework and select "Web Application" as template. Resulting application will have a structure as outlined in "Solution Explorer" window below. In the Index.cshtml, I add a AJAX call to OnGetServerData function. To add interactivity to page, I call this function every second using Javascript. Server function OnGetServerData simply returns name of web server and current timestamp. When running locally, application loads with home page like below.

Setting up CI/CD workflow - Build

Deploying any application to Azure should be automated using CI/CD workflow. This helps to improve availability as there is no manual intervention involved. For deploying a ASP.Net Core 2.0 application to VMSS, there are following main steps involved.

Build web application and package it
Provision Web Server (IIS)
Install ASP.Net Core 2.0
Deploy application using WebDeploy
Configure application
Create a VMSS
Update VMSS (If already created)

This post will cover how each of the above steps is automated using Visual Studio Team Services (VSTS). All of these steps can be automated equally easy using other CI/CD tools such as Jenkins or TeamCity.

Build web application and package it

VSTS offers a pre-packaged build step for ASP.Net Core application as highlighted below. This template provides a standard 4 step process as shown below to build and publish the application.

Provision Web Server (IIS)

This step starts to prepare destination server. This post shows how to provision IIS server. However, there are similar steps that can be used to provision other web servers such as Nginx or Apache.

Install ASP.Net Core 2.0

There are 2 components needed to be installed for IIS on Windows servers.

.NET Core 2.0 SDK
.NET Core 2.0 Windows Server Hosting bundle

Following powershell script illustrates automating both steps. Note that download path and installable file name will change over the time. Script below uses download path and installable filename as of Feb-18.

Deploy application using WebDeploy

Earlier, step "Build web application and package it" will create a deployment package in the form of a single zip file. This zip file can be deployed on IIS server using WebDeploy. Powershell script to download installable and installing it as shown below.

Configure application

When deploying web application using WebDeploy, it gets deployed as a "Virtual Directory" and should be converted to a "Web Application". Script below shows how to do that. A consolidated script to automate steps discussed in earlier section is available here. It's to be checked-in as part of source code for use in build process. Updated build pipeline looks like as shown below. Note that A copy file task copies script from source code/folder to artifactstagingdirectory which is finally published as build output in "Publish Artifact" Step.

Setting up CI/CD workflow - Release

After Build artifacts are generated, it's time to deploy them VSTS offers a "Azure Virtual Machine Scale Set Deployment" task that can pick up build artifacts and deploy them on VMSS.

Deployment Process Task

This task uses Packer template. After adding this task, configure it as shown below. Key values to be configured are –

Packer Template: This should have value "Auto Generated". If you are authoring a custom template, it can be used as well. This post uses "Auto Generated".
Azure Subscription: A VSTS Service endpoint for Azure.
Storage Location: Pick from the Drop-down box.
Storage Account: Pick from a list that appears after providing Storage Location. Ensure that it exists before you can configure it here. Ensure that it is "general purpose" kind.
Resource Group: Resource Group where VMSS will be created. It should be same as Storage Account Resource Group.
Deployment Package: Enter path to deployment package obtained after Build process.
Deployment Script: Path to script in Deployment Package.

Build immutable machine image Task

This task uses the Packer template configured in above step. It adds few more parameters as discussed below. Key parameters to be configured are discussed below.

Base Image Source: This value can be "Gallery" or "Custom". This post uses "Gallery" which mean OS base image will be fetched from Azure MarketPlace.
Base Image: Choose Windows Version.
Additional Builder Parameters: Packer uses a default VM size of Standard_D3_v2 to create a VM image. This VM series may not be available in some regions. Packer's default configuration value can be changed by passing additional builder parameter as shown above. Here a "vm_size" parameter with value of "Standard_A2" is passed.
Image URL: This variable holds the blob storage location where actual image will be created. By using a variable, it's value can be used in subsequent steps.

Create a VMSS

Once the immutable image is created in above step, a script can be invoked to either create or update VMSS. Script is available in source code (createorupdatevmss.ps1). This script in essence calls following powershell cmdlets –

Update-AzureRmVmss -ResourceGroupName $rgname -Name $vmssName -VirtualMachineScaleSet $vmss (IF VMSS already exists!)
New-AzureRmVmss -ResourceGroupName $rgname -Name $vmssName -VirtualMachineScaleSet $vmss -Verbose; (IF VMSS doesn't already exists!)

Key parameter value above is "Script Arguments". Apart from resource location and resource group name, image URL which holds the image location is passed as an argument. When this script finishes running, a VMSS is created if it didn't exist before or is updated with new image if it existed already.

Common troubleshooting

Below are some common troubleshooting techniques to overcome issues that may surface with approach described above.

Enable Packer Logging

Packer does most of the processing to create images. Without a proper debugging assistance, it's a problem to identify what is happening and potentially going wrong. Image below shows how it's possible to enable Packer logging. Some common examples of issues that can be captured by enabling Packer logging are –

VM Size not supported in a region.
Site doesn't exist
The supplied password must be between 8-123 characters long and must satisfy at least 3 of password complexity requirements

To identify exact error description, download Build or Release log file and search for "error" word.

Use General Purpose Storage account to store VMSS image

Ensure that the storage account used to hold the VMSS image is of type "General Purpose".

Use Custom Image for VMSS

Ensure that when you run above script, VMSS (with MarketPlace image) is not created beforehand using portal. Approach described above works with VMSS created using custom image. If you start with a pre-created VMSS using MarketPlace image, you'll get following error. scaleset The property 'uri' cannot be found on this object. Verify that the property exists and can be set

Use a private VSTS agent over hosted VSTS agent

Approach explained above uses VSTS hosted agent. This is default VSTS agent. Note that this agent has a default timeout setting of 30 mins. Creating a VMSS image and applying it to a new or existing image can easily take more than 30 mins. Depending upon, at what point build or release process times out, you may encounter following error. A workaround is to manually run the last script by passing parameter values. vmsscreateorupdate.ps1 CreateOrUpdateScaleSet -loc '' -rgname '' -imageurl "

Choosing the right Kubernetes object for deploying workloads in Azure

Mahesh M Kshirsagar — Wed, 25 Oct 2017 13:17:31 GMT

I have published a blog series on AzureCAT guidance blog for choosing the right Kubernetes object for deploying workloads in Azure. It consists of following posts:

Part 1: This post covers setting up Kubernetes locally. It talks about minikube, kubectl, and so on.
Part 2: This post covers setting up a Kubernetes cluster in Azure using Azure Container Service (ACS). It covers deployment options in Azure, deployment process, and connecting to a cluster by using a proxy.
Part 3: This post is a high-level conceptual overview of Kubernetes. It covers various menu options in the Kubernetes dashboard.
Part 4: This post covers deploying the SQL Server back-end, including choosing the right deployment object for running a database, the actual deployment process, and the interaction with SQL Server from SQL Server Management Studio.
Part 5: This post covers deploying the ASP.Net Core web front-end, choosing the right deployment object, the actual deployment process, monitoring the cluster, and verification of the application working with the back-end.

Get started with this introductory post of the series.

Running Spring Boot Java application as a Microservice in Service Fabric

Mahesh M Kshirsagar — Thu, 22 Jun 2017 17:56:00 GMT

Spring Boot Framework is one of the popular frameworks to author RESTful APIs using Java. It is very commonly used alongwith Angular and Kafka to create distributed applications. In this series of posts, I'll cover how a Spring Boot application can be deployed and run as a microservice using Azure Service Fabric. Below is table of content for each post and what it covers.

Part 1: Creating a Spring Boot application and getting it to run locally.
Part 2: Getting this application deployed and running in local Service Fabric cluster.
Part 3: Deploying this application to Azure Service Fabric cluster using CI/CD pipeline defined in VSTS.
Part 4: Containerizing this application and getting it running as a container in Azure Service Fabric.

Source code for application is available at following GitHub locations.

Running Spring Boot Java application as a Microservice in Service Fabric - Part 4

Mahesh M Kshirsagar — Thu, 22 Jun 2017 17:44:50 GMT

This series so far covered how Service Fabric can run Spring Boot application using JAR file. It uses java.exe which is bundled along with application to run this JAR file. This post will cover a more elegant approach - using containers instead of a full runtime. Service Fabric already supports running Windows containers on Windows cluster and docker/linux containers on Linux cluster. With Hyper-V container support on roadmap, Service Fabric will be able to provide better isolation for multi-tenant applications where customers prefer to share nothing. Coming back to Spring Boot application, it can be either containerized to a linux container or windows container with just a single line change and I'll cover how soon. Lets start with windows container. To containerize Spring Boot application, add dockerfile at the same location as pom.xml file. Let's look at content inside.

1st line is commented out (denoted by #). It is actually a switch between linux and windows container. If comment is removed, it will generate a linux container image.
2nd line is base image on top of which new image of application will be created. In this example, base image is of openjdk for windows server core available on Docker Hub.
3rd line exposes port 8080 on container.
4th line adds jar file from target folder in source directory to container.
5th line configures java to run added jar file using -jar switch.

In Docker for Windows, switch to Windows container mode as shown below. Navigate to folder containing dockerfile and issue following command. This command is going to use dockerfile described above (denoted by . in the end) and create a container image called maksh/sbmappimagewin. Once this command completes successfully (This may take some time due to large size base image!). Run following command to verify new image is successfully created. Now run a container from this image using following command. Switch -d is for running command in detached mode. -p is for port mapping between host and container port. A new container with Id 9d* has been successfully created. Lets extract its IP address by executing following command. Command above executes ipconfig on container identified by 9d (2 initials that uniquely identifies this container). Copy the IP address and navigate to IP:PortNo combination. Spring Boot application is now running as a windows container locally. Next step is to push it to Docker Hub so that it can be used for deployment anywhere we want. Use docker login and push commands as illustrated below. Local image (maksh/sbmappimagewin) should be available in Docker Hub after push operation completes successfully. Now, this container image can be used to deploy application on service fabric. Open the Service Fabric VS Solution we created in part 2. Delete the "Code" folder from solution. Comment out the ExeHost section and add new ContainerHost section in ServiceManifest.xml file as shown below. Add additional section as shown below in ApplicationManifest.xml file. Repository credentials are same as the ones used to connect with Docker Hub and push container image. Ensure that EndpointRef refers to Endpoint Name as in ServiceManifest.xml file. Next, select the project in solution explorer, right click and select "Publish". In dialog box that appears, select Cloud.xml as Target profile and Connection endpoint pointing to Azure Service Fabric cluster. Verify that application is successfully deployed by navigating to Azure Service Fabric Explorer. Finally, verify application as well :-) There it is again - a Spring Boot application running as a container in Service Fabric.

Running Spring Boot Java application as a Microservice in Service Fabric - Part 3

Mahesh M Kshirsagar — Thu, 22 Jun 2017 17:43:51 GMT

Let'd do a quick summary of previous 2 posts. Part 1: Covered creating Spring Boot application using Eclipse Part 2: Covered deploying this application to service fabric on a local cluster. In this post, we'll take a look at how we can use Visual Studio Team Services (VSTS) for implementing CI/CD pipeline to deploy to Azure. Project which I was working on has been pushed to GitHub and I'll use it as a source control repository to start CI/CD process. Ensure that you copy JRE folder and following Service Fabric specific files to Sprint Boot application and keep them at same location as pom.xml.

JRE: Folder that we earlier copied inside Code folder in Service Fabric solution.
ApplicationManifest.xml
ApplicationParameters.xml
PublishProfile.xml
ServiceManifest.xml

Lets start with building CI/CD pipeline. Navigate to "Build" menu in VSTS home page and click "New" button. Select "Empty" as a template. Select the "Github" as source control repository. You can also choose from other options shown. Select repository and branch name. Next add a Maven Build as a task. Select the Maven version, path to pom.xml file and goal(package). Next add a "Copy Files" task to copy JAR file generated by previous Maven build step and configure as shown below. We will create a service fabric VS solution structure using CI/CD pipeline. Note target folder is in source location denoted by variable $(build.sourcesdirectory). Maven build step generates JAR file in this source directory location. Specify **/sbmartifact.jar in "Contents" box, which is JAR file name as mentioned in pom.xml file. Finally copy this jar file to a staging directory denoted by build variable $(build.artifactstagingdirectory). This is where we start to construct service fabric VS solution structure. Folder stucture specified here is Root/Package/JarApiSFAppPkg/Code. Next add task to copy JRE folder Add Copy ApplicationManifest.xml file task. Note target folder location. It's at root of the Package. Add Copy ServiceManifest.xml file task. Note target folder location. It's 1 level below root Package. Now copy ApplicationParameters.xml and PublishProfile.xml files. Finally, add a "Publish Build Artifact" task. Publish Root folder that was constructed by earlier tasks. After this build finishes its run, take a look at "Artifact Explorer". It should have all files and directories arranged as shown below. We now have got all the build artifacts ready for deployment to Azure. Let's see how we can deploy this application to Azure. There are 2 pre-requisites before we can get started with deployment.

A Service Fabric cluster already deployed in Azure. See these instructions for setting this up.
Azure Service Fabric Endpoint in VSTS. See these instructions for setting this up.

One above pre-requisites are fulfilled, lets go back to our build definition. Click Build & Release --> Releases--> +create release definition. Select "Azure Service Fabric Deployment" as a template. Select the "Source (Build Definition)" we just created from the drop-down. Ensure "Continuous deployment" checkbox is ticked. Click "Create" button and a screen as shown below should be presented. Populate values as shown below.

Application Package: This value should be Root/Package folder.
Cluster Connection: This value should be selected from drop-down. It is populated by azure service fabric endpoint set as pre-requisite.
Publish Profile: Should be used to connect with Azure based SF cluster. An example is shown below.
Applicaiton Parameters: It is referred from Publish Profile. Typically contains instance_count setting for service.

Now, deploy this release and verify all deploy steps are completed successfully. Navigate to Azure Service Fabric Explorer and verify application has got deployed successfully and cluster is healthy. Given that this application runs on port 8080, a load-balancing rule needs to be added to Sevice Fabric cluster in Azure as shown below. Once the load-balancing rule is added, verify that application is working as expected navigating to service fabric URL. There it is - a Spring Boot Fat Jar application running as a microservice in Service Fabric in Azure using CI/CD pipeline in VSTS. But there's more! in next part, I'll show how to containerize this application and run it in Service Fabric as a container.

Running Spring Boot Java application as a Microservice in Service Fabric - Part 2

Mahesh M Kshirsagar — Thu, 22 Jun 2017 17:43:09 GMT

Previous post covered creating a fat JAR application and running it locally. In this post we'll look at how we can run this JAR application as a microservice in Service Fabric. Service Fabric Plugin for Eclipse makes it very easy to deploy from Eclipse on Linux/Mac platforms as described here. If you are using Windows as a development/deployment platform you can use Visual Studio 2017 with Service Fabric SDK. In this post, I'll use Visual Studio 2017. Start Visual Studio and click File-->New. Select "Cloud" under Templates and "Service Fabric Application" on the right-hand side pane. In next dialogue, select "Guest Executable" as a service template. Folder location containing JAR file as "Code Package Folder" and name of service in "Service Name". Visual Studio creates a solution structure as shown below. Now, lets add the JAR file to "Code" folder shown above. To do so, right click it, select "Add an existing Item", navigate to folder containing JAR file and select it. Along with JAR, we also need to upload runtime to run this JAR file. Typically, this is JRE. It generally resides in the JDK installation folder (C:\Program Files\Java\jdk1.8.0_131). Simply copy this folder and paste it on "Code" folder in VS. After copy, solution structure in VS should look like below. Now, navigate to "ServiceManifest.xml" file in Service Fabric solution. Change following parameters as shown below.

Program: This should point to java.exe file in JRE folder that was copied.
Arguments: This should contain the -jar and path of the JAR filename relative to java.exe. They are arguments passed to java.exe when it starts.
WorkingFolder: This should be CodeBase.
Endpoint: Name a endpoint and provide protocol as HTTP and port no (8080) along with type(input).

Next open the "ApplicationManifest.xml" file and verify its settings as shown below. Pay attention to name, type of the Service. They should match in ServiceManifest and ApllicaitonManifest files. Click "Start" button in Visual Studio and wait for a successful deployment to local SF cluster. Navigate the local service fabric cluster endpoint at https://localhost:19080/Explorer/index.html#/ and validate application is deployed and running successfully. Application is now running on service fabric cluster. Verify by navigating to localhost:8080 and it should return the IP address. At this point, we can potentially deploy this application to Azure. However, let's see how we can implement a CI/CD pipeline to deploy to Azure in next post.

Running Spring Boot Java application as a Microservice in Service Fabric - Part 1

Mahesh M Kshirsagar — Thu, 22 Jun 2017 17:42:34 GMT

This post covers authoring a new Spring Boot application using Maven. Start Eclipse and start with File-->New-->Maven Project. Select convenient location to save. Select webapp as archetype. Provide a name for your application/JAR file. Navigate to pom.xml file thus generated. Change the packaging from WAR to JAR. Add additional sections for properties and dependencies. I am using Java 1.8 as depicted below. More dependencies will be added in dependencies section. 1st dependency to be added is Spring Boot Framework. Navigate to Spring Boot Website, click "PROJECTS". Select and copy parent and dependency sections for Maven. Paste copied content inside pom.xml file as shown below. Next add Tomcat Embed Jasper dependency. Ensure that a "Release" version is chosen before you copy the Maven config settings. Select Maven specific config settings. Add Spring Boot Tomcat Starter dependency. Ensure that "Release" version is selected. Copy Maven specific config setting and paste it to pm.xml. Next, add Maven plugin itself by navigating to Spring Boot Maven Plugin website. Copy plugin config setting as highlighted below. After copying 4 dependencies - Spring Boot Frameork, Tomcat Embed Jasper, Spring Boot Tomat Starter and Maven plugin - pom.xml file should look like as below. Now start writing some code :-) Add a Application class which will bootstrap application. Ensure that checkbox for creating public static void main is ticked. Skeleton of class should look something like below. Now add Spring specific attributes and routes so that class looks like below. In this example, I am simply returning HOST name as a JSON from our Spring Boot API. Now, let's clean the files and directories during compilation of application. Navigate to path where pom.xml file resides and issue mvn clean command as shown below. Now, lets build and package our fat JAR file. To do that, issue mvn install command as shown below. After a successful completion, following message should appear. A fat JAR file should be created in target folder as shown below. Lets run application by running following command. When it starts successfully, note down port number on which it has started. In my case, it is port 8080 as shown below. Navigate to localhost: and verify if application is running. We now have got a fat JAR spring boot application running locally. In next post, let's see how we can use Service Fabric to run this application.

Implementing Rolling Updates in Azure Container Service (ACS) with Docker Swarm using VSTS

Mahesh M Kshirsagar — Thu, 02 Mar 2017 16:23:26 GMT

Docker 1.13 was released recently. 1 of the important feature that came out of this release was simplified deployment using docker-compose file. Also debuted is new compose file v3. As of now(Feb-17), it is most current and recommended compose file format. To understand what new features this enables, refer to this link. A new configuration option, deploy, brings a lot of goodness to overall deployment(including rolling updates) process in swarm mode. In this post, I'll discuss this new configuration option and use it to implement rolling updates. Deploy configuration option is available ONLY in docker compose v3 file format. It has following sub-configuration options - mode: This option is used to determine how containers gets deployed on swarm cluster. There are 2 possible values: global and replicated. global value makes a instance of container to be deployed on every swarm node. replicated value makes swarm to ensure at least X instances (where X is value provided by replicas value) of containers are running at all times. replicas: It determines the number of containers running at any point in time. This setting works together with mode value of replicated. placement: It defines the placement constraints. They are useful in specifying conditions for containers such as OS requirements or node type. update_config: This setting determines how upgrade to a running service are applied. This is the core setting that drives rolling updates in Swarm mode. This option has following sub-options -

parallelism: This value determines how many containers are updated during upgrade.
delay: Amount of time to wait between last and next container upgrade.
failure_action: Action to take in case container upgrade fails. It can take any one of the 2 values (continue or pause). Default is pause.
monitor: Amount of time for which a container is monitored for failure.
max_failure_ratio: Percentage value between o.o and 1.0 to determine tolerance of upgrade faulure before entire deploy process is declated a failure.

resources: This value is used to set the constraints on resources a container is allowed to use. It is combination of reservation as well as limits. restart_policy: This value determines a service's restart behavior. labels: They are used to label the service. Now that we have looked at deploy configuration option, let's switch to Azure Container Service (ACS) and Docker Swarm. Up until now, docker-compose file is used with docker-compose command (docker-compose -up) as below. New guideline however is to use it with deploy command. This command is available as part of docker daemon (server) running in experimental mode. ACS, by default, doesn't deploy docker daemon in experimental mode. So first step is to spin up ACS with server in experimental mode. With Azure Container Service now open sourced, it is very easy to take a look at code, clone/fork it and use it to run the customized ACS engine in Azure. Instructions to run a customized ACS engine locally are specified here. After the source code is cloned locally, simplest option is to use "Docker for Windows" for ACS customization. There are few pre-requisites that needs to be in place first. These pre-requisites are discussed below. It is required to have local drive "Shared". This setting needs to be set as shown below. After clicking "Apply" button, copy the powershell command listed in the prompt. Once the drive is shared, execute the devenv.ps1 script. This script is available inside /scripts folder that comes along with ACS source code. Once the script execution is finished, a container is spun up and a console logged into it is available to execute further commands. Any IDE/Editor can now be used to change code as required. To enable ACS engine run with docker server in experimental mode, change \acs-engine\parts\configure-swarmmode-cluster.sh file as shown below. After code change, build the codebase again by executing following command. When build finishes, a customized ACS engine is locally available. Run acs-engine command on the prompt available to understand usage of the command. To get this local ACS engine deployed to Azure, use instructions available here. The process in nutshell has following key steps.

Install acs-engine locally. This step is already discussed above.
Generate SSH key
Edit the Swarm Mode example and fill in the blank strings
Generate the template
Deploy the output azuredeploy.json and azuredeploy.parameters.json

A swarm mode file (referred in step 2 above) is available at /acs-engine/examples folder in the source code. It typically looks as below and can be changed to suit requirements. Ensure that dnsPrefix value is different for maser and agent. It is also possible to change other values such as agent and master counts, VM sizes for both, SSH public key data, etc. This file is to be used to generate azure deploy template. Use following command to generate the template. Note that acs-engine simply takes the path of swarmmode.json file. After command successfully executes, it generates a folder called as _output. One more sub-folder (with name as hash of the SSH key is also created). This new sub-folder has following 3 files. azuredeploy.parameters file is to be modified to include an additional nameSuffix node as shown below. "nameSuffix": { "value": "" }, After changes, file looks something like below. To deploy to Azure, use 1 of the options as described here. Note that a resource group should be created before executing the command. Once the deployment to Azure finishes, verify that there are no failures in deploying any component inside resource group. Now connect to ACS cluster as described here and verify that server has experimental flag set as True. Now it is possible to use docker deploy command to deploy multi-container application. There is a very good guidance available on setting up CI/CD pipeline in VSTS (Visual Studio Team Services) for ACS with Docker Swarm. I followed instructions as given in that guidance except only 1 change. "Run shell commands on remote machine" task in the release tasks needs to be adjusted as below. Once the shell script in the release task is successfully executed, it is reflected in the release log as shown below. An important point to note here is that unlike docker-compose up command execution, which needs a docker-compose down command execution, which necessitates downtime, docker deploy command updates services (group of containers) without needing any downtime. Deploy configuration policy specified in the docker-compose file gives developers complete control over the update process. It is now possible to implement rolling updates using docker deploy and docker-compose file on Azure Container Service (ACS) with Docker Swarm. Use this github repository for accessing code/docker files used for implementing rolling updates.

Running SQL Server + ASP.Net Core in a container on Linux in Azure Container Service on Docker Swarm - Part 3

Mahesh M Kshirsagar — Tue, 14 Feb 2017 12:55:58 GMT

In previous post, I created an ASP.Net Core Container application interacting SQL Server Container. In this post, I'll port this application to Azure. I am going to use Azure Container Service (ACS) with Docker Swarm as orchestrator. Let me start by creating a ACS cluster. I've followed instructions as described here . Point to remember while setting up this cluster to allow running SQL Server as Container is to choose VMs with at least 4GB ob RAM. This is a pre-requisite to run SQL Server Container using Docker. With Docker Swarm as a container orchestrator, authoring microservice-style, multi-container application using docker-compose file is an easy process. Earlier, as described, in post 1, a SQL Server Container image was created and pushed to Docker Hub. Similarly, in post 2, an ASP.Net Core image was created and pushed to Docker Hub. A docker-compose file will use these 2 images to deploy application in ACS. A network is also needed so that both these containers can run from within same network. docker-compose file looks something like below. This file has got 2 services and 1 network defined. Each service is created from their respective image. XXXweb service uses ASP.Net Core image. It uses port 8080 on the container host and 80 on the container itself. It has dependency on other service, named sqlinux. This service resides in network 2t (short-form for 2 tier!). Other service is sqlinux. This service uses the SQL Server Container image. It runs on port 1433 on both container host as well as container. It also resides in network 2t. Connect to ACS cluster from Windows machine as instructed here. set the Docker Host variable on local Docker CLI environment using following command. With Docker Host set, It is easy to interact with ACS cluster in Azure from local machine. Any command executed after setting up DOCKER_HOST, gets executed on ACS cluster. Refer this to understand more on setting up this variable. Now navigate to the location where docker-compose file is available in command prompt. Execute following command to ensure that there are no services already running on ACS cluster. To deploy application, run following command. As can be see above, the instructions in docker-compose file are executed and 2 services and 1 network gets deployed to ACS. By running following command, verify if services are created as expected. This command shows state of the container and nodes along-with IP address where each service (container) is running. With the containers running as expected, its time to verify if the application is running. Grab the agent FQDN from the ACS dashboard. Append the port used for the ASP.Net Core app to it and hit enter. Application is now running in ACS using Docker Swarm as an orchestrator. This concludes this blog series on getting SQL Server and ASP.Net Core run in a container on Linux in Azure Container Service on Docker Swarm. Combination of SQL Server and ASP.Net Core is a very common to create enterprise applications. Being able to take this combination into world of containers is very important milestone. It is now easy to move such applications to either Linux or Windows platform. ACS offers even more productivity gain by abstracting away the infrastructure/orchestration concerns to deploy these application in Azure.

Running SQL Server + ASP.Net Core in a container on Linux in Azure Container Service on Docker Swarm - Part 2

Mahesh M Kshirsagar — Tue, 14 Feb 2017 12:55:43 GMT

In previous post, we looked at how to create and run SQL Server Container. I'll build on that and develop an ASP.Net Core application that can interact with database inside this container. Start with File-->New is Visual Studio 2015 and create an ASP.Net Core application. When all clicks finish, solution structure looks something like this. Ignore the Hubs folder. As some may have guessed, I am trying to do some SignalR stuff. But you can start with a plain ASP.Net Core application as well. Now to most important part, how to connect to SQL Server Container? Connecting to a container is no different than connecting to a SQL Server. From a .Net Core application,a connectionstring needs to be defined and used with a Data Access Library. I am going to use .Net Core's native SQL Server client library. Any one of the many options listed here can be used as well. Use Nuget Package Manager from the Visual Studio Solution and pull System.Data.SqlClient package. Once package is registered, define connectionstring. As in the past, there are many different ways of defining connectionstring. In this post, I am going to define inside my SQL Data Access class. Important part of this connectionstring is the value of "Data Source". It should be the name as defined by using --name switch when the container was created. In short, it should be name of the SQL Server Container. Use strong password as opposed to the one used above. Once connectionstring is defined, rest of queries can be implemented the way they are used to be defined. In my example, a INSERT block of C# code looks like below. With the Docker Support in Visual Studio, It is possible to run application straight from within Container instead of running it from IIS Express. One can see the docker commands getting executed in the command prompt when you run the application from Visual Studio. We now have got both SQL Server as well as ASP.Net Core application running inside containers. I am running these containers on my local machine using "Docker For Windows". I am simulating a Linux environment for these containers to run. I can verify if the SQL Server Container is really able to store the data by querying table from SSMS. Surely, I do see data getting into table inside SQL Server Container. Just like we did in last post, let's create and push the image for ASP.Net Core application. To create an image, use following docker file and put it in the same location as Visual Studio Solution file. Run the following command to create docker image. This image is now create on local machine. As in previous post, use docker push command to push it to Docker Hub. In the next post, we'll take this set up and run it inside Azure Container Service using Docker Swarm as an orchestrator.