05. Deploying the Apps to ACI (Azure Container Instances)
Azure Container Instances (ACI) is the quickest way to have a Containers dev/test/staging environment where you can deploy single instances of containers.
This walkthrough shows you the main scenarios when deploying Windows Containers to Azure Container Instances (ACI) and how you can deploy eShopModernizing Apps into ACI.
Azure Container Instances makes it easy to create and manage Docker containers in Azure, without having to provision virtual machines or adopt a higher-level service. With ACI, you can directly deploy a Windows container in Azure and expose it to the internet with a fully qualified domain name (FQDN) in a matter of seconds (Provided that you have the Windows Container image ready in a Docker registry like Docker Hub or Azure Container Registry).
For further information on ACI, check the documentation here: https://docs.microsoft.com/en-us/azure/container-instances/
There can be variations about deploying the eShopModernizing apps into ACI such as deploying just one or all of the apps (MVC app, WebForms app or WCF service). In the following scenario shown below you can see the ASP.NET MVC app plus the SQL Server container both of them deployed as containers into ACI (Azure Container Instances).
The Azure Cloud Shell is a free interactive shell that you can use to run the Azure CLI steps in this walkthrough. It has common Azure tools pre-installed and configured to use with your Azure account.
The easiest way to launch the Azure Cloud Shell is by clicking on the Cloud Shell button on the menu in the upper right of the Azure portal, as shown in the image below:
Optionally, you can also use a local installation of the Azure CLI instead of Azure Cloud Shell.
If you choose to install and use the Azure CLI locally, make sure you are using the latest version of Azure CLI, at least Azure CLI 2.0.
Run az --version to find the version.
If you need to install or upgrade, see Install Azure CLI 2.0.
Azure container instances, like all Azure resources, must be placed in a resource group, a logical collection into which Azure resources are deployed and managed.
You can create a resource group with the az group create command from the Azure Cloud Shell or the Azure CLI.
The following example creates a resource group named eShopModernizedACI in the westus datacenter in Azure.
az group create --name YoureShopModernizedACIResGroup --location westus
Note: In production environments, we recommend to migrate/use Azure SQL Database which provides High Availability and many more PaaS features. However, for a Dev/Test environment, you can deploy a SQL Server container into ACI, as in this example.
In ACI, you can create a container by providing a name, a Docker image, and an Azure resource group to the az container create command. You can optionally expose the container to the internet by specifying a DNS name label. In the case of a SQL container you want to do that so we can access the databases, including from your dev PC by using SQL Server Management Studio.
Now, let's create your MSSQL container for the eShopModernizing apps with a command similar to the following:
az container create --image microsoft/mssql-server-windows-developer --resource-group YoureShopModernizedACIResGroup --location westus --name your-mssql-windows-eshop-container-group --os-type Windows --cpu 3 --memory 3.5 --dns-name-label your-eshop-sql --ip-address public --ports 1433 --environment-variables ACCEPT_EULA=Y SA_PASSWORD=YourSQLPassword --verbose
After a few seconds, the command's execution will respond with the container information, like in the following execution:
It is important to note that you won't be able to use the SQL container right away (that's why the initial state in the JSON response says "provisioningState": "Creating") so you'll need to wait a few minutes until the SQL image is pulled into ACI and the container is started. Then, it'll be ready to use.
You can check the state of the container/container-group with the command az container show like the following command:
az container show --name your-mssql-windows-eshop-container-group --resource-group YoureShopModernizedACIResGroup
The SQL container will be ready to use when you see the following in the response: "provisioningState": "Succeeded"
It is also important to find out what's its final public IP and fully qualified DNS name that you can find as part of the JSON response:
"ipAddress": {
"additionalProperties": {},
"dnsNameLabel": "your-eshop-sql",
"fqdn": "your-eshop-sql.westus.azurecontainer.io",
"ip": "25.91.35.39",
"ports": [
{
"additionalProperties": {},
"port": 1433,
"protocol": "TCP"
}
]
},
To view the container's logs you can run the following command where you can see that SQL Server was correctly started:
az container logs --resource-group YoureShopModernizedACIResGroup --name your-mssql-windows-eshop-container-group
At this point you should be able to see the SQL Server Windows Container in Azure's portal within your Azure Resource Manager resources, like here:
Finally, you could even connect to the SQL Server container in ACI with SQL Server Management Studio, as shown below:
Connect to the SQL Server container in ACI:
Browse SQL Server in the container at ACI:
You can delete the SQL container from ACI with:
az container delete --name your-mssql-windows-eshop-container-group --resource-group YoureShopModernizedACIResGroup
IMPORTANT SECURITY NOTE FOR THE SQL CONTAINER: Note that in this sample SQL Server container to be deployed in ACI, you are publishing the SQL Server port (1433) on a public IP with a related public DNS name. This is okay for a test if you want to access the SQL Server container from SQL Server Management Studio at your local dev machine, but for production-ready databases, you might want to use a secured and HA (High Available) database system like Azure SQL Database.
This walkthrough explains the steps on how to deploy the ASP.NET MVC app container into ACI, but very similar steps could be performed for the ASP.NET Web Forms app container or the WCF Service container.
As mentioned, you can create a container by providing a name, a Docker image, and an Azure resource group to the az container create command. You can optionally expose the container to the internet by specifying a DNS name label. In this case, since this is the Web application, you usually want to do this.
Now, let's create your ASP.NET MVC Windows Container from eShopModernizing with a command similar to the following:
az container create --image eshop/modernizedmvc --resource-group YoureShopModernizedACIResGroup --location westus --name mvc-windows-eshop-container-group --os-type Windows --cpu 2 --memory 1.5 --dns-name-label your-eshop-mvc --ip-address public --ports 80 --environment-variables UseMockData=False ConnectionString="Server=your-eshop-sql.westus.azurecontainer.io;Database=Microsoft.eShopOnContainers.Services.CatalogDb;User Id=sa;Password=YOUR_PASSWORD" UseCustomizationData=False UseAzureStorage=False --verbose
After a few seconds, the command's execution will respond with the container information, like in the following execution:
Again, you can check the state of the container/container-group with the command az container show like the following command:
az container show --name mvc-windows-eshop-container-group --resource-group YoureShopModernizedACIResGroup
The MVC container will be ready to use when you see the following in the response: "provisioningState": "Succeeded"
It is also important to find out what's its final public IP and fully qualified DNS name that you can find as part of the JSON response:
"ipAddress": {
"additionalProperties": {},
"dnsNameLabel": "your-eshop-mvc",
"fqdn": "your-eshop-mvc.westus.azurecontainer.io",
"ip": "26.93.141.238",
"ports": [
{
"additionalProperties": {},
"port": 80,
"protocol": "TCP"
}
]
},
Now, if you go again to your Azure Resource group in the portal, you should see both containers running in ACI:
At this point you should be able to run and see the MVC application in a browser, like here:
URL: http://your-eshop-mvc.westus.azurecontainer.io
The first time you run the MVC application, the eShopModernizedMVC application detects that the database still doesn't exist, but since the app is using the connection string provided as environment variable and it is pointing to the SQL Server container, the app creates the database the first time it runs by using C# code in the app based on Entity Framework Migrations. That's why the first execution of the MVC app takes longer than the next times. Once the app has the database created in the SQL Container any data operation in the MVC app like querying and persisting the data is working against the database in that SQL Server container in ACI.
Deploying Windows Containers with either SQL Server or full .NET Framework / ASP.NET into Azure Container Instances (ACI) is not quite as fast as deploying to a regular Docker Host (like a Windows Server 2016 with Windows Containers) because the Docker image has to be downloaded every time and the sizes of the SQL container image (15.1 GB) and the ASP.NET container image (13.9 GB) are significantly large, however it is much cheaper than maintaining your own docker host (permanently on-line Windows Server 2016 with Windows Containers VM in Azure).
As main conclusion, using Azure Container Instances is a very compelling option for Dev/Test scenarios and for CI/CD pipelines.
We have included ARM templates for deploying to Azure Container Instances, using standard ARM deployment instead of az container. In folder /ACI there are four files:
-
aci.json: Main ARM template -
webforms.parameters.json: ARM parameters file for webforms deployment -
mvc.parameters.json: ARM parameters file for MVC application deployment -
wcf.parameters.json: ARM parameters file for WCF service (part of NTier sample)
To install the appropiate application deploy the aci.json template and the corresponding parameters file:
az group deployment create --resource-group <my-resource-group> --parameters @<xxxx.parameters.json> --template-file aci.json