1. Introducción
Uno de los grandes problemas a resolver por los equipos de desarrollo, integradores y DevOps es cómo coordinar despliegues complejos. Esto es así sobre todo en los casos en los que intervienen diferentes tecnologías, lenguajes, plataformas y sobre todo, equipos de personas.
Además, hay que lograrlo sin tener pérdida de servicio (poderlos realizar, en la mayoría de los casos, fuera de las ventanas de mantenimiento… ¡los informáticos hacemos lo que sea para no trabajar los sábados!).
En Santander Global Tech estamos acostumbrados a este tipo de despliegues debido a la gran variedad de sistemas en los que funciona el software de los aplicativos bancarios con éxito.
En este artículo queremos mostrar cómo conseguimos que dichos despliegues lleguen a buen puerto en el 99% de los casos… y para ese 1% existe una contingencia con resolución inmediata. Para ello usaremos la conocida técnica de shadowing, es decir, se despliega en un entorno productivo pero no visible para el cliente final, donde se puede evaluar que el software y su configuración funciona de forma correcta.
Existen otras muchas formas de realizar la comprobación del software (blue-green, A/B Testing o canary). Se ha elegido esta forma para poder integrar de una forma más sencilla las diversas tecnologías e infraestructuras, ya que no todas permiten dichas técnicas más modernas o complicaría su integración y estar 100% seguros que funciona de forma correcta antes de abrirlo al cliente.
A lo largo del documento plantearemos la teoría y usaremos un ejemplo práctico para entenderlo mejor, en el que intervendrán servidores WAS y PaaS, en un entorno de alta disponibilidad Activo/Activo, que hablan entre ellos tanto vía navegación como Web Services.
En nuestro ejemplo detallaremos cómo gestionar las distintas tecnologías para que se traten como si fuese una sola, e integrarlas para las pruebas del usuario en el entorno oculto como si fuese un entorno real final integrado.
Hay que tener en cuenta que también se disponen de entornos de DEV y PRE previos para realizar UATs más extensas y sin tanta parafernalia, y realmente lo que se describe en este artículo se realiza en PRO para poder realizar una prueba de satisfacción tanto técnica como funcional, que permite asegurar que el software y su configuración se abrirán al público sin errores evitables (como por ejemplo, errores de conectividad).
2. Requisitos previos
2.1. La infraestructura, gran parte del éxito
Para poder dar un servicio continuo, resiliente y realizar despliegues sin pérdidas de servicio, así como poder disponer de alta disponibilidad Activo/Activo, es necesario usar la misma estrategia que la NASA: tener todo por duplicado.
Por ejemplo, respecto a la infraestructura IAS (servidores dedicados), en producción se disponen de dos clusters con dos servidores cada uno (y cada servidor de cada cluster en un CPD distinto). En cada uno se puede ejecutar una o varias instancias WAS por ejemplo, según los requerimientos de carga del entorno.
En cuanto a las infraestructuras PaaS con, por ejemplo, Openshift, igualmente se usan dos clusters distintos en distintos CPDs, y al menos dos PODs por servicio en cada cluster (normalmente cada POD se ejecuta en una máquina física distinta, ganando resiliencia).
Como resumen, se dispone de al menos cuatro elementos que pueden dar servicio en modo Activo/Activo, y se asegura mediante pruebas de carga que la mitad de esta infraestructura es capaz de soportar la carga total necesaria para dar un servicio óptimo. Y que en caso de una caída inusual de una máquina física o bien un CPD entero, el servicio no se interrumpiría.
En todos los casos un balanceador se encarga de gestionar la capa TLS. Este elemento de red permitirá hacer el cambio de DNS para evitar la pérdida de servicio y permitir verificar la calidad del software.
En términos genéricos, esta sería la infraestructura que permitiría disponer de una Alta Disponibilidad, además de permitirnos realizar los pases de forma más segura:
Pongamos aquí la infraestructura necesaria para nuestro ejemplo:
Llamaremos “Oculto” al primer cluster, que será la parte que primero se “ocultará” al usuario final para poder actualizar el software y realizar las pruebas mientras que “Real” (el segundo cluster) dará servicio.
A lo largo del documento se irá ilustrando cómo se configurará el balanceador para hacer dicho juego.
2.2. Un truco: DNS específicos para la tarea
Existen varias aproximaciones para solucionar el problema de tener que dar servicio mediante varias tecnologías para una misma aplicación. ¡De alguna forma hay que saber hacia dónde han de dirigirse las peticiones!
Una de ellas es usar un subdominio DNS (dominio de tercer o mayor nivel) distintos para una de las tecnologías, y la otra puede ser usar path en la URL que distingan hacia qué servidores se ha de dirigir (configurándolo en el balanceador, un proxy inverso o un gateway ligero).
En nuestro ejemplo elegiremos la primera forma, aunque es sencillo aplicar a la segunda (simplemente, por ejemplo, el nombre del subdominio sería el primer nivel del path de la URL).
Esto lo usaremos para poder realizar correctamente toda la UAT (las comúnmente llamadas pruebas de usuario), de forma que es necesario disponer de DNSs apuntando a cada entorno de cada sistema para que se puedan realizar las pruebas de forma integrada.
Como es normal, dispondremos de nuestra DNS que dará servicio a nuestra aplicación (por favor, no le pongáis pegas a los nombres ¡es un ejemplo! Para vuestras aplicaciones usar nombres más molones adecuados).
En nuestro caso concreto, usaremos dos, una para cada tecnología: serviciowas.miaplicacion.com y serviciopaas.miaplicacion.com
Adicionalmente necesitamos al menos crear otras 2 por cada tecnología (una por cluster):
- ocultowas.miaplicacion.com
- realwas.miaplicacion.com
- ocultopaas.miaplicacion.com
- realpaas.miaplicacion.com
Pintado en la arquitectura se entiende mejor:
Realmente todas los subdominios DNS apuntan al balanceador y éste es el que sabe que servicioxxx ha de apuntar a ambos clusters, ocultoxxx ha de apuntar al cluster 1 y realxxx ha de apuntar al cluster 2. Lo dejamos pintado así por clarificar.
2.3. Además, nuestro ingrediente secreto… pipelines multistep
Ahora, por favor, silencio, vamos a proceder a presentar a… ¡nuestro ingrediente secreto!
Una de las claves para poder realizar estos pases de la forma más desentendida posible es el uso de pipelines multistep.
¿Y qué significa eso?
Que se definen los ficheros de los despliegues en varios pasos. Así se pueden dar instrucciones de ejecución paso a paso, lo cual permite lanzar diferentes configuraciones o diferente software en cada uno de los pasos, marcando los avances un proceso orquestador o un humano lanzándolo manualmente.
La estructura de uno de los ficheros es la siguiente:
steps:
– name: Oculto
next: PrepararOcultoBalanceo
deploys:
– deploy:
[…]
– deploy:
[…]
– name: PrepararOcultoBalanceo
previous: Oculto
next: OcultoEnBalanceo
deploys:
– deploy:
[…]
[…]
De esta forma se puede indicar qué acciones se han de realiza en cada paso de forma automática.
Por ejemplo, en el primer paso se pueden bajar el número de PODs, sacar Oculto del Servicio en un Balanceador o configurar ciertos IAS de una manera específica.
Para pasar al siguiente paso (o al anterior si algo ha salido mal), simplemente se lanzaría eso, el siguiente paso o el anterior, nombrándolo o siguiendo un orden “siguiente” o “anterior” en el gestor de despliegues al uso (ejemplo, UrbanCode o Jenkins/Cloudbee).
3. Pasos de despliegue
Después, la estrategia de despliegue es lo que permite realizarlo de forma ordenada y permite realizar el test del nuevo software en un entorno controlado ¡y sin parada de servicio!.
Estos serían los pasos que seguiríamos…
3.1. Despliegue en Oculto
En este paso aislaremos los clusters de oculto para poder desplegar el software y su nueva configuración, de forma que cualquier cambio que hagamos no pueda ser visto por los clientes finales. Pero se podrá probar el software nuevo.
Estos serían los pasos a seguir:
- Balanceadores: Sacar Cluster de Oculto del Servicio y deja Real dando Servicio
- Configuración WAS: Configuración para usar en Oculto (Modificar para apuntar a DNSs de Oculto, por ejemplo, redirecciones, logins, WS).
- Despliegue WAS: Desplegar el software y configuración del WAS en los clusters Oculto.
- Configuración PaaS: Desplegar Ficheros de configuración y secrets. Se pueden desplegar en Oculto y Real (en nuestro caso están versionados por lo que aunque se instalen en Real no se usan hasta que se despliegue el nuevo SW, ya que se indica la versión a usar en los Enviroments de los PODs)
- Despliegue PaaS: Desplegar todos los servicios (ej. Angular y Springboot) a desplegar en Oculto con los secrets configurados apuntando a Oculto.
- Shakedown Oculto
Y así quedará nuestra arquitectura:
La parte de oculto ya no dará servicio y se accederá a través de los subdominio ocultoxxx. Al estar todo configurado apuntando a los dominios ocultoxxx, se podrá navegar por la aplicación como si ese fuese su dominio “de servicio” y los testers podrán probar su entorno de una manera más natural.
Es importante configurar el software para que todas las URL a las que llame sean las de ocultoxxx tanto las de navegación como las llamadas a posibles servicios (por ejemplo, web services) para que la experiencia sea totalmente “probar el software y configuración nuevas”.
3.2. Preparación de Oculto para dar Servicio
Una vez probado integrado que funciona bien el software, se configura a donde ha de apuntar realmente, a las DNS de servicio, y que no hay problemas antes de dar servicio.
Estos son los pasos que se seguirán en esta parte del pase:
- Configuración WAS: Configuración para usar dando Servicio (Modificar para apuntar a DNSs de Servicio, por ejemplo, redirecciones, logins, WS).
- Despliegue PaaS: configurar todos los servicios (ej, Angular y Springboot) con los secrets configurados apuntando a Servicio (tal y como funcionará).
- Shakedown Oculto preparado para dar Servicio
En este punto se prueba el entorno que funciona tal cual estará en PRO. Se pruebas conectividades y redirecciones, que son las correctas para el futuro entornos productivo.
Así queda la arquitectura del ejemplo:
Este punto es importante y se ha de configurar el software para que todas las URL a las que llame sean las de servicioxxx tanto las de navegación como las llamadas a posibles servicios (por ejemplo, web services) para que cuando entre en servicio tenga ya la configuración correcta.
3.3. Meter Oculto en Servicio
En este punto el software nuevo pasa a dar servicio.
Al ser un cambio instantáneo en el balanceador, no hay pérdida de servicio.
Estas son las tareas:
- Balanceadores: Meter a dar servicio el cluster de Oculto y sacar el custer de Real del Servicio
- Shakedown de servicio
- Esperar varios días
Así quedaría la arquitectura de nuestro ejemplo:
Tras este punto se suele esperar unos días (se suele decir que “se deja en barbecho”), por si hubiera algún problema, se puede revertir de una forma inmediata.
La forma de revertir es volver a apuntar el Balanceador como estaba en el punto anterior, es decir Real dando Servicio. Esta marcha atrás es inmediata y dejaría de nuevo funcionando el software y configuración anterior ante cualquier problema grave.
Aunque está la mitad de la infraestructura dando servicio, ésta está dimensionada para dar soporte al uso normal e incluso picos puntuales sin retrasos significativos en la respuesta.
3.4. Despliegue en Real
Ahora toca nivelar los dos clusters, es decir, dejar la misma configuración y software que hay en Oculto. Seguiremos la misma estrategia, aunque en este caso Real ya está sin dar servicio.
Por tanto, lo que se ha de realizar es desplegar el software en las celdas de Real y su configuración apuntando a los DNS de Real (realxxx).
Estas son las tareas:
- Configuración WAS: Configuración para usar en Real (Modificar para apuntar a DNSs de Real, por ejemplo, redirecciones, logins, WS).
- Despliegue WAS: Desplegar el software y configuración del WAS en los clusters Real.
- Despliegue PaaS: Desplegar todos los servicios (ej. Angular y Springboot) a desplegar en Oculto con los secrets configurados apuntando a Real.
- Shakedown Real
La arquitectura de ejemplo quedaría así:
Nuevamente se realizan unas pruebas mínimas de conformidad y algunas técnicas de verificación de conectividades, de forma integrada entre los dos sistemas.
3.5. Preparación de Real para meter en Servicio
Una vez comprobado que el software en los cluster de Real funciona de forma correcta, se ha de preparar la configuración para dar servicio.
Estas serían las tareas:
- Configuración WAS: Configuración para usar dando Servicio (Modificar para apuntar a DNSs de Servicio, por ejemplo, redirecciones, logins, WS).
- Despliegue PaaS: configurar todos los servicios (ej, Angular y Springboot) con los secrets configurados apuntando a Servicio (tal y como funcionará).
- Shakedown Real preparado para dar Servicio
Para ello se le aplica la configuración con los DNS apuntando a Servicioxxx y se comprueba que es correcto.
Así quedaría:
Y por fin ya estaríamos listos para el último paso…
3.6. Meter Real en Servicio
Ya siendo el último paso, los cluster de real pasan a dar servicio, con lo cual, ya volvemos a la situación inicial, pero con el nuevo software desplegado.
Estas serían las tareas:
- Balanceadores: Meter a dar servicio el cluster de Real (el custer de Oculto ya está dando Servicio)
- Shakedown de servicio
- Fin del pase y agradecer el resultado a los equipos participantes
Así queda la arquitectura al final:
Con ello nuestro software estará listo para dar servicio a plena potencia y esperando un nuevo pase.
4. Recomendaciones y próximos pasos
Y nuestra última recomendación, pero no por ello menos importante… la preparación y la documentación del pase a producción.
Parece obvio, pero es fundamental planificar el pase lo más detalladamente posible y dejar lo menos posible a la improvisación.
También ponerse en contacto con los departamentos que participarán en el pase, para determinar si consideran que falta algún punto a realizar o si se les puede anticipar datos que puedan necesitar.
Por ello, todas las tareas que se puedan adelantar han de adelantarse, sobre todo si requiere configuraciones especiales que tarden en realizarse o los equipos de ejecución necesitan de datos de terceros departamentos.
Ejemplos que pueden retrasar un pase a producción y llevarlo al traste: reglas de firewall, usuarios o client id/client secrets de WS o APIs, accesos a terceras aplicaciones, certificados de CAs de los destinos, certificados de cliente si son necesarios, permisos en directorios…
Todos esos puntos son sencillos de pedir de forma adelantada a los equipos correspondientes. También en muchos casos poder realizar una prueba de verificación antes del pase (por ejemplo, pidiendo una simple ejecución desde la máquina origen hacia la máquina destino se verificará la conectividad ahorrándonos muchas sorpresas).
Por ello en pases especialmente complejos o donde se requieran configuraciones nuevas o especiales, una rápida reunión con los departamentos de coordinación y ejecutores mostrando los pasos que quieren realizarse y describiendo las acciones a realizar, puede adelantar problemas que quizá de otra forma nos podríamos encontrar y retrasar el pase.
Además, otra máxima a seguir es la de “indica las instrucciones como te gustaría recibirlas a tí”. Es decir, indicar las tareas sin ambigüedades, de la forma más precisa y completa y como a ese equipo le gusta recibirla.
De esa forma no habrá confusiones, preguntas de última hora por no tener la información adecuada o errores en la ejecución.
Una buena práctica es disponer de un documento en el cual se indica en un resumen todos los pasos a realizar y en qué orden, y un apartado con la descripción detallada de cada uno de los puntos a realizar.
Ejemplo sencillo:
Pase 22333 de la aplicación “Mi aplicación”
Orden de tareas:
- Configurar WS
- Modificar fichero configuración Config.xml
Detalles
- Configurar WS
Configurar un nuevo WS en la configuración de la aplicación “Mi aplicación” ubicado en el servidor miservidor.corp.
La URL es https://app.otraapp.es/aplicacion/ en la cual se usarán las credenciales proporcionadas previamente por XXXXX en el hilo de correo “Contraseñas de WS otraapp”.
2. Modificar fichero configuración Config.xml
Modificar para la aplicación “Mi aplicación” ubicada en el servidor miservidor.corp, el fichero /configs/config.xml.
Editar el tag <idioma>:
Ahora contiene:
<idioma>es</idioma>
Y cambiar el contenido por: <idioma>en</idioma>
Este sencillo documento, además de facilitar las tareas del pase a los equipos, sirve como ejercicio de planificación y permite además determinar posibles carencias antes que se produzcan.
Lógicamente, usar una herramienta de coordinación de los pases y peticiones es de gran ayuda a la hora de gestionarlo, por ejemplo Remedy o Service Now.
Dentro de los siguientes pasos, si bien en Santander Global Tech la gran mayoría de las tecnologías ya pueden desplegarse con una CI completa y muchas de las tareas están automatizadas o semiautomatizadas, en Santander Global Tech se está trabajando duramente en conseguir una CI íntegra incluso en este tipo de pases multiplataforma complejos, minimizando las tareas manuales y permitiendo que los pases sean totalmente automáticos, mediante procesos coordinadores de los distintos pipelines que intervienen en las CIs.
Con ello se llegará a automatizar incluso los pases más complejos sin apenas intervención humana.
No se puede terminar este artículo sin agradecer a todos los equipos que permiten que este tipo de pases tan complejos siempre lleguen a buen fin, pues sin su gran conocimiento, dedicación y entusiasmo no sería posible: Gestión del Cambio, Soporte Despliegues, Sistema Web, DevSecOps, Red de datos, Establecimiento de servicio y tantos otros que participan puntualmente pero fundamentales y trabajando como un único gran equipo permiten este éxito continuo.
Santander Global Tech es la empresa de tecnología global, parte de la división de Technology and Operations (T&O) de Santander. Con más de 2.000 empleados y basada en Madrid, trabajamos para convertir al Santander en una plataforma abierta de servicios financieros.
Mira las posiciones que tenemos abiertas aquí para unirte a este equipazo y Be Tech! with Santander ?
Síguenos en LinkedIn y en Instagram.
Rubén Rodríguez Martín
Santander
Ingeniero Informático que lleva programando desde los 10 años, usuario y administrador en internet desde el 96, especialista en desarrollo del software, sistemas, redes, seguridad, domótica, despliegues complejos, PaaS… y un gran aficionado a las nuevas tecnologías, optimizar procesos, la innovación, la ciencia ficción ¡y mucho más!
