Gérer une IaC avec Terraform, Jenkins et GitOps

Ce tutoriel explique comment gérer une Infrastructure as Code (IaC) avec Terraform et Jenkins à l'aide de la méthodologie bien connue GitOps. Ce tutoriel s'adresse aux développeurs et aux opérateurs qui recherchent des bonnes pratiques pour gérer l'infrastructure de la même manière que les applications logicielles. Dans cet article, nous partons du principe que vous connaissez Terraform, Jenkins, GitHub, Google Kubernetes Engine (GKE) et Google Cloud.

Architecture

L'architecture utilisée dans ce tutoriel utilise des branches GitHub dev et prod pour représenter les environnements de développement et de production réels. Ces environnements sont définis par des réseaux de cloud privé virtuel (VPC) (dev et prod) dans un projet Google Cloud.

Proposition d'infrastructure

Comme le montre le schéma d'architecture suivant, le processus commence lorsqu'un développeur ou un opérateur soumet une proposition d'infrastructure à une branche non protégée GitHub, généralement une branche de fonctionnalité. Le cas échéant, cette branche de fonctionnalité peut être promue dans l'environnement de développement via une demande d'extraction vers la branche dev. Jenkins déclenche automatiquement une tâche pour exécuter le pipeline de validation. Cette tâche exécute la commande terraform plan et renvoie le résultat de validation à GitHub en incluant un lien vers un rapport détaillé sur les modifications de l'infrastructure. Cette étape est essentielle, car elle vous permet d'examiner les modifications potentielles avec les collaborateurs et d'ajouter des commits de suivi avant que les modifications ne soient fusionnées dans la branche dev.

Architecture montrant les pratiques GitOps pour la gestion des exécutions de Terraform

Déploiement Dev

Si le processus de validation réussit et que vous approuvez les modifications d'infrastructure proposées, vous pouvez fusionner la demande d'extraction dans la branche dev. Le schéma suivant illustre ce processus.

Fusion de la demande d'extraction dans la branche

Une fois la fusion terminée, Jenkins déclenche une autre tâche pour exécuter le pipeline de déploiement. Dans ce scénario, la tâche applique les fichiers manifestes Terraform dans l'environnement de développement pour obtenir l'état souhaité. Cette étape est importante, car elle vous permet de tester le code Terraform avant de le promouvoir en production.

Déploiement Prod

Une fois que vous avez testé l'infrastructure et que vous êtes prêt à promouvoir les modifications en production, vous devez fusionner la branche dev dans la branche prod pour déclencher l'installation de l'infrastructure dans l'environnement de production. Le schéma suivant illustre ce processus.

Fusion de la branche

Le même processus de validation s'exécute lorsque vous créez la demande d'extraction. Ce processus permet à votre équipe chargée des opérations d'examiner et d'approuver les modifications proposées en production.

Objectifs

  • Configurer votre dépôt GitHub
  • Créer un stockage d'état distant Terraform
  • Créer un cluster GKE et installer Jenkins
  • Modifier la configuration de votre environnement dans une branche de fonctionnalité
  • Faites la promotion des modifications dans l'environnement de développement.
  • Faites la promotion des modifications dans l'environnement de production.

Coûts

Ce tutoriel utilise les composants facturables suivants de Google Cloud :

Obtenez une estimation des coûts en fonction de votre utilisation prévue à l'aide du simulateur de coût. Les nouveaux utilisateurs de Google Cloud peuvent bénéficier d'un essai gratuit.

Une fois que vous avez terminé ce tutoriel, vous pouvez éviter de continuer à payer des frais en supprimant les ressources que vous avez créées. Consultez la page Effectuer un nettoyage pour en savoir plus.

Avant de commencer

  1. Connectez-vous à votre compte Google.

    Si vous n'en possédez pas déjà un, vous devez en créer un.

  2. Dans Cloud Console, sur la page de sélection du projet, sélectionnez ou créez un projet Cloud.

    Accéder à la page de sélection du projet

  3. Vérifiez que la facturation est activée pour votre projet Google Cloud. Découvrez comment vérifier que la facturation est activée pour votre projet.

  4. Dans Cloud Console, activez Cloud Shell.

    Activer Cloud Shell

    En bas de la fenêtre de Cloud Console, une session Cloud Shell démarre et affiche une invite de ligne de commande. Cloud Shell est un environnement shell dans lequel le SDK Cloud est déjà installé (y compris l'outil de ligne de commande gcloud), et dans lequel des valeurs sont déjà définies pour votre projet actuel. L'initialisation de la session peut prendre quelques secondes.

  5. Dans Cloud Shell, configurez votre ID de projet, et définissez votre nom d'utilisateur et votre adresse e-mail GitHub :
    PROJECT_ID=PROJECT_ID
    GITHUB_USER=YOUR_GITHUB_USER
    GITHUB_EMAIL=YOUR_EMAIL_ADDRESS
    gcloud config set project $PROJECT_ID
    

    Si vous n'avez pas encore accédé à GitHub depuis Cloud Shell, vous pouvez le configurer avec votre nom d'utilisateur et votre adresse e-mail :

    git config --global user.email "$GITHUB_EMAIL"
    git config --global user.name "$GITHUB_USER"
    

    GitHub utilise ces informations pour vous identifier en tant qu'auteur des commits que vous créez dans Cloud Shell.

Configurer votre dépôt GitHub

Dans ce tutoriel, vous utilisez un seul dépôt GitHub pour définir votre infrastructure cloud. Vous orchestrez cette infrastructure grâce à différentes branches correspondant à différents environnements :

  • La branche dev contient les dernières modifications appliquées à l'environnement de développement.
  • La branche prod contient les dernières modifications appliquées à l'environnement de production.

Grâce à cette infrastructure, vous pouvez toujours faire référence au dépôt pour savoir quelle configuration est attendue dans chaque environnement et pour proposer de nouvelles modifications en les fusionnant d'abord dans l'environnement dev. Vous faites ensuite la promotion des modifications en fusionnant la branche dev dans la branche prod.

Pour commencer, vous devez dupliquer le dépôt solutions-terraform-jenkins-gitops.

  1. Dans GitHub, accédez au dépôt solutions-terraform-jenkins-gitops.
  2. Cliquez sur Fork (Dupliquer).

    Dupliquer un dépôt dans GitHub

    Vous disposez maintenant d'une copie du dépôt solutions-terraform-jenkins-gitops avec les fichiers sources.

  3. Dans Cloud Shell, clonez ce dépôt dupliqué :

    cd ~
    git clone https://github.com/$GITHUB_USER/solutions-terraform-jenkins-gitops.git
    cd ~/solutions-terraform-jenkins-gitops
    

    Le code dans ce dépôt est structuré comme suit :

    • Dossier example-pipelines/ : contient des sous-dossiers avec l'exemple de pipeline utilisé dans ce tutoriel.
    • example-create/ : contient le code Terraform pour créer une machine virtuelle dans votre environnement.
    • environments/ : contient les dossiers d'environnement dev et prod avec des configurations du backend et des liens vers des fichiers du dossier example-create/.
    • Dossier jenkins-gke/ : contient les scripts requis pour déployer Jenkins dans un nouveau cluster GKE.
    • tf-gke/ : contient le code Terraform pour le déploiement sur GKE, et l'installation de Jenkins et de ses ressources dépendantes.

Créer un stockage d'état distant Terraform

L'état Terraform est stocké localement par défaut. Toutefois, nous vous recommandons de stocker l'état dans un espace de stockage central distant auquel vous pouvez accéder depuis n'importe quel système. Cette approche vous permet d'éviter de créer plusieurs copies sur différents systèmes, ce qui peut entraîner une non-concordance de la configuration et des états de l'infrastructure.

Dans cette section, vous allez configurer un bucket Cloud Storage qui stocke l'état distant de Terraform.

  1. Dans Cloud Shell, créez un bucket Cloud Storage.

    gsutil mb gs://${PROJECT_ID}-tfstate
    
  2. Activez la gestion des versions des objets pour conserver l'historique des états :

    gsutil versioning set on gs://${PROJECT_ID}-tfstate
    
  3. Remplacez l'espace réservé PROJECT_ID par votre ID de projet dans les fichiers terraform.tfvars et backend.tf :

    sed -i.bak "s/PROJECT_ID/${PROJECT_ID}/g" ./example-pipelines/environments/*/terraform.tfvars
    sed -i.bak "s/PROJECT_ID/${PROJECT_ID}/g" ./example-pipelines/environments/*/backend.tf
    
    sed -i.bak "s/PROJECT_ID/${PROJECT_ID}/g" ./jenkins-gke/tf-gke/terraform.tfvars
    sed -i.bak "s/PROJECT_ID/${PROJECT_ID}/g" ./jenkins-gke/tf-gke/backend.tf
    
  4. Vérifiez que tous les fichiers ont bien été mis à jour :

    git status
    

    La sortie ressemble à ceci :

    On branch dev
    Your branch is up-to-date with 'origin/dev'.
    Changes not staged for commit:
      (use "git add <file>..." to update what will be committed)
      (use "git checkout -- <file>..." to discard changes in working directory)
    
            modified:   example-pipelines/environments/dev/backend.tf
            modified:   example-pipelines/environments/dev/terraform.tfvars
            modified:   example-pipelines/environments/prod/backend.tf
            modified:   example-pipelines/environments/prod/terraform.tfvars
            modified:   jenkins-gke/tf-gke/backend.tf
            modified:   jenkins-gke/tf-gke/terraform.tfvars
    
  5. Procédez au commit et au transfert de vos modifications :

    git add --all
    git commit -m "Update project IDs and buckets"
    git push origin dev
    

Selon votre configuration GitHub, vous devrez peut-être vous authentifier afin de transférer les modifications précédentes.

Créer un cluster GKE et installer Jenkins

Dans cette section, vous utilisez Terraform et Helm pour configurer votre environnement afin de gérer une IaC (Infrastructure as Code). Tout d'abord, utilisez Terraform et le kit Cloud Foundations pour configurer un cloud privé virtuel, un cluster GKE et une ressource Workload Identity. Vous utilisez ensuite helm pour installer Jenkins sur cet environnement.

Avant de commencer à exécuter les commandes Terraform, vous devez créer un jeton d'accès personnel GitHub. Ce jeton est obligatoire pour permettre à Jenkins d'accéder à votre dépôt dupliqué.

Créer un jeton d'accès personnel GitHub

  1. Connectez-vous à GitHub.
  2. Cliquez sur votre photo de profil, puis sur Paramètres.
  3. Cliquez sur Paramètres du développeur, puis sur Jetons d'accès personnels.
  4. Cliquez sur Générer un nouveau jeton, saisissez une description dans le champ Note, puis sélectionnez le champ d'application dépôt.
  5. Cliquez sur Générer un jeton, puis copiez le jeton créé dans le presse-papiers.

    Générer et copier un jeton dans le presse-papiers

  6. Dans Cloud Shell, enregistrez le jeton dans la variable GITHUB_TOKEN. Cette variable est stockée ultérieurement en tant que secret dans votre cluster GKE.

    GITHUB_TOKEN="NEWLY_CREATED_TOKEN"
    

Créer un cluster GKE et installer Jenkins

Créez maintenant votre cluster GKE. Ce cluster inclut une ressource Workload Identity (jenkins-wi-jenkins@PROJECT_ID.iam.gserviceaccount.com), ce qui vous permet d'accorder à Jenkins l'autorisation requise sur la page Comptes de service dans Cloud Console. En raison de ses propriétés de sécurité améliorées et de sa facilité de gestion, nous vous recommandons d'utiliser Workload Identity pour accéder aux services Google Cloud à partir de GKE.

Pour gérer l'IaC (Infrastructure as Code) Google Cloud, Jenkins doit s'authentifier pour utiliser les API Google Cloud. Dans les étapes suivantes, Terraform configure le compte de service Kubernetes (KSA) utilisé par Jenkins pour agir en tant que compte de service Google (GSA). Cette configuration permet à Jenkins de s'authentifier automatiquement en tant que GSA lors de l'accès aux API Google Cloud.

Pour plus de simplicité, l'accès à l'éditeur de projet est accordé dans ce tutoriel. Cependant, comme ce rôle dispose d'une autorisation étendue, vous devez suivre les bonnes pratiques de votre entreprise en termes de sécurité informatique dans les environnements de production, en fournissant généralement un accès selon la stratégie du moindre privilège.

  1. Dans Cloud Shell, installez Terraform :

    wget https://releases.hashicorp.com/terraform/0.12.24/terraform_0.12.24_linux_amd64.zip
    unzip terraform_0.12.24_linux_amd64.zip
    sudo mv terraform /usr/local/bin/
    rm terraform_0.12.24_linux_amd64.zip
    
  2. Créez le cluster GKE et installez Jenkins :

    cd jenkins-gke/tf-gke/
    terraform init
    terraform plan --var "github_username=$GITHUB_USER" --var "github_token=$GITHUB_TOKEN"
    terraform apply --auto-approve --var "github_username=$GITHUB_USER" --var "github_token=$GITHUB_TOKEN"
    

    Ce processus peut prendre quelques minutes. Le résultat ressemble à ce qui suit :

    Apply complete! Resources: 28 added, 0 changed, 0 destroyed.
    
    Outputs:
    
    ca_certificate = LS0tLS1CRU..
    client_token = <sensitive>
    cluster_name = jenkins
    gcp_service_account_email = jenkins-wi-jenkins@PROJECT_ID.iam.gserviceaccount.com
    jenkins_k8s_config_secrets = jenkins-k8s-config
    jenkins_project_id = PROJECT_ID
    k8s_service_account_name = jenkins-wi-jenkins
    kubernetes_endpoint = <sensitive>
    service_account = tf-gke-jenkins-k253@PROJECT_ID.iam.gserviceaccount.com
    zone = us-east4-a
    

    Lorsque Jenkins est déployé sur le cluster GKE nouvellement créé, le répertoire d'accueil Jenkins est stocké sur un volume persistant conformément à la documentation du chart Helm. Ce déploiement est également fourni avec un pipeline multibranche préconfiguré avec example-pipelines/environments/Jenkinsfile qui se déclenche lors de demandes d'extraction et fusionne avec les branches dev et prod.

  3. Revenez au dossier principal :

    cd ../..
    
  4. Récupérez les identifiants de cluster que vous venez de créer :

    gcloud container clusters get-credentials jenkins --zone=us-east4-a --project=${PROJECT_ID}
    
  5. Récupérez l'URL et les identifiants Jenkins :

    JENKINS_IP=$(kubectl get service jenkins -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
    JENKINS_PASSWORD=$(kubectl get secret jenkins -o jsonpath="{.data.jenkins-admin-password}" | base64 --decode);echo
    printf "Jenkins url: http://$JENKINS_IP\nJenkins user: admin\nJenkins password: $JENKINS_PASSWORD\n"
    
  6. Connectez-vous à Jenkins à l'aide des informations obtenues à l'étape précédente.

  7. Configurez l'emplacement Jenkins de sorte que GitHub puisse créer des liens qui accèdent directement à vos compilations. Cliquez sur Manage Jenkins > Configure System (Gérer Jenkins > Configurer le système) et dans le champ Jenkins URL (URL Jenkins), définissez votre URL Jenkins.

Modifier la configuration de votre environnement dans une nouvelle branche de fonctionnalité

Votre environnement est désormais presque entièrement configuré. Il est donc temps de modifier le code.

  1. Dans Cloud Shell, créez une branche de fonctionnalité que vous pouvez utiliser sans affecter les autres membres de votre équipe :

    git checkout -b change-vm-name
    
  2. Modifiez le nom de la machine virtuelle :

    cd example-pipelines/example-create
    sed -i.bak "s/\${var.environment}-001/\${var.environment}-new/g" main.tf
    

    Vous modifiez le fichier main.tf dans le dossier example-create. Ce fichier est lié par les dossiers d'environnement dev et prod, ce qui signifie que la modification est appliquée aux deux environnements.

  3. Transférez la modification du code vers la branche de fonctionnalité GitHub :

    git commit -am "change vm name"
    git push --set-upstream origin change-vm-name
    
  4. Dans GitHub, accédez à la page principale de votre dépôt dupliqué.

  5. Cliquez sur l'onglet Pull requests (Demandes d'extraction) associé à votre dépôt, puis sur New pull request (Nouvelle demande d'extraction).

  6. Sélectionnez le dépôt que vous venez de dupliquer sous base repository (dépôt de base).

    Créer une demande d'extraction pour le dépôt

  7. Sous base, sélectionnez dev et sous compare (comparer), sélectionnez change-vm-name.

    Sélectionner les duplications

  8. Cliquez sur Create pull request (Créer une demande d'extraction).

  9. Une fois votre demande d'extraction ouverte, une tâche Jenkins est automatiquement lancée (Jenkins peut prendre une minute pour confirmer la nouvelle demande d'extraction). Cliquez sur Show all checks (Afficher toutes les vérifications) et attendez que la vérification devienne verte.

    Attendre que la vérification devienne verte

  10. Cliquez sur Details (Détails) pour afficher plus d'informations, y compris le résultat de la commande terraform plan.

    Informations supplémentaires sur les résultats, y compris le résultat de

La tâche Jenkins a exécuté le pipeline défini à l'emplacement Jenkinsfile. Ce pipeline présente différents comportements en fonction de la branche à récupérer. La compilation vérifie si la variable TARGET_ENV correspond à un dossier d'environnement. Si c'est le cas, Jenkins exécute terraform plan pour cet environnement. Sinon, Jenkins exécute terraform plan pour tous les environnements afin de s'assurer que la modification proposée est valable pour tous. Si l'exécution de l'un de ces plans échoue, la compilation échoue.

terraform plan et example-pipelines/environments s'exécutent pour tous les sous-dossiers, ce qui permet de s'assurer que les modifications proposées sont valables pour tous les environnements. Ainsi, avant de fusionner la demande d'extraction, vous pouvez passer en revue les plans pour vous assurer que l'accès n'est pas accordé à une entité non autorisée, par exemple.

Voici le code terraform plan dans JENKINSFILE :

stage('TF plan') {
  when { anyOf {branch "prod";branch "dev";changeRequest() } }
  steps {
    container('terraform') {
      sh '''
      if [[ $CHANGE_TARGET ]]; then
        TARGET_ENV=$CHANGE_TARGET
      else
        TARGET_ENV=$BRANCH_NAME
      fi

      if [ -d "example-pipelines/environments/${TARGET_ENV}/" ]; then
        cd example-pipelines/environments/${TARGET_ENV}
        terraform plan
      else
        for dir in example-pipelines/environments/*/
        do
          cd ${dir}
          env=${dir%*/}
          env=${env#*/}
          echo ""
          echo "*************** TERRAFOM PLAN ******************"
          echo "******* At environment: ${env} ********"
          echo "*************************************************"
          terraform plan || exit 1
          cd ../../../
        done
      fi'''
    }
  }
}

De même, la commande terraform apply s'exécute pour les branches de l'environnement, mais elle est ignorée dans les autres cas. Dans cette section, vous avez soumis une modification de code à une nouvelle branche, et aucun déploiement d'infrastructure n'a été appliqué à votre projet Cloud.

Voici le code terraform apply dans JENKINSFILE :

stage('TF Apply') {
  when { anyOf {branch "prod";branch "dev" } }
  steps {
    container('terraform') {
      sh '''
      TARGET_ENV=$BRANCH_NAME

      if [ -d "example-pipelines/environments/${TARGET_ENV}/" ]; then
        cd example-pipelines/environments/${TARGET_ENV}
        terraform apply -input=false -auto-approve
      else
        echo "*************** SKIPPING APPLY ******************"
        echo "Branch '$TARGET_ENV' does not represent an official environment."
        echo "*************************************************"
      fi'''
    }
  }
}

Forcer l'exécution Jenkins avant la fusion des branches

Vous pouvez vous assurer que les fusions ne sont appliquées que lorsque les exécutions de tâches Jenkins ont abouti.

  1. Dans GitHub, accédez à la page principale de votre dépôt dupliqué.
  2. Sous le nom de votre dépôt, cliquez sur Settings (Paramètres).
  3. Cliquez sur Branches.
  4. Sous Branch protection rules (Règles de protection des branches), cliquez sur Add rule (Ajouter une règle).
  5. Dans le champ Branch name pattern (Modèle de nom de branche), saisissez dev.
  6. Sous Protect matching branches (Protéger les branches correspondantes), sélectionnez Require status checks to pass before merging (Exiger la validation des vérifications d'état avant la fusion), puis sélectionnez continuous-integration/jenkins/pr-merge.

    (Facultatif) Envisagez d'activer les options Require pull request reviews before merging (Exiger un examen des demandes d'extraction avant la fusion) et Include administrators (Inclure les administrateurs) pour éviter la fusion des demandes d'extraction non examinées et non autorisées en production.

  7. Cliquez sur Create (Créer).

  8. Répétez les étapes 4 à 7 en définissant le modèle de nom de branche sur prod.

Cette configuration est importante pour protéger les branches dev et prod, ce qui signifie que les commits doivent d'abord être transférés vers une autre branche avant de pouvoir être fusionnés dans la branche protégée. Dans ce tutoriel, la protection nécessite que l'exécution de la tâche Jenkins réussisse pour que la fusion soit autorisée. Vous pouvez vérifier si votre configuration a été appliquée dans la nouvelle demande d'extraction. Recherchez les coches vertes.

Vérifier que votre configuration a bien été appliquée

Promouvoir des modifications dans l'environnement de développement

Vous disposez d'une demande d'extraction en attente de fusion. Vous pouvez maintenant appliquer l'état que vous souhaitez à votre environnement dev.

  1. Dans GitHub, accédez à la page principale de votre dépôt dupliqué.
  2. Sous le nom de votre dépôt, cliquez sur Pull requests (Demandes d'extraction).
  3. Cliquez sur la demande d'extraction que vous avez créée.
  4. Cliquez sur Merge pull request (Fusionner la demande d'extraction), puis sur Confirm merge (Confirmer la fusion).

    Fusionner et confirmer une demande d'extraction

  5. Dans Jenkins, cliquez sur Open Blue Ocean (Ouvrir Blue Ocean). Ensuite, dans le projet multibranche terraform-jenkins-create-demo, dans l'onglet Branches, vérifiez l'icône d'état pour voir si une nouvelle tâche dev a été déclenchée. Le démarrage peut prendre environ une minute.

    Vérifier qu'une nouvelle tâche **dev** a été déclenchée

  6. Dans Cloud Console, accédez à la page Instances de VM et vérifiez si vous disposez de la VM avec le nouveau nom.

    Accéder à la page "Instances de VM"

    Vérifiez que vous disposez de la VM avec le nouveau nom.

Promouvoir des modifications dans l'environnement de production

Maintenant que vous avez testé votre environnement de développement, vous pouvez promouvoir votre code d'infrastructure en production.

  1. Dans GitHub, accédez à la page principale de votre dépôt dupliqué.
  2. Cliquez sur New pull request (Nouvelle demande d'extraction).
  3. Sélectionnez le dépôt que vous avez dupliqué sous base repository (dépôt de base).

    Sélectionner le dépôt que vous avez dupliqué

  4. Sous base, sélectionnez prod et sous compare (comparer), sélectionnez dev.

    Dépôts dupliqués pour

  5. Cliquez sur Create pull request (Créer une demande d'extraction).

  6. Saisissez un titre (tel que Promoting vm name change), puis cliquez sur Create pull request (Créer une demande d'extraction).

  7. Attendez que le vérificateur s'affiche en vert (cela peut prendre une minute ou deux), puis cliquez sur le lien Details (Détails) à côté de continuous-integration/jenkins/pr-merge.

    Attendre que le vérificateur s'affiche en vert

  8. Dans Jenkins, sélectionnez TF Plan et examinez les modifications proposées dans les journaux.

    Examiner les modifications proposées dans les journaux

  9. Si les modifications proposées semblent correctes, dans GitHub, cliquez sur Merge pull request (Fusionner la demande d'extraction), puis sur Confirm merge (Confirmer la fusion).

  10. Dans Cloud Console, ouvrez la page Instances de VM et vérifiez si votre VM de production a été déployée.

    Instances de VM

    Vérifier si votre VM de production a été déployée

Vous avez configuré un pipeline IaC (Infrastructure as Code) dans Jenkins. À l'avenir, vous voudrez peut-être essayer les opérations suivantes :

  • Ajouter des déploiements pour des cas d'utilisation distincts
  • Créer des environnements supplémentaires pour répondre à vos besoins
  • Utiliser un projet par environnement au lieu d'un VPC par environnement

Nettoyer

Pour éviter que les ressources utilisées dans ce tutoriel soient facturées sur votre compte Google Cloud Platform, procédez comme suit :

Supprimer le projet

  1. Dans Cloud Console, accédez à la page Gérer les ressources.

    Accéder à la page Gérer les ressources

  2. Dans la liste des projets, sélectionnez le projet que vous souhaitez supprimer, puis cliquez sur Supprimer .
  3. Dans la boîte de dialogue, saisissez l'ID du projet, puis cliquez sur Arrêter pour supprimer le projet.

Étapes suivantes