En Chelyabinsk se están llevando a cabo reuniones de administradores de sistemas Sysadminka y en la última presenté un informe sobre nuestra solución para ejecutar aplicaciones en 1C-Bitrix en Kubernetes.
Bitrix, Kubernetes, Ceph: ¿una gran combinación?
Te contaré cómo elaboramos una solución funcional a partir de todo esto.
¡Vamos!
La reunión tuvo lugar el 18 de abril en Chelyabinsk. Puedes leer sobre nuestras reuniones en y mira .
Si desea venir a nosotros con un informe o como oyente, bienvenido, escriba a [email protected] y en Telegram t.me/vadimisakanov.
Mi reporte
Solución "Bitrix en Kubernetes, versión Southbridge 1.0"
Hablaré de nuestra solución en formato “para principiantes en Kubernetes”, como se hizo en la reunión. Pero supongo que conoces las palabras Bitrix, Docker, Kubernetes, Ceph al menos al nivel de los artículos de Wikipedia.
¿Qué hay listo para usar sobre Bitrix en Kubernetes?
Hay muy poca información en Internet sobre el funcionamiento de las aplicaciones Bitrix en Kubernetes.
Sólo encontré estos materiales:
Informe de Alexander Serbul, 1C-Bitrix y Anton Tuzlukov de Qsoft:
Recomiendo escucharlo.
Desarrollando tu propia solución desde el usuario .
Encontré más .
Y... en realidad, eso es todo.
Te lo advierto, no hemos comprobado la calidad de las soluciones en los enlaces anteriores :)
Por cierto, mientras preparaba nuestra solución, hablé con Alexander Serbul, luego su informe aún no había aparecido, por lo que en mis diapositivas hay un elemento "Bitrix no usa Kubernetes".
Pero ya hay muchas imágenes de Docker listas para usar para ejecutar Bitrix en Docker:
¿Es esto suficiente para crear una solución completa para Bitrix en Kubernetes?
No. Hay una gran cantidad de problemas que deben resolverse.
¿Cuáles son los problemas con Bitrix en Kubernetes?
Primero, las imágenes listas para usar de Dockerhub no son adecuadas para Kubernetes
Si queremos construir una arquitectura de microservicios (y en Kubernetes normalmente lo hacemos), necesitamos separar nuestra aplicación de Kubernetes en contenedores y hacer que cada contenedor realice una pequeña función (y hacerlo bien). ¿Por qué sólo uno? En resumen, cuanto más sencillo, más fiable.
Para ser más específico, mire este artículo y video, por favor:
Las imágenes de Docker en Dockerhub se basan principalmente en el principio de todo en uno, por lo que todavía teníamos que hacer nuestra propia bicicleta e incluso crear imágenes desde cero.
Segundo: el código del sitio se edita desde el panel de administración
Creamos una nueva sección en el sitio: se actualizó el código (se agregó un directorio con el nombre de la nueva sección).
Si cambió las propiedades de un componente desde el panel de administración, el código cambió.
Kubernetes "por defecto" no puede funcionar con esto; los contenedores deben ser sin estado.
Motivo: cada contenedor (pod) del clúster procesa solo una parte del tráfico. Si cambia el código en un solo contenedor (pod), entonces el código será diferente en diferentes pods, el sitio funcionará de manera diferente y se mostrarán diferentes versiones del sitio a diferentes usuarios. No puedes vivir así.
Tercero: necesitas resolver el problema con la implementación.
Si tenemos un servidor monolito y un servidor "clásico", todo es bastante simple: implementamos una nueva base de código, migramos la base de datos, cambiamos el tráfico a la nueva versión del código. El cambio se produce instantáneamente.
Si tenemos un sitio en Kubernetes, dividido en microservicios, hay muchos contenedores con código, oh. Debe recopilar contenedores con una nueva versión del código, implementarlos en lugar de los antiguos, migrar correctamente la base de datos e, idealmente, hacerlo sin que los visitantes lo noten. Afortunadamente, Kubernetes nos ayuda con esto, admitiendo una gran cantidad de tipos diferentes de implementaciones.
Cuarto: es necesario resolver el problema del almacenamiento de estática.
Si su sitio tiene “sólo” 10 gigabytes y lo implementa completamente en contenedores, terminará con contenedores de 10 gigabytes que tardarán una eternidad en implementarse.
Es necesario almacenar las partes "más pesadas" del sitio fuera de los contenedores, y surge la pregunta de cómo hacerlo correctamente.
¿Qué falta en nuestra solución?
Todo el código Bitrix no está dividido en microfunciones/microservicios (por lo que el registro es independiente, el módulo de tienda online es independiente, etc.). Almacenamos toda la base del código en cada contenedor.
Tampoco almacenamos la base de datos en Kubernetes (todavía implementé soluciones con una base de datos en Kubernetes para entornos de desarrollo, pero no para producción).
Los administradores del sitio seguirán notando que el sitio se ejecuta en Kubernetes. La función "verificación del sistema" no funciona correctamente; para editar el código del sitio desde el panel de administración, primero debe hacer clic en el botón "Quiero editar el código".
Se han identificado los problemas, se ha determinado la necesidad de implementar microservicios, el objetivo es claro: conseguir un sistema que funcione para ejecutar aplicaciones en Bitrix en Kubernetes, preservando tanto las capacidades de Bitrix como las ventajas de Kubernetes. Comencemos la implementación.
Arquitectura
Hay muchos pods "en funcionamiento" con un servidor web (trabajadores).
Uno debajo con tareas cron (solo se requiere una).
Una actualización para editar el código del sitio desde el panel de administración (también solo se requiere una).
Resolvemos dudas:
- ¿Dónde almacenar sesiones?
- ¿Dónde almacenar el caché?
- ¿Dónde almacenar estática, no colocar gigabytes de estática en un montón de contenedores?
- ¿Cómo funcionará la base de datos?
imagen acoplable
Comenzamos construyendo una imagen de Docker.
La opción ideal es que tengamos una imagen universal, en base a ella obtenemos pods de trabajadores, pods con Crontasks y pods de actualización.
.
Incluye nginx, apache/php-fpm (se puede seleccionar durante la compilación), msmtp para enviar correo y cron.
Al ensamblar la imagen, todo el código base del sitio se copia al directorio /app (con la excepción de aquellas partes que moveremos a un almacenamiento compartido separado).
Microservicios, servicios.
grupos de trabajadores:
- Contenedor con nginx + contenedor apache/php-fpm + msmtp
- No funcionó mover msmtp a un microservicio separado, Bitrix está empezando a indignarse porque no puede enviar correo directamente
- Cada contenedor tiene una base de código completa.
- Prohibición de cambiar código en contenedores.
cron bajo:
- contenedor con apache, php, cron
- base de código completa incluida
- prohibición de cambiar el código en contenedores
actualizar en:
- contenedor nginx + contenedor apache/php-fpm + msmtp
- No hay prohibición de cambiar el código en los contenedores.
almacenamiento de sesión
Almacenamiento en caché Bitrix
Otra cosa importante: almacenamos las contraseñas para conectarnos a todo, desde la base de datos hasta el correo, en secretos de Kubernetes. Obtenemos una ventaja: las contraseñas son visibles solo para aquellos a quienes les damos acceso a los secretos, y no para todos los que tienen acceso al código base del proyecto.
Almacenamiento de estática
Puede usar cualquier cosa: ceph, nfs (pero no recomendamos nfs para producción), almacenamiento en red de proveedores de nube, etc.
El almacenamiento deberá estar conectado en contenedores al directorio /upload/ del sitio y a otros directorios con contenido estático.
База данных
Para simplificar, recomendamos mover la base de datos fuera de Kubernetes. La base en Kubernetes es una tarea compleja separada; hará que el esquema sea un orden de magnitud más complejo.
Almacenamiento de sesiones
Usamos memcached :)
Maneja bien el almacenamiento de sesiones, está agrupado y es compatible "de forma nativa" como session.save_path en php. Un sistema de este tipo se ha probado muchas veces en la arquitectura monolítica clásica, cuando construíamos clústeres con una gran cantidad de servidores web. Para el despliegue utilizamos helm.
$ helm install stable/memcached --name sessionphp.ini: aquí la imagen contiene configuraciones para almacenar sesiones en Memcached
Usamos variables de entorno para pasar datos sobre hosts con memcached .
Esto le permite usar el mismo código en los entornos de desarrollo, etapa, prueba y producción (los nombres de host de Memcached en ellos serán diferentes, por lo que debemos pasar un nombre de host único para las sesiones de cada entorno).
Almacenamiento en caché Bitrix
Necesitamos un almacenamiento tolerante a fallos en el que todos los pods puedan escribir y leer.
También utilizamos memcached.
Esta solución es recomendada por el propio Bitrix.
$ helm install stable/memcached --name cachebitrix/.settings_extra.php: aquí en Bitrix se especifica dónde se almacena el caché
También utilizamos variables de entorno.
Krontaski
Existen diferentes enfoques para ejecutar Crontasks en Kubernetes.
- implementación separada con un pod para ejecutar Crontasks
- cronjob para ejecutar crontasks (si se trata de una aplicación web, con wget , o kubectl exec dentro de uno de los pods de trabajadores, etc.)
- etc.
Se puede discutir cuál es la más correcta, pero en este caso elegimos la opción "implementación separada con pods para Crontasks".
Cómo está hecho:
- agregue tareas cron a través de ConfigMap o mediante el archivo config/addcron
- en un caso, lanzamos un contenedor idéntico al módulo de trabajadores + permitimos la ejecución de tareas de corona en él
- Se utiliza la misma base de código, gracias a la unificación, el montaje del contenedor es sencillo.
Qué bien obtenemos:
- tenemos Crontasks trabajando en un entorno idéntico al entorno de desarrolladores (docker)
- No es necesario "reescribir" las crontasks para Kubernetes, funcionan de la misma forma y en la misma base de código que antes.
- Todos los miembros del equipo con derechos de compromiso en la rama de producción pueden agregar tareas cron, no solo los administradores.
Módulo Southbridge K8SDeploy y edición de código desde el panel de administración
¿Estábamos hablando de actualización en?
¿Cómo dirigir el tráfico allí?
Hurra, escribimos un módulo para esto en PHP :) Este es un pequeño módulo clásico para Bitrix. Aún no está disponible públicamente, pero planeamos abrirlo.
El módulo se instala como un módulo normal en Bitrix:
Y se ve así:
Le permite configurar una cookie que identifica al administrador del sitio y permite a Kubernetes enviar tráfico al módulo de actualización.
Cuando se completen los cambios, debe hacer clic en git push, los cambios de código se enviarán a git, luego el sistema creará una imagen con una nueva versión del código y la "implementará" en todo el clúster, reemplazando los pods antiguos. .
Sí, es un poco una muleta, pero al mismo tiempo mantenemos la arquitectura de microservicios y no les quitamos a los usuarios de Bitrix su oportunidad favorita de corregir el código desde el panel de administración. Al final, esta es una opción, puedes solucionar el problema de editar el código de otra forma.
Carta de timón
Para crear aplicaciones en Kubernetes, normalmente utilizamos el administrador de paquetes Helm.
Para nuestra solución Bitrix en Kubernetes, Sergey Bondarev, nuestro administrador líder de sistemas, escribió un gráfico Helm especial.
Crea pods de trabajo, actualización y cron, configura ingresos, servicios y transfiere variables de secretos de Kubernetes a pods.
Almacenamos el código en Gitlab y también ejecutamos la compilación de Helm desde Gitlab.
En resumen, se ve así
$ helm upgrade --install project .helm --set image=registrygitlab.local/k8s/bitrix -f .helm/values.yaml --wait --timeout 300 --debug --tiller-namespace=productionHelm también le permite realizar una reversión "sin interrupciones" si de repente algo sale mal durante la implementación. Es agradable cuando no estás en pánico "arregla el código a través de ftp porque se cayó el producto", pero Kubernetes lo hace automáticamente y sin tiempo de inactividad.
Desplegar
Sí, somos fanáticos de Gitlab y Gitlab CI, lo usamos :)
Al comprometerse en Gitlab con el repositorio del proyecto, Gitlab lanza una canalización que implementa una nueva versión del entorno.
Pasos:
- construir (construir una nueva imagen de Docker)
- prueba (prueba)
- limpiar (eliminar el entorno de prueba)
- push (lo enviamos al registro de Docker)
- implementar (implementamos la aplicación en Kubernetes a través de Helm).
¡Hurra, está listo, implementémoslo!
Bueno, o haz preguntas si las hay.
Entonces, qué hicimos
Desde un punto de vista técnico:
- Bitrix acoplado;
- "cortar" Bitrix en contenedores, cada uno de los cuales realiza un mínimo de funciones;
- logró el estado sin estado de los contenedores;
- resolvió el problema con la actualización de Bitrix en Kubernetes;
- todas las funciones de Bitrix siguieron funcionando (casi todas);
- Trabajamos en la implementación en Kubernetes y la reversión entre versiones.
Desde un punto de vista empresarial:
- Tolerancia a fallos;
- Herramientas de Kubernetes (fácil integración con Gitlab CI, implementación perfecta, etc.);
- contraseñas secretas (visibles sólo para aquellos a quienes se les concede acceso directo a las contraseñas);
- Es conveniente crear entornos adicionales (para desarrollo, pruebas, etc.) dentro de una única infraestructura.
Fuente: habr.com