Implementa tu aplicación

En esta página, se describe cómo usar Cloud Deploy para llevar tu aplicación a 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 pasos que debes implementar antes de implementar tu aplicación con Cloud Deploy.

  • Asegúrate de que tu cuenta de servicio de ejecución tenga los permisos y roles de IAM necesarios.

  • Crea tu canalización de entrega y destinos.

    Cloud Deploy puede implementarse en clústeres de Google Kubernetes Engine, Cloud Run y GKE Enterprise. La configuración de destino difiere según a cuál de estos se realice la implementación.

  • Ten las imágenes y los manifiestos de tu 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 otro elemento 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 a skaffold apply para implementarlos en tu destino. Para ello, Skaffold requiere al menos un skaffold.yaml mínimo. Puedes obtener uno de dos maneras:

    • Crea una propia.

      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`

    • Haz que se genere por ti.

      Si aún no tienes un archivo skaffold.yaml, puedes hacer que Cloud Deploy cree uno. 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 detalles. Además, en el artículo Administra manifiestos en Cloud Deploy, encontrarás más detalles sobre el uso de Skaffold y Cloud Deploy con herramientas de administración de manifiestos, como Helm, Kustomize y kpt.

Configura Cloud Deploy en el entorno de ejecución que desees

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 se implemente en tu entorno de ejecución, puedes enviar tu aplicación de acuerdo con la canalización de entrega que creaste.

  1. Ejecuta tu proceso de integración continua (CI) normal y crea el artefacto o los artefactos implementables.

  2. A fin de 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

    Debido a que este comando crea un archivo tar de todo el contenido del directorio y de los subdirectorios, es posible que no quieras ejecutar este comando 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 asignará a esta versión. El nombre debe ser único entre todas las versiones de esta canalización de entrega.

    Para especificar nombres de versiones dinámicos, incluye '$DATE', '$TIME' o ambos. Por ejemplo, si invocas este comando a las 3:07 p.m. UTC, 'rel-$TIME' se resuelve como rel-1507. '$DATE' y '$TIME' deben estar entre comillas simples, y la hora es 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 del progreso de los objetivos. Este nombre debe coincidir con el campo name en la definición de la canalización.

    REGION es el nombre de la región en la que estás creando 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 y crea la versión. Cloud Deploy también crea automáticamente un lanzamiento 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>

    Una colección de nombres de imágenes para reemplazar 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 rutas de acceso completas 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:

Estas dos opciones son mutuamente excluyentes.

También puedes incluir un archivo .gcloudignore si hay algún archivo en el directorio que no quieras que se incluya en el archivo tar.

Crea una versión desde la consola de Google Cloud

Puedes usar la consola de Google Cloud si quieres 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 da por sentado 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.

  1. En la página Detalles de la canalización de entrega, para una canalización de entrega específica, haz clic en Crear versión.

    detalles de la canalización de entrega, que muestra el botón Crear versión

  2. 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 propagado previamente en este campo para la evaluación.

    También puedes hacer clic en Seleccionar para elegir una imagen de contenedor de Artifact Registry o Container Registry.

  3. Proporciona un nombre único para esta versión en el campo Nombre de la versión o usa el nombre predeterminado proporcionado.

  4. Proporciona un nombre para el lanzamiento en el campo Nombre del lanzamiento o usa el nombre predeterminado que se proporcionó.

    Este nombre se usa para el lanzamiento en el primer destino de esta versión. Para los destinos posteriores, puedes asignar un nombre al lanzamiento en el diálogo Promote o en el comando gcloud deploy releases promote.

  5. De manera opcional, puedes incluir una descripción de esta versión en el campo Descripción.

  6. En Detalles de implementación, ingresa un nombre para tu implementación de GKE o servicio de Cloud Run, o usa el nombre predeterminado proporcionado.

    En GKE, Cloud Deploy genera el manifiesto por ti. Para Cloud Run, Cloud Deploy genera la definición del servicio, que se usa para crearlo.

  7. Haz clic en Crear.

    Diálogo Crear versión

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.

Cambia el tiempo de espera de la implementación

Para las implementaciones en clústeres de destino de GKE y GKE Enterprise, existen tres tiempos de espera distintos que afectan el tiempo que espera el sistema para 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 a que las implementaciones se estabilicen.

    El valor predeterminado es 600 segundos (10 minutos). Para usar este tiempo de espera, deploy.statusCheck debe configurarse como true. De forma predeterminada, lo es. Si statusCheck es false, no hay verificación de estado, el lanzamiento se marca como exitoso después de que kubectl apply finaliza correctamente.

  • Para los recursos de Kubernetes de kind: Deployment, existe Deployment.spec.progressDeadlineSeconds, que es la cantidad de tiempo que Kubernetes espera a que el objeto Deployment informe como estable.

    Este tiempo de espera solo se aplica a los recursos de Deployment. A continuación, se muestra cómo estos dos primeros tiempos de espera funcionan juntos:

    • Si no se configura 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, Skaffold ignora su propio tiempo de espera de la verificación de estado y el plazo del progreso de Kubernetes es el tiempo de espera efectivo. Sin embargo, si el tiempo de espera de Kubernetes se configura explícitamente como 600 (10 minutos), Skaffold supone que es el predeterminado (sin configurar) y lo ignora, y se usa el tiempo de espera de Skaffold (si se configuró).

    • Si no se configura ningún tiempo de espera, el tiempo de espera efectivo es el 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 hay alguna de ellas, revísala para asegurarte de que no entre 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 tener éxito o fallar en el clúster de GKE.

Para cambiar el tiempo de espera de estabilidad de tu implementación, haz lo siguiente:

  1. Asegúrate de que deploy.statusCheck esté configurado como true en skaffold.yaml.

    true es la configuración predeterminada. Cuando es true, Skaffold espera a que las verificaciones de estado informen una implementación estable, sujeto al valor de tiempo de espera en el siguiente paso.

  2. En skaffold.yaml, establece statusCheckDeadlineSeconds 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 ese tiempo antes de que la implementación se mantenga estable, la implementación fallará.

  3. De manera opcional, puedes agregar tolerateFailuresUntilDeadline: true después de statusCheckDeadlineSeconds.

    Esta configuración le indica a Skaffold que no se cierre si falla una sola implementación, sino que debe tolerar fallas hasta que venza statusCheckDeadlineSeconds. Esta 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 verificación de estado) para alcanzar un estado estable.

    Por ejemplo, si usas Istio o Anthos 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.

    La configuración solo funciona con Skaffold 2.0 o versiones posteriores.

  4. En tu manifiesto de Kubernetes, para los recursos de kind: Deployment, configura Deployment.spec.progressDeadlineSeconds con el mismo valor que configuraste para statusCheckDeadlineSeconds.

¿Qué sigue?