Después de haber trabajado en TI durante 10 años, me he dado cuenta de que confiar en el hardware simplemente no es realista. Tiende a estropearse. Muy a menudo. Inesperadamente.
Por suerte, el mundo sigue girando y cada año aparecen más y más soluciones de alta disponibilidad. Crear una buena arquitectura de alta disponibilidad no es fácil. Intentando equilibrar la calidad y el precio, apliqué la virtualización, drdb, pacemaker, nginx y haproxy, y creé varios clústeres de bases de datos de alta disponibilidad (postgres, mysql) con conmutación por error automática y demás.
Naturalmente, construirlo manualmente solo puede ser interesante un número limitado de veces. Más tarde, estas soluciones se automatizaron con la ayuda de Puppet, a la que siguió SaltStack en un año.
Todo parecía funcionar bien.
Sin embargo, es más complicado de lo que parece:
Sin lugar a dudas, la virtualización resuelve la mayoría de estos problemas. En aquel entonces opté por usar KVM y configuré todos los entornos nuevos en su base. Muchas máquinas virtuales requieren control. Plataformas como CloudStack, OpenStack y algunas otras hacen frente de manera excelente a esta tarea.
Sin embargo, estas soluciones solo son eficaces para proyectos de mediana y gran escala. Si un proyecto es pequeño y comienza a crecer de forma espectacular, tenemos un problema. O bien tenemos que pagar de más y configurar originalmente una arquitectura complicada y voluminosa, o bien empezar a pasarnos a la nube cuando ya hay mucho tráfico de producción. Y, como todos saben, el traslado de la producción a una arquitectura diferente con un tiempo de inactividad mínimo es una tarea ardua.
Luego empecé a buscar contenedores, FreeBSD era mi favorito (a decir verdad, casi me convertí en un fan de FreeBSD). Era una forma rápida y sencilla de ejecutar un contenedor con el conjunto de software necesario en un entorno aislado, controlarlo y clonarlo fácilmente. Me encantaba trabajar con Jail y ZFS, especialmente con ZFS, tanto que cambié un proyecto de alojamiento de Python/Django de ZFS a Jail.
La única desventaja era que usar FreeBSD en todas partes era difícil: la gente, especialmente los desarrolladores, se acostumbraron a Linux. Era comprensible; Linux había expulsado a BSDN del mercado de alojamiento hace mucho tiempo.
Luego, en 2013, mientras descansaba en algún lugar de la costa vietnamita, me encontré con un proyecto de código abierto llamado Docker. La tecnología era tan inspiradora que no pude evitar escribir una aplicación de una página titulada Lanza tu sitio en 1 clic.
La idea era simple: hacías clic en un botón grande y obtenías un dominio, un repositorio git y un puerto SSH. Podías colocar tu código de Python en el git y verlo en el sitio, así como obtener acceso de raíz al contenedor si fuera necesario.
A la mañana siguiente publiqué el enlace a ese sitio en un grupo de google+ dedicado a Python y llevé mi moto al faro de la costa sur. Cuando regresaba a mi pueblo, mi teléfono tenía conexión a Internet y vi que mi cuenta de Google+ estaba repleta de mensajes. De hecho, ¡cientos de personas se apresuraron a probar este servicio!
Sin embargo, lo triste fue que alguien escribió: «He perdido tu servidor». Empecé a investigarlo inmediatamente después de mi regreso. Resultó que el disco SSD del servidor se había quedado sin espacio. Alguien simplemente ejecutó:
«si bien es verdadero; do date >> ~/1.bin; listo».
Esa persona se identificó en los comentarios. Dijo que Docker era una mala tecnología, que no tenía ninguna posibilidad en este universo y que openvz era la solución definitiva.
.jpg)
Hablando con franqueza, me frustró este giro de los acontecimientos. De hecho, no había límites en cuanto al espacio en disco de un contenedor Docker. Me acostumbré a las cuotas en ZFS y no podía entender cómo se podía crear algo similar en Docker.
Dicho todo esto, esa persona sacudió mi entusiasmo por Docker y dejé de desarrollarme en esa dirección. Sin embargo, no durante mucho tiempo.
En 2014 solo trabajaba como autónomo y tenía muchos proyectos jóvenes con requisitos muy similares. Todos necesitaban soluciones de arquitectura, tecnologías estándar y necesidades empresariales similares:
Entonces me acordé de Docker. Casi al mismo tiempo, aprendí sobre Gitlab (antes solía configurar gitolite + redmine, lo cual no era muy práctico).
Al final, se me ocurrió una solución que conectaba Docker con Gitlab. Git simplemente enganchó la creación de imágenes tras subirlas a un repositorio, las envió a un registro privado de Docker, lanzó pruebas de contenedores y, si todo iba bien, ordenaba a los servidores de diferentes entornos que recrearan el contenedor. Funcionó muy bien.
Para entonces había aprendido muy bien a trabajar con Docker Volume, Docker Network, y estaba recopilando mi propia colección de Dockerfiles, que contenía las imágenes más típicas utilizadas en los proyectos.
Más tarde obtuve archivos docker-compose, que me permitieron desarrollar rápidamente la composición para el desarrollo local.
Todo iba bien hasta que el proyecto empezó a crecer. La fuerza de ataque ya no era suficiente y surgió el problema de la orquestación de los contenedores. Luego me enteré de Tutum (ahora es https://cloud.docker.com/).
Tutum era un sueño. Dio la oportunidad de convertir un proyecto muy dinámico basado en la arquitectura de microservicios http://checkio.org en contenedores sin problemas, con el único inconveniente de almacenar las imágenes en sus servidores. No todos los clientes estarían de acuerdo con eso.
Cada mes, Docker se volvía más estable y funcional. ¡En un año, incluso dejé de compararlo con FreeBSD Jail! Así fue hasta el otoño de 2016, cuando se hizo necesario construir un clúster de alta disponibilidad con orquestación y escalabilidad para una empresa de apuestas.
Uno de los requisitos importantes era la velocidad de implementación, modularidad y alojamiento de los nuevos entornos en sus servidores dedicados. Los contenedores encajan bien en ese paradigma, pero tenía que incluir algo más para facilitar la administración en una arquitectura de múltiples servicios.
En ese momento había:
Empecé mi investigación con Docker Swarm, ya que era mucho más estable y estaba más cerca del propio Docker. Swarm demostró ser bastante bueno durante las pruebas, pero lo más importante que me hizo seguir buscando fue su falta de flexibilidad e incluso cierta medida de su escasez tecnológica.
Kubernetes de Google demostró ser un proyecto muy grande y prometedor con instalaciones flexibles y un práctico formato de manifiestos que emplea YAML.
Desarrollé rápidamente un prototipo a partir de un nodo maestro y varios nodos de minions y empecé a experimentar. Durante el primer mes, descubrí tantos errores que dediqué todo mi tiempo a revisarlos en problemas de githib y, si algún error era nuevo, a informarlo. ¡El código fue corregido y desarrollado a una velocidad fantástica!
Recuerdo haber informado de un error de instalación y haber ido a la estación de tren. Mientras estaba en mi taxi (unos 40 minutos), ¡arreglaron el error y lo enviaron al maestro!
Durante un par de meses, mi experiencia con Kubernetes fue similar a la de abrirme paso entre arbustos espinosos en algún lugar de las montañas.
Cada día, Kuber se volvía más y más estable, mientras que mis habilidades para trabajar con él mejoraban.
Kubernetes inició la producción con un tiempo de inactividad mínimo (un par de minutos para redirigir las consultas a la base de datos) y ahí estaba, funcionando a la perfección.
La implementación con Rolling Update (hablaremos de esto más adelante) eliminó el tiempo de inactividad en la mayoría de las implementaciones posteriores. La descripción de la arquitectura en los archivos YAML de Kubernetes permitió implementar nuevos entornos muy rápido. Además, la integración con gitlab permitió a los desarrolladores olvidarse de los problemas de incompatibilidad de las diferentes bibliotecas en diferentes entornos.
Más adelante, establecimos límites que ayudaban a funcionar de manera eficiente en caso de pérdida de memoria en uno de los microservidores, e incluso hicimos que este problema pasara desapercibido para el usuario hasta que se corrigiera en el código.
.jpg)
La supervisión ayudó a recopilar las mediciones según grupos de servicios específicos y a comprender cómo los cambios en el código afectan a la latencia y al consumo de recursos.
Durante los últimos 6 meses, nuestro equipo se ha especializado en proyectos relacionados con las criptomonedas. Es un mercado extremadamente curioso y dinámico y, lo que es importante, nuestro producto y experiencia cumplen con los requisitos del campo: alta disponibilidad, seguridad y escalado automático. Hasta ahora, hemos desarrollado varias soluciones de arquitectura listas para usar para proyectos típicos del lado del servidor que funcionan con la cadena de bloques:
Ahora estamos trabajando en la creación de un servicio REST, que puede simplificar el trabajo de las criptomonedas con la cadena de bloques: crear direcciones, realizar operaciones de transferencia de dinero y enviar automáticamente el dinero a la billetera remota.
También estamos trabajando en la creación de un instalador automático de HA Kubernetes en AWS con interfaz web, que le presentará algunas de nuestras soluciones y le dará la oportunidad de probarlas.
Por lo tanto, tenemos muchos descubrimientos por descubrir, que mi equipo y yo compartiremos con ustedes.
El viaje ha comenzado.
.jpg)
