☂️ 🧀 📐 Kubernetes en el espíritu de la piratería: nuestro camino hacia los microservicios y una plantilla preparada para la implementación 😏 🌧️ ❗️

Hola, soy Yuri Buylov, estoy desarrollando en CarPrice y también estoy implementando prácticas de DevOps, microservicios y Kubernetes. Quiero hablar sobre Kubernetes en el espíritu de la piratería, no solo sobre la gestión de un gran barco hermoso en velas, sino sobre una flota de pequeños barcos de pesca antiestéticos, a veces oxidados, pero muy rápidos, ágiles y peligrosos.

Será interesante para aquellos que desarrollan o transfieren la infraestructura a microservicios, implementan DevOps sobre Kubernetes y van a la nube nativa en todos los sentidos. Le contaré sobre nuestro camino, al final del artículo compartiré nuestras bases para el entorno de microservicios. Daré un enlace a una plantilla que será conveniente para los desarrolladores y evaluadores.

Este artículo se basa en una presentación en video en la @Kubernetes Conference de Mail.ru Cloud SolutionsSi no quieres leer, puedes ver .

Cómo vivíamos antes de Kubernetes: servidores de desarrollo, bare metal y Ansible

Vivimos y vivimos en un modo de cambios y experimentos constantes: pruebas AV, probando varias hipótesis. Lanzamos nuevos servicios, luego, si algo no funciona, lo cortamos.

Una vez tuvimos un monolito en el PHP, que trajo mucho dolor y sufrimiento. Para proporcionar un tiempo de comercialización aceptable, seguimos el camino típico: comenzamos a ver este monolito para microservicios. Como resultado, resultó que un monolito grande se convirtió en muchos monolitos pequeños. Esto es normal, este es el caso de todos los que se han enfrentado a una tarea similar.

Luego comenzamos a probar otras tecnologías, en particular, Golang apareció en nuestra empresa, luego se convirtió en el principal lenguaje de desarrollo. Hubo preguntas: ¿cómo desarrollar, probar y desplegar todo esto? La respuesta era obvia: necesitas un servidor de desarrollo. Cada desarrollador debe tener un servidor de desarrollo, donde puede conectarse para escribir código de alta calidad y alto rendimiento allí.

Como resultado, los chicos escribieron un servidor de desarrollo. El resultado fue una interfaz web que controlaba la composición de Docker en los servidores. También había un contenedor con código fuente, que estaba montado en docker-compose. El desarrollador podría conectarse a través de SSH y el programa. Los probadores también trabajaron allí, todo funcionó a la perfección.

Pero con el aumento en el número de servicios, se hizo imposible trabajar. Llegó el momento en que fue necesario desplegar algo, no desempacar los contenedores. Llevamos metal desnudo, enrollamos Docker allí. Luego tomaron Ansible, escribieron varios roles. Cada rol es un servicio en el que la composición de la ventana acoplable yace, que "llegó" a uno de los autos.

Así que vivimos: en nginx nos registramos río arriba con nuestras manos, nos dijeron a qué puerto deberíamos ir, dónde vive este servicio. Incluso había un archivo yaml donde se enumeraban todos los puertos para que las aplicaciones no compitieran por ellos.

Cómo llegamos a Kubernetes y construimos la infraestructura en él

Obviamente, uno no puede vivir así, se necesita orquestación. Entendimos esto en 2017-2018, entonces no estaba claro dónde obtener esta orquesta. Kubernetes recién comenzaba, había HashiCorp Nomad, Rancher, OpenShift. Intentamos con Nomad, no estaba mal, pero no queríamos reescribir docker-compose a las configuraciones de Nomad.

Sobre Kubernetes, inmediatamente nos dimos cuenta de que colegas extranjeros intentaron hacerlo, no siempre tuvieron éxito. Y no teníamos administradores barbudos que pudieran hacernos un clúster. Comenzaron a pensar cómo implementar esto. Incluso entonces Kubernetes estaba, por ejemplo, en Amazon, pero recordamos las cerraduras, después de lo cual se movieron con urgencia. Por lo tanto, esta opción se descartó de inmediato, todo el tráfico más costoso allí.

Y luego Kubernetes apareció en la plataforma Mail.ru Cloud Solutions como un servicio Mail.ru Cloud Containers. Ya hemos trasladado nuestro almacenamiento S3 desde Amazon, decidimos probar los K8 también. Implementamos un clúster en la nube, todo funcionó.

Para las pruebas, decidimos implementar algún servicio sin estado allí. Tomó una API para aplicaciones móviles, implementada: funciona. Envió allí el 50% del tráfico, funciona. Sí, algo caía periódicamente, pero los chicos lo arreglaron, todo estaba bien. Como resultado, se transfirió toda la infraestructura, ahora está construida alrededor de Kubernetes, principalmente servidores de desarrollo y de escenario.

Cada desarrollador tiene su propio Minikube en VMware, con el que trabaja. Lanzamos nuevos proyectos en Kubernetes en la nube MCS, también implementamos MySQL administrado, que llega de inmediato con todos los esclavos, réplicas y copias de seguridad en S3.

Todavía tenemos legado en el metal desnudo, incluido un clúster de Docker que ejecuta Ansible, pero algún día lo resolveremos.

Cómo vivir con un zoológico tecnológico y no sufrir

El zoológico tecnológico ahora no da tanto miedo como lo fue, por ejemplo, en 2011. Incluso es normal si puede tomar herramientas y tecnologías especializadas de diferentes lugares y usarlas como desee. Por ejemplo, usamos Golang para algunas cosas, pero Data Scientist trabaja en Python, no puede obligarlos a escribir en GO o PHP.

En general, tenemos dos reglas:

dockerize: debe haber contenedores;
observabilidad: estos contenedores deben ser observables.

Para continuar con la analogía con el zoológico: hay células, y no es tan importante quién se sienta en estas células. Lo principal es que el agua y los alimentos llegan de manera regular, automática y uniforme, y los "productos vitales" de los servicios, es decir, los registros, se envían a algún lugar central.

Para observar, tenemos una pila estándar: cada aplicación escribe registros en stdout, desde donde todo se transfiere centralmente a EFK. Es decir, el desarrollador puede venir y ver los registros en Kibana. Las métricas de aplicaciones que incluimos en Prometheus, paneles y alertas de serie en Grafana. Jaeger es una historia de Opentracing que muestra quién accede a qué servicio si no lo conocemos o no queremos tratarlo de otras maneras.

Cómo desarrollar y probar con todo esto

Digamos que un nuevo desarrollador viene a nosotros, ve 100 servicios y 100 repositorios. Él inmediatamente tiene preguntas. ¿Cómo implementar estos 100 servicios y cómo configurarlos? ¿Dónde están las bases de datos? ¿Qué cuentas hay? Y hay muchas de esas preguntas. Debido a esto, el lanzamiento del nuevo desarrollador tomó un tiempo indecente, podía sentarse durante una semana y configurar todo.

Como resultado, hemos desarrollado un entorno de desarrollo de 1 clic. Cada desarrollador tiene su propio Minikube con núcleos y memoria condicionalmente infinitos, implementados en la nube VMware. Además de una base de datos: viene diariamente de la producción, se ofusca, se comprime y se pone en ZFS. Este es un desarrollo personal de nuestro administrador. Hemos estado involucrados en la reducción de costos durante mucho tiempo, teníamos que darles a todos los desarrolladores una base y no quebrarnos.

Hay instantáneas en ZFS, un desarrollador de API puede transferir la base de datos directamente desde la producción en dos segundos. Con las pruebas automáticas, la misma historia: comenzamos por API, y todo funciona.

Así es como se ve hoy el flujo de desarrollo: el

desarrollador está contento, DevOps y los administradores están contentos porque todos los procesos son uniformes, repetibles y unificados. Pero hay una cosa.

Sistema de capas en capas

Como dijo Linus Torvalds: “Hablar es barato. Muéstrame el código ". Entonces, utilizamos un sistema de capas de niveles múltiples. Hay capas triviales: dev, stage, prod, que vienen a la mente para todos los que van a hacer CI / CD.

Pero todavía hay desarrolladores, necesitan algunos de sus dominios, algunas historias específicas de usuarios, por lo que tenemos una capa de valores de usuarios. Pero esto no es suficiente, aún debe realizar la prueba. Supongamos que creamos una rama, tal vez varios servicios, y necesitamos pasar esto al probador para que se repita. Para esto, tenemos una capa con valores para tareas, es decir, valores de tareas.

Otro momento, ligeramente holivarny: no usamos Tiller, nos decidimos por Helm, pero de hecho lo usamos como un motor de plantillas. Es decir, usamos solo helm-template, proporciona un archivo yaml en la salida, que se puede atribuir a Minikube o un clúster, y no se necesita nada más.

Cómo funciona el repositorio K8s-helm

Como dije, tenemos capas obvias de desarrollo, producción y etapa, hay un archivo yaml de cada servicio, cuando estamos guardando un nuevo servicio, agregamos el archivo.

Además, hay un servidor dev.dydy con los más interesantes. Hay scripts de bash que ayudan, por ejemplo, a crear un nuevo usuario: no cree 100 servicios con sus manos y no complete archivos yaml, sino que simplemente ejecute con un comando. Aquí es donde se generan todos estos archivos yaml.

En la misma carpeta hay una subcarpeta de tareas. Si necesitamos hacer algunos valores específicos para nuestro despliegue, simplemente creamos una carpeta con números de tarea dentro, confirmamos la rama. Luego le decimos al probador: "Tal rama se encuentra en el repositorio, tómala y ejecútala". Comienza, tira del comando que se encuentra en el bin bin, y todo funciona, no es necesario configurarlo a mano. El milagro de DevOps es una infraestructura como código.

Como resultado, el proceso se reduce a tres equipos:

Cuando llega un nuevo desarrollador, le dan Minikube, una carpeta de archivo con certificados y un dominio. En general, solo necesita kubectl y Helm. Clona el repositorio para sí mismo, le muestra a kubectl la ruta a su configuración, ejecuta el comando make_user con su nombre. Y para todos los servicios, se crean copias para él. Además, no solo se crean: hay una base de datos que se le dio, el desarrollador le recetó las credenciales y todas estas credenciales van a otros servicios.

El usuario ha sido creado. ¿Cómo puedo implementarlo ahora? Aquí tampoco hay nada complicado: ejecutamos deploy.sh con su nombre, y todo llega al desarrollador en el espacio de nombres predeterminado en su Minikube, todo está inmediatamente disponible en su dominio.

Si el desarrollador ha programado algo, toma la identificación del problema y se la entrega al probador. El probador copia esta rama, inicia una implementación y aparece un entorno con una nueva característica en su clúster.

Conjunto de timón K8s

El repositorio en sí también se compila y se integra en los procesos de CI / CD. Nada especial aquí, solo kubectl con certificados y Helm.

En el proyecto, se ve así:

suponga que está implementado, y hay una etapa en la que necesita primero la etapa, y luego ejecutar las pruebas allí con Jenkins. Desde el repositorio, tiene una imagen compilada con Helm. Ejecutamos el comando de despliegue del espacio de nombres service_stage run y todo despega.

Luego viene CI, aquí .drone.yml, pero casi lo mismo sucederá en GitLab o en otro lugar.

Luego, comienza Jenkins, que ejecuta las pruebas en el escenario. Si todo está bien, entonces comienza casi la misma implementación, pero ya en el producto. Es decir, este mecanismo no solo facilita la vida de los desarrolladores y probadores, sino que también se utiliza para ofrecer funciones a los productos.

Nos encanta el código abierto, queremos invertir en el desarrollo de DevOps, por lo que creamos una plantilla que puede usar y la subimos al github . Hay todo de lo que hablé: puedes tomar, mirar, probar y aplicar. Será útil para todos los que implementen microservicios, o sufran el hecho de que el equipo implemente microservicios, o quieran construir procesos DevOps alrededor de esto.

Nuestros otros artículos relacionados:

Esta charla se realizó por primera vez en la Conferencia @Kubernetes por Mail.ru Cloud Solutions. Mire un video de otras presentaciones e inscríbase en los anuncios de eventos de Telegram Around Kubernetes en Mail.ru Group .

Kubernetes en el espíritu de la piratería: nuestro camino hacia los microservicios y una plantilla preparada para la implementación