Déployer votre application

Cette page explique comment utiliser Cloud Deploy pour intégrer votre application dans les environnements d'exécution cibles souhaités. Avant de commencer, vous devez créer votre pipeline et vos cibles de diffusion.

Avant de commencer

Cette section décrit les éléments que vous devez mettre en place avant de pouvoir déployer votre application à l'aide de Cloud Deploy.

• Assurez-vous que votre compte de service d'exécution dispose des rôles et autorisations IAM nécessaires.

• Créez votre pipeline de livraison et vos cibles.

  Cloud Deploy peut déployer des applications sur des clusters Google Kubernetes Engine, Cloud Run et GKE Enterprise. La configuration cible diffère selon l'environnement dans lequel vous déployez l'application.

• Disposez de vos images et de vos fichiers manifestes de conteneurs.

  Vous avez besoin d'une ou plusieurs images de conteneurs à déployer, ainsi que d'un ou plusieurs fichiers manifestes Kubernetes (pour déployer sur GKE) ou fichiers YAML de service (pour déployer sur Cloud Run).

  Vous avez besoin d'un pipeline d'intégration continue ou d'un autre processus pour compiler et placer vos images. Votre outil CI peut être Cloud Build, Jenkins ou tout autre outil générant des images de conteneurs que vous pouvez fournir à votre pipeline de déploiement Cloud Deploy.

• Disposer d'un fichier de configuration skaffold.yaml.

  Cloud Deploy appelle skaffold render pour afficher les fichiers manifestes Kubernetes à l'aide de ce fichier et skaffold apply pour les déployer dans votre cible. Pour ce faire, Skaffold nécessite au moins un skaffold.yaml minimal. Vous pouvez l'obtenir de deux manières :

  • Créez la vôtre.

    Notez que le fichier skaffold.yaml doit faire référence à l'espace de noms correspondant à une version Skaffold compatible sur la première ligne, comme dans cet exemple :

    `apiVersion: skaffold/v4beta7`
    

  • Demandez à Gemini de le générer pour vous.

    Si vous n'avez pas encore de fichier skaffold.yaml, vous pouvez demander à Cloud Deploy d'en créer un pour vous. Ce fichier est adapté à l'intégration, à l'apprentissage ou à la démonstration de Cloud Deploy. Il ne doit pas être utilisé pour les charges de travail de production.

  Pour en savoir plus, consultez Utiliser Skaffold avec Cloud Deploy. La page Gérer les fichiers manifestes dans Cloud Deploy fournit également plus d'informations sur l'utilisation de Skaffold et Cloud Deploy avec des outils de gestion des fichiers manifestes, tels que Helm, Kustomize et kpt.

Configurer Cloud Deploy pour l'environnement d'exécution de votre choix

Cloud Deploy peut déployer votre application dans l'un des environnements d'exécution suivants :

• GKE
• GKE Enterprise
• Cloud Run

Appeler votre pipeline de livraison pour créer une version

Une fois que vous avez configuré Cloud Deploy pour le déploiement sur votre environnement d'exécution, vous pouvez envoyer votre application pour qu'elle soit déployée selon le pipeline de déploiement que vous avez créé.

1. Exécutez votre processus d'intégration continue (CI) habituel pour créer le ou les artefacts déployables.

2. Lancez le pipeline de livraison en appelant Cloud Deploy pour créer une version.

   Exécutez la commande suivante à partir du répertoire contenant votre configuration Skaffold :

   gcloud deploy releases create RELEASE_NAME --delivery-pipeline=PIPELINE_NAME --region=REGION
   

   Étant donné que cette commande crée un fichier tar de l'intégralité du contenu du répertoire et de ses sous-répertoires, il est préférable de ne pas l'exécuter à partir de votre répertoire d'accueil ou racine. Exécutez la commande à partir du répertoire contenant votre configuration Skaffold ou incluez l'option --source=, décrite plus loin.

   Dans cette commande :

   RELEASE_NAME est le nom à attribuer à cette version. Le nom doit être unique parmi toutes les versions de ce pipeline de livraison.

   Vous pouvez spécifier des noms de version dynamiques en incluant '$DATE', '$TIME' ou les deux. Par exemple, si vous appelez cette commande à 15h07 UTC, 'rel-$TIME' est résolu en rel-1507. '$DATE' et '$TIME' doivent être entre guillemets simples, et l'heure est celle de l'ordinateur sur lequel vous exécutez la commande (heure UTC).

   PIPELINE_NAME est le nom du pipeline de livraison qui gérera le déploiement de cette version tout au long de la progression des cibles. Ce nom doit correspondre au champ name dans la définition du pipeline.

   REGION est le nom de la région dans laquelle vous créez la version, par exemple us-central1. Obligatoire.

Cette commande importe un fichier tar contenant vos configurations dans un bucket Cloud Storage et crée la version. Cloud Deploy crée également automatiquement un déploiement progressif et déploie votre image sur la première cible définie dans le pipeline de diffusion.

En plus des paramètres affichés avec cette commande, vous pouvez inclure l'une ou l'autre des options suivantes :

• --images=<name=path/name:$IMAGE_SHA>,<name=path/name:$IMAGE_SHA>

  Ensemble de remplacements de nom d'image par un chemin d'accès complet d'image.

• --build-artifacts=<path/file>

  Référence à un fichier de sortie d'artefacts de compilation Skaffold, qui peut être transmis pour représenter les remplacements de chemin d'accès complet d'image.

Ces deux options s'excluent mutuellement.

Vous pouvez également inclure l'un des indicateurs suivants pour que Cloud Deploy génère un fichier skaffold.yaml pour vous :

• --from-k8s-manifest=K8S_MANIFEST

  La configuration Skaffold générée est basée sur le fichier manifeste Kubernetes que vous transmettez à cet indicateur. L'utilisation de cette option avec l'option --skaffold-file ou --source génère une erreur. Pour en savoir plus, consultez Générer votre skaffold.yaml.

• --from-run-manifest=RUN_MANIFEST

  La configuration Skaffold générée est basée sur le fichier YAML du service Cloud Run que vous transmettez à cet indicateur. L'utilisation de cette option avec l'option --skaffold-file ou --source génère une erreur. Pour en savoir plus, consultez Générer votre skaffold.yaml.

Ces deux options s'excluent mutuellement.

Vous pouvez également inclure un fichier .gcloudignore si certains fichiers du répertoire ne doivent pas être inclus dans le fichier tar.

Créer une version depuis la console Google Cloud

Vous pouvez utiliser la console Google Cloud pour créer une version pour un pipeline de déploiement. Cette méthode est utile pour tester Cloud Deploy, mais n'est pas adaptée aux charges de travail de production.

La procédure suivante suppose que vous avez déjà créé un pipeline de livraison et une ou plusieurs cibles. (Vous pouvez également utiliser la console Google Cloud pour créer votre pipeline de livraison.)

1. Sur la page Informations sur le pipeline de diffusion, cliquez sur Créer une version pour un pipeline de diffusion spécifique.

   

2. Dans le champ Choisir un conteneur, collez ou saisissez le chemin d'accès à l'image de conteneur que vous souhaitez déployer. Vous pouvez également utiliser le conteneur par défaut prérempli dans ce champ pour l'évaluation.

   Vous pouvez également cliquer sur Sélectionner pour choisir une image de conteneur dans Artifact Registry.

3. Dans le champ Nom de la version, saisissez un nom unique pour cette version ou utilisez le nom par défaut fourni.

4. Dans le champ Nom du déploiement, saisissez un nom pour le déploiement ou utilisez le nom par défaut fourni.

   Ce nom est utilisé pour le déploiement sur la première cible, pour cette version. Pour les cibles suivantes, vous pouvez nommer le déploiement dans la boîte de dialogue Promouvoir ou avec la commande gcloud deploy releases promote.

5. Vous pouvez également inclure une description de cette version dans le champ Description.

6. Sous Détails du déploiement, saisissez un nom pour votre déploiement GKE ou votre service Cloud Run, ou utilisez le nom par défaut fourni.

   Pour GKE, Cloud Deploy génère le fichier manifeste pour vous. Pour Cloud Run, Cloud Deploy génère la définition de service, qui est utilisée pour créer le service.

7. Cliquez sur Créer.

   

Cloud Deploy utilise le fichier manifeste ou la définition de service Cloud Run générés, ainsi que le skaffold.yaml généré, pour créer la version.

Modifier le délai de déploiement

Pour les déploiements sur les clusters cibles GKE et GKE Enterprise, trois délais d'attente distincts affectent la durée pendant laquelle le système attend que Kubernetes signale un déploiement stable :

• Cloud Build dispose d'un délai avant expiration d'une heure pour les opérations qu'il effectue pour Cloud Deploy.

  Vous pouvez modifier ce délai d'expiration dans la configuration de votre environnement d'exécution.

• Skaffold dispose d'un délai avant expiration de la vérification d'état (deploy.statusCheckDeadlineSeconds), qui correspond au temps (en secondes) à attendre pour que les déploiements se stabilisent.

  La valeur par défaut est de 600 secondes (10 minutes). Pour utiliser ce délai avant expiration, deploy.statusCheck doit être défini sur true. Par défaut, c'est le cas. Si statusCheck est défini sur false, aucune vérification de l'état n'est effectuée. Le déploiement est marqué comme réussi une fois que kubectl apply s'est terminé avec succès.

• Pour les ressources Kubernetes de kind: Deployment, il existe Deployment.spec.progressDeadlineSeconds, qui correspond au temps pendant lequel Kubernetes attend que le déploiement soit signalé comme stable.

  Ce délai s'applique uniquement aux ressources Deployment. Voici comment ces deux premiers délais d'inactivité fonctionnent ensemble :

  • Si Deployment.spec.progressDeadlineSeconds n'est pas défini dans Kubernetes, le délai avant expiration de la vérification de l'état de Skaffold est le délai effectif, qu'il s'agisse de la valeur par défaut ou d'une valeur définie explicitement.

  • Si Deployment.spec.progressDeadlineSeconds est défini dans Kubernetes, Skaffold ignore son propre délai de vérification de l'état, et le délai de progression de Kubernetes devient le délai effectif. Toutefois, si le délai avant expiration de Kubernetes est explicitement défini sur 600 (10 minutes), Skaffold suppose qu'il s'agit de la valeur par défaut (non définie) et l'ignore. Le délai avant expiration de Skaffold est alors utilisé (s'il est défini).

  • Si aucun délai n'est défini, le délai effectif est celui par défaut de Skaffold, à savoir 600 (10 minutes).

  Outre les Deployment, d'autres ressources Kubernetes peuvent avoir des délais d'attente qui n'ont aucune incidence sur le délai d'attente de stabilité. Si l'un d'eux est présent, examinez-le pour vous assurer qu'il n'est pas en conflit avec le délai d'inactivité de stabilité.

  Si Skaffold (ou Cloud Build) expire, le déploiement GKE continue de s'exécuter. Cloud Deploy affiche un échec, mais le déploiement peut quand même réussir ou échouer sur le cluster GKE.

Pour modifier le délai avant expiration de la stabilité du déploiement :

1. Assurez-vous que deploy.statusCheck est défini sur true dans skaffold.yaml.

   true est la valeur par défaut. Lorsque la valeur est true, Skaffold attend que les vérifications de l'état signalent un déploiement stable, sous réserve de la valeur du délai d'expiration à l'étape suivante.

2. Dans skaffold.yaml, définissez statusCheckDeadlineSeconds sur le nombre de secondes que vous souhaitez attendre.

   deploy:
     ...
     statusCheck: true
     statusCheckDeadlineSeconds: 600
     ...
   

   La valeur par défaut est 600 (10 minutes). Skaffold attend ce délai pour un déploiement stable. Si ce délai est dépassé avant que le déploiement ne soit stable, le déploiement échoue.

3. Vous pouvez éventuellement ajouter tolerateFailuresUntilDeadline: true après statusCheckDeadlineSeconds.

   Ce paramètre indique à Skaffold de ne pas quitter si un seul déploiement échoue, mais de tolérer les échecs jusqu'à l'expiration de statusCheckDeadlineSeconds. Ce paramètre peut être utile dans les situations où vous disposez de ressources qui peuvent avoir besoin de plus de temps (jusqu'à l'échéance de la vérification de l'état) pour atteindre un état stable.

   Par exemple, si vous utilisez Istio ou Cloud Service Mesh, il est possible que le déploiement échoue et qu'un message semblable à celui-ci s'affiche :

   error iptables validation failed; workload is not ready for Istio.
   When using Istio CNI, this can occur if a pod is scheduled before the node is ready.
   

4. Dans votre fichier manifeste Kubernetes, pour les ressources de kind: Deployment, définissez Deployment.spec.progressDeadlineSeconds sur la même valeur que celle définie pour statusCheckDeadlineSeconds.

Étapes suivantes

• Découvrez comment déployer sur GKE.

• En savoir plus sur le déploiement sur Cloud Run

• Découvrez comment déployer sur GKE Enterprise.

• Découvrez comment créer votre pipeline de livraison et vos cibles.

• Découvrez comment promouvoir une sortie.