For developers and organizations leveraging Azure, it’s not uncommon to encounter connectivity hiccups. Especially, when the need arises to link Azure DevOps or GitHub, housed externally, to a private network ensconced within Azure’s realm. Further complicating matters is the need to adhere to organizational security controls and specific requirements that ensure data integrity and security. If this sounds all too familiar, I have good news. There’s a solution that’s not only effective but also easy on the pockets!
Azure Container Instance (ACI): The Heart of the Solution
The answer lies in Azure Container Instance (ACI). Throughout this blog, we’ll be exploring the nitty-gritty of using ACI to deploy system base files directly into your isolated network domain within Azure.
Why Linux Azure Container Instance?
Our journey begins with the Linux version of Azure Container Instance. You might wonder why. The answer is twofold:
- Network Integration: We aim for our deployed solution to seamlessly merge with the isolated network group. This might be within the backbone group for those utilizing an advanced network topology. Alternatively, it can be placed in the central hub, effectively communicating with connected spoke networks.
- Network Isolation: At the time of writing this piece, only the Linux version offers support for virtual network support (a.k.a. network isolation). This feature is indispensable for ensuring a secure, unfettered connection.
Envisioning the Solution
So, what does our solution entail at a granular level?
We’re essentially penning our script to an app service environment. But not just any environment. Our focus is on the isolated variant within the App Service Environment (ASE). This environment provides an optimal blend of security and connectivity, ensuring our Azure DevOps and GitHub interactions are smooth and protected.
Moving Forward
In the subsequent sections, we’ll delve deeper into the implementation details. We’ll cover setting up the Linux Azure Container Instance, integrating with the Azure network, and writing to the isolated App Service Environment (ASE). By the end of this blog, you will have a comprehensive guide to setting up a robust, private connection from Azure DevOps to Azure, all the while ensuring optimal security and cost-efficiency.
Diving Deeper: Creating Containers in Virtual Subnets
A pivotal aspect of our solution lies in creating a container situated within a connected virtual subnet. This positioning ensures it can seamlessly communicate with services housed within the virtual network. But how does this fit into our Azure DevOps environment?
When deployment demands arise, the Azure DevOps environment will spring into action, initiating the necessary services. Upon successful deployment, there’s a strategic breakdown of the service. Here’s where our approach is slightly malleable:
Complete Tear Down: Our preferred modus operandi involves a total tear down post-deployment. It’s neat and ensures there’s no lingering service overhead.
Time-Efficient Strategy for Frequent Deployments: For those who find themselves deploying multiple times, there’s an alternative approach. Instead of tearing down after each deployment, automate the process such that the container gets deleted post working hours. This way, you not only save on time but also on operational overhead.
Deploying your App Service Container Instance from DevOps with Bicep module. We use the following module to deploy our Azure environment.
param containerName string
param imageName string = 'mcr.microsoft.com/azure-pipelines/vsts-agent:ubuntu-16.04-tfs-2018'
param cpuCores double = 1
param memoryGb double = 1.5
param location string = resourceGroup().location
resource aci 'Microsoft.ContainerInstance/containerGroups@2021-03-01' = {
name: containerName
location: location
properties: {
osType: 'Windows'
containers: [
{
name: containerName
properties: {
image: imageName
resources: {
requests: {
cpu: cpuCores
memoryInGb: memoryGb
}
}
}
}
]
}
}- Save the above code as
aci-deployment.bicep. - Use the Azure CLI/ DevOps YAML pipeline to deploy the Bicep file:
az deployment group create --resource-group <YourResourceGroup> --template-file aci-deployment.bicep --parameters containerName=<YourContainerName>
Starting the container from Azure DevOps:
To run the container using YAML commands as Docker CLI steps, you can use the docker run command. Below are the commands to start and stop a container using the mcr.microsoft.com/azure-pipelines/vsts-agent:ubuntu-16.04-tfs-2018 image
docker run -d --name vstsagent mcr.microsoft.com/azure-pipelines/vsts-agent:ubuntu-16.04-tfs-2018
docker run: This is the command to run a Docker container.-d: This option runs the container in detached mode (in the background).--name myservercore: Assigns the name “vstsagent” to the running container. You can replacemyservercorewith any name of your choice.- mcr.microsoft.com/azure-pipelines/vsts-agent:ubuntu-16.04-tfs-2018: This is the image you want to run.
Stopping the container from Azure DevOps:
To stop the container, you use the docker stop command followed by the container’s name or ID:
docker stop vstsagentReplace myservercore with the name you assigned to your container when you started it.
(optional) Removing the container from Azure DevOps:
If you want to remove the image itself (for instance, to pull a fresh version), you can do so with:
docker rmi mcr.microsoft.com/azure-pipelines/vsts-agent:ubuntu-16.04-tfs-2018We delete the container to ensure that no residual code snippets remain. While this step is discretionary, it is recommended for enhanced security.
Coming Up Next: Bridging Azure DevOps with ACI
Stay tuned for our upcoming deep dive, where we’ll illuminate the intricate steps of intertwining Azure DevOps with your freshly crafted ACI container. The journey won’t stop there! We’ll also guide you through establishing an Azure DevOps pool, ensuring the seamless and secure transfer of your files into your Azure environment. It promises to be an insightful expedition for those keen on bolstering their Azure expertise. Don’t miss it!
