В Челябинск се провеждат срещи на системни администратори на Sysadminka и на последната изнесох доклад за нашето решение за стартиране на приложения на 1C-Bitrix в Kubernetes.
Bitrix, Kubernetes, Ceph - страхотна смес?
Ще ви кажа как създадохме работещо решение от всичко това.
Да вървим!
Срещата се състоя на 18 април в Челябинск. Можете да прочетете за нашите срещи на Часовник и погледнете YouTube.
Ако искате да дойдете при нас с доклад или като слушател - заповядайте, пишете на [имейл защитен] и в Telegram t.me/vadimisakanov.
Решение „Bitrix в Kubernetes, версия Southbridge 1.0“
Ще говоря за нашето решение във формата „за манекени в Kubernetes“, както беше направено на срещата. Но предполагам, че знаете думите Bitrix, Docker, Kubernetes, Ceph поне на ниво статии в Wikipedia.
Какво е готово за Bitrix в Kubernetes?
В целия Интернет има много малко информация за работата на приложенията Bitrix в Kubernetes.
Намерих само тези материали:
Доклад на Александър Сербул, 1C-Bitrix и Антон Тузлуков от Qsoft:
Предупреждавам ви, не сме проверили качеството на решенията в горните връзки :)
Между другото, когато подготвях нашето решение, разговарях с Александър Сербул, тогава неговият доклад все още не се появи, така че в моите слайдове има елемент „Bitrix не използва Kubernetes“.
Това достатъчно ли е за създаване на цялостно решение за Bitrix в Kubernetes?
Не. Има голям брой проблеми, които трябва да бъдат решени.
Какви са проблемите с Bitrix в Kubernetes?
Първо, готовите изображения от Dockerhub не са подходящи за Kubernetes
Ако искаме да изградим архитектура на микроуслуги (а в Kubernetes обикновено го правим), трябва да разделим нашето приложение Kubernetes на контейнери и всеки контейнер да изпълнява една малка функция (и да го прави добре). Защо само един? Накратко, колкото по-просто, толкова по-надеждно.
За да бъдете по-конкретни, гледайте тази статия и видеоклип, моля: https://habr.com/ru/company/southbridge/blog/426637/
Изображенията на Docker в Dockerhub са изградени главно на принципа „всичко в едно“, така че все пак трябваше да направим наш собствен велосипед и дори да създаваме изображения от нулата.
Второ - кодът на сайта се редактира от админ панела
Създадохме нова секция в сайта - актуализирахме кода (добавихме директория с името на новата секция).
Ако сте променили свойствата на компонент от административния панел, кодът се е променил.
Kubernetes „по подразбиране“ не може да работи с това; контейнерите трябва да са без състояние.
Причина: Всеки контейнер (pod) в клъстера обработва само част от трафика. Ако промените кода само в един контейнер (pod), тогава кодът ще бъде различен в различните pods, сайтът ще работи по различен начин и различни версии на сайта ще се показват на различни потребители. Не може да се живее така.
Трето - трябва да решите проблема с внедряването
Ако имаме монолит и един „класически“ сървър, всичко е съвсем просто: внедряваме нова кодова база, мигрираме базата данни, превключваме трафика към новата версия на кода. Превключването става моментално.
Ако имаме сайт в Kubernetes, нарязан на микроуслуги, има много контейнери с код - о. Трябва да съберете контейнери с нова версия на кода, да ги разгърнете вместо старите, да мигрирате правилно базата данни и в идеалния случай да направите това незабелязано от посетителите. За щастие, Kubernetes ни помага с това, поддържайки цял куп различни видове внедрявания.
Четвърто - трябва да решите проблема със съхранението на статиката
Ако вашият сайт е „само“ 10 гигабайта и го разположите изцяло в контейнери, ще получите 10 гигабайтови контейнери, чието разгръщане отнема цяла вечност.
Трябва да съхранявате „най-тежките“ части от сайта извън контейнерите и възниква въпросът как да направите това правилно
Какво липсва на нашето решение?
Целият код на Bitrix не е разделен на микрофункции/микроуслуги (така че регистрацията да е отделна, модулът на онлайн магазина да е отделен и т.н.). Ние съхраняваме цялата кодова база във всеки контейнер.
Също така не съхраняваме базата данни в Kubernetes (все още внедрих решения с база данни в Kubernetes за среди за разработка, но не и за производство).
Все още ще бъде забележимо за администраторите на сайта, че сайтът работи на Kubernetes. Функцията „проверка на системата“ не работи правилно; за да редактирате кода на сайта от административния панел, първо трябва да щракнете върху бутона „Искам да редактирам кода“.
Проблемите са идентифицирани, необходимостта от внедряване на микроуслуги е определена, целта е ясна - да получите работеща система за стартиране на приложения на Bitrix в Kubernetes, запазвайки както възможностите на Bitrix, така и предимствата на Kubernetes. Да започнем изпълнението.
архитектура
Има много „работещи“ модули с уеб сървър (работници).
Един под с cron задачи (изисква се само един).
Един ъпгрейд за редактиране на кода на сайта от админ панела (необходим е и само един).
Решаваме въпроси:
Къде да съхранявам сесиите?
Къде да съхранявам кеша?
Къде да съхранявате статика, а не да поставяте гигабайти статика в куп контейнери?
Как ще работи базата данни?
Докер изображение
Започваме с изграждането на Docker изображение.
Идеалният вариант е да имаме един универсален образ, на базата на който получаваме worker pods, pods с Crontask и upgrade pods.
Той включва nginx, apache/php-fpm (може да бъде избран по време на компилация), msmtp за изпращане на поща и cron.
При сглобяването на изображението цялата кодова база на сайта се копира в директорията /app (с изключение на онези части, които ще преместим в отделно споделено хранилище).
Микроуслуги, услуги
работни капсули:
Контейнер с nginx + контейнер apache/php-fpm + msmtp
Не се получи преместването на msmtp в отделна микроуслуга, Bitrix започва да се възмущава, че не може да изпраща поща директно
Друго важно нещо: съхраняваме пароли за свързване с всичко, от базата данни до пощата, в тайните на kubernetes. Получаваме бонус: паролите са видими само за тези, на които даваме достъп до тайните, а не за всички, които имат достъп до кодовата база на проекта.
Склад за статика
Можете да използвате всичко: ceph, nfs (но ние не препоръчваме nfs за производство), мрежово съхранение от доставчици на облак и т.н.
Хранилището ще трябва да бъде свързано в контейнери към директорията /upload/ на сайта и други директории със статично съдържание.
база данни
За по-лесно препоръчваме да преместите базата данни извън Kubernetes. Базата в Kubernetes е отделна сложна задача, тя ще направи схемата с порядък по-сложна.
Съхранение на сесии
Използваме memcached :)
Той се справя добре със съхранението на сесиите, клъстерен е и се поддържа „нативно“ като session.save_path в php. Такава система е тествана многократно в класическата монолитна архитектура, когато изградихме клъстери с голям брой уеб сървъри. За разгръщане използваме кормило.
$ helm install stable/memcached --name session
php.ini - тук изображението съдържа настройки за съхраняване на сесии в memcached
Използвахме променливи на средата, за да предаваме данни за хостове с 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 - тук в Битрикс е посочено къде се съхранява кеша
Ние също използваме променливи на средата.
Кронтаски
Има различни подходи за изпълнение на Crontasks в Kubernetes.
отделно внедряване с под за изпълнение на Crontasks
cronjob за изпълнение на crontasks (ако това е уеб приложение - с wget https://$host$cronjobname, или kubectl exec в една от работните групи и т.н.)
и т.н.
Можете да спорите за най-правилния, но в този случай избрахме опцията „отделно внедряване с подове за Crontasks“
Как се прави:
добавете cron задачи чрез ConfigMap или чрез файла config/addcron
в един случай стартираме контейнер, идентичен на worker pod + позволяваме изпълнението на коронни задачи в него
използва се една и съща кодова база, благодарение на унификацията сглобяването на контейнера е лесно
Какво добро получаваме:
имаме работещи Crontasks в среда, идентична на средата на разработчиците (докер)
Crontasks не се нуждаят от „пренаписване“ за Kubernetes, те работят в същата форма и в същата кодова база, както преди
cron задачите могат да се добавят от всички членове на екипа с права за ангажиране към производствения клон, а не само от администратори
Southbridge K8SDeploy модул и редактиране на код от админ панела
Говорихме за надграждане под?
Как да насоча трафика там?
Ура, написахме модул за това на PHP :) Това е малък класически модул за Bitrix. Все още не е публично достъпен, но планираме да го отворим.
Модулът се инсталира като обикновен модул в Bitrix:
И изглежда така:
Тя ви позволява да зададете бисквитка, която идентифицира администратора на сайта и позволява на Kubernetes да изпраща трафик към модула за надстройка.
Когато промените са завършени, трябва да щракнете върху git push, промените в кода ще бъдат изпратени до git, след което системата ще изгради изображение с нова версия на кода и ще го „разпространи“ в клъстера, заменяйки старите подове .
Да, това е малко патерица, но в същото време поддържаме архитектурата на микросервизите и не отнемаме на потребителите на Bitrix любимата им възможност да коригират кода от администраторския панел. В крайна сметка това е опция; можете да решите проблема с редактирането на кода по различен начин.
Диаграма на кормилото
За да създаваме приложения на Kubernetes, ние обикновено използваме мениджъра на пакети Helm.
За нашето решение Bitrix в Kubernetes, Сергей Бондарев, нашият водещ системен администратор, написа специална Helm диаграма.
Той изгражда worker, надграждане, cron pods, конфигурира ingresses, услуги и прехвърля променливи от Kubernetes тайните към pods.
Ние съхраняваме кода в Gitlab и също така изпълняваме компилацията на Helm от Gitlab.
Helm също ви позволява да направите „безпроблемно“ връщане назад, ако изведнъж нещо се обърка по време на внедряването. Хубаво е, когато не сте в паника „поправете кода чрез ftp, защото prod падна“, но Kubernetes го прави автоматично и без престой.
Разположете
Да, фенове сме на Gitlab & Gitlab CI, използваме ги :)
Когато се ангажира в Gitlab към хранилището на проекта, Gitlab стартира конвейер, който внедрява нова версия на средата.
етапа:
изграждане (изграждане на ново изображение на Docker)
тест (тестване)
почистване (премахване на тестовата среда)
push (изпращаме го в регистъра на Docker)
внедряване (ние внедряваме приложението в Kubernetes чрез Helm).
Ура, готово е, да го реализираме!
Е, или задавайте въпроси, ако има такива.
И така, какво направихме
От техническа гледна точка:
докеризиран Bitrix;
„нарежете“ Bitrix на контейнери, всеки от които изпълнява минимум функции;
постигнато състояние без състояние на контейнерите;
решен проблемът с актуализирането на Bitrix в Kubernetes;
всички функции на Bitrix продължиха да работят (почти всички);
Работихме върху внедряването в Kubernetes и връщането назад между версиите.
От бизнес гледна точка:
отказоустойчивост;
Инструменти на Kubernetes (лесна интеграция с Gitlab CI, безпроблемно внедряване и т.н.);
секретни пароли (видими само за тези, на които е предоставен пряк достъп до паролите);
Удобно е да създавате допълнителни среди (за разработка, тестове и т.н.) в рамките на една инфраструктура.