Using Bicep, we can deploy and manage all the resources required for our Azure Container Apps. In this post, we'll write a Bicep template that defines all the infrastructure required for our Container App and deploys it using the AZ CLI. In our Bicep template, we'll be deploying the following resources: A Log Analytics workspace. Azure Container Registry An Azure Container App Environment A Container App. Before we kick this off, it's to note that Container Apps is ! That means what I publish in my present might/will change in your future! One example of this is that the namespace that Container Apps currently reside in will be changing in March 2022, as referenced in ( ) REALLY IMPORTANT currently in preview this GitHub issue Note to self, update this article! Creating our Container App resources in Bicep Bicep is a domain-specific language that we can use as Infrastructure as Code (IaC) that Microsoft created to deploy Azure resources. Bicep code is compiled to ARM templates and in my opinion, is a lot nicer to work with than ARM. To work with Bicep, there's a fantastic that we can use to work with Bicep. Open up Visual Studio Code and click the tab. Enter into the search bar and you should see the extension. Visual Studio Code extension extensions Bicep To work with Bicep, you'll also need to have Azure CLI version 2.20.0 or later. Check out for more details on how to get Bicep set up on your machine. this page Now that we have everything set up, we can start writing our Bicep templates with all the resources we need for our Container Apps. Log Analytics Container Apps gathers data about your container app and stores it in Log Analytics. We can write single text strings or a line of serialized JSON data to Log Analytics. For our Container App, we'll need to create a Log Analytics workspace to send our Container Apps logs to. @description('Name of the log analytics workspace')
param logAnalyticsName string

resource logAnalytics 'Microsoft.OperationalInsights/workspaces@2021-12-01-preview' = {
  name: logAnalyticsName
  location: location
  properties: {
    sku: {
      name: 'PerGB2018'
    }
  }
} In this resource block, we're creating our Log Analytics workspace, providing it with the name of the workspace using a parameter, a location (which I'll discuss in a bit) and the SKU defined in the properties block. Azure Container Registry Next up we will need to create an Azure Container Registry. In future posts, I'll show you how we can pull images from our container registry and deploy it to a Container App. But for now, we can create our Container Registry in Bicep like so: @description('Name of the connected Container Registry')
param containerRegistryName string

resource containerRegistry 'Microsoft.ContainerRegistry/registries@2021-12-01-preview' = {
  name: containerRegistryName
  location: location
  sku: {
    name: 'Basic'
  }
  properties: {
    adminUserEnabled: true
  }
} Here, I'm giving my ACR instance a name via a parameter, deploying it in the same location as my Log Analytics workspace, setting the SKU to basic, and then enabling the Admin User. Usually, we do this. Instead, we'd create a managed identity for our Container Registry and our Container App, and then assign a to our Container App of 'AcrPull' which will allow our Container App to pull images from our registry. shouldn't role At the time of writing, however, managed identities can't be created for our Container Apps, so as a workaround, we'll enable the admin user in our container registry and use the login to authorize our Container App to pull images from the registry. Azure Container App Environment Let's move onto creating an environment for our Container Apps. Individual Container Apps are deployed to a single . The environment acts as a secure boundary around groups of container apps. Container Apps environment Container Apps in the same environment are deployed to the same virtual network and they write logs to the same Log Analytics workspace. For our Bicep template, we'll define our Container App environment and configure it to send logs to our Log Analytics workspace that we've just defined. @description('Name of the Container App Environment')
param containerAppEnvName string

resource containerAppEnvironment 'Microsoft.Web/kubeEnvironments@2021-03-01' = {
  name: containerAppEnvName
  location: location 
  kind: 'containerenvironment'
  properties: {
    environmentType: 'managed'
    internalLoadBalancerEnabled: false
    appLogsConfiguration: {
      destination: 'log-analytics'
      logAnalyticsConfiguration: {
        customerId: logAnalytics.properties.customerId
        sharedKey: logAnalytics.listKeys().primarySharedKey
      }
    }
  }
} Here we're providing a name for our Container Apps environment with a parameter and deploying it in the same location as our other resources. For this Container Apps environment, we are disabling the internal load balancer, because we're not working with a vNET for this environment. We can set this flag to to make this environment visible only within the vNET subnet, but that's out of scope for this article. true We set the environment type to as this is the only supported type for Container App Environments. We then configure our environment to send logs to Log Analytics with the block. Here we use the and the , which we can access as outputs of our resource. managed logAnalyticsConfiguration customerId primarySharedKey logAnalytics To see what else we can configure when creating Container App Environments in Bicep, check out the template reference . here Container App We now have an environment that we can deploy our Container Apps to, so let's write up some Bicep for a single Container App. @description('Name of the TodoApi Container App')
param todoApiContainerName string

resource todoApiContainerApp 'Microsoft.Web/containerApps@2021-03-01' = {
  name: todoApiContainerName
  location: location
  properties: {
    kubeEnvironmentId: containerAppEnvironment.id
    configuration: {
      ingress: {
        external: true
        targetPort: 80
        allowInsecure: false
        traffic: [
          {
            latestRevision: true
            weight: 100
          }
        ]
      }
      registries: [
        {
          server: containerRegistry.name
          username: containerRegistry.properties.loginServer
          passwordSecretRef: 'container-registry-password'
        }
      ]
      secrets: [
        {
          name: 'container-registry-password'
          value: containerRegistry.listCredentials().passwords[0].value
        }
      ]
    }
    template: {
      containers: [
        {
          name: todoApiContainerName
          image: 'mcr.microsoft.com/azuredocs/containerapps-helloworld:latest'
          resources: {
            cpu: '0.5'
            memory: '1Gi'
          }         
        }
      ]
      scale: {
        minReplicas: 1
        maxReplicas: 1
      }
    }
  }
} There's quite a bit happening here so let's break it down a bit: Starting with the basics, I'm giving my Container App a name that I will set as a parameter and deploying it in the same location as the rest of my resources. We then move onto our Container App-specific properties. We need to provide the resource ID of the Container App's kubeEnvironment to tell our Bicep code that this Container App belongs to our Container App environment. We do this by accessing the ID as an output of our resource. containerAppEnvironment Within our block, we're enabling external Ingress and setting our target port for this Container to port 80. We deny insecure traffic and set the traffic level to our latest revision at 100%. If we had , we split traffic between our revisions. Since we're only working with one revision, we'll send all traffic there. configuration multiple revisions Next up, we define the registry that our container app will pull images from. We do this by providing the server name and username as outputs from our resource block that we defined earlier. We then provide a to the name of the secret that we will use to store the login password for our Azure Container Registry. containerRegistry reference We then define a block that will create our secret that has a value containing the password needed to access our Azure Container Registry. Again, we use the output from our to get this password. secret containerRegistry In our block, we define the container that we'll deploy to our Container App. In my array, I'm using the same name as my container app for my image, using a simple hello-world image that Microsoft has provided and setting both CPU and Memory resources (You can read how to configure your containers in Container Apps ). Within my block, I'm just setting the minimum and the maximum number of replicas to 1, but at the time of writing, we could set a . template container here scale maximum of up to 25 replicas For more information on what we can define in a Container Apps Bicep template, check out the template guide . here Deploying our Bicep Template Our full Bicep template should look like this (I've moved things around just to tidy it up a bit, so feel free to copy and paste this if you want, or fix your template to make it look similar): @description('Name of the log analytics workspace')
param logAnalyticsName string

@description('Name of the connected Container Registry')
param containerRegistryName string

@description('Name of the Container App Environment')
param containerAppEnvName string

@description('Name of the TodoApi Container App')
param todoApiContainerName string

param location string = resourceGroup().location

resource logAnalytics 'Microsoft.OperationalInsights/workspaces@2021-12-01-preview' = {
  name: logAnalyticsName
  location: location
  properties: {
    sku: {
      name: 'PerGB2018'
    }
  }
}

resource containerRegistry 'Microsoft.ContainerRegistry/registries@2021-12-01-preview' = {
  name: containerRegistryName
  location: location
  sku: {
    name: 'Basic'
  }
  properties: {
    adminUserEnabled: true
  }
}

resource containerAppEnvironment 'Microsoft.Web/kubeEnvironments@2021-03-01' = {
  name: containerAppEnvName
  location: location 
  kind: 'containerenvironment'
  properties: {
    environmentType: 'managed'
    internalLoadBalancerEnabled: false
    appLogsConfiguration: {
      destination: 'log-analytics'
      logAnalyticsConfiguration: {
        customerId: logAnalytics.properties.customerId
        sharedKey: logAnalytics.listKeys().primarySharedKey
      }
    }
  }
}

resource todoApiContainerApp 'Microsoft.Web/containerApps@2021-03-01' = {
  name: todoApiContainerName
  location: location
  properties: {
    kubeEnvironmentId: containerAppEnvironment.id
    configuration: {
      ingress: {
        external: true
        targetPort: 80
        allowInsecure: false
        traffic: [
          {
            latestRevision: true
            weight: 100
          }
        ]
      }
      registries: [
        {
          server: containerRegistry.name
          username: containerRegistry.properties.loginServer
          passwordSecretRef: 'container-registry-password'
        }
      ]
      secrets: [
        {
          name: 'container-registry-password'
          value: containerRegistry.listCredentials().passwords[0].value
        }
      ]
    }
    template: {
      containers: [
        {
          name: todoApiContainerName
          image: 'mcr.microsoft.com/azuredocs/containerapps-helloworld:latest'
          resources: {
            cpu: '0.5'
            memory: '1Gi'
          }         
        }
      ]
      scale: {
        minReplicas: 1
        maxReplicas: 1
      }
    }
  }
} We will also need to provide a parameter file to accompany our Bicep template. Like ARM, this is just a JSON file. We could provide parameters via the AZ CLI, but in future posts, I want to deploy my Bicep template via GitHub Actions, so we'll start with a parameter file. Our parameter file will look like this (You'll need to provide your own values): {
    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
      "logAnalyticsName": {
        "value": "<log-analytics-workspace-name>"
      },
      "containerAppEnvName": {
          "value": "<container-environment-name>"
      },
      "todoApiContainerName": {
          "value": "<container-app-name>"
      },
      "containerRegistryName": {
          "value": "<container-registry-name>"
      }
    }
  } We can now deploy our Bicep template. As you can see within the Bicep template, I've set the parameter to be the location of the resource group that we will deploy our Container App resources to. location At the time of writing, Container Apps can only be provisioned in the following environments: East US North Europe Canada Central East US 2 West Europe With that in mind, we'll create a resource group that we'll deploy our resources to by running the following AZ CLI command. az group create --name <name-of-your-resource-group> --location <one-of-the-above-locations> We now have a resource group to deploy our Container App resources to. Let's do that by running the following command: az deployment group create --resource-group <name-of-your-resource-group> --template-file <your-bicep-file>.bicep --parameters --<your-parameter-file>.json Give that a couple of minutes to run and we should see the following output: Click on and we should see that all the resources we defined in our Bicep template have been deployed to Azure! Go to the resource group Let's see how our Container App is doing! Click on your Container App resource and you should see an Application Url (since we enabled external ingress in our Container App). Navigate to it and you should see the following web page: Awesome! We've just deployed an Azure Container App in a Container App environment that sends logs to our Log Analytics workspace and can pull images from our Azure Container Registry in just one Bicep file! Good job! 👏👏 Wrapping Up As you can see, we can manage and deploy our Container Apps using Bicep! As this awesome product grows, more features will be released meaning that we can extend our Bicep template further ( ) vNet integration comes to mind If you want a reference to the code that we've written in this post, you can do so in this . GitHub repository In a future post, we'll deploy our Bicep template via GitHub actions rather than running AZ CLI commands on our local machine each time we want to deploy our Container Apps. If you have any questions, feel free to reach out to me on Twitter @willvelida Until next time, Happy coding! 🤓🖥️

Fetch

Creating and Provisioning Azure Container Apps with Bicep

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

How Bindings in Azure Functions Work

10 reasons to give cloud computing a go

10 Microsoft Azure Courses for Beginners to Learn Azure Cloud Computing

The Noonification: Proglogging: The Developers Detective Toolkit (10/9/2023)

Top 10 AI Development Companies in USA

How Bindings in Azure Functions Work

10 reasons to give cloud computing a go

10 Microsoft Azure Courses for Beginners to Learn Azure Cloud Computing

The Noonification: Proglogging: The Developers Detective Toolkit (10/9/2023)

Top 10 AI Development Companies in USA

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps