En esta página, se describe cómo usar Cloud Deploy para obtener tu aplicación en los entornos de ejecución de destino previstos. Antes de hacer esto, debes crear tu canalización de entrega y destinos
Antes de comenzar
En esta sección, se describen los elementos que debes tener antes de poder 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 tu canalización de entrega y destinos.
Cloud Deploy puede implementarse en Google Kubernetes Engine, Cloud Run, y clústeres de GKE Enterprise. La configuración de destino es diferente dependiendo de cuál sea la ubicación en la que realices la implementación.
Tener tus imágenes y manifiestos de contenedores
Necesitas una o más imágenes de contenedor para implementar, y una o más imágenes de contenedor manifiestos (para implementar en GKE) o archivos YAML de servicio (para implementar a Cloud Run).
Necesitas una canalización de integración continua o algún otro proceso para compilar y ubica 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.
Ten 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 estas dos maneras:Crea uno propio.
Ten en cuenta que el archivo
skaffold.yaml
debe hacer referencia al espacio de nombres Corresponde a una versión compatible de Skaffold en la primera línea, como en este ejemplo:`apiVersion: skaffold/v4beta7`
Generada por ti.
Si aún no tienes un archivo
skaffold.yaml
, puedes haz que Cloud Deploy cree uno por ti. Este archivo es adecuado para la integración, el aprendizaje o la demostración de Cloud Deploy, y no debe usarse para cargas de trabajo de producción.
Consulta Usa Skaffold con Cloud Deploy para obtener más información. Además, Administra manifiestos en Cloud Deploy tiene más detalles sobre el uso de Skaffold y Cloud Deploy con 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 las siguientes opciones entornos de ejecución:
Invoca tu canalización de entrega para crear una versión
Después de configurar Cloud Deploy para que se implemente en tu entorno de ejecución, ahora 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 y crea el recurso implementable artefacto o artefactos.
Para iniciar la canalización de entrega, llama 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
Dado que este comando crea un archivo tar de todo el contenido de la directorio y subdirectorio, es posible que no quieras ejecutar este comando desde tu directorio principal o raíz. Ejecuta el comando desde el directorio con tu configuración de Skaffold o incluir 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 El nombre debe ser único entre todas las versiones de esta canalización de entrega.Para especificar nombres de versiones dinámicos, incluye
'$DATE'
o'$TIME'
. ambos. Por ejemplo, si invocas este comando a las 3:07 p.m. UTC,'rel-$TIME'
se resuelve enrel-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 de la canalización de entrega. que administrará la implementación de esta versión objetivos. 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 te encuentras. que crea la versión, por ejemplo,us-central1
. Este campo es obligatorio.
Este comando sube un archivo tar que contiene tus archivos de configuración a un bucket de Cloud Storage bucket y crea la versión. Cloud Deploy también habilita automáticamente crea un lanzamiento e implementa tu imagen en el primer destino definido en el canalización de entrega continua.
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>
Una colección de nombres de imágenes para reemplazos de la ruta completa de imágenes.
--build-artifacts=<path/file>
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 usar Cloud Deploy
Genera un archivo skaffold.yaml
por ti:
--from-k8s-manifest=K8S_MANIFEST
La configuración generada de Skaffold se basa en el manifiesto de Kubernetes que pasaste esta marca. Usa esta marca con la marca
--skaffold-file
o--source
, genera un error. Consulta Generando tuskaffold.yaml
para obtener más información.--from-run-manifest=RUN_MANIFEST
La configuración generada de Skaffold se basa en la API de Cloud Run de servicio YAML, pasas esta marca. Si usas esta marca con la marca
--skaffold-file
o--source
, se genera un error. Consulta Generando tuskaffold.yaml
para obtener más información.
Estas dos opciones son mutuamente excluyentes.
También puedes incluir un archivo .gcloudignore
si hay algún archivo en el
que no deseas 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 de entrega en una canalización de integración continua. 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 sentado que ya creaste una canalización de entrega y uno o más objetivos. También puedes usar la consola de Google Cloud para crear tu canalización de entrega).
Desde la página Detalles de la canalización de entrega para una entrega específica haz clic en Crear versión.
En el campo Choose a container, pega o escribe la ruta de acceso a la imagen del contenedor que deseas implementar. También puedes usar el contenedor predeterminado prepropagado en este campo con fines de evaluación.
También puedes hacer clic en Seleccionar para elegir una imagen de contenedor de Artifact Registry. o Container Registry.
Proporciona un nombre único para esta versión en el campo Nombre de la versión, o bien usa el nombre predeterminado proporcionado.
Proporciona un nombre para el lanzamiento en el campo Nombre del lanzamiento, o bien usa el el nombre predeterminado que se proporciona.
Este nombre se usa para el lanzamiento en el primer destino de esta versión. Para destinos, puedes asignar un nombre al lanzamiento en el diálogo Promover o en el comando
gcloud deploy releases promote
De manera opcional, puedes incluir una descripción de esta versión en la Descripción. .
En Detalles de la implementación, ingresa un nombre para tu GKE. Deployment o Service de Cloud Run, o usar el nombre predeterminado que se proporcionan.
Para GKE, Cloud Deploy genera el manifiesto ti. Para Cloud Run, Cloud Deploy genera el del 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, y el skaffold.yaml
generado, para crear la versión.
Cambia el tiempo de espera de la implementación
Para implementaciones en GKE y en el destino de GKE Enterprise hay tres tiempos de espera separados que afectan 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 la verificación de estado (
deploy.statusCheckDeadlineSeconds
), que es la cantidad de tiempo, en segundos, que se debe esperar para que las implementaciones se estabilicen.El valor predeterminado es 600 segundos (10 minutos). Para usar este tiempo de espera,
deploy.statusCheck
debe configurarse comotrue
. De forma predeterminada, lo es. SistatusCheck
esfalse
, hay no tiene verificación de estado, el lanzamiento se marca como exitoso después delkubectl apply
finaliza correctamente.Para los recursos de Kubernetes de
kind: Deployment
, hayDeployment.spec.progressDeadlineSeconds
, que es la cantidad de tiempo que Kubernetes espera que el objeto Deployment informe como sea estable.Este tiempo de espera solo se aplica a
Deployment
recursos. A continuación, te mostramos cómo estos los dos primeros tiempos de espera funcionan juntos:Si no se establece
Deployment.spec.progressDeadlineSeconds
en Kubernetes, el tiempo de espera de la verificación de estado de Skaffold es el tiempo de espera efectivo, ya sea el predeterminado o el establecido de forma explícita.Si se configura
Deployment.spec.progressDeadlineSeconds
en Kubernetes, entonces Skaffold ignora su propio tiempo de espera de verificación de estado y el progreso de Kubernetes la fecha límite es el tiempo de espera efectivo. Sin embargo, si el tiempo de espera de Kubernetes establecido de forma explícita en600
(10 minutos), entonces Skaffold supone que es el default (unset) y lo ignora, y se usa el tiempo de espera de Skaffold (si está configurado).Si no se establece ninguno, el tiempo de espera efectivo corresponde a Skaffold el valor predeterminado es
600
(10 minutos).
Además de los
Deployment
s, otros recursos de Kubernetes pueden tener tiempos de espera, lo que no influyen en el tiempo de espera de estabilidad. Si se encuentra alguna de ellas, revisa para garantizar que no entren en conflicto con el tiempo de espera de estabilidad.Si se agota el tiempo de espera de Skaffold (o Cloud Build), GKE del objeto Deployment a seguir ejecutándose. Cloud Deploy muestra una falla, pero 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
se establece entrue
enskaffold.yaml
.true
es la configuración predeterminada. Cuando seatrue
, Skaffold espera a que las verificaciones de estado informar una implementación estable, sujeta al valor del tiempo de espera en el siguiente paso.En
skaffold.yaml
, establecestatusCheckDeadlineSeconds
a la cantidad de segundos que quieres esperar.deploy: ... statusCheck: true statusCheckDeadlineSeconds: 600 ...
El valor predeterminado es
600
(10 minutos). Skaffold espera esta cantidad de tiempo durante un implementación estable. Si se excede este tiempo antes de que la implementación sea estable, esta falla.De manera opcional, puedes agregar
tolerateFailuresUntilDeadline: true
después delstatusCheckDeadlineSeconds
Este parámetro le indica a Skaffold que no se cierre si falla una sola implementación, pero que tolera fallas hasta que venza el
statusCheckDeadlineSeconds
. Este parámetro de configuración Puede ser de ayuda en situaciones en las que tiene recursos que tal vez necesiten 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 un Falló la implementación 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.
Este parámetro de configuración solo funciona con Skaffold 2.0 o versiones posteriores.
En tu manifiesto de Kubernetes, establece lo siguiente para los recursos de
kind: Deployment
:Deployment.spec.progressDeadlineSeconds
al mismo valor que estableciste parastatusCheckDeadlineSeconds
¿Qué sigue?
Obtén más información sobre la implementación en GKE.
Obtén más información sobre la implementación en Cloud Run.
Obtén información para implementar en GKE Enterprise
Obtén información para promocionar un lanzamiento.