Aprovisionamiento de Azure Container Apps
Nota:
Los planes de Básico, Estándar y Enterprise quedarán en desuso a partir de mediados de marzo de 2025, con un período de retiro de 3 años. Se recomienda realizar la transición a Azure Container Apps. Para más información, consulte el anuncio de retirada de Azure Spring Apps.
El plan de consumo estándar y dedicado quedará obsoleto a partir del 30 de septiembre de 2024, con un cierre completo al cabo de seis meses. Se recomienda realizar la transición a Azure Container Apps. Para obtener más información, consulte Migrar el plan de consumo y dedicado Azure Spring Apps Standard a Azure Container Apps.
Este artículo se aplica a: Enterprise ✅ Básico/Estándar ✅
En este artículo se proporciona información general sobre las consideraciones durante la creación de Azure Container Apps.
En Azure Spring Apps, las aplicaciones se implementan dentro de una instancia de servicio, que proporciona una plataforma totalmente administrada. Del mismo modo, en Azure Container Apps, las aplicaciones de contenedor se crean dentro de un Entorno de Azure Container Apps, que actúa como host fundamental para las aplicaciones. Aunque ambos servicios proporcionan entornos de hospedaje, difieren en varios aspectos, como modelos de precios, mantenimiento, soporte técnico regional y operaciones de administración. En este artículo se exploran estas diferencias y se proporcionan instrucciones sobre cómo crear y administrar entornos de Azure Container Apps.
Requisitos previos
- Una suscripción a Azure activa. En caso de no tener ninguna, puede crear una cuenta gratuita de Azure.
- Azure CLI.
- El proveedor de recursos
Microsoft.App
está registrado en la suscripción de Azure. Para más información, vea Tipos y proveedores de recursos de Azure.
Crear un entorno de Azure Container Apps
Para crear un entorno de Azure Container Apps, use el siguiente comando:
az containerapp env create \
--resource-group $RESOURCE_GROUP \
--name $ENVIRONMENT \
--location "$LOCATION"
Para ver otras opciones de configuración, consulte Comandos de la CLI de Azure Container Apps.
Después de crear el entorno, puede implementar una aplicación de contenedor dentro de él. Para obtener instrucciones paso a paso, consulte Inicio rápido: Implementación de la primera aplicación contenedora mediante Azure Portal.
Nota:
Los entornos de aplicación de contenedor se eliminan automáticamente si cumplen ciertas condiciones; por ejemplo, si un entorno permanece inactivo durante más de 90 días. Para obtener una lista completa de las condiciones, consulte la sección Directivas de Entornos de Azure Container Apps.
Regiones admitidas
Es posible que las regiones actualmente compatibles con Azure Container Apps no se alineen completamente con esas regiones compatibles con Azure Spring Apps. Compruebe la disponibilidad más reciente en Productos disponibles por región.
Precios
Para una instancia de Azure Spring Apps, los cargos se basan en uno de los planes disponibles: Básico, Estándar o Enterprise. Aunque en Azure Container Apps, los precios dependen del tipo de entorno y de los perfiles de carga de trabajo que elija.
Tipo de entorno
Hay dos tipos de entorno en Azure Container Apps: Workload profile
y Consumption only
. Puede especificar el tipo de entorno mediante el parámetro --enable-workload-profiles
al crear el entorno de Azure Container Apps. De forma predeterminada, --enable-workload-profiles
se establece en true
al crear un entorno de Workload profile
. Si lo establece en false
, se crea un entorno de Consumption only
.
Workload profile
entornos permiten crear perfiles de carga de trabajo dedicados y de consumo.
Consumption only
entornos no admiten la creación de perfiles de carga de trabajo.
Para conocer las consideraciones de facturación para distintos tipos, puede encontrar más información en la sección Tipos de Entornos de Azure Container Apps. Si tiene previsto usar su propia red virtual, tenga en cuenta las diferencias que se describen en la tabla siguiente:
Tipo de entorno | Tipos de plan admitidos | Descripción |
---|---|---|
Perfiles de carga de trabajo | Consumo, dedicado | Admite rutas definidas por el usuario (UDR), salida a través de NAT Gateway y creación de puntos de conexión privados en el entorno de la aplicación contenedora. El tamaño mínimo necesario de subred es /27 . |
Solo consumo | Consumo | No admite rutas definidas por el usuario (UDR), salida a través de NAT Gateway, emparejamiento a través de una puerta de enlace remota u otra salida personalizada. El tamaño mínimo necesario de subred es /23 . |
Para más información, consulte Entornos de Azure Container Apps.
Perfil de carga de trabajo
Si decide crear un entorno Workload profile
, puede usar el perfil Consumption
predeterminado o crear perfiles Dedicated
adicionales para satisfacer sus requisitos de aplicación específicos. En la tabla siguiente se describen estas opciones:
Tipo de perfil | Descripción | Uso posible |
---|---|---|
Consumo | Se agrega automáticamente a cualquier nuevo entorno. | Aplicaciones que no requieren requisitos de hardware específicos. |
Dedicado (de uso general) | Equilibra la memoria y los recursos de proceso. | Aplicaciones que requieren grandes cantidades de CPU o memoria. |
Dedicado (optimizado para memoria) | Mayor cantidad de recursos de memoria. | Aplicaciones que necesitan acceso a datos grandes en memoria, modelos de aprendizaje automático en memoria u otros requisitos de memoria elevados. |
Dedicado (habilitado para GPU) (versión preliminar) | Habilitado para GPU con un aumento de los recursos de memoria y proceso disponibles en las regiones Oeste de EE. UU. 3 y Norte de Europa. | Aplicaciones que requieren GPU. |
Para más información sobre los tamaños y tipos de perfil de carga de trabajo, consulte la sección Tipos de perfil de Perfiles de carga de trabajo en Azure Container Apps.
Estimación de costos
Use la Calculadora de precios de Azure para calcular los costos de ambos tipos de perfil de carga de trabajo en función de los requisitos de recursos de la aplicación.
Considere la posibilidad de escalar configuraciones y desencadenadores de escalado automático, ya que afectan significativamente al uso de recursos.
Para más información, consulte Perfiles de carga de trabajo en Azure Container Apps.
Mantenimiento
Azure Container Apps garantiza que la aplicación se reinicie correctamente durante el mantenimiento subyacente. Puede configurar una ventana de mantenimiento para el entorno de la aplicación mediante el comando siguiente:
az containerapp env maintenance-config add \
--resource-group <RESOURCE_GROUP> \
--environment <ENVIRONMENT_NAME> \
--weekday Monday \
--start-hour-utc 1 \
--duration 8
De forma similar a la característica de mantenimiento planeado en Azure Spring Apps, puede establecer los días de la semana, la hora de inicio y la duración ( al menos 8 horas) en Azure Container Apps. Container Apps realiza actualizaciones no críticas según la configuración de mantenimiento.
Nota:
Las horas en formato UTC se expresan con el formato de hora 24 horas. Por ejemplo, si desea que la hora de inicio sea de 1:00 p.m., el valor de start-hour-utc
es 13.
Azure Container Apps garantiza que el mantenimiento se inicia dentro de la ventana de mantenimiento configurada, pero no garantiza que el mantenimiento finalice dentro del período de tiempo.
Solo las actualizaciones no críticas siguen la ventana de mantenimiento configurada. Las actualizaciones críticas no.
Para más información, consulte Mantenimiento planeado de Azure Container Apps.
Fiabilidad
Compatibilidad de zonas de disponibilidad
En la mayoría de las regiones, Azure Spring Apps y Azure Container Apps usan zonas de disponibilidad en las regiones donde están disponibles. Para obtener una lista de las regiones que admiten zonas de disponibilidad, consulte Servicios de Azure con compatibilidad con zonas de disponibilidad. Azure Container Apps ofrece la misma compatibilidad de confiabilidad independientemente del tipo de plan.
Para habilitar zonas de disponibilidad en Azure Container Apps, debe especificar una red virtual con una subred disponible al crear el entorno de aplicación de contenedor. Tanto Azure Spring Apps como Azure Container Apps usan el mismo parámetro para habilitar la redundancia de zona. Para más información sobre cómo habilitar zonas de disponibilidad, consulte Confiabilidad en Azure Container Apps.
Recuperación ante desastres
Azure Spring Apps y Azure Container Apps emplean una estrategia unificada para la recuperación ante desastres y la continuidad empresarial. Para más información, consulte la sección Recuperación ante desastres entre regiones y continuidad empresarial de Confiabilidad en Azure Container Apps.
Restricciones conocidas
- Inicio y detención: Azure Spring Apps permite iniciar o detener toda la instancia de servicio o las aplicaciones individuales. Por el contrario, Azure Container Apps solo admite la funcionalidad start/stop en el nivel de aplicación de contenedor, no para todo el entorno.
- Eliminar: Al eliminar una instancia de servicio de Azure Spring Apps, se quitan automáticamente todos los recursos subyacentes. Por el contrario, para Azure Container Apps, primero debe eliminar subrecursos, como quitar todas las aplicaciones de contenedor antes de eliminar el entorno de aplicaciones de contenedor.