Es bastante habitual que en mi tiempo de ocio me dedique a trabajar con HTML y CSS por interés personal. A veces puedo hacer pruebas de concepto estáticas y otras puedo utilizar un generador estático; en todos los casos necesito de un servidor web levantado solo para mi sesión personal.
Hace tiempo me enamoré de un generador de webs estáticas llamado pelican; puede que fuera por estar escrito en python, o por tener una gran colección de temas y plugins disponibles. Con el tiempo, han aparecido muchas alternativas, y una de ellas me llamó la atención por su sencillez y velocidad: hugo.
Tengo un usuario que es muy cómodo; él solo consiguió una excepción de seguridad para poder abrir el puerto TCP de docker de un servidor concreto, para chafardear cómodamente desde su máquina. A pesar de mis reticencias, cumplí con lo que se me pedía, y no tardamos mucho en lamentarlo.
En otros artículos hablé de una librería javascript que nos permitía escribir documentación de forma fácil, escribiendo en el fichero .html el contenido en lenguaje de marcado markdown. Se trataba de Strapdown y le he dado mucho uso desde entonces; aunque soy minimalista y me gusta ir a lo básico.
Hace ya algún tiempo escribí un artículo sobre como montar un gateway utilizando Debian, iptables y dnsmasq. Siguiendo mi política de ir actualizando los artículos más útiles, y visto la aparición en mi toolbox de una nueva herramienta para simplificar iptables, le ha tocado una reescritura al artículo mencionado anteriormente.
Los Server Side Includes (SSI) son una extensión de algunos servidores web que nos permiten hacer manipulaciones en el fichero HTML servido de forma fácil. Esto nos permite, por ejemplo, incluir snippets de código en nuestras páginas estáticas, lo que contribuye en el principio Dont Repeat Yourself, sin contenido duplicado.
Muchas veces he utilizado los volúmenes de Docker para “inyectar” un fichero de configuración que sobreescriba a otro. Cuando utilizamos Docker Swarm suele ser un problema distribuir estos ficheros de configuración; además, a veces necesitamos que se transmitan encriptados para que no los puedan ver los contenedores hermanos, por seguridad.
Hace unos meses recibí una petición interesante; unos conocidos querían exponer un sitio web estático, pero lo querían replicado en muchos sitios porque era posible que les fueran cerrando sitios por su dudosa legalidad. Por supuesto me negué, pero el desafío era muy estimulante, así que intenté diseñarlo a posteriori.
Una petición muy habitual que recibo es la de algún usuario que quiere ejecutar “algo” en un servidor. Como no puede ser de otra manera dadas las restricciones de seguridad de la compañía, solo le puedo dar acceso por SSH; pero poner una jaula para restringir sus acciones es tedioso.
Como bien sabemos los que trabajamos con Docker, el servidor es bastante malo comprobando si un contenedor está funcionando o no. El check que hace Docker solo se molesta en ver si el proceso invocado está ejecutando o no, aunque no esté respondiendo. Esto ha cambiado recientemente con los healthchecks.
«« « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 » »»