Челябинск шаарында Sysadminka тутумунун администраторлорунун жолугушуулары өтүп жатат, акыркысында мен Кубернетестеги 1C-Bitrixте тиркемелерди иштетүү боюнча чечимибиз жөнүндө отчет бердим.
Bitrix, Kubernetes, Ceph - сонун аралашмасы?
Мен мунун баарын кантип чогуу чечкенибизди айтып берем.
Кеттик!
Жолугушуу 18-апрелде Челябинск шаарында өттү. Биздин жолугушуулар тууралуу бул жерден окуй аласыз жана карап .
Бизге репортаж менен же угарман катары келүүнү кааласаңыз - кош келиңиз, жазыңыз [электрондук почта корголгон] жана Telegram t.me/vadimisakanov.
Менин баяндамам
Чечим "Kubernetesтеги Bitrix, Southbridge 1.0 версиясы"
Мен жолугушууда айтылгандай, "Кубернетестеги муляждар үчүн" форматында биздин чечимибиз жөнүндө сүйлөшөм. Бирок сиз Bitrix, Docker, Kubernetes, Ceph деген сөздөрдү жок дегенде Википедиядагы макалалардын деңгээлинде билесиз деп ойлойм.
Kubernetesтеги Bitrix жөнүндө эмне даяр?
Кубернетестеги Bitrix тиркемелеринин иштеши жөнүндө бүткүл Интернетте өтө аз маалымат бар.
Мен бул материалдарды гана таптым:
Александр Сербулдун, 1C-Bitrix жана Антон Тузлуковдун Qsoftдон репортажы:
Мен аны угууну сунуштайм.
Колдонуучудан өзүңүздүн чечимиңизди иштеп чыгуу .
Көбүрөөк табылган .
Aaand... чындыгында, баары ушунда.
Мен сизге эскертем, биз жогорудагы шилтемелердеги чечимдердин сапатын текшерген жокпуз :)
Баса, биздин чечимди даярдап жатканда, мен Александр Сербул менен сүйлөштүм, анда анын баяндамасы чыга элек болчу, ошондуктан менин слайддарымда "Bitrix Kubernetes колдонбойт" деген пункт бар.
Бирок Dockerде Bitrixти иштетүү үчүн көптөгөн даяр Docker сүрөттөрү бар:
Бул Kubernetesте Bitrix үчүн толук чечимди түзүү үчүн жетиштүүбү?
Жок. Чечүүнү талап кылган көп сандагы көйгөйлөр бар.
Kubernetesтеги Bitrix менен кандай көйгөйлөр бар?
Биринчиден, Dockerhub'тан даяр сүрөттөр Kubernetes үчүн ылайыктуу эмес
Эгерде биз микросервис архитектурасын кургубуз келсе (жана Кубернеттерде биз адатта жасайбыз), биз Кубернетес тиркемесин контейнерлерге бөлүп, ар бир контейнер бир кичинекей функцияны аткарышыбыз керек (жана муну жакшы аткарышыбыз керек). Эмне үчүн бир гана? Кыскасы, канчалык жөнөкөй болсо, ошончолук ишенимдүү.
Тактоо үчүн, бул макаланы жана видеону көрүңүз:
Dockerhub'тагы Docker сүрөттөрү негизинен бардыгы бир жерде принцибинде курулган, ошондуктан биз дагы эле өзүбүздүн велосипедибизди жасап, ал тургай нөлдөн баштап сүрөттөрдү жаратууга туура келди.
Экинчиден - сайттын коду администратор панелинен түзөтүлөт
Биз сайтта жаңы бөлүм түздүк - код жаңыланды (жаңы бөлүмдүн аталышы менен каталог кошулду).
Эгер сиз администратор панелинен компоненттин касиеттерин өзгөрткөн болсоңуз, код өзгөрдү.
Kubernetes "демейки боюнча" муну менен иштей албайт; контейнерлер жарандыгы жок болушу керек.
Себеп: Кластердеги ар бир контейнер (под) трафиктин бир бөлүгүн гана иштетет. Эгер сиз кодду бир гана контейнерде (под) өзгөртсөңүз, анда код ар башка подколордо башкача болот, сайт башкача иштейт жана сайттын ар кандай версиялары ар кандай колдонуучуларга көрсөтүлөт. Сен минтип жашай албайсың.
Үчүнчүдөн - сиз жайылтуу менен маселени чечүү керек
Эгерде бизде монолит жана бир "классикалык" сервер болсо, анда бардыгы жөнөкөй: биз жаңы коддук базаны жайгаштырабыз, маалымат базасын көчүрөбүз, трафикти коддун жаңы версиясына алмаштырабыз. Которуу заматта ишке ашат.
Эгерде бизде Kubernetes сайтында микросервистерге кесилген болсо, анда коду бар контейнерлер көп - оо. Коддун жаңы версиясы бар контейнерлерди чогултуп, аларды эскилеринин ордуна жайып, маалымат базасын туура көчүрүп, эң жакшысы муну коноктор байкабай жасашыңыз керек. Бактыга жараша, Kubernetes бизге бул жагынан жардам берип, ар кандай жайгаштыруулардын бир тобун колдойт.
Төртүнчүдөн - статиканы сактоо маселесин чечүү керек
Эгер сиздин сайтыңыз "болгону" 10 гигабайт болсо жана сиз аны толугу менен контейнерлерде жайгаштырсаңыз, анда сизде 10 гигабайттык контейнерлер пайда болот, алар түбөлүккө жайылтылат.
Сайттын "эң оор" бөлүктөрүн контейнерлердин сыртында сакташыңыз керек жана муну кантип туура кылуу керек деген суроо туулат.
Биздин чечимибизде эмне жетишпейт?
Bitrix коду бүтүндөй микрофункцияларга/микросервистерге бөлүнбөйт (каттоо өзүнчө, онлайн дүкөндүн модулу өзүнчө ж.б.). Биз ар бир контейнерде бардык код базасын сактайбыз.
Биз ошондой эле маалымат базасын Kubernetesте сактабайбыз (мен дагы эле иштеп чыгуу чөйрөлөрү үчүн Kubernetes маалымат базасы менен чечимдерди ишке ашырдым, бирок өндүрүш үчүн эмес).
Сайттын администраторлоруна бул сайт Kubernetesте иштегени дагы деле байкалат. "Системаны текшерүү" функциясы туура иштебей жатат, администратор панелинен сайттын кодун түзөтүү үчүн, адегенде "Мен кодду түзөткүм келет" баскычын басышыңыз керек.
Көйгөйлөр аныкталды, микросервистерди ишке ашыруу зарылчылыгы аныкталды, максат айкын – Bitrixтин мүмкүнчүлүктөрүн да, Kubernetesтин артыкчылыктарын да сактап, Bitrixтин Кубернетесинде тиркемелерди иштетүү үчүн жумушчу системаны алуу. Ишке ашырууну баштайлы.
архитектура
Веб-сервери (жумушчулар) менен көптөгөн "иштеп жаткан" подколор бар.
Биринин астында 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
- Контейнерлердеги кодду өзгөртүүгө тыюу салынган эмес
сеанс сактагыч
Bitrix кэш сактагычы
Дагы бир маанилүү нерсе: биз бардык нерсеге туташуу үчүн сырсөздөрдү, маалымат базасынан почтага чейин, kubernetes сырларында сактайбыз. Биз бонус алабыз: сырсөздөр биз сырларга кирүү мүмкүнчүлүгүн бергендерге гана көрүнөт, ал эми долбоордун код базасына кирүү мүмкүнчүлүгү барлардын бардыгына эмес.
Статика үчүн сактагыч
Сиз каалаган нерсени колдоно аласыз: ceph, nfs (бирок биз өндүрүш үчүн nfs сунуш кылбайбыз), булут провайдерлеринин тармактык сактагычы ж.б.
Сактагычты контейнерлерде сайттын /жүктөө/ каталогуна жана статикалык мазмуну бар башка каталогдорго туташтыруу керек болот.
Маалымат базасы
Жөнөкөйлүк үчүн маалымат базасын Kubernetes'тен тышкары жылдырууну сунуштайбыз. Кубернетедеги база өзүнчө татаал тапшырма болуп саналат; ал схеманы чоңдуктун тартибин татаалыраак кылат.
Сеанс сактагыч
Биз memcached колдонобуз :)
Ал сеанс сактагычты жакшы иштетет, кластерленген жана phpде session.save_path катары "түпкүлүгүндө" колдоого алынат. Мындай система классикалык монолиттик архитектурада көп жолу сыналган, биз көп сандагы веб-серверлери бар кластерлерди курган кезде. Жайгаштыруу үчүн биз рулду колдонобуз.
$ helm install stable/memcached --name sessionphp.ini - бул жерде сүрөт memcached сеанстарды сактоо үчүн орнотууларды камтыйт
Биз memcached менен хосттор жөнүндө маалыматтарды өткөрүү үчүн Environment Variables колдондук .
Бул бир эле кодду иштеп чыгуучу, этап, тест, прод чөйрөлөрүндө колдонууга мүмкүндүк берет (алардын мемкэштелген хост аттары ар кандай болот, ошондуктан биз ар бир чөйрөгө сессиялар үчүн уникалдуу хост атын өткөрүп беришибиз керек).
Bitrix кэш сактагычы
Бизге каталарга чыдамдуу сактагыч керек, аны баардык поддондор жазып жана андан окуй алат.
Биз ошондой эле memcached колдонобуз.
Бул чечим Bitrix өзү тарабынан сунушталат.
$ helm install stable/memcached --name cachebitrix/.settings_extra.php - бул жерде Bitrixте кэш кайда сакталаары көрсөтүлгөн
Биз ошондой эле Environment Variables колдонобуз.
Кронтаски
Kubernetesте Crontasks иштетүүгө ар кандай ыкмалар бар.
- Crontasks иштетүү үчүн подъезд менен өзүнчө жайгаштыруу
- cronjob cronjob (эгерде бул веб колдонмо болсо - wget менен , же жумушчу поддондорунун биринин ичиндеги kubectl exec ж.б.)
- жана башкалар
Сиз эң туурасы жөнүндө талаша аласыз, бирок бул учурда биз "Crontasks үчүн подколор менен өзүнчө жайгаштыруу" опциясын тандадык.
Кантип аткарылган эмес:
- ConfigMap аркылуу же config/addcron файлы аркылуу cron тапшырмаларын кошуңуз
- бир учурда биз жумушчу поддонуна окшош контейнерди ишке киргизебиз + андагы таажы тапшырмаларын аткарууга уруксат беребиз
- ошол эле код базасы колдонулат, бириктирүү аркасында контейнерди чогултуу жөнөкөй
Биз кандай жакшылыкка ээ болобуз:
- бизде Crontasks иштеп чыгуучулардын чөйрөсүнө окшош чөйрөдө иштейт (докер)
- Crontaskтарды Kubernetes үчүн "кайра жазуунун" кереги жок, алар мурункудай эле формада жана ошол эле код базасында иштешет.
- cron тапшырмаларын администраторлор эле эмес, өндүрүш тармагына укук алган бардык команда мүчөлөрү кошо алышат
Southbridge K8SDeploy модулу жана администратор панелинен кодду түзөтүү
Биз жаңыртуу жөнүндө сүйлөшүп жатканбыз?
Ал жакка трафикти кантип багыттоо керек?
Уррай, биз бул үчүн PHPде модул жазганбыз :) Бул Bitrix үчүн кичинекей классикалык модул. Ал азырынча жалпыга жеткиликтүү эмес, бирок биз аны ачууну пландап жатабыз.
Модуль Bitrixтин кадимки модулу сыяктуу орнотулган:
Жана мындай көрүнөт:
Бул сайттын администраторун аныктаган cookie файлын коюуга мүмкүндүк берет жана Kubernetes'ке жаңыртуу подъездине трафик жөнөтүүгө мүмкүндүк берет.
Өзгөртүүлөр аяктагандан кийин, сиз git push баскычын басышыңыз керек, коддун өзгөртүүлөрү gitке жөнөтүлөт, андан кийин система коддун жаңы версиясы менен сүрөттү куруп, аны кластер боюнча эски подкасттарды алмаштырып, "жайгарат". .
Ооба, бул бир аз кыйынчылык, бирок ошол эле учурда биз микросервис архитектурасын сактайбыз жана Bitrix колдонуучуларын администратор панелинен кодду оңдоо үчүн сүйүктүү мүмкүнчүлүгүнөн ажыратпайбыз. Акыр-аягы, бул вариант, сиз кодду оңдоо маселесин башка жол менен чече аласыз.
Руль диаграммасы
Kubernetes'те тиркемелерди куруу үчүн биз адатта Helm пакет менеджерин колдонобуз.
Кубернетестеги Bitrix чечимибиз үчүн биздин алдыңкы система администраторубуз Сергей Бондарев атайын Helm диаграммасын жазган.
Ал жумушчуларды курат, жаңыртат, крон поддондорун түзөт, кирүүлөрдү, кызматтарды конфигурациялайт, өзгөрмөлөрдү Kubernetes сырларынан подддорго өткөрөт.
Биз кодду Gitlab'та сактайбыз, ошондой эле Gitlabдан Helm түзүмүн иштетебиз.
Кыскасы, мындай көрүнөт
$ 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 айлана-чөйрөнүн жаңы версиясын жайылткан куурду ишке киргизет.
этаптары:
- куруу (жаңы Docker сүрөтүн куруу)
- тест (сыноо)
- тазалоо (сыноо чөйрөсүн алып салуу)
- түртүү (биз аны Docker реестрине жөнөтөбүз)
- жайгаштыруу (колдонмону Helm аркылуу Kubernetesке жайгаштырабыз).
Ура, даяр, ишке ашыралы!
Мейли, же бар болсо суроолорду бер.
Ошентип, биз эмне кылдык
Техникалык көз караштан алганда:
- докерлештирилген Bitrix;
- Bitrixти ар бири минималдуу функцияларды аткарган контейнерлерге "кесүү";
- контейнерлердин жарандыгы жок абалына жетишилген;
- Kubernetesте Bitrixти жаңыртуу менен көйгөй чечилди;
- бардык Bitrix функциялары иштей берген (дээрлик бардыгы);
- Биз Kubernetes'ке жайгаштыруу жана версиялардын ортосунда артка кайтаруу боюнча иштедик.
Бизнес көз карашынан алганда:
- катага сабырдуулук;
- Kubernetes куралдары (Gitlab CI менен оңой интеграция, үзгүлтүксүз жайылтуу ж.б.);
- жашыруун сырсөздөр (паролдорго түздөн-түз кирүү мүмкүнчүлүгү бар адамдарга гана көрүнүп турат);
- Бир инфраструктуранын ичинде кошумча чөйрөлөрдү (иштеп чыгуу, сыноо, ж.б. үчүн) түзүү ыңгайлуу.
Source: www.habr.com