Difícilmente sería incorrecto decir que los mejores de las personas
encuentran alegría a través del sufrimiento.
Ludwig van Beethoven
Soy Sergey, trabajo en Yandex.Money en el equipo de investigación de rendimiento. Quiero contarles el inicio de la historia de nuestro camino hacia el uso de la orquestación: cómo elegimos las herramientas y qué consideramos al hacerlo. Todos los eventos de este artículo ocurren en tiempo real, por lo que ustedes, queridos lectores, seguirán el desarrollo de la situación casi en vivo.
¿Por qué necesitamos un director en el equipo?
¿Quién es un director? Del francés diriger — gestionar, dirigir, guiar — en el mundo de la música, es la persona que dirige el ensayo y la ejecución de la música de conjunto. En nuestro caso, este papel es ocupado por sistemas de orquestación y automatización.
Su papel no difiere en nada del papel de un director en la música: son necesarios para ayudar al equipo, guiar y organizar su interpretación.
Por lo general, el equipo cuenta con un cierto conjunto de capacidades — llamémoslas servidores, en los que llevan a cabo sus proyectos.
El enfoque para adquirir y operar estos servidores es diverso. Algunos ejemplos:
- El equipo hace una solicitud, por ejemplo, al grupo de operaciones, para que les proporcionen recursos con ciertos parámetros.
- El grupo de operaciones les proporciona la cantidad necesaria — cloud o bare metal («hardware desnudo») — y se comprometen a mantenerlos en el estado adecuado según SLA. La configuración también es realizada por el grupo de operaciones.
- El equipo recibe solo recursos cloud o bare metal del grupo de operaciones, la configuración la realiza por su cuenta.
- El equipo mismo 'compra' los recursos y los mantiene/configura completamente de manera independiente.
En nuestro equipo se utilizan servidores que necesitan mantenimiento — actualizar el sistema operativo, instalar nuevos paquetes, etc.
Para nosotros, los hemos clasificado en dos tipos principales:
- grupo de tanques,
- grupo de servicios.
El grupo de tanques consiste en hosts con Yandex.Tank.
El grupo de servicios incluye todo lo relacionado con el mantenimiento — son varios servicios para garantizar el ciclo de vida de lanzamientos, generación de informes automáticos, etc.
En un momento, se volvió complicado gestionar todo esto manualmente, y comenzamos a considerar la automatización de todo el proceso, desde el "provisionamiento" de servidores hasta el desarrollo, implementación y lanzamiento de nuestro servicio interno.
¿Por qué se necesita un director, incluso si la orquesta puede tocar por sí sola?
Primero, dominamos Ansible y comenzamos a "provisionar" nuestros servidores bare metal, para ser menos dependientes de los administradores de sistemas; aquí todos ganan, adquirimos nuevas habilidades y aliviamos a los administradores de parte del trabajo que siempre tienen de sobra. Nos esforzamos por desarrollarnos fuera de nuestra especialidad y ser lo más autónomos posible.
En la empresa, el trabajo con Ansible ya está bastante establecido y regulado, por lo que incorporamos fácilmente nuestra solución a este proceso.
Actualmente, el aprovisionamiento de hosts consta de tres roles de Ansible:
- el primer rol instala el sistema operativo,
- el segundo aplica configuraciones básicas para el host, como la autorización LDAP,
- y el tercero instala Yandex.Tank en un contenedor Docker junto con sus dependencias.
Pasemos a los servicios que utilizamos dentro del equipo.
Para nuestras tareas, usamos de igual manera Kotlin y Python, y también un poco de Golang. Para unificar el desarrollo y la implementación de nuestros servicios, decidimos empaquetarlos en contenedores Docker. Esto permite la libertad de elección del lenguaje de programación y al mismo tiempo regula un formato único para la entrega de nuestra aplicación.
Una pequeña nota sobre ipv6 en Docker
Parte de los servicios con los que interactuamos solo están disponibles a través de ipv6, por lo que tuvimos que investigar cómo habilitar ipv6 para los contenedores.
Según la documentación sobre ipv6 en el sitio oficial de Docker, se habilita ipv6 añadiendo parámetros en daemon.json:
{
"ipv6": true,
"fixed-cidr-v6": "2001:db8:1::/64"
}El proveedor debe emitir la subred ipv6 que se indicará en fixed-cidr-v6.
Sin embargo, elegimos otra opción: NAT ipv6, y aquí está el porqué:
- Actualmente, en Docker solo con ipv6.
- La presencia de una dirección globalmente enrutable en cada contenedor significa que todos los puertos (incluso los no publicados) se vuelven accesibles para todos, a menos que se implemente un filtrado adicional.
- userland proxy para la publicación de puertos, .
NAT ipv6 es , que gestiona las reglas en ip6tables y las edita al agregar un nuevo contenedor.
Para que esta solución funcione correctamente, fue necesario realizar una serie de manipulaciones adicionales. Es fundamental inicializar ip6table_nat en el sistema. La presencia de este módulo en el sistema no garantiza que se cargue en el núcleo al iniciarse. Nos encontramos con esto cuando recibimos el siguiente error al iniciar un contenedor con NAT en un nuevo host:
2019/01/22 14:59:54 ejecutando [/sbin/ip6tables -t filter -N DOCKER --wait]: estado de salida 3: modprobe: no se puede cambiar el directorio a '/lib/modules': No hay tal archivo o directorio
ip6tables v1.6.2: no se puede inicializar la tabla ip6tables `filter': La tabla no existe (¿necesita insmod?)El problema se resolvió después de agregar a la función de Ansible la inicialización mediante el módulo modprobe y la carga al iniciar el sistema operativo con lineinfile:
- name: Agregar módulo ip6table_nat
modprobe:
name: ip6table_nat
state: present
- name: Agregar ip6table_nat al inicio
lineinfile:
path: /etc/modules
line: 'ip6table_nat'Por cierto, hay un buen artículo en Habr , que describe brevemente y con claridad las ventajas y desventajas de diferentes métodos para trabajar con ipv6 en docker.
Pero volvamos a nuestro tema planteado al principio:
¿Por qué se necesita un director, incluso si la orquesta puede tocar por sí sola?
Ahora todos entienden cómo jugar en nuestro equipo:
- se ha creado el proceso de "provisionamiento" de servidores,
- el desarrollo y despliegue de servicios están unificados.
Surge una pregunta razonable: ¿cómo desplegar, actualizar y monitorear nuestros servicios en contenedores docker de manera eficiente y automatizada?
A pesar de que cada miembro de la orquesta conoce su parte, puede confundirse, desviarse de la idea original. Aquí es donde llegamos a la conclusión de que sin un director, nuestra orquesta no podrá ensayar ni tocar de manera efectiva. El director es responsable de todos los parámetros de ejecución, de que todo esté unificado en un mismo tempo y estado de ánimo.
¿Cómo conseguir un buen director con una inversión mínima?
El tema de la orquestación está bastante desarrollado en el mercado. Pero primero hablemos de las herramientas auxiliares que pueden ayudar al director.
— un sistema que proporciona dos funciones principales:
- descubrimiento de servicios (service discovery),
- almacenamiento distribuido de clave-valor.
En nuestra orquesta, Consul se encargará del registro de servicios y del almacenamiento de sus configuraciones. Hay dos variantes de registro:
- Activa — cuando el servicio se registra a sí mismo usando HTTP API;
- Pasiva — se debe registrar el servicio manualmente.
Vault es un repositorio que estandariza y unifica el almacenamiento seguro y el manejo de secretos: contraseñas, certificados.
Estas son las ventajas que obtendremos al utilizar esta herramienta:
- Un centro único para la creación y almacenamiento de secretos, gestionando su ciclo de vida a través de la API HTTP.
- Transit Secrets Engine permite cifrar y descifrar datos sin almacenarlos. Posibilidad de transmitir datos en formato cifrado a través de canales no seguros.
- Políticas de acceso que se pueden configurar fácilmente.
- Auditoría de acceso a los secretos.
- Posibilidad de crear su propia CA (Autoridad Certificadora) para gestionar certificados autofirmados dentro de su infraestructura.
Teniendo en cuenta todos nuestros requisitos, había dos opciones adecuadas para el orquestador: Kubernetes y Nomad.
Kubernetes
Cuántos artículos y libros se han escrito sobre él (aquí , por ejemplo), se han dado tantas charlas que escribiré brevemente: es un combinador universal que puede prácticamente hacer de todo. El precio a pagar por esto es que la configuración y el mantenimiento del clúster en Kubernetes no siempre son sencillos.
Nomad
de HashiCorp, una empresa conocida por los mencionados consul y vault.
Nos pareció que Nomad era bastante más fácil de instalar y configurar que Kubernetes. Un solo archivo binario funciona tanto en modo servidor como cliente. Además, Nomad cubre toda la lista de tareas que queremos que resuelva: gestión del clúster, programador rápido, soporte para multidatacenter. Además, al usar consul y vault, obtenemos una integración más estrecha para la orquestación de nuestros servicios.
Actualmente en proceso:
- hemos preparado los servidores para el despliegue de Consul,
- en Consul se cargará la configuración del clúster de nomad, con la que nomad debe desplegarse automáticamente,
- mientras tanto, estaremos instalando vault para el almacenamiento de secretos.
Pregunta al público: ¿vale la pena establecer un orquestador para tales tareas o se puede orquestar bien sin él? Cuéntanos en los comentarios qué piensas al respecto.
Suscríbete a nuestro blog y mantente en contacto: pronto te contaremos qué resultados obtuvimos y si configuramos el clúster de nomad como queríamos.
Visita nuestro acogedor , donde siempre puedes pedir consejo, ayudar a colegas y simplemente hablar sobre investigaciones de rendimiento y más.
Fuente: habr.com
