Azure Container Apps – Part 2

La théorie c’est bien, la pratique c’est mieux !

Prérequis

D’abord il va vous falloir installer Azure CLI si ça n’est pas déjà fait !

Azure CLI est disponible pour Windows, macOS et Linux. Il peut aussi être exécuté dans un container Docker ainsi que dans Azure Cloud Shell.

La première chose à faire est de vous connecter à Azure avec la commande :

az login

Attention, si vous avez plusieurs souscriptions Azure, sélectionnez celle dont vous avez besoin :

az account set --subscription <subscription name or id>

Une fenêtre de votre navigateur va s’ouvrir pour vous demander de vous connecter.

Une fois connecté, vous retrouverez l’ensemble de vos souscriptions Azure.

Création des ressources nécessaires

1. Resource Group

Première étape, nous allons créer le Resource Group qui va contenir l’ensemble des ressources. Ici il s’appelle rg-my-container-apps :

az group create --name rg-my-container-apps --location "northeurope"

{
  "id": "/subscriptions/XXXXXXXXXXXXXXXXXXXXXXXXX/resourceGroups/rg-my-container-apps",
  "location": "northeurope",
  "name": "rg-my-container-apps",
  "properties": {
    "provisioningState": "Succeeded"
  }
}

2. Log Analytics Workspace

Une fois le Resource Group créé, on va ajouter le Log Analytics Workspace :

az monitor log-analytics workspace create \
  --resource-group rg-my-container-apps \
  --workspace-name my-container-apps-logs

{
  "customerId": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
  "id": "/subscriptions/XXXXXXXXXXXXXXXXXXXXXXXXXXXX/resourceGroups/rg-my-container-apps/providers/Microsoft.OperationalInsights/workspaces/my-container-apps-logs",
  "location": "northeurope",
  "name": "my-container-apps-logs",
  "provisioningState": "Succeeded",
  "retentionInDays": 30,
  "sku": { "name": "PerGB2018" }
}

3. Récupérer le Client ID et le Client Secret

Maintenant que l’on a le Log Analytics Workspace, nous allons avoir besoin du Client ID et du Client Secret pour s’y connecter :

# GET CLIENT ID
az monitor log-analytics workspace show \
  --query customerId \
  -g rg-my-container-apps \
  -n my-container-apps-logs \
  --out tsv

# GET CLIENT SECRET
az monitor log-analytics workspace get-shared-keys \
  --query primarySharedKey \
  -g rg-my-container-apps \
  -n my-container-apps-logs \
  --out tsv

4. Création de l’environnement

Vous avez noté le Client ID et le Client Secret ? On peut maintenant créer l’environnement :

az containerapp env create \
  --name my-environment \
  --resource-group rg-my-container-apps \
  --logs-workspace-id XXXXXXXXXXXXXXXXXXXX \
  --logs-workspace-key XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX \
  --location "northeurope"

{
  "id": "/subscriptions/XXXXXXXXXXXXXXXXXXXXXX/resourceGroups/rg-my-container-apps/providers/Microsoft.App/managedEnvironments/my-environment",
  "location": "northeurope",
  "name": "my-environment",
  "properties": {
    "defaultDomain": "ambitiousgrass-5fea002a.northeurope.azurecontainerapps.io",
    "provisioningState": "Succeeded",
    "staticIp": "20.82.203.237"
  },
  "sku": { "name": "Consumption" }
}

Container App

Il se peut que l’on vous demande d’installer l’extension containerapp lors de la première utilisation.

Tout est OK à présent pour créer notre première Container App !

On se basera sur l’image mcr.microsoft.com/azuredocs/containerapps-helloworld:latest qui vient du Microsoft Artifact Registry — c’est une image de démo.

On va :

Exposer notre container app sur le port 80
Spécifier que c’est accessible de l’extérieur avec --ingress 'external'
Afficher le FQDN de la config

az containerapp create \
  --name my-container-app \
  --resource-group rg-my-container-apps \
  --environment my-environment \
  --image mcr.microsoft.com/azuredocs/containerapps-helloworld:latest \
  --target-port 80 \
  --ingress 'external' \
  --query configuration.ingress.fqdn

Voilà, notre Container App est disponible !

Allons faire un tour sur notre portail azure ! Nous y retrouverons toutes nos ressources créées plus haut.

Allons faire un check de notre config ! on retrouve bien tous nos éléments. ainsi que notre configuration Ingress.

On peut constater également que notre Première révision est créée et active !

Plus loin dans la config …….

On peut voir notre container avec les config “CPU resquest” et “MemoryRequest” cf https://ozaradny.azurewebsites.net/2022/05/29/azure-container-apps/

Nouvelle révision

Et si on essayait de créer une nouvelle révision ?

On se basera sur une nouvelle image DockerHub : mavilleg/acarevision-helloworld:acarevision-hellowold

Attention : Si vous voulez avoir plusieurs révisions simultanément, il faut modifier la config dans “Choose revision mode” et passer en mode Multiple.

Dans le portail, créez une nouvelle révision avec les paramètres suivants :

Champ	Valeur
Name	`my-container-app-2`
Image source	Docker Hub
Image Type	Public
Image and tag	`mavilleg/acarevision-helloworld:acarevision-hellowold`

N’oubliez pas de supprimer l’ancienne image:

puis cliquez sur “Create”.

On peut constater que nos deux révisions sont actives. Par contre, au niveau du traffic HTTP, notre première révision monopolise 100% du traffic. Cela signifie que dans 100% des cas, nous allons accéder à cette révision via l’URL.

Traffic Splitting

Le Traffic Splitting permet de splitter le trafic HTTP entre les 2 révisions. Testons le 50% / 50% :

En configurant le split à 50/50, si on rafraîchit le navigateur on constatera qu’une fois sur deux on tombe sur la première révision et vice versa via l’URL :

https://my-container-app.ambitiousgrass-5fea002a.northeurope.azurecontainerapps.io/

création

nouvelle révision