Lotes de aplicaciones nativas en la nube
Sugerencia
Este contenido es un extracto del libro electrónico “Architecting Cloud Native .NET Applications for Azure” (Diseño de la arquitectura de aplicaciones .NET nativas en la nube para Azure), disponible en Documentos de .NET o como un PDF descargable y gratuito que se puede leer sin conexión.
Una propiedad clave de las aplicaciones nativas de nube es que sacan provecho de las capacidades de la nube para acelerar el desarrollo. Este diseño suele implicar que una aplicación completa utilice diferentes tipos de tecnología. Las aplicaciones se pueden enviar en contenedores Docker, algunos servicios pueden usar Azure Functions, mientras que otras partes se pueden ejecutar directamente en máquinas virtuales, asignadas en servidores exclusivos grandes con aceleración de GPU de hardware. No hay dos aplicaciones nativas de nube iguales, por eso ha sido difícil proporcionar un único mecanismo para enviarlas juntas.
Los contenedores 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 se compilan con Ansible. Se trata de una gran variedad de tecnologías y no ha habido ninguna manera de empaquetarlas todas juntas en un paquete que funcione razonablemente. Hasta ahora.
Los lotes de aplicaciones nativas en la nube (CNAB) son un esfuerzo conjunto de muchas empresas centradas en la comunidad, como Microsoft, Docker y HashiCorp, para desarrollar una especificación de paquetes de aplicaciones distribuidas.
Este proyecto se anunció en diciembre de 2018, por lo que todavía queda un poco de trabajo por hacer para que toda la comunidad pueda disfrutar del esfuerzo que se ha hecho. Sin embargo, ya hay una especificación abierta, y una implementación de referencia llamada Duffle. Esta herramienta, que se escribió 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 elementos como los gráficos de Helm, las plantillas de Terraform y los cuadernos de estrategias de Ansible coexistan en el mismo paquete. Una vez compilados, estos paquetes son autosuficientes y portables; se pueden instalar desde una memoria USB. Los paquetes se firman criptográficamente para asegurar que su origen está en la entidad que llevan señalada.
El núcleo de un CNAB es un archivo denominado bundle.json. Este archivo define el contenido del lote, ya sea de Terraform, de imágenes o de 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 Docker que se encuentra en el directorio cnab se integra en una imagen Docker, que después se incluye en el lote. Tener Terraform instalado dentro de un contenedor Docker en el lote significa que los usuarios no necesitan tener Terraform instalado en su máquina para ejecutar el lote.
{
"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 ejemplo de archivo de Terraform
bundle.json también define un conjunto de parámetros que se pasan a Terraform. La parametrización del lote permite su 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
Hoy por hoy, hay muchísimas herramientas excelentes en el espacio de DevOps, y un número aún mayor de libros y artículos fantásticos que le llevarán al éxito. Un libro de referencia para iniciarse en la aventura de DevOps es The Phoenix Project, que sigue la transformación de una empresa ficticia de NoOps a DevOps. Hay una cosa que está muy clara: DevOps ha dejado de ser algo que “no viene mal” al implementar aplicaciones complejas y nativas en la nube. Es un requisito, y debe tener la planificación y los recursos que necesite al empezar cualquier proyecto.
