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.

Este límite 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 más información, consulte Azure subscription and service limits (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 dos planes de tarifa:

• Nivel Gratis
• Nivel estándar

Si ha creado un almacén antes de la introducción del nivel Estándar, este se mueve automáticamente al nivel Gratis cuando está disponible con carácter general. Puede optar por actualizar al nivel Estándar o continuar en el nivel Gratis.

No se puede degradar un almacén del nivel Estándar al nivel Gratis. Puede crear un nuevo almacén en el nivel Gratis y luego importar los datos de configuración en ese almacén.

Ambos niveles de App Configuration ofrecen funcionalidad básica, incluidos los valores de 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.

• 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 gratuito. Las suscripciones pueden tener un número ilimitado de almacenes de configuración en el nivel Estándar.

• Almacenamiento por recurso: en el nivel gratuito, 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 1 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, el historial se almacena durante siete días. En el nivel Estándar, el 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. Cuando se agota la cuota por hora, las solicitudes pueden devolver el código de estado HTTP 429, que indica que hay demasiadas solicitudes hasta que finalice 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.

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

• Características: ambos niveles incluyen funcionalidades, incluido el cifrado con claves administradas por Microsoft, la autenticación a través de la clave de acceso o Microsoft Entra ID, el control de acceso basado en rol (RBAC) de Azure, la identidad administrada, las etiquetas de servicio y la redundancia de zona de disponibilidad. El nivel Estándar ofrece 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: Los almacenes del nivel Estándar tienen un cargo de uso diario. Las primeras 200 000 solicitudes de cada día se incluyen en el cargo diario. También hay un cargo por uso por encima del límite por las solicitudes más allá de la asignación diaria. El uso de un almacén del nivel Gratis no supone ningún costo.

Puede actualizar desde el nivel Gratis al nivel Estándar en cualquier momento.

No se puede degradar un almacén del nivel Estándar al nivel Gratis. Puede crear un nuevo almacén en el nivel Gratis y, a continuación, importar los 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 configuración del nivel Gratis están limitados a 1000 solicitudes al día. Los almacenes de configuración del nivel estándar pueden experimentar una limitación temporal si la velocidad supera las 30 000 solicitudes por hora.

Cuando un almacén alcanza su límite en el nivel estándar, puede devolver el código de estado HTTP 429 con algunas de las solicitudes realizadas hasta que termine la hora. El encabezado retry-after-ms de la respuesta proporciona un tiempo de espera sugerido (en milisegundos) antes de volver a intentar la solicitud.

Si la aplicación recibe periódicamente respuestas de código de estado HTTP 429, considere la posibilidad de rediseñarla para reducir el número de solicitudes realizadas. Para obtener más información, consulte Cómo reducir las solicitudes realizadas a App Configuration.

Recibirá una respuesta con el código de estado HTTP 429 en estas circunstancias:

• Superación del límite de solicitudes diarias de un almacén en el nivel Gratis.
• Superación del límite de solicitudes por horas de un almacén en el nivel estándar.
• Limitación momentánea debido a una gran ráfaga de solicitudes†.
• Limitación momentánea debido al uso excesivo de ancho de banda†.
• Intento de crear o modificar una clave 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.

†Un almacén de configuración puede experimentar una limitación momentánea si recibe una gran ráfaga de solicitudes o transfiere un volumen excesivo de datos. Los clientes de App Configuration, como el SDK de Azure, las bibliotecas del proveedor de configuración y las tareas de Azure Pipeline, se reintentan automáticamente en las solicitudes limitadas. En el caso de las aplicaciones que usen uno de estos clientes o un cliente personalizado que vuelve a intentar las solicitudes limitadas, esta limitación momentánea debe pasar desapercibida, en caso de que se produzca.

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. Ten en cuenta que como las peticiones de claves de Sentinel son frecuentes y no suelen cambiar, la mayoría de ellas no contarán para los límites de cuota horaria del almacén†.

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. 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 al límite por hora. Para obtener más información, consulte Cómo reducir las solicitudes realizadas a App Configuration.

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

Todos los almacenes de App Configuration en el nivel estándar han habilitado automáticamente la característica de eliminación temporal. Cuando se elimina un almacén de App Configuration de nivel estándar, 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 el nivel estándar 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