Cette page explique comment utiliser 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 les éléments que vous devez mettre en place pour 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 effectuer des déploiements sur des clusters Google Kubernetes Engine, Cloud Run et GKE Enterprise. La configuration cible diffère selon l'emplacement où vous effectuez le déploiement.
Disposer des images et des fichiers manifestes de votre conteneur
Vous avez besoin d'une ou de plusieurs images de conteneur à déployer et d'un ou plusieurs fichiers manifestes Kubernetes (à déployer sur GKE) ou 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 d'intégration continue peut être Cloud Build, Jenkins ou tout autre élément générant des images de conteneur que vous pouvez fournir à votre pipeline de livraison 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 etskaffold apply
pour les déployer dans votre cible. Pour ce faire, Skaffold nécessite au moins unskaffold.yaml
minimal. Vous pouvez en obtenir un 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/v2beta28`
Faites en sorte qu'il soit généré automatiquement.
Si vous n'avez pas encore de fichier
skaffold.yaml
, vous pouvez demander à Cloud Deploy d'en créer un pour vous. Ce fichier convient à 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 la page Utiliser Skaffold avec Cloud Deploy. Vous trouverez également dans la section Gérer les fichiers manifestes dans Cloud Deploy davantage d'informations sur l'utilisation de Skaffold et de Cloud Deploy avec des outils de gestion des fichiers manifestes, tels que Helm, Kustomize et kpt.
Configurez 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:
Appeler votre pipeline de livraison pour créer une version
Une fois que vous avez configuré Cloud Deploy pour effectuer un déploiement dans votre environnement d'exécution, vous pouvez envoyer votre application à déployer en fonction du pipeline de livraison que vous avez créé.
Exécutez votre processus d'intégration continue (CI) standard en créant le ou les artefacts déployables.
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
Où :
RELEASE_NAME
est un 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'
renvoierel-1507
.'$DATE'
et'$TIME'
doivent être entre guillemets simples, et l'heure correspond à l'heure 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 via la progression des cibles. Ce nom doit correspondre au champname
de la définition du pipeline.REGION
est le nom de la région dans laquelle vous créez la version, par exempleus-central1
. Ce champ est 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 et déploie votre image sur la première cible définie dans le pipeline de livraison.
En plus des paramètres présentés par 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 de l'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--source
génère une erreur. Pour en savoir plus, consultez la section Générer le codeskaffold.yaml
.--from-run-manifest=RUN_MANIFEST
La configuration Skaffold générée est basée sur le fichier YAML du service Cloud Run auquel 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 le codeskaffold.yaml
.
Ces deux options s'excluent mutuellement.
Créer une version à partir de la console Google Cloud
Vous pouvez utiliser la console Google Cloud afin de créer une version pour un pipeline de livraison. Cette approche est utile pour tester Cloud Deploy, mais pas pour les 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.)
Sur la page Détails du pipeline de livraison, cliquez sur Créer une version pour un pipeline de livraison spécifique.
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 ou Container Registry.
Indiquez un nom unique pour cette version dans le champ Nom de la version ou utilisez le nom par défaut fourni.
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
.Ajoutez éventuellement une description de cette version dans le champ Description.
Sous Informations sur le 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.
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 avant expiration du déploiement
Pour les déploiements sur des clusters cibles GKE et GKE Enterprise, trois délais avant expiration distincts affectent le délai 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 effectuées par Cloud Build pour Cloud Deploy.
Vous pouvez modifier ce délai avant expiration dans 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 à la durée, en secondes, nécessaire pour attendre 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 surtrue
. Par défaut, c'est le cas. SistatusCheck
est défini surfalse
, aucune vérification de l'état n'est effectuée, et le déploiement est marqué comme réussi une fois l'étapekubectl apply
terminée.Pour les ressources Kubernetes de
kind: Deployment
, il existeDeployment.spec.progressDeadlineSeconds
, qui correspond au temps que Kubernetes attend que le déploiement soit signalé comme stable.Ce délai avant expiration ne s'applique qu'aux ressources
Deployment
. Voici comment ces deux premiers délais fonctionnent ensemble:Si la valeur
Deployment.spec.progressDeadlineSeconds
n'est pas définie dans Kubernetes, le délai avant expiration de la vérification d'état Skaffold correspond au délai effectif, qu'il s'agisse de la valeur par défaut ou qu'elle soit explicitement définie.Si
Deployment.spec.progressDeadlineSeconds
est défini dans Kubernetes, Skaffold ignore son propre délai avant expiration de la vérification de l'état. Le délai de progression de Kubernetes correspond au délai d'expiration effectif. Toutefois, si le délai avant expiration de Kubernetes est explicitement défini sur600
(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 Skaffold est alors utilisé (s'il est défini).Si aucun délai avant expiration n'est défini, le délai avant expiration effectif est la valeur par défaut définie par Skaffold (
600
) (10 minutes).
Outre les
Deployment
, d'autres ressources Kubernetes peuvent avoir des délais avant expiration qui n'influencent pas le délai avant expiration de la stabilité. Le cas échéant, vérifiez-les pour vous assurer qu'ils n'entrent pas en conflit avec le délai avant expiration de la stabilité.Si Skaffold (ou Cloud Build) expire, le déploiement GKE continue de s'exécuter. Cloud Deploy présente un échec, mais il peut tout de même réussir ou échouer sur le cluster GKE.
Pour modifier le délai avant expiration de la stabilité du déploiement:
Assurez-vous que
deploy.statusCheck
est défini surtrue
dansskaffold.yaml
.true
est la valeur par défaut. Lorsque la valeur esttrue
, Skaffold attend que les vérifications d'état signalent un déploiement stable, sous réserve de la valeur de délai avant expiration indiquée à l'étape suivante.Dans
skaffold.yaml
, définissezstatusCheckDeadlineSeconds
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 obtenir un déploiement stable. Si ce délai est dépassé avant que le déploiement ne soit stable, le déploiement échoue.Vous pouvez éventuellement ajouter
tolerateFailuresUntilDeadline: true
aprèsstatusCheckDeadlineSeconds
.Ce paramètre indique à Skaffold de ne pas se fermer en cas d'échec d'un déploiement, 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 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 ayant échoué peut s'afficher 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.
Dans votre fichier manifeste Kubernetes, pour les ressources de
kind: Deployment
, définissezDeployment.spec.progressDeadlineSeconds
sur la même valeur que celle définie pourstatusCheckDeadlineSeconds
.
Étapes suivantes
Apprenez-en davantage sur le déploiement sur GKE.
Découvrez comment déployer 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 faire la promotion d'un album.