Martha, the CTO of the boutique cloud-native technologies consulting firm - StartUps & More Inc. (SUM Inc.), requires her consultants to be conversant with emergent technologies and methodologies at a consistent yet fast pace. One of the key decisions she makes with the advent of every new technology, is to determine - it's fit-to-purpose and efficacy - before having her consultants delve deeper themselves and subsequently having them help their clients.
Azure Container Apps (ACA) is the newest offering from Microsoft providing a serverless platform for running containerized microservices, this is on the top of Martha's emerging tech list for a few important reasons that she has heard so far -
-
ACA can empower developers to build cloud-native solutions focusing on their apps rather than cloud infrastructure.
Something that resonated even more - considering startup teams would rather focus on product differentiation, speedy go-to-market as compared to foundational infrastructure setup, security and Day-2 operations.
-
ACA is built on the foundation of open-source Cloud Native Computing Foundation (CNCF) projects like - Kubernetes Event Driven Autoscaling (KEDA) and Distributed Application Runtime (Dapr) which are gaining adoption amongst cloud native developers and ACA inherently utilizing the CNCF Graduated project - Envoy - for its service-proxy functionality.
Serverless PaaS powered by CNCF projects to enable developers - sounded like an attractive proposition
Martha has looped in and tasked two of her top engineers Alice and Bob to conduct a timeboxed hands-on evaluation of ACA. Such a time-boxed evaluation methodology has proven to be a strategic advantage to Martha's firm for many years.
Alice is a Kubernetes expert having worked with several of SUM Inc.'s clients on anything ranging from - large DIY Kubernetes clusters - to - vendor managed Kubernetes offerings including the Azure Kubernetes Service (AKS) from Microsoft. She has recently passed the Certified Kubernetes Administrator & Certified Kubernetes Application Developer exams from the Linux Foundation.
Bob is a polyglot developer - addressing the full-stack of cloud native application development. He is familiar with containerization and orchestration but would rather spend his time building high-performant microservices and applying the needed development rigor driven by well-adopted software development patterns. He is relatively new to Azure.
Alice and Bob proceed on the quest set forth by Martha.
Apart from looking into the official Azure Container Apps documentation and the studying the comparison of Azure Containers Apps with other Azure Container options --- Alice and Bob --- read the following articles by members of the Azure Container Apps Product Group at Microsoft.
- Go Cloud Native with Container Apps link
- Journey to the cloud with Azure Container Apps link
- Observability with Azure Container Apps link
Having digested the optimal information on Azure Container Apps in a timeboxed manner, both Alice and Bob concur on the prospect this option offer and prepare an executive summary for Martha. The highlight of the summary being a crisp slide as depicted in one of the Microsoft Product Group articles -
Based on the reassurance of Alice and Bob's presentation, Martha introduces them to a prospective customer of the firm - Marketblitz This customer, Martha believes, could be an ideal pilot customer for ACA and could benefit from a set of hands-on-labs for their development team.
Alice and Bob are tasked with creating the labs with one overarching instruction from Martha - "Keep it simple but not simplistic :)"
Markeblitz is a rapidly growing market research firm which has recently acquired 2 different startups and their respective product lines.
One of the acquisition is a market analytics firm that develops mostly on the Microsoft web tech stack – Dotnet Core , ASP.Net Web API et.al. The other acquisition is a marketing UX firm focusing mostly on different UI libraries.
Marketblitz – is at a juncture where they want to consolidate ALL their offerings as a single API suite while ensuring their top talent is retained and continues to work on their respective areas of expertise. They hope to structure some of the existing core APIs for internal usage only – parts of which could be used by the new API suite which would be customer facing. After the first phase of consolidation, they expect to beta test – at which point they foresee some challenges with A/B testing and are also concerned as to how they will meet scaling needs if/when the pilot becomes successful with increasing demand from end-users.
The Dev team is a mix of developers who are conversant with Azure and the ones who are just getting started on Azure.
Apart from core concerns, the lean Ops team at Marketblitz would require insights and visualization of the performance of the API suite too without them having to spin up and manage any new instrumentation or dashboards.
Prerequisites
Structure
Lab 1
Lab 2
Lab 3
Lab 4
Lab 5
- Access to an Azure subscription with privileges to create Azure resources.
- If you do not have an entire Azure subscription , access to a Azure resource group with privileges to create Azure resources is required. The labs assume you have a subscription; you would need to skip the resource group creation steps in the relevant labs if you already have the resource group.
- Azure Cloud Shell configured and ready to use. Bash commands/instructions provided in relevant labs.
- Usage of Cloud Shell is favored for users who do not have typical Azure development tools like Azure CLI installed. Feel free to use your Azure development setup / tooling if you have one.
- Access to pull container images from a public DockerHub container image registry.
- If you cannot or do not want to use the lab specific container images from the public DockerHub repo, source code is provided in the relevant labs with it's Dockerfile - for you to build and push to container registry of your choice.Your container registry and image details would need to be substituted accordingly in the relevant steps of the lab.
- Tooling of your choice to test API endpoints.
- Postman App is utilized here in the relevant labs.
- Tooling of your choice to load test API endpoints.
- Artillery is utilized here in the relevant labs.
- Basic understanding of APIs, Containers and Azure Portal UI and UX.
Each lab has the following structure -
Objectives - Listing of the key objectives of the lab.
Why is it relevant to the customer ? - This section describes the relevance and reasoning behind why Alice and Bob chose the objectives for the customer - Marketblitz
Steps - A set of detailed steps to follow in an hands-on manner to achieve the objectives.
Challenges(optional) - While the Objectives and the Steps to achieve them are considered mandatory, every lab has a set of optional Challenges that could be completed with some additional effort on the candidate's part. Highly Recommended.
Lab 1 – Create an Azure Container App using the Azure Portal and implement traffic-split functionality
Objectives
- Create the environment and test a sample container app using the Azure Portal.
- Utilize multiple revisions and test Traffic Split functionality with 2 different versions of the same app.
As part of the Azure Container App environment creation and deployment, get familiar with the Azure Portal UI and learn the Azure Container App specific terminologies & features. - Optionally, work through and complete the listed challenges.
Why is it relevant to the customer ?
a. Alice and Bob have crafted this lab to be an easy initiation via the Azure Portal to create Azure resources for the developers in the Marketblitz team just getting started on their Azure journey.
b. After the creation of the first app, this lab then addresses one of the key customer requirements - A/B Testing - and how its foundation could be laid via the multiple revisions and the traffic split functionality that is readily available with ACA.
Steps
-
Create the sample app - Download & follow instructions in the Create the sample app PDF to create the sample app. Preferably, open this PDF in a PDF viewer or a separate browser window.
The [Lab 1 - Create Azure Container App - Azure Portal.pdf] is inside the [Lab 1] folder in this repo.
Note 1: Complete all instructions in the PDF and then return to this README.md again - for the next steps of this Lab 1.
The PDF is only for the Create the sample app step.Note 2: Please note that the container image for this sample app is pulled from a public Docker repository.
If you choose to utilize your own container image repository, utilize the [Lab1\src] folder and the associated Dockerfile to build and push the image to your container registry of choice / repository and substitute the values in the Container App creation step for the [Registry login server] and [Image and tag] values. -
Enable multiple revisions - One of the fundamental steps for Traffic Split is to enable multiple revisions of the app to exist simultaneously.
a. Go to the Container App resource created in Step 1 by clicking on it's resource name in your resource group.
b. Select the - Revision Management - link in the left navigation menu as shown below.c. Click on the - Choose revision mode - option as depicted in the image below -
d. Then select - Multiple: Several revisions active simultaneously and click Apply
e. Refresh the page you are on within the Azure Portal and navigate back to same Container App resource and the Revision Management link in the left navigation menu, same as Step 2.b. above.
-
Create a new revision
a. Click on Create new revision as shown below
b. Click on the previously created container image's Name as shown below in the Container Image section
c. In the Edit a container tab that opens up - Enter the new value for the Image and tag field as - dockerr10n/aca-lab1-image:blue - as shown in the image below and then click Save
d. Now click Create as shown below
e. You should now see the new revision appear as shown below - with Traffic at 0 % and Active enabled.
NOTE: 2 key aspects to note - (a.) you did not have to create another Container App Environment and (b.) when a revision-scope change was made by making container configuration and image changes a new revision was automatically created for you. Read more about Container App Environments here and about Revisions here
-
Create traffic split
a. Now let us create a traffic split of 50 % each to these 2 revisions by editing and entering the values as shown below and then click on Save
b. After the revisions of successfully updated, traffic split is successfully created with the percentage weight we assigned
-
Test traffic split.
a. Navigate to the [Overview] link as shown and click on the [Application Url]
b. You should either see a blue or green back ground - and for every n page refreshes you would see that approximately n/2 times the page back ground would be blue and then green for the other instances - effectively proving that we have created a traffic split for 2 different revisions of the same Container App that are active simultaneously.
You should see one of the 2 following depictions when you refresh the [Application Url] of the [Container App]
OR
Challenges (optional)
-
Implement a 30/30/40 split for same app - so that traffic split amongst the green, blue and pink revisions.
(Hint: The - dockerr10n/aca-lab1-image:pink - image results in a html page with pink colored background.) -
Inactivate one of the revisions and re-implement 50/50 split so that traffic is split between the green and pink revisions.
Objectives
- Get familiar with the az cli and the az containerapp commands to create the Container App in Lab 1 in a command line driven manner.
- Optionally, work through and complete the listed challenge(s).
Why is it relevant to the customer ?
a. Nudge Marketblitz's developer team further to get familiar with the Azure command line and scripting options.
b. Addresses the customer's need for segmenting their API suite - with few APIs for internal only use and others for external use.
Steps
1. Add the needed extensions and register the necessary providers - required for creating an Azure Container App using the CLI.
# Login to the account if you are using Azure CLI command-line tool that is locally installed
# Skip this step if you are using Azure Cloud shell.
az login
# Install the ACA extension for the CLI
az extension add --name containerapp --upgrade
# Register the Microsoft.App namespace
az provider register --namespace Microsoft.App
# Register the Microsoft.OperationalInsights provider for the Azure Monitor Log Analytics workspace if you have not used it before.
az provider register --namespace Microsoft.OperationalInsights
2. Create the sample app using CLI
# Set the following environment variables
RESOURCE_GROUP="rg-spt-aca-hol1" # your new resource group name
LOCATION="eastus"
CONTAINERAPPS_ENVIRONMENT="aca-hol-env1" # your new Conatiner Apps environment name
# Create a resource group to organize the services related to your new container app
az group create \
--name $RESOURCE_GROUP \
--location $LOCATION
# Create the ACA Environment
az containerapp env create \
--name $CONTAINERAPPS_ENVIRONMENT \
--resource-group $RESOURCE_GROUP \
--location $LOCATION
# Create the Container App
az containerapp create \
--image "docker.io/dockerr10n/aca-lab1-image:green" \
--name aca-hol-demo1 \
--resource-group $RESOURCE_GROUP \
--environment $CONTAINERAPPS_ENVIRONMENT
After executing the above commands, if you navigate to the resource group you created in the Azure Portal and click on the newly created Container App you will observe the following as depicted in the image below:
a. Container App is created
b. Application Url has the value - Ingress Disabled.
This is to demonstrate the Container App can be created without any ingress. The Container App can later be updated to accept (Ingress) traffic from the Internet.This will be performed during the next step.
3. Update the Container App to enable ingress
Note: Update the values in the following command to reflect the name of your container app and resource group.
az containerapp ingress enable -n aca-hol-demo1 -g rg-spt-aca-hol1 \
--type external --allow-insecure --target-port 80 --transport auto
After you execute this command, you will get a Application Url in the resultant output in the CLI; you will have the Url in the fqdn value too.
Navigate to the above Url. (Or) You could also - Navigate back to the Application URL field (Within overview) in the portal and click on the now populated URL field and you should see the browser result as depicted below.
NOTE: We could have created an ingress enabled Container App as part of the previous step itself by passing in the --ingress external and target-port 80 in the earlier command in Step 2. We did it in 2 parts to demonstrate that it can be enabled after the creation of the Container App.
4. Set the revision to Multiple - enabling multiple revisions of the Container App to exist simultaneously
az containerapp revision set-mode --mode multiple \
--name aca-hol-demo1 \
--resource-group rg-spt-aca-hol1
Ensure that you get the output - "Mutliple" - which means the revision mode was set successfully
5. Create a new revision - based on the existing revision and using the image - docker.io/dockerr10n/aca-lab1-image:blue
az containerapp revision copy -n aca-hol-demo1 -g rg-spt-aca-hol1 --image "docker.io/dockerr10n/aca-lab1-image:blue"
Navigate to the Revision Management configuration page for the Container App within the Azure Portal. You will see that two revisions exist simultaneously and that the revision we recently created is configured to receive 100 % of the traffic.
And if we navigate to the Application Url - we observe the change with the loading of the blue background page.
NOTE: 2 key aspects to note - (a.) you did not have to create another Container App Environment and (b.) when a revision-scope change was made by making container configuration and image changes a new revision was automatically created for you. Read more about Container App Environments here and about Revisions here
6. Create a traffic split - of 50-50 each for both these revisions.
You can list the revisions using the following command ; observe and note down the full revision name of the most 2 revisions that exist.
az containerapp revision list --name aca-hol-demo1 -g rg-spt-aca-hol1
The latest revision is now getting 100 % of the ingress traffic; so let us split the ingress traffic between the latest and the revision name of the first revision we created.
az containerapp ingress traffic set -n aca-hol-demo1 \
-g rg-spt-aca-hol1 \
--revision-weight latest=50 aca-hol-demo1--d9ggleh=50
After this command is executed, you get the following output depicting that the traffic split has been configured
7. Test the traffic split - navigate to the Application Url and refresh the page a few times and you would see 50-50 weighted split between pages with green and blue colored backgrounds.
Challenges (optional)
- Using the CLI - Implement a 30/30/40 split for same app - so that traffic split amongst the green, blue and pink revisions.
(Hint: The - dockerr10n/aca-lab1-image:pink - image results in a html page with pink colored background.) - Using the CLI - Inactivate one of the revisions and re-implement 50/50 split so that traffic is split between the green and pink revisions.
- Convert the above deployment to an internal only ingress using - az cli .
- Discuss and explore options you have securing the Container App with a VNet. If you are up to it - secure the Container App based on the options and choices you make. (Hint: You may need to create a new Container Apps Environment based on choices you make and then redeploy the app.)
Objectives
- Create 3 Azure Container Apps - 2 back-end APIs and 1 UI front end - and integrate them to demonstrate cross Container App integration.
- Optionally, work through and complete the listed challenge(s).
NOTE: -
a. Please note that the container images for the 2 APIs and 1 UI - are pulled from a public Docker repository in this lab.
If you choose to utilize your own container image repository, utilize the [Lab3\src] folder and the associated Dockerfiles to build and push the images to your container registry of choice / repository and substitute the values in the relevant steps.
b. The source code for the 3 container apps used in the lab to follow is taken from the following sample: - https://github.com/Azure-Samples/dotNET-FrontEnd-to-BackEnd-on-Azure-Container-Apps
Why is it relevant to the customer ?
Applies to the customer scenario where different teams own their set of core APIs but there is a need for API integration and cross-service usage - arising from Marketblitz's acquisition of 2 different companies.
Steps
1. Create a Container App - for the inventoryapi microservice.
# Assuming the Resource Group and Container App environment are already created as part of Lab 2
# if not create them.
# Set the following environment variables
RESOURCE_GROUP="rg-spt-aca-hol1"
CONTAINERAPPS_ENVIRONMENT="aca-hol-env1"
# Deploy the Container App for the inventoryapi microservice
az containerapp create \
--name inventoryapi \
--resource-group $RESOURCE_GROUP \
--environment $CONTAINERAPPS_ENVIRONMENT \
--image 'docker.io/dockerr10n/storeinventoryapi:latest' \
--target-port 80 \
--ingress 'external' \
--query configuration.ingress.fqdn
After the command is executed successfully, make a note of the App Url that is emitted in output.
2. Test the inventoryapi Container App
In the Postman Client, enter the URI as depicted below for the HTTP GET call and the expected a result of a random number denoting the inventory count of the productId passed as part of the URI is returned in response.
HTTP GET URI : https://< yourInventoryAPIAppURL >/inventory/< any-alphanumeric-string-representative-of-productId >
3. Create a Container App - for the productsapi microservice
# Deploy the Container App for the productsapi microservice
az containerapp create \
--name productsapi \
--resource-group $RESOURCE_GROUP \
--environment $CONTAINERAPPS_ENVIRONMENT \
--image 'docker.io/dockerr10n/storeproductapi:latest' \
--target-port 80 \
--ingress 'external'
After the command is executed successfully, make a note of the App Url that is emitted in output.
4. Test the productsapi Container App
In the Postman Client, enter the URI as depicted below for the HTTP GET call and the expected a result of a randomized collection of 10 product names with their productId.
HTTP GET URI : https://< yourProductsAPIAppURL >/products
5. Create a Container App - for the store UI frontend
az containerapp create \
--name store \
--resource-group $RESOURCE_GROUP \
--environment $CONTAINERAPPS_ENVIRONMENT \
--image 'docker.io/dockerr10n/store:latest' \
--target-port 80 \
--ingress 'external'
After the command is executed successfully, make a note of the App Url that is emitted in output.
6. Create and configure Environment Variables
In order for the UI store front Container App - to utilize the data obtained from the 2 backend API Container Apps - inventoryapi and productsapi -- we must create and set the environment variables expected within the store Container App.
# Create the value needed for the - InventoryApi - environment variable
INVENTORY_FQDN=$(az containerapp show \
--resource-group $RESOURCE_GROUP \
--name inventoryapi \
--query properties.configuration.ingress.fqdn -o tsv)
# Set the - InventoryApi - environment variable
az containerapp update -n store -g $RESOURCE_GROUP --set-env-var "InventoryApi=https://$INVENTORY_FQDN"
# Create the value needed for the - ProductsApi - environment variable
PRODUCT_FQDN=$(az containerapp show \
--resource-group $RESOURCE_GROUP \
--name productsapi \
--query properties.configuration.ingress.fqdn -o tsv)
# Set the - ProductsApi - environment variable
az containerapp update -n store -g $RESOURCE_GROUP --set-env-var "ProductsApi=https://$PRODUCT_FQDN"
7. Test the integrated UI by navigating to the App Url of the store Container App - our UI frontend
Navigate to the App Url of the store Container App.
You should see the following page render with the Campaign Product data being obtained from the productsapi Container App and the Inventory column data being obtained from the inventoryapi Container App.
Challenges (optional)
- Determine – if there are other ways to achieve the same objective - cross microservice communication ? (Hint: Dapr)
- Explore and implement the same cross-microservice integration scenario with the 3 Container Apps above with Dapr.
Objectives
- Configure inventoryapi for KEDA scaling with - httptrigger - for HTTP handler based scaling down to zero.
- Optionally, work through and complete the listed challenge(s).
Why is it relevant to the customer ?
Marketblitz customer demand to increase during the beta testing phase and would like to be in a position to adapt to the demand without sunken costs.
Steps
- Configure inventoryapi for KEDA scaling with - httptrigger
a.
b.
c.
d.
e. After you click Create a new revision is deployed for the Container App and the scale rule is configured successfully.
- Observe that replicas are at zero
- Generate/simulate concurrent user and http requests load using a load testing mechanism of your choice to the inventoryapi App Url
- Observe that replicas are scaling up as the load test progresses
Challenges (optional)
- Utilize the az cli (as containerapp) to achieve the same objectives of Lab 4.
- Explore other scalers in KEDA and create a custom scaler implementation of your choice based on KEDA scaled object chosen. You might need to deploy additional Azure resource(s) based on choices made.
Objectives
- Visualize the metrics of the deployed Azure Container Apps using Azure Managed Grafana.
- Optionally, work through and complete the listed challenge(s).
Why is it relevant to the customer ?
Marketblitz's lean Ops team requires dashboards and insights into performance / operational metrics of the API suite but without them having to spin up and manage dashboards.
Steps
-
Deploy an Azure Managed Grafana instance
a.
b.
c.
-
Configure and Import a Azure Container App workbook
a. Navigate to the Endpoint of the Azure Managed Grafana resource you created in Step 1 of Lab 5.
b. Click on Import as shown below
c. We will now import the Grafana Dashboard -
So, navigate to the above link and click on Copy ID to clipboard (the ID is currently 16592) and Load it as shown below -
e. Proceed to Import it after selecting Azure Monitor as the source as shown below
-
Observe the Grafana dashboard for the metrics visualization.
a. Observe the dashboard after selecting the appropriate - Subscription, Resource Group and then choose the inventoryapi Container App we created previously. You will observe the resource allocations for CPU and Memory. With no recent activity / load testing - the Max Request Count and Max Replica Count should also show 0.
b. Generate/simulate concurrent user and http requests load using a load testing mechanism of your choice to the inventoryapi App Url
c. Now observe the dashboard for changes in values. Scroll down the dashboard to the various sections to observe what this pre-built dashboard provides for visualization.
Challenges (optional)
- Explore other ways to visualize metrics and implement an Azure native one without using Grafana.