Una implementación de Cloud Deploy incluye fases. Una fase es una estructura ordenada, o agrupamiento de trabajos para hacer en un lanzamiento.
Cada fase incluye trabajos, que son las acciones que se deben realizar en cada fase (por
Por ejemplo, deploy
o verify
). Y cada trabajo puede tener cero o más ejecuciones.
La ejecución de un trabajo es una instancia de un trabajo. Si el trabajo no se ejecutó, no hay ejecuciones de trabajo.
En este documento, se describen las fases, trabajos y ejecución de trabajos y cómo administrarlas.
Estructura de un lanzamiento
Un lanzamiento es un recurso de Cloud Deploy que asocia un release con un objetivo.
Fases
Un lanzamiento consta de una o más fases.
Para una estrategia de implementación estándar,
es solo una fase: stable
.
Para una estrategia de implementación de versiones canary, Hay una fase separada para cada porcentaje configurado. Por ejemplo, si configura una versión canary que implementa el 25%, el 50% y, luego el 100%, habrá tres fases:
canary-25
canary-50
stable
Estos nombres de fase son estándar: canary-[PERCENTAGE]
para etapas canary y
stable
para la fase del 100%. Sin embargo, si configuras un
manual o
canary personalizados,
controlar los nombres de las fases.
Trabajos y ejecuciones de trabajos
Cada fase de lanzamiento incluye uno o más trabajos.
Para un lanzamiento en una implementación estándar
de implementación sin la verificación de implementación habilitada, hay una fase
(stable
).
En el caso del lanzamiento de versiones canary, habrá una fase para cada parte
(por ejemplo, canary-25
, canary-50
, stable
) y, para cada fase, hay un
Trabajo deploy
. Si la verificación está habilitada, también hay un trabajo verify
para cada fase.
La ejecución de un trabajo es una instancia de un trabajo. Por ejemplo, si se ejecuta un trabajo para un trabajo deploy
, se considera lo siguiente:
y, si tiene éxito, no hay más ejecuciones de trabajos para ese trabajo. Si falla, se puede reintentar como otra ejecución de trabajo.
Cómo omitir fases la primera vez
Algunas estrategias de implementación (por ejemplo, versiones canary) distribuyen el tráfico entre versiones nuevas y anteriores. Si es la primera vez que implementas en un destino porque no hay una versión antigua, por lo que no podemos distribuir el tráfico.
Por este motivo, cuando implementas una versión canary por primera vez, omitimos las fases de la versión canary y ejecutamos la fase stable
. Después de eso, la aplicación
implementadas, y las implementaciones de versiones canary futuras incluirán las fases de versiones canary.
En una situación real, por lo general, ejecutará una implementación de versiones canary en la que Tu aplicación ya se está ejecutando, por lo que la omisión de esta fase será poco frecuente.
Estados dentro de un lanzamiento
Los lanzamientos, las fases, los trabajos y las ejecuciones de trabajos tienen estados. En esta sección, se describen las estados para cada una.
Estados de lanzamiento
Un lanzamiento tendrá uno de los siguientes estados:
APPROVAL_REJECTED
El lanzamiento requería la aprobación pero se rechazó la aprobación.
CANCELLED
El estado terminal para los lanzamientos que canceló de un usuario.
CANCELLING
Un usuario canceló el lanzamiento, pero la cancelación no finalizó el procesamiento de datos.
HALTED
En una implementación en paralelo, si uno o más lanzamientos secundarios fallan, pero al menos uno se realiza correctamente, el lanzamiento del controlador se DETIENE si hay más fases después de la actual.
Para reanudar un lanzamiento detenido de un controlador, haz lo siguiente:
Cancela el lanzamiento del control
Vuelve a intentar o ignora los trabajos con errores en los lanzamientos secundarios
IN_PROGRESS
Se está procesando la ejecución de un trabajo.
FAILED
Un trabajo falló y el usuario no eligió ignorar la falla.
PENDING
No se comenzó a procesar el lanzamiento. Este estado pasa a
IN_PROGRESS
oCANCELED
.PENDING_APPROVAL
El lanzamiento requiere aprobación, pero aún no se aprobó.
PENDING_RELEASE
El lanzamiento está esperando a que se renderice la versión.
SUCCEEDED
El lanzamiento finalizó sin errores.
Estados de fase
Una fase tendrá uno de los siguientes estados:
PENDING
La fase está esperando que termine otra fase del lanzamiento.
IN_PROGRESS
Comenzó la fase.
SUCCEEDED
La fase se completó correctamente.
FAILED
Se produjo un error en un trabajo de la fase, y el usuario no optó por ignorar la falla.
ABORTED
Se produjo un error en una fase anterior.
SKIPPED
Cuando ejecutas una estrategia de implementación, como canary, Cloud Deploy se pasa a la fase
stable
en los casos en los que aún no hay una versión en ejecución de la aplicación con la que dividir el tráfico. En este caso, el estado es se establece enSKIPPED
.
Estados del trabajo
Un trabajo tendrá uno de los siguientes estados:
ABORTED
Si una fase falla, las fases posteriores se anulan.
Si un trabajo falla y esa falla no se ignora, se abortan los trabajos posteriores. Por ejemplo, si una fase incluye un trabajo de implementación y un el trabajo de implementación y el trabajo de implementación falla, el trabajo de verificación se anula.
DISABLED
Es posible que algunos trabajos de una fase estén inhabilitados. Por ejemplo, las fases siempre incluyen verificar trabajos, ya sea que la verificación sea o no habilitado. Si la verificación no está habilitada, el trabajo de verificación se establece en
DISABLED
FAILED
Se produjo un error en la ejecución de este trabajo, por lo que el usuario no optó por hacerlo ignorar la falla.
El usuario decidió finalizar la ejecución del trabajo para este trabajo.
IGNORED
Una ejecución de trabajo falló, y el usuario eligió ignorar la falla.
IN_PROGRESS
Se está ejecutando un trabajo para este trabajo.
PENDING
El trabajo ejecutado para este trabajo está esperando para comenzar, porque otra fase o trabajo aún no ha terminado.
SKIPPED
Cuando ejecutas una estrategia de implementación, como canary, Cloud Deploy se pasa a la fase
stable
en los casos en los que aún no hay una versión en ejecución de la aplicación con la que dividir el tráfico. En este caso, el estado se establece enSKIPPED
en los trabajos dentro de la fase o fases omitidas.SUCCEEDED
La ejecución del trabajo finalizó correctamente y comenzó el siguiente trabajo de la fase, o que la siguiente fase haya comenzado o esté lista para comenzar (posiblemente, las actualizaciones de usuario entrada), o el lanzamiento finalizó.
Estados de ejecución del trabajo
FAILED
La ejecución del trabajo falló durante la ejecución.
IN_PROGRESS
La ejecución del trabajo comenzó, pero no finalizó.
TERMINATED
El usuario finalizó la ejecución del trabajo.
TERMINATING
El usuario finalizó la ejecución del trabajo, pero no finalizó. finalizando aún.
SUCCEEDED
Cuando la ejecución de un trabajo finaliza correctamente, sin fallar ni ser finalizada un usuario, se pone en un estado
SUCCEEDED
, lo que
Administra tu lanzamiento
Con la consola de Google Cloud o el SDK de Google Cloud, puedes hacer lo siguiente: siguiente con un lanzamiento de Cloud Deploy:
Si usas la implementación paralela con una estrategia de implementación de versiones canary, consulta este documento.
Cómo adelantar un lanzamiento
En el caso de los objetivos configurados para utilizar una estrategia de implementación distinta de la “estándar”, tú necesitas hacer que el lanzamiento avance de fase a fase.
Por ejemplo, si tienes un destino configurado para realizar una implementación de versiones canary sencilla
solo para las fases de 50% y stable
(100%), deberías avanzar en el lanzamiento.
una vez, desde la fase canary-50
hasta la fase stable
(100%).
gcloud
gcloud deploy rollouts advance ROLLOUT_NAME \
--release=RELEASE_NAME \
--delivery-pipeline=PIPELINE_NAME \
--region=REGION
Aquí:
ROLLOUT_NAME
es el nombre del lanzamiento actual
el cual pasarás a la siguiente fase.
RELEASE_NAME
es el nombre de la versión que esta
el lanzamiento.
PIPELINE_NAME
es el nombre de la canalización de entrega que usas para administrar la implementación de esta versión.
REGION
es el nombre de la región en la que
versión, por ejemplo, us-central1
. Este campo es obligatorio.
Consulta la referencia del SDK de Google Cloud para obtener más información sobre el
Comando gcloud deploy rollouts advance
Console
Haz clic en tu canalización que se muestra en la lista de canalizaciones de publicación.
En la página Detalles de la canalización de entrega, se muestra una representación gráfica de el progreso de tu canalización de entrega.
En la pestaña Lanzamientos, en Detalles de la canalización de entrega, haz clic en el nombre del lanzamiento.
Se muestra la página de detalles del lanzamiento para ese lanzamiento.
Observa que, en este ejemplo, el lanzamiento tiene una fase
canary-50
y una fasestable
. Tu lanzamiento puede tener más fases o diferentes fases.Haz clic en Lanzamiento avanzado.
El lanzamiento avanza a la siguiente fase.
Cancela un lanzamiento
Puedes cancelar cualquier lanzamiento que no haya finalizado. También puedes cancelar una solicitud el lanzamiento para evitar que se realicen más acciones (como ignorarlo o reintentarlo). El lanzamiento Debe tener uno de los siguientes estados:
FAILED
HALTED
IN_PROGRESS
PENDING
PENDING_APPROVAL
PENDING_RELEASE
Después de cancelar un lanzamiento, este estará en un estado CANCELLING
hasta que
se completaron las ejecuciones de trabajos pendientes. Puedes terminar
ejecuciones de trabajos pendientes que no quieres esperar. Una vez que el lanzamiento sea CANCELLED
, ya no se podrá avanzar ni modificar.
Para cancelar un lanzamiento, haz lo siguiente:
gcloud
gcloud deploy rollouts cancel ROLLOUT_NAME \
--release=RELEASE_NAME \
--delivery-pipeline=PIPELINE_NAME \
--region=REGION
Aquí:
ROLLOUT_NAME
es el nombre del lanzamiento actual
el cual pasarás a la siguiente fase.
RELEASE_NAME
es el nombre de la versión que esta
el lanzamiento.
PIPELINE_NAME
es el nombre de la canalización de entrega que usas para administrar la implementación de esta versión.
REGION
es el nombre de la región en la que
versión, por ejemplo, us-central1
. Este campo es obligatorio.
Consulta la referencia del SDK de Google Cloud para obtener más información sobre el
Comando gcloud deploy rollouts cancel
Console
Haz clic en la canalización que se muestra en la lista de canalizaciones de entrega.
En la página Detalles de la canalización de entrega, se muestra una representación gráfica de el progreso de tu canalización de entrega.
En la pestaña Lanzamientos, en Detalles de la canalización de entrega, haz clic en el nombre del lanzamiento.
Se muestra la página de detalles del lanzamiento para ese lanzamiento.
Observa que, en este ejemplo, el lanzamiento tiene una fase
canary-50
y una Fasestable
: Tu lanzamiento puede tener más fases o diferentes fases.Haz clic en Cancelar lanzamiento.
Se canceló el lanzamiento.
Finaliza la ejecución de un trabajo
Puedes finalizar una ejecución de trabajo que esté en curso. Es posible que quieras hacer esto,
por ejemplo, si la ejecución de un trabajo parece tardar demasiado o no funciona
lo esperado. La ejecución del trabajo debe ser IN_PROGRESS
para que puedas finalizarla.
gcloud
gcloud deploy job-runs terminate JOB_RUN_ID \
--release=RELEASE_NAME \
--delivery-pipeline=PIPELINE_NAME \
--rollout=ROLLOUT_NAME \
--region=REGION
Aquí:
JOB_RUN_ID
es el (UUID) de la ejecución del trabajo que deseas
rescindir. Puedes encontrar el ID de ejecución del trabajo en la consola de Google Cloud, por
Cloud Deploy, en la página de lanzamiento:
También puedes obtener el ID de las ejecuciones de trabajo con el comando gcloud deploy rollouts
describe
.
RELEASE_NAME
es el nombre de la versión que esta
de la que forma parte la ejecución del trabajo.
PIPELINE_NAME
es el nombre de la canalización de entrega que usas para administrar la implementación de esta versión.
ROLLOUT_NAME
es el nombre del lanzamiento de este trabajo
es parte de la ejecución.
REGION
es el nombre de la región en la que
versión, por ejemplo, us-central1
. Este campo es obligatorio.
Consulta la referencia del SDK de Google Cloud para obtener más información sobre el
Comando gcloud deploy job-runs terminate
Console
Haz clic en tu canalización que se muestra en la lista de canalizaciones de publicación.
En la página Detalles de la canalización de entrega, se muestra una representación gráfica de el progreso de tu canalización de entrega.
En la pestaña Lanzamientos, en Detalles de la canalización de entrega, haz clic en el nombre del lanzamiento.
Se muestra la página de detalles del lanzamiento para ese lanzamiento.
Observa que, en este ejemplo, el lanzamiento tiene una fase
canary-50
y una Fasestable
: Tu lanzamiento puede tener más fases o diferentes fases.En Fases, haz clic en la fase que incluye el trabajo cuyo trabajo se ejecutó. estás dando por terminada.
En Ejecuciones de trabajos, selecciona la ejecución del trabajo específica que estás finalizando y, luego, Haz clic en Finalizar.
La ejecución del trabajo se cancela y el estado del trabajo, como se muestra en la tabla Fases, es
Failure
.
Después de que finalizas la ejecución de un trabajo, este se considera con errores y puedes hacer cualquier de las siguientes opciones:
- Déjalo así y omite el lanzamiento con errores.
- Reintentar el trabajo
- Ignora el trabajo y continúa con el siguiente trabajo o fase de la lanzamiento
Ignora un trabajo
Puedes ignorar un trabajo con errores y pasar inmediatamente al siguiente trabajo de la fase. Es posible que ese trabajo haya fallado por cualquier motivo, incluso tú o alguien más finalizó una ejecución de trabajo para ese trabajo.
Un trabajo con errores significa una fase y un lanzamiento con errores. Sin embargo, si ignoras
la falla, tanto la fase como el lanzamiento pueden avanzar y, en última instancia,
tienen SUCCEEDED
estados.
gcloud
gcloud deploy rollouts ignore-job ROLLOUT_NAME \
--release=RELEASE_NAME \
--delivery-pipeline=PIPELINE_NAME \
--job-id=JOB_ID \
--phase-id=PHASE_ID \
--region=REGION
Aquí:
ROLLOUT_NAME
es el nombre del lanzamiento de este trabajo
es parte de la ejecución.
RELEASE_NAME
es el nombre de la versión actual.
que incluye este trabajo.
PIPELINE_NAME
es el nombre de la canalización de entrega que usas para administrar la implementación de esta versión.
JOB_ID
es el nombre del trabajo que se debe ignorar, por
DEPLOY
de ejemplo. Puedes encontrar el nombre del trabajo en la tabla Fases del
lanzamiento, en la consola de Google Cloud:
PHASE_ID
es el nombre de la fase que incluye el elemento
trabajo que ignoras.
REGION
es el nombre de la región en la que
versión, por ejemplo, us-central1
.
Consulta la referencia del SDK de Google Cloud para obtener más información sobre el
Comando gcloud deploy rollouts ignore-job
Console
Haz clic en la canalización que se muestra en la lista de canalizaciones de entrega.
En la página Detalles de la canalización de entrega, se muestra una representación gráfica de el progreso de tu canalización de entrega.
En la pestaña Lanzamientos, en Detalles de la canalización de entrega, haz clic en el nombre del lanzamiento.
Se muestra la página de detalles del lanzamiento para ese lanzamiento.
Selecciona el trabajo con errores que deseas ignorar.
Haz clic en el botón Ignorar fallas.
Se ignora la ejecución del trabajo con errores y el lanzamiento continúa como si el trabajo habían tenido éxito. Es decir, si hay otros trabajos en la misma fase, estos se ejecutan. De lo contrario, el lanzamiento está listo para avanzar a la siguiente fase.
Reintentar un trabajo con errores
Puedes reintentar la ejecución de un trabajo que falló. El trabajo puede fallar en cualquiera de los siguientes casos motivos:
No se pudo completar la ejecución de un trabajo.
Por ejemplo, es posible que se haya producido un error en los permisos.
Un usuario finalizó la ejecución de un trabajo a partir de ese trabajo.
Terminar una ejecución de trabajo genera un trabajo con errores, que puedes volver a intentar.
Falló una prueba de verificación.
Para un trabajo de verificación, una prueba de verificación falló. A pesar de que el trabajo de verificación se completó correctamente, una de tus las pruebas de verificación fallaron y las propagamos de vuelta al trabajo de verificación. En este caso, debes reintentar el trabajo como parte de la depuración de la prueba con errores en tu aplicación.
Para reintentar un trabajo con errores, sigue estos pasos:
gcloud
gcloud deploy rollouts retry-job JOB_NAME \
--release=RELEASE_NAME \
--delivery-pipeline=PIPELINE_NAME \
--rollout=ROLLOUT_NAME \
--phase=PHASE_ID \
--region=REGION
Aquí:
JOB_NAME
es el nombre de la tarea que intentas nuevamente. Por ejemplo, si reintentas el trabajo de verificación después de un error
verificación, que sería verify
.
RELEASE_NAME
es el nombre de la versión que esta
de la que forma parte la ejecución del trabajo.
PIPELINE_NAME
es el nombre de la canalización de entrega que usas para administrar la implementación de esta versión.
ROLLOUT_NAME
es el nombre del lanzamiento de este trabajo
es parte de la ejecución.
PHASE_ID
es el nombre de la fase en la que se realiza este trabajo.
de las que forman parte. Por ejemplo, canary-50
o stable
.
REGION
es el nombre de la región en la que
versión, por ejemplo, us-central1
. Este campo es obligatorio.
Consulta la referencia del SDK de Google Cloud para obtener más información sobre el
Comando gcloud deploy rollouts retry-job
Console
Haz clic en tu canalización que se muestra en la lista de canalizaciones de publicación.
En la página Detalles de la canalización de entrega, se muestra una representación gráfica de el progreso de tu canalización de entrega.
En la pestaña Lanzamientos, en Detalles de la canalización de publicación, haz clic en el nombre de tu lanzamiento.
Se muestra la página de detalles del lanzamiento para ese lanzamiento.
En Fases y trabajos, haz clic en la fase que incluye el trabajo reintentar.
Selecciona el trabajo que deseas reintentar.
Haz clic en Reintentar y confirma tu decisión.
La ejecución del trabajo se vuelve a ejecutar y el estado del trabajo, como se muestra en Fases está "en curso". Si hay otros trabajos en el mismo de servicio, se ejecutan. De lo contrario, el lanzamiento está listo para avanzar en la siguiente fase.
¿Qué sigue?
Obtén más información sobre cómo funcionan las estrategias de implementación en Cloud Deploy.
Consulta la documentación sobre la arquitectura de servicios de Cloud Deploy más información sobre cómo los lanzamientos, las fases, los trabajos y las ejecuciones de trabajos se adaptan el resto de Cloud Deploy.