В Челябинск се провеждат срещи на системни администратори на Sysadminka и на последната изнесох доклад за нашето решение за стартиране на приложения на 1C-Bitrix в Kubernetes.
Bitrix, Kubernetes, Ceph - страхотна смес?
Ще ви кажа как създадохме работещо решение от всичко това.
Да вървим!
Срещата се състоя на 18 април в Челябинск. Можете да прочетете за нашите срещи на и погледнете .
Ако искате да дойдете при нас с доклад или като слушател - заповядайте, пишете на [имейл защитен] и в Telegram t.me/vadimisakanov.
Моят доклад
Решение „Bitrix в Kubernetes, версия Southbridge 1.0“
Ще говоря за нашето решение във формата „за манекени в Kubernetes“, както беше направено на срещата. Но предполагам, че знаете думите Bitrix, Docker, Kubernetes, Ceph поне на ниво статии в Wikipedia.
Какво е готово за Bitrix в Kubernetes?
В целия Интернет има много малко информация за работата на приложенията Bitrix в Kubernetes.
Намерих само тези материали:
Доклад на Александър Сербул, 1C-Bitrix и Антон Тузлуков от Qsoft:
Препоръчвам да го слушате.
Разработване на собствено решение от потребителя .
Намерих още .
Ааа... всъщност това е всичко.
Предупреждавам ви, не сме проверили качеството на решенията в горните връзки :)
Между другото, когато подготвях нашето решение, разговарях с Александър Сербул, тогава неговият доклад все още не се появи, така че в моите слайдове има елемент „Bitrix не използва Kubernetes“.
Но вече има много готови Docker изображения за стартиране на Bitrix в Docker:
Това достатъчно ли е за създаване на цялостно решение за Bitrix в Kubernetes?
Не. Има голям брой проблеми, които трябва да бъдат решени.
Какви са проблемите с Bitrix в Kubernetes?
Първо, готовите изображения от Dockerhub не са подходящи за Kubernetes
Ако искаме да изградим архитектура на микроуслуги (а в Kubernetes обикновено го правим), трябва да разделим нашето приложение Kubernetes на контейнери и всеки контейнер да изпълнява една малка функция (и да го прави добре). Защо само един? Накратко, колкото по-просто, толкова по-надеждно.
За да бъдете по-конкретни, гледайте тази статия и видеоклип, моля:
Изображенията на 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 започва да се възмущава, че не може да изпраща поща директно
- Всеки контейнер има пълна кодова база.
- Забрана за промяна на кода в контейнери.
cron под:
- контейнер с apache, php, cron
- включена пълна кодова база
- забрана за промяна на кода в контейнери
надграждане под:
- nginx контейнер + apache/php-fpm контейнер + msmtp
- Няма забрана за промяна на кода в контейнерите
съхранение на сесии
Кеш памет на Bitrix
Друго важно нещо: съхраняваме пароли за свързване с всичко, от базата данни до пощата, в тайните на kubernetes. Получаваме бонус: паролите са видими само за тези, на които даваме достъп до тайните, а не за всички, които имат достъп до кодовата база на проекта.
Склад за статика
Можете да използвате всичко: ceph, nfs (но ние не препоръчваме nfs за производство), мрежово съхранение от доставчици на облак и т.н.
Хранилището ще трябва да бъде свързано в контейнери към директорията /upload/ на сайта и други директории със статично съдържание.
база данни
За по-лесно препоръчваме да преместите базата данни извън Kubernetes. Базата в Kubernetes е отделна сложна задача, тя ще направи схемата с порядък по-сложна.
Съхранение на сесии
Използваме memcached :)
Той се справя добре със съхранението на сесиите, клъстерен е и се поддържа „нативно“ като session.save_path в php. Такава система е тествана многократно в класическата монолитна архитектура, когато изградихме клъстери с голям брой уеб сървъри. За разгръщане използваме кормило.
$ helm install stable/memcached --name sessionphp.ini - тук изображението съдържа настройки за съхраняване на сесии в memcached
Използвахме променливи на средата, за да предаваме данни за хостове с memcached .
Това ви позволява да използвате един и същ код в dev, stage, test, prod среди (имената на хостове в memcached в тях ще бъдат различни, така че трябва да предадем уникално име на хост за сесии към всяка среда).
Кеш памет на Bitrix
Имаме нужда от устойчиво на грешки хранилище, в което всички подове могат да пишат и да четат.
Ние също използваме memcached.
Това решение се препоръчва от самия Bitrix.
$ helm install stable/memcached --name cachebitrix/.settings_extra.php - тук в Битрикс е посочено къде се съхранява кеша
Ние също използваме променливи на средата.
Кронтаски
Има различни подходи за изпълнение на Crontasks в Kubernetes.
- отделно внедряване с под за изпълнение на Crontasks
- cronjob за изпълнение на crontasks (ако това е уеб приложение - с wget , или 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 upgrade --install project .helm --set image=registrygitlab.local/k8s/bitrix -f .helm/values.yaml --wait --timeout 300 --debug --tiller-namespace=productionHelm също ви позволява да направите „безпроблемно“ връщане назад, ако изведнъж нещо се обърка по време на внедряването. Хубаво е, когато не сте в паника „поправете кода чрез ftp, защото prod падна“, но Kubernetes го прави автоматично и без престой.
Разположете
Да, фенове сме на Gitlab & Gitlab CI, използваме ги :)
Когато се ангажира в Gitlab към хранилището на проекта, Gitlab стартира конвейер, който внедрява нова версия на средата.
етапа:
- изграждане (изграждане на ново изображение на Docker)
- тест (тестване)
- почистване (премахване на тестовата среда)
- push (изпращаме го в регистъра на Docker)
- внедряване (ние внедряваме приложението в Kubernetes чрез Helm).
Ура, готово е, да го реализираме!
Е, или задавайте въпроси, ако има такива.
И така, какво направихме
От техническа гледна точка:
- докеризиран Bitrix;
- „нарежете“ Bitrix на контейнери, всеки от които изпълнява минимум функции;
- постигнато състояние без състояние на контейнерите;
- решен проблемът с актуализирането на Bitrix в Kubernetes;
- всички функции на Bitrix продължиха да работят (почти всички);
- Работихме върху внедряването в Kubernetes и връщането назад между версиите.
От бизнес гледна точка:
- отказоустойчивост;
- Инструменти на Kubernetes (лесна интеграция с Gitlab CI, безпроблемно внедряване и т.н.);
- секретни пароли (видими само за тези, на които е предоставен пряк достъп до паролите);
- Удобно е да създавате допълнителни среди (за разработка, тестове и т.н.) в рамките на една инфраструктура.
Източник: www.habr.com