Déployer votre application

Cette page explique comment utiliser Cloud Deploy pour obtenir votre application dans les environnements d'exécution cibles souhaités. Avant cela, vous devez créez votre pipeline de livraison et vos cibles.

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 diffusion et vos cibles.

  Cloud Deploy peut effectuer des déploiements sur Google Kubernetes Engine, Cloud Run, et les clusters GKE Enterprise. La configuration de la cible diffère selon celui sur lequel vous effectuez le déploiement.

• Avoir vos images de conteneur et vos fichiers manifestes

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

  Vous avez besoin d'un pipeline d'intégration continue ou d'un autre processus pour créer et placer vos images. Votre outil de CI peut être Cloud Build, Jenkins ou tout autre outil qui génère des images de conteneur que vous pouvez fournir à votre pipeline de livraison Cloud Deploy.

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

  Cloud Deploy appelle skaffold render pour effectuer le rendu des fichiers manifestes Kubernetes à l'aide de ce fichier skaffold apply pour les déployer dans votre cible. Pour ce faire, Skaffold a besoin d'au moins un skaffold.yaml minimale. Vous pouvez en obtenir un de deux manières :

  • Créez-en un.

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

    `apiVersion: skaffold/v4beta7`
    

  • Laissez-nous la générer pour vous.

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

  Pour en savoir plus, consultez la section Utiliser Skaffold avec Cloud Deploy. Pour en savoir plus, consultez la page Gérer les fichiers manifestes dans Cloud Deploy. plus en détail sur l'utilisation de Skaffold et Cloud Deploy avec de gestion des fichiers manifestes, comme 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 conformément au pipeline de diffusion que vous avez créé.

1. Exécutez votre processus d'intégration continue (CI) standard en créant le déploiement ou encore des artefacts.

2. Démarrez le pipeline de livraison en appelant Cloud Deploy pour créer une sortie.

   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, vous ne souhaiterez peut-être 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 diffusion.

   Vous pouvez spécifier des noms de versions dynamiques en incluant '$DATE', '$TIME' ou les deux. Par exemple, si vous appelez cette commande à 15h07 UTC, 'rel-$TIME' correspond à rel-1507. Les éléments '$DATE' et '$TIME' doivent être entre guillemets simples. l'heure est l'heure UTC sur la machine où vous appelez la commande.

   PIPELINE_NAME est le nom du pipeline de livraison. qui gérera le déploiement de cette version 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 la création de la version, par exemple us-central1. Ce champ est obligatoire.

Remarque :Vous pouvez éventuellement inclure --source=SOURCE_PATH. pour spécifier l'emplacement du fichier skaffold.yaml. La valeur par défaut est le répertoire actuel.

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

En plus des paramètres affichés avec cette commande, vous pouvez inclure l'une 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 à votre place :

• --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 l'option --source génère une erreur. Voir Génération de votre skaffold.yaml pour en savoir plus.

• --from-run-manifest=RUN_MANIFEST

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

Ces deux options s'excluent mutuellement.

Vous pouvez également inclure un fichier .gcloudignore si le répertoire contient des fichiers que vous ne souhaitez pas inclure dans le fichier tar.

Créer une version depuis la console Google Cloud

Vous pouvez créer une version pour une distribution à l'aide de la console Google Cloud pipeline. 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 diffusion.

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 du 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 ou Container Registry.

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

4. Attribuez un nom au déploiement dans le champ Nom du 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 dans la commande gcloud deploy releases promote.

5. Incluez éventuellement une description de cette version dans 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 vous. Pour Cloud Run, Cloud Deploy génère la définition de service, qui permet de créer le service.

7. Cliquez sur Créer.

   

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

Modifier le délai avant expiration du déploiement

Pour les déploiements dans les clusters cibles GKE et GKE Enterprise, trois délais d'inactivité distincts affectent la durée d'attente du système pour 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 dans le la configuration de votre environnement d'exécution.

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

  La valeur par défaut est de 600 secondes (10 minutes). Pour utiliser ce délai, deploy.statusCheck doit être défini sur true. Par défaut, il l'est. Si statusCheck est 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é.

• Pour les ressources Kubernetes de kind: Deployment, Deployment.spec.progressDeadlineSeconds, c'est-à-dire la durée pendant laquelle Kubernetes attend que le déploiement soit consigné stable.

  Ce délai avant expiration ne s'applique qu'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, alors le délai avant expiration de la vérification d'état Skaffold est le délai avant expiration effectif, qu'il s'agisse par défaut ou est explicitement défini.

  • Si Deployment.spec.progressDeadlineSeconds est défini dans Kubernetes, alors Skaffold ignore son propre délai avant expiration de la vérification de l'état, et la progression Kubernetes "délai" correspond au délai avant expiration 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 d'inactivité n'est défini, le délai avant expiration effectif correspond au délai d'expiration Skaffold. la valeur par défaut est 600 (10 minutes).

  En plus des Deployment, d'autres ressources Kubernetes peuvent avoir des délais avant expiration, qui n'affectent pas le délai avant expiration de stabilité. Si l'un d'entre eux est présent, vérifiez pour s'assurer qu'ils n'entrent pas en conflit avec le délai avant expiration de la stabilité.

  En cas d'expiration du délai Skaffold (ou Cloud Build), le cluster GKE continue de s'exécuter. Cloud Deploy affiche une erreur, mais le déploiement peut toujours 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 signaler un déploiement stable, soumis à la valeur du délai avant expiration à l'étape suivante.

2. Dans skaffold.yaml, définissez statusCheckDeadlineSeconds sur le nombre de secondes d'attente.

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

   La valeur par défaut est 600 (10 minutes). Skaffold attend ce délai 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 s'arrêter si un seul déploiement échoue, mais de tolérer les échecs jusqu'à l'expiration de statusCheckDeadlineSeconds. Ce paramètre peut être utile lorsque des ressources peuvent avoir besoin de plus de temps (jusqu'à la date limite de vérification de l'état) pour atteindre un état stable.

   Par exemple, si vous utilisez Istio ou Cloud Service Mesh, le déploiement peut échouer avec un message semblable à celui-ci :

   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.
   

   Ce paramètre ne fonctionne qu'avec Skaffold 2.0 ou version ultérieure.

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

Étape suivante

• Apprenez-en davantage sur le déploiement sur GKE.

• Découvrez comment déployer sur Cloud Run.

• Apprenez-en davantage sur le déploiement sur GKE Enterprise.

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

• Découvrez comment promouvoir une version.