As reunións do administrador do sistema Sysadminka están a ter lugar en Chelyabinsk, e na última dei un informe sobre a nosa solución para executar aplicacións en 1C-Bitrix en Kubernetes.
Bitrix, Kubernetes, Ceph - unha gran mestura?
Vouche contar como elaboramos unha solución de traballo a partir de todo isto.
Imos alí!
A reunión tivo lugar o 18 de abril en Chelyabinsk. Podes ler sobre as nosas reunións en e mira .
Se queres vir a nós cunha reportaxe ou como oínte, benvido, escribe a [protexido por correo electrónico] e en Telegram t.me/vadimisakanov.
O meu informe
Solución "Bitrix en Kubernetes, versión Southbridge 1.0"
Falarei da nosa solución no formato "para dummies en Kubernetes", como se fixo na reunión. Pero supoño que coñeces as palabras Bitrix, Docker, Kubernetes, Ceph polo menos a nivel de artigos na Wikipedia.
Que está feito de Bitrix en Kubernetes?
Hai moi pouca información en toda Internet sobre o funcionamento das aplicacións Bitrix en Kubernetes.
Só atopei estes materiais:
Informe de Alexander Serbul, 1C-Bitrix e Anton Tuzlukov de Qsoft:
Recomendo escoitalo.
Desenvolvendo a súa propia solución a partir do usuario .
Atopou máis .
Aaand... en realidade, iso é todo.
Advírtoche que non comprobamos a calidade das solucións nas ligazóns anteriores :)
Por certo, ao preparar a nosa solución, falei con Alexander Serbul, entón o seu informe aínda non aparecera, polo que nas miñas diapositivas hai un elemento "Bitrix non usa Kubernetes".
Pero xa hai moitas imaxes de Docker preparadas para executar Bitrix en Docker:
¿É suficiente para crear unha solución completa para Bitrix en Kubernetes?
Non. Hai unha gran cantidade de problemas que hai que resolver.
Cales son os problemas con Bitrix en Kubernetes?
En primeiro lugar, as imaxes preparadas de Dockerhub non son adecuadas para Kubernetes
Se queremos construír unha arquitectura de microservizos (e en Kubernetes adoitamos facer), necesitamos separar a nosa aplicación Kubernetes en contedores e que cada contedor realice unha pequena función (e o faga ben). Por que só un? En resumo, canto máis sinxelo, máis fiable.
Para ser máis específico, mira este artigo e vídeo, por favor:
As imaxes de Docker en Dockerhub baséanse principalmente no principio de todo-en-un, polo que aínda tivemos que facer a nosa propia bicicleta e incluso crear imaxes desde cero.
Segundo: o código do sitio é editado desde o panel de administración
Creamos unha nova sección no sitio: o código actualizouse (engadiuse un directorio co nome da nova sección).
Se cambiaches as propiedades dun compoñente desde o panel de administración, o código cambiou.
Kubernetes "por defecto" non pode funcionar con isto; os contedores deben ser sen estado.
Motivo: cada contedor (pod) do clúster procesa só unha parte do tráfico. Se cambias o código só nun recipiente (pod), entón o código será diferente en diferentes pods, o sitio funcionará de forma diferente e mostraranse diferentes versións do sitio a diferentes usuarios. Non se pode vivir así.
En terceiro lugar, cómpre resolver o problema coa implantación
Se temos un monólito e un servidor "clásico", todo é bastante sinxelo: despregamos unha nova base de código, migramos a base de datos, cambiamos o tráfico á nova versión do código. O cambio prodúcese ao instante.
Se temos un sitio en Kubernetes, cortado en microservizos, hai moitos contedores con código - oh. Necesitas recoller contedores cunha nova versión do código, lanzalos en lugar dos antigos, migrar correctamente a base de datos e, idealmente, facelo desapercibido para os visitantes. Afortunadamente, Kubernetes axúdanos con isto, admitindo un montón de diferentes tipos de despregamentos.
En cuarto lugar, cómpre resolver o problema do almacenamento de estática
Se o teu sitio ten "só" 10 gigabytes e o implementas enteiramente en contedores, acabarás con contedores de 10 gigabytes que tardan unha eternidade en implementarse.
Debe almacenar as partes "máis pesadas" do sitio fóra dos contedores, e xorde a pregunta de como facelo correctamente
Que falta na nosa solución?
Todo o código Bitrix non está dividido en microfuncións/microservizos (de xeito que o rexistro é separado, o módulo da tenda en liña está separado, etc.). Almacenamos toda a base de código en cada recipiente.
Tampouco almacenamos a base de datos en Kubernetes (aínda implementei solucións cunha base de datos en Kubernetes para ambientes de desenvolvemento, pero non para produción).
Os administradores do sitio seguirán notando que o sitio funciona en Kubernetes. A función de "comprobación do sistema" non funciona correctamente; para editar o código do sitio desde o panel de administración, primeiro debes facer clic no botón "Quero editar o código".
Identificáronse os problemas, determinouse a necesidade de implementar microservizos, o obxectivo é claro: conseguir un sistema que funcione para executar aplicacións en Bitrix en Kubernetes, preservando tanto as capacidades de Bitrix como as vantaxes de Kubernetes. Comecemos a implementación.
Arquitectura
Hai moitos pods "funcionantes" cun servidor web (traballadores).
Un baixo con tarefas cron (só é necesario un).
Unha actualización para editar o código do sitio desde o panel de administración (tamén só se precisa unha).
Resolvemos preguntas:
- Onde gardar as sesións?
- Onde almacenar a caché?
- Onde almacenar estática, non para colocar gigabytes de estática nun montón de contedores?
- Como funcionará a base de datos?
Imaxe de Docker
Comezamos construíndo unha imaxe de Docker.
A opción ideal é que teñamos unha imaxe universal, sobre a súa base obtemos pods de traballadores, pods con Crontasks e pods de actualización.
.
Inclúe nginx, apache/php-fpm (pódese seleccionar durante a compilación), msmtp para enviar correo e cron.
Ao montar a imaxe, todo o código base do sitio cópiase no directorio /app (a excepción daquelas partes que moveremos a un almacenamento compartido separado).
Microservizos, servizos
vainas de traballadores:
- Contedor con nginx + contenedor apache/php-fpm + msmtp
- Non funcionou mover msmtp a un microservizo separado, Bitrix comeza a indignarse porque non pode enviar correo directamente
- Cada contedor ten unha base de código completa.
- Prohibición de cambiar código nos contedores.
cron baixo:
- contenedor con apache, php, cron
- base de código completa incluída
- prohibición de cambiar o código nos contedores
actualizar baixo:
- contenedor nginx + contenedor apache/php-fpm + msmtp
- Non hai prohibición de cambiar o código nos contedores
almacenamento da sesión
Almacenamento en caché Bitrix
Outra cousa importante: almacenamos os contrasinais para conectarnos a todo, dende a base de datos ata o correo, en segredos de kubernetes. Temos un extra: os contrasinais son visibles só para aqueles aos que lles damos acceso aos segredos, e non para todos os que teñen acceso ao código base do proxecto.
Almacenamento para estática
Podes usar calquera cousa: ceph, nfs (pero non recomendamos nfs para a produción), almacenamento en rede de provedores de nube, etc.
O almacenamento terá que estar conectado en contedores ao directorio /upload/ do sitio e a outros directorios con contido estático.
Base de datos
Para simplificar, recomendamos mover a base de datos fóra de Kubernetes. A base en Kubernetes é unha tarefa complexa separada; fará que o esquema sexa unha orde de magnitude máis complexo.
Almacenamento da sesión
Usamos memcached :)
Xestiona ben o almacenamento da sesión, está agrupado e é compatible "de forma nativa" como session.save_path en php. Tal sistema foi probado moitas veces na arquitectura monolítica clásica, cando construímos clusters cunha gran cantidade de servidores web. Para o despregamento usamos helm.
$ helm install stable/memcached --name sessionphp.ini: aquí a imaxe contén a configuración para almacenar sesións en memcached
Usamos variables de ambiente para pasar datos sobre hosts con memcached .
Isto permítelle usar o mesmo código nos contornos de desenvolvemento, escenario, proba e produto (os nomes de host almacenados en memcache serán diferentes, polo que necesitamos pasar un nome de host único para as sesións a cada ambiente).
Almacenamento en caché Bitrix
Necesitamos almacenamento tolerante a fallos no que todos os pods poidan escribir e ler.
Tamén usamos memcached.
Esta solución é recomendada pola propia Bitrix.
$ helm install stable/memcached --name cachebitrix/.settings_extra.php - aquí en Bitrix especifícase onde se almacena a caché
Tamén usamos variables de ambiente.
Krontaski
Hai diferentes enfoques para executar Crontasks en Kubernetes.
- implementación separada cun pod para executar Crontasks
- cronjob para executar crontasks (se esta é unha aplicación web - con wget , ou kubectl exec dentro dun dos módulos de traballo, etc.)
- etc.
Podes discutir sobre o máis correcto, pero neste caso escollemos a opción "implementación separada con pods para Crontasks"
Como se fai:
- engadir tarefas cron mediante ConfigMap ou mediante o ficheiro config/addcron
- nun caso lanzamos un contedor idéntico ao pod do traballador + permitimos a execución de tarefas da coroa nel
- utilízase a mesma base de código, grazas á unificación, a montaxe do recipiente é sinxela
Que ben temos:
- temos Crontasks que funcionan nun ambiente idéntico ao ambiente dos desenvolvedores (docker)
- As crontasks non precisan ser "reescritas" para Kubernetes, funcionan na mesma forma e na mesma base de código que antes
- As tarefas cron poden ser engadidas por todos os membros do equipo con dereitos de commit na rama de produción, non só os administradores
Southbridge K8SDeploy módulo e edición de código desde o panel de administración
Estivemos a falar de actualización en?
Como dirixir o tráfico alí?
Hurrah, escribimos un módulo para isto en PHP :) Este é un pequeno módulo clásico para Bitrix. Aínda non está dispoñible para o público, pero temos previsto abrilo.
O módulo está instalado como un módulo normal en Bitrix:
E vese así:
Permítelle configurar unha cookie que identifique ao administrador do sitio e permite que Kubernetes envíe tráfico ao pod de actualización.
Cando se completen os cambios, cómpre facer clic en git push, os cambios de código enviaranse a git e, a continuación, o sistema creará unha imaxe cunha nova versión do código e "desprazaao" no clúster, substituíndo os antigos pods. .
Si, é un pouco unha muleta, pero ao mesmo tempo mantemos a arquitectura do microservizo e non quitamos aos usuarios de Bitrix a súa oportunidade favorita de corrixir o código desde o panel de administración. Ao final, esta é unha opción; podes resolver o problema de editar o código dunha forma diferente.
Gráfico de timón
Para crear aplicacións en Kubernetes, normalmente usamos o xestor de paquetes Helm.
Para a nosa solución Bitrix en Kubernetes, Sergey Bondarev, o noso principal administrador do sistema, escribiu un gráfico especial de Helm.
Constrúe worker, upgrade, cron pods, configura entradas, servizos e transfire variables dos segredos de Kubernetes aos pods.
Almacenamos o código en Gitlab e tamén executamos a compilación Helm de Gitlab.
En resumo, parece así
$ helm upgrade --install project .helm --set image=registrygitlab.local/k8s/bitrix -f .helm/values.yaml --wait --timeout 300 --debug --tiller-namespace=productionHelm tamén che permite facer un retroceso "sen interrupcións" se de súpeto algo falla durante a implantación. É bo cando non estás en pánico "arranxa o código a través de ftp porque caeu o produto", pero Kubernetes faino automaticamente e sen tempo de inactividade.
Implantar
Si, somos fans de Gitlab e Gitlab CI, usámolo :)
Cando se compromete en Gitlab ao repositorio do proxecto, Gitlab lanza unha canalización que desprega unha nova versión do ambiente.
Etapas:
- construír (construír unha nova imaxe de Docker)
- proba (proba)
- limpar (eliminar o ambiente de proba)
- push (enviámolo ao rexistro de Docker)
- implementar (implantamos a aplicación en Kubernetes a través de Helm).
Vaia, xa está listo, poñémolo en práctica!
Ben, ou fai preguntas se as hai.
Entón, que fixemos
Desde o punto de vista técnico:
- Bitrix dockerizado;
- "cortar" Bitrix en recipientes, cada un dos cales realiza un mínimo de funcións;
- conseguiu o estado sen estado dos contedores;
- resolveu o problema coa actualización de Bitrix en Kubernetes;
- todas as funcións de Bitrix continuaron funcionando (case todas);
- Traballamos na implementación en Kubernetes e na restauración entre versións.
Dende o punto de vista empresarial:
- tolerancia a fallos;
- Ferramentas de Kubernetes (fácil integración con Gitlab CI, implementación sen problemas, etc);
- contrasinais secretos (visibles só para aqueles que teñan acceso directamente aos contrasinais);
- É conveniente crear ambientes adicionais (para desenvolvemento, probas, etc.) dentro dunha única infraestrutura.
Fonte: www.habr.com