Una infraestructura Agil.

La infraestructura básica para poder realizar un despliegue continuo de aplicaciones, tanto para empresas de desarrollo como empresas de hosting seria, a mi juicio, el siguiente:

1. un orquestador de contenedores: como k8s, RancherosTm Openshift Container Tm, etc; que nos permitirá desplegar aplicaciones de entornos Unix de forma eficiente, 

2. un SCM, los hay bastante conocidos: Github, Gitlab, etc; donde almacenamos el código de las aplicaciones, los "playbooks" de ansible, información de seguridad, información de configuración de: red, "workers", etc

3. Un software de automatización de despliegue de aplicaciones tal como: "Jenkins", etc, 

4. Un software de automatización de gestión de la configuración como: "Ansible Tower Tm", "Rundeck";

5. Un software de despliegue de sistema operativos como: WSD (Windows), o FAI (Linux)

6. Un software de registro de imágenes de contenedores y objetos compilados como: Artifactory Tm; o similares

7. Un sistema centralizado de logs donde localizaremos toda la información de los logs de: las aplicaciones, los servidores (sus métricas y elementos de seguridad), y los eventos de seguridad para SIEM,

8. Un sistema de validación de usuarios centralizado, 

9. Un DNS tambien centralizado. 

Todo lo anterior se puede desplegar en un entorno "on-premise" (directamente sobre servidores) o en entornos virtualizados como: VmwareTm, Xen, kvm; 

Distinguiremos entre:

1. el despliegue de los workers de Linux / Windows para dar soporte a los contenedores, tanto físicos como virtualizados. Los "workers" físicos/virtualizados se instalarán con:

    1. WSD (caso de los WindowsTm) , sistemas con hyper V 

    2. FAI (caso de los Linux)

    3. Se configurarán con ansible (linux / Windows) y/o PowerShell

El código de ansible / PowerShell estará almacenado en el SCM y será invocado por Ansible Tower Tm

2. los mecanismos de CI de las aplicaciones almacenadas en el SCM y el despliegue de las imágenes con los productos de software compilados en los diferentes entornos definidos. Para ello distinguiremos:

    a. Los mecanismos de "Continous Integration" (CI) de las aplicaciones, desde el código fuente hasta tener un objeto compilado/imagen construida de forma exitosa a partir del código fuente de los proyectos, aquí tenemos que diferenciar entre código compilado y código interpretado, definiendo pasos diferentes según sea el lenguaje, para:

        1. compilado, tendremos que:

            a.  revisar el código (pruebas unitarias) para asegurar su calidad, 

            b. compilar el objeto de software

            c. subir el objeto de software al registro de objetos (ArtifactoryTm o similar)

            d. construir con éxito la imagen del contenedor que contendrá el objeto

            e. subir esta imagen al registro de imágenes del sistema

            f. revisar con un sistema de escaneo de seguridad la imagen subida

        2. un interpretado tendremos que:

            a. revisar el código (pruebas unitarias)

            b. construir, con éxito, la imagen del contenedor de la aplicación

            c. subir esta imagen al registro de imágenes del sistema 

            d. revisar con un sistema de escaneo de seguridad la imagen subida

    b. Los mecanismos de "Continous Deploy" de las aplicaciones, desde los objetos / imágenes, pasando por las imágenes de despliegue , en este tendremos que:

        1. desplegar la imagen del contenedor de la aplicación en el entorno que corresponda por la rama de código que esté trabajando, en esta fase definimos los archivos de despliegue / charts de despliegue de las aplicaciones en el orquestador de contenedores que se tenga desplegado (k8s, rancheros, OC, etc)

            a. "feature" --> test

            b. "develop" --> PRE

        2. (solo en  PRE) aplicar los test de regresión, automatizados para poder comprobar que el código hace lo que se supone que hace

        3. (solo en PRE) test de stress de la aplicación

        4. realizar un escaneo de seguridad

        5. "tagear" la versión como candidata a ser promocionada a la rama de PRO (master/main)

Además de lo anterior tendremos desplegado los "playbooks" de administración y seguridad que sean necesarios para que la infraestructura se mantengan de una forma correcta. Todo ello debidamente almacenado en el SCM y será ejecutado por diferentes disparadores de las aplicaciones, repositorios, etc que sean necesarios. Asi si tenemos que dar de alta un usuario en un dominio activo (DA), será gestionado por un repositorio donde guardaremos la info del usuario, el cual actualizado ejecutará un "trigger" que atacará un "webhook" de Jenkins el cual posteriormente hará las oportunas inserciones en los servidores adecuados (DA de WindowsTm, LDAP, etc) para que el usuario reciba un correo con una contraseña a cambiar en su primer "login". 

La productividad inherente a estos mecanismos automatizados implica que en entornos relativamente simples se puede llegar a gestionar grandes entornos con escasos recursos humanos y posibilita la autonomía de los diferentes grupos de aplicaciones / desarrolladores para ir gestionando los despliegues de las aplicaciones sin necesidad de intervención de ese grupo humano que gestiona la infraestructura.

Posteriormente deberíamos desarrollar la arquitectura de los "workers", de forma que analicemos el hardware que da soporte a esos "workers" (fisicos, virtualizados).