Infrastructure des agents hébergés avec Azure Developer CLI

Lorsque vous exécutez azd ai agent init --infra ou azd ai agent init --infra=bicep, Azure Developer CLI (azd) extrait une infrastructure modifiable à partir de vos déclarations de service de Foundry. Sans infrastructure existante, le chemin d’accès par défaut est infra. Pour préserver l’infrastructure d’application existante, eject ajoute une couche Foundry sous infra/foundry. L’exécution de azd provision déploie l’infrastructure déclarée.

Ce qui est provisionné

Par défaut, azd ai agent init ne crée pas de fichiers infrastructure-as-code. Utilisez --infra ou --infra=bicep pour éjecter Bicep. Utilisez --infra=terraform pour éjecter Terraform et d’enregistrer le fournisseur de la couche. Si votre projet déclare déjà des services Foundry, appelez --infra seul ; ce chemin rejette les entrées d’initialisation non liées.

Les modèles éjectés proviennent du synthétiseur d’infrastructure de l’extension, et non d’un dépôt de démarrage distinct. Pour un nouveau projet, l’infrastructure générée crée le compte Foundry, le projet et les déploiements de modèles déclarés. Les ressources supplémentaires dépendent de la configuration du service :

Lorsque le projet déclare l’isolation réseau, les modèles/templates configurent également des sous-réseaux, un point de terminaison privé de compte et un DNS privé. Le mode de sortie sélectionne l’injection de réseau client ou un réseau géré par Microsoft.

Les modèles actuels ne déploient pas automatiquement Application Insights, un espace de travail Log Analytics, Recherche Azure AI, un compte de stockage ou une ressource de grounding Bing. Déclarez et gérez une infrastructure d’application supplémentaire séparément plutôt que de supposer qu’une référence d’outil la crée.

Structure du projet

infra/
|-- main.bicep
|-- main.parameters.json
|-- abbreviations.json
\-- modules/

Cet exemple montre la sortie Bicep par défaut sans infrastructure existante. Un projet avec l’infrastructure d’application existante reçoit une couche distincte infra/foundry ; les configurations en couches existantes conservent leurs chemins déclarés. Les modules exacts dépendent du fait que vous créez un projet ou que vous vous connectez à un projet existant. L’éjection de Terraform écrit des fichiers .tf au lieu de créer main.tfvars.json.

Flux des paramètres

L’élément généré main.parameters.json contient des liaisons de paramètres et des valeurs dérivées de azure.yaml. Par exemple, une couche Bicep utilise des liaisons d’environnement telles que :

{
  "parameters": {
    "location": { "value": "${AZURE_LOCATION}" },
    "foundryProjectName": { "value": "${AZURE_AI_PROJECT_NAME=${AZURE_ENV_NAME}}" },
    "resourceTokenSalt": { "value": "${AZD_RESOURCE_TOKEN_SALT}" }
  }
}

Lors de azd provision, azd résout ces références ${VAR} à partir de l’environnement (.azure/<env>/.env) et les transmet au processus de déploiement Bicep. Les sorties du déploiement, telles que le point de terminaison du projet Foundry et le point de terminaison du registre de conteneurs, sont enregistrées dans l’environnement pour être utilisées par azd deploy, azd ai agent run et les commandes de ressource azd ai.

Infrastructure Terraform

Pour un nouveau projet, azd ai agent init --infra=terraform génère des fichiers tels que les suivants :

infra/
|-- main.tf
|-- provider.tf
|-- variables.tf
|-- outputs.tf
|-- main.tfvars.json
\-- .azd-foundry

Les services basés sur des conteneurs peuvent également générer container-registry.tf. Les projets existants peuvent conserver leur infrastructure et recevoir une couche Foundry distincte sous infra/foundry/. Utilisez la disposition générée réelle plutôt que de déplacer des fichiers entre des couches.

La configuration Terraform provisionne le compte Foundry, le projet, les déploiements de modèles et les ressources associées requises par les services sélectionnés. La création du registre de conteneurs dépend du mode de déploiement et de la configuration de l’image.

main.tfvars.json lie les entrées d’infrastructure aux valeurs d’environnement azd. outputs.tf expose à azd des valeurs telles que le point de terminaison du projet Foundry après le provisionnement. Ces liaisons font partie du flux de travail azd ; ne supposez pas qu’un fichier de paramètres généré fonctionne sans modification avec un fichier autonome terraform apply.

Pour personnaliser l’infrastructure Terraform, modifiez les fichiers générés .tf , conservez les sorties requises par vos services d’agent et exécutez azd provision. Passez en revue le plan Terraform avant d’appliquer des modifications d’infrastructure.

État Terraform et CI/CD

Les fichiers générés ne démarrent pas un back-end d’état distant. Pour les déploiements d’équipe, configurez l’état stockage Azure soutenu, les clés d’état distinctes pour chaque environnement et les autorisations back-end requises avant de configurer CI/CD.

Consultez Configurer CI/CD avec Terraform pour le flux de déploiement et Utiliser Terraform avec azd pour la configuration back-end.

Limitations de l’éjection de Terraform

Le chemin d’éjection Terraform ne prend pas en charge la configuration du service network: dans l’extension actuelle des agents Foundry. Passez en revue les contraintes de ressources existantes avant d’éjecter un projet qui dispose déjà d’une infrastructure. Ejection n’est pas une migration générale de l’état de Bicep vers Terraform, et la suppression de ressources de production n’est pas un préalable pour adopter Terraform.

Ressources existantes

Pour réutiliser un compte et un projet Foundry existants, initialisez par rapport à l’ID de ressource du projet :

azd ai agent init --project-id "<foundry-project-resource-id>"

Lors de l’éjection d’un projet existant, les références au compte et au projet sont réutilisées plutôt que de créer des remplacements. Il peut ajouter des déploiements de modèles déclarés et créer ou réutiliser un registre de conteneurs. Pour un registre connecté existant, utilisez --acr-connection lors de l’initialisation. Consultez Déployer avec un registre de conteneurs privé.

Personnaliser l’infrastructure

Le infra/ répertoire est une infrastructure standard azd . Pour ajouter ou modifier des ressources Bicep :

1. Modifiez infra/main.bicep ou ajoutez de nouveaux modules sous infra/modules/. Pour l’infrastructure en couches, utilisez le chemin déclaré de la couche Foundry.
2. Ajoutez de nouveaux paramètres à main.parameters.json avec des liaisons ${VAR}.
3. Définissez les variables d’environnement correspondantes azd avec azd env set.
4. Exécutez azd provision pour appliquer les modifications.

Les modifications apportées aux fichiers Bicep persistent entre les déploiements.

Restrictions de région

Le actif généré main.bicep ne contient pas de liste de régions autorisées. Choisissez une région qui prend en charge les fonctionnalités et modèles d’agent hébergé requis. La modification d’un modèle n’active pas un service dans une région non prise en charge.

Contenu connexe

• référence azure.yaml pour les agents hébergés
• Déployer un agent hébergé
• Configurer des réseaux virtuels