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