Челябинскіде жүйе әкімшілерінің Sysadminka кездесулері өтуде және олардың соңында мен Кубернетестегі 1C-Bitrix-те қолданбаларды іске қосуға арналған шешіміміз туралы есеп бердім.
Bitrix, Kubernetes, Ceph - тамаша қоспасы?
Мұның бәрінен жұмыс шешімін қалай біріктіретінімізді айтып беремін.
Барайық!
Кездесу 18 сәуірде Челябіде өтті. Біздің кездесулер туралы мына жерден оқи аласыз және қараңыз .
Бізге есеппен немесе тыңдарман ретінде келгіңіз келсе - қош келдіңіз, жазыңыз [электрондық пошта қорғалған] және Telegram t.me/vadimisakanov.
Менің есебім
Шешім «Kubernetes ішіндегі Bitrix, Southbridge 1.0 нұсқасы»
Мен кездесуде айтылғандай, «Кубернетестегі муляждар үшін» форматында шешіміміз туралы айтатын боламын. Бірақ сіз Bitrix, Docker, Kubernetes, Ceph сөздерін кем дегенде Википедиядағы мақалалар деңгейінде білесіз деп ойлаймын.
Кубернетестегі Bitrix туралы не дайын?
Kubernetes-тегі Bitrix қолданбаларының жұмысы туралы бүкіл Интернетте өте аз ақпарат бар.
Мен тек мына материалдарды таптым:
Qsoft-тен Александр Сербул, 1C-Bitrix және Антон Тузлуковтың баяндамасы:
Мен оны тыңдауды ұсынамын.
Пайдаланушыдан өз шешіміңізді әзірлеу .
Көбірек табылды .
Ааа... шын мәнінде, бәрі осы.
Сізге ескертемін, біз жоғарыдағы сілтемелердегі шешімдердің сапасын тексерген жоқпыз :)
Айтпақшы, шешімімізді дайындаған кезде мен Александр Сербулмен сөйлестім, содан кейін оның есебі әлі пайда болған жоқ, сондықтан менің слайдтарымда «Bitrix Кубернеттерді пайдаланбайды» деген тармақ бар.
Бірақ Docker-те Bitrix-ті іске қосу үшін көптеген дайын Docker кескіндері бар:
Бұл Kubernetes ішіндегі Bitrix үшін толық шешім жасау үшін жеткілікті ме?
Жоқ. Шешімін қажет ететін мәселелер көп.
Kubernetes-тегі Bitrix-те қандай мәселелер бар?
Біріншіден, Dockerhub-тен дайын кескіндер Kubernetes үшін жарамсыз
Егер біз микросервис архитектурасын құрғымыз келсе (және Кубернеттерде біз әдетте жасаймыз), бізге Kubernetes қолданбасын контейнерлерге бөліп, әрбір контейнер бір шағын функцияны орындауы керек (және оны жақсы орындаңыз). Неге бір ғана? Қысқасы, неғұрлым қарапайым болса, соғұрлым сенімді.
Нақтырақ болу үшін осы мақаланы және бейнені қараңыз:
Dockerhub-тағы Docker кескіндері негізінен барлығы бір-бір принципіне негізделген, сондықтан біз әлі де өз велосипедімізді жасауға және тіпті нөлден бастап кескіндерді жасауға тура келді.
Екінші – сайт коды әкімші панелінен өңделеді
Біз сайтта жаңа бөлім жасадық - код жаңартылды (жаңа бөлімнің атауы бар каталог қосылды).
Егер сіз басқару тақтасынан құрамдастың сипаттарын өзгертсеңіз, код өзгерді.
Kubernetes «әдепкі бойынша» мұнымен жұмыс істей алмайды; контейнерлер азаматтығы жоқ болуы керек.
Себеп: кластердегі әрбір контейнер (под) трафиктің бір бөлігін ғана өңдейді. Егер кодты тек бір контейнерде (под) өзгертсеңіз, онда код әртүрлі подкасттарда әртүрлі болады, сайт басқаша жұмыс істейді және сайттың әртүрлі нұсқалары әртүрлі пайдаланушыларға көрсетіледі. Сіз бұлай өмір сүре алмайсыз.
Үшіншіден - орналастыру арқылы мәселені шешу керек
Егер бізде монолитті және бір «классикалық» сервер болса, бәрі өте қарапайым: біз жаңа кодтық базаны орналастырамыз, дерекқорды тасымалдаймыз, трафикті кодтың жаңа нұсқасына ауыстырамыз. Ауыстыру бірден орын алады.
Егер бізде Kubernetes-те микросервистерге бөлінген сайт болса, онда коды бар көптеген контейнерлер бар - oh. Кодтың жаңа нұсқасы бар контейнерлерді жинап, оларды ескілерінің орнына шығару керек, дерекқорды дұрыс көшіру керек және мұны келушілер байқамай орындау керек. Бақытымызға орай, Kubernetes бізге әртүрлі орналастыру түрлерін қолдай отырып, көмектеседі.
Төртінші – статиканы сақтау мәселесін шешу керек
Егер сіздің сайтыңыз «бар болғаны» 10 гигабайт болса және оны толығымен контейнерлерде орналастырсаңыз, сізде 10 гигабайттық контейнерлер болады, оларды орналастыру үшін мәңгі қажет.
Сіз сайттың «ең ауыр» бөліктерін контейнерлерден тыс сақтауыңыз керек және мұны қалай дұрыс жасау керек деген сұрақ туындайды.
Біздің шешімімізде не жетіспейді?
Бүкіл Bitrix коды микрофункцияларға/микросервистерге бөлінбейді (тіркеу бөлек, интернет-дүкен модулі бөлек және т.б.). Біз әр контейнерде барлық код базасын сақтаймыз.
Сондай-ақ біз дерекқорды Kubernetes-те сақтамаймыз (мен әлі де әзірлеу орталары үшін Kubernetes-те дерекқормен шешімдерді енгіздім, бірақ өндіріс үшін емес).
Сайт әкімшілеріне бұл сайттың Kubernetes жүйесінде жұмыс істейтіні әлі де байқалады. «Жүйені тексеру» функциясы дұрыс жұмыс істемейді, әкімші панелінен сайт кодын өңдеу үшін алдымен «Мен кодты өңдегім келеді» түймесін басу керек.
Мәселелер анықталды, микросервистерді енгізу қажеттілігі анықталды, мақсат айқын – Bitrix мүмкіндіктерін де, Kubernetes артықшылықтарын да сақтай отырып, 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-те кэш қай жерде сақталатыны көрсетілген.
Біз сондай-ақ ортаның айнымалы мәндерін пайдаланамыз.
Кронтаски
Kubernetes жүйесінде Crontasks іске қосудың әртүрлі тәсілдері бар.
- Crontasks іске қосу үшін подводпен бөлек орналастыру
- cronjob cronjob тапсырмаларын орындауға арналған (егер бұл веб-бағдарлама болса - wget , немесе kubectl exec жұмысшы блоктарының бірінде және т.б.)
- және т.б.
Сіз ең дұрысы туралы даулай аласыз, бірақ бұл жағдайда біз «Crontasks үшін подкасттармен бөлек орналастыру» опциясын таңдадық.
Мұны қалай істеу керек:
- cron тапсырмаларын ConfigMap арқылы немесе config/addcron файлы арқылы қосыңыз
- бір жағдайда біз жұмысшы бағанына ұқсас контейнерді іске қосамыз + ондағы тәж тапсырмаларын орындауға мүмкіндік береміз
- бірдей кодтық база пайдаланылады, біріктірудің арқасында контейнерді құрастыру оңай
Бізге қандай жақсылық бар:
- Бізде Crontasks әзірлеушілер ортасына ұқсас ортада жұмыс істейді (докер)
- Crontasks 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 арқылы түзетіңіз, себебі өнім құлап кетті», бірақ Кубернетес мұны автоматты түрде және тоқтаусыз жасайды.
Орналастыру
Иә, біз Gitlab және Gitlab CI жанкүйерлеріміз, біз оны қолданамыз :)
Gitlab жүйесінде жоба репозиторийіне кіру кезінде Gitlab ортаның жаңа нұсқасын орналастыратын құбырды іске қосады.
Кезеңдері:
- құрастыру (жаңа Docker кескінін құру)
- сынақ (сынау)
- тазалау (сынақ ортасын жою)
- push (біз оны Docker тізіліміне жібереміз)
- орналастыру (біз Helm арқылы Kubernetes қолданбасын орналастырамыз).
Ура, дайын болды, іске асырайық!
Жақсы, немесе бар болса сұрақтар қойыңыз.
Сонымен біз не істедік
Техникалық тұрғыдан:
- докерленген Bitrix;
- Bitrix-ті әрқайсысы ең аз функцияларды орындайтын контейнерлерге «кесіңіз»;
- контейнерлердің азаматтығы жоқ күйіне қол жеткізілді;
- Kubernetes ішіндегі Bitrix жаңарту мәселесін шешті;
- барлық Bitrix функциялары жұмысын жалғастырды (барлығы дерлік);
- Біз Kubernetes-ке орналастыру және нұсқалар арасында кері қайтару бойынша жұмыс жасадық.
Бизнес тұрғысынан:
- ақауларға төзімділік;
- Kubernetes құралдары (Gitlab CI-мен оңай интеграция, үздіксіз орналастыру және т.б.);
- құпия парольдер (құпия сөздерге тікелей рұқсат берілгендерге ғана көрінеді);
- Бір инфрақұрылым ішінде қосымша орталарды (әзірлеу, сынақтар және т.б. үшін) жасау ыңғайлы.
Ақпарат көзі: www.habr.com