Partager via

Configurer une image conteneur pour exécuter des déploiements

  • Article

Les Environnements de déploiement Azure (ADE) prennent en charge un modèle d’extensibilité qui vous permet de configurer votre définition d’environnement avec votre infrastructure de modèle IaC préférée. Vous pouvez stocker des images personnalisées dans un registre de conteneurs comme Azure Container Registry (ACR) ou Docker Hub, puis les référencer dans vos définitions d’environnement pour déployer des environnements.

Dans cet article, vous allez apprendre à générer des images conteneur Bicep personnalisées pour déployer vos définitions d’environnement dans ADE. Vous découvrirez comment utiliser une image standard fournie par Microsoft ou comment configurer une infrastructure d’approvisionnement d’image personnalisée à l’aide de l’infrastructure IaC (Infrastructure-as-Code) Bicep.

Dans cet article, vous allez apprendre à générer des images conteneur Terraform personnalisées pour créer des environnements de déploiement avec les Environnements de déploiement Azure (ADE). Vous apprenez à configurer une image personnalisée pour provisionner une infrastructure en utilisant le framework Infrastructure en tant que code (IaC) Terraform.

Dans cet article, vous apprendrez à utiliser Pulumi pour les déploiements dans ADE. Vous découvrirez comment utiliser une image standard fournie par Pulumi ou comment configurer une image personnalisée pour approvisionner une infrastructure à l’aide de l’infrastructure IaC (Infrastructure-as-Code) Pulumi.

Prérequis

Utiliser les images conteneur avec ADE

Vous pouvez adopter l’une des approches suivantes pour utiliser des images conteneur avec ADE :

  • Utiliser une image conteneur standard Pour les scénarios simples, utilisez l’image conteneur ARM-Bicep standard fournie par ADE.
  • Créer une image conteneur personnalisée Pour des scénarios plus complexes, créez une image conteneur personnalisée qui répond à vos besoins spécifiques.

Utiliser une image conteneur standard

ADE prend en charge Azure Resource Manager (ARM) et Bicep sans nécessiter de configuration supplémentaire. Vous pouvez créer une définition d’environnement qui déploie des ressources Azure pour un environnement de déploiement en ajoutant les fichiers de modèle (comme azuredeploy.json et environment.yaml) à votre catalogue. ADE utilise ensuite l’image conteneur ARM-Bicep standard pour créer l’environnement de déploiement.

Dans le fichier environment.yaml, la propriété runner spécifie l’emplacement de l’image conteneur que vous souhaitez utiliser. Pour utiliser l’image standard publiée dans le Registre des artefacts Microsoft, utilisez les identificateurs runner respectifs.

L’exemple suivant montre un runner qui référence l’image conteneur ARM-Bicep standard :

    name: WebApp
    version: 1.0.0
    summary: Azure Web App Environment
    description: Deploys a web app in Azure without a datastore
    runner: Bicep
    templatePath: azuredeploy.json

Vous pouvez voir l’image conteneur Bicep standard dans le référentiel standard ADE sous Dossier Runner-Images pour l’image ARM-Bicep.

Pour plus d’informations sur la création de définitions d’environnement qui utilisent les images conteneur ADE pour déployer vos ressources Azure, consultez Ajouter et configurer une définition d’environnement.

Créer une image de conteneur personnalisée

Créer une image conteneur personnalisée à l’aide d’un script

La création d’une image conteneur personnalisée vous permet de personnaliser vos déploiements en fonction de vos besoins. Vous pouvez créer des images personnalisées basées sur des images standard ADE.

Une fois la personnalisation de l’image terminée, vous pouvez générer l’image et l’envoyer (push) vers votre registre de conteneurs à l’aide d’un script fourni par Microsoft pour automatiser le processus.

Vous générez des images personnalisées en utilisant les images standard ADE en tant que base avec l’interface CLI ADE, qui est préinstallée sur les images standard. Pour en savoir plus sur l’interface CLI ADE, consultez les Informations de référence sur les images Runner personnalisées de l’interface CLI.

Dans cet exemple, vous apprenez à créer une image Docker pour utiliser des déploiements ADE et accéder à l’interface CLI ADE, en basant votre image sur l’une des images créées par ADE.

Pour créer une image configurée pour ADE, suivez ces étapes :

  1. Créer une image personnalisée basée sur une image standard.
  2. Installer les packages souhaités.
  3. Configurer des scripts d’interpréteur de commandes d’opération.
  4. Créer des scripts d’interpréteur de commandes d’opération pour déployer des modèles ARM ou Bicep.

1. Créer une image personnalisée basée sur une image standard

Créez un Dockerfile qui inclut une instruction FROM pointant vers une image standard hébergée dans le Registre des artefacts Microsoft.

Voici un exemple d’instruction FROM qui référence l’image principale standard :

FROM mcr.microsoft.com/deployment-environments/runners/core:latest

Cette instruction extrait la dernière image de base publiée et en fait la base de votre image personnalisée.

2. Installer les packages nécessaires

Lors de cette étape, vous installez tous les packages dont vous avez besoin dans votre image, y compris Bicep. Vous pouvez installer le package Bicep avec Azure CLI en utilisant l’instruction RUN, comme illustré dans l’exemple suivant :

RUN az bicep install

Les images standard ADE sont basées sur l’image Azure CLI, et les packages de l’interface CLI ADE et JQ sont préinstallés. Vous pouvez en savoir plus sur Azure CLI et le package JQ.

Pour installer les autres packages dont vous avez besoin dans votre image, utilisez l’instruction RUN.

3. Configurer des scripts d’interpréteur de commandes d’opération

Dans les images standard, les opérations sont déterminées et exécutées en fonction du nom de l’opération. Actuellement, les deux noms d’opération pris en charge sont deploy et delete.

Pour configurer votre image personnalisée afin qu’elle utilise cette structure, spécifiez un dossier au niveau de votre fichier Dockerfile nommé scripts, puis spécifiez deux fichiers, deploy.shet delete.sh. Le script d’interpréteur de commandes deploy s’exécute quand votre environnement est créé ou redéployé, et le script d’interpréteur de commandes delete s’exécute quand votre environnement est supprimé. Vous pouvez voir des exemples de scripts d’interpréteur de commandes dans le dépôt sous le dossier Runner-Images pour l’image ARM-BICEP.

Pour vérifier que ces scripts d’interpréteur de commandes sont exécutables, ajoutez les lignes suivantes à votre fichier Dockerfile :

COPY scripts/* /scripts/
RUN find /scripts/ -type f -iname "*.sh" -exec dos2unix '{}' '+'
RUN find /scripts/ -type f -iname "*.sh" -exec chmod +x {} \;

4. Créer des scripts d’interpréteur de commandes d’opération pour déployer des modèles ARM ou Bicep

Pour vous assurer que vous pouvez correctement déployer l’infrastructure ARM ou Bicep via ADE, vous devez :

  1. Convertir les paramètres ADE en paramètres acceptables pour ARM
  2. Résoudre les modèles liés s’ils sont utilisés dans le déploiement
  3. Utiliser l’identité managée privilégiée pour effectuer le déploiement

Durant la phase entrypoint de l’image core, tous les paramètres définis pour l’environnement actuel sont stockés sous la variable $ADE_OPERATION_PARAMETERS. Pour les convertir en paramètres acceptables pour ARM, vous pouvez exécuter la commande suivante avec JQ :

# format the parameters as arm parameters
deploymentParameters=$(echo "$ADE_OPERATION_PARAMETERS" | jq --compact-output '{ "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#", "contentVersion": "1.0.0.0", "parameters": (to_entries | if length == 0 then {} else (map( { (.key): { "value": .value } } ) | add) end) }' )

Ensuite, pour résoudre tous les modèles liés utilisés dans un modèle ARM basé sur JSON, vous pouvez décompiler le fichier de modèle principal, qui résout tous les fichiers d’infrastructure locaux utilisés dans de nombreux modules Bicep. Ensuite, régénérez ces modules dans un modèle ARM unique en incorporant les modèles liés dans le modèle ARM principal en tant que modèles imbriqués. Cette étape est nécessaire uniquement pendant l’opération de déploiement. Le fichier de modèle principal peut être spécifié avec le $ADE_TEMPLATE_FILE défini durant la phase entrypoint de l’image core. Vous devez réinitialiser cette variable avec le fichier de modèle recompilé. Voir l’exemple suivant :

if [[ $ADE_TEMPLATE_FILE == *.json ]]; then

    hasRelativePath=$( cat $ADE_TEMPLATE_FILE | jq '[.. | objects | select(has("templateLink") and (.templateLink | has("relativePath")))] | any' )

    if [ "$hasRelativePath" = "true" ]; then
        echo "Resolving linked ARM templates"

        bicepTemplate="${ADE_TEMPLATE_FILE/.json/.bicep}"
        generatedTemplate="${ADE_TEMPLATE_FILE/.json/.generated.json}"

        az bicep decompile --file "$ADE_TEMPLATE_FILE"
        az bicep build --file "$bicepTemplate" --outfile "$generatedTemplate"

        # Correctly reassign ADE_TEMPLATE_FILE without the $ prefix during assignment
        ADE_TEMPLATE_FILE="$generatedTemplate"
    fi
fi

Pour fournir à un déploiement les autorisations nécessaires pour exécuter le déploiement et la suppression des ressources au sein de l’abonnement, utilisez l’identité managée privilégiée associée au type d’environnement de projet ADE. Si votre déploiement nécessite des autorisations spéciales, notamment des rôles particuliers, attribuez ces rôles à l’identité du type d’environnement de projet. Parfois, l’identité managée n’est pas immédiatement disponible quand vous entrez le conteneur. Vous pouvez réessayer jusqu’à ce que la connexion réussisse.

echo "Signing into Azure using MSI"
while true; do
    # managed identity isn't available immediately
    # we need to do retry after a short nap
    az login --identity --allow-no-subscriptions --only-show-errors --output none && {
        echo "Successfully signed into Azure"
        break
    } || sleep 5
done

Pour commencer le déploiement des modèles ARM ou Bicep, exécutez la commande az deployment group create. Lors de l’exécution de cette commande à l’intérieur du conteneur, choisissez un nom de déploiement qui ne remplace pas les déploiements passés, et utilisez les indicateurs --no-prompt true et --only-show-errors pour vous assurer que le déploiement n’échoue pas en cas d’avertissement ou ne se bloque pas en attendant une entrée utilisateur, comme le montre l’exemple suivant :

deploymentName=$(date +"%Y-%m-%d-%H%M%S")
az deployment group create --subscription $ADE_SUBSCRIPTION_ID \
    --resource-group "$ADE_RESOURCE_GROUP_NAME" \
    --name "$deploymentName" \
    --no-prompt true --no-wait \
    --template-file "$ADE_TEMPLATE_FILE" \
    --parameters "$deploymentParameters" \
    --only-show-errors

Pour supprimer un environnement, effectuez un déploiement en mode Complete et fournissez un modèle ARM vide qui supprime toutes les ressources dans le groupe de ressources ADE spécifié, comme le montre l’exemple suivant :

deploymentName=$(date +"%Y-%m-%d-%H%M%S")
az deployment group create --resource-group "$ADE_RESOURCE_GROUP_NAME" \
    --name "$deploymentName" \
    --no-prompt true --no-wait --mode Complete \
    --only-show-errors \
    --template-file "$DIR/empty.json"

Vous pouvez consulter l’état et les détails de l’approvisionnement en exécutant les commandes ci-dessous. ADE utilise des fonctions spéciales pour lire et fournir plus de contexte en fonction des détails de provisionnement, disponibles dans le dossier Runner-Images. Voici un exemple d’implémentation simple :

if [ $? -eq 0 ]; then # deployment successfully created
    while true; do

        sleep 1

        ProvisioningState=$(az deployment group show --resource-group "$ADE_RESOURCE_GROUP_NAME" --name "$deploymentName" --query "properties.provisioningState" -o tsv)
        ProvisioningDetails=$(az deployment operation group list --resource-group "$ADE_RESOURCE_GROUP_NAME" --name "$deploymentName")

        echo "$ProvisioningDetails"

        if [[ "CANCELED|FAILED|SUCCEEDED" == *"${ProvisioningState^^}"* ]]; then

            echo -e "\nDeployment $deploymentName: $ProvisioningState"

            if [[ "CANCELED|FAILED" == *"${ProvisioningState^^}"* ]]; then
                exit 11
            else
                break
            fi
        fi
    done
fi

Enfin, pour afficher les sorties de votre déploiement et les passer à ADE afin de les rendre accessibles via Azure CLI, vous pouvez exécuter les commandes suivantes :

deploymentOutput=$(az deployment group show -g "$ADE_RESOURCE_GROUP_NAME" -n "$deploymentName" --query properties.outputs)
if [ -z "$deploymentOutput" ]; then
    deploymentOutput="{}"
fi
echo "{\"outputs\": $deploymentOutput}" > $ADE_OUTPUTS

Générer une image conteneur avec un script

Plutôt que de générer votre image personnalisée et de l’envoyer vers un registre de conteneurs vous-même, vous pouvez utiliser un script pour générer et envoyer votre image personnalisée vers un registre de conteneurs spécifié.

Microsoft fournit un script de démarrage rapide pour vous aider à générer votre image personnalisée et à l’envoyer vers un registre. Le script génère votre image et la pousse dans une instance Azure Container Registry (ACR) spécifiée sous le dépôt ade et l’étiquette latest.

Pour utiliser le script, vous devez :

  1. Créez un fichier Dockerfile et un dossier scripts pour prendre en charge le modèle d’extensibilité ADE.
  2. Fournir un nom de registre et un répertoire pour votre image personnalisée.
  3. Avoir Azure CLI et Docker Desktop installés et ajoutés dans vos variables PATH.
  4. Avoir Docker Desktop en cours d’exécution.
  5. Avoir l’autorisation de pousser dans le registre spécifié.

Vous pouvez voir le script ici.

Vous pouvez appeler le script avec la commande suivante dans PowerShell :

.\quickstart-image-build.ps1 -Registry '{YOUR_REGISTRY}' -Directory '{DIRECTORY_TO_YOUR_IMAGE}'

Par ailleurs, si vous voulez pousser l’image vers un dépôt et un nom d’étiquette spécifiques, vous pouvez exécuter :

.\quickstart-image.build.ps1 -Registry '{YOUR_REGISTRY}' -Directory '{DIRECTORY_TO_YOUR_IMAGE}' -Repository '{YOUR_REPOSITORY}' -Tag '{YOUR_TAG}'

Utiliser les images conteneur avec ADE

Vous pouvez adopter l’une des approches suivantes pour utiliser des images conteneur avec ADE :

  • Créer une image conteneur tirant parti d’un flux de travail GitHub : pour commencer, vous pouvez utiliser le flux de travail GitHub publié à partir du modèle d’extensibilité d’ADE avec le référentiel Terraform.
  • Créer une image conteneur personnalisée : vous pouvez créer un flux de travail qui crée une image spécifique de Terraform personnalisée avec tous les logiciels, les paramètres et la configuration dont vous avez besoin.

Créer une image conteneur à l’aide d’un flux de travail GitHub

La création d’une image conteneur personnalisée vous permet de personnaliser vos déploiements en fonction de vos besoins. Vous pouvez créer des images personnalisées basées sur des images standard ADE.

Une fois la personnalisation de l’image terminée, vous devez générer l’image et la transmettre (push) à votre registre de conteneurs.

Vous pouvez générer et envoyer (push) l’image manuellement, ou utiliser un script fourni par Microsoft pour automatiser le processus.

L’action GitHub publiée permet de générer et d’envoyer (push) une image vers Azure Container Registry (ACR). Vous pouvez référencer un lien d’image ACR fourni dans une définition d’environnement dans ADE pour déployer ou supprimer un environnement avec l’image fournie.

Pour créer une image configurée pour ADE, suivez ces étapes :

  1. Créer une image personnalisée basée sur un flux de travail GitHub.
  2. Installer les packages souhaités.
  3. Configurer des scripts d’interpréteur de commandes d’opération.
  4. Créer des scripts d’interpréteur de commandes d’opération qui utilisent l’interface CLI Terraform.

1. Créer une image personnalisée basée sur un flux de travail GitHub

Utilisez le référentiel publié pour tirer parti du flux de travail GitHub. Le référentiel contient des exemples d’images compatibles avec ADE, notamment un Dockerfile et des scripts d’interpréteur de commandes pour le déploiement et la suppression d’environnements à l’aide de modèles Terraform IaC. Cet exemple de code vous aide à créer votre propre image conteneur.

2. Installer les packages nécessaires Lors de cette étape, vous installez tous les packages dont vous avez besoin dans votre image, y compris Terraform. Vous pouvez installer l’interface CLI Terraform dans un emplacement exécutable pour pouvoir l’utiliser dans vos scripts de déploiement et de suppression.

Voici un exemple de ce processus, qui installe la version 1.7.5 de l’interface CLI Terraform :

RUN wget -O terraform.zip https://releases.hashicorp.com/terraform/1.7.5/terraform_1.7.5_linux_amd64.zip
RUN unzip terraform.zip && rm terraform.zip
RUN mv terraform /usr/bin/terraform

Conseil

Vous pouvez obtenir l’URL de téléchargement de votre version préférée de l’interface CLI Terraform à partir des publications Hashicorp.

3. Configurer des scripts d’interpréteur de commandes d’opération

Dans les images standard, les opérations sont déterminées et exécutées en fonction du nom de l’opération. Actuellement, les deux noms d’opération pris en charge sont deploy et delete.

Pour configurer votre image personnalisée afin qu’elle utilise cette structure, spécifiez un dossier au niveau de votre fichier Dockerfile nommé scripts, puis spécifiez deux fichiers, deploy.shet delete.sh. Le script d’interpréteur de commandes deploy s’exécute quand votre environnement est créé ou redéployé, et le script d’interpréteur de commandes delete s’exécute quand votre environnement est supprimé. Vous pouvez voir des exemples de scripts d’interpréteur de commandes dans le dépôt sous le dossier Runner-Images pour l’image ARM-BICEP.

Pour vérifier que ces scripts d’interpréteur de commandes sont exécutables, ajoutez les lignes suivantes à votre fichier Dockerfile :

COPY scripts/* /scripts/
RUN find /scripts/ -type f -iname "*.sh" -exec dos2unix '{}' '+'
RUN find /scripts/ -type f -iname "*.sh" -exec chmod +x {} \;

4. Créer des scripts d’interpréteur de commandes d’opération qui utilisent l’interface CLI Terraform

Il y a trois étapes pour déployer l’infrastructure via Terraform :

  1. terraform init : initialise l’interface CLI Terraform pour effectuer des actions dans le répertoire de travail
  2. terraform plan : développe un plan basé sur les fichiers et variables entrants de l’infrastructure Terraform, ainsi que tous les fichiers d’état existants, et développe les étapes nécessaires pour créer ou mettre à jour l’infrastructure spécifiée dans les fichiers .tf
  3. terraform apply : applique le plan pour créer une infrastructure ou mettre à jour l’existante dans Azure

Pendant le point d’entrée de l’image de base, tous les fichiers d’état existants sont extraits dans le conteneur et le répertoire enregistré sous la variable d’environnement $ADE_STORAGE. Par ailleurs, tous les paramètres définis pour l’environnement actuel sont stockés sous la variable $ADE_OPERATION_PARAMETERS. Pour accéder au fichier d’état existant et définir vos variables dans un fichier .tfvars.json, exécutez les commandes suivantes :

EnvironmentState="$ADE_STORAGE/environment.tfstate"
EnvironmentPlan="/environment.tfplan"
EnvironmentVars="/environment.tfvars.json"

echo "$ADE_OPERATION_PARAMETERS" > $EnvironmentVars

Par ailleurs, pour utiliser les privilèges ADE et déployer l’infrastructure dans votre abonnement, votre script doit utiliser l’identité MSI (Managed Service Identity) pendant l’approvisionnement de l’infrastructure avec le fournisseur Terraform AzureRM. Si votre déploiement a besoin d’autorisations spéciales pour effectuer votre déploiement, comme des rôles particuliers, attribuez ces autorisations à l’identité du type d’environnement de projet utilisée pour le déploiement de votre environnement. Étant donné qu’ADE définit les variables d’environnement appropriées, comme le client, le locataire et les ID d’abonnement au sein du point d’entrée de l’image de base, exécutez les commandes suivantes pour que le fournisseur utilise l’identité MSI ADE :

export ARM_USE_MSI=true
export ARM_CLIENT_ID=$ADE_CLIENT_ID
export ARM_TENANT_ID=$ADE_TENANT_ID
export ARM_SUBSCRIPTION_ID=$ADE_SUBSCRIPTION_ID

Si vous avez d’autres variables à référencer dans votre modèle qui ne sont pas spécifiées dans les paramètres de votre environnement, définissez des variables d’environnement avec le préfixe TF_VAR. Une liste des variables d’environnement ADE fournies est mise à disposition pour la référence des variables CLI d’environnement de déploiement Azure. Voici un exemple de ces commandes :

export TF_VAR_resource_group_name=$ADE_RESOURCE_GROUP_NAME
export TF_VAR_ade_env_name=$ADE_ENVIRONMENT_NAME
export TF_VAR_env_name=$ADE_ENVIRONMENT_NAME
export TF_VAR_ade_subscription=$ADE_SUBSCRIPTION_ID
export TF_VAR_ade_location=$ADE_ENVIRONMENT_LOCATION
export TF_VAR_ade_environment_type=$ADE_ENVIRONMENT_TYPE

À présent, vous pouvez exécuter les étapes listées précédemment pour initialiser l’interface CLI Terraform, générer un plan pour l’infrastructure de provisionnement et appliquer un plan pendant votre script de déploiement :

terraform init
terraform plan -no-color -compact-warnings -refresh=true -lock=true -state=$EnvironmentState -out=$EnvironmentPlan -var-file="$EnvironmentVars"
terraform apply -no-color -compact-warnings -auto-approve -lock=true -state=$EnvironmentState $EnvironmentPlan

Pendant votre script de suppression, vous pouvez ajouter l’indicateur destroy à votre génération de plan afin de supprimer les ressources existantes, comme illustré dans l’exemple suivant :

terraform init
terraform plan -no-color -compact-warnings -destroy -refresh=true -lock=true -state=$EnvironmentState -out=$EnvironmentPlan -var-file="$EnvironmentVars"
terraform apply -no-color -compact-warnings -auto-approve -lock=true -state=$EnvironmentState $EnvironmentPlan

Enfin, pour que les sorties de votre déploiement soient chargées et accessibles quand vous accédez à votre environnement avec Azure CLI, convertissez l’objet de sortie de Terraform au format spécifié par ADE avec le package JQ. Définissez la valeur de la variable d'environnement $ADE_OUTPUTS, comme indiqué dans l’exemple suivant :

tfOutputs=$(terraform output -state=$EnvironmentState -json)
# Convert Terraform output format to ADE format.
tfOutputs=$(jq 'walk(if type == "object" then 
            if .type == "bool" then .type = "boolean" 
            elif .type == "list" then .type = "array" 
            elif .type == "map" then .type = "object" 
            elif .type == "set" then .type = "array" 
            elif (.type | type) == "array" then 
                if .type[0] == "tuple" then .type = "array" 
                elif .type[0] == "object" then .type = "object" 
                elif .type[0] == "set" then .type = "array" 
                else . 
                end 
            else . 
            end 
        else . 
        end)' <<< "$tfOutputs")

echo "{\"outputs\": $tfOutputs}" > $ADE_OUTPUTS

Générer l’image personnalisée

Vous pouvez générer votre image à l’aide de l’interface CLI Docker. Vérifiez que le moteur Docker est installé sur votre ordinateur. Ensuite, accédez au répertoire de votre fichier Dockerfile, puis exécutez la commande suivante :

docker build . -t {YOUR_REGISTRY}.azurecr.io/{YOUR_REPOSITORY}:{YOUR_TAG}

Par exemple, si vous voulez enregistrer votre image sous un dépôt au sein de votre registre nommé customImage et le charger avec la version d’étiquette 1.0.0, vous exécutez :

docker build . -t {YOUR_REGISTRY}.azurecr.io/customImage:1.0.0

Utiliser une image conteneur standard fournie par Pulumi

L’équipe Pulumi fournit une image prédéfinie pour vous aider à démarrer, que vous pouvez voir dans le dossier Runner-Image. Cette image est disponible publiquement sur le Docker Hub de Pulumi en tant que pulumi/azure-deployment-environments. Vous pouvez donc l’utiliser directement à partir de vos définitions d’environnement ADE.

Voici un exemple de fichier environment.yaml qui utilise l’image prédéfinie :

name: SampleDefinition
version: 1.0.0
summary: First Pulumi-Enabled Environment
description: Deploys a Storage Account with Pulumi
runner: pulumi/azure-deployment-environments:0.1.0
templatePath: Pulumi.yaml

Vous trouverez quelques exemples de définitions d’environnement dans le dossier Environnements.

Créer une image personnalisée

La création d’une image conteneur personnalisée vous permet de personnaliser vos déploiements en fonction de vos besoins. Vous pouvez créer des images personnalisées basées sur les images standard Pulumi et les personnaliser pour répondre à vos besoins. Une fois la personnalisation de l’image terminée, vous devez générer l’image et la transmettre (push) à votre registre de conteneurs.

Pour créer une image configurée pour ADE, suivez ces étapes :

  1. Créer une image personnalisée basée sur une image standard.
  2. Installer les packages souhaités.
  3. Configurer des scripts d’interpréteur de commandes d’opération.
  4. Créer des scripts d’interpréteur de commandes d’opération qui utilisent l’interface CLI Pulumi.

1. Créer une image personnalisée basée sur une image standard

Créez un Dockerfile qui inclut une instruction FROM pointant vers une image standard hébergée dans le Registre des artefacts Microsoft.

Voici un exemple d’instruction FROM qui référence l’image principale standard :

FROM mcr.microsoft.com/deployment-environments/runners/core:latest

Cette instruction extrait la dernière image de base publiée et en fait la base de votre image personnalisée.

2. Installer les packages nécessaires

Vous pouvez installer l’interface CLI Pulumi dans un emplacement exécutable pour pouvoir l’utiliser dans vos scripts de déploiement et de suppression.

Voici un exemple de ce processus, en installant la dernière version de l’interface CLI Pulumi :

RUN apk add curl
RUN curl -fsSL https://get.pulumi.com | sh
ENV PATH="${PATH}:/root/.pulumi/bin"

En fonction du langage de programmation que vous envisagez d’utiliser pour les programmes Pulumi, vous devrez peut-être installer un ou plusieurs runtimes correspondants. Le runtime Python est déjà disponible dans l’image de base.

Voici un exemple d’installation de Node.js et de TypeScript :

# install node.js, npm, and typescript
RUN apk add nodejs npm
RUN npm install typescript -g

Les images standard ADE sont basées sur l’image Azure CLI, et les packages de l’interface CLI ADE et JQ sont préinstallés. Vous pouvez en savoir plus sur Azure CLI et le package JQ.

Pour installer les autres packages dont vous avez besoin dans votre image, utilisez l’instruction RUN.

Il existe quatre étapes pour déployer l’infrastructure via Pulumi :

  1. pulumi login : connectez-vous au stockage d’état, dans le système de fichiers local ou dans Pulumi Cloud
  2. pulumi stack select : créez ou sélectionnez la pile à utiliser pour l’environnement particulier
  3. pulumi config set : passez les paramètres de déploiement en tant que valeurs de configuration Pulumi
  4. pulumi up : exécutez le déploiement pour créer une infrastructure ou mettre à jour l’infrastructure existante dans Azure

Pendant le point d’entrée de l’image de base, tous les fichiers d’état locaux existants sont extraits dans le conteneur et le répertoire enregistré sous la variable d’environnement $ADE_STORAGE. Pour accéder au fichier d’état existant, exécutez les commandes suivantes :

mkdir -p $ADE_STORAGE
export PULUMI_CONFIG_PASSPHRASE=
pulumi login file://$ADE_STORAGE

Pour vous connecter à Pulumi Cloud à la place, définissez votre jeton d’accès Pulumi en tant que variable d’environnement et exécutez les commandes suivantes :

export PULUMI_ACCESS_TOKEN=YOUR_PULUMI_ACCESS_TOKEN
pulumi login

Tous les paramètres définis pour l’environnement actuel sont stockés sous la variable $ADE_OPERATION_PARAMETERS. En outre, la région Azure et le nom du groupe de ressources sélectionnés sont passés respectivement dans ADE_ENVIRONMENT_LOCATION et ADE_RESOURCE_GROUP_NAME. Pour définir votre configuration de pile Pulumi, exécutez les commandes suivantes :

# Create or select the stack for the current environment
pulumi stack select $ADE_ENVIRONMENT_NAME --create

# Store configuration values in durable storage
export PULUMI_CONFIG_FILE=$ADE_STORAGE/Pulumi.$ADE_ENVIRONMENT_NAME.yaml

# Set the Pulumi stack config
pulumi config set azure-native:location $ADE_ENVIRONMENT_LOCATION --config-file $PULUMI_CONFIG_FILE
pulumi config set resource-group-name $ADE_RESOURCE_GROUP_NAME --config-file $PULUMI_CONFIG_FILE
echo "$ADE_OPERATION_PARAMETERS" | jq -r 'to_entries|.[]|[.key, .value] | @tsv' |
  while IFS=$'\t' read -r key value; do
    pulumi config set $key $value --config-file $PULUMI_CONFIG_FILE
  done

Par ailleurs, pour utiliser les privilèges ADE et déployer l’infrastructure dans votre abonnement, votre script doit utiliser l’identité MSI (Managed Service Identity) ADE pendant l’approvisionnement de l’infrastructure à l’aide du fournisseur Pulumi Azure natif ou Azure Classic. Si votre déploiement a besoin d’autorisations spéciales pour effectuer votre déploiement, comme des rôles particuliers, attribuez ces autorisations à l’identité du type d’environnement de projet utilisée pour le déploiement de votre environnement. Étant donné qu’ADE définit les variables d’environnement appropriées, comme le client, le locataire et les ID d’abonnement au sein du point d’entrée de l’image de base, exécutez les commandes suivantes pour que le fournisseur utilise l’identité MSI ADE :

export ARM_USE_MSI=true
export ARM_CLIENT_ID=$ADE_CLIENT_ID
export ARM_TENANT_ID=$ADE_TENANT_ID
export ARM_SUBSCRIPTION_ID=$ADE_SUBSCRIPTION_ID

À présent, vous pouvez exécuter la commande pulumi up pour exécuter le déploiement :

pulumi up --refresh --yes --config-file $PULUMI_CONFIG_FILE

Sinon, pendant votre script de suppression, vous pouvez exécuter la commande destroy, comme illustré dans l’exemple suivant :

pulumi destroy --refresh --yes --config-file $PULUMI_CONFIG_FILE

Enfin, pour que les sorties de votre déploiement soient chargées et accessibles quand vous accédez à votre environnement avec Azure CLI, convertissez l’objet de sortie de Pulumi au format spécifié par ADE avec le package JQ. Définissez la valeur de la variable d'environnement $ADE_OUTPUTS, comme indiqué dans l’exemple suivant :

stackout=$(pulumi stack output --json | jq -r 'to_entries|.[]|{(.key): {type: "string", value: (.value)}}')
echo "{\"outputs\": ${stackout:-{\}}}" > $ADE_OUTPUTS

Générer l’image personnalisée

Vous pouvez générer votre image à l’aide de l’interface CLI Docker. Vérifiez que le moteur Docker est installé sur votre ordinateur. Ensuite, accédez au répertoire de votre fichier Dockerfile, puis exécutez la commande suivante :

docker build . -t {YOUR_REGISTRY}.azurecr.io/{YOUR_REPOSITORY}:{YOUR_TAG}

Par exemple, si vous voulez enregistrer votre image sous un dépôt au sein de votre registre nommé customImage et le charger avec la version d’étiquette 1.0.0, vous exécutez :

docker build . -t {YOUR_REGISTRY}.azurecr.io/customImage:1.0.0

Rendre l’image personnalisée accessible à ADE

Pour pouvoir utiliser des images personnalisées, vous devez les stocker dans un registre de conteneurs. Vous pouvez utiliser un registre de conteneurs public ou un registre de conteneurs privé. Azure Container Registry (ACR) est fortement recommandé, car en raison de son intégration étroite avec ADE, l’image peut être publiée sans autoriser l’accès par extraction anonyme public. Vous devez générer votre image conteneur personnalisée et l’envoyer (push) vers un registre de conteneurs afin de la rendre disponible dans ADE.

Il est également possible de stocker l’image dans un autre registre de conteneurs comme Docker Hub mais dans ce cas, il doit être accessible publiquement.

Attention

Le stockage de votre image conteneur dans un registre avec un accès par extraction anonyme (non authentifié) le rend accessible publiquement. Ne faites pas cela si votre image contient des informations sensibles. Au lieu de cela, stockez-le dans Azure Container Registry (ACR) avec un accès par extraction anonyme désactivé.

Pour utiliser une image personnalisée stockée dans ACR, vous devez vérifier qu’ADE dispose des autorisations appropriées pour accéder à votre image. Lorsque vous créez une instance ACR, elle est sécurisée par défaut et autorise l’accès uniquement aux utilisateurs authentifiés.

Vous pouvez utiliser Pulumi pour créer un Registre de conteneurs Azure et y publier votre image. Reportez-vous à l’exemple Approvisionnement/image personnalisée pour un projet Pulumi autonome qui crée toutes les ressources nécessaires dans votre compte Azure.

Sélectionnez l’onglet approprié pour en savoir plus sur chaque approche.

Utiliser un registre privé avec un accès sécurisé

Par défaut, l’accès pour extraire ou envoyer du contenu dans un registre de conteneurs Azure est disponible seulement pour les utilisateurs authentifiés. Vous pouvez sécuriser davantage l’accès à ACR en limitant l’accès depuis certains réseaux et en attribuant des rôles spécifiques.

Pour créer une instance d’ACR, qui peut être effectuée via Azure CLI, le Portail Azure, des commandes PowerShell, etc., suivez l’un des guides de démarrage rapide.

Limiter l’accès réseau

Pour sécuriser l’accès réseau à votre ACR, vous pouvez limiter l’accès à vos propres réseaux ou désactiver entièrement l’accès du réseau public. Si vous limitez l’accès réseau, vous devez activer l’exception de pare-feu Autoriser les services Microsoft approuvés à accéder à ce registre de conteneurs.

Pour désactiver l’accès depuis des réseaux publics :

  1. Créez une instance ACR ou utilisez une instance existante.

  2. Dans le portail Azure, accédez à l’ACR que vous souhaitez configurer.

  3. Dans le menu de gauche, sous Paramètres, sélectionnez Mise en réseau.

  4. Dans la page Mise en réseau, sous l’onglet Accès réseau public, sélectionnez Désactivé.

    Capture d’écran du portail Azure montrant les paramètres réseau d’ACR, avec Accès public et Désactivé mis en évidence.

  5. Sous Exception pare-feu, vérifiez que Autoriser les services Microsoft approuvés à accéder à ce registre de conteneurs est sélectionné, puis sélectionnez Enregistrer.

    Capture d’écran des paramètres réseau d’ACR, avec Autoriser les services Microsoft approuvés à accéder à ce registre de conteneurs et Enregistrer mis en évidence.

Attribuer le rôle AcrPull

La création d’environnements en utilisant des images conteneur utilise l’infrastructure ADE, y compris les projets et les types d’environnement. Chaque projet a un ou plusieurs types d’environnement de projet, qui ont besoin d’un accès en lecture à l’image conteneur qui définit l’environnement à déployer. Pour accéder aux images de votre ACR de façon sécurisée, attribuez le rôle AcrPull à chaque type d’environnement de projet.

Pour attribuer le rôle AcrPull au type d’environnement de projet :

  1. Dans le portail Azure, accédez à l’ACR que vous souhaitez configurer.

  2. Dans le menu de gauche, sélectionnez contrôle d’accès (IAM).

  3. Sélectionnez Ajouter>Ajouter une attribution de rôle.

  4. Attribuez le rôle suivant. Pour connaître les étapes détaillées, consultez Attribuer des rôles Azure à l’aide du portail Azure.

    Paramètre Valeur
    Rôle Sélectionnez AcrPull.
    Attribuer l’accès à Sélectionnez Utilisateur, groupe ou principal de service.
    Members (Membres) Entrez le nom du type d’environnement de projet qui doit accéder à l’image dans le conteneur.

    Le type d’environnement de projet s’affiche comme dans l’exemple suivant :

    Capture d’écran du volet Sélectionner des membres, montrant une liste de types d’environnement de projet avec une partie du nom mise en évidence.

Dans cette configuration, ADE utilise l’identité managée pour le type d’environnement de projet, qu’il soit affecté par le système ou par l’utilisateur.

Conseil

Cette attribution de rôle doit être effectuée pour chaque type d’environnement de projet. Elle peut être automatisée via Azure CLI.

Quand vous êtes prêt à pousser votre image dans votre registre, exécutez la commande suivante :

docker push {YOUR_REGISTRY}.azurecr.io/{YOUR_IMAGE_LOCATION}:{YOUR_TAG}

Connecter l’image à votre définition d’environnement

Quand vous créez les définitions d’environnement pour utiliser votre image personnalisée dans leur déploiement, modifiez la propriété runner dans le fichier manifeste (environment.yaml ou manifest.yaml).

runner: "{YOUR_REGISTRY}.azurecr.io/{YOUR_REPOSITORY}:{YOUR_TAG}"

Pour en savoir plus sur la création de définitions d’environnement qui utilisent les images conteneur ADE pour déployer vos ressources Azure, consultez Ajouter et configurer une définition d’environnement.

Contenu connexe