- Objetivo
- Pre-requisitos
- Infraestructura
- Gestión de la configuración
- CI / CD [TBD]
- Contenedores [TBD]
- Notas
El objetivo de este reto no es otro que conocer, entender y practicar los principios de la filosofía DevOps a través de una serie de ejercicios.
Cada ejercicio de este reto es libre de ser realizado con las herramientas que se desee siempre y cuando se cumpla con los mantras del mismo:
- No crear o configurar recursos en una interfaz web a menos que sea la única vía posible.
- No tocar archivos de configuración del sistema o la aplicación de forma manual.
- No acceder por SSH a tus servidores más que para depurar algo extraño.
- Tener una cuenta en AWS. Si es la primera vez que usa AWS puede aprovechar la capa gratuita durante un año.
- Crear un par de claves de acceso (Programmatic access) que correspondan a un usuario con privilegios de Admin[¹] para poder crear recursos.
- Un dominio gratuito o de pago que te permita cambiar los NS autoritarios a los de AWS (para su uso con Route53)
- Escoge alguna de las herramientas de aprovisionamiento de infraestructura del DevOps Roadmap. Por ejemplo: Terraform o CloudFormation.
- Crea un nuevo proyecto y define tres entornos: DEV, STAGING y PROD. Cada entorno tendrá los mismos componentes de la arquitectura elegida. Cada entorno se engloba dentro de un VPC y tendrá un subdominio propio.
- Describe en infraestructura como código (IaC) lo necesario para crear desde cero y sin intervención manual la siguiente arquitectura propuesta: (PDF)
La arquitectura consiste en (para cada VPC):
- Una zona en Route53 con los registros necesarios.
- CDN (opcional).
- S3 para contendo estático y recursos (opcional).
- Balanceador de carga (ELB) público.
- Instancias de los servidores web.
- Grupo de Autoescalamiento (ASG) de las instancias de los servidores web.
- Bases de datos RDS (base de datos relacional) con máster y réplica.
En el diagrama no se indica con número, pero se observa otro ASG para los servidores de aplicaciones al igual que un ELB interno. Puede elegir crearlos o no.
Si escoge crearlos: Los servidores web actuarán como proxies reversos a los servidores de aplicaciones y estos últimos serán quienes se conecten a la base de datos.
Si escoge NO crearlos: Los servidores web (5) alojarán la aplicación web y desde ellos se conectará a la base de datos RDS.
Disfruta de lo que se siente crearla y destruirla cuantas veces quieras. 🙃
Una vez la infraestructura está creada, escoge un gestor de configuración (Ansible, Puppet, Chef, Salt, etc) y crea los recursos necesarios para configurar todos los servidores y las BBDD.
El objetivo de este apartado es evitar tener que entrar a servidores a cambiar parámetros o ficheros de configuración así que evita cambios manuales. ¡Probablemente habrá alguna manera de hacerlo con la herramienta que has escogido!
Con los recursos base configurados, escoge una aplicación web para desplegar. Se proponen los siguientes ejemplos:
- Análisis de sentimiento (Front + Back)
- RealWorld (Front + Back)
- Kotlin Full-stack Application Example (Front + Back)
- Lectura Extra: crear un servidor web para conectarse a la instancia de base de datos de Amazon RDS
Ahora debe crear nuevos recursos para desplegar y configurar automáticamente la aplicación escogida. Una vez creados, aplicarlos junto con los creados anteriormente.
Finaliza esta parte con el siguiente objetivo:
Suponiendo que tu dominio es dominio.tld:
- prod.dominio.tld mostraría la app del entorno de PROD
- staging.dominio.tld mostraría la app del entorno de STAGING
- dev.dominio.tld mostraría la app del entorno de DEV
Luego de eso diría que te pongas un pipeline en tu CI/CD favorito. Hazte una web app de prueba en un repo git. Y que tu pipeline compile si tiene que compilar, suba los artefactos al entorno de staging/pre, les haga + pruebas y si las pasa que lo despliegue en el entorno de pro.
Estos entornos podrían ser diferentes instancias o diferentes VPCs en tu cuenta de AWS.
Algo tan sencillo como un hello world, y probar que la llamada a la URL te devuelva eso. O un botón de X color. Lo que sea.
Luego de eso, me metería en el tema de contenedores, tanto montar la infra para contenedores como que tu CI/CD genere la imagen docker, la suba a un registry y tu orquestador de contenedores la despliegue.
[¹]: Para iniciación rápida a IaC esta es una forma de no tener problemas de permisos pero es una MUY MALA práctica. Las cuentas con Programmatic access deben de tener permisos bien pensados. Un par de credenciales filtradas pueden resultar en una cuenta comprometida, destrucción de recursos y facturas sorpresas.