Hace unas semanas, hablamos de un balanceador que trabaja muy bien con docker. Se trataba de traefik y nos permitía olvidarnos de su configuración, que él mismo podía extraer de los metadatos de los contenedores y reconfigurarse dinámicamente. Hoy vamos a explicar como funciona con un cluster de docker swarm.
Cuando trabajas con terceras partes, los problemas relacionados con la resolución DNS son demasiado habituales. Muchas veces utilizan DNS internos y cuando nos pasan los datos de conexión remota, no funciona nada. En estos casos, el procedimiento suele pasar por verificar primero la resolución DNS antes que la conectividad remota.
Todos estamos hartos de ver páginas web con distracciones por todos lados: anuncios, popups, menús desplegables y horribles scripts de javascript. Eso hace que el contenido no llegue al usuario final y por lo tanto, no se queden con ganas de volver. Eso no significa tener una página HTML básica.
He sido fan de python desde hace muchos años. Inicialmente lo empecé a utilizar porque, junto a bash, era la herramienta que venía por defecto en todos los servidores que administraba. Pero con el tiempo salió la versión 3, incompatible con la 2; al final me ha tocado migrar forzadamente.
Ya vimos en otros artículos lo fácilmente que podemos utilizar dnsmasq en un gateway para ayudar a los servidores a que se conozcan entre sí por nombre y como una forma de ocultar el DNS real de la red interna. Sin embargo es una caché excelente para un sistema aislado.
Lo he vuelto a hacer: a pesar de que es una antipráctica de docker, me veo tentado a ejecutar varios servicios en mis contenedores. Solo lo hago cuando estos servicios tienen un objetivo común, como servir PHP (nginx/php-fpm); para ello necesitamos un gestor de procesos. Hoy hablaremos de s6.
Cuando escalamos nuestros servicios o añadimos nuevos en Docker, suele ser un problema la configuración del balanceador. Se necesita modificar su configuración y reiniciarlo para que la nueva configuración aplique. Con el tiempo han aparecido nuevas soluciones para simplificar estos casos, con configuraciones dinámicas. Una de estas soluciones es Traefik.
Es muy cómodo dejar un fichero en una carpeta local y saber que ese fichero está a salvo, en la nube; seguramente los que utilizáis un servicio de sincronización en la nube váis a estar de acuerdo. La empresas no suelen permitirlo, pero podéis utilizar un servicio local por SSH.
Llega el momento que tantas veces hemos repetido: montamos un servidor para una función concreta, y le asignamos un disco o partición a la carpeta que va a alojar la cantidad creciente de datos necesarios. De repente nos fijamos en que la capacidad del disco se ha perdido tras formatear.
Muchas veces me pregunto para qué necesito guardar un histórico de comandos en mis sesiones de bash. Como no soy nada repetitivo con los comandos que uso, solo se trata de basura acumulándose en ~/.bash_history, y un riesgo innecesario de que otros usuarios puedan chafardear los comandos que voy utilizando.
«« « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 » »»