Hace poco he cambiado de trabajo por motivos personales. En mi nueva posición me he encontrado con un cambio en las tecnologías usadas; lo que me he encontrado es algo que hacía tiempo que no tocaba: basan sus sistemas en Java y Tomcat. He necesitado un ligero reciclaje en ellos.
No dejan de sorprenderme los administradores de sistemas que crean usuarios a petición, pero les asignan passwords supuestamente de un solo uso pidiéndoles que la cambien en el primer uso. La experiencia me dice que esa password solo se cambia si es estrictamente necesario. Esta petición la puedes forzar fácilmente.
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.
«« « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 » »»