Go Cloud Native with Azure Container Apps
In this article, we discuss how Azure Container Apps is purpose-built to support cloud native applications. This post is part of the Zero To Hero series for #ServerlessSeptember, a month-long initiative to learn, use, and celebrate, all things Serverless On Azure. Check out the main site at https://aka.ms/serverless-september to read other posts, participate in a Cloud Skills Challenge, explore a Serverless Hack and participate in live Q&A with product teams on #AskTheExper
Observability on Azure Container Apps
Managing the infrastructure needed to operate numerous containers at scale can be challenging, and Azure Container Apps is designed to address this exact issue. Azure Container Apps offers a serverless platform enabling you to scale and run multiple containers effortlessly, without the need to manage the infrastructure behind them. It’s ideal for microservices architecture, and is also commonly utilized for event-driven processing, background tasks, and various other applications. A question I often get is, how do I approach observability in Azure Container Apps? My goal in this post is to outline what it takes to have an observable Azure Container Apps Environment.
How to remove secrets from Container Apps linked to ACR
Azure Container Apps allows your application to securely store sensitive configuration values. Once secrets are defined at the application level, secured values are available to revisions in your container apps. Additionally, you can reference secured values inside scale rules. This blog provides a detailed, step-by-step procedure for removing secrets associated with an Azure Container Registry (ACR). In this example, we will walk through the process of creating a Container App with an image reference from the ACR, which automatically generates a secret. We will then attempt to remove this secret and observe its behaviour throughout the process. Secrets are scoped to an application, outside of any specific revision of an application. Adding, removing, or changing secrets doesn't generate new revisions. Each application revision can reference one or more secrets. Multiple revisions can reference the same secret(s). An updated or deleted secret doesn't automatically affect existing revisions in your app. When a secret is updated or deleted, you can respond to changes in one of two ways: Deploy a new revision. Restart an existing revision. Before you delete a secret, deploy a new revision that no longer references the old secret. Then deactivate all revisions that reference the secret. Create an Azure Container Registry: az acr create \ --name "$CONTAINER_REGISTRY_NAME"\ --resource-group "$RESOURCE_GROUP"\ --location "$LOCATION"\ --sku Basic \ --admin-enabled true Explanation: This command creates an Azure Container Registry (ACR) with the specified name, resource group and location. The --sku Basic specifies the pricing tier for the registry, and --admin-enabled true enables admin access to the registry. Build and push image from a Dockerfile. Now use Azure Container Registry to build and push an image. First, create a local working directory and then create a Dockerfile named Dockerfile with the single line: FROM mcr.microsoft.com/hello-world. This is a simple example to build a Linux container image from the hello-world image hosted at Microsoft Container Registry. You can create your own standard Dockerfile and build images for other platforms. If you are working at a bash shell, create the Dockerfile with the following command: echo "FROM mcr.microsoft.com/hello-world" > Dockerfile Run the az acr build command, which builds the image and, after the image is successfully built, pushes it to your registry. The following example builds and pushes the sample/hello-world:v1 image. The . at the end of the command sets the location of the Dockerfile, in this case the current directory. az acr build --image sample/hello-world:v1 \ --registry myContainerRegistry008 \ --file Dockerfile . Create and Deploy the Container App from ACR Create and deploy your container app with the containerapp up command. This command will: Create the resource group Create the Container Apps environment Create the Log Analytics workspace Create and deploy the container app using a public container image Note that if any of these resources already exist, the command will use them instead of creating new ones. az containerapp up \ --name my-container-app \ --resource-group my-container-apps \ --location centralus \ --environment 'my-container-apps' \ --image azuredockerregistry.azurecr.io/image:latest \ --target-port 80 \ --ingress external \ --query properties.configuration.ingress.fqdn 1. Once the Container App gets created , check if there are any secrets added to your container app. 2. If you attempt to delete an existing secret and encounter an error, it's because there is a running revision that still references the secret. 3. In this case, ensure you deactivate all existing revisions that reference the secret and create a new revision that references an image from a public repository (e.g., docker.io). 4. After verifying that there are no references to secrets in existing revisions, you can use the `az containerapp registry remove` command to remove a registry associated with your container app. az containerapp registry remove -n MyContainerapp -g MyResourceGroup --server MyContainerappRegistry.azurecr.io If successful, the command will return "Registry Successfully Removed." 5. Upon checking the "Secrets" section in the portal you should see the secret removed. 6. If you continue to see secrets in the portal UI even after following the above steps, now try deleting the secrets directly using the delete option in the portal. It's crucial to manage secrets carefully to maintain the security and integrity of your Azure Container Apps and associated resources. !!HAPPY LEARNING !!
