DevOps / Cloud Jr route: learn for free from scratch in 6 weeks

Los servidores de internet casi nunca tienen pantalla ni mouse: se manejan con la terminal, escribiendo comandos. Moverte por carpetas (cd), listar archivos (ls), ver un archivo (cat), buscar dentro (grep) y cambiar quién puede usar un archivo (chmod) es el día a día de DevOps. Cuando repites los mismos comandos, los guardas en un script de Bash.

Mini ejemplo: grep -c ERROR app.log cuenta cuántas líneas del log tienen la palabra ERROR.

Error típico de principiante: ejecutar un comando que borra (rm -rf) sin revisar en qué carpeta estás. Antes de borrar, mira con pwd y ls.

Cuando escribes una dirección en el navegador pasan muchas cosas: el DNS traduce el nombre (codea.andeon.la) a una dirección IP, el navegador se conecta al servidor y le habla en HTTP (o HTTPS, cifrado) con una petición como GET /, y el servidor responde con un código de estado (200 bien, 404 no existe, 500 error del servidor). Para entrar a un servidor sin contraseña se usa SSH. Y en Git, un equipo DevOps cuida que el historial esté limpio: ramas cortas, Pull Requests y rebase cuando hace falta (la ruta Git y GitHub Jr lo explica desde cero).

Mini ejemplo: curl -I https://codea.andeon.la muestra solo las cabeceras de la respuesta, empezando por el código de estado.

Error típico de principiante: pensar que "la web no carga" siempre es culpa del código. Puede ser DNS, el certificado HTTPS o el servidor: hay que revisar por capas.

"En mi computadora funciona" es la frase más temida en un equipo. Docker la elimina: empaqueta tu app con su versión exacta de Node, sus librerías y su configuración en una imagen. Desde esa imagen creas contenedores que corren igual en tu laptop, en la de tu compañero y en el servidor. La receta de la imagen se escribe en un Dockerfile, y si tu app necesita una base de datos, Docker Compose levanta las dos juntas.

Mini ejemplo: docker run -p 8080:80 nginx descarga un servidor web y lo deja en http://localhost:8080.

Error típico de principiante: guardar datos dentro del contenedor. Si lo borras, se pierden; para eso existen los volúmenes.

CI (integración continua) significa que cada vez que alguien sube código, un robot lo prueba solo: si algo se rompe, te enteras en minutos y no el viernes en la noche. CD (despliegue continuo) significa que lo que pasó las pruebas se publica solo. En GitHub ese robot se llama GitHub Actions y se configura con un archivo YAML en .github/workflows/. Cada archivo es un workflow con jobs, y cada job tiene steps.

Mini ejemplo:

on: [push]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm test

Error típico de principiante: escribir un token o contraseña dentro del workflow. Va en Settings → Secrets and variables → Actions y se usa como ${{ secrets.NOMBRE }}.

Desplegar es poner tu app en una computadora que está siempre encendida y conectada a internet, para que cualquiera la use. Hay varias formas: para un sitio estático (HTML, React), Vercel o Firebase Hosting lo publican gratis en segundos; para una app con servidor y Docker, servicios como Render reciben tu imagen o tu repositorio y la ejecutan; y si quieres control total, alquilas un VPS (un servidor virtual) y lo administras tú. Al final conectas tu propio dominio y activas HTTPS.

Mini ejemplo: con Vercel conectado a GitHub, cada git push a main publica una nueva versión y cada PR tiene su propia URL de prueba (preview).

Error típico de principiante: configurar la app con valores escritos en el código (puerto, URL de la base). En la nube esos valores cambian: léelos de variables de entorno, como dice la metodología 12-factor.

Que la app esté desplegada no significa que esté bien. Monitorear es saber, sin que un usuario te lo diga, si la app responde, si responde rápido y si está dando errores. Los logs cuentan qué pasó en cada petición; las métricas son números en el tiempo (peticiones por minuto, tiempo de respuesta); y las alertas te avisan cuando algo se sale de lo normal. Con todo esto armas el proyecto final: tu app en contenedor, con pipeline que la prueba y la despliega, y vigilada.

Mini ejemplo: un monitor de uptime llama a https://tu-app/health cada 5 minutos y te manda un correo si no responde 200.

Error típico de principiante: poner alertas para todo. Si te llegan 50 correos al día, dejarás de leerlos. Alerta solo lo que exige actuar.