Los servidores de git son muy útiles, pero si solo lo accedemos mediante terminal, se quedan limitados a pocos usuarios avanzados. Sin embargo, las soluciones con interfaz web, como GitHub llegan a todo tipo de usuarios. En un intento de abaratar costes, se han hecho varios clones, entre ellos, Gitea.
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.
Aquellos que leéis mis artículos habitualmente ya sabéis lo que es un balanceador de carga, especialmente los de peticiones HTTP; en especial conocemos nginx y haproxy. La parte mala de estos servicios es que la configuración es estática e inmutable, y en un mundo cloud, eso no es lo ideal.
Ya vimos que consul nos permitía mantener una foto del estado de nuestros servidores y de los servicios que corren en ellos. Es todavía más importante cuando contamos con varios servidores, y todos declaran sus partes a un servidor central, de forma que tenemos una foto global de la situación.
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.
He visto muchos artículos por internet que hacen maravillas para tener un cluster de Docker Swarm funcional. Puede que en versiones anteriores fuera así, pero cada vez se ha simplificado más el setup para alinearse con la filosofía de la simplicidad, frente a otras soluciones más completas, pero más complejas.
«« « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 » »»