How To Get An Azure Container Instance Running Inside a VNet with a FileShare mount using Terraform

$C:\Dave\Storey$

3 min readOct 16, 2020

Introduction

Welcome dear readers, hopefully this blog post finds you well, and not as I was… ripping my hair out trying to get an ACI running within a VNet on Azure. I am sure most of you have probably seen the Azure docs about how to get this setup, am sure some of your have likely read the Terraform docs too and still been a bit confused.

Well fear not dear reader, I want to try and relieve any pain points here with my quick and simple guide.

First off if you haven’t read the official docs, I would recommend that you give them a quick skim, there is some useful notes in there even if they don’t mention Terraform

Storage

Nice and simple, I am going to create an Azure Storage Account, with a File share:

Nothing too crazy here right? cool. You can also add firewall rules to your storage if you wish, I didn’t just for the sake of simplicity, but the option is there if you wish.

The Subnet

Ok at this point I’m going to assume you have a VNet already setup, if you don’t then I would definitely say to take a look at the Terraform docs as this one is pretty straight forward. Alternatively if you want to get a VNet spun up with an OpenVPN gateway, then please take a look at this epic blog by my colleague Lawrence Gripper. With your VNet setup, lets create the subnet:

Please note here the following:

The subnet used by ACI must be empty of any resources other than ACI. This cryptically mentioned in passing here
We need to define the service_endpoints for storage
We also need to define the delegation object

Without these definitions the subnet will block the ACI from starting up correctly.

Network Security Group

Right, we have our storage, we have our subnet, lets lock it all down with a bit of security:

Great, we have now officially made it really difficult for ourselves and others to do anything, but thats a good thing, because security… right? :)

Key thing I would like to call out here is that the port 445 is opened. Why? Well because that is the port that the Azure File Share uses. If you miss that off then your container will fail to start as it cannot mount the storage account. We have also opened port 443, that my friends is because ACI uses https to pull images, if you block that then you will soon find out that you can’t pull anything down from your registry.

Final note here is that the application I was deploying listened on port 8000, hence why the port 8000 entry appears in the inbound rules.

Azure Container Instance

Last, but no means least, lets get the ACI spun up:

Few things to note here:

You need to create an azure_network_profile as this is how the ACI can see and work with the subnet.
ip_address_type must be set as Private
os_type must be Linux
If using an internal ACR then you should use the image_registry_credential as shown.
The volume attribute object allows you to wire up your ACI to your file share over the subnet.

Conclusion

I lost a lot of time here in the pitfalls of port numbers, image registry credentials, service delegation at the subnet and also the cryptic fact that the subnet must be empty of all resources except a container group. I hope that this blog, while simple and to the point, will help others work their way through this task with ease