Հարավային կամուրջը Չելյաբինսկում և Բիթրիքսը Կուբերնետեսում

Sysadminka համակարգի ադմինիստրատորների հանդիպումները տեղի են ունենում Չելյաբինսկում, և վերջին անգամ ես զեկույց տվեցի Kubernetes-ում 1C-Bitrix-ի վրա հավելվածներ գործարկելու մեր լուծման մասին:

Bitrix, Kubernetes, Ceph - հիանալի խառնուրդ:

Ես ձեզ կասեմ, թե ինչպես ենք մենք հավաքել աշխատանքային լուծում այս ամենից:

Եկեք գնանք.

Հանդիպումը տեղի է ունեցել ապրիլի 18-ին Չելյաբինսկում։ Մեր հանդիպումների մասին կարող եք կարդալ այստեղ Ժամացույց և նայիր YouTube.

Եթե ​​ցանկանում եք մեզ մոտ գալ ռեպորտաժով կամ որպես ունկնդիր, բարի գալուստ, գրեք [էլեկտրոնային փոստով պաշտպանված] և Telegram-ում t.me/vadimisakanov:

Իմ զեկույցը

Սլայդներ

Լուծում «Bitrix in Kubernetes, տարբերակ Southbridge 1.0»

Ես կխոսեմ մեր լուծման մասին «Կուբերնետեսում կեղծիքների համար» ձևաչափով, ինչպես արվեց հանդիպման ժամանակ: Բայց ես ենթադրում եմ, որ դուք գիտեք Bitrix, Docker, Kubernetes, Ceph բառերը գոնե Վիքիպեդիայի հոդվածների մակարդակով։

Ի՞նչ է պատրաստ Bitrix-ի մասին Kubernetes-ում:

Ողջ ինտերնետում շատ քիչ տեղեկատվություն կա Kubernetes-ում Bitrix հավելվածների աշխատանքի մասին:
Ես գտա միայն այս նյութերը.

Զեկույց Ալեքսանդր Սերբուլի, 1C-Bitrix-ի և Անտոն Տուզլուկովի կողմից Qsoft-ից.

Խորհուրդ եմ տալիս լսել։

Օգտագործողի կողմից ձեր սեփական լուծումների մշակում սերկյրոն Հաբրեի վրա.
Գտնվել է ավելին նման որոշում.

Աաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաաատ...

Զգուշացնում եմ, վերևի հղումներում լուծումների որակը չենք ստուգել :)
Ի դեպ, մեր լուծումը պատրաստելիս ես խոսեցի Ալեքսանդր Սերբուլի հետ, այնուհետև նրա զեկույցը դեռ չէր հայտնվել, ուստի իմ սլայդներում կա «Bitrix-ը չի օգտագործում Kubernetes» կետը:

Բայց արդեն կան շատ պատրաստ Docker պատկերներ Docker-ում Bitrix-ը գործարկելու համար. https://hub.docker.com/search?q=bitrix&type=image

Սա բավարա՞ր է Kubernetes-ում Bitrix-ի համար ամբողջական լուծում ստեղծելու համար:
Ոչ Մեծ թվով խնդիրներ կան, որոնք պետք է լուծվեն։

Որո՞նք են Bitrix-ի հետ կապված խնդիրները Kubernetes-ում:

Նախ, Dockerhub-ի պատրաստի պատկերները հարմար չեն Kubernetes-ի համար

Եթե ​​մենք ցանկանում ենք կառուցել միկրոսերվիսների ճարտարապետություն (իսկ Kubernetes-ում մենք սովորաբար անում ենք), մենք պետք է մեր Kubernetes հավելվածը տարանջատենք կոնտեյներների մեջ և յուրաքանչյուր կոնտեյներ կատարի մեկ փոքր գործառույթ (և դա լավ կատարի): Ինչու՞ միայն մեկը: Մի խոսքով, որքան պարզ է, այնքան հուսալի:
Ավելի կոնկրետ լինելու համար դիտեք այս հոդվածը և տեսանյութը, խնդրում ենք. https://habr.com/ru/company/southbridge/blog/426637/

Dockerhub-ի Docker պատկերները հիմնականում կառուցված են «Բոլորը մեկում» սկզբունքով, այնպես որ մենք դեռ պետք է պատրաստեինք մեր սեփական հեծանիվը և նույնիսկ զրոյից պատկերներ ստեղծեինք:

Երկրորդ - կայքի կոդը խմբագրվում է ադմինիստրատորի վահանակից

Կայքում ստեղծել ենք նոր բաժին՝ կոդը թարմացվել է (ավելացվել է նոր բաժնի անունով գրացուցակ):

Եթե ​​դուք փոխել եք բաղադրիչի հատկությունները ադմինիստրատորի վահանակից, կոդը փոխվել է:

Kubernetes-ը «լռելյայն» չի կարող աշխատել դրա հետ, բեռնարկղերը պետք է քաղաքացիություն չունեն:

Պատճառը՝ կլաստերի յուրաքանչյուր կոնտեյներ (փոդ) մշակում է տրաֆիկի միայն մի մասը: Եթե ​​կոդը փոխեք միայն մեկ կոնտեյներով (pod), ապա ծածկագիրը տարբեր կլինի տարբեր pods-ում, կայքը կաշխատի այլ կերպ, և կայքի տարբեր տարբերակները կցուցադրվեն տարբեր օգտվողների համար: Չի կարելի այդպես ապրել։

Երրորդ - դուք պետք է լուծեք խնդիրը տեղակայման միջոցով

Եթե ​​մենք ունենք մոնոլիտ և մեկ «դասական» սերվեր, ամեն ինչ բավականին պարզ է. մենք տեղադրում ենք նոր կոդային բազա, տեղափոխում ենք տվյալների բազան, փոխարկում ենք երթևեկությունը կոդի նոր տարբերակին: Անջատումը տեղի է ունենում ակնթարթորեն:
Եթե ​​մենք Կուբերնետեսում ունենք կայք՝ կտրված միկրոսերվիսներով, ապա կոդով շատ կոնտեյներներ կան՝ օ: Դուք պետք է հավաքեք կոնտեյներներ կոդի նոր տարբերակով, դրանք դուրս գցեք հինների փոխարեն, ճիշտ տեղափոխեք տվյալների բազան և իդեալականորեն դա անեք այցելուների կողմից աննկատ: Բարեբախտաբար, Kubernetes-ն օգնում է մեզ այս հարցում՝ աջակցելով տարբեր տեսակի տեղակայումների մի ամբողջ փունջ:

Չորրորդ - դուք պետք է լուծեք ստատիկների պահպանման հարցը

Եթե ​​ձեր կայքը «ընդամենը» 10 գիգաբայթ է, և դուք այն ամբողջությամբ տեղակայում եք բեռնարկղերի մեջ, դուք կհայտնվեք 10 գիգաբայթանոց կոնտեյներներով, որոնց տեղակայումը ընդմիշտ պահանջվում է:
Դուք պետք է պահեք կայքի «ամենածանր» մասերը բեռնարկղերից դուրս, և հարց է առաջանում, թե ինչպես դա անել ճիշտ:

Ի՞նչն է պակասում մեր լուծումից:

Ամբողջ Bitrix կոդը բաժանված չէ միկրոֆունկցիաների/միկրոծառայությունների (որպեսզի գրանցումն առանձին լինի, առցանց խանութի մոդուլը առանձին լինի և այլն)։ Մենք պահում ենք ծածկագրի ամբողջ բազան յուրաքանչյուր կոնտեյներով:

Մենք նաև չենք պահում տվյալների բազան Kubernetes-ում (ես դեռ լուծումներ եմ կիրառել Kubernetes-ի տվյալների բազայով զարգացման միջավայրերի համար, բայց ոչ արտադրության համար):

Կայքի ադմինիստրատորների համար դեռ նկատելի կլինի, որ կայքը աշխատում է Kubernetes-ով: «Համակարգի ստուգում» գործառույթը ճիշտ չի աշխատում, կայքի կոդը ադմինիստրատորի վահանակից խմբագրելու համար նախ պետք է սեղմել «Ես ուզում եմ խմբագրել կոդը» կոճակը:

Բացահայտվել են խնդիրները, որոշվել է միկրոսերվիսների ներդրման անհրաժեշտությունը, նպատակը պարզ է՝ ստանալ Kubernetes-ում Bitrix-ի վրա հավելվածներ գործարկելու աշխատանքային համակարգ՝ պահպանելով ինչպես Bitrix-ի հնարավորությունները, այնպես էլ Kubernetes-ի առավելությունները։ Սկսենք իրագործումը։

ճարտարապետություն

Վեբ սերվերով (աշխատողներ) կան բազմաթիվ «աշխատող» պատյաններ:
One under cron առաջադրանքներով (պահանջվում է միայն մեկը):
Մեկ թարմացում՝ կայքի կոդը ադմինիստրատորի վահանակից խմբագրելու համար (նաև պահանջվում է միայն մեկը):

Մենք հարցեր ենք լուծում.

• Որտեղ պահել նիստերը:
• Որտեղ պահել քեշը:
• Որտե՞ղ պահել ստատիկան, չտեղադրել գիգաբայթ ստատիկներ մի փունջ տարաների մեջ:
• Ինչպե՞ս է աշխատելու տվյալների բազան:

Դոկերի պատկեր

Մենք սկսում ենք Docker պատկեր ստեղծելով:

Իդեալական տարբերակն այն է, որ մենք ունենք մեկ ունիվերսալ պատկեր, որի հիման վրա մենք ստանում ենք աշխատանքային պատիճներ, պատիճներ Crontasks-ով և արդիականացումներ:

Մենք հենց այսպիսի կերպար ենք ստեղծել.

Այն ներառում է nginx, apache/php-fpm (կարելի է ընտրել կառուցման ընթացքում), msmtp փոստ ուղարկելու համար և cron:

Պատկերը հավաքելիս կայքի կոդերի ամբողջ բազան պատճենվում է /app գրացուցակում (բացառությամբ այն մասերի, որոնք մենք կտեղափոխենք առանձին ընդհանուր պահեստ):

Միկրոծառայություններ, ծառայություններ

բանվորական պատյաններ.

• Կոնտեյներ nginx + կոնտեյներով apache/php-fpm + msmtp
• Չստացվեց msmtp-ը տեղափոխել առանձին միկրոսերվիս, Bitrix-ը սկսում է վրդովվել, որ չի կարող ուղղակիորեն նամակ ուղարկել։
• Յուրաքանչյուր կոնտեյներ ունի ամբողջական կոդերի բազա:
• Տարաներում ծածկագիրը փոխելու արգելք.

cron under:

• կոնտեյներ apache-ով, php, cron-ով
• կոդերի ամբողջական բազան ներառված է
• բեռնարկղերում ծածկագիրը փոխելու արգելք

արդիականացնել տակ՝

• nginx կոնտեյներ + apache/php-fpm կոնտեյներ + msmtp
• Տարաներում ծածկագիրը փոխելու արգելք չկա

նիստերի պահեստավորում

Bitrix քեշի պահեստավորում

Մեկ այլ կարևոր բան. մենք գաղտնաբառերը պահում ենք ամեն ինչին միանալու համար՝ տվյալների բազայից մինչև փոստ, kubernetes գաղտնիքներում։ Մենք ստանում ենք բոնուս. գաղտնաբառերը տեսանելի են միայն նրանց, ում մենք թույլ ենք տալիս մուտք գործել գաղտնիքներ, և ոչ բոլոր նրանց, ովքեր մուտք ունեն ծրագրի կոդերի բազա:

Ստատիկի պահեստավորում

Դուք կարող եք օգտագործել ցանկացած բան՝ ceph, nfs (բայց մենք չենք առաջարկում nfs արտադրության համար), ցանցային պահեստավորում ամպային մատակարարներից և այլն:

Պահեստը պետք է բեռնարկղերով միացվի կայքի /upload/ գրացուցակին և ստատիկ բովանդակությամբ այլ գրացուցակներին:

Նյութերի բազա

Պարզության համար խորհուրդ ենք տալիս տվյալների բազան տեղափոխել Kubernetes-ից դուրս: Կուբերնետեսի բազան առանձին բարդ խնդիր է, այն կդարձնի սխեման ավելի բարդ:

Նիստի պահեստավորում

Մենք օգտագործում ենք memcached :)

Այն լավ է կառավարում նիստերի պահեստավորումը, կլաստերացված է և աջակցվում է «բնականաբար» որպես session.save_path php-ում: Նման համակարգը բազմիցս փորձարկվել է դասական մոնոլիտ ճարտարապետության մեջ, երբ մենք կառուցեցինք կլաստերներ մեծ թվով վեբ սերվերներով։ Տեղակայման համար մենք օգտագործում ենք ղեկը:

$ helm install stable/memcached --name session

php.ini - այստեղ պատկերը պարունակում է նիստերը memcached-ում պահելու կարգավորումներ

Մենք օգտագործել ենք Environment Variables՝ հոսթինգների մասին տվյալները memcached-ով փոխանցելու համար https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/.
Սա թույլ է տալիս օգտագործել նույն կոդը մշակման, փուլի, փորձարկման, պրոդ միջավայրերում (դրանցում memcached host անունները տարբեր կլինեն, ուստի մենք պետք է յուրաքանչյուր միջավայրին փոխանցենք յուրօրինակ հոսթի անուն նիստերի համար):
Bitrix քեշի պահեստավորում

Մեզ անհրաժեշտ է անսարքության հանդուրժող պահեստ, որտեղ բոլոր պատյանները կարող են գրել և կարդալ:

Մենք նաև օգտագործում ենք memcached:
Այս լուծումը առաջարկվում է հենց Bitrix-ի կողմից:

$ helm install stable/memcached --name cache

bitrix/.settings_extra.php - այստեղ Bitrix-ում նշվում է, թե որտեղ է պահվում քեշը

Մենք նաև օգտագործում ենք Environment Variables:

Կրոնտասկի

Կուբերնետեսում Crontasks-ը գործարկելու տարբեր մոտեցումներ կան:

• առանձին տեղակայում պատիճով Crontasks-ի գործարկման համար
• cronjob crontasks-ի կատարման համար (եթե սա վեբ հավելված է՝ wget-ով https://$host$cronjobname, կամ kubectl exec աշխատողի պատյաններից մեկի ներսում և այլն)
• եւ այլն:

Դուք կարող եք վիճել ամենաճիշտի մասին, բայց այս դեպքում մենք ընտրեցինք «առանձին տեղակայում պատիճներով Crontasks-ի համար» տարբերակը:

Ինչպես դա անել:

• ավելացնել cron առաջադրանքները ConfigMap-ի կամ config/addcron ֆայլի միջոցով
• մի դեպքում մենք գործարկում ենք բանվորի պատի նույնական կոնտեյներ + թույլ ենք տալիս դրանում կատարել թագի առաջադրանքները
• օգտագործվում է նույն ծածկագրի բազան, միավորման շնորհիվ բեռնարկղերի հավաքումը պարզ է

Ինչ լավ ենք մենք ստանում.

• մենք ունենք աշխատանքային Crontasks մի միջավայրում, որը նույնական է մշակողների միջավայրին (docker)
• Crontasks-ը Kubernetes-ի համար «վերագրելու» կարիք չունի, նրանք աշխատում են նույն ձևով և նույն կոդի բազայում, ինչ նախկինում:
• cron-ի առաջադրանքները կարող են ավելացնել թիմի բոլոր անդամները, որոնք իրավունք ունեն արտադրական ճյուղին, այլ ոչ միայն ադմինները

Southbridge K8SDeploy մոդուլը և կոդի խմբագրումը ադմինիստրատորի վահանակից

Մենք խոսում էինք արդիականացման մասին:
Ինչպե՞ս ուղղորդել երթևեկությունը այնտեղ:
Ուռա, մենք դրա համար մոդուլ ենք գրել PHP-ում :) Սա փոքրիկ դասական մոդուլ է Bitrix-ի համար: Այն դեռ հանրությանը հասանելի չէ, բայց մենք նախատեսում ենք բացել այն:
Մոդուլը տեղադրված է սովորական մոդուլի նման Bitrix-ում.

Եվ դա կարծես հետևյալն է.

Այն թույլ է տալիս սահմանել թխուկ, որը նույնականացնում է կայքի ադմինիստրատորին և թույլ է տալիս Kubernetes-ին երթևեկություն ուղարկել դեպի թարմացման պատիճ:

Երբ փոփոխություններն ավարտվեն, դուք պետք է սեղմեք git push-ը, կոդի փոփոխությունները կուղարկվեն git-ին, այնուհետև համակարգը կստեղծի պատկեր կոդի նոր տարբերակով և այն «կթողարկի» ամբողջ կլաստերի վրա՝ փոխարինելով հին պատյանները: .

Այո, դա մի քիչ հենարան է, բայց միևնույն ժամանակ մենք պահպանում ենք միկրոսերվիսային ճարտարապետությունը և չենք խլում Bitrix-ի օգտատերերից ադմինիստրատորի վահանակից ծածկագիրը շտկելու իրենց սիրելի հնարավորությունը: Ի վերջո, սա տարբերակ է՝ դուք կարող եք այլ կերպ լուծել կոդը խմբագրելու խնդիրը։

Սաղավարտի աղյուսակ

Kubernetes-ի վրա հավելվածներ ստեղծելու համար մենք սովորաբար օգտագործում ենք Helm փաթեթի կառավարիչը:
Կուբերնետեսում մեր Bitrix լուծման համար Սերգեյ Բոնդարևը՝ մեր առաջատար համակարգի ադմինիստրատորը, գրել է Helm-ի հատուկ աղյուսակ:

Այն կառուցում է worker, ugrade, cron pods, կարգավորում է մուտքերը, ծառայությունները և փոփոխականները տեղափոխում Kubernetes գաղտնիքներից դեպի pods:

Մենք պահում ենք կոդը Gitlab-ում, ինչպես նաև գործարկում ենք Helm build-ը Gitlab-ից:

Մի խոսքով, կարծես սա է

$ helm upgrade --install project .helm --set image=registrygitlab.local/k8s/bitrix -f .helm/values.yaml --wait --timeout 300 --debug --tiller-namespace=production

Helm-ը նաև թույլ է տալիս «անխափան» հետադարձ կատարել, եթե տեղակայման ժամանակ հանկարծ ինչ-որ բան սխալ լինի: Հաճելի է, երբ խուճապի մեջ չես «շտկել կոդը ftp-ի միջոցով, քանի որ արդյունահանումն ընկել է», բայց Kubernetes-ը դա անում է ավտոմատ կերպով և առանց խափանումների:

Տեղակայել

Այո, մենք Gitlab & Gitlab CI-ի երկրպագուներ ենք, օգտագործում ենք :)
Երբ Gitlab-ում ներգրավվում է նախագծի պահեստին, Gitlab-ը գործարկում է խողովակաշար, որը տեղակայում է շրջակա միջավայրի նոր տարբերակը:

Բեմեր `

• կառուցել (նոր Docker պատկերի ստեղծում)
• թեստ (փորձարկում)
• մաքրում (հեռացնելով փորձարկման միջավայրը)
• push (մենք այն ուղարկում ենք Docker ռեեստր)
• տեղակայել (հավելվածը տեղադրում ենք Kubernetes-ում Helm-ի միջոցով):

Ուռա՛յ, պատրաստ է, եկեք իրականացնենք։
Դե, կամ հարցեր տվեք, եթե կան:

Այսպիսով, ինչ արեցինք

Տեխնիկական տեսանկյունից.

• dockerized Bitrix;
• «կտրել» Bitrix-ը տարաների մեջ, որոնցից յուրաքանչյուրը կատարում է նվազագույն գործառույթներ.
• հասել է բեռնարկղերի քաղաքացիություն չունեցող վիճակի.
• լուծել խնդիրը Kubernetes-ում Bitrix-ի թարմացման հետ.
• Bitrix-ի բոլոր գործառույթները շարունակեցին աշխատել (գրեթե բոլորը);
• Մենք աշխատել ենք Kubernetes-ում տեղակայման և տարբերակների միջև վերադարձի վրա:

Բիզնեսի տեսանկյունից.

• սխալների հանդուրժողականություն;
• Kubernetes գործիքներ (հեշտ ինտեգրում Gitlab CI-ի հետ, անխափան տեղակայում և այլն);
• գաղտնի գաղտնաբառեր (տեսանելի են միայն նրանց, ում ուղղակիորեն տրված է մուտք դեպի գաղտնաբառեր);
• Հարմար է ստեղծել լրացուցիչ միջավայրեր (մշակման, փորձարկումների և այլն) մեկ ենթակառուցվածքի շրջանակներում:

Source: www.habr.com