A lo largo de mi carrera laboral he tocado bastantes palos, y en varias ocasiones he tenido que aprender sobre la marcha. Unos años atrás me metieron en un proyecto de Big Data con Scala y Spark, no teniendo yo idea de nada de esto; en mi último trabajo me ofrecí a tocar cosas de Angular sin haber tocado frontend hasta el momento. También he acabado involucrado de una forma u otra en integración y despliegue continuo, Docker, o Kubernetes. Hay, sin embargo, algo en lo que nunca he tenido la necesidad de produndizar y que viendo mis búsquedas en LinkedIn queda claro que es casi un requisito indispensable.

Aunque el término cloud engloba muchas cosas, podríamos simplificarlo y dividirlo en tres niveles: SaaS, PaaS e IaaS.¹ El primero es muy sencillo: cualquier hijo de vecino sabe lo que es Gmail o Dropbox, aunque no sepa que son software como servicio (Software as a Service). Las plataformas como servicio ya si que están enfocadas a desarrolladores: Openshift o Supabase (la primera usada en mi anterior trabajo, la segunda en uno de mis proyectos personales) nos permiten desplegar aplicaciones o utilizar determinados servicios sin tener que preocuparnos por la infraestructura que hay debajo. Esa infraestructura es precisamente la que entra en juego en el tercer nivel, donde ya hablamos de servidores, redes, almacenamiento, balanceadores, etcétera. Es “infraestructura como servicio” porque no tenemos el servidor físicamente en una habitación ni compramos discos duros, switches o routers, sino que alquilamos esos recursos bajo demanda a un proveedor; es a esto a lo que normalmente nos referimos cuando leemos cloud en alguna oferta de trabajo.

No es que me sea algo ni mucho menos ajeno. Como ya comenté en mi anterior artículo, llevo tiempo gestionando mi propio VPS. Pero cuando hablamos de sistemas más grandes, la complejidad cambia de escala: no es lo mismo mantener un servidor propio para gestionar una pequeña página web que diseñar infraestructura reproducible, escalable y fácil de automatizar. Es ahí donde entran Amazon Web Services, Microsoft Azure o Google Cloud, y es aquí donde, hasta la fecha, voy un poco más perdido. De todos ellos, el proveedor líder en el mercado es AWS, y es por eso por lo que voy a centrarme en él. Sin embargo, más que aprender un proveedor concreto, me resulta mucho más interesante entender cómo gestionar infraestructura independientemente de la plataforma. Aquí es donde entra Terraform y la IaC, Infrastructure as Code. Trabajar con Terraform me permite abstraerme en parte del proveedor y no “casarme” con nadie.

Como creo que la mejor forma de aprender es hacer cosas, mi intención es sobrecomplicar un poco mi actual infraestructura y replicar lo que ya tengo construido en mi VPS, pero esta vez usando Terraform y AWS. Para ello había comprado hace unas semanas el dominio pabloquiros.xyz en Hostinger. Pero el dominio .xyz parece, a primera vista, bastante más “serio” que el .click, que prácticamente remite a páginas de broma. Es por ello que, antes de nada, he decidido migrar de dominio y dejar en un futuro .click para futuras pruebas.

Apuntes locales

En su día, para desplegar una página web estática en un VPS, seguí algunos tutoriales sencillos de YouTube. A día de hoy ya me se de memoria lo que tengo que hacer, ya que no es muy complicado: instalar nginx en mi VPS, crear un archivo en /etc/nginx/sites-available que se vea de la siguiente forma:

server {
    listen 80;
    listen [::]:80;

    server_name midominio.com www.midominio.com;

    root /var/www/mi-web;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

generar un link simbólico de este archivo en /etc/nginx/sites-enabled, recargar nginx y voilá!, ya tenemos página web, cuyo contenido será lo que haya en el archivo /var/www/mi-web/index.html. Habría también que añadir certbot, lo cual también es muy sencillo.

Pese a que recuerdo todos estos pasos, uno siempre se puede olvidar de algo, por lo que viene bien tener a mano documentación; aquí es donde entra un proyecto personal del que todavía no había hablado y que tenía un poco abandonado, pero que he vuelto a actualizar aprovechando la coyuntura. Se trata de una bóveda de Obsidian local donde pretendo crear una suerte de apuntes de informática. En ella doy cabida a la máxima cantidad de información y documentación posible. Este es un proyecto que en el mejor de los casos caerá presa del síndrome del 90%, ya que siempre se le podrán añadir nuevas carpetas y nuevos apuntes, así que nunca planeo terminarlo como tal, pero si espero que me resulte útil a futuro. Actualmente este es su árbol de carpetas:

├── Anexo
├── Full-stack
│   ├── 1. Lenguajes de programación
│   │   ├── 1.1 Lenguajes de propósito general
│   │   ├── 1.2 Marcado y estilos
│   │   ├── 1.3 Consulta
│   │   └── 1.4 Configuración
│   ├── 2. Arquitectura de software
│   │   └── 2.1 Seguridad
│   ├── 3. Infraestructura
│   │   ├── 3.1 Sistemas
│   │   ├── 3.2 Redes
│   │   ├── 3.3 Hosting
│   │   ├── 3.4 Contenedores
|   |   ├── 3.5 Cloud
│   │   └── 3.6 Seguridad
│   ├── 4. Backend
│   ├── 5. Frontend
│   │   └── Frameworks Javascript
│   ├── 6. Bases de datos
│   │   ├── 6.1 Relacionales
│   │   └── 6.2 No relacionales
│   ├── 7. CI-CD
│   │   ├── 7.1 Control de versiones
│   │   ├── 7.2 Dependencias y build
│   │   ├── 7.3 Pipelines
│   │   └── 7.4 Despliegue
│   └── 8. Testing
└── Proyectos

De momento tengo muy poca documentación. Tras realizar la migración, en la sección 3.3.Hosting añadí un archivo detallando como realizar el deploy de una web estática, además de añadir otros como nginx.md (3.2 Redes) o docker.md (3.4 Contenedores). Cuando estos apuntes sean ya algo útil planeo subirlos a mi servidor para que sean accesibles, pero de momento es un proyecto a futuro y no le voy a dar prioridad.

DNS

En el dominio .click había empezado usando los nameservers de Epik durante las primeras semanas, hasta que un día decidí pasarme a los de Vultr. Tenía pensado hacer lo mismo con el dominio .xyz, pero pensé que tenía más sentido centralizarlo todo en Cloudflare, que no solo actúa como proveedor de DNS sino que añade una capa adicional de cacheo, protección frente a ataques, certificados SSL automáticos y, en general, una mejora en el rendimiento. Basta con crear una cuenta gratuita en Cloudflare, añadir el dominio y revisar los registros DNS que detecta automáticamente. Una vez verificado que todo es correcto, solo hay que cambiar los nameservers en el registrador para que apunten a Cloudflare. A partir de ahí, se gestionan todos los registros DNS desde su panel.

Al principio y para hacer la prueba empecé usando el modo “DNS only”, es decir, sin pasar el tráfico por los servidores de Cloudflare. Una vez comprobado que todo funcionaba bien, activé el modo proxy²; en el panel de Cloudflare me permiten ver el tráfico de mi página o parchear de forma sencilla las vulnerabilidades que me indican en el apartado de Security insights. Son este tipo de cosas las que quiero empezar a integrar dentro de un entorno cloud más estructurado en los próximos pasos.

Esta semana empezaré mi formación de Terraform y AWS.