1. Gestión de la configuración
en aplicaciones web
Dr. Pedro J. Molina @pmolinam
Málaga, 2022.11.12

2. Dr. Pedro J. Molina
@pmolinam https://linkedin.com/in/pjmolina

3. Agenda
▪ Entornos
▪ Gestión de la configuración
▪ Tipos de configuración
▪ Segregación de responsabilidades
▪ Herramientas e inercia
▪ Inyección en tiempo de compilación vs
despliegue

4. Entornos
▪ LOCAL, DES, PRE, QA, PRO, etc.
▪ Independientes
▪ HW y dependencias físicas probablemente diferentes

5. Tipos de configuración
Mantenidaspor el desarrollador
Dependendelcódigo
Sefijanentiempodecompilación
▪ Versionesde librerías
▪ Configuración interna de aplicación
▪ Des/habilitación de características según su
madurez
▪ Configuración dependiente del HW
▪ URLs internas de aplicación
▪ Etc.
Mantenidaspor el operador
Dependendelentorno
Sefijanendespliegueocambianenoperación
▪ IPs, nombresDNS de servicios dependientes
▪ Usuarios, contraseñas
▪ Cadenas de conexión a BD
▪ Claves criptográficas
▪ Volúmenes y rutas a disco
▪ Cuotas: limitaciones de memoria, CPU, E/S y disco
▪ Habilitar/Deshabilitarcaracterísticas: A/B testing

6. Problema habitual
▪ Cuando aparecenmezcladas
▪ Mismo mecanismo
▪ Fichero o variable de entorno
Porque:
1. Fugan credenciales (inyectadas en compilación)
2. Exponen la complejidad de la conf. interna al operador, provocando errores de despliegue
(configuración incompleta, invalida o desfasada)
3. Un cambio de configuración externa → implica un redespliegue (cuando no debería) → más
lento

7. Gestión de la configuración
▪ Auditoria y control de los recursos de una organización
▪ Versionado
▪ Manifiesto 12 Factor Apps. https://12factor.net/es/
▪ Recomendación I. Basedecódigoúnicasobre laquegenerarNdespliegues
▪ Recomendación III. Guardarlaconfiguraciónenelentorno
▪ Recomendación V. SepararcompletamentelasetapasdeConstruir,distribuiryejecutar

8. Rec. I. Base de código única desde
donde construir versiones
▪ Versionado: SemVer para las publicaciones (release)
https://semver.org/lang/es/
<mayor>.<menor>.<parche>
LOCAL DES PRE PRO

9. Rec. III. Guardar la configuración en el entorno
▪ Entorno ➔ Fuera de la aplicación
▪ Variables de entorno (SO)
▪ Ficheros
▪ Servicios de configuración
Entorno
Aplicación
desplegada
CI

10. Rec. V. Separar construcción, distribución
y despliegue
▪ Construir: CI
▪ Distribución: repositorios de versiones
▪ Despliegue: Instalación en 1 entorno
Entorno E1
Aplicación
desplegada
CI

11. Segregación de Responsabilidades
▪ Principio de seguridad: SegregationofDuties
▪ Ejemplo: Elque emite recibe lafactura esdiferente alque paga.
▪ En IT, donde la seguridad es importante:
▪ El desarrollador no conoce las claves de producción (y no suele tener acceso de
admin, salvo para acciones puntuales).
▪ El operador/administrador no desarrolla (evita caballos de troya)
▪ Son personas diferentes, con permisos en la organización diferentes

12. Herramientas e Inercia
▪ Visual Studio permite diversos Web.config paraNentornos(selecciónen
tiempode compilación)
▪ Angular permite Nentornos (selecciónentiempodecompilación)
▪ Cómodo para de desarrollador, pero contraproducente para la
seguridad y despliegues bien gestionados
▪ Porqué:
1. La configuración acaba dentro del repositorio de código
2. Permite la fuga de credenciales, impidiendola segregación de
responsabilidades
3. Son ficheros que se combinanen tiempo de compilación (demasiadopronto)
4. El desarrollador no tiene porque saber nada del entorno final donde corre la
aplicación (entorno desconocido)
Tiempo de compilación

13. Soluciones
▪ Separar la configuracióninterna de la externa
▪ Inyectar la interna en tiempode compilación
▪ Inyectar la externa en tiempo dedespliegue u operación
▪ Permitir cambios en caliente si lo necesitamos: p.e. ajustes a
A/B Testing
▪ Aplicacionesweb SPA. Inversión decontrol.
▪ Hacer que el backend proporcione TODA la configuración
externa al SPA.
▪ SPA = JS, se puede depurar en el navegador. Toda su
configuración es potencialmente visible → no debe contener
ninguna credencial privada.
CI
Entorno E1

14. Alternativas: SPA
Mecanismo de configuraciónen tiempo de ejecución(inicialización)
▪ Angular:https://juristr.com/blog/2018/01/ng-app-runtime-config/
1. Embebidoen código ❌ No puedes cambiarlo
2. Fichero JSON en /assets ❌ Obliga a reescribir el fichero tras despliegue
3. Descargadodesde un servicio GET/spa-config
✅ Más flexible

15. GET /spa-config
Navegador envía cabeceras HTTP
GET https://api.acme.com:876/api/spa-config
origin: https://spa1.qa.acme.com:456/
remote-address: 67.45.34.213:456
accept-language: es-ES,es;q=0.9,en-US;q=0.8,en;q=0.7
Servidor evalúa y retorna
origin: ¿Autorizado para CORS? sí/no
La URL determina el entorno (QA)
remote-address: Geo-IP → Provincia, País → A/B Testing
Seguridad / Baneo de IPs
accept-language: Preferencia de idioma del cliente (i18n)
{
"env": "qa",
"audience": "https://id.qa.acme.com",
"clientId": "spa1-qa",
"user-lang": "es-ES",
"lang-resources": "https://cdn.acme.com/i18n/es-ES.json",
"branding": "https://cdn.acme.com/red-acme",
"feature-a": true,
"feature-b": false
}

16. Alternativas: Backend
1. Fichero (e.j. appsettings.json) ❌ Requiere reescritura
2. Persistido en base de datos ❌ Requiere cadena de conexión
3. Variables de entorno ✅ Flexible. Estándar en contenedores
4. Servicio de configuración ✅ Más Flexible. A/B Testing
ejemplo: Consul

17. Montaje completo
GET/spa-config
Entorno E1
API
Integración congit

18. ¿Preguntas?
Código demo:
https://github.com/pjmolina/configuration-management-demo
Cenv:
https://github.com/metadevpro/cenv

19. ¿Más Preguntas?
Seguimos después en:
Twitter: @pmolinam
Linkedin: https://linkedin.com/in/pjmolina