En esta página se describe cómo usar Cloud Deploy para transferir tu aplicación a los entornos de ejecución de destino que quieras. Antes de hacerlo, debe crear su canal de distribución y sus destinos.
Antes de empezar
En esta sección se describen los requisitos que debes cumplir para poder desplegar tu aplicación con Cloud Deploy.
Asegúrate de que tu cuenta de servicio de ejecución tenga los roles y permisos de gestión de identidades y accesos necesarios.
Crea tu flujo de procesamiento de entrega y tus objetivos.
Cloud Deploy puede desplegarse en clústeres de Google Kubernetes Engine, Cloud Run y GKE Enterprise. La configuración de destino varía en función de dónde se implemente.
Tener tus imágenes y manifiestos de contenedor.
Necesitas una o varias imágenes de contenedor para desplegar y uno o varios manifiestos de Kubernetes (para desplegar en GKE) o archivos YAML de servicio (para desplegar en Cloud Run).
Necesitas una canalización de integración continua u otro proceso para compilar y colocar tus imágenes. Tu herramienta de integración continua puede ser Cloud Build, Jenkins o cualquier otra que genere imágenes de contenedor que puedas proporcionar a tu flujo de trabajo de lanzamiento de Cloud Deploy.
Tener un archivo de configuración
skaffold.yaml
.Cloud Deploy llama a
skaffold render
para renderizar los archivos de manifiesto de Kubernetes con este archivo y askaffold apply
para desplegarlos en tu destino. Para ello, Skaffold requiere al menos unskaffold.yaml
mínimo. Puedes obtener uno de dos formas:Crea el tuyo.
Ten en cuenta que el archivo
skaffold.yaml
debe hacer referencia al espacio de nombres correspondiente a una versión de Skaffold compatible en la primera línea, como en este ejemplo:`apiVersion: skaffold/v4beta7`
Generarla por ti.
Si aún no tienes un archivo
skaffold.yaml
, puedes pedirle a Cloud Deploy que cree uno por ti. Este archivo es adecuado para la incorporación, el aprendizaje o la demostración de Cloud Deploy, y no debe usarse para cargas de trabajo de producción.
Consulta más información en el artículo Usar Skaffold con Cloud Deploy. En el artículo Gestionar archivos de manifiesto en Cloud Deploy, se explica con más detalle cómo usar Skaffold y Cloud Deploy con herramientas de gestión de archivos de manifiesto, como Helm, Kustomize y kpt.
Configurar Cloud Deploy para el entorno de ejecución que elijas
Cloud Deploy puede desplegar tu aplicación en cualquiera de los siguientes entornos de ejecución:
Invocar el flujo de procesamiento de entrega para crear una versión
Una vez que hayas configurado Cloud Deploy para que se despliegue en tu tiempo de ejecución, podrás enviar tu aplicación para que se despliegue según la canalización de entrega que hayas creado.
Ejecuta tu proceso de integración continua (CI) habitual para crear el artefacto o los artefactos desplegables.
Inicia el flujo de procesamiento de entrega llamando a Cloud Deploy para crear una versión.
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 con 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:
RELEASE_NAME
es el nombre que se le asigna a esta versión. El nombre debe ser único entre todas las versiones de este flujo de lanzamiento.Puedes especificar nombres de lanzamiento dinámicos incluyendo
'$DATE'
o'$TIME'
o ambos. Por ejemplo, si invocas este comando a las 15:07 (UTC),'rel-$TIME'
se resuelve comorel-1507
.'$DATE'
y'$TIME'
deben estar entre comillas simples, y la hora es la hora UTC de la máquina en la que invocas el comando.PIPELINE_NAME
es el nombre del flujo de procesamiento de entrega que gestionará la implementación de esta versión a lo largo de la progresión de los destinos. Este nombre debe coincidir con el camponame
de la definición de la canalización.REGION
es el nombre de la región en la que vas a crear la versión (por ejemplo,us-central1
). Este campo es obligatorio.
Este comando sube un archivo tar que contiene tus configuraciones a un segmento de Cloud Storage y crea la versión. Cloud Deploy también crea automáticamente un lanzamiento e implementa la 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>
Colección de sustituciones de nombres de imágenes por rutas completas de imágenes.
--build-artifacts=<path/file>
Referencia a un archivo de salida de artefactos de compilación de Skaffold, que se puede transferir para representar las sustituciones de la ruta completa de la imagen.
Estas dos opciones se excluyen mutuamente.
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 pases a esta marca. Si se usa esta marca con la marca
--skaffold-file
o con la marca--source
, se genera un error. Consulta más información sobre cómo generar tuskaffold.yaml
.--from-run-manifest=RUN_MANIFEST
La configuración de Skaffold generada se basa en el archivo YAML del servicio de Cloud Run que le transfieras a esta marca. Si se usa esta marca con la marca
--skaffold-file
o con la marca--source
, se genera un error. Consulta más información sobre cómo generar tuskaffold.yaml
.
Estas dos opciones se excluyen mutuamente.
También puedes incluir un archivo .gcloudignore
si hay archivos en el directorio que no quieras incluir en el archivo tar.
Crear una versión desde la Google Cloud consola
Puedes usar la Google Cloud consola para crear una versión de una canalización de distribución. Esto es útil para probar Cloud Deploy, pero no es adecuado para cargas de trabajo de producción.
En el siguiente procedimiento se da por hecho que ya has creado una canalización de entrega y uno o varios destinos. También puedes usar la Google Cloud consola para crear tu canal de distribución.
En la página Detalles de la cadena de lanzamiento, haga clic en Crear lanzamiento en la cadena de lanzamiento que quiera.
En el campo Elige un contenedor, pega o escribe la ruta de la imagen del contenedor que quieras desplegar. También puedes usar el contenedor predeterminado que se rellena automáticamente en este campo para hacer una evaluación.
También puedes hacer clic en Seleccionar para elegir una imagen de contenedor de Artifact Registry.
En el campo Nombre de la versión, asigna un nombre único a esta versión o usa el nombre predeterminado.
Indique un nombre para el lanzamiento en el campo Nombre del lanzamiento o use el nombre predeterminado.
Este nombre se usa para la implementación en el primer destino de esta versión. En el caso de los objetivos posteriores, puedes asignar un nombre al lanzamiento en el cuadro de diálogo Promocionar o en el comando
gcloud deploy releases promote
.Si quieres, puedes incluir una descripción de esta versión en el campo Descripción.
En Deployment details (Detalles del despliegue), introduce un nombre para tu despliegue de GKE o tu servicio de Cloud Run, o usa el nombre predeterminado.
En el caso de GKE, Cloud Deploy genera el manifiesto automáticamente. En Cloud Run, Cloud Deploy genera la definición de servicio, que se usa para crear el servicio.
Haz clic en Crear.
Cloud Deploy usa el manifiesto generado o la definición de servicio de Cloud Run, así como el skaffold.yaml
generado, para crear la versión.
Cambiar el tiempo de espera del despliegue
En las implementaciones en clústeres de destino de GKE y GKE Enterprise, hay tres tiempos de espera independientes que afectan al tiempo que espera el sistema a que Kubernetes informe de 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 comprobación de estado (
deploy.statusCheckDeadlineSeconds
), que es el tiempo, en segundos, que se espera a que las implementaciones se estabilicen.El valor predeterminado es 600 segundos (10 minutos). Para usar este tiempo de espera,
deploy.statusCheck
debe tener el valortrue
. De forma predeterminada, es así. SistatusCheck
esfalse
, no se comprueba el estado y el lanzamiento se marca como correcto después de quekubectl apply
se complete correctamente.En el caso de los recursos de Kubernetes de
kind: Deployment
, existeDeployment.spec.progressDeadlineSeconds
, que es el tiempo que espera Kubernetes a que la implementación se considere estable.Este tiempo de espera solo se aplica a los recursos de
Deployment
. A continuación, te explicamos cómo funcionan estos dos primeros tiempos de espera:Si
Deployment.spec.progressDeadlineSeconds
en Kubernetes no está definido, el tiempo de espera de comprobación del estado de Skaffold será el tiempo de espera efectivo, ya sea el predeterminado o el que se haya definido explícitamente.Si se define
Deployment.spec.progressDeadlineSeconds
en Kubernetes, Skaffold ignora su propio tiempo de espera de comprobación del estado y el tiempo de espera efectivo es el tiempo límite de progreso de Kubernetes. Sin embargo, si el tiempo de espera de Kubernetes se define explícitamente como600
(10 minutos), Skaffold asume que es el valor predeterminado (sin definir) y lo ignora, y se usa el tiempo de espera de Skaffold (si se ha definido).Si no se define ningún tiempo de espera, el tiempo de espera efectivo será el valor predeterminado de Skaffold
600
(10 minutos).
Además de los
Deployment
s, otros recursos de Kubernetes pueden tener tiempos de espera, que no influyen en el tiempo de espera de estabilidad. Si se da alguno de estos casos, 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 sigue ejecutándose. Cloud Deploy muestra un error, pero puede seguir funcionando o fallar en el clúster de GKE.
Para cambiar el tiempo de espera de la estabilidad de la implementación, sigue estos pasos:
Asegúrate de que
deploy.statusCheck
esté configurado comotrue
enskaffold.yaml
.El valor predeterminado es
true
. Cuandotrue
, Skaffold espera a que las comprobaciones de estado informen de un despliegue estable, sujeto al valor de tiempo de espera del siguiente paso.En
skaffold.yaml
, asigna astatusCheckDeadlineSeconds
el número de segundos que quieras esperar.deploy: ... statusCheck: true statusCheckDeadlineSeconds: 600 ...
El valor predeterminado es
600
(10 minutos). Skaffold espera este tiempo para que el despliegue sea estable. Si se supera este tiempo antes de que el despliegue sea estable, el despliegue fallará.Opcionalmente, puedes añadir
tolerateFailuresUntilDeadline: true
después destatusCheckDeadlineSeconds
.Este ajuste indica a Skaffold que no se cierre si falla una sola implementación, sino que tolere los errores hasta que expire
statusCheckDeadlineSeconds
. Esta opción puede ser útil en situaciones en las que tengas recursos que necesiten más tiempo (hasta la fecha límite de la comprobación de estado) para alcanzar un estado estable.Por ejemplo, si usas Istio o Cloud Service Mesh, es posible que se produzca un error en la implementación y que aparezca 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 el manifiesto de Kubernetes, para los recursos de
kind: Deployment
, asigna aDeployment.spec.progressDeadlineSeconds
el mismo valor que astatusCheckDeadlineSeconds
.
Siguientes pasos
Consulta información sobre cómo desplegar en GKE.
Consulta información sobre cómo desplegar en Cloud Run.
Consulta información sobre cómo desplegar en GKE Enterprise.
Consulte cómo crear su canal de distribución y sus objetivos.
Consulta cómo promocionar un lanzamiento.