Preguntas frecuentes de Azure App Configuration

App Configuration ayuda a los desarrolladores a administrar la configuración de las aplicaciones y a controlar la disponibilidad de características. Pretende simplificar muchas de las tareas del trabajo con datos de configuración complejos.

App Configuration admite:

• Espacios de nombres jerárquicos
• Etiquetado
• Consultas amplias
• Recuperación por lotes
• Operaciones de administración especializadas
• Una interfaz de usuario de administración de características

App Configuration complementa a Key Vault y los dos deben usarse en paralelo en la mayoría de las implementaciones de aplicaciones.

Aunque App Configuration ofrece mayor seguridad, Key Vault sigue siendo el mejor lugar para almacenar los secretos de la aplicación. Key Vault proporciona cifrado de nivel de hardware, directivas de acceso pormenorizadas y operaciones de administración como la rotación de certificados.

Puede crear valores clave de App Configuration que hagan referencia a secretos almacenados en Key Vault. Para obtener más información, consulte Uso de referencias de Key Vault en una aplicación de ASP.NET Core.

Sí. App Configuration siempre cifra todos los datos en tránsito y en reposo. Toda la comunicación de red se realiza a través de TLS 1.2 o TLS 1.3. App Configuration admite el cifrado en reposo con claves administradas por Microsoft o claves administradas por el cliente.

Azure App Service permite definir la configuración de la aplicación para cada instancia de App Service. Estas configuraciones se pasan como variables de entorno al código de la aplicación. Si lo desea, puede asociar un valor a una ranura de implementación específica. Para obtener más información, consulte Configuración de aplicaciones.

En cambio, Azure App Configuration permite definir una configuración que se puede compartir entre varias aplicaciones. Esto incluye las aplicaciones que se ejecutan en App Service, así como otras plataformas. El código de la aplicación accede a esta configuración mediante los proveedores de configuración para .NET y Java, mediante el SDK de Azure o directamente mediante las API REST.

Puede agregar referencias a los datos de App Configuration en Configuración de aplicación de App Service. También puede importar y exportar configuraciones entre App Service y App Configuration. Esta funcionalidad permite configurar rápidamente un nuevo almacén de App Configuration en función de la configuración de App Service existente. También puede compartir la configuración con una aplicación existente que se base en la configuración de App Service.

Hay un límite de 10 KB para un único elemento clave-valor, incluidos atributos como etiqueta, tipo de contenido, etiquetas y otros metadatos. No hay ningún límite en el número de claves y etiquetas siempre que su tamaño total esté por debajo del límite de almacenamiento.

Este límite de clave-par debe ser suficiente para una configuración sencilla en la mayoría de las aplicaciones. Si encuentra que su configuración es mayor que este límite, puede considerar la posibilidad de almacenar los datos en otro lugar y agregar una referencia de esos datos en App Configuration.

Para obtener una lista completa de los límites, consulte límites de suscripción y servicio de Azure.

Puede controlar quién accede a App Configuration en cada almacén. Use un almacén independiente para cada entorno que requiera permisos distintos. Este enfoque ofrece el mejor aislamiento de seguridad.

Si no necesita aislamiento de seguridad entre entornos, puede usar etiquetas para diferenciar los valores de configuración. Uso de etiquetas para habilitar diferentes configuraciones para distintos entornos proporciona un ejemplo completo.

Consulte los procedimientos recomendados.

Hay tres planes de tarifa: Gratis, Estándar y Premium. Para obtener información detallada sobre los precios, consulte la página Precios de App Configuration.

Todos los niveles de App Configuration ofrecen funcionalidad básica, incluida la configuración, las marcas de características, las referencias de Key Vault, las instantáneas de configuración, las operaciones de administración básicas, las métricas y los registros.

A continuación se indican algunas consideraciones para elegir un nivel.

• Propósito: el nivel Gratis es perfecto para evaluar el servicio en entornos que no son de producción, lo que le permite explorar sus características sin ningún costo. El nivel Estándar se adapta a los casos de uso de producción de volumen medio, lo que proporciona un equilibrio de rendimiento y rentabilidad. En el caso de las necesidades de producción de alto volumen o de nivel empresarial, el nivel Premium ofrece el mayor nivel de rendimiento y escalabilidad, lo que garantiza que las aplicaciones se ejecuten sin problemas incluso con una carga pesada.

• Recursos por suscripción: Un recurso se compone de un único almacén de configuración. Cada suscripción está limitada a un almacén de configuración por región en el nivel Gratis. Las suscripciones pueden tener un número ilimitado de almacenes de configuración en los niveles Estándar y Premium.

• Almacenamiento por recurso: en el nivel Gratis, cada almacén de configuración está limitado a 10 MB de almacenamiento normal y 10 MB de almacenamiento de instantáneas. En el nivel Estándar, cada almacén de configuración puede usar hasta 1 GB de almacenamiento normal y un adicional de 1 GB de almacenamiento de instantáneas. En el nivel Premium, cada almacén de configuración puede usar hasta 4 GB de almacenamiento normal y 4 GB adicionales de almacenamiento de instantáneas.

• Historial de revisiones: App Configuration almacena un historial de todos los cambios realizados en las claves. En el nivel Gratis, este historial se almacena durante siete días. En los niveles Estándar y Premium, este historial se almacena durante 30 días.

• Cuota de solicitudes: los almacenes del nivel Gratis se limitan a 1 000 solicitudes al día. Cuando un almacén alcanza 1000 solicitudes, devuelve el código de estado HTTP 429 para todas las solicitudes hasta medianoche UTC.

  Los almacenes del nivel estándar están limitados a 30 000 solicitudes por hora. Una vez agotada la cuota por hora, las solicitudes adicionales pueden devolver un código de estado HTTP 429, que indica demasiadas solicitudes, hasta el final de la hora. Cuantas más solicitudes se envíen por encima de la cuota, mayor será el porcentaje de ella que podrían devolver el código de estado 429.

  Los almacenes de nivel Premium no tienen límite de cuota en las solicitudes, lo que garantiza que el acceso al almacén nunca se bloquee.

• Rendimiento: los almacenes de App Configuration en todos los niveles tienen una asignación de rendimiento. Las solicitudes que superen esta asignación recibirán una respuesta de código de estado HTTP 429. Los almacenes del nivel Gratis no tienen ningún rendimiento garantizado.

  Los almacenes en el nivel Estándar permiten una velocidad de ejecución† de hasta 300 solicitudes por segundo (RPS) para solicitudes de lectura y hasta 60 RPS para solicitudes de escritura.

  Los almacenes en el nivel Premium permiten una velocidad de ejecución† de hasta 450 RPS para las solicitudes de lectura y hasta 100 RPS para las solicitudes de escritura.

  †La velocidad de ejecución se mide normalmente como el número medio de solicitudes controladas por un almacén de App Configuration sin limitación durante un período especificado.

• Contrato de nivel de servicio: el nivel Gratis no tiene un Acuerdo de Nivel de Servicio. El nivel Estándar tiene un Acuerdo de Nivel de Servicio de disponibilidad del 99,9 % y una disponibilidad del 99,95 % con la replicación geográfica habilitada. El nivel Premium tiene un Contrato de nivel de servicio de disponibilidad del 99,9 % y una disponibilidad del 99,99 % con la replicación geográfica habilitada.

• Características: todos los niveles incluyen funcionalidades, incluido el cifrado con claves administradas por Microsoft, la autenticación a través de la clave de acceso o el identificador de Microsoft Entra, el control de acceso basado en rol (RBAC), la identidad administrada, las etiquetas de servicio y la redundancia de zona de disponibilidad. Los niveles Estándar y Premium ofrecen más funcionalidades, incluida la compatibilidad con Private Link, el cifrado con claves administradas por el cliente, la protección de eliminación temporal y la funcionalidad de replicación geográfica.

• Costo: no hay ningún costo para usar un almacén de niveles gratis.

  Los almacenes de niveles estándar tienen un cargo de uso diario, que incluye las primeras 200 000 solicitudes cada día. Las solicitudes más allá de esta asignación diaria incurren en un cargo por encima del límite.

  Los almacenes de nivel Premium también tienen un cargo de uso diario e incluyen una réplica. Las primeras 800 000 solicitudes para el origen y las primeras 800 000 solicitudes de la réplica cada día se incluyen en el cargo diario. Las solicitudes que superan esta asignación diaria incurren en un cargo por encima del límite.

Puede actualizar un almacén de App Configuration en cualquier momento, por ejemplo, desde el nivel Gratis al nivel Estándar o Premium, o desde el nivel Estándar al nivel Premium.

No se puede cambiar a una versión anterior un almacén de App Configuration, por ejemplo, desde el nivel Premium hasta el nivel Estándar, ni desde el nivel Estándar hasta el nivel Gratis. Sin embargo, puede crear un nuevo almacén en el nivel deseado y a continuación, importar datos de configuración en ese almacén.

Los datos de cliente almacenados en App Configuration residen en la región en la que se creó el almacén de App Configuration del cliente. Los datos del cliente se replicarán en otra región solo si el cliente habilita la replicación geográfica para esa región. Esto se aplica a todas las regiones disponibles. Los clientes pueden mover, copiar o acceder a los datos desde cualquier ubicación global.

Azure App Configuration admite la replicación geográfica para mejorar la resistencia a las interrupciones regionales.

Azure App Configuration admite Azure Availability Zones para proteger la aplicación y los datos frente a errores de un solo centro de datos. Todas las regiones compatibles con las zonas de disponibilidad constan de un mínimo de tres zonas de disponibilidad, donde cada una es un centro de datos físicamente independiente. Para lograr resistencia, esta compatibilidad de App Configuration está habilitada para todos los clientes sin costo adicional. A continuación, se muestran las regiones en las que App Configuration tiene habilitada la compatibilidad con las zonas de disponibilidad. Para más información, consulte Regiones y zonas de disponibilidad en Azure.

A continuación, se muestran las regiones en las que App Configuration tiene habilitada la compatibilidad con las zonas de disponibilidad.

Los almacenes de App Configuration tienen diferentes cuotas de solicitud en función de su nivel. Los almacenes de nivel Gratis están limitados a 1000 solicitudes al día, los almacenes de nivel Estándar a 30 000 solicitudes por hora y los almacenes de nivel Premium no tienen límites de solicitud, lo que garantiza el acceso ininterrumpido.

Los almacenes de App Configuration tienen asignaciones de rendimiento en función de su nivel. Los almacenes de nivel Gratis no tienen un rendimiento garantizado. El nivel estándar almacena la velocidad de ejecución de hasta 300 solicitudes por segundo (RPS) para las operaciones de lectura y hasta 60 RPS para las operaciones de escritura. El nivel Premium almacena la velocidad de ejecución hasta 450 RPS para operaciones de lectura y hasta 100 RPS para operaciones de escritura.

Tomemos un ejemplo y supongamos que tiene una aplicación con 1000 opciones de configuración. La aplicación carga todas esas opciones desde App Configuration al iniciarse. Después, comprueba si hay una clave centinela para los cambios de configuración cada 30 segundos. Independientemente de si se ejecuta en Kubernetes, en App Service o en máquinas virtuales, supongamos que tiene 50 instancias de la aplicación en ejecución simultánea.

En primer lugar, vamos a calcular las solicitudes para la supervisión de la configuración. Cada instancia de la aplicación enviará una solicitud para la clave centinela a App Configuration cada 30 segundos, por lo que enviará 120 (=3600/30) solicitudes en una hora. Dado que tiene 50 instancias de la aplicación, la aplicación envía 6000 (=120x50) solicitudes en total cada hora para la supervisión de la configuración. Tenga en cuenta que, dado que las solicitudes de clave centinela son frecuentes y principalmente no se modifican, la mayoría de ellas no cuentan con los límites de cuota por hora del almacén† para un almacén de nivel Estándar.

En segundo lugar, vamos a calcular las solicitudes de carga o recarga de la configuración. La aplicación carga toda la configuración en el inicio o cada vez que se detecta un cambio de clave centinela. Cada solicitud para App Configuration puede recuperar hasta 100 valores de clave, por lo que necesitará 10 (=1000/100) solicitudes para cargar todas las opciones. Dado que tiene 50 instancias de aplicación, envía 500 (=10x50) solicitudes en total cuando la aplicación se reinicia o vuelve a cargar su configuración.

Por último, vamos a reunirlo. Suponiendo que ha actualizado la clave centinela dos veces en una hora, el almacén de App Configuration recibirá 7000 (=6000+500x2) solicitudes en total en esa hora. Tenga en cuenta que, más allá de estas solicitudes, solo unas 1000 solicitudes (=500x2) usarán la cuota por hora disponible para un almacén de nivel Estándar. Actualice los números de este ejemplo para que coincidan con su configuración y diseño específicos según corresponda, y verá que tiene un búfer suficiente con respecto a la cuota por hora.

†En los almacenes de nivel Gratis no se excluyen las solicitudes frecuentes y repetidas de su límite diario.

Es posible que la aplicación reciba una respuesta con el código de estado HTTP 429 en las siguientes circunstancias:

• Al superar la cuota de solicitudes diarias de un almacén en el nivel Gratis.
• Al superar la cuota de solicitudes por hora de un almacén en el nivel Estándar.
• Al superar la asignación de rendimiento de un almacén en cualquier nivel.
• Al superar la asignación de ancho de banda de un almacén en cualquier nivel.
• Al intentar crear o modificar una clave-valor cuando se ha superado la cuota de almacenamiento.

Compruebe el cuerpo de la respuesta 429 para conocer el motivo específico por el que se produjo un error en la solicitud. También puede recopilar registros para el almacén de App Configuration en Azure Monitor y configurar alertas para la métrica Uso de cuota de solicitudes.

La recepción de respuestas de código de estado HTTP 429 momentáneas normalmente no produce ningún daño, ya que los clientes de App Configuration las controlan correctamente. Pero si la aplicación recibe periódicamente respuestas de código de estado HTTP 429, considere las opciones siguientes:

• Actualizar el almacén al nivel Premium: este nivel no tiene límite de cuota en las solicitudes y ha aumentado la cuota de almacenamiento y una mayor asignación de rendimiento.
• Usar proveedores de App Configuration: los proveedores tienen funcionalidades integradas de reintentos y almacenamiento en caché junto con muchas otras características de resistencia. Asegúrese de actualizar a la versión más reciente del proveedor para todas las mejoras más recientes.
• Usar SDK de App Configuration si la aplicación necesita enviar solicitudes de escritura. Aunque es posible que los SDK no tengan tantas características como los proveedores, vuelven a intentarlo automáticamente en las respuestas de código de estado HTTP 429 y otros errores transitorios.
• Incluir lógica de reintento en clientes personalizados si no puede usar proveedores o SDK de App Configuration. El encabezado retry-after-ms de la respuesta proporciona un tiempo de espera sugerido (en milisegundos) antes de volver a intentar la solicitud.
• Distribuir las solicitudes en varias instancias de cliente: esto ayuda a lograr el rendimiento máximo del almacén de App Configuration.
• Reducir las solicitudes realizadas a App Configuration: siga las instrucciones para minimizar el número de solicitudes.
• Mejorar la resistencia de la aplicación: considere la posibilidad de integrar la replicación geográfica para permitir la conmutación por error y el equilibrio de carga. Consulte los procedimientos recomendados para compilar aplicaciones con alta resistencia.

Todos los almacenes de App Configuration en los niveles Estándar y Premium han habilitado automáticamente la característica de eliminación temporal. Cuando se elimina un almacén de App Configuration de nivel Estándar o Premium, su nombre se reserva para el período de retención. Para volver a crear un almacén con el mismo nombre antes de que expire el período de retención, primero debe purgar el almacén eliminado temporalmente, siempre que el almacén no tenga habilitada la protección de purga. Si la protección de purga está habilitada, debe esperar a que transcurra el período de retención. Use la función de purga o establezca un período de retención más corto si a menudo necesita volver a crear un almacén con el mismo nombre. Los flujos de trabajo que requieren la recreación de un almacén con el mismo nombre deben dejar pasar una hora entre la purga de un almacén de configuración y la posterior creación. Esta recomendación se debe a que, una vez solicitada la purga, la limpieza real de los recursos del almacén de configuración se realiza de forma asíncrona, lo que requiere un poco más de tiempo para finalizar. Para evitar tener que esperar, se recomienda que los flujos de trabajo que crean almacenes de configuración efímeros utilicen nombres únicos.

Todos los almacenes de App Configuration en los niveles Estándar y Premium admiten la característica de eliminación temporal, que no se puede deshabilitar. Puede recuperar un almacén eliminado dentro de su período de retención. Siga estas instrucciones para recuperar un almacén de App Configuration por error.

Sí. Aunque puede administrar marcas de características y referencias de Key Vault en App Configuration a través del Azure Portal o la CLI, también puede crearlas y actualizarlas mediante programación mediante App Configuration SDK. Por lo tanto, puede escribir el portal de administración personalizado o administrarlos en su CI/CD mediante programación. La marca de características y las API de referencia de Key Vault están disponibles en los SDK de todos los idiomas admitidos. Consulte los vínculos de ejemplo para ver ejemplos en cada idioma admitido.

La evaluación y el consumo de marcas de características en la aplicación requiere el proveedor de App Configuration y las bibliotecas de administración de características, que están disponibles en .NET y Java Spring. Consulte la sección Administración de características en Inicios rápidos y tutoriales para obtener más información.

Los perfiles de Spring proporcionan una manera de separar partes de la aplicación, incluida la configuración, y hacer que solo esté disponible en determinados entornos o cuando se usen bibliotecas específicas.

Se recomienda establecer la etiqueta de los pares clave-valor para que coincidan con los perfiles de Spring. De manera predeterminada, la biblioteca de proveedores Spring de App Configuration cargará los pares clave-valor con las etiquetas que coincidan con los perfiles de Spring activos actuales (${spring.profiles.active}) si el filtro de etiqueta no se establece explícitamente. Si no hay ningún conjunto de perfiles de Spring activo, se cargarán los pares clave-valor con el mensaje "sin etiqueta".

Por ejemplo, con perfiles los dev y prod, se crean los pares clave-valor según corresponda con las etiquetas siguientes.

Cuando el perfil de Spring se establece en dev, el valor de config.message será Hello from dev. Cuando el perfil de Spring se establece en prod, el valor de config.message será Hello from prod.

Este comportamiento predeterminado se puede invalidar estableciendo el filtro de etiqueta en el archivo de arranque. La biblioteca de proveedores Spring cargará los pares clave-valor con las etiquetas especificadas independientemente del perfil de Spring activo.

spring.cloud.azure.appconfiguration.stores[0].selects[0].label-filter: my-label

Para seleccionar otras etiquetas y los perfiles de Spring, puede usar un filtro de etiqueta como ',${spring.profiles.active}', que seleccionarán todas las claves sin una etiqueta y las que coincidan con los perfiles de Spring. Las etiquetas más a la derecha tienen prioridad cuando se encuentran claves duplicadas.

A partir de la versión 3.1.0, la biblioteca Microsoft.FeatureManagement permite ejecutar servicios de administración de características, incluidos filtros de características, como servicios con ámbito en aplicaciones .NET basadas en inserción de dependencias. Para aprovechar esta característica, simplemente puede reemplazar la llamada AddFeatureManagement en el código por AddScopedFeatureManagement, como se muestra en el siguiente fragmento de código:

services.AddScopedFeatureManagement();

Los filtros de características pueden evaluar una marca de característica en función de las propiedades de una solicitud HTTP. Normalmente, esto se realiza inspeccionando HttpContext a través del patrón IHttpContextAccessorsingleton. Sin embargo, este patrón no funciona para las aplicaciones del servidor Blazor en las que se deban usar los servicios con ámbito en su lugar. En este caso, se debe usar el método AddScopedFeatureManagement.

Suscríbase a nuestro repositorio de anuncios de GitHub.

Puede comunicarse con nosotros directamente en GitHub.

• Acerca de Azure App Configuration