DevOps

Cuando la tecnología Docker apareció, la adoraron por el lema: «Build once, run anywhere» (Construye una vez, ejecuta en cualquier lugar). Los desarrolladores dejaron de escuchar la frase «en mi máquina funciona, pero en el servidor no». Pero junto con la comodidad llegó una nueva amenaza.

Un contenedor no es solo tu aplicación. Es todo un mini-sistema operativo (SO) con sus propias bibliotecas, utilidades y llamadas al sistema. Y si no vigilas ese SO, dejas a los atacantes una puerta enorme completamente abierta.

Imagina que estás construyendo una casa. Tú mismo diseñaste las paredes, revisaste cada ladrillo y te aseguraste de no haber olvidado las llaves en la cerradura. Pero ¿y si el hormigón que compraste a un proveedor externo con el tiempo empieza a desmoronarse? ¿O si en los marcos de las ventanas que instalaste hay defectos ocultos?

En el desarrollo moderno la situación es exactamente así. Una aplicación promedio hoy en día está formada en un 80–90% por bibliotecas de código abierto. Solo escribes una pequeña parte del código (la punta del iceberg), que gestiona un enorme volumen de código ajeno oculto «bajo la superficie».

¿Alguna vez te has preguntado cómo los programadores experimentados encuentran errores en el código ajeno con solo mirarlo? Buscan patrones. Saben que si los datos del usuario entran directamente en una consulta SQL —eso es malo. Si la contraseña se compara con un == en lugar de una función segura —es un riesgo.

Pero una persona no puede revisar 100 000 líneas de código sin pasar algo por alto. Aquí entra en escena SAST (Static Application Security Testing).

Imagine la situación: trabajas en un proyecto genial toda la noche. A las 4 de la mañana todo está listo, haces un git push final y te vas a dormir tranquilo. Y por la mañana descubres que tu balance en AWS está a cero y que hay un minero corriendo en tus servidores. ¿Qué pasó? Resulta que en uno de los archivos dejaste la línea: AWS_ACCESS_KEY_ID = "AKIA...".

Es un error clásico por el que han pasado miles de desarrolladores. En este artículo veremos por qué «simplemente borrar la contraseña» no ayuda y cómo configurar una protección automática que físicamente te impedirá cometer el error.

Escribir un Dockerfile simple: FROM node, COPY ., CMD run. Esto funciona, y para pruebas locales a menudo es suficiente. Pero cuando tal imagen llega al CI/CD o, Dios no lo quiera, a producción, empiezan los problemas: la construcción dura una eternidad, la imagen pesa gigabytes y los de seguridad se llevan las manos a la cabeza.

La diferencia entre “funciona” y “funciona correctamente” es colosal. Vamos a analizar cuatro niveles de optimización que separan una chapuza aficionada de una solución de ingeniería fiable.

OpenVPN — es un protocolo VPN fiable y probado, que permite organizar acceso remoto protegido a la red local. MikroTik RouterOS soporta OpenVPN en modo servidor desde la versión 6.x (TCP), y desde la versión 7+ — también UDP, pero con una serie de limitaciones arquitectónicas:

• autenticación obligatoria por usuario/contraseña incluso al usar certificados;
• lista limitada de cifrados y algoritmos;
• ausencia de algunas funcionalidades del OpenVPN “clásico”.

A pesar de ello, OpenVPN en MikroTik sigue siendo una solución demandada — especialmente en escenarios donde los clientes no soportan WireGuard o se requiere compatibilidad con sistemas antiguos.

Si te ocupas de self-hosting, tienes un laboratorio doméstico o administras un VPS pequeño, seguramente conoces Portainer. Es el estándar de facto: una navaja suiza potente y completa para Docker.

Pero seamos honestos: a veces la navaja suiza es demasiado pesada cuando solo necesitas pelar una manzana.

Recientemente descubrí Dockge — una herramienta del mismo desarrollador del popular Uptime Kuma. Me hizo replantear por completo el enfoque para gestionar contenedores. En este artículo cuento por qué Dockge puede ser el reemplazo ideal de Portainer para muchos escenarios.

Al trabajar con proyectos reales (cambio de CDN, migración, refactorización) a menudo es necesario reemplazar en masa una URL por otra.

A primera vista la tarea parece trivial: sed -i 's|old|new|g' **/* — y listo.

En realidad ese enfoque es una ruleta rusa.

Un reemplazo descuidado conduce a:

• 💀 Daño de archivos binarios (imágenes, pdf, archivos);
• 📉 Basura en el historial de git (los binarios aparecen como modificados);
• 🚫 Imposibilidad de una reversión limpia si no se hizo un respaldo.

En esta nota analizaremos un algoritmo apto para producción: cambiamos solo texto, no tocamos binarios, hacemos un respaldo puntual.

Jitsi Meet funciona de serie y resuelve muy bien la tarea de videoconferencias. La combinación Jitsi Meet + Jibri permite grabar las reuniones — y en muchas instalaciones ahí se quedan.

Pero tan pronto como Jitsi se usa no de forma esporádica, sino en el flujo de trabajo, muy pronto surgen preguntas:

• ¿Dónde almacenar las grabaciones de forma centralizada?
• ¿Cómo publicar automáticamente los enlaces para el equipo?
• ¿Cómo librarse de los pesados MP4 y pasar a reproducción por streaming?
• ¿Cómo servir las grabaciones por HTTPS sin revelar la estructura de directorios?
• ¿Cómo hacer todo esto automáticamente, sin intervención manual del administrador?

A continuación — una canalización de producción completa con código: desde la finalización de la grabación de Jibri hasta la publicación en Notion y el transcodificado asíncrono MP4→HLS con entrega a través de Caddy.

Los enrutadores Mikrotik son muy valorados por los administradores de sistemas por su increíble flexibilidad.
Una característica única de este equipo es que desde un hAP lite doméstico y económico hasta un potente enrutador corporativo de miles de dólares funcionan con el mismo sistema operativo: RouterOS.

Esto significa que, al aprender a configurar un dispositivo, podrá gestionar cualquier equipo de la marca.
En este artículo desglosaremos las etapas fundamentales para configurar Mikrotik desde cero hasta un estado completamente funcional.