Déployer votre application

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

Avant de commencer

Cette section décrit ce que vous devez avoir en place avant de pouvoir déployer votre application à l'aide de Google 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.

  Google Cloud Deploy peut effectuer des déploiements sur des clusters Google Kubernetes Engine, Cloud Run et Anthos. La configuration cible varie en fonction de celle sur laquelle vous déployez.

• Conservez vos images de conteneur et vos fichiers manifestes.

  Vous avez besoin d'une ou de plusieurs images de conteneur à déployer et 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 CI peut être Cloud Build, Jenkins ou tout autre élément qui génère des images de conteneur que vous pouvez fournir à votre pipeline de livraison Google Cloud Deploy.

• Vous devez disposer d'un fichier de configuration skaffold.yaml.

  Google 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 en obtenir une de deux manières:

  • Créez le 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/v2beta28`
    

  • Faites-le générer automatiquement.

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

  Pour en savoir plus, consultez la page Utiliser Skaffold avec Google Cloud Deploy. Pour en savoir plus sur l'utilisation de Skaffold et de Google Cloud Deploy avec des outils de gestion de fichiers manifestes tels que Helm, Kustomize et Kpt, consultez la page Gérer les fichiers manifestes dans Google Cloud Deploy.

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

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

• GKE
• Anthos
• Cloud Run

Appelez votre pipeline de livraison pour créer une version

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

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

2. Démarrez le pipeline de livraison en appelant Google 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
   

   Où :

   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' renvoie rel-1507. '$DATE' et '$TIME' doivent être entre guillemets simples, et l'heure est UTC sur la machine sur laquelle vous appelez la commande.

   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. 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 package tarball contenant vos configurations dans un bucket Cloud Storage et crée la version. Google Cloud Deploy crée également un déploiement et déploie votre image sur la première cible définie dans le pipeline de livraison.

Outre les 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'une des options suivantes pour que Google 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. 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.

• --from-run-manifest=RUN_MANIFEST

  La configuration Skaffold générée est basée sur le service YAML 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 la section Générer votre skaffold.yaml.

Ces deux options s'excluent mutuellement.

Modifier le délai avant expiration du déploiement

Pour les déploiements sur des clusters cibles GKE et Anthos, trois délais d'expiration distincts affectent le temps que le système attend pour que Kubernetes signale un déploiement stable:

• Le délai avant expiration de Cloud Build est d'une heure pour les opérations effectuées par Cloud Build pour Google Cloud Deploy.

  Vous pouvez modifier ce délai 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 à la durée, en secondes, nécessaire à la stabilisation des déploiements.

  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, c'est le cas. Si la valeur de statusCheck est false, aucune vérification d'é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 à la durée pendant laquelle Kubernetes attend que le déploiement soit stable.

  Ce délai s'applique uniquement aux ressources Deployment. Voici comment ces deux premiers délais d'expiration interagissent:

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

  • Si Deployment.spec.progressDeadlineSeconds, dans Kubernetes, est défini, Skaffold ignore son propre délai avant vérification de l'état et le délai de progression de Kubernetes est le 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 utilisé (le cas échéant).

  • Si aucun délai d'inactivité n'est défini, le délai d'expiration effectif est la valeur par défaut de Skaffold, définie sur 600 (10 minutes).

  Outre les Deployment, d'autres ressources Kubernetes peuvent avoir des délais d'expiration qui n'ont pas d'incidence sur le délai d'expiration de la stabilité. Si l'un de ces éléments est présent, vérifiez-le afin de vous assurer qu'il n'est pas en conflit avec le délai d'expiration de la stabilité.

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

Pour modifier le délai avant expiration de la stabilité de votre 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 avant 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, il échoue.

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

   Ce paramètre indique à Skaffold de ne pas se fermer en cas d'échec d'un seul déploiement, mais de tolérer les échecs jusqu'à l'expiration de statusCheckDeadlineSeconds. Ce paramètre peut s'avérer utile si vous avez des ressources qui pourraient 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 Anthos Service Mesh, un déploiement peut échouer et un message semblable à celui-ci peut s'afficher:

   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 kind: Deployment, définissez Deployment.spec.progressDeadlineSeconds sur la même valeur que statusCheckDeadlineSeconds.

Étapes suivantes

• Découvrez comment déployer sur GKE

• Découvrez comment déployer sur Cloud Run

• Découvrez comment déployer sur Anthos.

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

• Découvrez comment promouvoir une version.