Imagen tomada del sitio: https://www.muycomputer.com/wp-content/uploads/2023/05/FreeBSD.png
Imagen tomada del sitio: https://it-notes.dragas.net/featured/datacenter.webp
Buenos días/tardes/noches estimados blurtters que les gusta el Open-Source!
En esta ocasión vamos a hablar de un caso de éxito para solucionar los problemas de una empresa que tenía una solución en la nube con AWS, sustituyendolo con una solución basada en FreeBSD.
Del Caos a la Eficiencia de FreeBSD
Introdución
Hace algunos meses. un cliente me pidió hacerme cargo de su cluster de Kubernetes (hospedado en AWS y GCP). En su opinión, el coso era exorbitantemente alto para su sitios orientados a páginas web relativamente simples. Ellos tenían muchas visitas eso es seguro, pero nada demasiado excesivo ni que requiriera demasiada sabiduría en su desarrollo.
Yo amablemente decliné. Desafortunadamente su situación es demasiado común en estos días: ellos contrataron desarrolladores acostumbrados a trabajar de esa forma, convencidos de que un administrador de sistemas es algo innecesario hoy día "debido a que la nube tiene un potencial infinito.” Estaban acostumbrados a
considerar la optimización como algo secundario debido a que “tenemos poder infinito” (y esto ya es un espoiler para el final del post).
Estando abierto al diálogo y a nuevas experiencias, ellos pidieron mi opinión en el asunto. Hablamos por un tiempo, y yo expliqué que desde mi punto de vista, para el tipo de configuración que ellos tenían (estándar, sin varias réplicas y variantes, pero basado en dos plataformas principalmente), esto no tenía sentido. Y yo lo vi como que se estaban complicando las cosas.
Una excesiva reingeniería de algo simple. Era como tomar un trasatlantico para cruzar un río.
Y entonces ellos me pidieron crear algo simple que pudiera servir como servidor de desarrollo y para respaldos, para entender que tipo de solución tenía yo en mente.
La Solución
Por lo tanto, Comenzamos a construir todo. Comencé con FreeBSD 13.2-RELEASE, pero durante ese tiempo salió 14.0-RELEASE así que esa es la versión que se entregó.
Se instaló el sistema operativo en un servidor físico, rentado en uno de los proveedores principales de Europa. Aprovechando una de sus ofertas (hay unas muy buenas que pueden encontrarse los fines de semana), Ellos encontraron una máquina lo suficientemente poderosa, con 128 GB de RAM, 2 unidades NVMe de 1 TB cada uno, y dos discos de plato de 2 TB cada uno por menos de 100 euros por mes. Ellos también tomaron otro, menos poderoso para respaldos adicionales y para respaldar el primer equipo.
Implementación
Se decidió mantener el anfitrión tan limpio como fuera posible y se concentraron los servicios en "Jails" (administradas por BastilleBSD) y máquinas virtuales. La máquina fue dividida como sigue:
- Una serie de puentes - que serán usados para diferentes proyectos. Jails del mismo proyecto y/o tipo usan el mismo puente y pueden comunicarse con los demás, compartiendo algunos recursos (MariaDB, etc.).
- Una máquina virtual en bhyve con Alpine Linux - en opinión de un servidor, la mejor distribución para correr contenedores Docker. Realmente necesitamos systemd solo para lanzar Docker? Ellos lo usan principalmente como banca de pruebas de pre-producción, conectado vía VPN a la red local de su compañía. Es el núcleo de
su desarrollo "en línea", p.ej. fuera de sus computadoras. Ésta tiene 32 GB de RAM, 200 GB de disco (obviamente bhyve está configurado con controladores NVMe), y 4 núcleos asignados. - Una "Jail" VNET con un proxy inverso (nginx) - ellos saben como modificar anfitriones virtuales y generar certificados con certbot, apuntando a las jails subyacentes.
- Una serie de "Jails" VNET vacías, para ser clonadas. para cada tipo de configuración (ellos principalmente tienen un CMS basado en WordPress y Laravel, así que con todas las dependencias adentro nginx, php, redis, etc. excepto las bases de datos).
- Una "Jail" VNET con MariaDB instalada, para ser clonada, para conectarse a diferentes proyectos conforme se necesite.
- zfs-autobackup realiza instantaneas locales, manteniendo: una cada 15 minutes por 3 horas, una por hora durante 24 horas y una por día durante 3 días.
Los respaldos son realizados usando zfs-autobackup y, en caso de desastre recuperar de forma rápida, un comando zfs-send (y el correspondiente zfs-receive) cada 10 minutos en otra máquina (la otra, es una más pequeña, también adquirida de oferta), con los mismos puentes, reglas de muro de fuego, y con BastilleBSD y bhyve instalado y listo para arrancar en caso de desastre. Siendo un servidor de pruebas. no se consideró implementar un sistema de Alta Disponibilidad (HA) de momento, ya que no tendría sentido.
Ellos también tienen otra tarea con zfs-autobackup que realiza respaldos adicionales en un servidor (Debian en sus oficinas. Resguar Datos, en mi opinión, es mejor cuando los tienes de bajo de tu escritorio.
Se entregó todo a ellos y se les dió un curso breve a los desarrolladores más experimentados en cuanto a cómo administrar las cosas. No se requirió dar explicación de la Máquina Virtual de Alpine Linux, pero si se les mostró a ellos las "jails", como clonarlas, configurarlas y administrarlas.
Imágen tomada del sitio https://www.rhyous.com/wp-content/uploads/2010/12/FreeBSD-Box.png
Bueno, les deseo éxito en todo lo que hagan en relación al software opensource.
Estamos a la espera de sus comentarios, hasta la próxima publicación donde continuaremos con más sobre éste caso de éxito usando FreeBSD.
@cosmicboy123 fuera!
Si lo deseas puedes votar por mi como witness para poder aumentar las capacidades de un servidor.
https://blurtwallet.com/~witnesses?highlight=cosmicboy123
Integrate al grupo de Telegram de @team-mexico 😀 donde yo y otros usuarios de México y de otros países de habla hispana compartimos experiencias y opiniones así como nuestros propios posts. Una gran iniciativa de @cristo
| 👉Entra a https://t.me/TeamMexico 👈