What’s new in Azure Container Apps at Build’24
Azure Container Apps is a fully managed serverless container service that enables you to build and deploy modern, cloud-native applications and microservices at scale. It offers a simplified developer experience while providing the flexibility and portability of containers. Azure Container Apps supports a variety of languages and frameworks, making it a versatile platform for developers. The features we're announcing at Build'24 for intelligent apps, Java and .NET Aspire will further deepen this commitment.
Downloading Files from Azure Container App to your Local Machine via Azure Blob Storage
Azure Container Apps is a powerful tool for running containerized applications in the cloud. However, if you need to transfer files (custom log files, network captures, etc.) from your container app to another destination such as your local machine or Azure Blob Storage, you might find that the process is not as straightforward as you'd like. In this post, we'll walk you through the steps to transfer files from your Azure Container App to Azure Blob Storage using the `curl` command. Once the file is present on your Blob Storage, you can easily download it to your local machine from the Azure Portal itself in case you need to analyze the logs or network traces with a local tool. Step 1: Accessing the Azure Container App Console To access the Azure Container App Console, navigate to your container app in the Azure Portal. Once you've selected your container app, click on the "Console" option under the "Monitoring" blade. This will open up a terminal window in your browser that you can use to connect to your container. Step 2: Installing `curl` Before you can transfer files using curl, you'll need to install it within your container. To install `curl`, simply enter the following command in the terminal window: apt-get update && apt-get install -y curl Step 3: Creating the `curl` Command To transfer a file from your Azure Container App to Azure Blob Storage, you'll need to create a `curl` command that specifies the location of the file you want to transfer and the destination container and blob in Azure Blob Storage. The curl syntax to upload a file to a Container within an Azure Blob Storage would look like this curl -X PUT -T [file_path] -H "x-ms-blob-type: BlockBlob" "https://[storage_account_name].blob.core.windows.net/[container_name]/[blob_name]?[sas_token]" Make sure to replace the placeholders with the appropriate values: [file_path] is the local file path of the file you want to upload. [storage_account_name] is the name of your Azure Storage account. [container_name] is the name of the container you want to upload the file to. [blob_name] is the name of the blob you want to create or overwrite. [sas_token] is a Shared Access Signature (SAS) token that provides permission to upload the file to the container. You can generate a SAS token with the appropriate permissions using the Azure portal or Azure CLI. Here's an example command to upload a file named "example.txt" to a container named "mycontainer" into a storage account named "mystorageaccount" with a SAS token: curl -X PUT -T example.txt -H "x-ms-blob-type: BlockBlob" "https://mystorageaccount.blob.core.windows.net/mycontainer/example.txt?[sas_token]" Step 4: Executing the curl Command Once you've created your `curl` command, you can execute it in the Azure Container App Console by pasting it into the terminal window and hitting enter. This will initiate the file transfer process and upload the specified file to Azure Blob Storage. Step 5: Downloading the file from Azure Storage to your Local Machine Once you've confirmed the file is in your Azure Blob Storage, you can simply browse to the Container within the Storage Account and download the file. Note:- This post assumes you are not mounting a file share to your Container App, in case you are, you can simply 'mv' or 'cp' the file from whichever directory it is into the directory where you mounted the file share volume.
Use Nginx as a reverse proxy in Azure Container App
A recent requirement from a customer was to host multiple container apps on Azure Container Apps within the same environment to optimize resource usage. To limit the traffic within the container app environment, an Nginx container was utilized as a reverse proxy server and public endpoint to direct all inbound internet traffic to the appropriate container app based on the URL. The traffic flow for this architecture is as follows:Delete Passwords: Passwordless Connections for Java Apps to Azure Services
Using username/password credentials to access one application from another presents a huge security risk for many reasons. Today, we are announcing the preview of passwordless connections for Java applications to Azure database and eventing services, letting you finally shift away from using passwords.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 #AskTheExperDeploying an Event-Driven-Job with Azure Container App Job and Azure Service Bus
Azure Container Apps jobs let you perform specific tasks inside containers that start, run for a short time, and then stop. You can make these tasks happen whenever you want, following a schedule, or when something specific occurs. These jobs work well for things like dealing with data, teaching computers, or situations where you need quick computing power without leaving a trace. This blog helps you in deploying an event driven job using Azure Container apps and Azure Service Bus. In this example, the trigger will be a message in Service bus Queue and the Azure container app Job reads the message present in the queue and prints the message in container app console log. Below are the steps to be performed: Create a Container Apps environment to deploy your container apps. Create an Azure Service Bus to send messages to the container app. Build a container image that runs a job. Deploy the job to the Container Apps environment. Verify that the Service Bus messages are processed by the container app. The job you create starts an execution for each message that is sent to an Azure Service Bus Queue. Each job execution runs a container that performs the following steps: Dequeues one message from the Service Bus queue. Logs the message to the job execution logs. Deletes the message from the Service Bus queue. Job completes its one execution. If there is an existing Container App Environment, you can use the same or you can create a new environment by following the steps outlined here. Build and deploy the container app job: First ensure to login to Azure CLI and set the subscription, you can use PowerShell/CMD/Cloud shell on Azure portal. Command to login to Azure CLI az login Command to set the subscription: Replace the empty quotes with your subscription. az account set --subscription "" To deploy the job, you must first build a container image for the job and push it to any container registry. In this blog post, we will be using Azure Container Registry. Define a name for your container image and registry. CONTAINER_IMAGE_NAME="servicebus-reader-job:1.0" CONTAINER_REGISTRY_NAME="<CONTAINER_REGISTRY_NAME>" Replace <CONTAINER_REGISTRY_NAME> with a unique name for your container registry. Container registry names must be unique within Azure and should be between 5 and 50 characters in length, containing only numbers and lowercase letters. 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. The source code for the job is available on GitHub. Run the following command to clone the repository and build the container image in the cloud using the az acr build command. az acr build \ --registry"$CONTAINER_REGISTRY_NAME"\ --image"$CONTAINER_IMAGE_NAME"\ "https://github.com/karthimalyala/ServiceBusEventDriven.git" Explanation: This command builds a container image from the specified GitHub repository and pushes it to the Azure Container Registry ($CONTAINER_REGISTRY_NAME). The image will have the name and version specified in $CONTAINER_IMAGE_NAME. The image can later be used to deploy the container app job. Create a job in the Container Apps environment. Command to create a job in the specified resource group and environment: az containerapp job create \ --name "$JOB_NAME"\ --resource-group "$RESOURCE_GROUP"\ --environment "$ENVIRONMENT"\ --trigger-type "Event"\ --replica-timeout "1800"\ --replica-retry-limit "1"\ --replica-completion-count "1"\ --parallelism "1"\ --min-executions "0"\ --max-executions "10"\ --polling-interval "60"\ --scale-rule-name "queue"\ --scale-rule-type "azure-servicebus"\ --scale-rule-metadata "queueName=xxxxx" "namespace=xxxxxx" "messageCount=1"\ --scale-rule-auth "connection=connection-string-secret"\ --image "$CONTAINER_REGISTRY_NAME.azurecr.io/$CONTAINER_IMAGE_NAME"\ --cpu "0.5"\ --memory "1Gi"\ --secrets "connection-string-secret=$QUEUE_CONNECTION_STRING"\ --registry-server "$CONTAINER_REGISTRY_NAME.azurecr.io"\ --env-vars "AZURE_STORAGE_QUEUE_NAME=$QUEUE_NAME" "AZURE_SERVICE_BUS_CONNECTION_STRING=secretref:connection Explanation: This command creates a job within the Azure Container Apps environment. The job is configured to trigger when a message arrives in Azure Service Bus. To know more about the parameters used, refer to this document. In the above CLI command - --scale-rule-type is set to azure-service bus which is a KEDA based scaler. For more details, refer here QUEUE_NAME is the queue name you created in your Azure Service Bus. QUEUE_CONNECTION_STRING is the connection string for your Storage Account. --scale-rule-metadata: the queueName is the Azure Service Bus queue name and the namespace is the Azure Service Bus name. Verify the deployment: To verify that the job was configured correctly, you can send some messages to the Azure Service Bus, confirm that job executions are started, and check if the messages are logged in the job execution logs. Send a message to the queue and Peek from start in Azure Service Bus: List the executions of a job: You can refer to the Execution History of the Azure Container App job, we can notice that the job execution has started. You can also verify the logs from the Log Analytics workspace, which will display the processing of the Azure Service Bus messages by the Azure Container App job, as shown below: Thank you for accompanying us on this journey through the world of event-driven processing with Azure Service Bus and Container App Jobs. We trust this guide has not only expanded your knowledge but also empowered you to harness the capabilities of these technologies in your projects. Should you have any inquiries, insights to share, or suggestions for improvements, please don't hesitate to reach out in the comments section below. We value your feedback and are committed to refining our content based on your input. Happy learning and coding, and may your innovative endeavors continue to flourish in the dynamic realm of technology!
