Gestionando la configuración de nuestras aplicaciones (1/x)

 

Nuestras aplicaciones requieren valores de configuración para funcionar correctamente en cada uno de los entornos disponibles (producción, staging, etc…).

 

Estas configuraciones pueden ser clasificadas en diferentes tipos, vamos a verlo con un ejemplo. Imaginad una aplicación que tiene que hacer una llamada a un API tercero, un sistema de compra de tickets por ejemplo. Vamos a necesitar tres variables de configuración:

 

• La url del servicio
• El tiempo que esperaremos por la respuesta del servicio antes de asumir que falla y actuar en consecuencia
• El API key necesario para invocar el servicio

 

Si nos paramos a analizar las tres variables, vamos a ver que podemos clasificarlas en tres tipos bien diferenciados:

 

• Valores de configuración que no dependen del entorno (tiempo que esperaremos por la respuesta del servicio)

 

• Valores de configuración que si dependen del entorno, como la url del servicio, que podría variar para hacer pruebas (apuntando a un entorno no productivo).

 

• Secretos, como el API key, que debemos proteger y no deben estar guardados en claro en ficheros.

¿Cómo gestionamos estas variables?

 

Si hablamos de .NET (empezando en la primera versión de NET core) podríamos pensar en ficheros de configuración json, que de un modo sencillo nos permitirán dar valores para cada entorno:

 

• appsetting.json
• appsettings.<environmentName>.json

 

 

En el primer fichero estarán todas las variables de configuración. Además podemos crear ficheros adicionales que sobrescriban los valores para cada entorno deseado: appsettings.Staging.json o appsettings.Production.json por ejemplo.

 

¿Cómo se fija en que entorno estamos?

 

Por defecto estaremos en el entorno Production. Podemos fijar otro entorno seteando una de las siguientes variebles de entorno:

 

• DOTNET_ENVIRONMENT
• ASPNETCORE_ENVIRONMENT

 

Dependiendo de tipo de aplicación y la versión de .NET debemos usar una u otra, no es el objetivo de este post entrar a verlo en detalle, aquí os dejo la documentación oficial: https://learn.microsoft.com/en-us/aspnet/core/fundamentals/environments?view=aspnetcore-7.0

 

Con lo anterior, resolvemos de un plumazo la configuración por cada entorno, cumpliendo además el tercer factor promulgado por 12-factor app, que indica que la configuración debe guardarse en el entorno:Store config in the environment.

 

Pero aún tenemos un problema: los secretos

 

¿Cómo gestionamos los secretos?

 

Desde luego no pueden estar en ficheros de configuración que guardemos en nuestro repositorio de código fuente. ¿Imagináis una cadena de conexión de Azure Storage publicada en GitHub? Los malos ya tendrían su Cloud drive infinito, a tu costa :-(

 

Podríamos tener las variables en los ficheros sin valores reales, y reemplazar sus valores en tiempo de despliegue en nuestra herramienta de CI/CD (Github Actions o Azure DevOps son mis preferidas), es algo que se ha venido haciendo mucho. Sin embargo, aunque las herramientas de CI/CD pueden guardar secretos, carecen de la seguridad y las características avanzadas que proporcionan herramientas específicas como Azure Key Vault o HashiCorp Vault.  Por dar una pincelada, rotar un secreto con Azure Key Vault no es tan doloroso como hacerlo con secretos de la herramienta CI/CD.

 

Además, no nos engañemos: guardar un secreto en Azure Pipelines, y aplicarlo al fichero de configuración al desplegar hace que el secreto acabe guardado en claro un archivo.

 

Espero que os haya resultado de interés, continuaré profundizando en la configuración, con otro artículo en el que usaremos dos herramientas para gestionar la configuración de nuestras aplicaciones de un modo centralizado: Consul y Azure App configuration.

 

¡Hasta la próxima!