Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Démarrage avec AWS DevOps Agent utilisant Terraform ## Vue d’ensemble Ce guide explique comment utiliser Terraform pour créer et déployer des ressources d' AWS DevOps agent. La configuration Terraform automatise la création d'un espace d'agent, de rôles IAM, d'une application opérateur et d'associations de comptes. AWS L'approche Terraform automatise les étapes manuelles décrites dans le guide d'intégration de la [ CLI en ](https://docs.aws.amazon.com/devopsagent/latest/userguide/getting-started-with-aws-devops-agent-cli-onboarding-guide.html) définissant toutes les ressources requises sous forme d'infrastructure en tant que code. AWS DevOps L'agent est disponible dans les 6 AWS régions suivantes : USA Est (Virginie du Nord), USA Ouest (Oregon), Asie-Pacifique (Sydney), Asie-Pacifique (Tokyo), Europe (Francfort) et Europe (Irlande). Pour plus d'informations sur les régions prises en charge, consultez[Régions prises en charge](about-aws-devops-agent-supported-regions.md). ## Conditions préalables Avant de commencer, assurez-vous de disposer des éléments suivants : + Terraform >= 1.0 installé + AWS CLI installée et configurée avec les informations d'identification appropriées + Un AWS compte pour le compte de surveillance (principal) + (Facultatif) Un deuxième AWS compte si vous souhaitez configurer la surveillance entre comptes + (Pour la partie 4), version 1.98.0 ou ultérieure du `awscc` fournisseur. Les `awscc_devopsagent_trigger` ressources `awscc_devopsagent_asset` et ont été ajoutées dans cette version. Pour vérifier la version dans votre configuration, exécutez`terraform providers`. ## Ce que couvre ce guide Ce guide est divisé en quatre parties : + **Partie 1 ** — Déployez un espace agent avec une application opérateur et une AWS association dans votre compte de surveillance. Une fois cette partie terminée, l'agent peut surveiller les problèmes liés à ce compte. + **Partie 2 (Facultatif) ** — Ajoutez une AWS association de source pour un compte de service et déployez un rôle IAM inter-comptes ainsi qu'un echo Lambda dans ce compte. Cela permet à l'espace agent de surveiller les ressources entre les comptes. + **Partie 3 (Facultative) ** — Enregistrez des services tiers (Dynatrace ServiceNow, Splunk, New Relic GitLab, PagerDuty) et associez-les à l'espace agent. + **Partie 4 (Facultatif) ** — Ajoutez une compétence, un agent personnalisé et un déclencheur programmé à l'espace agent, afin que l'agent dispose de connaissances personnalisées et que le déclencheur programmé exécute automatiquement cet agent personnalisé. ## Ressources créées ### Partie 1 : Compte de suivi + **Rôle IAM ** (`DevOpsAgentRole-AgentSpace-*`) : assumé par le service DevOps Agent pour surveiller le compte. Inclut la politique `AIDevOpsAgentAccessPolicy` gérée et une politique en ligne qui permet la création du rôle lié au service Resource Explorer. Créé uniquement lorsqu'il n'`existing_agentspace_role_arn`est pas défini. + **Rôle IAM ** (`DevOpsAgentRole-WebappAdmin-*`) : rôle de l'opérateur dans l'application avec la politique `AIDevOpsOperatorAppAccessPolicy` gérée pour les opérations des agents. Créé uniquement lorsqu'il n'`existing_operator_role_arn`est pas défini. + **Espace d'agent ** (nom configurable) : espace d'agent central, créé à l'aide de la `awscc_devopsagent_agent_space` ressource. Comprend la configuration de l'application pour l'opérateur. + **Association ** (AWS moniteur) : associe le compte de surveillance à l'espace agent à l'aide de la `awscc_devopsagent_association` ressource. + **Association ** (AWS source) — (Facultatif) Associe le compte de service à l'espace agent pour une surveillance intercomptes. ### Partie 2 : Compte de service (facultatif) + **Rôle IAM ** (`DevOpsAgentRole-SecondaryAccount-TF`) : Cross-account rôle avec un nom fixe. Approuvé par l'espace agent dans le compte de surveillance. Inclut la politique `AIDevOpsAgentAccessPolicy` gérée et une politique en ligne qui permet la création du rôle lié au service Resource Explorer. + **Fonction Lambda ** (`echo-service-tf`) : exemple de service simple qui renvoie les événements d'entrée. ### Partie 4 : Actifs et déclencheurs (facultatif) Cette configuration crée les ressources suivantes : + **Compétence ** (`rds-performance-investigation`) : compétence que l'agent charge le cas échéant, créée à l'aide de la `awscc_devopsagent_asset` ressource avec un `asset_type` de`skill`. + **Agent personnalisé ** (`rds-firefighter`) : attribue à l'agent un flux de travail spécifique avec des compétences associées, créé à l'aide de la `awscc_devopsagent_asset` ressource avec un `asset_type` de`custom_agent`. + **Trigger ** (`TIME_BASED`) : exécute l'agent personnalisé selon un calendrier, créé à l'aide de la `awscc_devopsagent_trigger` ressource. ## Configuration ### Étape 1 : cloner le référentiel d'échantillons ``` git clone https://github.com/aws-samples/sample-aws-devops-agent-terraform.git cd sample-aws-devops-agent-terraform ``` ### Étape 2 : Configuration des variables Copiez le fichier de variables d'exemple et personnalisez-le en fonction de votre environnement : ``` cp terraform.tfvars.example terraform.tfvars ``` Modifiez `terraform.tfvars` avec le nom et la description de votre espace agent : ``` agent_space_name = "MyCompanyAgentSpace" agent_space_description = "DevOps Agent Space for monitoring production workloads" ``` ## Partie 1 : Déploiement de l'espace agent Dans cette section, vous créez l'espace agent, les rôles IAM, l'application opérateur et une AWS association dans votre compte de surveillance. ### Étape 1 : Déploiement automatisé (recommandé) Utilisez le script de déploiement fourni pour une configuration simplifiée : ``` ./deploy.sh ``` Ce script permet automatiquement : + Vérifie les prérequis (Terraform, AWS CLI, informations d'identification) + Crée `terraform.tfvars` à partir d'un exemple si nécessaire + Initialise, valide, planifie et applique Terraform Sinon, si vous préférez le contrôle manuel : ``` terraform init terraform plan terraform apply ``` Tapez `yes` lorsque vous êtes invité à confirmer le déploiement. ### Étape 2 : Enregistrez les sorties Une fois le déploiement terminé, Terraform imprime les sorties. Enregistrez ces valeurs pour une utilisation ultérieure : ``` Outputs: agent_space_id = "abc123" agent_space_arn = "arn:aws:aidevops:::agentspace/abc123" agent_space_name = "MyCompanyAgentSpace" devops_agentspace_role_arn = "arn:aws:iam:::role/DevOpsAgentRole-AgentSpace-a1b2c3d4" devops_operator_role_arn = "arn:aws:iam:::role/DevOpsAgentRole-WebappAdmin-a1b2c3d4" primary_account_id = "" primary_account_association_id = "assoc-xyz" ``` Si vous prévoyez de terminer la partie 2, enregistrez la `agent_space_arn` valeur. Vous en aurez besoin pour configurer les ressources du compte de service. ### Étape 3 : vérifier le déploiement Exécutez le script de vérification après déploiement : ``` ./post-deploy.sh ``` Ou utilisez l' AWS interface de ligne de commande pour vérifier que l'espace agent a été créé correctement : ``` aws devops-agent get-agent-space \ --agent-space-id \ --region ``` À ce stade, votre espace agent est déployé avec l'application opérateur activée et votre compte de surveillance associé. L'agent peut surveiller les problèmes liés à ce compte. ## Partie 2 (Facultatif) : Ajouter une surveillance multi-comptes Dans cette section, vous allez étendre la configuration afin que l'espace agent puisse surveiller les ressources d'un second AWS compte (le compte de service). Cela implique deux actions : 1. Ajout d'une AWS association source qui pointe vers le compte de service. 1. Déploiement d'un rôle IAM inter-comptes et d'une fonction echo Lambda dans le compte de service. **Important** **Vous devez terminer la partie 1 avant de continuer. Les ressources du compte de service nécessitent la sortie `agent_space_arn` de déploiement de la partie 1. ### Étape 1 : configurer l'ID du compte de service Dans`terraform.tfvars`, définissez l'identifiant de votre compte de service : ``` service_account_id = "" ``` ### Étape 2 : définir l'ARN de l'espace agent Copiez la `agent_space_arn` valeur de la sortie de la partie 1 (étape 2) et définissez-la dans `terraform.tfvars` : ``` agent_space_arn = "arn:aws:aidevops:::agentspace/" ``` Les ressources du compte de service utilisent cette valeur pour définir la politique de confiance sur le rôle du compte secondaire. Ces ressources ne sont créées que lorsque cette valeur est définie. ### Étape 3 : configurer le fournisseur `aws.service` Dans`main.tf`, configurez l'alias du `aws.service` fournisseur avec les informations d'identification du compte de service. Vous pouvez utiliser un profil nommé ou un rôle d'acteur : À l'aide d'un profil : ``` provider "aws" { alias = "service" region = var.aws_region profile = "your-service-account-profile" } ``` Ou en utilisant Assume Role : ``` provider "aws" { alias = "service" region = var.aws_region assume_role { role_arn = "arn:aws:iam:::role/OrganizationAccountAccessRole" } } ``` ### Étape 4 : Déploiement Appliquez la configuration mise à jour : ``` terraform apply ``` Cela crée les ressources suivantes dans le compte de service : + Un rôle IAM (`DevOpsAgentRole-SecondaryAccount-TF`) qui fait confiance à l'espace agent dans le compte de surveillance + Une fonction echo Lambda (`echo-service-tf`) comme exemple de service Il crée également une AWS association de source dans le compte de surveillance qui relie le compte de service. ### Étape 5 : vérifier le déploiement Testez le service Echo pour confirmer que la fonction Lambda a été correctement déployée : ``` aws lambda invoke \ --function-name echo-service-tf \ --payload '{"test": "hello world"}' \ --profile \ --region \ response.json cat response.json ``` ## Partie 3 (Facultative) : Enregistrer les intégrations tierces Dans cette section, vous enregistrez des services externes (Dynatrace, Splunk ServiceNow, New Relic GitLab, PagerDuty) auprès de l'espace agent. Ces intégrations permettent à AWS DevOps l'Agent d'accéder à la télémétrie, aux données d'incidents et aux informations de contrôle des sources pendant les enquêtes. Contrairement à l'exemple AWS CDK, qui nécessite une IntegrationsStack phase distincte et un câblage manuel de l'identifiant de l'espace agent, ces ressources font directement référence à l'espace agent et peuvent être déployées de la même manière `terraform apply` que dans la partie 1. ### Intégrations prises en charge | Service | Type de service | Authentification | | --- | --- | --- | | Dynatrace | dynatrace | Informations d’identification client OAuth | | ServiceNow | servicenow | Informations d’identification client OAuth | | Splunk | mcpserversplunk | Jeton au porteur | | New Relic | mcpservernewrelic | Clé API | | GitLab | gitlab | Jeton d’accès | | PagerDuty | pagerduty | Informations d’identification client OAuth | **Note** **Datadog n'est pas inclus dans la configuration de Terraform. La connexion à Datadog nécessite une autorisation OAuth interactive de l'utilisateur (connexion au navigateur et consentement), comme décrit dans[Connecter DataDog](connecting-telemetry-sources-connecting-datadog.md), que Terraform ne peut pas automatiser. Enregistrez Datadog manuellement via la page Capability Providers de la console. ### Étape 1 : configurer les informations d'identification d'intégration Ajoutez un `integrations` bloc à`terraform.tfvars`, en renseignant uniquement les services que vous souhaitez. L'exemple suivant illustre une intégration Dynatrace : ``` integrations = { dynatrace = { account_urn = "" client_id = "" client_name = "" client_secret = "" env_id = "" resources = [""] } } ``` Pour la forme complète de chaque intégration, consultez `terraform.tfvars.example` le référentiel d'exemples. **ServiceNow exigence : définissez ** toujours `instance_id` explicitement le nom court de l'instance (par exemple, `"ven04972"` — pas le nom complet`instance_url`). Si elle `instance_id` est omise, l'association revient à`instance_url`, ce que l'API de l' DevOps agent rejette avec un`400 GeneralServiceException: instanceId '' does not match the registered ServiceNow instance`. **Sécurité : ** la `integrations` variable est marquée`sensitive`, de sorte que ses valeurs sont supprimées du plan et appliquées à la sortie. Ne confiez pas de véritables informations d'identification à`terraform.tfvars`. Pour la production, utilisez les AWS secrets de source à partir de Secrets Manager ou de AWS Systems Manager Parameter Store (par exemple, à l'aide de `data` sources) plutôt que du texte en clair. ### Étape 2 : Déploiement Appliquez la configuration : ``` terraform apply ``` Cela crée un enregistrement et une association de services pour chaque intégration activée. ### Étape 3 : Passez en revue les résultats Une fois le déploiement terminé, les sorties d'intégration mappent chaque service activé à ses identifiants enregistrés : ``` integration_service_ids = { "dynatrace" = "service-abc123" } integration_association_ids = { "dynatrace" = "assoc-xyz789" } ``` **Remarque : ** Terraform ne renvoie pas l'URL et le secret du webhook en sortie, car le secret est sensible. Une fois `terraform apply` terminé, faites pivoter le webhook dans la console pour obtenir l'URL et le secret. Pour obtenir des instructions sur la gestion des informations d'identification du webhook, consultez la section [ Gestion des informations d'identification du webhook. ](configuring-integrations-and-knowledge-invoking-devops-agent-through-webhook.md) Pour plus d'informations sur la configuration des informations d'identification pour chaque service, consultez : + [Connecter Dynatrace](connecting-telemetry-sources-connecting-dynatrace.md) + [Connecter ServiceNow](connecting-to-ticketing-and-chat-connecting-servicenow.md) + [Connecter Splunk](connecting-telemetry-sources-connecting-splunk.md) + [Connecter New Relic](connecting-telemetry-sources-connecting-new-relic.md) + [Connecter GitLab](connecting-to-cicd-pipelines-connecting-gitlab.md) + [Connecter PagerDuty](connecting-to-ticketing-and-chat-connecting-pagerduty.md) ## Partie 4 (Facultatif) : Ajouter une compétence, un agent personnalisé et un déclencheur programmé Dans cette section, vous ajoutez trois ressources à l'espace agent que vous avez créé dans la partie 1. Vous ajoutez une ** compétence que ** l'agent charge le cas échéant et un agent ** personnalisé ** qui définit l'agent pour un flux de travail spécifique. Vous ajoutez également un déclencheur ** programmé ** qui exécute automatiquement l'agent personnalisé. Ces ressources utilisent les `awscc_devopsagent_trigger` ressources `awscc_devopsagent_asset` et. Ces ressources peuvent entraîner des frais supplémentaires sur votre AWS compte. Pour les supprimer lorsque vous avez terminé, suivez la section Nettoyage à la fin de ce guide. Cet exemple utilise les types `custom_agent` d'actifs `skill` et. La même `awscc_devopsagent_asset` ressource crée tous les types d'actifs, tels que `memory_store``agents_md`, et. `attachment` Pour utiliser un autre type, modifiez l'`asset_type`argument et fournissez les métadonnées requises par ce type. Pour obtenir la liste complète des types de ressources, leurs métadonnées requises et la référence de propriété, consultez[Gestion des ressources](about-aws-devops-agent-managing-assets.md). **Important** **Vous devez terminer la partie 1 avant de continuer. Ces ressources nécessitent l'identifiant de l'espace agent issu du déploiement de la partie 1. ### Étape 1 : ajouter la configuration Créez un fichier nommé `assets.tf` avec les contenus suivants. L'action d'un déclencheur basé sur le temps fait référence à l'agent personnalisé par ID d'actif, dans le formulaire`custom:`. La configuration le connecte automatiquement à l'`asset_id`attribut de l'agent personnalisé. La `skills` liste de l'agent personnalisé prend également des identifiants d'actifs plutôt que des noms, elle fait donc référence à l'`asset_id`attribut de la compétence. Cela confère également à Terraform une dépendance implicite, de sorte que la compétence est créée avant l'agent qui l'attache. Notez que les `action` arguments `metadata` et sont des documents JSON transmis sous forme de chaînes, donc cet exemple les utilise`jsonencode`. ``` variable "agent_space_id" { type = string description = "The agent space ID from the Part 1 output" } # A skill the agent loads when relevant resource "awscc_devopsagent_asset" "example_skill" { agent_space_id = var.agent_space_id asset_type = "skill" metadata = jsonencode({ name = "rds-performance-investigation" description = "Investigation procedures for RDS performance issues." agent_types = ["GENERIC"] }) files = [{ path = "SKILL.md" content_text = <<-EOT # RDS Performance Investigation Use this skill when investigating database latency, connection errors, or query timeouts. EOT }] } # A custom agent with attached skills that a trigger can invoke resource "awscc_devopsagent_asset" "example_custom_agent" { agent_space_id = var.agent_space_id asset_type = "custom_agent" metadata = jsonencode({ name = "rds-firefighter" skills = [awscc_devopsagent_asset.example_skill.asset_id] }) files = [{ path = "AGENT.md" content_text = <<-EOT # RDS Firefighter Custom agent for RDS incidents. EOT }] } # A time-based trigger that runs the custom agent on a schedule resource "awscc_devopsagent_trigger" "daily" { agent_space_id = var.agent_space_id type = "TIME_BASED" condition = { schedule = { expression = "rate(1 day)" } } action = jsonencode({ actionType = "create:task" task = { agent = "custom:${awscc_devopsagent_asset.example_custom_agent.asset_id}" } }) status = "Active" } output "skill_asset_id" { description = "The skill asset ID" value = awscc_devopsagent_asset.example_skill.asset_id } output "custom_agent_asset_id" { description = "The custom agent asset ID" value = awscc_devopsagent_asset.example_custom_agent.asset_id } output "trigger_id" { description = "The trigger ID" value = awscc_devopsagent_trigger.daily.trigger_id } ``` Si vous l'ajoutez au référentiel d'exemples, vous pouvez référencer directement la ressource d'espace agent au lieu de déclarer la `agent_space_id` variable. ### Étape 2 : Déploiement Définissez l'ID de l'espace de l'agent en `terraform.tfvars` utilisant la `agent_space_id` valeur de la sortie de la partie 1 : ``` agent_space_id = "" ``` Appliquez la configuration : ``` terraform apply ``` Les `asset_type` arguments `agent_space_id` et d'un actif sont uniquement créés, tout comme les `action` arguments`agent_space_id`, `type``condition`, et d'un déclencheur. La modification de l'un d'entre eux remplace la ressource. Vous pouvez mettre à jour le déclencheur `status` (`Active`ou`Inactive`) en place, en le configurant `Inactive` pour le suspendre sans le supprimer. ### Étape 3 : vérifier le déploiement Pour confirmer que les actifs et le déclencheur ont été créés, exécutez les commandes AWS CLI suivantes : ``` aws devops-agent list-assets \ --agent-space-id \ --region aws devops-agent list-triggers \ --agent-space-id \ --region ``` ## Utilisation des rôles IAM existants (facultatif) Par défaut, la configuration Terraform crée de nouveaux rôles IAM pour l'espace agent et l'application opérateur. Si vous possédez déjà des rôles IAM dotés des politiques requises, vous pouvez ignorer la création de rôles et fournir les ARN des rôles existants à la place. ### Exigences Les rôles existants doivent répondre aux exigences suivantes : #### Rôle de l'espace agent + La politique de confiance `aidevops.amazonaws.com` permet d'assumer le rôle avec `sts:AssumeRole` + La politique `AIDevOpsAgentAccessPolicy` gérée est-elle associée + (Facultatif) Dispose d'une politique en ligne qui permet la création du rôle lié au service Resource Explorer #### Rôle de l'opérateur dans l'application + La politique de confiance `aidevops.amazonaws.com` permet d'assumer le rôle avec `sts:AssumeRole` et `sts:TagSession` + La politique `AIDevOpsOperatorAppAccessPolicy` gérée est-elle associée ### Configuration Dans`terraform.tfvars`, définissez un ou les deux ARN de rôle : ``` existing_agentspace_role_arn = "arn:aws:iam::ACCOUNT_ID:role/YourAgentSpaceRole" existing_operator_role_arn = "arn:aws:iam::ACCOUNT_ID:role/YourOperatorRole" ``` Lorsque ces valeurs sont définies, les ressources de rôle correspondantes `iam.tf` sont ignorées. Cette approche est totalement rétrocompatible : les configurations existantes avec des valeurs vides (par défaut) préservent le comportement actuel de création de rôle. ## Résolution des problèmes **Délais de propagation IAM ** + La configuration inclut un délai de 30 secondes `time_sleep` entre la création du rôle IAM et la création de l'espace d'agent. Le service DevOps Agent valide la politique de confiance du rôle d'opérateur lors de la création de l'espace d'agent, et cela peut échouer si IAM ne s'est pas complètement propagé. Si des erreurs de politique de confiance persistent, attendez une minute et lancez `terraform apply` à nouveau. Les rôles IAM existent déjà et l'application reprendra là où elle s'était arrêtée. **ServiceNow `instanceId does not match`erreur ** + Définissez `instance_id` explicitement dans le bloc `service_now` d'intégration le nom court de l'instance (par exemple,`"ven04972"`), et non le nom complet`instance_url`. Voir la note de la partie 3 ci-dessus. **Association Dynatrace `status: invalid` ** + En cas de `terraform apply` succès mais que les rapports d'association qui en résultent `status = "invalid"` (visibles depuis `aws devops-agent get-association` ou depuis la console) indiquent que Dynatrace a rejeté les informations d'identification du client OAuth. Double-check `client_id``client_secret`, et `account_urn` contre le compte Dynatrace, plutôt que pour un problème de configuration Terraform. **Erreurs d'autorisation ** + Vérifiez que vos AWS informations d'identification disposent des autorisations IAM nécessaires pour créer des rôles et des politiques. + Vérifiez que les conditions de la politique de confiance correspondent à votre identifiant de compte. **Cross-account le déploiement échoue ** + Le `aws.service` fournisseur doit être configuré avec des informations d'identification pour le compte de service. Utilisez un profil nommé ou un bloc de rôle assumé. + Vérifiez que la `agent_space_arn` valeur correspond à l'ARN de la sortie de la partie 1. **Type de ressource Terraform introuvable ** + Vérifiez que vous disposez de la version du `awscc` fournisseur `~> 1.0` ou d'une version ultérieure. Les `awscc_devopsagent_association` ressources `awscc_devopsagent_agent_space` et nécessitent le fournisseur AWS Cloud Control. + Les `awscc_devopsagent_trigger` ressources `awscc_devopsagent_asset` et utilisées dans la partie 4 nécessitent la version 1.98.0 ou ultérieure du `awscc` fournisseur. Exécutez `terraform providers` pour vérifier votre version, puis exécutez `terraform init -upgrade` après avoir augmenté la contrainte de version. ## Nettoyage Si vous avez terminé la partie 4, supprimez d'abord la compétence, l'agent personnalisé et le déclencheur. Contrairement au guide AWS CDK, qui place ces ressources dans une pile distincte, `assets.tf` fait partie de la même configuration Terraform, donc un simple `terraform destroy` supprime l'espace d'agent avec elles. Supprimez `assets.tf` et appliquez la modification pour supprimer uniquement les ressources de la partie 4 : ``` rm assets.tf terraform apply ``` Pour conserver le fichier, ciblez plutôt les trois ressources : ``` terraform destroy \ -target=awscc_devopsagent_trigger.daily \ -target=awscc_devopsagent_asset.example_custom_agent \ -target=awscc_devopsagent_asset.example_skill ``` La suppression de ces seules ressources permet de conserver l'espace d'agent intact. Faites-le si vous avez appliqué la partie 4 à un espace d'agent que vous partagez avec d'autres personnes ou que vous n'avez pas créé dans la partie 1. Pour supprimer ensuite tout le reste, détruisez dans l'ordre inverse si vous avez déployé la partie 2 : ``` ./cleanup.sh ``` Ou manuellement : ``` terraform destroy ``` **Avertissement : ** Cela supprime définitivement votre espace agent et toutes les données associées. Assurez-vous d'avoir sauvegardé toutes les informations importantes avant de continuer. ## Considérations sur la sécurité + La configuration Terraform crée des rôles IAM avec des politiques de confiance qui permettent uniquement au principal du `aidevops.amazonaws.com` service de les assumer. + Les politiques de confiance incluent des conditions qui limitent l'accès à votre AWS compte spécifique et à l'ARN de votre espace d'agent. + Toutes les politiques suivent le principe du moindre privilège. Passez en revue et personnalisez les politiques IAM en fonction des exigences de sécurité de votre organisation. + Le rôle inter-comptes (`DevOpsAgentRole-SecondaryAccount-TF`) utilise un nom fixe et est limité à un ARN d'espace d'agent spécifique. ## Étapes suivantes Après avoir déployé votre AWS DevOps agent à l'aide de Terraform : 1. Découvrez la gamme complète des fonctionnalités de l' DevOps agent dans le guide de l'utilisateur de l'[AWS DevOps agent](https://docs.aws.amazon.com/devopsagent/latest/userguide/). 1. Envisagez d'intégrer le déploiement de Terraform dans vos CI/CD pipelines pour une gestion automatisée de l'infrastructure. ## Ressources supplémentaires + [AWS DevOps Guide de l'utilisateur de l'agent ](https://docs.aws.amazon.com/devopsagent/latest/userguide/) + [Exemple de référentiel Terraform ](https://github.com/aws-samples/sample-aws-devops-agent-terraform) + [Guide d'intégration à la CLI ](https://docs.aws.amazon.com/devopsagent/latest/userguide/getting-started-with-aws-devops-agent-cli-onboarding-guide.html) + [Ressource awscc\_devopsagent\_agent\_space ](https://registry.terraform.io/providers/hashicorp/awscc/latest/docs/resources/devopsagent_agent_space) dans le registre Terraform * * + [Ressource awscc\_devopsagent\_association ](https://registry.terraform.io/providers/hashicorp/awscc/latest/docs/resources/devopsagent_association) dans le registre Terraform * * + [Ressource awscc\_devopsagent\_private\_connection ](https://registry.terraform.io/providers/hashicorp/awscc/latest/docs/resources/devopsagent_private_connection) dans le registre Terraform * * + [Ressource awscc\_devopsagent\_asset ](https://registry.terraform.io/providers/hashicorp/awscc/latest/docs/resources/devopsagent_asset) dans le registre Terraform * * + [Ressource awscc\_devopsagent\_trigger ](https://registry.terraform.io/providers/hashicorp/awscc/latest/docs/resources/devopsagent_trigger) dans le registre Terraform * * + [Gestion des ressources](about-aws-devops-agent-managing-assets.md)