04 DevOps e Infraestructura

Actualizado: 17 de marzo de 2026

Ruta de Aprendizaje y Onboarding: DevOps e Infraestructura Cloud#

Como especialista de Infraestructura, tu trabajo no es construir aplicaciones — es asegurar que las aplicaciones de otros nunca se caigan, escalen bajo tráfico, loggeen con precisión y estén protegidas por escudos de ciberseguridad. Esta ruta abarca desde los fundamentos de computación hasta la infraestructura real de SoyDigital.

Tiempo estimado de estudio: 50–70 horas

Prerrequisitos: Conocimiento básico de la línea de comandos de Linux. Si nunca has usado una terminal, completa primero el Nivel 1 de la guía de Brigadista.

Índice de Contenidos y Mapa de Profundidad#

  • Nivel 1 (Junior): Contenedores y Logs in-situ
  • Nivel 2 (Semi-Senior): Orquestación Resiliente y Seguridades de Red OS
  • Nivel 3 (Senior/Arquitecto): Bare-Metal, Microkernel y Tracing
  • Escenarios Críticos y Troubleshooting (Edge Cases)

Ruta de Dominio y Escalafón Profesional (Matriz de Habilidades SecOps/DevOps)#

La Operación Distribuida "On-Premises" e "In-Cloud" combinada exige dominios arquitectónicos mucho más limpios e intrincados que los típicos clusters de Kubernetes Cloud tradicionales, ya que cada Mini-PC funciona como un clúster físico autónomo.

Nivel Junior (Contenedores y Logs in-situ)#

➤ Profundización Técnica / Casos de Borde:

  • Asfixia de JSON-File Logging: Si dejas Docker con la configuración por defecto, los logs del contenedor pueden crecer hasta ocupar los 250GB completos del Mini-PC, crasheando Linux. El DevOps debe configurar /etc/docker/daemon.json inyectando un max-size: "50m" y max-file: "3" para rotación obligatoria de bitácoras.
  1. Dominio de Docker: Subir/bajar contenedores con fluidez. Entender la diferencia entre docker-compose up e instancias independientes. Comprender Bind Mounts vs Docker Volumes localizados.
  2. Administración Básica de Sistema (Ubuntu): Saber cómo funciona el árbol /var/log. Analizar journal de sistema nativo journalctl -xeu docker.service. Configurar instancias básicas con PM2.
  3. Manejo de permisos: Uso y lectura precisa de los roles locales, controlando que bases de datos o llaves criptográficas estén aseguradas (chmod 600 / 700, control con chown).

Nivel Semi-Senior (Orquestación Resiliente y Seguridades de Red OS)#

➤ Profundización Técnica / Casos de Borde:

  • Ceguera de Iptables/UFW bajo Docker: UFW (Uncomplicated Firewall) es inútil si no sabes que Docker manipula iptables directamente. Si haces ufw deny 5432 pero levantas PostgreSQL en Docker expuesto, el puerto estará abierto a todo el mundo. Debes deshabilitar la inyección iptables: false en daemon.json o mapear estrictamente al localhost 127.0.0.1:5432.
  1. Reglas UFW y Firewalls Invariables: Entendimiento denso sobre iptables/ufw en un host directo para impedir acceso por los puertos WiFi. Aceptando y protegiendo de manera hermética las IPs específicas de Wireguard/Netbird wt0 hacia el puerto SSH 22. Integración con "Fail2Ban".
  2. GitOps & Scripting de Mantenimiento: Despliegues CI/CD que interactúan con túneles Netbird reversos para ejecutar tareas Bash idempotentes sobre los miles de Mini-PCs instalados de manera controlada. Implementan "Log Rotation" obligatorio y limitan el log driver de docker (ej: max-size 50m).
  3. Limpieza Automatizada: Resolver asfixia de Overlay2. Orquestar subrutinas de limpieza de contenedores suspendidos o deshuérfanos mediante automatización docker system prune estructurada.

Nivel Senior/Arquitecto (Bare-Metal, Microkernel y Tracing)#

➤ Profundización Técnica / Casos de Borde:

  • Ansible Pull vs Push bajo NAT: Los Mini-PC no tienen IP Pública real accesible. Ansible Push tradicional fracasa. El Arquitecto debe diseñar un sistema Ansible-Pull (donde el Mini-PC despierta, se conecta a GitHub/Indotel por Tareas, jala el playbook y lo ejecuta localmente) o enrutar todo por túneles SSH reversos estables a un Bastion Host central.
  1. Despliegues Zero-Downtime Locales (Blue/Green Edge): K8s o K3s consumen demasiado del Mini-PC, el Arquitecto orquesta scripts que suben el "Contenedor API Nuevo" en un puerto anexo (v2), hace polling de salud hasta que pasa un test de readiness local y entonces reescribe el proxy nginx local mediante socket, dándole Kill al antiguo, asegurando cero fallos.
  2. Kernel Tracing y Profiling Extremo: Capacidad de usar herramientas eBPF (bpf-tools, memleak, tcpdrop) para validar cuellos de botella exactos de disco M.2, memory-leaks letales generados a bajo nivel y control minucioso de I/O disk latency mediante ajustes en los sysctl.conf.
  3. Provisionamiento por PXE / Cloud-Init: Para estandarizar flotillas (decenas de Mini-PCs), desarrollo de flujos automatizados (Ansible local playbooks / PXE Boot) para no depender exclusivamente de la labor del Brigadista en planta base.

Escenarios Críticos y Troubleshooting (Edge Cases)#

1. Apagón de UPS Destruye partición OverlayFS (Kernel Ext4 Corruption)

  • Síntoma: Al arrancar el demonio de Docker, los contenedores entran en loop de Created / Restarting. El log marca "failed to mount overlay" o "mounting storage: overlay2 I/O error".
  • Protocolo de Acción (SecOps):
    • Debido a la caída violenta, bloques físicos del sistema raiz quedaron atascados. El devops remotamente aísla temporalmente docker systemctl stop docker, localiza qué carpetas sufren, realiza en lo posible backup del "volumes", y fulmina limpiamente el árbol de contenedores interno rm -rf /var/lib/docker/overlay2/*. Alternativamente corre remotamente fsck.ext4 contra los lvm particionados y reinicia por fuerza para recrear limpios docker-compose up -d --force-recreate.

➤ Profundización Técnica / Casos de Borde:

  • Mitigación Activa usando Cgroups (Control Groups): En vez de rogar a PM2 que no ahogue el sistema, el Arquitecto lanza el ecosistema dentro de un systemd slice restringido que le impone un hard-limit de Kernel de 1.5GB de RAM al usuario de la API. Si el proceso cruza ese límite de cgroup, el Kernel lo descabeza instantáneamente sin dejar que el lag toque al sistema de Brigada.

2. Un PM2 Runtime Zombie evade Control de Memoria (OOM Killer Loop)

  • Síntoma: El sistema levanta CPU constante al 100%, el Mini-PC se laguea enormemente, fallan los pings remotos y el usuario del panel Web (Brigadista) experimenta una API muda.
  • Protocolo de Acción:
    • El PM2 Watchdog no pudo detectar el loop. El Arquitecto entra vía una pipe SSH, lanza un kill -9 selectivo contra los PIDs (htop / top). Realiza la auditoría de limpieza en /pm2/logs/. Una vez estabilizado, impone hard restrictions explreñas en el PM2 Ecosystem (p.ej: reinicio automático a límites strict con max_memory_restart: '1G') y fuerza a Node a Garbage Collector prematuro pasándole el flag node --max-old-space-size=1024 ....

➤ Profundización Técnica / Casos de Borde (TLS Expiration):

  • Certbot CA Rate Limits en Borde: Si el túnel expone muchas URLs secundarias, pedir certificados Let'sEncrypt nuevos en cada reinicio del Mini-PC bloqueará la IP institucional por 7 días. El DevOps debe persistir crónicamente las carpetas de /etc/letsencrypt en un volumen montado o usar certificados Wildcard auto-renovables inyectados desde el servidor maestro hacia el borde asíncronamente.