Sysadminka tizimi ma'murlari uchrashuvlari Chelyabinskda bo'lib o'tmoqda va oxirgi marta men Kubernetesda 1C-Bitrix-da ilovalarni ishga tushirish bo'yicha bizning yechimimiz haqida hisobot berdim.
Bitrix, Kubernetes, Ceph - ajoyib aralashma?
Bularning barchasidan qanday qilib ishlaydigan yechimni birlashtirganimizni aytib beraman.
Yuringlar!
Uchrashuv 18 aprel kuni Chelyabinskda bo'lib o'tdi. Uchrashuvlarimiz haqida o'qishingiz mumkin va qarang .
Agar siz bizga hisobot bilan yoki tinglovchi sifatida kelmoqchi bo'lsangiz - xush kelibsiz, yozing [elektron pochta bilan himoyalangan] va Telegram t.me/vadimisakanov.
Mening hisobotim
Yechim "Kubernetesdagi Bitrix, Southbridge 1.0 versiyasi"
Uchrashuvda bo'lgani kabi, men "Kubernetesdagi qo'g'irchoqlar uchun" formatida yechimimiz haqida gapiraman. Ammo siz Bitrix, Docker, Kubernetes, Ceph so'zlarini hech bo'lmaganda Vikipediyadagi maqolalar darajasida bilasiz deb o'ylayman.
Kubernetesdagi Bitrix haqida nima tayyor?
Kubernetes-da Bitrix ilovalarining ishlashi haqida butun Internetda juda kam ma'lumot mavjud.
Men faqat ushbu materiallarni topdim:
Qsoft'dan Aleksandr Serbul, 1C-Bitrix va Anton Tuzlukovning hisoboti:
Men uni tinglashni tavsiya qilaman.
Foydalanuvchidan o'z yechimingizni ishlab chiqish .
Ko'proq topildi .
Aaand... aslida hammasi shu.
Sizni ogohlantiraman, biz yuqoridagi havolalardagi echimlar sifatini tekshirmadik :)
Aytgancha, yechimimizni tayyorlashda men Aleksandr Serbul bilan gaplashdim, keyin uning hisoboti hali paydo bo'lmagan, shuning uchun mening slaydlarimda "Bitrix Kubernetesdan foydalanmaydi" bandi bor.
Ammo Docker-da Bitrix-ni ishga tushirish uchun allaqachon ko'plab tayyor Docker tasvirlari mavjud:
Bu Kubernetes-da Bitrix uchun to'liq yechim yaratish uchun etarlimi?
Yo'q. Ko'p sonli hal qilinishi kerak bo'lgan muammolar mavjud.
Kubernetes-da Bitrix bilan qanday muammolar bor?
Birinchidan, Dockerhub-dan tayyor tasvirlar Kubernetes uchun mos emas
Agar biz mikroservislar arxitekturasini yaratmoqchi bo'lsak (va biz odatda Kubernetesda qilamiz), biz Kubernetes ilovamizni konteynerlarga ajratishimiz va har bir konteynerda bitta kichik funktsiyani bajarishimiz kerak (va buni yaxshi bajaring). Nega faqat bitta? Muxtasar qilib aytganda, qanchalik sodda bo'lsa, shunchalik ishonchli.
Aniqroq bo'lish uchun ushbu maqola va videoni tomosha qiling, iltimos:
Dockerhub-dagi Docker tasvirlari asosan all-in-one printsipi asosida qurilgan, shuning uchun biz hali ham o'z velosipedimizni yasashimiz va hatto noldan tasvirlarni yaratishimiz kerak edi.
Ikkinchidan - sayt kodi administrator panelidan tahrirlanadi
Biz saytda yangi bo'lim yaratdik - kod yangilandi (yangi bo'lim nomi bilan katalog qo'shildi).
Agar siz administrator panelidan komponentning xususiyatlarini o'zgartirgan bo'lsangiz, kod o'zgaradi.
Kubernetes "sukut bo'yicha" bu bilan ishlay olmaydi; konteynerlar fuqaroligi bo'lmagan bo'lishi kerak.
Sababi: Klasterdagi har bir konteyner (pod) trafikning faqat bir qismini qayta ishlaydi. Agar siz kodni faqat bitta konteynerda (pod) o'zgartirsangiz, u holda kod turli podslarda har xil bo'ladi, sayt boshqacha ishlaydi va saytning turli versiyalari turli foydalanuvchilarga ko'rsatiladi. Siz bunday yashay olmaysiz.
Uchinchidan - siz tarqatish bilan muammoni hal qilishingiz kerak
Agar bizda monolit va bitta "klassik" server bo'lsa, hamma narsa juda oddiy: biz yangi kod bazasini joylashtiramiz, ma'lumotlar bazasini ko'chiramiz, trafikni kodning yangi versiyasiga o'tkazamiz. O'tish bir zumda sodir bo'ladi.
Agar bizda Kubernetesda mikroservislarga ajratilgan saytimiz bo'lsa, kodli konteynerlar juda ko'p - oh. Siz kodning yangi versiyasi bilan konteynerlarni to'plashingiz, ularni eskilari o'rniga chiqarishingiz, ma'lumotlar bazasini to'g'ri ko'chirishingiz va ideal holda buni tashrif buyuruvchilar sezmasdan qilishingiz kerak. Yaxshiyamki, Kubernetes bu borada bizga yordam beradi va har xil turdagi joylashtirishlarni qo'llab-quvvatlaydi.
To'rtinchidan - siz statikani saqlash masalasini hal qilishingiz kerak
Agar sizning saytingiz "faqat" 10 gigabayt bo'lsa va siz uni butunlay konteynerlarda joylashtirsangiz, siz 10 gigabaytlik konteynerlarga ega bo'lasiz, ular abadiy foydalanishni talab qiladi.
Saytning "eng og'ir" qismlarini konteynerlardan tashqarida saqlashingiz kerak va buni qanday qilib to'g'ri qilish kerakligi haqida savol tug'iladi.
Bizning yechimimizda nima etishmayapti?
Butun Bitrix kodi mikrofunktsiyalarga/mikroservislarga bo'linmaydi (shuning uchun ro'yxatdan o'tish alohida, onlayn do'kon moduli alohida va hokazo). Biz butun kod bazasini har bir konteynerda saqlaymiz.
Shuningdek, biz ma'lumotlar bazasini Kubernetes-da saqlamaymiz (men ishlab chiqarish muhiti uchun Kubernetes-da ma'lumotlar bazasi bilan echimlarni joriy qildim, lekin ishlab chiqarish uchun emas).
Sayt ma'murlari uchun sayt Kubernetes-da ishlayotgani hali ham seziladi. "Tizimni tekshirish" funksiyasi to'g'ri ishlamayapti, administrator panelidan sayt kodini tahrirlash uchun avval "Men kodni tahrir qilmoqchiman" tugmasini bosishingiz kerak.
Muammolar aniqlandi, mikroservislarni joriy qilish zarurati aniqlandi, maqsad aniq – Bitrix imkoniyatlarini ham, Kubernetes afzalliklarini ham saqlab qolgan holda Kubernetesda Bitrix’da ilovalarni ishga tushirish uchun ishchi tizimni olish. Amalga oshirishni boshlaylik.
arxitektura
Veb-server (ishchilar) bilan ko'plab "ishchi" podlar mavjud.
Cron vazifalari bilan bir ostida (faqat bitta talab qilinadi).
Administrator panelidan sayt kodini tahrirlash uchun bitta yangilanish (shuningdek, faqat bittasi talab qilinadi).
Biz savollarni hal qilamiz:
- Seanslarni qayerda saqlash kerak?
- Keshni qayerda saqlash kerak?
- Statikani qayerda saqlash kerak, gigabayt statikalarni konteynerlar to'plamiga joylashtirish uchun emas?
- Ma'lumotlar bazasi qanday ishlaydi?
Docker tasviri
Biz Docker tasvirini yaratishdan boshlaymiz.
Ideal variant shundaki, bizda bitta universal tasvir bor, uning asosida biz ishchi podlarni, Crontasks bilan podlarni olamiz va podlarni yangilaymiz.
.
U nginx, apache/php-fpm (qurilish vaqtida tanlanishi mumkin), pochta jo‘natish uchun msmtp va cronni o‘z ichiga oladi.
Rasmni yig'ishda saytning butun kod bazasi /app katalogiga ko'chiriladi (biz alohida umumiy xotiraga o'tadigan qismlar bundan mustasno).
Mikroservislar, xizmatlar
ishchi podalar:
- Nginx + konteyner apache/php-fpm + msmtp bilan konteyner
- Msmtp-ni alohida mikroservisga o'tkazish ish bermadi, Bitrix to'g'ridan-to'g'ri pochta jo'nata olmasligidan g'azablana boshladi
- Har bir konteynerda to'liq kod bazasi mavjud.
- Konteynerlardagi kodni o'zgartirishni taqiqlash.
cron ostida:
- apache, php, cron bilan konteyner
- to'liq kod bazasi kiritilgan
- konteynerlardagi kodni o'zgartirishni taqiqlash
ostida yangilash:
- nginx konteyneri + apache/php-fpm konteyneri + msmtp
- Konteynerlardagi kodni o'zgartirishga hech qanday taqiq yo'q
sessiya saqlash
Bitrix kesh xotirasi
Yana bir muhim narsa: biz hamma narsaga ulanish uchun parollarni, ma'lumotlar bazasidan pochtagacha, kubernet sirlarida saqlaymiz. Biz bonusga ega bo'lamiz: parollar faqat biz sirlarga kirish huquqini beradiganlarga ko'rinadi, lekin loyihaning kod bazasiga kirish huquqiga ega bo'lgan har bir kishi uchun emas.
Statik uchun saqlash
Siz har qanday narsadan foydalanishingiz mumkin: ceph, nfs (lekin biz ishlab chiqarish uchun nfs ni tavsiya etmaymiz), bulutli provayderlardan tarmoq xotirasi va boshqalar.
Saqlash saytning /upload/ katalogiga va statik tarkibga ega boshqa kataloglarga konteynerlarda ulanishi kerak.
Malumotlar bazasi
Oddiylik uchun ma'lumotlar bazasini Kubernetesdan tashqariga ko'chirishni tavsiya qilamiz. Kubernetesdagi baza alohida murakkab vazifa bo'lib, u sxemani kattalik tartibini yanada murakkablashtiradi.
Seansni saqlash
Biz memcached-dan foydalanamiz :)
U seansni saqlashni yaxshi boshqaradi, klasterlangan va php da session.save_path sifatida “mahalliy” quvvatlanadi. Bunday tizim klassik monolit arxitekturada ko'p marta sinovdan o'tgan, biz ko'p sonli veb-serverlar bilan klasterlar qurganimizda. Joylashtirish uchun biz ruldan foydalanamiz.
$ helm install stable/memcached --name sessionphp.ini - bu erda rasmda memcached-da seanslarni saqlash sozlamalari mavjud
Biz memcached bilan xostlar haqidagi ma'lumotlarni uzatish uchun Environment Variables-dan foydalandik .
Bu sizga bir xil kodni ishlab chiqaruvchi, bosqich, test, prod muhitlarida ishlatish imkonini beradi (ulardagi memkeshlangan xost nomlari boshqacha bo'ladi, shuning uchun biz har bir muhitga sessiyalar uchun noyob xost nomini o'tkazishimiz kerak).
Bitrix kesh xotirasi
Bizga barcha podlar yozishi va oʻqishi mumkin boʻlgan nosozliklarga chidamli xotira kerak.
Biz memcached-dan ham foydalanamiz.
Ushbu yechim Bitrix tomonidan tavsiya etiladi.
$ helm install stable/memcached --name cachebitrix/.settings_extra.php - bu erda Bitrix-da kesh saqlanadigan joy ko'rsatilgan.
Biz atrof-muhit o'zgaruvchilaridan ham foydalanamiz.
Krontaski
Kubernetes-da Crontasks-ni ishga tushirish uchun turli xil yondashuvlar mavjud.
- Crontasks-ni ishga tushirish uchun podkast bilan alohida joylashtirish
- cronjob (agar bu veb-ilova bo'lsa - wget bilan , yoki kubectl exec ishchi podlardan birida va hokazo.)
- va hokazo
Siz eng to'g'risi haqida bahslashishingiz mumkin, ammo bu holda biz "Crontasks uchun podlar bilan alohida joylashtirish" variantini tanladik.
Buni qanday qilish kerak:
- ConfigMap yoki config/addcron fayli orqali cron vazifalarini qo'shing
- bir holatda biz ishchi podga o'xshash konteynerni ishga tushiramiz + undagi toj vazifalarini bajarishga ruxsat beramiz
- bir xil kod bazasi ishlatiladi, birlashtirish tufayli konteyner yig'ish oddiy
Biz qanday yaxshilikni olamiz:
- Bizda ishlab chiquvchilar muhiti (docker) bilan bir xil muhitda ishlaydigan Crontasks bor.
- Crontasklarni Kubernetes uchun "qayta yozish" shart emas, ular avvalgidek bir xil shaklda va bir xil kod bazasida ishlaydi.
- cron vazifalarini faqat administratorlar emas, balki ishlab chiqarish bo'limiga tegishli huquqlarga ega bo'lgan barcha jamoa a'zolari qo'shishi mumkin
Administrator panelidan Southbridge K8SDeploy moduli va kodni tahrirlash
Biz ostida yangilash haqida gapirgan edi?
Qanday qilib u erga trafikni yo'naltirish kerak?
Hurray, biz PHP da buning uchun modul yozdik :) Bu Bitrix uchun kichik klassik modul. U hali ommaga ochiq emas, lekin biz uni ochishni rejalashtirmoqdamiz.
Modul Bitrix-da oddiy modul kabi o'rnatiladi:
Va bu shunday ko'rinadi:
Bu sizga sayt administratorini identifikatsiya qiluvchi va Kubernetesga yangilanish podasiga trafik jo‘natish imkonini beruvchi cookie faylini o‘rnatish imkonini beradi.
O'zgartirishlar tugallangach, siz git push tugmasini bosishingiz kerak, kod o'zgarishlari git-ga yuboriladi, keyin tizim kodning yangi versiyasi bilan tasvirni yaratadi va uni eski podlarni almashtirgan holda klaster bo'ylab "tashlaydi". .
Ha, bu biroz qiyin, lekin shu bilan birga biz mikroservis arxitekturasini saqlab qolamiz va Bitrix foydalanuvchilarini administrator panelidagi kodni tuzatish uchun sevimli imkoniyatidan mahrum qilmaymiz. Oxir-oqibat, bu variant, siz kodni tahrirlash muammosini boshqa yo'l bilan hal qilishingiz mumkin.
Rulda diagrammasi
Kubernetes-da ilovalar yaratish uchun biz odatda Helm paket menejeridan foydalanamiz.
Kubernetesdagi Bitrix yechimimiz uchun yetakchi tizim administratorimiz Sergey Bondarev maxsus Helm diagrammasini yozdi.
U ishchi, ugrade, cron podslarini quradi, kirishlar, xizmatlarni sozlaydi va o'zgaruvchilarni Kubernetes sirlaridan podlarga o'tkazadi.
Biz kodni Gitlab-da saqlaymiz va Gitlab-dan Helm qurilishini ham ishga tushiramiz.
Qisqasi, bu shunday ko'rinadi
$ helm upgrade --install project .helm --set image=registrygitlab.local/k8s/bitrix -f .helm/values.yaml --wait --timeout 300 --debug --tiller-namespace=productionHelm, shuningdek, joylashtirish paytida to'satdan biror narsa noto'g'ri bo'lsa, "uzluksiz" orqaga qaytish imkonini beradi. Vahima ichida bo'lmasangiz, "kodni ftp orqali tuzating, chunki mahsulot tushib ketgani" juda yoqimli, lekin Kubernetes buni avtomatik ravishda va ishlamay qoladi.
Joylashtirish
Ha, biz Gitlab & Gitlab CI muxlislarimiz, biz undan foydalanamiz :)
Gitlab-da loyiha omboriga kirishda Gitlab muhitning yangi versiyasini joylashtiradigan quvur liniyasini ishga tushiradi.
Bosqichlar:
- qurish (yangi Docker tasvirini yaratish)
- sinov (sinov)
- tozalash (sinov muhitini olib tashlash)
- surish (biz uni Docker registriga yuboramiz)
- joylashtirish (biz Helm orqali Kubernetesga ilovani joylashtiramiz).
Huray, tayyor, uni amalga oshiramiz!
Xo'sh, agar mavjud bo'lsa, savollar bering.
Xo'sh, biz nima qildik
Texnik nuqtai nazardan:
- dokerlashtirilgan Bitrix;
- Bitrix-ni har biri minimal funktsiyalarni bajaradigan konteynerlarga "kesish";
- konteynerlarning fuqaroligi bo'lmagan holatiga erishildi;
- Kubernetes-da Bitrix-ni yangilash muammosini hal qildi;
- barcha Bitrix funktsiyalari ishlashda davom etdi (deyarli barchasi);
- Biz Kubernetes-ga joylashtirish va versiyalar o'rtasida orqaga qaytish ustida ishladik.
Biznes nuqtai nazaridan:
- xatolarga chidamlilik;
- Kubernetes vositalari (Gitlab CI bilan oson integratsiya, uzluksiz joylashtirish va boshqalar);
- maxfiy parollar (faqat parollarga bevosita kirish huquqiga ega bo'lganlarga ko'rinadi);
- Yagona infratuzilma doirasida qo'shimcha muhitlarni (ishlab chiqish, testlar va boshqalar uchun) yaratish qulay.
Manba: www.habr.com