Lista de materiales

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.

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.

En los últimos diez años la industria del despliegue de aplicaciones web ha recorrido el camino desde scripts FTP y rsync hasta sistemas de orquestación muy complejos. Hoy en día los desarrolladores y los equipos pequeños se enfrentan cada vez más a una decisión difícil:

• o bien pagar una prima considerable por la comodidad de las plataformas PaaS (Heroku, Render, Fly.io),
• o bien sumergirse en la complejidad cognitiva y operativa de Kubernetes.

Kamal ofrece una tercera vía: la comodidad de los servicios en la nube modernos — en su propio servidor.

En un mundo donde el volumen de datos crece más rápido que los precios de las tarjetas gráficas, la pregunta «¿Dónde guardar los archivos?» se vuelve urgente. Google Drive e iCloud son cómodos, pero caros y no ilimitados. Los discos duros externos no son fiables. Las soluciones listas de Synology o QNAP son buenas, pero cuestan mucho.

Aquí entra en escena TrueNAS. Es un sistema operativo que convierte un ordenador común en un potente almacenamiento en red (NAS) de nivel empresarial.

Si su negocio trabaja con usuarios de Rusia, la cuestión de dónde se almacenan los datos personales le concierne directamente. Teléfonos, nombres, direcciones de correo electrónico, solicitudes de formularios, datos de empleados: todo esto está sujeto a estrictos requisitos de localización.

Durante años muchas empresas vivieron en una “zona gris”: los datos aparentemente se almacenaban tanto en Rusia como en el extranjero y la responsabilidad estaba diluida. Pero a partir del 1 de julio de 2025 las reglas cambiaron tanto que muchos esquemas técnicos habituales ahora se consideran una violación directa de la ley.

Mudarse a la nube o cambiar de proveedor — siempre es una operación a corazón abierto. El ingeniero debe resolver un montón de cuestiones: ¿cómo trasladar terabytes de datos con el mínimo tiempo de inactividad? ¿Cómo convertir el esquema? ¿Cómo configurar CDC (Change Data Capture) para no perder ni una sola transacción durante el corte?

Cada gran proveedor de la nube tiene su respuesta. Los enfoques son radicalmente diferentes: unos ofrecen simplemente una “tubería” para los datos, otros —un ETL completo—, y algunos hacen la migración serverless y lo más indolora posible.