Docker-ում միկրոսերվիսների ավտոմատ ստուգում շարունակական ինտեգրացիայի համար

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

Միքսուսայի ամբողջ կոդը կարող է ընդգրկվել միավորը-թեստերով և մոկ-բառերով, սակայն դա միայն جزٔաք է լուծում և թողնում է բազմաթիվ հարցեր և բարդություններ, հատկապես տվյալների հետ աշխատելու թեստավորման ժամանակ: Հաճախ, ամենալուրջները՝ մեկ, տվյալների համահունչության թեստավորումը հարաբերական DB-ում, երկուսի դեպքում ամպերի ծառայությունների հետ աշխատելու թեստավորումը և սխալ ենթադրությունները մոկ-բառերի գրառման ժամանակ:

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

Այս մոտեցման ավտոմատիզացումը ներկայացնում է մի շարք խնդիրներ, որոնց լուծումն արդեն նկարագրված է բավականին քիչ որոնումներում:

• համաժամյա առաջադրանքների կոնֆլիկտներ մեկ Docker-host-ում;
• իդենտիֆիկատների կոնֆլիկտներ DB-ում թեստի ինտրացիաների ժամանակ;
• միկսուսների պատրաստության սպասումը;
• լոգերի միացում և արտահայտում արտաքին համակարգերին;
• արտաքին HTTP հարցումների թեստավորում;
• վեբ-сոկետների թեստավորում (SignalR-ի միջոցով);
• OAuth-ի ինձ հանդերձակավորում և արտադրման թեստավորում:

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

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

Նույն սցենարը կիրառվում է ինչպես ինքը ծրագրավորողները իրենց Windows-նախնականներում, այնպես էլ Gitlab CI-ի սերվերը Linux-ում:

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

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

• Ցանցը երբեք չի լինում ամբողջապես վստահելի: Մեկից հազար հարցադրումից մեկը կարող է չանցնել:
  Ավտոմատացված թեստը այս դեպքում չի անցնի, աշխատանքը կանգնելու է, պետք կլինի գտնել պատճառը լոգերում:
• Շատ հաճախակի հարցումները որոշակի արտաքին ծառայություններով չեն թույլատրվում:

Բացի այդ, պլատֆորմը ներգրավելը ցանկալի չէ, քանի որ:

• Սպասարկման ստենդը կարող է վնասվել ոչ միայն վատ կոդի պատճառով, որը աշխատում է նրա վրա, այլ նաև տվյալների պատճառով, որոնք ճիշտ կոդը չի կարող մշակել;
• Ինչքան էլ որ մենք փորձենք վերադառնալ բոլոր փոփոխություններին, որոնք կատարում է թեստը, թեստի ընթացքում ինչ-որ բան կարող է սխալ գնալ (այլապես, ինչու մենք թեսթ կպահպանենք?):

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

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

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

Ծրագրի arquitectura

Հավելվածը կազմված է ավելի քան տասը ծառայություններից: Որոշները գրված են .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 socket-ի աջակցությունը Gateway-ում ներառելու կարիք չկա, համեմատած OAuth-ի և ծանուցման ծառայության ինտեգրմանը:

Հայտնի մոտեցում թեստավորման համար

Յոնիթ-թեստերը փոխարինում են մոկ- առարկաներ, օրինակ, տվյալների սեղան: Եթե միկროსարքը, օրինակ, փորձում է ստեղծել գրառում սեղանում արտաքին բանալիով, իսկ այդ բանալիով կապվող գրառումները չկան, ապա հարցումը չի կարող կատարվել: Յոնիթ-թեստերը չեն կարող դա բացահայտել:

Մեույն Մայքրոսոֆտի հոդվածում եւ առաջարկվում է օգտագործել in-memory տվյալների բազա և ներառել մոկ-առարկաներ:

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

Մոկ-առարկաները մոդելավորում են փոխարինվող դասը միայն այնքան, որքան որ թեստի մշակողը հասկանում է դրա աշխատանքը:

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

Ամփոփելով լուծումը

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

Թեստային միջավայրի կարգավորում

Առաջին խնդիրը՝ ձևավորել թեստային միջավայրը: Փուլերը, որոնք անհրաժեշտ են միկրոսպասարկման մեկնարկի համար՝

• Կարգավորել փորձարկվող ծառայությունը տեղական միջավայրում, միջավայրի փոփոխականներում նշվում են տվյալների բազայի և AWS-ի միացման տվյալները;
• Արդեն սկսել Postgres-ը և կատարել միգրացիան, գործարկել Liquibase-ը:
  Ռելացիոն DBMS-ներում, նախքան տվյալները տվյալների հետագայում գրելը, անհրաժեշտ է ստեղծել տվյալների սխեմա, այսինքն՝ աղյուսակներ: Գործողությունների կիրառման ժամանակ աղյուսակները պետք է բացահայտվեն նոր տարբերակին համապատասխան, և ցանկալի է, որ տվյալները պահպանվեն: Այս գործընթացը կոչվում է միգրացիա: Աղյուսակների ստեղծումը սկզբնական դատարկ տվյալների բազայում՝ միգրացիայի մասնավոր դեպք է: Միգրացիան կարելի է ներգրավել դյուրին կերպով ինքն uygulamasında: Չնայած .NET-геและ NodeJS-ге առկա են միգրացիայի շրջանակներ: Մեր դեպքում անվտանգության նկատառումներից ելնելով, միկրոսերվիսները զրկված են տվյալների սխեման փոխելու իրավունքից, և միգրացիան իրականացվում է Liquibase-ի միջոցով.
• Запуск Amazon LocalStack. Это реализация сервисов AWS для запуска у себя. Для LocalStack есть готовый образ в Docker Hub.
• Запустить скрипт для создания в LocalStack необходимых сущностей. Shell-скрипты используют AWS CLI.

Для тестирования на проекте используется . Postman-ը ունի աշխատասեղանի տարբերակներ Windows, Linux և MacOS համար: Դրա կողքին կա Google Chrome-ի պլագին: Մենք կօգտագործենք հենց այս ծրագիրը: Նախ պետք է որոնել Postman-ը Google Chrome Store-ում և տեղադրել այն:. Он был и раньше, но его запускали вручную и тестировали приложение, уже развернутое на стенде. Этот инструмент позволяет делать произвольные HTTP(S)-запросы и проверять соответствие ответов ожиданиям. Запросы объединяются в коллекцию, и можно запустить всю коллекцию целиком.

Как устроен автоматический тест

Во время теста в Docker работает все: и тестируемый сервис, и Postgres, и инструмент для миграции, и Postman, а, вернее, его консольная версия – Newman.

Docker решает целый ряд проблем:

• Независимость от конфигурации хоста;
• Установка зависимостей: докер скачивает образы с Docker Hub;
• Возврат системы в исходное состояние: просто удаляем контейнеры.

Docker-compose объединяет контейнеры в виртуальную сеть, изолированную от интернета, в которой контейнеры находят друг друга по доменным именам.

Тестом управляет shell-скрипт. Для запуска теста под Windows используем git-bash. Таким образом, достаточно одного скрипта и для Windows и для Linux. Git и Docker установлены у всех разработчиков на проекте. При установке Git под Windows устанавливается git-bash, так что он тоже у всех есть.

Скрипт выполняет следующие шаги:

• Построение докер-образов

  docker-compose build

• Запуск БД и 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-ը, սակայն ծավալները միայն տեղադրում են գրոցներ հյուրընկալող համակարգից, այլ ոչ թե մեկ այլ սարքից:

Խնդիրներ, որոնցով կարող ենք բախվել

Պատրաստության սպասում

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

Այս առաջադրանքը որոշ ժամանակներին լուծվում է սքրիպտի միջոցով wait-for-it.sh, որը սպասում է TCP միացման հաստատմանը: Սակայն LocalStack-ը կարող է արտագրել 502 Bad Gateway սխալի: Բացի այդ, այն բաղկացած է բազմաթիվ ծառայություններից, և եթե մեկը պատրաստ է, դա ոչինչ չի ասում մյուսների մասին:

Լուծում: LocalStack-ի պատրաստման սքրիպտներ, որոնք սպասում են 200 պատասխան հավաքելու SQS-ից և SNS-ից:

Նկարագրերի հակամարտություններ

Մի քանի թեստեր կարող են միաժամանակ աշխատել մեկ Docker հյուրընկալում, ուստի հարուստները և ցանցերը պետք են լինել եզակի: Ուստի, ծառայությունների տարբեր բոքերում գտնվող թեստերը նույնպես կարող են միաժամանակ աշխատել, ուստի բավարար չէ յուրաքանչյուր compose-թղթապանակի մեջ սեփական անունները գրել:

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

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

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

1. Սքրիպտները սարքում պետք է լինեն Linux-ի վերջնական ավարտով:
   شل լոգո CR-ն սխալ է: Ошибку сложно понять, что проблема в этом. Когда редактируете такие скрипты в Windows, нужен правильный текстовый редактор. Кроме того, система контроля версий должна быть настроена должным образом:

Вот так настраивается git:

git config core.autocrlf input

1. Git-bash эмулирует стандартные папки Linux при вызове exe-файла (в том числе docker.exe) заменяет абсолютные Linux-пути на Windows-пути. Однако это не имеет смысла для путей, не на локальной машине (или путей в контейнере). Такое поведение не отключается:

Լուծում: добавляет дополнительный слэш в начало пути: \/\/bin вместо \/bin. Linux понимает такие пути, для него несколько слэшей – то же, что один. Но git-bash такие пути не распознаёт и не пытается преобразовывать.

Լոգերի ելքեր

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

Պարունակային լուծումը բաղկացած էր նրանից, որպեսզի կատարել docker-compose up без флага -d, սակայն օգտագործելով շելլի հնարավորությունները, ուղարկել գործընթացը ֆոնային:

docker-compose up  &

Այսպիսի գործել ձևով, մինչև անհրաժեշտություն ստեղծվեց ուղարկել լոգերը դոկերից արտաքին ծառայություն: docker-compose up դադարեցրեց լոգերը կոնսոլում ցուցադրել։ Սակայն աշխատում էր հրաման docker attach.

Լուծում:

docker attach --no-stdin ${COMPOSE_PROJECT_NAME}__1 &

ID-ների հակասությունը թեստավորման ժամանակ

Թեստերը աշխատում են մի քանի հավաքներ։ Bases-ը չի մաքրվում։ Գրանցվածները ունեն յուրահատուկ ID-ներ։ Եթե հատուկ ID-ներ գրանցվեն запросներում, երկրորդ հավաքի ժամանակ կստանանք հակասություն։

Եթե վերջինը չլինի, ID-ներն պետք է լինեն յուրահատուկ կամ անհրաժեշտ է ջնջել բոլոր օբյեկտները, որոնք ստեղծում է թեստը։ Նույնիսկ որոշ օբյեկտներ ջնջել չի կարելի՝ պահանջների համաձայն։

Լուծում: ստեղծել GUID-ներ Postman-ով սկրիպտներով։

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

Այնուհետև запросում օգտագործելու նշանը {{myUUID}}, որը կհամապատասխանի փոփոխականի արժեքին։

Ագակցություն LocalStack-ով

Եթե փորձարկվող ծառայությունը SQS հերթ queues է ընթերցում կամ գրում, ապա դրա գործիքները նույնպես պետք է աշխատել այդ հերթում։

Լուծում: запросները Postman-ից LocalStack-ով.

AWS ծառայությունների API-ը փաստաթղթավորված է, ինչը թույլ է տալիս անել запросներ առանց SDK-ի։

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

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

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

Թեստավորում HTTP-запросների, որոնք դուրս են գալիս փորձարկվող միկրոսերվիսից

Որոշ ծառայություններ աշխատում են HTTP-ով ոչ AWS-ի հետ, և որոշ AWS ֆունկցիաներ չեն իրականացվում LocalStack-ով։

Լուծում: այդ դեպքերում կարող է օգնել MockServer, որն ունի պատրաստի նկարագրություն Docker Hub. Ապակողմնորոշված запросներ և դրանց ի պատասխան տեղադրվում են HTTP запросով։ API-ն փաստաթղթավորված է, դրա համար запросներ ենք անում Postman-ից։

OAuth-ի վավերացում և իրավունքների ստուգում

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

Ամբողջ շփումը ծառայության և OAuth մատակարարի միջև սահմանափակվում է երկու запросով․ նախ խնդրվում է կոնֆիգուրացիան /.well-known/openid-configuration, իսկ հետո հանրային բանալին (JWKS) խնդրվում է կոնֆիգուրացիայից։ Ամեն ինչ այսու.static առաջինն երկարաձգում։

Լուծում: մեր թեստային OAuth մատակարարը static կոնտենթի սերվերն է և երկու ֆայլերը, որոնք գործում են նրա մեջ։ Բանալին ստեղծվում է մեկ անգամ և գրանցվում Git-ում։

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

Վեբ-սոկետների հետ Postman-ը չի աշխատում։ SignalR-ի թեստավորման համար ստեղծվել է հատուկ գործիք։

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

Երբեք հաճախորդի հետ միաժամանակ աշխատում է Newman։ Դրանք մեկնարկվում են մի քանիսը, որպեսզի ստուգեն, որ հաղորդագրությունները դիմավորում են բոլորին, ում պետք է։

Որոշ հաճախորդների մեկնարկելու համար օգտագործվում է —scale docker-compose հրամանային տողի օգտվողը։

Postman սցենարը սկսելուց առաջ սպասում է, որ բոլոր հաճախորդները կապ հաստատեն։
Կապի սպասման խնդիրը մեզ արդեն հանդիպել է։ Բայց այնտեղ սերվերներ էին, իսկ այստեղ հաճախորդ։ Բարեփոխման անհրաժեշտություն կա։

Լուծում: կոնտեյները հաճախորդը օգտագործում է մեխանիզմը HealthCheck, որպեսզի հաղորդի հյուրընկալող սցենարին իր վիճակը։ Հաճախորդը ստեղծում է файл որոշակի տեղի վրա, օրինակ, /healthcheck, երբ կապը հաստատվում է։ HealthCheck-սկրիպտը Docker ֆայլում տեսք ունի այսպես՝

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

Հրաման docker inspect ցույց է տալիս կոնտեյների սովորական վիճակը, health-վիճակը և ավարտման կոդը։

Newman-ը ավարտելուց հետո սցենարը ստուգում է, որ բոլոր կոնտեյները, որոնց միջև է հաճախորդը, ավարտվել են 0 կոդով։

Հաջողություն կա

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

Այս թեստերը պաշտպանում են 30+ ծրագրավորողների թիմին приложения ամենաբարդ փոխադարձությունների թեստերում 10+ միկրոցանցերով հաճախակի տեղանցումների ժամանակ։

Ընտանիք: habr.com