Во Чељабинск се одржуваат состаноци со системскиот администратор на Sysadminka, а на последниот дадов извештај за нашето решение за извршување на апликации на 1C-Bitrix во Кубернетес.
Bitrix, Kubernetes, Ceph - одлична мешавина?
Ќе ви кажам како составивме работно решение од сето ова.
Ајде да одиме!
Средбата се одржа на 18 април во Челјабинск. Можете да прочитате за нашите состаноци на и погледнете .
Ако сакате да дојдете кај нас со репортажа или како слушател - добредојде, пишете [заштитена по е-пошта] и на Телеграма t.me/vadimisakanov.
Мојот извештај
Решение „Битрикс во Кубернетес, верзија Саутбриџ 1.0“
Ќе зборувам за нашето решение во форматот „за кукли во Кубернетес“, како што беше направено на состанокот. Но, претпоставувам дека ги знаете зборовите Bitrix, Docker, Kubernetes, Ceph барем на ниво на статии на Википедија.
Што е подготвено за Bitrix во Kubernetes?
Има многу малку информации на целиот Интернет за работата на апликациите Bitrix во Kubernetes.
Ги најдов само овие материјали:
Извештај на Александар Сербул, 1C-Bitrix и Антон Тузлуков од Qsoft:
Препорачувам да го слушате.
Развивање на сопствено решение од корисникот .
Најде повеќе .
Aaand... всушност, тоа е сè.
Ве предупредувам, не го проверивме квалитетот на решенијата на линковите погоре :)
Патем, кога го подготвував нашето решение, разговарав со Александар Сербул, тогаш неговиот извештај сè уште не се појави, така што во моите слајдови има ставка „Битрикс не користи Кубернетес“.
Но, веќе има многу готови Docker слики за извршување на Bitrix во Docker:
Дали е ова доволно за да се создаде целосно решение за Bitrix во Kubernetes?
бр. Има голем број проблеми кои треба да се решат.
Кои се проблемите со Bitrix во Kubernetes?
Прво, готови слики од Dockerhub не се погодни за Kubernetes
Ако сакаме да изградиме микросервисна архитектура (а во Kubernetes тоа обично го правиме), треба да ја одвоиме нашата Kubernetes апликација во контејнери и секој контејнер да изврши една мала функција (и да го направи тоа добро). Зошто само еден? Накратко, колку е поедноставно толку посигурно.
За да бидете поконкретни, погледнете ја оваа статија и видео, ве молиме:
Сликите на Docker во Dockerhub главно се изградени на принципот сè-во-едно, па сепак моравме да направиме сопствен велосипед, па дури и да создаваме слики од нула.
Второ - кодот на страницата се уредува од административниот панел
Создадовме нов дел на страницата - кодот беше ажуриран (додаден е директориум со името на новиот дел).
Ако сте ги промениле својствата на компонентата од административниот панел, кодот се сменил.
Kubernetes „по дифолт“ не може да работи со ова; контејнерите мора да бидат без државјанство.
Причина: Секој контејнер (под) во кластерот обработува само дел од сообраќајот. Ако го промените кодот само во еден контејнер (под), тогаш кодот ќе биде различен во различни подлоги, страницата ќе работи поинаку и различни верзии на страницата ќе се прикажуваат на различни корисници. Не можеш да живееш така.
Трето - треба да го решите проблемот со распоредувањето
Ако имаме монолит и еден „класичен“ сервер, сè е прилично едноставно: распоредуваме нова база на кодови, мигрираме база на податоци, го префрламе сообраќајот на новата верзија на кодот. Префрлувањето се случува веднаш.
Ако имаме локација во Кубернетес, исечена на микросервиси, има многу контејнери со код - ох. Треба да соберете контејнери со нова верзија на кодот, да ги поставите наместо старите, правилно да ја мигрирате базата на податоци и идеално да го направите ова незабележано од посетителите. За среќа, Kubernetes ни помага во ова, поддржувајќи цел куп различни видови распоредувања.
Четврто - треба да го решите прашањето за складирање на статика
Ако вашата страница е „само“ 10 гигабајти и ја распоредите целосно во контејнери, ќе завршите со контејнери од 10 гигабајти на кои им треба вечно распоредување.
Треба да ги чувате „најтешките“ делови од страницата надвор од контејнерите и се поставува прашањето како да го направите тоа правилно
Што недостасува од нашето решение?
Целиот код на Bitrix не е поделен на микрофункции/микроуслуги (така што регистрацијата е посебна, модулот на онлајн продавницата е одделен итн.). Ја складираме целата база на кодови во секој контејнер.
Ние, исто така, не ја складираме базата на податоци во Kubernetes (сè уште имплементирав решенија со база на податоци во Kubernetes за развојни средини, но не и за производство).
Сè уште ќе биде забележливо за администраторите на страницата дека страницата работи на Kubernetes. Функцијата „проверка на системот“ не работи правилно; за да го уредите кодот на страницата од административниот панел, прво мора да кликнете на копчето „Сакам да го уредам кодот“.
Идентификувани се проблемите, утврдена е потребата од имплементација на микроуслуги, целта е јасна - да се добие работен систем за извршување на апликации на Bitrix во Kubernetes, зачувувајќи ги и можностите на Bitrix и предностите на Kubernetes. Да започнеме со имплементација.
архитектура
Има многу „работни“ подлоги со веб-сервер (работници).
Еден под со cron задачи (потребна е само една).
Една надградба за уредување на кодот на страницата од административниот панел (исто така потребна е само една).
Ги решаваме прашањата:
- Каде да се складираат сесиите?
- Каде да се складира кешот?
- Каде да се складира статиката, а не да се ставаат гигабајти статика во куп контејнери?
- Како ќе работи базата на податоци?
Докер слика
Започнуваме со изградба на слика на Docker.
Идеалната опција е да имаме една универзална слика, врз основа на неа добиваме работни места, мешунки со Crontasks и подградби.
.
Вклучува nginx, apache/php-fpm (може да се избере за време на изградбата), msmtp за испраќање пошта и cron.
При составување на сликата, целата база на кодови на страницата се копира во директориумот /app (со исклучок на оние делови што ќе ги преместиме во посебна заедничка меморија).
Микроуслуги, услуги
работнички мешунки:
- Контејнер со nginx + контејнер apache/php-fpm + msmtp
- Не успеа да го премести msmtp во посебен микросервис, Bitrix почнува да се огорчува што не може директно да испраќа пошта
- Секој контејнер има целосна база на кодови.
- Забрана за менување код во контејнери.
cron под:
- контејнер со apache, php, cron
- вклучена е целосна база на кодови
- забрана за промена на код во контејнери
надградба под:
- nginx контејнер + контејнер apache/php-fpm + msmtp
- Нема забрана за менување на кодот во контејнерите
складирање на сесии
Складирање на битрикс кеш
Друга важна работа: ние складираме лозинки за поврзување со сè, од базата на податоци до пошта, во тајните на kubernetes. Добиваме бонус: лозинките се видливи само за оние на кои им даваме пристап до тајните, а не за секој што има пристап до базата на кодови на проектот.
Складирање за статика
Можете да користите сè: ceph, nfs (но не препорачуваме nfs за производство), мрежно складирање од даватели на облак, итн.
Складирањето ќе треба да се поврзе во контејнери со директориумот /upload/ на страницата и другите директориуми со статична содржина.
База на податоци
За едноставност, препорачуваме да ја преместите базата на податоци надвор од Kubernetes. Основата во Кубернетес е посебна сложена задача; таа ќе ја направи шемата по ред на големина посложена.
Складирање на сесии
Ние користиме мемкеш :)
Добро се справува со складирањето на сесиите, е кластерирано и е поддржано „народено“ како session.save_path во php. Ваков систем е многупати тестиран во класичната монолитна архитектура, кога изградивме кластери со голем број веб-сервери. За распоредување користиме кормило.
$ helm install stable/memcached --name sessionphp.ini - овде сликата содржи поставки за складирање сесии во мемкеширана
Ги користевме променливите на животната средина за да пренесуваме податоци за хостовите со мемкеширана .
Ова ви овозможува да го користите истиот код во околините на dev, фаза, тест, прод (имињата на мемкешираните домаќини во нив ќе бидат различни, затоа треба да пренесеме единствено име на домаќин за сесии на секоја средина).
Складирање на битрикс кеш
Потребно ни е складирање толерантно на грешки во кое сите подлоги можат да пишуваат и да читаат.
Ние исто така користиме мемкеш.
Ова решение го препорачува самиот Битрикс.
$ helm install stable/memcached --name cachebitrix/.settings_extra.php - овде во Bitrix е наведено каде се чува кешот
Ние исто така користиме променливи на животната средина.
Кронтаски
Постојат различни пристапи за водење на Crontasks во Kubernetes.
- посебно распоредување со подлога за водење на Crontasks
- cronjob за извршување crontasks (ако ова е веб-апликација - со wget , или kubectl exec во еден од работните подлоги, итн.)
- итн
Може да се расправате за најточниот, но во овој случај ја избравме опцијата „посебно распоредување со подлоги за Crontasks“
Како се прави:
- додадете cron задачи преку ConfigMap или преку датотеката config/addcron
- во еден пример лансираме контејнер идентичен на работниот под + дозволуваме извршување на задачите на круната во него
- се користи истата база на кодови, благодарение на обединувањето, склопувањето на контејнерот е едноставно
Колку добро добиваме:
- имаме работни Crontasks во средина идентична со околината на програмерите (docker)
- Crontasks не треба да се „препишуваат“ за Kubernetes, тие работат во иста форма и во истата база на кодови како порано
- cron задачите може да ги додадат сите членови на тимот со права за обврзување во производствената гранка, а не само администраторите
Southbridge K8SDeploy модул и уредување код од административниот панел
Зборувавме за надградба под?
Како да се насочи сообраќајот таму?
Ура, напишавме модул за ова во PHP :) Ова е мал класичен модул за Bitrix. Сè уште не е јавно достапен, но планираме да го отвориме.
Модулот е инсталиран како обичен модул во Bitrix:
И изгледа вака:
Ви овозможува да поставите колаче што го идентификува администраторот на страницата и му дозволува на Кубернетес да испраќа сообраќај до подлогата за надградба.
Кога промените ќе бидат завршени, треба да кликнете на git push, промените на кодот ќе бидат испратени до git, а потоа системот ќе изгради слика со нова верзија на кодот и ќе ја „префрли“ низ кластерот, заменувајќи ги старите парчиња .
Да, тоа е малку патерица, но во исто време ја одржуваме архитектурата на микросервис и не им ја одземаме на корисниците на Bitrix нивната омилена можност да го поправат кодот од административниот панел. На крајот, ова е опција, можете да го решите проблемот со уредување на кодот на поинаков начин.
Табела на кормилото
За да изградиме апликации на Kubernetes, ние обично го користиме менаџерот на пакети Helm.
За нашето решение Bitrix во Кубернетес, Сергеј Бондарев, нашиот водечки системски администратор, напиша специјална табела Helm.
Создава работник, ugrade, cron pods, конфигурира влезови, услуги и пренесува променливи од тајните на 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 затоа што продот падна“, но Kubernetes го прави тоа автоматски и без прекини.
Распоредување
Да, ние сме обожаватели на Gitlab & Gitlab CI, го користиме :)
Кога се обврзува во Gitlab за складиштето на проектот, Gitlab лансира гасовод што распоредува нова верзија на околината.
Фази:
- build (градење нова слика на Docker)
- тест (тестирање)
- чистење (отстранување на околината за тестирање)
- притисни (го испраќаме во регистарот на Docker)
- распореди (ја распоредуваме апликацијата на Кубернетс преку Helm).
Ура, готов е, ајде да го спроведеме!
Па, или поставувајте прашања ако ги има.
Па што направивме
Од техничка гледна точка:
- приклучен Bitrix;
- „Исечете го“ Bitrix во контејнери, од кои секоја извршува минимум функции;
- постигната состојба на контејнери без државјанство;
- го реши проблемот со ажурирање на Bitrix во Kubernetes;
- сите функции на Bitrix продолжија да работат (скоро сите);
- Работевме на распоредување во Kubernetes и враќање помеѓу верзиите.
Од деловна гледна точка:
- толеранција на грешки;
- Kubernetes алатки (лесна интеграција со Gitlab CI, непречено распоредување итн.);
- тајни лозинки (видливи само за оние на кои директно им е дозволен пристап до лозинките);
- Удобно е да се создадат дополнителни средини (за развој, тестови, итн.) во рамките на една инфраструктура.
Извор: www.habr.com