Hace mucho tiempo inicié un proyecto de gestión de contenedores con la tecnología Docker Swarm, pero los tiempos modernos utilizan Kubernetes, así que hacer crecer este proyecto no parece buena idea.

Para ello empieza una nueva trayectoria, esta vez con Kubernetes, replicando los mismos servicios, mejorando algunas secciones gracias a la experiencia y añadiendo nuevos servicios.

Y así es como se estrena el K8s Project.

Después de mucho tiempo, inauguro una nueva sección de IT.

Esta sección está dedicada a servicios que no estén en contenedores (ya que para eso están los proyectos específicos), ni aquellos que sean servicios básicos, que se despliegan dentro del Rasp Project.

Podría mentir descaradamente diciendo que fue hace 4 días cuando empecé un nuevo proyecto, uno más grande que ningún otro de los que he llevado a cabo: renovar mi infraestructura para utilizar contenedores.

Claro que, cuando empiezas a poner una piedra, te das cuenta de que quizás deberías poner más piedras, y construir un muro, y mover ese río de ahí, construir un puente, el pueblo, el castillo, ¡una ciudad!

Y así es como se han llevado a cabo varios proyectos en paralelo: la renovación de la web, el Rasp Project, y el Swarm Project.

Desde hace años, todas las webs deben estar en HTTPS, si no es así, es muy posible que navegadores o servicios se nieguen a utilizarlas.

Cuando nuestra web está publicada a internet, es buena idea contratar un certificado o utilizar sistemas gratuitos como Let's Encrypt, pero cuando tu web no está publicada a Internet, si no que forma parte de tu intranet, la cosa se complica.

En estos casos, se utilizan certificados autofirmados, estos son completamente funcionales, pero tienen la pega de que todos los sistemas muestran un mensaje para avisar de que ellos no confían en el certificado, aun así, si están bien hechos, es posible minimizar o eliminar este problema.

Kubernetes tiene varias opciones para crear volúmenes, en otro artículo ya expliqué cómo utilizar NFS, ahora le toca a algo más profesional: GlusterFS.

GlusterFS es un sistema de réplica de datos, similar a crear una RAID a nivel de software, aunque tiene algunos extras, como la capacidad de hacer snapshots o la georeplicación. En caso de Kubernetes, únicamente nos interesa su capacidad para crear réplicas de los datos y compartirlas, similar a una carpeta compartida.

Debo avisar que GlusterFS es realmente grande y Kubernetes no está configurado "por defecto" para utilizarlo (requiere un intermediario: Heketi), así que su configuración es bastante compleja, y además hará falta obtener conocimientos de GlusterFS para gestionarlo manualmente si fuera necesario.

La mentalidad de los contenedores es que sus datos se pierden tras borrarse, así que los datos que necesitamos que no se pierdan, deberán ir en volumenes.

En caso de tener un Kubernetes desplegado en una Cloud, lo recomendable es utilizar el sistema de estos, pero si tenemos nuestro propio sistema, nos tendremos que apañar con lo que podamos.

El más sencillo de todos es asociar el volumen a una carpeta compartida por NFS.

Con la aparición de la virtualización, el mundo cambió, ahora podías dividir tu mega-servidor en pequeños servidores y así utilizar todo su potencial, sin duda, fue una gran mejora y quienes se opusieron a ello, acabaron cambiando de mentalidad.

Después de esto, apareció la Cloud, un timo en toda regla, donde pagas una barbaridad por un servicio que podrías tener en tu servidor físico por un precio claramente inferior, algo inaudito fue ver cómo la gente se movió hacia la Cloud creyendo que todo sería más barato, no lo fue, pero aun así su avance no ha parado (ni su precio).

No suficiente con ello, otro gran cambio apareció con los contenedores, ya no requieres virtualizar, puedes dividir el potenciar de tu servidor distribuyendo contenedores con los servicios que necesitas, y, además, estos se pueden replicar "fácilmente" entre otros servidores, lo que te permite tener pequeños servidores junto a grandes servidores (sí, ya existen cajas donde poner varios Raspberrys para crear un cluster realmente eficiente, aunque ojo que su CPU es ARM y no todos los contenedores son compatibles).

Hacia la cabeza de estos sistemas está Docker como creador y gestor de contenedores, y Kubernetes como gestor de despliegues. Existen otras opciones a Kubernetes (como Docker Swarm, que funciona perfectamente y es mucho más sencillo), pero no hay nada más extendido y libre que este.

Llevo tantos años siguiendo a SuSE, que ni siquiera me había planteado seriamente alguno de sus rivales, ni a nivel doméstico ni empresarial, SuSE tenía todo, una versión community y una de pago con soporte, seguía estando allá arriba junto a Red Hat.

Pero los tiempos cambian, unos se adaptan, y otros no.

En estos últimos años, he seguido utilizando OpenSuSE y viendo sus cambios de versión en solo 1 año vista, las actualizaciones que explotan destruyendo entornos de producción con pocos años, y teniendo que revisar todos los cambios de la siguiente versión antes de hacer el salto, debido a que podías llegar a perder un servidor sin darte cuenta por un motivo desconocido.

A todo esto, YaST cada vez era menos útil, debido a que los cambios tan rápidos hacían que YaST no llegara a actualizarse al mismo nivel.

Mientras, Red Hat junto a Fedora, y la versión CentOS de la comunidad han hecho unos grandes avances y cada vez han ido cogiendo más mercado, hasta el punto de luchar tu a tu contra Ubuntu en zonas domésticas, y quedarse el liderazgo en el ámbito empresarial.

Por todo esto, traigo una guía rápida para instalar CentOS.

El servicio de DHCP quizás es uno de los más olvidados, en muy raro que no esté disponible, y al funcionar de forma transparente, nadie le hace caso, además, en un sistema doméstico o una PYME, normalmente es el router del proveedor de Internet quien se encarga de esto, así que está ahí, pero nadie le hace caso.

La realidad es que es uno de los servicios más importantes, y más ahora con tantos dispositivos conectados a la red y que no pueden ajustar una IP fija, sin DHCP, muchos dispositivos ni siquiera funcionarían.

Además de asignar una IP diferente a cada dispositivo, este se debe encargar de poder definir una IP fija a una Mac, de esta forma podremos asignar IPs que no cambiarán a esos dispositivos que no pueden contener estáticas o para evitarnos tener que poner fijas a dispositivos que se mueven fuera de la red, otra aún más importante es poder enviar las DNS que queremos utilizar, y este último es lo que provoca que valga la pena obviar el servicio original de un router y tener un servidor DHCP propio.

Últimamente PostgreSQL es la base de datos que más está siendo implementada, debido a su origen OpenSource y su potencial que le permite estar a la altura de las grandes bases de datos de pago.

También hay que sumar la cantidad de años que tiene, lo que la hace una base de datos sólida, y con más funcionalidad que MariaDB, si principal rival en el OpenSource.

Actualmente muchas aplicaciones aceptan (e incluso recomiendan) su uso, si a eso añadimos que también está ganando dentro del mundo cloud y contenedores, la convierte en una base de datos a tener en cuenta.