Muchas veces me he encontrado haciendo demos con aplicaciones ejecutando en local o en un contenedor. Otras tantas el cliente ha hecho un montón de preguntas tontas referentes a porqué pone localhost. En algunos de estos sistemas no disponía de acceso root o sudo para cambiar el fichero /etc/hosts.
Para muchas aplicaciones caseras, nos importa poco parar un servidor de aplicaciones o web. Sin embargo, en el mundo empresarial, un corte de servicio o downtime son palabras mayores, y normalmente vienen seguidos de un papeleo espectacular; otras veces se puede calmar la situación mediante el despido del pobre operador.
Quiero presentar una de esas herramientas que ya existen, pero que alguien ha reescrito con el lenguaje go. Se trata de una utilidad tipo cron, pero está compilada de forma estática, no necesita de otras librerías y, por lo tanto, lo podemos usar en donde no tengamos permisos de root.
El otro día recibí una petición en el trabajo por parte de un cliente: poder ejecutar algunas operaciones por SSH en nuestro servidor. Solo de pensar en montar una jaula SSH con los binarios y sus librerías ya se me hizo cuesta arriba, y por eso lo hice con git-shell.
Hace poco me topé con una excelente pieza de software llamada Consul. Se trata de un binario que proporciona varios servicios: node autodiscovery, service autodiscovery, health checking y almacén de valores key-value. Todo ello mostrado en una interfaz web y suministrando un servidor DNS y una API que podemos usar.
Curioso de ver como mucho contenedores eran capaces de ver el contenido Docker de mi servidor, he decidido aprender como se hace, por si me hiciera falta en un futuro. En este artículo intento explicar las lecciones aprendidas, de forma que sean una futura referencia en caso de ser necesario.
Como ya sabéis, la tecnología docker me encanta; seguía con mi cruzada para dockerizar todos mis sistemas, cuando me topé con un artículo antiguo. En este artículo os contaré los problemas con los que me enfrenté en esta tarea y como los pude superar, explicando lo aprendido en el proceso.
Configurar servidores desde cero es una tarea muy pesada, una fuente de errores innecesaria y hace nuestros servidores difícilmente reproducibles. Los setups más básicos son siempre los mismos, y podemos configurar nuestros servidores para que ejecuten un script la primera vez que se (re)inicien, a falta de mejores herramientas.
Cuando trabajamos con tamaños de disco muy limitados, como por ejemplo en dispositivos embedded o pendrives, nos vemos obligados a reducir nuestros sistemas de ficheros. Algunos de estos sistemas de ficheros son de solo lectura, y vienen comprimidos, lo que nos permite ahorrar en espacio de disco, no en funcionalidades.
Ya vimos en un artículo anterior como delegar en SystemD la persistencia de túneles SSH. El otro día intenté reproducirlo sin éxito en un servidor con una versión baja de SystemD; finalmente me di cuenta de que había otra herramienta en el servidor capaz de reiniciar un túnel caído: Docker.