En esta página, se describe cómo usar Cloud Deploy para que tu aplicación funcione en los entornos de ejecución de destino deseados. Antes de hacerlo, debes crear tu canalización de entrega y tus destinos.
Antes de comenzar
En esta sección, se describen los elementos que debes tener listos antes de implementar tu aplicación con Cloud Deploy.
Asegúrate de que tu cuenta de servicio de ejecución tenga los roles y permisos de IAM necesarios.
Crea la canalización de entrega y los destinos.
Cloud Deploy puede realizar implementaciones en clústeres de Google Kubernetes Engine, Cloud Run y GKE Enterprise. La configuración del destino difiere según el destino en el que realices la implementación.
Tener tus imágenes y manifiestos de contenedor
Necesitas una o más imágenes de contenedor para implementar y uno o más manifiestos de Kubernetes (para implementar en GKE) o archivos YAML de servicio (para implementar en Cloud Run).
Necesitas una canalización de integración continua o algún otro proceso para compilar y colocar tus imágenes. Tu herramienta de CI puede ser Cloud Build, Jenkins o cualquier otra herramienta que genere imágenes de contenedor que puedas proporcionar a tu canalización de entrega de Cloud Deploy.
Tener un archivo de configuración
skaffold.yaml
Cloud Deploy llama a
skaffold render
para renderizar los manifiestos de Kubernetes con este archivo y askaffold apply
para implementarlos en tu destino. Para ello, Skaffold requiere al menos unskaffold.yaml
mínimo. Puedes obtener uno de dos maneras:Crea tu propia lista.
Ten en cuenta que el archivo
skaffold.yaml
debe hacer referencia al espacio de nombres correspondiente a una versión compatible de Skaffold en la primera línea, como en este ejemplo:`apiVersion: skaffold/v4beta7`
Genera el texto por ti.
Si aún no tienes un archivo
skaffold.yaml
, puedes hacer que Cloud Deploy cree uno por ti. Este archivo es adecuado para la incorporación, el aprendizaje o la demostración de Cloud Deploy, y no se debe usar para cargas de trabajo de producción.
Consulta Cómo usar Skaffold con Cloud Deploy para obtener más detalles. Además, en Administra manifiestos en Cloud Deploy, encontrarás más detalles para usar Skaffold y Cloud Deploy con herramientas de administración de manifiestos, como Helm, Kustomize y kpt.
Configura Cloud Deploy para el entorno de ejecución que elijas
Cloud Deploy puede implementar tu aplicación en cualquiera de los siguientes entornos de ejecución:
Invoca tu canalización de entrega para crear una versión
Después de configurar Cloud Deploy para que realice la implementación en tu entorno de ejecución, puedes enviar tu aplicación para que se implemente según la canalización de entrega que creaste.
Ejecuta tu proceso de integración continua (CI) habitual para crear los artefactos implementables.
Llama a Cloud Deploy para crear una versión y, así, iniciar la canalización de entrega.
Ejecuta el siguiente comando desde el directorio que contiene tu configuración de Skaffold:
gcloud deploy releases create RELEASE_NAME --delivery-pipeline=PIPELINE_NAME --region=REGION
Como este comando crea un archivo tar de todo el contenido del directorio y de los subdirectorios, es posible que no quieras ejecutarlo desde tu directorio principal o raíz. Ejecuta el comando desde el directorio que contiene tu configuración de Skaffold o incluye la opción
--source=
, que se describe más adelante.En este comando, sucede lo siguiente:
RELEASE_NAME
es un nombre para esta versión. El nombre debe ser único entre todas las versiones de esta canalización de entrega.Puedes especificar nombres de versión dinámicos si incluyes
'$DATE'
o'$TIME'
, o ambos. Por ejemplo, si invocas este comando a las 3:07 p.m. (UTC),'rel-$TIME'
se resuelve comorel-1507
.'$DATE'
y'$TIME'
deben estar entre comillas simples, y la hora es la hora UTC en la máquina en la que invocas el comando.PIPELINE_NAME
es el nombre de la canalización de entrega que administrará la implementación de esta versión a través de la progresión de los destinos. Este nombre debe coincidir con el camponame
en la definición de la canalización.REGION
es el nombre de la región en la que crearás la versión, por ejemplo,us-central1
. Este campo es obligatorio.
Este comando sube un archivo tar que contiene tus configuraciones a un bucket de Cloud Storage y crea la versión. Cloud Deploy también crea automáticamente una implementación progresiva y, luego, implementa tu imagen en el primer destino definido en la canalización de entrega.
Además de los parámetros que se muestran con este comando, puedes incluir cualquiera de las siguientes opciones:
--images=<name=path/name:$IMAGE_SHA>,<name=path/name:$IMAGE_SHA>
Es una colección de reemplazos del nombre de la imagen por la ruta de acceso completa de la imagen.
--build-artifacts=<path/file>
Es una referencia a un archivo de salida de artefactos de compilación de Skaffold, que se puede pasar para representar los reemplazos de la ruta de acceso completa de la imagen.
Estas dos opciones son mutuamente excluyentes.
También puedes incluir una de las siguientes marcas para que Cloud Deploy genere un archivo skaffold.yaml
por ti:
--from-k8s-manifest=K8S_MANIFEST
La configuración de Skaffold generada se basa en el manifiesto de Kubernetes que le pasas a esta marca. Si usas esta marca con la marca
--skaffold-file
o la marca--source
, se generará un error. Consulta Cómo generar tuskaffold.yaml
para obtener más detalles.--from-run-manifest=RUN_MANIFEST
La configuración de Skaffold generada se basa en el archivo YAML del servicio de Cloud Run que pasas a esta marca. Si usas esta marca con la marca
--skaffold-file
o la marca--source
, se generará un error. Consulta Cómo generar tuskaffold.yaml
para obtener más detalles.
Estas dos opciones son mutuamente excluyentes.
También puedes incluir un archivo .gcloudignore
si hay archivos en el directorio que no quieres incluir en el archivo tar.
Crea una versión desde la consola de Google Cloud
Puedes usar la consola de Google Cloud para crear una versión para una canalización de entrega. Esto es útil para probar Cloud Deploy, pero no es adecuado para cargas de trabajo de producción.
En el siguiente procedimiento, se supone que ya creaste una canalización de entrega y uno o más destinos. También puedes usar la consola de Google Cloud para crear tu canalización de entrega.
En la página Detalles de la canalización de entrega, haz clic en Crear lanzamiento para una canalización de entrega específica.
En el campo Elige un contenedor, pega o escribe la ruta de acceso a la imagen del contenedor que deseas implementar. También puedes usar el contenedor predeterminado que se completa previamente en este campo para la evaluación.
También puedes hacer clic en Seleccionar para elegir una imagen de contenedor de Artifact Registry.
Proporciona un nombre único para esta versión en el campo Nombre de la versión o usa el nombre predeterminado que se proporciona.
Proporciona un nombre para el lanzamiento en el campo Nombre del lanzamiento o usa el nombre predeterminado que se proporciona.
Este nombre se usa para el lanzamiento en el primer destino de esta versión. Para los destinos posteriores, puedes nombrar el lanzamiento en el diálogo Promote o en el comando
gcloud deploy releases promote
.De forma opcional, incluye una descripción para esta versión en el campo Descripción.
En Detalles de la implementación, ingresa un nombre para tu implementación de GKE o servicio de Cloud Run, o bien usa el nombre predeterminado proporcionado.
En el caso de GKE, Cloud Deploy genera el manifiesto por ti. En el caso de Cloud Run, Cloud Deploy genera la definición del servicio, que se usa para crear el servicio.
Haz clic en Crear.
Cloud Deploy usa el manifiesto generado o la definición del servicio de Cloud Run, y el skaffold.yaml
generado, para crear la versión.
Cómo cambiar el tiempo de espera de implementación
En el caso de las implementaciones en clústeres de destino de GKE y GKE Enterprise, hay tres tiempos de espera independientes que afectan el tiempo que el sistema espera a que Kubernetes informe una implementación estable:
Cloud Build tiene un tiempo de espera de 1 hora en las operaciones que realiza para Cloud Deploy.
Puedes cambiar este tiempo de espera en la configuración de tu entorno de ejecución.
Skaffold tiene un tiempo de espera de verificación de estado (
deploy.statusCheckDeadlineSeconds
), que es la cantidad de tiempo, en segundos, que se debe esperar para que se estabilicen las implementaciones.El valor predeterminado es 600 segundos (10 minutos). Para usar este tiempo de espera,
deploy.statusCheck
debe establecerse entrue
. De forma predeterminada, es así. SistatusCheck
esfalse
, no se realiza ninguna verificación de estado y el lanzamiento se marca como exitoso después de quekubectl apply
finaliza correctamente.En el caso de los recursos de Kubernetes de
kind: Deployment
, existeDeployment.spec.progressDeadlineSeconds
, que es la cantidad de tiempo que Kubernetes espera a que la Deployment se informe como estable.Este tiempo de espera solo se aplica a los recursos de
Deployment
. Así es como funcionan juntos estos dos primeros tiempos de espera:Si
Deployment.spec.progressDeadlineSeconds
, en Kubernetes, no está configurado, el tiempo de espera de la verificación de estado de Skaffold es el tiempo de espera efectivo, ya sea el predeterminado o el que se haya configurado de forma explícita.Si se configura
Deployment.spec.progressDeadlineSeconds
en Kubernetes, Skaffold ignora su propio tiempo de espera de verificación de estado, y el plazo de progreso de Kubernetes es el tiempo de espera efectivo. Sin embargo, si el tiempo de espera de Kubernetes se establece de forma explícita en600
(10 minutos), Skaffold supone que es el valor predeterminado (sin establecer) y lo ignora, y se usa el tiempo de espera de Skaffold (si se establece).Si no se establece ningún tiempo de espera, el tiempo de espera efectivo será el valor predeterminado de Skaffold de
600
(10 minutos).
Además de los
Deployment
, otros recursos de Kubernetes pueden tener tiempos de espera, que no influyen en el tiempo de espera de estabilidad. Si alguno de estos está presente, revísalos para asegurarte de que no entren en conflicto con el tiempo de espera de estabilidad.Si se agota el tiempo de espera de Skaffold (o Cloud Build), la implementación de GKE continúa ejecutándose. Cloud Deploy muestra una falla, pero aún puede tener éxito o fallar en el clúster de GKE.
Para cambiar el tiempo de espera de estabilidad de la implementación, haz lo siguiente:
Asegúrate de que
deploy.statusCheck
esté establecido entrue
enskaffold.yaml
.true
es la configuración predeterminada. Cuando se usatrue
, Skaffold espera a que las verificaciones de estado informen una implementación estable, sujeta al valor de tiempo de espera del siguiente paso.En
skaffold.yaml
, establecestatusCheckDeadlineSeconds
en la cantidad de segundos que deseas esperar.deploy: ... statusCheck: true statusCheckDeadlineSeconds: 600 ...
El valor predeterminado es
600
(10 minutos). Skaffold espera esta cantidad de tiempo para una implementación estable. Si se supera este tiempo antes de que la implementación sea estable, la implementación falla.De manera opcional, puedes agregar
tolerateFailuresUntilDeadline: true
después destatusCheckDeadlineSeconds
.Este parámetro de configuración le indica a Skaffold que no salga si falla una sola implementación, sino que tolere las fallas hasta que venza
statusCheckDeadlineSeconds
. Este parámetro de configuración puede ser útil en situaciones en las que tienes recursos que podrían necesitar más tiempo (hasta la fecha límite de la verificación de estado) para alcanzar un estado estable.Por ejemplo, si usas Istio o Cloud Service Mesh, es posible que tengas una implementación fallida con un mensaje similar a este:
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.
En tu manifiesto de Kubernetes, para los recursos de
kind: Deployment
, estableceDeployment.spec.progressDeadlineSeconds
en el mismo valor que estableciste parastatusCheckDeadlineSeconds
.
¿Qué sigue?
Obtén información para realizar implementaciones en GKE
Obtén información para realizar implementaciones en Cloud Run
Obtén más información para realizar implementaciones en GKE Enterprise
Obtén más información para crear tu canalización de entrega y tus destinos
Obtén más información para promocionar un lanzamiento.