Southbridge в Челябинск и Битрикс в Kubernetes

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

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

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

Хайде да започваме!

Срещата се проведе на 18 април в Челябинск. За нашите срещи можете да прочетете в Timepad и да се запознаете с ютуба.

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

Моят доклад

Слайдове

Решение „Битрикс в Kubernetes, версия Southbridge 1.0“

Ще разкажа за нашето решение в формат „за начинаещи в Kubernetes“, както беше на срещата. Но предполагам, че думите Битрикс, Docker, Kubernetes, Ceph са ви известни поне на ниво статии в Wikipedia.

Какво всъщност има готово за Битрикс в Kubernetes?

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

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

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

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

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

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

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

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

В какво се състоят проблемите с Битрикс в 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. Започваме реализацията.

Архитектура

Много „работещи“ подове с уебсървър (worker’и).
Един под с cron задачи (задължително само един).
Един upgrade под за редактиране на кода на сайта от админ панела (също задължително само един).

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

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

Docker образ

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

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

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

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

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

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

worker подове:

• Контейнер с 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 ще се различават, ето защо за всяка среда трябва да предаваме уникално име на хостовете за сесии).
Кеш хранилище Bitrix

Нуждаем се от устойчиво хранилище, в което всички подове могат да пишат и да четат.

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

$ helm install stable/memcached --name cache

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

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

Крон задачи

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

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

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

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

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

Какво добро получаваме:

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

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

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

И изглежда по следния начин:

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

Когато промените са завършени, трябва да натиснете 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, защото production е паднал", а Kubernetes го прави автоматично без даунтайм.

Деплой

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

Стъпки:

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

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

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

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

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

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

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

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