Dicen que en la variedad está el gusto. Y efectivamente, siempre es mejor tener muchas opciones para poder elegir entre ellas la que más nos guste. Pero cuando por variedad no nos referimos a los sabores de un helado sino a que en un mismo proyecto tenemos gente que usa un editor de código que finaliza los archivos con una nueva linea mientras que otros usan otro editor que no, unos indentan los archivos con espacios y otros con tabuladores, unos tienen el tamaño máximo de cada línea de 80 carácteres y otros de 120... al final acabamos con un popurrí de estilos que en el mejor de los casos hará que las revisiones de código sean un infierno y que haya cambios en el código cuya aprobación dependerá subjetivamente de la persona que esté revisándolos en ese momento. La variedad ahora ya no está tan bien, ¿verdad?

Si estas intentando montar un cluster de Kubernetes en alta disponibilidad, o bien tienes alguna experiencia en esto porque lo has visto anteriormente o porque ya has trabajado con ello antes, o bien has llegado a este artículo buscando ayuda en Internet después de haber pasado un buen rato intentando seguir sin éxito los pasos de la incorrecta documentación oficial de multi-master en Kubernetes que hay publicada al respecto.

Bien por este motivo o bien porque quieres tener un servicio de etcd tolerante a fallos para tu proyecto, espero que con este artículo no te quede ninguna duda sobre cómo montar un cluster para conseguir alta disponibilidad y comunicaciones totalmente cifradas con SSL en el servicio de etcd.

Así que basta ya de hablar y vamos al turrón...

Hoy en dia nadie concibe (o nadie debería concebir, mejor dicho) empezar un proyecto de programación sin sus correspondientes tests. Tranquilidad en el desarrollo, código más robusto, anticiparnos a los errores, etc. son algunas de las maravillas que nos ofrece el mundo del testing, así que si tiene tantas ventajas... ¿porqué no íbamos a aplicarlo también a otros ámbitos que no sean exclusivamente los de la programación?

Ansible es una de esas herramientas indispensables para cualquiera que administre servidores, automatizando la instalación de nuevos servicios, el despliegue de aplicaciones, configuraciones, etc. permitiendo que llevemos a cabo todas esas tareas de forma sencilla, rápida y automatizada ya sea en un servidor, en diez o en miles de ellos mediante la creación de roles.

En este artículo voy a explicar cómo implementar el framework Molecule en dichos roles para poder testear su sintaxis, su idempotencia (me encanta esta palabra) y su ejecución en diferentes instancias con diferentes sistemas operativos y configuraciones.

Hay muchas formas de instalar diferentes versiones de Java en nuestros sistemas: en la propia web de Oracle (que como todos sabéis, es el propietario de Java desde hace varios años) podemos descargar diferentes versiones (9, 8, 7, ...), en diferentes formatos (comprimido con tar.gz, paquetes para CentOS/RedHat, ejecutables binarios, ...) y para diferentes sistemas operativos (Linux, MacOS, Windows y SPARC).

Incluso hay repositorios no-oficiales que ponen a disposición de todo el mundo los paquetes de instalación de Java en otros formatos, por lo que a simple vista cualquiera diría que existiendo tanta variedad incluso nosotros (fieles y exigentes defensores de Debian y de la mantenibilidad de los sistemas) estaríamos contentos, verdad?

Pues va a ser que no...

El SPAM es una de las mayores lacras que inundan Internet desde el principio de su creación. Genera cien veces más pérdidas a la sociedad que beneficio a sus creadores y supone el 84% de los emails que recibimos. Y este mal existe, entre otras cosas, porque el sistema de correo electrónico de Internet se diseñó dando por hecho que toda la gente que lo iba a utilizar lo haría de buena fe: craso error.

Pensar que nadie iba a utilizar el correo electrónico para hacer cosas malas hizo que se diseñara, entre otras muchas cosas, sin ningún sistema que garantice a quien los recibe que dichos mensajes no han sido manipulados por el camino o escritos por remitentes falsos.

Por estos motivos, Internet lleva años desarrollando herramientas y sistemas que ayuden a paliar los problemas de diseño que el correo electrónico tiene de base.

DKIM es uno de estos mecanismos, y permite a los destinatarios de un mensaje de correo electrónico saber si un email ha sido realmente enviado por el remitente y no por alguien haciéndose pasar por él (esta práctica se denomina mail spoofing).