Actualización e implementación de cambios en Azure Container Apps
La administración de cambios puede ser difícil a medida que desarrolla aplicaciones en contenedor en la nube. En última instancia, necesita la compatibilidad para realizar un seguimiento de los cambios, garantizar el tiempo de actividad y tener mecanismos para controlar las reversiones sin problemas.
La administración de cambios en Azure Container Apps se basa en revisiones, que son una instantánea de cada versión de la aplicación contenedora.
Entre las características clave de las revisiones se incluyen las siguientes:
Inmutable: una vez establecida, una revisión permanece inmutable.
Control de versiones: las revisiones actúan como un registro de las versiones de la aplicación contenedora, capturando su estado en varias fases.
Aprovisionado automáticamente: al implementar una aplicación contenedora por primera vez, se crea automáticamente una revisión inicial.
Cambios con ámbito: aunque las revisiones permanecen estáticas, los cambios en el ámbito de aplicación pueden afectar a todas las revisiones, mientras que los cambios en el ámbito de revisión crean una nueva revisión.
Registro histórico: de forma predeterminada, tiene acceso a 100 revisiones inactivas, pero puede ajustar este umbral manualmente.
Varias revisiones: puede ejecutar varias revisiones simultáneamente. Esta característica es especialmente beneficiosa cuando necesitas administrar diferentes versiones de tu aplicación simultáneamente.
Ciclo de vida
Cada revisión se somete a estados específicos, influenciados por su estado y disponibilidad. Durante su ciclo de vida, una aplicación contenedora pasa por diferentes aprovisionamiento, ejecución y estado inactivo.
Estado de aprovisionamiento
Al crear una nueva revisión, la aplicación contenedora se somete a comprobaciones de inicio y preparación. Durante esta fase, el estado de aprovisionamiento sirve como guía para realizar un seguimiento del progreso de la aplicación contenedora.
| Estado | Descripción |
|---|---|
| Aprovisionamiento | La revisión está en el proceso de comprobación. |
| aprovisionado | La revisión ha superado correctamente todas las comprobaciones. |
| error de aprovisionamiento. | La revisión encontró problemas durante la comprobación. |
Estado de ejecución
Una vez aprovisionada correctamente una aplicación contenedora, una revisión entra en su fase operativa. El estado en ejecución ayuda a supervisar el estado y la funcionalidad de una aplicación contenedora.
| Estado | Descripción |
|---|---|
| Aprovisionamiento | La revisión está en el proceso de comprobación. |
| Escalado a 0 | Cero réplicas en ejecución y no aprovisionar ninguna réplica nueva. La aplicación contenedora puede crear nuevas réplicas si se desencadenan reglas de escalado. |
| En activación | Réplicas en ejecución cero, una réplica que se aprovisiona. |
| Error de activación | No se pudo aprovisionar la primera réplica. |
| Escalado y procesamiento | Se está realizando el escalado o el escalado horizontal. Se están ejecutando una o varias réplicas, mientras que se aprovisionan otras réplicas. |
| En ejecución | Se están ejecutando una o varias réplicas. No hay problemas para informar. |
| En ejecución (como máximo) | El número máximo de réplicas (según las reglas de escalado de la revisión) se están ejecutando. No hay problemas para informar. |
| Deprovisioning | La revisión está realizando la transición de activo a inactivo y quita los recursos que ha creado. |
| Degradado | Al menos una réplica de la revisión está en estado de error. Vea los detalles del estado de ejecución para ver problemas específicos. |
| Con errores | Los errores críticos provocaron un error en las revisiones. El estado en ejecución proporciona detalles. Las causas más comunes son: •Terminación • Código de salida 137 |
Estado inactivo
Las revisiones también pueden especificar un estado inactivo. Estas revisiones no poseen estados de aprovisionamiento ni ejecución. Sin embargo, Azure Container Apps mantiene una lista de estas revisiones, que admite hasta 100 entradas inactivas. Puede activar una revisión en cualquier momento.
Cambio del límite de revisiones inactivas
Puede usar el --max-inactive-revisions parámetro con los containerapp create comandos o containerapp update para controlar el número de revisiones inactivas a las que realiza el seguimiento Container Apps.
En este ejemplo se muestra cómo crear una nueva aplicación contenedora que realiza un seguimiento de 50 revisiones inactivas:
az containerapp create --max-inactive-revisions 50
Modos de revisión
Azure Container Apps admite dos modos de revisión. La elección del modo determina cuántas revisiones de la aplicación están activas simultáneamente.
| Modos de revisión | Descripción | Valor predeterminado |
|---|---|---|
| Single | Las nuevas revisiones se aprovisionan, activan y escalan automáticamente al tamaño deseado. Una vez que todas las réplicas se ejecutan según lo definido por la regla de escalado, el tráfico se desvía de la versión anterior a la nueva. Si se produce un error en una actualización, el tráfico sigue apuntando a la revisión anterior. Las revisiones antiguas se desaprovisionan automáticamente. | Sí |
| Múltiple | Puede tener varias revisiones activas, dividir el tráfico entre revisiones y elegir cuándo desaprovisionar las revisiones antiguas. Este nivel de control es útil para probar varias versiones de una aplicación, pruebas azul-verde o tomar el control total de las actualizaciones de la aplicación. Consulte la división de tráfico para obtener más detalles. |
Etiquetas
En el caso de las aplicaciones de contenedor con tráfico HTTP externo, las etiquetas dirigen el tráfico a revisiones específicas. Una etiqueta proporciona una URL única que puede usar para dirigir el tráfico a la revisión que tiene asignada la etiqueta.
Para cambiar el tráfico entre revisiones, puede mover la etiqueta de una revisión a otra.
- Las etiquetas mantienen la misma dirección URL cuando se mueven de una revisión a otra.
- Una etiqueta solo se puede aplicar a una revisión cada vez.
- La asignación de la división de tráfico no es necesaria para las revisiones con etiquetas.
- Las etiquetas son más útiles cuando la aplicación está en modo de revisión múltiple.
- Se pueden activar las etiquetas, la división del tráfico o ambas.
Las etiquetas son útiles para probar nuevas revisiones. Por ejemplo, cuando quiera conceder acceso a un conjunto de usuarios de prueba, puede asignarles la dirección URL de la etiqueta. Entonces, cuando quiera mover a los usuarios a una revisión diferente, puede mover la etiqueta a esa revisión.
Las etiquetas funcionan independientemente de la división del tráfico. La división del tráfico distribuye el tráfico que va a la URL de la aplicación del contenedor a las revisiones en función del porcentaje de tráfico. Cuando el tráfico se dirige a la URL de una etiqueta, el tráfico se dirige a una revisión específica.
Un nombre de etiqueta debe:
- Consta de caracteres alfanuméricos o guiones en minúsculas (
-) - Comience con un carácter alfabético
- Terminar con un carácter alfanumérico
Las etiquetas no deben:
- Tener dos guiones consecutivos (
--) - Tener más de 64 caracteres
Puede administrar las etiquetas desde la página de Administración de revisiones de su aplicación de contenedor en el Azure Portal.
La dirección URL de la etiqueta está disponible en el panel de detalles de revisión.
Implementación sin tiempo de inactividad
En el modo de revisión única, Container Apps garantiza que la aplicación no experimente tiempo de inactividad al crear una nueva revisión. La revisión activa existente no se desactiva hasta que la nueva revisión esté lista.
Si la entrada está habilitada, la revisión existente sigue recibiendo el 100 % del tráfico hasta que la nueva revisión esté lista.
Una nueva revisión se considera lista cuando:
- La revisión se ha aprovisionado correctamente
- La revisión se ha escalado verticalmente para que coincida con el recuento de réplicas de revisiones anteriores (respetando el número mínimo y máximo de réplicas de la nueva revisión).
- Todas las réplicas han pasado sus sondeos de inicio y preparación
En el modo de revisión múltiple, puede controlar cuándo se activan o desactivan las revisiones y qué revisiones reciben tráfico de entrada. Si se configura una regla de división de tráfico con latestRevisionestablecida en true, el tráfico no cambia a la revisión más reciente hasta que esté lista.
Trabajar con varias revisiones
Aunque el modo de revisión única es el predeterminado, a veces es posible que desee tener control total sobre cómo se administran las revisiones.
El modo de revisión múltiple le ofrece la flexibilidad de administrar la revisión manualmente. Por ejemplo, el uso del modo de revisión múltiple permite decidir exactamente cuánto tráfico se asigna a cada revisión.
División del tráfico
En el diagrama siguiente se muestra una aplicación de contenedor con dos revisiones.
En este escenario se supone que la aplicación contenedora está en el estado siguiente:
- La entrada está habilitada, lo que hace que la aplicación contenedora esté disponible a través de HTTP o TCP.
- La primera revisión se implementó como Revision 1.
- Después de actualizar el contenedor, se activa una nueva revisión, Revision 2 (Revisión 2).
- Las reglas de división del tráfico están configuradas para que Revision 1 reciba el 80 % de las solicitudes y Revision 2 el 20 % restante.
Acceso directo a revisiones
En lugar de usar una regla de enrutamiento para desviar el tráfico a una revisión, es posible que desee que una revisión esté disponible para las solicitudes de una dirección URL específica. El modo de revisión múltiple puede permitirle enviar todas las solicitudes que llegan al dominio a la revisión más reciente, mientras que las solicitudes de una revisión anterior están disponibles a través de etiquetas para el acceso directo.
Estado de activación
En el modo de revisión múltiple, puede activar o desactivar las revisiones según sea necesario. Las revisiones activas son operativas y pueden controlar las solicitudes, mientras que las revisiones inactivas permanecen inactivas.
Container Apps no cobra por revisiones inactivas. Sin embargo, hay un límite en el número total de revisiones disponibles, con los más antiguos que se purgan una vez que se supera un recuento de 100.
Tipos de cambio
Los cambios en una aplicación de contenedor se dividen en dos categorías: cambios en el ámbito de la revisión o en el ámbito de la aplicación. Los cambios de ámbito de revisión activan una nueva revisión cuando se implementa la aplicación, mientras que los cambios de ámbito de aplicación no lo hacen.
Cambios del ámbito de revisión
Se crea una nueva revisión cuando se actualiza una aplicación contenedor con cambios de ámbito de revisión. Los cambios se limitan a la revisión en la que se implementan, y no afectan a otras revisiones.
Un cambio de ámbito de revisión es cualquier cambio en los parámetros de la sección properties.template de la plantilla de recursos de la aplicación contenedor.
Estos parámetros son:
- Sufijo de revisión
- Configuración e imágenes de contenedor
- Reglas de escalado para la aplicación de contenedor
Cambios del ámbito de aplicación
Al implementar una aplicación en contenedor con cambios en el ámbito de la aplicación:
- Los cambios se aplican globalmente a todas las revisiones.
- No se crea una nueva revisión.
Los cambios de ámbito de aplicación se definen como cualquier cambio en los parámetros de la sección properties.configuration de la plantilla de recursos de la aplicación contenedor.
Estos parámetros son:
- Valores secretos(las revisiones se deben reiniciar antes de que un contenedor reconozca los nuevos valores secretos)
- Modo de revisión
- Configuración de entrada, entre las que se incluyen:
- La activación o desactivación de la entrada
- Reglas de división del tráfico
- Etiquetas
- Credenciales para registros de contenedores privados
- Configuración de Dapr
Personalización de revisiones
Puede personalizar el nombre y las etiquetas de revisión para alinearse mejor con las convenciones de nomenclatura o la estrategia de control de versiones.
Sufijo de nombre
A cada revisión de Container Apps se le asigna un identificador único. Aunque los nombres se generan automáticamente, puede personalizar el nombre de revisión.
El formato típico de un nombre de revisión es:
<CONTAINER_APP_NAME>-<REVISION_SUFFIX>
Por ejemplo, si tiene una aplicación contenedor denominada album-api y decide el sufijo de revisión first-revision, el nombre de revisión completo se convierte en album-api-first-revision.
Un nombre de sufijo de revisión debe:
- Consta solo de caracteres alfanuméricos en minúsculas o guiones (
-) - Comience con un carácter alfabético
- Terminar con un carácter alfanumérico
Los nombres no deben tener:
- Dos guiones consecutivos (
--) - Tener más de 64 caracteres
Puede establecer el sufijo de revisión en la plantilla ARM, a través de los comandos az containerapp create y az containerapp update de la CLI de Azure, o al crear una revisión a través del Azure portal.
Casos de uso
A continuación se muestran casos de uso comunes para usar revisiones en aplicaciones de contenedor. Esta lista no es una lista exhaustiva de la finalidad o funcionalidades de usar revisiones de Container Apps.
Administración de versiones
Las revisiones simplifican el proceso de presentación de nuevas versiones de la aplicación. Cuando esté listo para implementar una actualización o una nueva característica, puede crear una nueva revisión sin afectar a la versión activa actual. Este enfoque garantiza una transición sin problemas y minimiza las interrupciones para los usuarios finales.
Reversión a versiones anteriores
A veces, es necesario revertir rápidamente a una versión estable anterior de la aplicación. Si es necesario, puede revertir a una revisión anterior de la aplicación contenedora.
Pruebas A/B
Cuando quiera probar diferentes versiones de la aplicación, las revisiones pueden admitir pruebas A/B. Puede enrutar un subconjunto de los usuarios a una nueva revisión, recopilar comentarios y tomar decisiones informadas basadas en datos reales.
Implementaciones azul-verde
Las revisiones admiten la estrategia de implementación azul-verde. Al tener dos revisiones paralelas (azul para la versión activa y verde para la nueva), puede realizar una fase gradual en una nueva revisión. Una vez que esté seguro de la estabilidad y el rendimiento de la nueva versión, puede cambiar el tráfico por completo al entorno verde.