Agrupaciones de aplicaciones nativas en la nube

Una propiedad clave de las aplicaciones nativas de la nube es que aprovechan las funcionalidades de la nube para acelerar el desarrollo. Este diseño suele significar que una aplicación completa usa diferentes tipos de tecnologías. Las aplicaciones se pueden enviar en contenedores de Docker, algunos servicios pueden usar Azure Functions, mientras que otras partes se pueden ejecutar directamente en máquinas virtuales asignadas en servidores metálicos grandes con aceleración de GPU de hardware. No hay dos aplicaciones nativas en la nube iguales, por lo que ha sido difícil proporcionar un único mecanismo para enviarlos.

Los contenedores de Docker se pueden ejecutar en Kubernetes mediante un gráfico de Helm para la implementación. Azure Functions se puede asignar mediante plantillas de Terraform. Por último, las máquinas virtuales se pueden asignar mediante Terraform, pero creadas con Ansible. Esta es una gran variedad de tecnologías y no ha habido ninguna manera de empaquetarlos todos juntos en un paquete razonable. Hasta ahora.

Las agrupaciones de aplicaciones nativas en la nube (CNAB) son un esfuerzo conjunto de muchas empresas de mente comunidad, como Microsoft, Docker y HashiCorp, para desarrollar una especificación para empaquetar aplicaciones distribuidas.

El esfuerzo se anunció en diciembre de 2018, por lo que todavía queda bastante trabajo por hacer para dar a conocer el esfuerzo a la comunidad en general. Sin embargo, ya hay una especificación abierta y una implementación de referencia conocida como Duffle. Esta herramienta, escrita en Go, es un esfuerzo conjunto entre Docker y Microsoft.

Los CNAB pueden contener diferentes tipos de tecnologías de instalación. Este aspecto permite que coexistan elementos como gráficos de Helm, plantillas de Terraform y cuadernos de estrategias de Ansible en el mismo paquete. Una vez construidos, los paquetes son independientes y portátiles; se pueden instalar desde un stick USB. Los paquetes están firmados criptográficamente para asegurarse de que se originan en la entidad que reclaman.

El núcleo de un CNAB es un archivo denominado bundle.json. Este archivo define el contenido de la agrupación, ya sea Terraform o imágenes o cualquier otra cosa. En la figura 11-9 se define un CNAB que invoca a Terraform. Sin embargo, tenga en cuenta que en realidad se define una imagen de invocación que se usa para invocar a Terraform. Cuando se empaqueta, el archivo de Docker que se encuentra en el directorio cnab se integra en una imagen de Docker, que se incluirá en el paquete. Tener Terraform instalado dentro de un contenedor de Docker en el paquete significa que los usuarios no necesitan tener Terraform instalado en su máquina para ejecutar la agrupación.

{
    "name": "terraform",
    "version": "0.1.0",
    "schemaVersion": "v1.0.0-WD",
    "parameters": {
        "backend": {
            "type": "boolean",
            "defaultValue": false,
            "destination": {
                "env": "TF_VAR_backend"
            }
        }
    },
    "invocationImages": [
        {
        "imageType": "docker",
        "image": "cnab/terraform:latest"
        }
    ],
    "credentials": {
        "tenant_id": {
            "env": "TF_VAR_tenant_id"
        },
        "client_id": {
            "env": "TF_VAR_client_id"
        },
        "client_secret": {
            "env": "TF_VAR_client_secret"
        },
        "subscription_id": {
            "env": "TF_VAR_subscription_id"
        },
        "ssh_authorized_key": {
            "env": "TF_VAR_ssh_authorized_key"
        }
    },
    "actions": {
        "status": {
            "modifies": true
        }
    }
}

Figura 10-18 : Un archivo de Terraform de ejemplo

bundle.json también define un conjunto de parámetros que se pasan a Terraform. La parametrización de la agrupación permite la instalación en varios entornos diferentes.

El formato CNAB también es flexible, lo que permite su uso en cualquier nube. Incluso se puede usar en soluciones locales como OpenStack.

Decisiones de DevOps

Hay tantas herramientas excelentes en el espacio de DevOps en estos días e incluso libros y documentos fantásticos sobre cómo tener éxito. Un libro favorito para empezar a trabajar en el recorrido de DevOps es The Phoenix Project, que sigue la transformación de una empresa ficticia de NoOps a DevOps. Una cosa es segura: DevOps ya no es algo deseable al implementar aplicaciones complejas de la nube nativas. Es un requisito y debe planearse y tener recursos al principio de cualquier proyecto.

Referencias

• Azure DevOps
• Administrador de Recursos de Azure
• Terraform
• Azure CLI