Partager via


Utiliser des variables d’environnement Azure Developer CLI

Azure Developer CLI (azd) utilise des variables d’environnement pour stocker et gérer les paramètres de configuration pour les environnements de déploiement. Ces variables contrôlent la façon dont votre application est provisionnée, déployée et exécutée dans Azure. Cet article explique comment fonctionnent les variables d’environnement dans azd les environnements et fournit des conseils sur la gestion efficace.

Comprendre les variables d’environnement

Dans le contexte de l’interface CLI développeur Azure, les variables d’environnement sont des paires clé-valeur liées à des environnements nommés spécifiques tels que le développement, le test ou la production. Chaque azd environnement conserve son propre ensemble de variables d’environnement, ce qui vous permet de configurer différents paramètres pour différentes cibles de déploiement.

Les variables d’environnement dans azd sont stockées dans des fichiers .env situés dans vos dossiers d’environnement du dossier .azure. Ils servent comme entrées pour :

  • Flux de travail de déploiement d’applications
  • Configurations pour les services et connexions Azure
  • Approvisionnement d’infrastructure via Bicep et Terraform

Contrairement aux variables d’environnement traditionnelles qui existent au niveau du système d’exploitation, azd les variables d’environnement sont étendues à des environnements spécifiques au sein de votre projet, ce qui permet d’isoler les différentes cibles de déploiement.

Les variables d’environnement offrent plusieurs avantages clés lors de l’utilisation de azd.

  • Isolation de l’environnement : conservez les configurations pour le développement, les tests et la production distincts et distincts.
  • Cohérence de la configuration : assurez-vous que tous les membres de l’équipe utilisent les mêmes paramètres pour un environnement spécifique.
  • Infrastructure en tant que code : définissez le paramétrage de l’infrastructure via des variables au lieu de valeurs codées en dur.
  • Automatisation du déploiement : activez les pipelines CI/CD à déployer dans différents environnements à l’aide du même codebase, mais des configurations différentes.
  • Gestion simplifiée : mettez facilement à jour les paramètres de tous les services d’un environnement à partir d’un emplacement central.

Chaque azd environnement a son propre ensemble de variables, ce qui permet des configurations spécifiques à l’environnement tout en utilisant le même code d’application et les mêmes modèles d’infrastructure.

Variables d’environnement et fichiers .env

Les azd variables d’environnement sont stockées dans .env des fichiers dans les répertoires spécifiques à l’environnement de votre projet. Lorsque vous créez un environnement à l’aide azd env new <name>de , une structure de répertoires est créée :

.azure/
├── <environment-name>/
│   ├── .env                   # Environment variables for this environment

Le .env fichier utilise un format standard où chaque ligne représente une paire clé-valeur :

KEY1=value1
KEY2=value2

Conseil / Astuce

Pour plus d’informations sur les environnements, consultez l’article azd.

Lorsque vous exécutez des commandes telles que azd up, azd charge automatiquement des variables à partir du fichier de .env l’environnement sélectionné.

Ces variables influencent :

  • Approvisionnement d’infrastructure : variables telles AZURE_LOCATION que et AZURE_SUBSCRIPTION_ID déterminer où et comment les ressources sont créées.
  • Déploiement : les variables telles que les points de terminaison de service contrôlent la façon dont votre application se connecte aux services Azure.
  • Configuration de l’application : les variables peuvent être transmises à votre configuration d’application pour contrôler son comportement.
  • Nommage des ressources : des variables telles que AZURE_RESOURCE_GROUP influencent les modèles de nomenclature des ressources.

Le fichier .env est également mis à jour automatiquement par azd pendant les opérations telles que azd init, azd provision et azd deploy, capturant les sorties de vos modèles d'infrastructure et les stockant pour une utilisation ultérieure.

Définir des variables d’environnement

Vous pouvez utiliser différentes méthodes pour définir azd des variables d’environnement, en fonction du scénario.

Utiliser les commandes CLI

La méthode recommandée pour définir une variable d’environnement utilise la azd env set commande, qui inclut des vérifications pour garantir des valeurs valides :

azd env set <key> <value>

Par exemple, pour définir une valeur de configuration pour votre application :

azd env set API_TIMEOUT 5000

La commande ajoute ou met à jour la variable dans le .env fichier de l’environnement actuellement sélectionné. Vous pouvez également cibler un environnement spécifique à l’aide de l’indicateur --environment :

azd env set API_TIMEOUT 5000 --environment prod

Pour vérifier que votre variable d’environnement a été correctement définie :

azd env get-value API_TIMEOUT

Sortie de Bicep

Une fonctionnalité puissante de azd est sa capacité à capturer automatiquement les paramètres de sortie de vos modèles d'infrastructure Bicep en tant que variables d'environnement. Par exemple, lorsque vous définissez un paramètre de sortie dans votre main.bicep fichier :

output API_ENDPOINT string = apiService.outputs.SERVICE_ENDPOINT_URL

Une fois l’exécution terminée azd provision, cette sortie est automatiquement enregistrée dans le fichier de l’environnement .env :

API_ENDPOINT=https://api-dev-123456.azurewebsites.net

Cette approche garantit que votre application a toujours accès aux informations de ressources les plus actuelles, telles que :

  • Points de terminaison de service et URL
  • Noms et identificateurs de ressources

Obtenir et utiliser des variables d’environnement

Une fois défini, vous pouvez accéder aux variables d’environnement dans plusieurs contextes.

Commandes CLI

Pour afficher toutes les variables d’environnement de l’environnement actuel :

azd env get-values

Pour afficher la valeur d’une variable spécifique :

azd env get-value API_ENDPOINT

Pour la sortie lisible par l’ordinateur (utile dans les scripts) :

azd env get-values --output json

Utiliser des variables d’environnement dans des fichiers d’infrastructure

Vous pouvez utiliser des variables d’environnement pour personnaliser vos modèles d’infrastructure. Cela est utile pour nommer, marquer ou configurer des ressources en fonction de l’environnement actuel. azd utilise également des balises pour localiser des ressources dans Azure pour le déploiement et d’autres tâches.

Considérez le flux courant suivant :

  1. Pendant azd init, azd définit ces variables d’environnement en fonction de la réponse de l’utilisateur aux invites :

    AZURE_ENV_NAME=myapp-dev
    AZURE_LOCATION=eastus2
    
  2. Référencez ces variables dans main.parameters.json le infra dossier. azd remplace les valeurs pendant l’approvisionnement et transmet les paramètres résolus à Bicep :

    {
      "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
      "contentVersion": "1.0.0.0",
      "parameters": {
        "name": {
          "value": "${AZURE_ENV_NAME}"
        },
        "location": {
          "value": "${AZURE_LOCATION}"
        }
      }
    }
    
  3. Définissez les paramètres correspondants dans votre modèle Bicep :

    @description('Name of the environment used to derive resource names and tags.')
    param name string
    
    @minLength(1)
    @description('Primary Azure region for all resources.')
    param location string
    

    azd fournit ces paramètres Bicep avec les valeurs substituées dans main.parameters.json.

  4. Utilisez les paramètres d’affectation de noms et de balises de ressource pour identifier ultérieurement l’environnement auquel appartient une ressource :

    var resourceToken = toLower(uniqueString(resourceGroup().id, name, location))
    
    resource storageAccount 'Microsoft.Storage/storageAccounts@2022-09-01' = {
      name: 'st${resourceToken}'
      location: location
      sku: {
        name: 'Standard_LRS'
      }
      kind: 'StorageV2'
      tags: {
        Environment: name
        Project: 'myproject'
      }
    }
    

Ce modèle conserve vos modèles flexibles, active la personnalisation par environnement sans modification du code et améliore la gouvernance des ressources (nommage, balisage et découverte).

Note

azd s’appuie également sur l’étiquetage pour localiser les ressources Azure pendant la phase de déploiement.

Hooks

azd Les variables d’environnement sont automatiquement préchargées et disponibles dans les hooks et les scripts personnalisés définis dans votre azure.yaml fichier, vous pouvez accéder aux variables d’environnement à l’aide de la syntaxe suivante :

# Use the variables in your script
echo "API endpoint: $API_ENDPOINT"
echo "Deploying to: $AZURE_LOCATION"

Vous pouvez définir des hooks dans votre azure.yaml fichier pour exécuter ces scripts à des points spécifiques du cycle de azd vie :

hooks:
  postprovision:
    windows:
      shell: pwsh
      run: ./scripts/load-env-vars.ps1
      interactive: false
    posix:
      shell: sh
      run: ./scripts/load-env-vars.sh
      interactive: false

Conseil / Astuce

Pour plus d’informations sur l’utilisation de hooks, consultez l’article Personnaliser les flux de travail à l’aide de hooks .

Supprimer ou mettre à jour des variables

Pour supprimer une variable de votre environnement :

azd env unset VARIABLE_NAME

Pour mettre à jour une variable existante :

azd env set VARIABLE_NAME "new-value"

Pour actualiser vos variables d’environnement locales à partir de l’état actuel de vos ressources Azure :

azd env refresh

L’actualisation de votre environnement est utile lorsque :

  • Vous souhaitez vous assurer que votre fichier local .env reflète les dernières sorties de votre infrastructure (comme les chaînes de connexion, les points de terminaison, etc.).
  • Vous devez synchroniser les variables d’environnement après qu’un coéquipier a mis à jour l’environnement.

Variables d’environnement AZD et OS

azd les variables d’environnement et les variables d’environnement du système d’exploitation servent des objectifs différents et fonctionnent de différentes manières :

Concept Interface en ligne de commande Azure pour les développeurs Système d’exploitation
Emplacement Stocké dans des .azure/<env-name>/.env fichiers Définir dans l’environnement de votre système d’exploitation
Scope Délimité à un environnement nommé spécifique dans un projet Global à votre session ou système utilisateur
Gestion Géré à l’aide des commandes azd env Géré à l’aide de commandes spécifiques au système d’exploitation (export, setetc.)
Access Chargé automatiquement par les commandes azd Généralement chargé explicitement dans des scripts ou des applications
Target Lié aux ressources et déploiements Azure Configuration du système à usage général
Cycle de vie Persister entre les sessions de terminal Peut être temporaire ou persistant en fonction de la façon dont ils sont définis

azd ne lit pas automatiquement ou n’écrit pas de variables d’environnement de système d’exploitation. Toutefois, vous pouvez interagir avec les deux types de variables à l’aide de scripts personnalisés.

Lire les azd variables d’environnement et les variables d’environnement du système d’exploitation :

# Access OS environment variable
echo "OS variable: $PATH"

# Access azd environment variable
echo "AZD variable: $(azd env get-value MY_VARIABLE)"

Écrivez des azd variables d’environnement dans des variables d’environnement de système d’exploitation ou de framework :

# Load all azd environment variables into the current shell session
while IFS='=' read -r key value; do
    value=$(echo "$value" | sed 's/^"//' | sed 's/"$//')
    export "$key=$value"
done <<EOF
$(azd env get-values)
EOF

Variables d’environnement standard

azd définit et utilise plusieurs variables d’environnement courantes dans tous les environnements :

Variable Description Example Quand défini
AZURE_ENV_NAME Nom de l’environnement actuel dev Lors de la création de l’environnement
AZURE_LOCATION Région Azure où les ressources sont déployées eastus Lors du premier approvisionnement
AZURE_SUBSCRIPTION_ID ID de l’abonnement Azure utilisé 00000000-0000-0000-0000-000000000000 Lors du premier approvisionnement
AZURE_RESOURCE_GROUP Nom du groupe de ressources rg-myapp-dev Lors de l’approvisionnement
AZURE_PRINCIPAL_ID ID de l'utilisateur/principal du service en cours d'exécution 00000000-0000-0000-0000-000000000000 Lors de l’approvisionnement
AZURE_PRINCIPAL_TYPE Type d’un principal dans l’environnement. 1a2b3c Lors de l’approvisionnement
AZURE_TENANT_ID ID du locataire Azure utilisé. 00000000-0000-0000-0000-000000000000 Lors de l’approvisionnement

Considérations relatives aux secrets et aux données sensibles

Bien que les variables d’environnement soient pratiques pour la configuration, elles nécessitent une gestion spéciale pour les données sensibles :

Éviter de stocker des secrets dans des fichiers .env

.env Les fichiers sont généralement stockés en texte brut et peuvent facilement être :

  • Validé accidentellement dans la gestion du code source
  • Partagé ou copié sans protection appropriée
  • Consulté par toute personne ayant accès aux fichiers du projet
  • Inclus dans les journaux d’activité ou les rapports d’erreurs

Avertissement

Ne stockez jamais de secrets dans un fichier AZURE Developer CLI .env . Ces fichiers peuvent facilement être partagés ou copiés dans des emplacements non autorisés ou archivés dans le contrôle de code source. Utilisez des services tels qu’Azure Key Vault ou le contrôle d’accès en fonction du rôle Azure (RBAC) pour des solutions protégées ou sans secret.

Alternatives pour la gestion des secrets

Pour les données sensibles, tenez compte de ces approches plus sécurisées :

  • Références Azure Key Vault : Stockez les secrets dans Azure Key Vault et référencez-les dans votre .env fichier :

    azd env set-secret <secret-value>
    

    Cette commande crée un secret Key Vault et stocke une référence à celui-ci dans votre .env fichier plutôt que la valeur réelle.

  • Identités managées : configurez vos services Azure pour utiliser des identités managées au lieu de chaînes de connexion ou de clés d’accès.

  • Sécurité propre à l’environnement : appliquez des contrôles de sécurité plus stricts aux environnements de production qu’aux environnements de développement.

  • Secrets juste-à-temps : générez des informations d’identification de courte durée pendant le déploiement plutôt que de stocker des secrets persistants.

Étapes suivantes