Southbridge в Челябинск и Bitrix в Kubernetes

В Челябинске се провеждат митапи за системни администратори Sysadminka, и на последния от тях представих нашето решение за работа с приложения на 1C-Bitrix в Kubernetes.

Bitrix, Kubernetes, Ceph — отлична комбинация?

Нека ви разкажа как събрахме работещо решение от всичко това.

Да тръгваме!

Митапът се състоя на 18 април в Челябинск. За нашите митапи можете да прочетете в Timepad и да гледате на YouTube.

Ако искате да се присъедините с доклад или като слушател — заповядайте, пишете на vadim.isakanov@gmail.com и в Telegram t.me/vadimisakanov.

Моят доклад

Слайдове

Решение «Bitrix в Kubernetes, версия Southbridge 1.0»

Ще ви разкажа за нашето решение в формат «за начинаещи в Kubernetes», както беше направено на митапа. Предполагам, че думите Bitrix, Docker, Kubernetes, Ceph са ви известни поне на ниво статии в Wikipedia.

Какво наистина има готово за Bitrix в Kubernetes?

В интернет има много малко информация за работата на приложенията с Bitrix в Kubernetes.
Намерих само такива материали:

Доклад от Александър Сербул и Антон Тузлуков от Qsoft:

Препоръчвам да го изслушате.

Разработка на собствено решение от потребител serkyron на Хабра.
Намерих още такова решение.

Ииии… всъщност, това е всичко.

Предупреждавам, качеството на решенията по линковете горе не е проверявано 🙂
Между другото, при подготовката на нашето решение общувах с Александър Сербул, тогава неговият доклад още не беше готов, затова в моите слайдове има пункт «Bitrix не използва Kubernetes».

Но затова пък готовите Docker образи за работа с Bitrix в Docker вече са много: https://hub.docker.com/search?q=bitrix&type=image

Достатъчни ли са те за създаване на пълно решение за Bitrix в Kubernetes?
Не. Има много проблеми, които трябва да се решат.

Какви са проблемите с Bitrix в Kubernetes?

Първият — готовите образи от Dockerhub не са подходящи за Kubernetes.

Ако искаме да изградим микросервизна архитектура (а в Kubernetes обикновено искаме), приложението в Kubernetes трябва да се разделя на контейнери и да се стремим всеки контейнер да изпълнява една малка функция (и да я изпълнява добре). Защо само една? Ако накратко — колкото по-просто, толкова по-надеждно.
Ако искате по-подробно — моля, вижте тази статия и видео: https://habr.com/ru/company/southbridge/blog/426637/

Docker образите в Dockerhub основно са изградени по принципа «всичко в едно», затова се наложи все пак да направим свой велосипед и дори да измислим образи от нулата.

Вторият — кодът на сайта се променя от административната панел.

Създадохме нов раздел на сайта — кодът е актуализиран (добавена е директория с името на новия раздел).

Променихме свойствата на компонента от администраторския панел — кодът е променен.

Kubernetes „по подразбиране“ не може да работи с това, контейнерите трябва да бъдат неизменяеми (Stateless).

Причина: всеки контейнер (под) в клъстера обработва само част от трафика. Ако промените кода само в един контейнер (под), то в различните подове кодът ще бъде различен, сайтът ще работи по различен начин и на различни потребители ще се показват различни версии на сайта. Това не може да продължава.

Третата — трябва да решим въпроса с деплоя.

Ако имаме монолит и един „класически“ сървър, всичко е много просто: разгръщаме нова кодова база, провеждаме миграция на БД, пренасочваме трафика към новата версия на кода. Пренасочването е мигновено.
Ако сайтът ни е в Kubernetes, разделен на микросервиси, и имаме много контейнери с код — ой. Трябва да съберем контейнерите с новата версия на кода, да ги внедрим вместо старите, да извършим миграция на БД и, в идеалния случай, да направим това незабележимо за посетителите. За щастие, Kubernetes ни помага в това, предоставяйки множество различни видове деплой.

Четвъртата — трябва да решим въпроса с управлението на статичните файлове.

Ако вашият сайт е „само“ 10 гигабайта и го разположите изцяло в контейнери, ще получите контейнери с тегло от 10 гигабайта, които ще се внедряват вечно.
Трябва да съхраняваме най „тежките“ части на сайта извън контейнерите, и възниква въпросът как да го правим правилно.

Какво липсва в нашето решение.

Целият код на Битрикс не е разрязан на микрофункции/микросервиси (така, че регистрацията да е отделно, модулът за онлайн магазин да е отделен и т.н.). Цялата кодова база я съхраняваме в всеки контейнер напълно.

Базата в Kubernetes също не я съхраняваме (осъществявал съм решения с база в Kubernetes за средите на разработчиците, но не и за продукция).

Администраторите на сайта все пак ще забележат, че сайтът работи в Kubernetes. Функцията „проверка на системата“ неработи коректно, за редактиране на кода на сайта от администраторския панел първо трябва да натиснете бутона „искам да редактирам кода“.

Проблемите бяха разрешени, необходимостта от микросервисна архитектура беше установена, целта е ясна — да получим работеща система за работа с приложения на Битрикс в Kubernetes, запазвайки както възможностите на Битрикс, така и предимствата на Kubernetes. Започваме реализацията.

Архитектура

Много 'работни' подове с уебсървър (работници).
Един под с крон-задачи (задължително само един).
Един под за ъпгрейд за редактиране на кода на сайта от админ панела (също задължително само един).

Решаваме въпросите:

• Къде да съхраняваме сесиите?
• Къде да съхраняваме кеша?
• Къде да съхраняваме статиката? Не е удачно да поставяме гигабайти статични файлове в множество контейнери.
• Как ще работи базата данни?

Docker образ

Започваме със създаването на Docker образ.

Идеалният вариант е да имаме един универсален образ, от който получаваме както работни подове, така и подове с крон задачи, както и ъпгрейд подове.

Създадохме точно такъв образ..

В него е включен nginx, apache/php-fpm (може да се избере при изграждането), msmtp за изпращане на имейли и cron.

При изграждане на образа, целият кодов база на сайта се копира в директория /app (с изключение на тези части, които ще изнесем в отделно споделено хранилище).

Микросервисност, услуги

работни подове:

• контейнер с nginx + контейнер apache/php-fpm + msmtp
• Не успяхме да изнесем msmtp в отделен микросервис, Битрикс започва да се оплаква, че не може директно да изпрати имейл.
• Във всеки контейнер е разположена целия кодов база.
• Забрана за изменение на кода в контейнерите.

cron под:

• контейнер с apache, php, cron
• в комплекта е включена целия кодов база
• забрана за изменение на кода в контейнерите

upgrade под:

• контейнер с nginx + контейнер apache/php-fpm + msmtp
• няма забрана за изменение на кода в контейнерите

хранилище на сесиите

хранилище на кеша за Битрикс

Важно е също: паролите за свързване до всичко, от базата данни до имейли, съхраняваме в Kubernetes secrets. Получаваме бонус, паролите са видими само за тези, на които даваме достъп до секретите, а не за всички, които имат достъп до кодовата база на проекта.

Хранилище за статиката

Може да се използва всичко: ceph, nfs (но не препоръчваме nfs за продуктивни среди), мрежово хранилище от 'облачни' доставчици и т.н.

Хранилището трябва да бъде свързано с контейнерите в директория /upload/ на сайта и в други директории със статични файлове.

База данни

За удобство препоръчваме базата да бъде извън Kubernetes. Базата в Kubernetes е отделна сложна задача, тя ще направи схемата много по-сложна.

Хранилище на сесиите

Използваме memcached 🙂

Той се справя добре с съхранението на сесии, клъстеризира се и се поддържа "нативно" като session.save_path в php. Тази система е преминала през много тестове в класическата монолитна архитектура, когато изграждахме клъстери с множество уеб сървъри. За внедряване използваме helm.

$ helm install stable/memcached --name session

php.ini — тук в образа са зададени настройките за съхранение на сесии в memcached

Използвахме Environment Variables за предаване на данни за хостовете с memcached https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/.
Това позволява да използваме един и същ код в средите dev, stage, test, prod (имената на хостовете memcached в тях ще се различават, затова за всяка среда трябва да предаваме уникално име на хостовете за сесиите).
Хранилище за кеш Битрикс

Нуждаем се от устойчива система за съхранение, в която всички подове могат да записват и от която могат да четат.

Също така използваме memcached.
Това решение е препоръчано от самия Битрикс.

$ helm install stable/memcached --name cache

bitrix/.settings_extra.php — тук в Битрикс се задава къде се съхранява кеша

Също така използваме Environment Variables.

Крон задачи

Има различни подходи за изпълнение на крон задачите в Kubernetes.

• отделендеплоймент с под за изпълнение на крон задачите
• cronjob за изпълнение на крон задачите (ако е уеб приложение — с wget https://$host$cronjobname, или kubectl exec вътре в един от worker подовете и т.н.)
• и т.н.

Можем да спорим за най-добрия начин, но в този случай избрахме варианта "отделен деплоймент с подове за крон задачите".

Как е направено:

• крон задачите добавяме чрез ConfigMap или през файла config/addcron
• възлагаме контейнер с един екземпляр, идентичен на worker пода + разрешаваме изпълнението на крон задачите в него
• използва се същата кодова база, благодарение на унификацията, изграждането на контейнера е просто

Какви предимства получаваме:

• имаме работещи крон задачи в среда, идентична на тази на разработчиците (docker)
• крон задачите не трябва да се "преписват" за Kubernetes, те работят по същия начин и със същата кодова база, както преди
• крон задачите могат да добавят всички членове на екипа с права за commit в производствената клонка, а не само администраторите

Модулът Southbridge K8SDeploy и редактиране на кода от админ панела

Ние говорихме за ъпгрейд на пода?
А как да насочим трафика там?
Ура, написахме модул за това на php 🙂 Това е малък класически модул за Битрикс. Още не е достъпен публично, но планираме да го направим.
Модулът се инсталира като обикновен модул в Битрикс:

И изглежда така:

Той позволява да зададете cookie, която идентифицира администратора на сайта и позволява на Kubernetes да насочва трафика към апдейт пода.

Когато промените са завършени, трябва да натиснете git push, промените в кода ще бъдат изпратени в git, след това системата ще създаде образ с новата версия на кода и „разпределя“ нея по клъстера, заменяйки старите подове.

Да, малко неудачно, но така запазваме микросервисната архитектура и не отнемаме на потребителите на Битрикс любимата възможност да поправят кода от админ панела. В крайна сметка, това е опция, задачата за корекция на кода може да бъде решена по различен начин.

Helm чарт

За изграждане на приложения в Kubernetes обикновено използваме пакетния мениджър Helm.
За нашето решение Битрикс в Kubernetes, Сергей Бондарев, нашият водещ системен администратор, е написал специален Helm чарт.

Той извършва изграждането на worker, upgrade, cron подовете, настройва ingress'и, услуги, прехвърля променливи от Kubernetes secrets в подовете.

Кода съхраняваме в Gitlab и също така стартираме изграждането на Helm от Gitlab.

Ако казваме накратко, това изглежда така

$ helm upgrade --install project .helm --set image=registrygitlab.local/k8s/bitrix -f .helm/values.yaml --wait --timeout 300 --debug --tiller-namespace=production

Helm също така позволява да се направи „безшевен“ откат, ако нещо се обърка при разположението. Приятно е, когато не в паника „поправяте кода по ftp, защото прод е паднал“, а Kubernetes го прави автоматично, без време на неработа.

Деплой

Да, ние сме фенове на Gitlab & Gitlab CI, използваме го 🙂
При комит в Gitlab в репозитория на проекта Gitlab стартира пайплайн, който изпълнява разгръщането на новата версия на средата.

Етапи:

• build (изграждаме нов Docker образ)
• test (тестваме)
• clean up (изтриваме тестовата среда)
• push (изпращаме го в Docker registry)
• deploy (разгръщаме приложението в Kubernetes чрез Helm).

Ура, готово, внедряваме!
Или задаваме въпроси, ако имаме.

И така, какво направихме

От техническа гледна точка:

• докеризирахме Битрикс;
• „разрязахме“ Битрикс на контейнери, всеки от които изпълнява минимум функции;
• постигнахме stateless състояние на контейнерите;
• решихме проблема с актуализацията на Битрикс в Kubernetes;
• всички функции на Битрикс продължиха да работят (почти всички);
• изпълнихме деплой в Kubernetes и откат между версиите.

От бизнес гледна точка:

• отказоустойчивост;
• инструменти на Kubernetes (лесна интеграция с Gitlab CI, безшевен деплой, и др.);
• пароли в тайни (видими само за тези, на които е предоставен достъп до паролите);
• удобно да се създават допълнителни среди (за разработка, тестове и др.) в рамките на единна инфраструктура.

Източник: habr.com