Աշխատելով ՏՏ ոլորտում, սկսում ես նկատել, որ համակարգերն ունեն իրենց առանձնահատկությունը: Նրանք կարող են լինել ճկուն, լուռ, էքսցենտրիկ և խիստ: Նրանք կարող են գրավել կամ վանել: Այսպես թե այնպես, պետք է «բանակցել» նրանց հետ, մանևրել «որոգայթների» միջև և կառուցել նրանց փոխազդեցության շղթաներ։
Այսպիսով, մենք պատիվ ունեցանք կառուցելու ամպային հարթակ, և դրա համար մեզ անհրաժեշտ էր «համոզել» մի քանի ենթահամակարգերի աշխատել մեզ հետ: Բարեբախտաբար, մենք ունենք «API լեզու», անմիջական ձեռքեր և մեծ ոգևորություն:
Այս հոդվածը տեխնիկապես հարդքոր չի լինի, այլ նկարագրելու է այն խնդիրները, որոնք մենք հանդիպել ենք ամպը կառուցելիս: Ես որոշեցի նկարագրել մեր ուղին թեթև տեխնիկական ֆանտազիայի տեսքով այն մասին, թե ինչպես ենք մենք ընդհանուր լեզու փնտրում համակարգերի հետ և ինչ ենք դուրս գալիս դրանից:
Բարի գալուստ կատու:
Սկիզբն է ճանապարհորդության
Որոշ ժամանակ առաջ մեր թիմին հանձնարարվել էր ամպային հարթակ գործարկել մեր հաճախորդների համար: Մենք ունեինք կառավարման աջակցություն, ռեսուրսներ, ապարատային փաթեթ և ազատություն՝ ծառայության ծրագրային մասի ներդրման համար տեխնոլոգիաներ ընտրելու հարցում:
Կային նաև մի շարք պահանջներ.
- ծառայությանը անհրաժեշտ է հարմար անձնական հաշիվ.
- հարթակը պետք է ինտեգրված լինի գոյություն ունեցող բիլինգի համակարգին.
- ծրագրային ապահովում և սարքավորում՝ OpenStack + վոլֆրամի գործվածք (Open Contrail), որը մեր ինժեներները սովորել են բավականին լավ «եփել»:
Մենք ձեզ մեկ այլ անգամ կպատմենք այն մասին, թե ինչպես է հավաքվել թիմը, մշակվել է անձնական հաշվի միջերեսը և կայացվել են դիզայնի որոշումներ, եթե Հաբրա համայնքը հետաքրքրված է:
Գործիքները, որոնք մենք որոշեցինք օգտագործել.
- Python + Flask + Swagger + SQLAlchemy - ամբողջովին ստանդարտ Python հավաքածու;
- Vue.js frontend-ի համար;
- Մենք որոշեցինք կատարել բաղադրիչների և ծառայությունների միջև փոխազդեցությունը՝ օգտագործելով Celery-ը AMQP-ի միջոցով:
Նախատեսելով Python-ի ընտրության վերաբերյալ հարցեր՝ ես կբացատրեմ: Լեզուն գտել է իր տեղը մեր ընկերությունում և դրա շուրջ ձևավորվել է փոքր, բայց դեռևս մշակույթ: Ուստի որոշվեց դրա վրա սկսել ծառայությունը կառուցել։ Ավելին, նման խնդիրների զարգացման արագությունը հաճախ որոշիչ է։
Այսպիսով, եկեք սկսենք մեր ծանոթությունը:
Լուռ օրինագիծ - հաշիվ
Մենք վաղուց ենք ճանաչում այս տղային: Նա միշտ նստում էր կողքիս ու լուռ ինչ-որ բան հաշվում։ Երբեմն նա մեզ ուղարկում էր օգտատերերի հարցումներ, թողարկում հաճախորդների հաշիվ-ապրանքագրեր և կառավարում ծառայություններ: Սովորական աշխատասեր տղա։ Ճիշտ է, դժվարություններ կային։ Նա լուռ է, երբեմն մտախոհ և հաճախ՝ սեփական մտքի վրա։
Billing-ը առաջին համակարգն է, որի հետ մենք փորձել ենք ընկերանալ: Եվ առաջին դժվարությունը, որին հանդիպեցինք, ծառայությունների մշակման ժամանակ էր։
Օրինակ, երբ ստեղծվում կամ ջնջվում է, առաջադրանքը մտնում է վճարման ներքին հերթ: Այսպիսով, ներդրվում է ծառայությունների հետ ասինխրոն աշխատանքի համակարգ։ Մեր ծառայությունների տեսակները մշակելու համար մենք պետք է «դնենք» մեր առաջադրանքները այս հերթի մեջ: Եվ այստեղ մենք բախվեցինք մի խնդրի՝ փաստաթղթերի պակասի:
Դատելով ծրագրային ապահովման API-ի նկարագրությունից՝ դեռ հնարավոր է լուծել այս խնդիրը, բայց մենք ժամանակ չունեինք հակադարձ ճարտարագիտություն անելու, ուստի տրամաբանությունը դուրս հանեցինք և առաջադրանքների հերթ կազմակերպեցինք RabbitMQ-ի վերևում: Ծառայության վրա գործողությունը նախաձեռնվում է հաճախորդի կողմից իր անձնական հաշվից, վերածվում է Celery «առաջադրանքի» հետնամասում և կատարվում է բիլինգի և OpenStack-ի կողմից: Նեխուրը բավականին հարմար է դարձնում առաջադրանքները կառավարելը, կրկնությունները կազմակերպելը և կարգավիճակը վերահսկելը: Դուք կարող եք ավելին կարդալ «նեխուրի» մասին, օրինակ. .
Բացի այդ, բիլինգը չխանգարեց մի նախագիծ, որը սպառվեց: Շփվելով ծրագրավորողների հետ՝ մենք պարզեցինք, որ վիճակագրությունը հաշվարկելիս (և մենք պետք է իրականացնենք հենց այսպիսի տրամաբանություն), գոյություն ունի դադարեցման կանոնների բարդ փոխկապակցվածություն։ Բայց այս մոդելները լավ չեն համապատասխանում մեր իրականությանը: Մենք դա իրականացրեցինք նաև Celery-ի առաջադրանքների միջոցով՝ տանելով ծառայության կառավարման տրամաբանությունը դեպի հետին պլան:
Վերոհիշյալ երկու խնդիրներն էլ հանգեցրին նրան, որ կոդը մի փոքր փքվեց, և ապագայում մենք ստիպված կլինենք վերամշակել, որպեսզի առաջադրանքների հետ աշխատելու տրամաբանությունը տեղափոխենք առանձին ծառայություն: Մենք նաև պետք է որոշ տեղեկություններ պահենք օգտատերերի և նրանց ծառայությունների մասին մեր աղյուսակներում՝ աջակցելու այս տրամաբանությանը:
Մեկ այլ խնդիր լռությունն է։
Բիլլին լուռ պատասխանում է «Լավ» որոշ API հարցումների: Սա այն դեպքն էր, օրինակ, երբ մենք խոստացված վճարումների վճարումներ կատարեցինք թեստի ժամանակ (այդ մասին ավելի ուշ): Հարցումները ճիշտ են կատարվել, և մենք սխալներ չենք տեսել։
Ես ստիպված էի ուսումնասիրել տեղեկամատյանները UI-ի միջոցով համակարգի հետ աշխատելիս: Պարզվեց, որ բիլինգն ինքն է կատարում նմանատիպ հարցումներ՝ փոխելով շրջանակը կոնկրետ օգտատիրոջ, օրինակ՝ ադմինիստրատորի, փոխանցելով այն su պարամետրով։
Ընդհանուր առմամբ, չնայած փաստաթղթերում առկա բացերին և API-ի փոքր թերություններին, ամեն ինչ բավականին լավ է անցել: Տեղեկամատյանները կարելի է կարդալ նույնիսկ մեծ ծանրաբեռնվածության դեպքում, եթե հասկանում եք, թե ինչպես են դրանք կառուցված և ինչ փնտրել: Տվյալների բազայի կառուցվածքը զարդարուն է, բայց բավականին տրամաբանական և որոշ առումներով նույնիսկ գրավիչ:
Այսպիսով, ամփոփելու համար, հիմնական խնդիրները, որոնք մենք հանդիպեցինք փոխգործակցության փուլում, կապված են որոշակի համակարգի ներդրման առանձնահատկությունների հետ.
- չփաստաթղթավորված «առանձնահատկություններ», որոնք այս կամ այն կերպ ազդել են մեզ վրա.
- փակ աղբյուր (բիլինգը գրված է C++-ով), արդյունքում՝ անհնար է 1-ին խնդիրը լուծել այլ կերպ, քան «փորձություն և սխալ»:
Բարեբախտաբար, արտադրանքն ունի բավականին ընդարձակ API, և մենք ինտեգրել ենք հետևյալ ենթահամակարգերը մեր անձնական հաշվի մեջ.
- Տեխնիկական աջակցության մոդուլ - ձեր անձնական հաշվից ստացված հարցումները «փոխանցվում են» սպասարկման հաճախորդների համար թափանցիկ վճարման համար.
- ֆինանսական մոդուլ - թույլ է տալիս ընթացիկ հաճախորդներին հաշիվ-ապրանքագրեր տրամադրել, դուրս գրել և ստեղծել վճարային փաստաթղթեր.
- ծառայության կառավարման մոդուլ. դրա համար մենք պետք է իրականացնեինք մեր սեփական կարգավորիչը: Համակարգի ընդլայնելիությունը ձեռնտու էր մեզ, և մենք Բիլիին «սովորեցրինք» ծառայության նոր տեսակ:
Դա մի քիչ դժվարություն էր, բայց այսպես թե այնպես, կարծում եմ, որ ես ու Բիլլին իրար հետ կհասնենք։
Քայլելով վոլֆրամի դաշտերով – Վոլֆրամի գործվածք
Վոլֆրամի դաշտերը կետագծված են հարյուրավոր մետաղալարերով՝ դրանց միջով փոխանցելով հազարավոր բիթ տեղեկատվություն: Տեղեկատվությունը հավաքվում է «փաթեթների» մեջ, վերլուծվում, կառուցում բարդ երթուղիներ, ասես կախարդանքով:
Սա երկրորդ համակարգի տիրույթն է, որի հետ մենք պետք է ընկերանայինք՝ վոլֆրամի գործվածք (TF), նախկինում՝ OpenContrail: Նրա խնդիրն է կառավարել ցանցային սարքավորումները՝ մեզ՝ որպես օգտագործողների, ապահովելով ծրագրային աբստրակցիա։ TF - SDN, ներառում է ցանցային սարքավորումների հետ աշխատելու բարդ տրամաբանությունը: Բուն տեխնոլոգիայի մասին լավ հոդված կա, օրինակ. .
Համակարգը ինտեգրված է OpenStack-ի հետ (քննարկվում է ստորև) Նեյտրոնային հավելվածի միջոցով:
OpenStack ծառայությունների փոխազդեցություն:
Օպերատիվ բաժնի տղաները մեզ ծանոթացրեցին այս համակարգի հետ։ Մենք օգտագործում ենք համակարգի API՝ մեր ծառայությունների ցանցային փաթեթը կառավարելու համար: Դա մեզ դեռ որևէ լուրջ խնդիր կամ անհարմարություն չի պատճառել (չեմ կարող խոսել ՕԷ-ի տղաների փոխարեն), բայց փոխազդեցության մեջ եղել են տարօրինակություններ:
Առաջինն այսպիսի տեսք ուներ. հրամանները, որոնք պահանջում էին մեծ քանակությամբ տվյալների արտածում SSH-ի միջոցով միանալիս, պարզապես «կախեցին» կապը, մինչդեռ VNC-ի միջոցով ամեն ինչ ճիշտ էր աշխատում:
Նրանց համար, ովքեր ծանոթ չեն խնդրին, այն բավականին ծիծաղելի է թվում. ls /root-ը ճիշտ է աշխատում, մինչդեռ, օրինակ, վերին մասը «սառեցնում է» ամբողջությամբ։ Բարեբախտաբար, նախկինում էլ բախվել ենք նմանատիպ խնդիրների։ Որոշվեց՝ կարգավորելով MTU-ն հաշվողական հանգույցներից մինչև երթուղիչները երթուղու վրա: Ի դեպ, սա TF-ի խնդիր չէ։
Հաջորդ խնդիրը հենց անկյունում էր: Մի «գեղեցիկ» պահի մեջ երթուղայինի կախարդանքն անհետացավ հենց այնպես։ TF-ը դադարեցրել է սարքավորումների երթուղիների կառավարումը:
Մենք աշխատեցինք Openstack-ի հետ ադմինիստրատորի մակարդակից և դրանից հետո անցանք անհրաժեշտ օգտվողի մակարդակին: SDN-ն, ըստ երևույթին, «գրավում» է այն օգտվողի շրջանակը, ում կողմից կատարվում են գործողությունները: Փաստն այն է, որ նույն ադմինիստրատորի հաշիվն օգտագործվում է TF-ին և OpenStack-ին միացնելու համար: Օգտագործողին անցնելու քայլին «կախարդանքն» անհետացավ։ Որոշվեց ստեղծել առանձին հաշիվ՝ համակարգի հետ աշխատելու համար։ Սա մեզ թույլ տվեց աշխատել՝ չխախտելով ինտեգրման գործառույթը:
Silicon Lifeforms - OpenStack
Տարօրինակ ձևով սիլիկոնե արարած է ապրում վոլֆրամի դաշտերի մոտ: Ամենից շատ այն կարծես չափահաս երեխա է, ով կարող է մեկ ճոճանակով ջախջախել մեզ, բայց նրանից ակնհայտ ագրեսիա չի գալիս։ Այն վախ չի առաջացնում, բայց նրա չափը վախ է ներշնչում։ Ինչպես և շրջապատում տեղի ունեցողի բարդությունը:
OpenStack-ը մեր հարթակի առանցքն է:
OpenStack-ն ունի մի քանի ենթահամակարգեր, որոնցից մենք ներկայումս առավել ակտիվ օգտագործում ենք Nova, Glance և Cinder: Նրանցից յուրաքանչյուրն ունի իր սեփական API-ն: Nova-ն պատասխանատու է հաշվողական ռեսուրսների և օրինակների ստեղծման համար, Cinder-ը պատասխանատու է ծավալների և դրանց նկարների կառավարման համար, Glance-ը պատկերային ծառայություն է, որը կառավարում է ՕՀ-ի ձևանմուշները և դրանց վրա մետատեղեկատվությունը:
Յուրաքանչյուր ծառայություն աշխատում է կոնտեյներով, և հաղորդագրության միջնորդը «սպիտակ նապաստակն» է՝ RabbitMQ:
Այս համակարգը մեզ տվեց ամենաանսպասելի դժվարությունը։
Եվ առաջին խնդիրը չուշացավ, երբ փորձեցինք լրացուցիչ ծավալ միացնել սերվերին։ Cinder API-ն կտրականապես հրաժարվեց կատարել այս առաջադրանքը: Ավելի ճիշտ, եթե հավատում եք OpenStack-ին, կապը հաստատված է, բայց վիրտուալ սերվերի ներսում սկավառակի սարք չկա:
Մենք որոշեցինք շեղում կատարել և նույն գործողությունը պահանջեցինք Nova API-ից: Արդյունքն այն է, որ սարքը ճիշտ է միանում և հասանելի է սերվերի ներսում: Թվում է, որ խնդիրն առաջանում է, երբ բլոկ-պահեստավորումը չի արձագանքում Cinder-ին:
Մեզ մեկ այլ դժվարություն էր սպասում սկավառակների հետ աշխատելիս. Համակարգի ծավալը չհաջողվեց անջատել սերվերից:
Կրկին, OpenStack-ն ինքը «երդվում է», որ ոչնչացրել է կապը, և այժմ դուք կարող եք ճիշտ աշխատել ձայնի հետ առանձին: Բայց API-ն կտրականապես չէր ցանկանում գործողություններ կատարել սկավառակի վրա:
Այստեղ մենք որոշեցինք ոչ թե առանձնապես կռվել, այլ փոխել մեր տեսակետը ծառայության տրամաբանության վերաբերյալ։ Եթե կա օրինակ, պետք է լինի նաև համակարգի ծավալը։ Հետևաբար, օգտատերը դեռ չի կարող հեռացնել կամ անջատել համակարգի «սկավառակը»՝ առանց «սերվերը» ջնջելու։
OpenStack-ը համակարգերի բավականին բարդ հավաքածու է իր փոխազդեցության տրամաբանությամբ և զարդարուն API-ով: Մեզ օգնում են բավականին մանրամասն փաստաթղթերը և, իհարկե, փորձն ու սխալը (ուր կլինեինք մենք առանց դրա):
Փորձնական վազք
Անցյալ տարվա դեկտեմբերին մենք փորձնական գործարկում ենք իրականացրել։ Հիմնական խնդիրն էր մեր նախագիծը մարտական ռեժիմով փորձարկել տեխնիկական և UX կողմից։ Հանդիսատեսը ընտրովի է հրավիրվել, իսկ թեստավորումը փակվել է։ Այնուամենայնիվ, մենք թողել ենք նաև մեր կայքում փորձարկման մուտքի իրավունք խնդրելու տարբերակը:
Թեստն ինքնին, իհարկե, զերծ չմնաց իր զվարճալի պահերից, քանի որ հենց այստեղ են մեր արկածները նոր սկսվում։
Նախ, մենք որոշ չափով սխալ գնահատեցինք նախագծի նկատմամբ հետաքրքրությունը և ստիպված եղանք արագորեն ավելացնել հաշվողական հանգույցներ հենց թեստի ընթացքում: Կլաստերի համար սովորական դեպք, բայց այստեղ էլ կային որոշ նրբերանգներ: TF-ի որոշակի տարբերակի փաստաթղթերը ցույց են տալիս միջուկի կոնկրետ տարբերակը, որի վրա փորձարկվել է vRouter-ի հետ աշխատանքը: Մենք որոշեցինք գործարկել հանգույցներ ավելի նոր միջուկներով: Արդյունքում, TF-ն հանգույցներից երթուղիներ չի ստացել: Ես ստիպված էի շտապ հետ գլորել միջուկները։
Մեկ այլ հետաքրքրություն կապված է ձեր անձնական հաշվի «փոխել գաղտնաբառը» կոճակի գործունակության հետ:
Մենք որոշեցինք օգտագործել JWT՝ մեր անձնական հաշվի մուտքը կազմակերպելու համար, որպեսզի չաշխատենք նիստերի հետ: Քանի որ համակարգերը բազմազան են և լայնորեն ցրված, մենք կառավարում ենք մեր սեփական նշանը, որում մենք «փաթաթում ենք» նիստերը բիլինգից և նշանը OpenStack-ից: Երբ գաղտնաբառը փոխվում է, նշանը, իհարկե, «վատանում է», քանի որ օգտվողի տվյալները այլևս վավեր չեն, և այն պետք է վերաթողարկվի:
Մենք մոռացանք այս կետի մասին, և պարզապես բավարար ռեսուրսներ չկային այս հատվածն արագ ավարտելու համար: Մենք պետք է անջատեինք ֆունկցիոնալությունը թեստը սկսելուց անմիջապես առաջ:
Ներկայումս մենք դուրս ենք գալիս օգտատիրոջից, եթե գաղտնաբառը փոխվել է:
Չնայած այս նրբերանգներին, թեստավորումը լավ անցավ: Մի երկու շաբաթվա ընթացքում մոտ 300 մարդ կանգ առավ։ Մենք կարողացանք ապրանքին նայել օգտատերերի աչքերով, փորձարկել այն գործողության մեջ և հավաքել բարձրորակ արձագանքներ:
Շարունակելի
Մեզանից շատերի համար սա այս մասշտաբի առաջին նախագիծն է: Մենք մի շարք արժեքավոր դասեր քաղեցինք այն մասին, թե ինչպես աշխատել որպես թիմ և կայացնել ճարտարապետական և նախագծային որոշումներ: Ինչպես ինտեգրել փոքր ռեսուրսներով բարդ համակարգերը և դրանք արտադրել:
Իհարկե, աշխատելու բան կա և՛ կոդի, և՛ համակարգի ինտեգրման ինտերֆեյսների վրա: Նախագիծը բավականին երիտասարդ է, բայց մենք լի ենք այն հուսալի և հարմարավետ ծառայության վերածելու հավակնություններով:
Մենք արդեն կարողացել ենք համոզել համակարգերին։ Բիլը պարտաճանաչորեն կատարում է հաշվումը, վճարումը և օգտատերերի հարցումները իր պահարանում: Վոլֆրամի դաշտերի «կախարդանքը» մեզ կայուն հաղորդակցություն է ապահովում: Եվ միայն OpenStack-ը երբեմն դառնում է քմահաճ՝ գոռալով նման բան. «WSREP-ը դեռ չի պատրաստել հանգույցը հավելվածի օգտագործման համար»: Բայց դա բոլորովին այլ պատմություն է...
Մենք վերջերս գործարկեցինք ծառայությունը:
Բոլոր մանրամասներին կարող եք ծանոթանալ մեր կայքում .
CLO զարգացման թիմ
Օգտակար հղումներ
OpenStack
Վոլֆրամի գործվածք
Source: www.habr.com