Desplegar una aplicación

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.

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.

  1. Ejecuta tu proceso de integración continua (CI) habitual para crear el artefacto o los artefactos desplegables.

  2. 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 como rel-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 campo name 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 tu skaffold.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 tu skaffold.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.

  1. En la página Detalles de la cadena de lanzamiento, haga clic en Crear lanzamiento en la cadena de lanzamiento que quiera.

    Detalles del flujo de procesamiento de entrega, con el botón para crear una versión

  2. 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.

  3. En el campo Nombre de la versión, asigna un nombre único a esta versión o usa el nombre predeterminado.

  4. 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.

  5. Si quieres, puedes incluir una descripción de esta versión en el campo Descripción.

  6. 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.

  7. Haz clic en Crear.

    Cuadro de diálogo para crear una versión

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 valor true. De forma predeterminada, es así. Si statusCheck es false, no se comprueba el estado y el lanzamiento se marca como correcto después de que kubectl apply se complete correctamente.

  • En el caso de los recursos de Kubernetes de kind: Deployment, existe Deployment.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 como 600 (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 Deployments, 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:

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

    El valor predeterminado es true. Cuando true, Skaffold espera a que las comprobaciones de estado informen de un despliegue estable, sujeto al valor de tiempo de espera del siguiente paso.

  2. En skaffold.yaml, asigna a statusCheckDeadlineSeconds 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á.

  3. Opcionalmente, puedes añadir tolerateFailuresUntilDeadline: true después de statusCheckDeadlineSeconds.

    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.
    
  4. En el manifiesto de Kubernetes, para los recursos de kind: Deployment, asigna a Deployment.spec.progressDeadlineSeconds el mismo valor que a statusCheckDeadlineSeconds.

Siguientes pasos