Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
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
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_LOCATIONque etAZURE_SUBSCRIPTION_IDdé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_GROUPinfluencent 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 :
Pendant
azd init,azddéfinit ces variables d’environnement en fonction de la réponse de l’utilisateur aux invites :AZURE_ENV_NAME=myapp-dev AZURE_LOCATION=eastus2Référencez ces variables dans
main.parameters.jsonleinfradossier.azdremplace 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}" } } }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 stringazdfournit ces paramètres Bicep avec les valeurs substituées dansmain.parameters.json.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
.envreflè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
.envfichier :azd env set-secret <secret-value>Cette commande crée un secret Key Vault et stocke une référence à celui-ci dans votre
.envfichier 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.