Միկրոծառայությունների ավտոմատացված փորձարկում Docker-ում շարունակական ինտեգրման համար

Միկրոծառայությունների ճարտարապետության զարգացման հետ կապված նախագծերում CI/CD-ն անցում է կատարում հաճելի հատկանիշի կատեգորիայից հրատապ անհրաժեշտության կատեգորիա: Ավտոմատացված թեստավորումը շարունակական ինտեգրման անբաժանելի մասն է, որի ճիշտ մոտեցումը կարող է թիմին տալ բազմաթիվ հաճելի երեկոներ ընտանիքի և ընկերների հետ: Հակառակ դեպքում, նախագիծը երբեք չի ավարտվի:

Հնարավոր է ամբողջ միկրոսպասարկման կոդը ծածկել միավորի թեստերով կեղծ օբյեկտներով, բայց դա միայն մասամբ լուծում է խնդիրը և թողնում է բազմաթիվ հարցեր և դժվարություններ, հատկապես տվյալների հետ աշխատանքը փորձարկելիս: Ինչպես միշտ, ամենահրատապն են տվյալների համապատասխանության փորձարկումը հարաբերական տվյալների բազայում, ամպային ծառայությունների հետ աշխատանքի փորձարկումը և սխալ ենթադրությունները՝ ծաղրական օբյեկտներ գրելիս:

Այս ամենը և մի փոքր ավելին կարելի է լուծել՝ փորձարկելով ամբողջ միկրոսերվիսը Docker կոնտեյներով: Թեստի վավերականությունն ապահովելու ակնհայտ առավելությունն այն է, որ նույն Docker պատկերները, որոնք արտադրվում են, փորձարկվում են:

Այս մոտեցման ավտոմատացումը ներկայացնում է մի շարք մարտահրավերներ, որոնց լուծումները կնկարագրվեն ստորև.

• Զուգահեռ առաջադրանքների կոնֆլիկտներ մեկ դոկերի հոսթում;
• տվյալների բազայում նույնացուցիչների կոնֆլիկտները թեստային կրկնությունների ժամանակ.
• սպասել միկրոծառայությունների պատրաստ լինելուն.
• տեղեկամատյանների համակցում և դուրս բերում արտաքին համակարգեր;
• ելքային HTTP հարցումների փորձարկում;
• վեբ վարդակների փորձարկում (օգտագործելով SignalR);
• OAuth վավերացման և թույլտվության փորձարկում:

Այս հոդվածը հիմնված է իմ ելույթը SECR 2019-ում: Այսպիսով, նրանց համար, ովքեր չափազանց ծույլ են կարդալու համար, Ներկայացնում ենք կատարման ձայնագրությունը.

Այս հոդվածում ես ձեզ կասեմ, թե ինչպես օգտագործել սկրիպտը՝ փորձարկվող ծառայությունը գործարկելու համար, տվյալների բազան և Amazon AWS ծառայությունները Docker-ում, այնուհետև թեստավորել Postman-ի վրա, և դրանց ավարտից հետո դադարեցնել և ջնջել ստեղծված բեռնարկղերը։ Թեստերը կատարվում են ամեն անգամ, երբ կոդը փոխվում է: Այս կերպ մենք համոզվում ենք, որ յուրաքանչյուր տարբերակ ճիշտ է աշխատում AWS տվյալների բազայի և ծառայությունների հետ:

Նույն սկրիպտը վարում են և՛ մշակողները՝ իրենց Windows աշխատասեղաններում, և՛ Gitlab CI սերվերը Linux-ում:

Որպեսզի նոր թեստերի իրականացումը հիմնավորված լինի, այն չպետք է պահանջի լրացուցիչ գործիքների տեղադրում ո՛չ մշակողի համակարգչում, ո՛չ էլ սերվերի վրա, որտեղ թեստերը կատարվում են կատարելիս: Docker-ը լուծում է այս խնդիրը:

Թեստը պետք է աշխատի տեղական սերվերի վրա հետևյալ պատճառներով.

• Ոչ մի ցանց լիովին հուսալի չէ: Հազար խնդրանքներից մեկը կարող է ձախողվել.
  Այս դեպքում ավտոմատ թեստը չի անցնի, աշխատանքը կդադարի, և դուք ստիպված կլինեք պատճառը փնտրել տեղեկամատյաններում;
• Չափազանց հաճախակի հարցումները չեն թույլատրվում երրորդ կողմի որոշ ծառայությունների կողմից:

Բացի այդ, խորհուրդ չի տրվում օգտագործել ստենդը, քանի որ.

• Դա ոչ միայն ստենդի վրա աշխատող վատ կոդը է, որը կարող է կոտրել այն, այլև այն տվյալները, որոնք ճիշտ կոդը չի կարող մշակել.
• Անկախ նրանից, թե որքան էլ մենք փորձենք ետ բերել թեստի կողմից կատարված բոլոր փոփոխությունները հենց թեստի ընթացքում, ինչ-որ բան կարող է սխալ լինել (հակառակ դեպքում, ո՞րն է թեստի իմաստը):

Ծրագրի և գործընթացի կազմակերպման մասին

Մեր ընկերությունը մշակել է միկրոսերվիսային վեբ հավելված, որն աշխատում է Docker-ում Amazon AWS ամպում: Նախագիծն արդեն օգտագործել էր միավորի թեստեր, բայց հաճախ կային սխալներ, որոնք միավորի թեստերը չէին հայտնաբերել: Անհրաժեշտ էր փորձարկել մի ամբողջ միկրոսերվիս տվյալների բազայի և Amazon ծառայությունների հետ միասին։

Նախագիծն օգտագործում է ստանդարտ շարունակական ինտեգրման գործընթաց, որը ներառում է միկրոծառայության փորձարկում յուրաքանչյուր ստանձնման հետ: Առաջադրանք նշանակելուց հետո ծրագրավորողը փոփոխություններ է կատարում միկրոսերվիսում, ձեռքով փորձարկում և կատարում է բոլոր հասանելի ավտոմատ թեստերը: Անհրաժեշտության դեպքում մշակողը փոխում է թեստերը: Եթե ​​որևէ խնդիր չի հայտնաբերվել, ապա պարտավորություն է կատարվում այս առաջադրանքի ճյուղին: Յուրաքանչյուր commit-ից հետո թեստերը ավտոմատ կերպով գործարկվում են սերվերի վրա: Միաձուլվել ընդհանուր ճյուղին և դրա վրա ավտոմատ թեստերի մեկնարկը տեղի է ունենում հաջող վերանայումից հետո: Եթե ​​ընդհանուր մասնաճյուղի թեստերն անցնեն, ծառայությունը ավտոմատ կերպով թարմացվում է Amazon Elastic Container Service-ի (փորձարկման մահճակալ) փորձարկման միջավայրում: Ստենդը անհրաժեշտ է բոլոր մշակողների և փորձարկողների համար, և այն կոտրելն անցանկալի է։ Այս միջավայրում փորձարկողները փորձարկում են ուղղում կամ նոր գործառույթ՝ գործարկելով ձեռքով թեստեր:

Ծրագրի ճարտարապետություն

Հավելվածը բաղկացած է տասից ավելի ծառայություններից։ Դրանցից մի քանիսը գրված են .NET Core-ում, իսկ որոշները՝ NodeJs-ում: Յուրաքանչյուր ծառայություն աշխատում է Docker կոնտեյներով Amazon Elastic Container Service-ում: Յուրաքանչյուր ոք ունի իր Postgres տվյալների բազան, իսկ ոմանք ունեն նաև Redis: Ընդհանուր տվյալների բազաներ չկան: Եթե ​​մի քանի ծառայությունների կարիք ունեն նույն տվյալները, ապա այդ տվյալները փոփոխման պահին փոխանցվում են այս ծառայություններից յուրաքանչյուրին SNS (Simple Notification Service) և SQS (Amazon Simple Queue Service) միջոցով, և ծառայությունները դրանք պահպանում են իրենց առանձին տվյալների բազայում:

SQS և SNS

SQS-ը թույլ է տալիս հաղորդագրություններ դնել հերթի մեջ և կարդալ հաղորդագրությունները հերթից՝ HTTPS-ի միջոցով:

Եթե ​​մի քանի ծառայություններ կարդում են մեկ հերթ, ապա յուրաքանչյուր հաղորդագրություն գնում է դրանցից միայն մեկին: Սա օգտակար է նույն ծառայության մի քանի օրինակներ գործարկելու ժամանակ՝ բեռը նրանց միջև բաշխելու համար:

Եթե ​​ցանկանում եք, որ յուրաքանչյուր հաղորդագրություն առաքվի մի քանի ծառայությունների, յուրաքանչյուր ստացող պետք է ունենա իր սեփական հերթը, և SNS-ն անհրաժեշտ է հաղորդագրությունները մի քանի հերթերի կրկնօրինակելու համար:

SNS-ում ստեղծում եք թեմա և բաժանորդագրվում դրան, օրինակ՝ SQS հերթ։ Դուք կարող եք հաղորդագրություններ ուղարկել թեմայում: Այս դեպքում հաղորդագրությունն ուղարկվում է այս թեմային բաժանորդագրված յուրաքանչյուր հերթին: SNS-ը հաղորդագրություններ կարդալու մեթոդ չունի: Եթե ​​Ձեզ անհրաժեշտ է իմանալ, թե ինչ է ուղարկվում SNS-ին վրիպազերծման կամ փորձարկման ժամանակ, կարող եք ստեղծել SQS հերթ, բաժանորդագրվել այն ցանկալի թեմային և կարդալ հերթը:

API Gateway

Ծառայությունների մեծ մասը ուղղակիորեն հասանելի չէ ինտերնետից: Մուտքն ապահովվում է API Gateway-ի միջոցով, որը ստուգում է մուտքի իրավունքները: Սա նաև մեր ծառայությունն է, և դրա համար նույնպես կան թեստեր:

Իրական ժամանակի ծանուցումներ

Հավելվածը օգտագործում է SignalRօգտատիրոջ ծանուցումները իրական ժամանակում ցուցադրելու համար: Սա իրականացվում է ծանուցման ծառայությունում: Այն հասանելի է անմիջապես համացանցից և աշխատում է հենց OAuth-ի հետ, քանի որ պարզվեց, որ անիրագործելի է ինտեգրել Web Sockets-ի աջակցությունը Gateway-ին՝ համեմատած OAuth-ի և ծանուցման ծառայության ինտեգրման հետ:

Փորձարկման հայտնի մոտեցում

Միավոր թեստերը փոխարինում են տվյալների բազայի նման բաները կեղծ օբյեկտներով: Եթե ​​միկրոսերվիսը, օրինակ, փորձում է աղյուսակում գրառում ստեղծել օտար բանալիով, և այն գրառումը, որին վերաբերում է այս բանալին, գոյություն չունի, ապա հարցումը չի կարող կատարվել: Միավոր թեստերը չեն կարող դա հայտնաբերել:

В հոդված Microsoft-ից Առաջարկվում է օգտագործել հիշողության տվյալների բազա և իրականացնել կեղծ օբյեկտներ։

Հիշողության տվյալների բազան այն DBMS-ներից մեկն է, որն աջակցում է Entity Framework-ը: Այն ստեղծված է հատուկ թեստավորման համար։ Նման տվյալների բազայում տվյալները պահվում են միայն այնքան ժամանակ, մինչև այն օգտագործող գործընթացն ավարտվի: Այն չի պահանջում աղյուսակների ստեղծում և չի ստուգում տվյալների ամբողջականությունը:

Ծաղրական օբյեկտները մոդելավորում են դասը, որը նրանք փոխարինում են միայն այնքանով, որքանով թեստային մշակողը հասկանում է, թե ինչպես է այն աշխատում:

Ինչպես անել, որ Postgres-ը ավտոմատ կերպով գործարկվի և կատարի միգրացիաներ, երբ թեստն ավարտված է, նշված չէ Microsoft-ի հոդվածում: Իմ լուծումը դա անում է, և բացի այդ, միկրոսերվիսին ոչ մի կոդ չի ավելացվում հատուկ թեստերի համար:

Անցնենք լուծմանը

Մշակման գործընթացում պարզ դարձավ, որ միավորի թեստերը բավարար չեն բոլոր խնդիրները ժամանակին գտնելու համար, ուստի որոշվեց այս հարցին մոտենալ այլ տեսանկյունից:

Թեստային միջավայրի ստեղծում

Առաջին խնդիրը թեստային միջավայրի տեղակայումն է: Միկրոծառայության գործարկման համար անհրաժեշտ քայլերն են.

• Կազմաձևեք փորձարկվող ծառայությունը տեղական միջավայրի համար. շրջակա միջավայրի փոփոխականները նշում են տվյալների բազայի և AWS-ին միանալու մանրամասները.
• Սկսեք Postgres-ը և գործարկեք միգրացիան՝ գործարկելով Liquibase-ը:
  Հարաբերական DBMS-ում, նախքան տվյալների բազայում տվյալները գրելը, դուք պետք է ստեղծեք տվյալների սխեման, կամ, ավելի պարզ ասած, աղյուսակ: Հավելվածը թարմացնելիս աղյուսակները պետք է բերվեն նոր տարբերակով օգտագործվող ձևով, ցանկալի է՝ առանց տվյալների կորստի: Դա կոչվում է միգրացիա: Ի սկզբանե դատարկ տվյալների բազայում աղյուսակների ստեղծումը միգրացիայի հատուկ դեպք է: Միգրացիան կարող է ներկառուցվել հենց հավելվածի մեջ: Ե՛վ .NET-ը, և՛ NodeJS-ն ունեն միգրացիոն շրջանակներ: Մեր դեպքում, անվտանգության նկատառումներից ելնելով, միկրոսերվիսներին չի թույլատրվում փոխել տվյալների սխեման, և միգրացիան իրականացվում է Liquibase-ի միջոցով։
• Գործարկեք Amazon LocalStack-ը: Սա AWS ծառայությունների իրականացումն է՝ ինքնուրույն աշխատելու համար: Docker Hub-ում LocalStack-ի համար պատրաստի պատկեր կա։
• Գործարկեք սկրիպտը՝ LocalStack-ում անհրաժեշտ սուբյեկտները ստեղծելու համար: Shell սկրիպտներն օգտագործում են AWS CLI:

Նախագծի վրա փորձարկման համար օգտագործվում է Փոստատար. Այն նախկինում կար, բայց այն գործարկվեց ձեռքով և օգտագործվեց ստենդի վրա արդեն տեղադրված հավելվածը փորձարկելու համար: Այս գործիքը թույլ է տալիս կատարել կամայական HTTP(S) հարցումներ և ստուգել՝ արդյոք պատասխանները համապատասխանում են սպասելիքներին: Հարցումները միավորվում են հավաքածուի մեջ, և ամբողջ հավաքածուն կարող է գործարկվել:

Ինչպե՞ս է աշխատում ավտոմատացված թեստը:

Փորձարկման ընթացքում Docker-ում ամեն ինչ աշխատում է՝ փորձարկվող ծառայությունը, Postgres-ը, միգրացիոն գործիքը և Postman-ը, ավելի ճիշտ՝ դրա կոնսոլային տարբերակը՝ Newman-ը:

Docker-ը լուծում է մի շարք խնդիրներ.

• Անկախություն հյուրընկալող կոնֆիգուրացիայից;
• Կախվածությունների տեղադրում. Docker-ը նկարներ է ներբեռնում Docker Hub-ից;
• Համակարգի սկզբնական վիճակի վերակայում. պարզապես ջնջեք բեռնարկղերը:

Docker-կազմել միավորում է կոնտեյներները ինտերնետից մեկուսացված վիրտուալ ցանցի մեջ, որտեղ կոնտեյներները գտնում են միմյանց դոմենային անուններով:

Թեստը վերահսկվում է shell script-ով: Windows-ի տակ թեստն իրականացնելու համար մենք օգտագործում ենք git-bash: Այսպիսով, մեկ սկրիպտը բավական է և՛ Windows-ի, և՛ Linux-ի համար։ Git-ը և Docker-ը տեղադրվում են նախագծի բոլոր մշակողների կողմից: Երբ դուք տեղադրում եք Git-ը Windows-ում, տեղադրվում է git-bash-ը, այնպես որ բոլորը դա նույնպես ունեն:

Սցենարը կատարում է հետևյալ քայլերը.

• Docker պատկերների կառուցում

  docker-compose build

• DB-ի և LocalStack-ի գործարկում

  docker-compose up -d <контейнер>

• Տվյալների բազայի տեղափոխում և LocalStack-ի պատրաստում

  docker-compose run <контейнер>

• Ծառայության գործարկումը փորձարկման փուլում

  docker-compose up -d <сервис>

• Թեստի անցկացումը (Newman)
• Դադարեցրեք բոլոր բեռնարկղերը

  docker-compose down

• Արդյունքների տեղադրում Slack-ում
  Մենք ունենք զրույց, որտեղ ուղարկվում են կանաչ նշանով կամ կարմիր խաչով հաղորդագրություններ և հղում դեպի մատյան:

Այս քայլերը ներառում են հետևյալ Docker պատկերները.

• Փորձարկվող ծառայությունը նույն պատկերն է, ինչ արտադրության համար: Թեստի կոնֆիգուրացիան իրականացվում է շրջակա միջավայրի փոփոխականների միջոցով:
• Postgres-ի, Redis-ի և LocalStack-ի համար օգտագործվում են պատրաստի պատկերներ Docker Hub-ից: Կան նաև պատրաստի պատկերներ Liquibase-ի և Newman-ի համար։ Մենք կառուցում ենք մեր սեփականը նրանց կմախքի վրա՝ ավելացնելով մեր ֆայլերը այնտեղ:
• LocalStack-ը տրամադրելու համար դուք օգտագործում եք նախապես կառուցված AWS CLI պատկեր և ստեղծում եք դրանից սկրիպտ պարունակող պատկեր:

Օգտագործելով ծավալները, պարզապես անհրաժեշտ չէ Docker պատկեր ստեղծել՝ կոնտեյների մեջ ֆայլեր ավելացնելու համար: Այնուամենայնիվ, ծավալները հարմար չեն մեր միջավայրի համար, քանի որ Gitlab CI առաջադրանքներն իրենք աշխատում են բեռնարկղերում: Դուք կարող եք կառավարել docker-ը նման կոնտեյներից, բայց հատորները տեղադրում են թղթապանակներ միայն հյուրընկալող համակարգից, այլ ոչ այլ կոնտեյներից:

Խնդիրներ, որոնց կարող եք հանդիպել

Սպասում է պատրաստակամության

Երբ ծառայության հետ կոնտեյներ է աշխատում, դա չի նշանակում, որ այն պատրաստ է միացումներ ընդունելու: Դուք պետք է սպասեք, որ կապը շարունակվի:

Այս խնդիրը երբեմն լուծվում է սցենարի օգնությամբ։ սպասիր.շ, որը սպասում է TCP կապ հաստատելու հնարավորության։ Այնուամենայնիվ, LocalStack-ը կարող է վերադարձնել 502 Bad Gateway սխալ: Բացի այդ, այն բաղկացած է բազմաթիվ ծառայություններից, և եթե դրանցից մեկը պատրաստ է, ապա դա ոչինչ չի նշանակում մյուսների մասին։

որոշումLocalStack-ի պատրաստման սկրիպտներ, որոնք սպասում են 200 պատասխանի և՛ SQS-ից, և՛ SNS-ից:

Զուգահեռ առաջադրանքների կոնֆլիկտներ

Բազմաթիվ թեստեր կարող են միաժամանակ գործարկվել մեկ Docker հոսթի վրա, ուստի կոնտեյների և ցանցի անունները պետք է եզակի լինեն: Ավելին, նույն ծառայության տարբեր ճյուղերի թեստերը նույնպես կարող են միաժամանակ աշխատել, ուստի յուրաքանչյուր կոմպոզիցիոն ֆայլում իրենց անունները գրելը բավարար չէ:

որոշում: սկրիպտը եզակի արժեք է սահմանում COMPOSE_PROJECT_NAME փոփոխականի համար:

Windows-ի առանձնահատկությունները

Windows-ում Docker-ն օգտագործելիս կան մի քանի բաներ, որոնք ես ուզում եմ նշել, քանի որ այս փորձը կարևոր է սխալների պատճառները հասկանալու համար:

1. Շելլ սկրիպտները կոնտեյներով պետք է ունենան Linux տողերի վերջավորություններ:
   Կեղևի CR խորհրդանիշը շարահյուսական սխալ է: Սխալի հաղորդագրությունից դժվար է ասել, որ դա է խնդիրը: Windows-ում նման սցենարներ խմբագրելիս անհրաժեշտ է համապատասխան տեքստային խմբագրիչ: Բացի այդ, տարբերակների կառավարման համակարգը պետք է ճիշտ կազմաձևվի:

git-ը կազմաձևված է հետևյալ կերպ.

git config core.autocrlf input

1. Git-bash-ը ընդօրինակում է Linux-ի ստանդարտ թղթապանակները և փոխարինում է բացարձակ Linux-ի ուղիները Windows-ի ուղիներով՝ exe ֆայլ (ներառյալ docker.exe) կանչելիս: Այնուամենայնիվ, սա իմաստ չունի այն ուղիների համար, որոնք չեն գտնվում տեղական մեքենայի վրա (կամ ուղիները կոնտեյներով): Այս պահվածքը հնարավոր չէ անջատել:

որոշումերթուղու սկզբին ավելացրեք լրացուցիչ կտրվածք. //bin /bin-ի փոխարեն: Linux-ը հասկանում է նման ուղիները, քանի որ նրա համար մի քանի շեղերը նույնն են, ինչ մեկը: Բայց git-bash-ը չի ճանաչում նման ուղիները և չի փորձում դրանք փոխակերպել։

Տեղեկամատյանների ելք

Թեստերն աշխատելիս ես կցանկանայի տեսնել ինչպես Նյումանի, այնպես էլ ծառայության տեղեկամատյանները, որոնք փորձարկվում են: Քանի որ այս տեղեկամատյանների իրադարձությունները կապված են միմյանց հետ, դրանք մեկ վահանակում միավորելը շատ ավելի հարմար է, քան երկու առանձին ֆայլեր։ Նյումանը սկսում է ներս docker compose run, և դրա ելքը գնում է կոնսոլ: Մնում է միայն համոզվել, որ ծառայության ելքը նույնպես հասնում է այնտեղ:

Նախնական որոշումը եղել է անել docker կազմել առանց դրոշի -d, բայց օգտագործելով shell-ի հնարավորությունները, ուղարկեք այս գործընթացը հետին պլան.

docker-compose up <service> &

Սա աշխատեց այնքան ժամանակ, մինչև որ անհրաժեշտություն առաջացավ Docker-ից տեղեկամատյաններ ուղարկել երրորդ կողմի ծառայությանը: docker կազմել դադարեցրեց տեղեկամատյանների թողարկումը վահանակ: Այնուամենայնիվ, թիմն աշխատեց docker կցել.

որոշում:

docker attach --no-stdin ${COMPOSE_PROJECT_NAME}_<сервис>_1 &

Նույնացուցիչի հակամարտությունը թեստային կրկնությունների ժամանակ

Թեստերն անցկացվում են բազմակի կրկնություններով: Հիմքը մաքրված չէ։ Տվյալների բազայի գրառումներն ունեն եզակի ID-ներ: Եթե ​​հարցումներում գրեք կոնկրետ ID-ներ, ապա երկրորդ կրկնության դեպքում հակասություն կստանաք:

Սրանից խուսափելու համար կա՛մ ID-ները պետք է եզակի լինեն, կա՛մ թեստի միջոցով ստեղծված բոլոր օբյեկտները պետք է ջնջվեն: Որոշ օբյեկտներ չեն կարող ջնջվել պահանջների պատճառով:

որոշումՍտեղծեք GUID-ներ սկրիպտներով Postman-ում:

var uuid = require('uuid');
var myid = uuid.v4();
pm.environment.set('myUUID', myid);

Այնուհետև օգտագործեք նշանը ձեր հարցման մեջ {{myUUID}}, որը կփոխարինվի փոփոխականի արժեքով։

Փոխազդեցություն LocalStack-ի միջոցով

Եթե ​​ստուգվող ծառայությունը կարդում է կամ գրում է SQS հերթից, ապա թեստն ինքը պետք է աշխատի նաև այդ հերթի հետ՝ դա ստուգելու համար:

որոշումհարցումներ Փոստատարից LocalStack-ին:

AWS ծառայություններն ունեն փաստաթղթավորված API-ներ, որոնք թույլ են տալիս հարցումներ կատարել առանց SDK-ի:

Եթե ​​ծառայությունը գրում է հերթում, մենք կարդում ենք այն և ստուգում հաղորդագրության բովանդակությունը:

Եթե ​​ծառայությունը հաղորդագրություններ է ուղարկում SNS-ին, LocalStack-ի պատրաստման փուլում նույնպես ստեղծվում է հերթ և բաժանորդագրվում այս SNS թեմային: Հետո ամեն ինչ իջնում ​​է վերը նկարագրվածին։

Եթե ​​ծառայությունը կարիք ունի կարդալու հաղորդագրություն հերթից, ապա թեստի նախորդ քայլում մենք գրում ենք այս հաղորդագրությունը հերթում:

Փորձարկվող HTTP հարցումները, որոնք ստացվում են փորձարկվող միկրոսերվիսից

Որոշ ծառայություններ HTTP-ի միջոցով շփվում են այլ բաների հետ, բացի AWS-ից, և AWS-ի որոշ առանձնահատկություններ չեն ներդրված LocalStack-ում:

որոշումԱյս դեպքերում դա կարող է օգնել MockServer, որն ունի պատրաստի պատկեր է Docker հանգույց. Ակնկալվող հարցումները և դրանց պատասխանները կազմաձևվում են HTTP հարցումով: API-ն փաստաթղթավորված է, ուստի մենք հարցումներ ենք անում փոստատարից:

OAuth վավերացման և թույլտվության փորձարկում

Մենք օգտագործում ենք OAuth և JSON Web Tokens (JWT). Թեստի համար մեզ անհրաժեշտ է OAuth մատակարար, որը մենք կարող ենք լոկալ գործարկել:

Ծառայության և OAuth մատակարարի միջև բոլոր փոխազդեցությունները կրճատվել են մինչև երկու հարցում. նախ՝ կոնֆիգուրացիան պահանջվում է /.լավ հայտնի/openid-configuration, և այնուհետև կոնֆիգուրացիայից հասցեում պահանջվում է հանրային բանալին (JWKS): Այս ամենը ստատիկ բովանդակություն է։

որոշումՄեր փորձնական OAuth մատակարարը ստատիկ բովանդակության սերվեր է և դրա վրա երկու ֆայլ: Նշանը ստեղծվում է մեկ անգամ և հանձնվում է Git-ին:

SignalR թեստավորման առանձնահատկությունները

Փոստատարը չի աշխատում վեբ վարդակների հետ: SignalR-ի փորձարկման համար ստեղծվել է հատուկ գործիք։

SignalR հաճախորդները կարող են լինել ցանկացած բան՝ բրաուզերից մինչև հաճախորդ: Դրա համար կա հաճախորդի գրադարան .NET Core-ի համար: .NET Core-ում գրված հաճախորդը կապ է հաստատում, վավերացնում և սպասում է հաղորդագրությունների որոշակի հաջորդականությանը: Եթե ​​ստացվում է անսպասելի հաղորդագրություն կամ կապը խզվում է, հաճախորդն ավարտվում է 1 կոդով: Եթե ստացվում է վերջին սպասված հաղորդագրությունը, այն ավարտվում է 0 կոդով:

Նյումանը միաժամանակ աշխատում է հաճախորդի հետ։ Մի քանի հաճախորդներ գործարկվում են՝ ստուգելու, որ հաղորդագրությունները առաքվում են բոլորին, ովքեր դրանց կարիքն ունեն:

Մի քանի հաճախորդներ գործարկելու համար օգտագործեք տարբերակը -- մասշտաբ docker-compose հրամանի տողում:

Նախքան Postman-ը սկսելը, սցենարը սպասում է, որ բոլոր հաճախորդները կապ հաստատեն:
Մենք արդեն բախվել ենք կապի սպասելու խնդրին։ Բայց այնտեղ սերվերներ կային, և ահա հաճախորդը: Այլ մոտեցում է պետք։

որոշումՀաճախորդը կոնտեյներով օգտագործում է մեխանիզմը Առողջությունտեղեկացնել հաղորդավար սկրիպտին իր կարգավիճակի մասին: Հաճախորդը ստեղծում է ֆայլ որոշակի ճանապարհով, ասենք /healthcheck, երբ կապը հաստատվի: Docker ֆայլում HealthCheck սցենարը հետևյալն է.

HEALTHCHECK --interval=3s CMD if [ ! -e /healthcheck ]; then false; fi

Թիմ docker ստուգում Ցույց է տալիս կոնտեյների նորմալ կարգավիճակը, առողջական վիճակը և ելքի կոդը:

Նյումանն ավարտելուց հետո սկրիպտը ստուգում է, որ հաճախորդի հետ բոլոր բեռնարկղերը լրացված են և 0 կոդով:

Երջանկությունը գոյություն ունի

Այն բանից հետո, երբ մենք հաղթահարեցինք վերը նկարագրված դժվարությունները, մենք ունեցանք կայուն աշխատանքային թեստեր: Թեստերում յուրաքանչյուր ծառայություն աշխատում է որպես մեկ միավոր՝ շփվելով տվյալների բազայի և Amazon LocalStack-ի հետ:

Այս թեստերը պաշտպանում են 30+ ծրագրավորողների թիմին հաճախակի տեղակայման ժամանակ 10+ միկրոծառայությունների բարդ փոխազդեցությամբ հավելվածում սխալներից:

Source: www.habr.com