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 pour 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 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 conteneurs et vos fichiers manifestes
Vous avez besoin d'une ou de plusieurs images de conteneur à déployer et d'au moins une image Kubernetes des fichiers manifestes (à déployer sur GKE) ou des fichiers YAML de service (pour déployer à Cloud Run).
Vous avez besoin d'un pipeline d'intégration continue ou d'un autre processus pour compiler et placez vos images. Vous pouvez utiliser votre outil d'intégration continue Cloud Build, Jenkins ou tout autre outil générant des images de conteneurs 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 fichierskaffold apply
pour les déployer dans votre cible. Pour ce faire, Skaffold requiert au moinsskaffold.yaml
minimale. Vous pouvez en obtenir un de deux manières:Créez le vôtre.
Notez que le fichier
skaffold.yaml
doit référencer l'espace de noms correspondant à une version de Skaffold compatible sur la première ligne, comme dans cet exemple:`apiVersion: skaffold/v4beta7`
Demandez-le 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 Cloud Deploy et ne doivent pas être utilisées pour les charges de travail de production.
Consultez la page Utiliser Skaffold avec Cloud Deploy. pour en savoir plus. 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.
Configurez Cloud Deploy pour l'environnement d'exécution de votre choix
Cloud Deploy peut déployer votre application dans l'un des environnements suivants : environnements d'exécution:
Appeler votre pipeline de livraison pour créer une version
Après avoir configuré Cloud Deploy pour qu'il se déploie dans votre environnement d'exécution, vous pouvez envoyer votre application pour qu'elle soit déployée que vous avez créé.
Exécutez votre processus d'intégration continue (CI) standard en créant le déploiement ou encore des artefacts.
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
Comme cette commande crée un fichier tar contenant l'intégralité du contenu et ses sous-répertoires, vous ne souhaiterez peut-être pas exécuter cette commande de votre répertoire d'accueil ou racine. Exécutez la commande à partir du répertoire contenant votre configuration Skaffold ou inclure l'option
--source=
, décrite plus tard.Dans cette commande...
RELEASE_NAME
est un nom à donner à cette version. La doit être unique parmi toutes les versions de ce pipeline de livraison.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 tout au long cibles. Ce nom doit correspondre au champname
de la définition du pipeline.REGION
est le nom de la région dans laquelle vous la création de la version, par exempleus-central1
. Ce champ est obligatoire.
Cette commande importe un fichier tar contenant vos configurations dans un bucket Cloud Storage bucket 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 transmise 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érez 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. Si vous utilisez cette option avec l'option
--skaffold-file
ou--source
génère une erreur. Voir Génération de votreskaffold.yaml
pour en savoir plus.--from-run-manifest=RUN_MANIFEST
La configuration Skaffold générée est basée sur le Cloud Run de service YAML, vous transmettez cette option. Si vous utilisez cet indicateur avec le paramètre l'option
--skaffold-file
ou--source
génère une erreur. Voir Génération de votreskaffold.yaml
pour en savoir plus.
Ces deux options s'excluent mutuellement.
Vous pouvez également inclure un fichier .gcloudignore
si le fichier
que vous ne voulez 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 approche est utile pour tester Cloud Deploy, mais n'est pas adapté aux charges de travail de production.
La procédure suivante suppose que vous avez déjà créé un pipeline de livraison 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, pour une livraison spécifique, cliquez sur Create release (Créer une version).
Dans le champ Sélectionner un conteneur, collez ou saisissez le chemin d'accès au conteneur. que vous souhaitez déployer. Vous pouvez aussi utiliser le conteneur prérempli par défaut dans ce champ, à des fins d'évaluation.
Vous pouvez également cliquer sur Sélectionner pour choisir une image de conteneur à partir d'Artifact Registry ou Container Registry.
Indiquez un nom unique pour cette version dans le champ Nom de la version ou utilisez le nom fourni par défaut.
Attribuez un nom au déploiement dans le champ Nom du déploiement ou utilisez le est fourni par défaut.
Ce nom est utilisé pour le déploiement sur la première cible de cette version. Pour cibles ultérieures, vous pouvez nommer le déploiement dans la boîte de dialogue Promouvoir ou sur la commande
gcloud deploy releases promote
.Incluez éventuellement une description de cette version dans Description .
Sous Deployment details (Détails du déploiement), saisissez un nom pour votre déploiement ou service Cloud Run, ou utilisez le nom par défaut fournies.
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.
Cliquez sur Créer.
Cloud Deploy utilise le fichier manifeste généré ou
la définition du service Cloud Run, et le skaffold.yaml
généré,
pour créer la version.
Modifier le délai d'expiration du déploiement
Pour les déploiements sur GKE et GKE Enterprise cible clusters, trois délais d'expiration distincts affectent la durée d'exécution attend que Kubernetes signale un déploiement stable:
Cloud Build a un délai avant expiration d'une heure pour les opérations Cloud Build s'exécute pour Cloud Deploy.
Vous pouvez modifier ce délai dans le la configuration de votre environnement d'exécution.
Skaffold propose délai avant expiration de la vérification de l'état (
deploy.statusCheckDeadlineSeconds
) qui correspond au délai d'attente, exprimé en secondes, avant 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, il l'est. SistatusCheck
estfalse
, il y a n'est pas vérifié, le déploiement est marqué comme réussi aprèskubectl apply
se termine correctement.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 Les deux premiers délais avant expiration 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 sur600
(10 minutes), alors Skaffold suppose qu'il s'agit default (non défini) et l'ignore, et le délai avant expiration Skaffold est 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).
Outre les ressources
Deployment
, d'autres ressources Kubernetes peuvent avoir des délais avant expiration, ce qui n'influencent pas le délai avant expiration de la 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 montre 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 de l'état signaler un déploiement stable, soumis à la valeur du délai avant expiration à l'étape suivante.Dans
skaffold.yaml
, définissezstatusCheckDeadlineSeconds
au 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 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ès lestatusCheckDeadlineSeconds
.Ce paramètre indique à Skaffold de ne pas se fermer en cas d'échec d'un déploiement tolérer les échecs jusqu'à l'expiration de
statusCheckDeadlineSeconds
. Ce paramètre peut vous aider lorsque vous disposez de ressources ayant 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, ayant échoué au déploiement 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 n'est compatible 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
Étape suivante
Apprenez-en davantage sur le déploiement sur GKE.
Obtenez plus d'informations sur le déploiement sur Cloud Run.
Apprenez-en davantage sur le déploiement sur GKE Enterprise.
Découvrez comment créer votre pipeline de livraison et vos cibles.
Découvrez comment promouvoir un titre