DevOps

Todo se hizo rápido y con precisión. Lo recomiendo.

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.

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.

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.

Todo fue bien, el profesional respondió rápidamente a las preguntas y ayudó a resolver el problema. ¡Gracias!

Respuesta: ¡Gracias por la reseña! ¡Encantado de ayudar!

Todo lo hicieron con rapidez.
Seguiremos acudiendo. ¡Lo recomiendo!

Todo se hizo con rapidez. Михаил siempre está en contacto. Seguiremos recurriendo a él

Respuesta: ¡Gracias por el comentario! ¡Encantado de ayudar!