Тасралтгүй нэгтгэхийн тулд Docker дахь микро үйлчилгээг автоматжуулсан туршилт

Микро үйлчилгээний архитектурыг хөгжүүлэхтэй холбоотой төслүүдэд CI/CD нь таатай боломжийн ангилалаас яаралтай хэрэгцээний ангилалд шилждэг. Автоматжуулсан туршилт нь тасралтгүй интеграцийн салшгүй хэсэг бөгөөд чадварлаг арга барил нь багийг гэр бүл, найз нөхөдтэйгээ олон сайхан үдшийг өнгөрөөх боломжийг олгодог. Тэгэхгүй бол төсөл хэзээ ч дуусахгүй эрсдэлтэй.

Хуурамч объект бүхий нэгжийн тестээр микро үйлчилгээний кодыг бүхэлд нь хамрах боломжтой боловч энэ нь зөвхөн асуудлыг хэсэгчлэн шийдэж, олон асуулт, бэрхшээлийг үлдээдэг, ялангуяа өгөгдөлтэй ажиллах тест хийх үед. Үргэлж л хамгийн тулгамдсан зүйл бол харилцааны мэдээллийн сан дахь өгөгдлийн нийцтэй байдлыг шалгах, үүлэн үйлчилгээтэй ажиллах тест хийх, хуурамч объект бичихдээ буруу таамаглал гаргах явдал юм.

Энэ бүгдийг болон бага зэрэг бусад асуудлыг Docker контейнерт микро үйлчилгээг бүхэлд нь туршиж үзэх замаар шийдэж болно. Туршилтын найдвартай байдлыг баталгаажуулах эргэлзээгүй давуу тал бол үйлдвэрлэлд орж буй ижил Docker зургуудыг туршиж үзэх явдал юм.

Энэхүү аргын автоматжуулалт нь хэд хэдэн асуудал үүсгэдэг бөгөөд тэдгээрийн шийдлийг доор тайлбарлах болно.

• нэг докер хост дахь зэрэгцээ даалгавруудын зөрчил;
• туршилтын давталтын үед мэдээллийн сан дахь танигчийн зөрчил;
• бичил үйлчилгээ бэлэн байхыг хүлээх;
• логуудыг гадаад системд нэгтгэх, гаргах;
• гарч буй HTTP хүсэлтийг шалгах;
• вэб залгуурын туршилт (SignalR ашиглан);
• OAuth баталгаажуулалт, зөвшөөрлийг турших.

Энэ нийтлэл дээр үндэслэсэн болно миний яриа at SECR 2019. Тиймээс уншихаас залхуурдаг хүмүүст зориулж, илтгэлийн бичлэгийг энд оруулав.

Энэ нийтлэлд би Docker дахь туршилтын үйлчилгээ, өгөгдлийн сан болон Amazon AWS үйлчилгээг ажиллуулахын тулд скриптийг хэрхэн ашиглах, дараа нь Postman дээр тест хийж, дууссаны дараа үүсгэсэн контейнеруудыг зогсоож устгах талаар танд хэлэх болно. Код өөрчлөгдөх бүрд тестүүд хийгддэг. Ингэснээр бид хувилбар бүр AWS мэдээллийн сан болон үйлчилгээтэй зөв ажиллаж байгаа эсэхийг шалгана.

Ижил скриптийг хөгжүүлэгчид өөрсдөө Windows-ийн ширээний компьютер болон Linux-ийн Gitlab CI серверээр ажиллуулдаг.

Үндэслэлтэй байхын тулд шинэ тестийг нэвтрүүлэх нь хөгжүүлэгчийн компьютер эсвэл тестийг коммит дээр ажиллуулдаг сервер дээр нэмэлт хэрэгслийг суулгах шаардлагагүй. Docker энэ асуудлыг шийддэг.

Дараах шалтгааны улмаас туршилтыг локал сервер дээр ажиллуулах ёстой.

• Сүлжээ хэзээ ч бүрэн найдвартай байдаггүй. Мянган хүсэлтээс нэг нь бүтэлгүйтэж магадгүй;
  Энэ тохиолдолд автомат туршилт ажиллахгүй, ажил зогсох бөгөөд та бүртгэлээс шалтгааныг хайх хэрэгтэй болно;
• Хэт олон удаа хүсэлт гаргахыг зарим гуравдагч талын үйлчилгээ зөвшөөрдөггүй.

Үүнээс гадна, индэр ашиглах нь зохисгүй, учир нь:

• Стенд нь зөвхөн муу код дээр ажиллаж байгаа төдийгүй зөв код боловсруулах боломжгүй өгөгдлөөр эвдэрч болно;
• Туршилтын явцад хийсэн бүх өөрчлөлтийг буцаахыг бид хичнээн хичээсэн ч ямар нэг зүйл буруу болж магадгүй (эсвэл яагаад тест хийх ёстой гэж?).

Төсөл, үйл явцын зохион байгуулалтын талаар

Манай компани Amazon AWS үүлэн дээр Docker дээр ажилладаг микро үйлчилгээний вэб программыг боловсруулсан. Төсөлд нэгжийн туршилтыг аль хэдийн ашиглаж байсан боловч нэгжийн туршилтууд илрүүлээгүй алдаа ихэвчлэн гардаг. Мэдээллийн сан болон Amazon үйлчилгээнүүдийн хамт бүхэл бүтэн микро үйлчилгээг турших шаардлагатай болсон.

Төсөл нь микросервисийг амлалт болгон туршихыг багтаасан стандарт тасралтгүй интеграцийн процессыг ашигладаг. Даалгавраа өгсний дараа хөгжүүлэгч бичил үйлчилгээнд өөрчлөлт оруулж, гараар туршиж, боломжтой бүх автоматжуулсан тестүүдийг ажиллуулдаг. Шаардлагатай бол хөгжүүлэгчид туршилтуудыг өөрчилдөг. Хэрэв ямар нэгэн асуудал олдохгүй бол энэ асуудлын салбарт үүрэг өгнө. Үйлдэл бүрийн дараа тестүүд сервер дээр автоматаар явагдана. Нийтлэг салбар болгон нэгтгэж, түүн дээр автомат туршилтуудыг эхлүүлэх нь амжилттай хянан шалгасны дараа тохиолддог. Хэрэв хуваалцсан салбар дээрх тестүүд тэнцсэн бол үйлчилгээ нь Amazon Elastic Container Service (вандан) дээрх туршилтын орчинд автоматаар шинэчлэгддэг. Тавиур нь бүх хөгжүүлэгчид болон тестерүүдэд зайлшгүй шаардлагатай бөгөөд үүнийг эвдэхийг зөвлөдөггүй. Энэ орчны тестерүүд засвар эсвэл шинэ функцийг гар аргаар шалгах замаар шалгадаг.

Төслийн архитектур

Энэхүү програм нь арав гаруй үйлчилгээнээс бүрддэг. Тэдгээрийн зарим нь .NET Core, зарим нь NodeJs дээр бичигдсэн байдаг. Үйлчилгээ бүр нь Amazon Elastic Container Service дахь Docker контейнерт ажилладаг. Тус бүр өөрийн гэсэн Postgres мэдээллийн сантай, зарим нь Redis-тэй. Нийтлэг мэдээллийн сан байхгүй байна. Хэрэв хэд хэдэн үйлчилгээнд ижил өгөгдөл шаардлагатай бол энэ өгөгдөл өөрчлөгдөх үед SNS (Энгийн мэдэгдлийн үйлчилгээ) болон SQS (Amazon Simple Queue Service) -ээр дамжуулан эдгээр үйлчилгээ тус бүрд дамждаг бөгөөд үйлчилгээнүүд үүнийг тусдаа мэдээллийн санд хадгалдаг.

SQS ба SNS

SQS нь HTTPS протоколыг ашиглан мессежийг дараалалд оруулах, дарааллаас мессеж унших боломжийг олгодог.

Хэрэв хэд хэдэн үйлчилгээ нэг дарааллыг уншвал мессеж бүр зөвхөн аль нэгэнд нь ирдэг. Энэ нь ачааллыг хооронд нь хуваарилахын тулд ижил үйлчилгээний хэд хэдэн тохиолдлыг ажиллуулахад хэрэгтэй.

Хэрэв та мессеж бүрийг олон үйлчилгээнд хүргэхийг хүсвэл хүлээн авагч бүр өөрийн гэсэн дараалалтай байх ёстой бөгөөд мессежийг олон дараалалд хуулбарлахад SNS шаардлагатай.

SNS дээр та сэдэв үүсгэж, түүнд бүртгүүлэх, жишээлбэл, SQS дараалал. Та сэдэв рүү мессеж илгээх боломжтой. Энэ тохиолдолд мессежийг энэ сэдэвт бүртгүүлсэн дараалал бүрт илгээдэг. SNS-д мессеж унших арга байхгүй. Хэрэв дибаг хийх эсвэл тест хийх явцад SNS руу юу илгээгдсэнийг олж мэдэх шаардлагатай бол SQS дараалал үүсгэж, хүссэн сэдвээр бүртгүүлж, дарааллыг уншиж болно.

API гарц

Ихэнх үйлчилгээнд интернетээс шууд хандах боломжгүй байдаг. Хандалт нь хандалтын эрхийг шалгадаг API Gateway-ээр дамждаг. Энэ бол бас бидний үйлчилгээ бөгөөд үүнд зориулсан туршилтууд бас байдаг.

Бодит цагийн мэдэгдэл

Аппликешн ашигладаг SignalRхэрэглэгчдэд бодит цагийн мэдэгдлийг харуулах. Энэ нь мэдэгдлийн үйлчилгээнд хэрэгждэг. Энэ нь интернетээс шууд хандах боломжтой бөгөөд өөрөө OAuth-тай ажилладаг, учир нь OAuth болон мэдэгдлийн үйлчилгээг нэгтгэхтэй харьцуулахад Gateway-д вэб залгууруудын дэмжлэгийг бий болгох нь боломжгүй юм.

Туршилтын сайн арга

Нэгжийн тест нь мэдээллийн сан гэх мэт зүйлсийг хуурамч объектоор сольдог. Жишээлбэл, бичил үйлчилгээ нь гадаад түлхүүр бүхий хүснэгтэд бичлэг үүсгэхийг оролдох бөгөөд энэ түлхүүрийн иш татсан бичлэг байхгүй бол хүсэлтийг биелүүлэх боломжгүй болно. Нэгжийн туршилтууд үүнийг илрүүлж чадахгүй.

В Microsoft-ын нийтлэл Санах ойн мэдээллийн санг ашиглах, хуурамч объектуудыг хэрэгжүүлэхийг санал болгож байна.

Санах ойн мэдээллийн сан нь Entity Framework-ийн дэмждэг DBMS-ийн нэг юм. Энэ нь туршилтын зорилгоор тусгайлан бүтээгдсэн. Ийм мэдээллийн сан дахь өгөгдөл нь зөвхөн түүнийг ашиглах үйл явц дуусах хүртэл хадгалагдана. Энэ нь хүснэгт үүсгэх шаардлагагүй бөгөөд мэдээллийн бүрэн бүтэн байдлыг шалгадаггүй.

Хуурамч объектууд нь сольж буй ангиа тест хөгжүүлэгчид хэрхэн ажилладагийг ойлгох хэмжээнд л загварчилдаг.

Туршилтыг ажиллуулах үед Postgres-ийг хэрхэн автоматаар эхлүүлэх, шилжүүлэхийг Microsoft-ын нийтлэлд заагаагүй болно. Миний шийдэл үүнийг хийдэг бөгөөд үүнээс гадна микро үйлчилгээнд тест хийх тусгай код нэмдэггүй.

Шийдэл рүүгээ явцгаая

Боловсруулах явцад бүх асуудлыг цаг тухайд нь олоход нэгжийн туршилт хангалтгүй байгаа нь тодорхой болсон тул энэ асуудалд өөр өнцгөөс хандахаар шийдсэн.

Туршилтын орчинг бүрдүүлэх

Эхний ажил бол туршилтын орчинг байрлуулах явдал юм. Микро үйлчилгээг ажиллуулахад шаардлагатай алхамууд:

• Шалгаж буй үйлчилгээг локал орчинд тохируулах, мэдээллийн сан болон AWS-тай холбогдох мэдээллийг орчны хувьсагчдад зааж өгөх;
• Postgres-ийг эхлүүлж, Liquibase-г ажиллуулж шилжүүлэг хийнэ.
  Харьцангуй DBMS-д өгөгдлийн санд өгөгдөл бичихийн өмнө та өгөгдлийн схем, өөрөөр хэлбэл хүснэгт үүсгэх хэрэгтэй. Аппликешныг шинэчлэх үед хүснэгтүүдийг шинэ хувилбарт ашигласан хэлбэрт оруулах ёстой бөгөөд өгөгдлийг алдагдуулахгүй байх ёстой. Үүнийг шилжилт хөдөлгөөн гэж нэрлэдэг. Эхэндээ хоосон мэдээллийн санд хүснэгт үүсгэх нь шилжилтийн онцгой тохиолдол юм. Шилжилтийг програмд ​​өөрөө суулгаж болно. .NET болон NodeJS аль аль нь шилжих хүрээтэй. Манай тохиолдолд аюулгүй байдлын үүднээс микро үйлчилгээнүүд өгөгдлийн схемийг өөрчлөх эрхээ хасуулж, шилжүүлгийг Liquibase ашиглан гүйцэтгэдэг.
• Amazon LocalStack-ийг ажиллуул. Энэ бол гэртээ ажиллуулах AWS үйлчилгээний хэрэгжилт юм. Docker Hub дээр LocalStack-д зориулсан бэлэн зураг байна.
• LocalStack дээр шаардлагатай нэгжүүдийг үүсгэхийн тулд скриптийг ажиллуулна уу. Shell скриптүүд нь AWS CLI-г ашигладаг.

Төсөл дээр туршилт хийхэд ашигладаг Шуудан зөөгч. Энэ нь өмнө нь байсан боловч гараар эхлүүлсэн бөгөөд стенд дээр байрлуулсан програмыг туршиж үзсэн. Энэ хэрэгсэл нь танд дурын HTTP(S) хүсэлт гаргах, хариулт нь хүлээлттэй нийцэж байгаа эсэхийг шалгах боломжийг олгодог. Асуултуудыг цуглуулгад нэгтгэж, цуглуулгыг бүхэлд нь ажиллуулж болно.

Автомат туршилт хэрхэн ажилладаг вэ?

Туршилтын үеэр бүх зүйл Docker дээр ажилладаг: туршиж буй үйлчилгээ, Postgres, шилжих хэрэгсэл, Postman, эсвэл түүний консол хувилбар - Ньюман.

Docker хэд хэдэн асуудлыг шийддэг:

• Хост тохиргооноос хараат бус байх;
• Хамаарал суулгах: Docker Docker Hub-аас зураг татаж авдаг;
• Системийг анхны байдалд нь буцаах: зүгээр л савыг зайлуулах.

Докер-бүтээх чингэлэгүүдийг интернетээс тусгаарлагдсан виртуал сүлжээнд нэгтгэдэг бөгөөд дотор нь контейнерууд бие биенээ домэйн нэрээр олдог.

Туршилтыг бүрхүүлийн скриптээр удирддаг. Туршилтыг Windows дээр ажиллуулахын тулд бид git-bash ашигладаг. Тиймээс нэг скрипт нь Windows болон Linux-д хангалттай. Git болон Docker-ийг төслийн бүх хөгжүүлэгчид суулгадаг. Windows дээр Git-г суулгахад git-bash суулгасан байдаг тул хүн бүрт ийм байдаг.

Скрипт нь дараах алхмуудыг гүйцэтгэдэг.

• Докерын зургийг бүтээх

  docker-compose build

• Өгөгдлийн сан болон LocalStack ажиллуулж байна

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

• Өгөгдлийн санг шилжүүлэх, LocalStack бэлтгэх

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

• Туршилтын дагуу үйлчилгээг эхлүүлж байна

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

• Туршилтыг явуулж байна (Ньюман)
• Бүх савыг зогсооно

  docker-compose down

• Үр дүнг Slack дээр нийтлэх
  Бид ногоон тэмдэглэгээ эсвэл улаан загалмай, бүртгэлийн холбоос бүхий мессежүүд явдаг чаттай.

Дараах Docker зургууд нь эдгээр алхмуудад оролцдог.

• Туршиж буй үйлчилгээ нь үйлдвэрлэлийнхтэй ижил зураг юм. Туршилтын тохиргоо нь орчны хувьсагчаар дамждаг.
• Postgres, Redis болон LocalStack-ийн хувьд Docker Hub-ийн бэлэн зургуудыг ашигладаг. Мөн Liquibase болон Newman-д зориулсан бэлэн зургууд байдаг. Бид тэдний араг яс дээр өөрсдийнхөө файлыг бүтээж, тэнд файлуудаа нэмдэг.
• LocalStack-ийг бэлтгэхийн тулд та бэлэн AWS CLI дүрсийг ашиглаж, түүн дээр үндэслэсэн скрипт агуулсан зураг үүсгэнэ.

Ашиглаж байна хэмжээ, та зөвхөн контейнерт файл нэмэхийн тулд Docker дүрс үүсгэх шаардлагагүй. Гэсэн хэдий ч Gitlab CI даалгаврууд нь өөрөө саванд ажилладаг тул хэмжээ нь манай орчинд тохиромжгүй. Та ийм контейнерээс Docker-г удирдах боломжтой, гэхдээ эзэлхүүн нь зөвхөн хост системээс хавтас холбодог болохоос өөр контейнерээс биш.

Танд тулгарч болзошгүй асуудлууд

Бэлэн байдлыг хүлээж байна

Үйлчилгээтэй контейнер ажиллаж байгаа үед энэ нь холболтыг хүлээн авахад бэлэн байна гэсэн үг биш юм. Та холболтыг үргэлжлүүлэхийг хүлээх хэрэгтэй.

Энэ асуудлыг заримдаа скрипт ашиглан шийддэг хүлээж-for-it.sh, энэ нь TCP холболт үүсгэх боломжийг хүлээж байна. Гэсэн хэдий ч LocalStack 502 Bad Gateway алдаа гаргаж болзошгүй. Нэмж дурдахад энэ нь олон үйлчилгээнээс бүрддэг бөгөөд хэрэв тэдгээрийн аль нэг нь бэлэн бол бусад үйлчилгээний талаар юу ч хэлэхгүй.

шийдвэр: SQS болон SNS аль алинаас нь 200 хариулт хүлээж байгаа LocalStack-н нөөцийн скриптүүд.

Зэрэгцээ даалгаврын зөрчил

Нэг Docker хост дээр олон тест нэгэн зэрэг ажиллах боломжтой тул контейнер болон сүлжээний нэр нь өвөрмөц байх ёстой. Түүнчлэн, нэг үйлчилгээний өөр өөр салбаруудын тестүүд нэгэн зэрэг ажиллах боломжтой тул тэдгээрийн нэрийг бичих файл бүрт бичих нь хангалтгүй юм.

шийдвэр: Скрипт нь COMPOSE_PROJECT_NAME хувьсагчийг өвөрмөц утгаар тохируулдаг.

Windows-ийн онцлогууд

Windows дээр Docker-г ашиглахдаа хэд хэдэн зүйлийг онцлон тэмдэглэхийг хүсч байна, учир нь эдгээр туршлага нь алдаа яагаад гарч байгааг ойлгоход чухал ач холбогдолтой юм.

1. Контейнер дэх бүрхүүлийн скриптүүд нь Линукс мөрийн төгсгөлтэй байх ёстой.
   Бүрхүүлийн CR тэмдэг нь синтаксийн алдаа юм. Алдааны мэдэгдлээс ийм зүйл байгааг хэлэхэд хэцүү байна. Windows дээр ийм скриптийг засварлахдаа танд тохирох текст засварлагч хэрэгтэй. Үүнээс гадна хувилбарын хяналтын системийг зөв тохируулсан байх ёстой.

Git ийм байдлаар тохируулагдсан:

git config core.autocrlf input

1. Git-bash нь стандарт Линукс фолдеруудыг дуурайдаг бөгөөд exe файлыг (docker.exe гэх мэт) дуудахдаа үнэмлэхүй Линукс замыг Windows-ийн замаар орлуулдаг. Гэсэн хэдий ч, энэ нь орон нутгийн машин (эсвэл саванд байгаа зам) дээр байхгүй замуудын хувьд утгагүй юм. Энэ зан үйлийг идэвхгүй болгох боломжгүй.

шийдвэр: замын эхэнд нэмэлт налуу зураас нэмнэ: //bin оронд /bin. Линукс ийм замыг ойлгодог тул хэд хэдэн налуу зураас нь нэгтэй ижил байна. Гэхдээ git-bash ийм замуудыг танихгүй бөгөөд хөрвүүлэх гэж оролддоггүй.

Бүртгэлийн гаралт

Туршилтыг ажиллуулахдаа би Ньюман болон туршиж буй үйлчилгээний логуудыг харахыг хүсч байна. Эдгээр бүртгэлийн үйл явдлууд хоорондоо холбоотой байдаг тул тэдгээрийг нэг консолд нэгтгэх нь хоёр тусдаа файлаас хамаагүй илүү тохиромжтой. Ньюман дамжуулан эхлүүлсэн docker-compose ажиллуулах, тэгээд түүний гаралт нь консол дээр дуусдаг. Үлдсэн зүйл бол үйлчилгээний гарц мөн тэнд очсон эсэхийг шалгах явдал юм.

Анхны шийдэл нь хийх байсан Дүүгчийг бүрдүүлэх туг байхгүй -d, гэхдээ бүрхүүлийн боломжуудыг ашиглан энэ процессыг арын дэвсгэр рүү илгээнэ үү:

docker-compose up <service> &

Энэ нь Docker-ээс гуравдагч талын үйлчилгээ рүү лог илгээх хүртэл ажилласан. Дүүгчийг бүрдүүлэх консол руу бүртгэл гаргахаа больсон. Гэсэн хэдий ч баг ажилласан Дүүгч хавсаргана.

шийдвэр:

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

Туршилтын давталтын үед танигчийн зөрчил

Туршилтыг хэд хэдэн давталтаар явуулдаг. Мэдээллийн сан арилаагүй байна. Өгөгдлийн сан дахь бүртгэлүүд нь өвөрмөц ID-тай байдаг. Хэрэв бид хүсэлтэд тодорхой ID-г бичвэл хоёр дахь давталт дээр зөрчил гарна.

Үүнээс зайлсхийхийн тулд ID нь өвөрмөц байх эсвэл тестээр үүсгэсэн бүх объектыг устгах ёстой. Зарим объектыг шаардлагын улмаас устгах боломжгүй.

шийдвэр: Postman скрипт ашиглан GUID үүсгэх.

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

Дараа нь асуулгад тэмдэглэгээг ашиглана уу {{myUUID}}, энэ нь хувьсагчийн утгаар солигдох болно.

LocalStack-ээр дамжуулан хамтран ажиллах

Хэрэв шалгаж байгаа үйлчилгээ нь SQS дараалалд уншиж эсвэл бичдэг бол үүнийг шалгахын тулд тест өөрөө энэ дараалалтай ажиллах ёстой.

шийдвэр: Postman-аас LocalStack руу илгээсэн хүсэлт.

AWS үйлчилгээний API нь баримтжуулсан бөгөөд SDKгүйгээр асуулга хийх боломжийг олгодог.

Хэрэв үйлчилгээ дараалалд бичвэл бид үүнийг уншиж, мессежийн агуулгыг шалгана.

Хэрэв үйлчилгээ нь SNS руу мессеж илгээдэг бол бэлтгэлийн шатанд LocalStack нь дараалал үүсгэж, энэ SNS сэдвээр бүртгүүлдэг. Дараа нь бүх зүйл дээр дурдсан зүйл дээр бууна.

Хэрэв үйлчилгээ дараалалаас мессеж унших шаардлагатай бол өмнөх туршилтын алхамд бид энэ мессежийг дараалалд бичдэг.

Туршиж буй микро үйлчилгээнээс гаралтай HTTP хүсэлтийг шалгаж байна

Зарим үйлчилгээнүүд HTTP дээр AWS-ээс өөр зүйлээр ажилладаг ба AWS-ийн зарим функцууд LocalStack-д хэрэгждэггүй.

шийдвэр: эдгээр тохиолдолд энэ нь тусалж чадна Хуурамч сервер, аль нь бэлэн зураг байна Докерын төв. Хүлээгдэж буй хүсэлтүүд болон тэдгээрийн хариуг HTTP хүсэлтээр тохируулдаг. API нь баримтжуулсан тул бид Postman-аас хүсэлт гаргадаг.

OAuth баталгаажуулалт ба зөвшөөрлийг туршиж байна

Бид OAuth болон ашигладаг JSON вэб токенууд (JWT). Туршилтад бид дотооддоо ажиллуулах боломжтой OAuth үйлчилгээ үзүүлэгч шаардлагатай.

Үйлчилгээ болон OAuth үйлчилгээ үзүүлэгчийн хоорондох бүх харилцан үйлчлэл нь хоёр хүсэлтээр явагддаг: нэгдүгээрт, тохиргоог хийх хүсэлт гаргана. /.сайн мэдэх/openid-тохиргоо, дараа нь тохиргооны хаягаар нийтийн түлхүүрийг (JWKS) хүсэх болно. Энэ бүхэн статик контент юм.

шийдвэр: Манай туршилтын OAuth үйлчилгээ үзүүлэгч нь статик контент сервер ба түүн дээрх хоёр файл юм. Токеныг нэг удаа үүсгэж, Git-д зориулдаг.

SignalR тестийн онцлог

Шуудангийн ажилтан вэб залгууртай ажилладаггүй. SignalR-г туршихын тулд тусгай хэрэгсэл бүтээгдсэн.

SignalR клиент нь зөвхөн хөтөч биш байж болно. .NET Core доор түүнд зориулсан клиент номын сан байдаг. .NET Core дээр бичигдсэн үйлчлүүлэгч нь холболт үүсгэж, баталгаажуулж, тодорхой дарааллын мессежийг хүлээнэ. Гэнэтийн мессеж ирсэн эсвэл холболт тасарсан тохиолдолд үйлчлүүлэгч 1 гэсэн кодоор гарна.Хэрэв хамгийн сүүлд хүлээгдэж буй мессежийг хүлээн авсан бол үйлчлүүлэгч 0 кодоор гарна.

Ньюман үйлчлүүлэгчтэй нэгэн зэрэг ажилладаг. Мессежийг хэрэгцээтэй хүн бүрт хүргэж байгаа эсэхийг шалгахын тулд хэд хэдэн үйлчлүүлэгч ажиллуулдаг.

Олон үйлчлүүлэгч ажиллуулахын тулд сонголтыг ашиглана уу - масштаб docker-compose командын мөрөнд.

Ажиллуулахын өмнө Postman скрипт нь бүх үйлчлүүлэгчид холболт үүсгэхийг хүлээдэг.
Бид холболтыг хүлээх асуудалтай аль хэдийн тулгарсан. Гэхдээ серверүүд байсан бөгөөд энд үйлчлүүлэгч байна. Өөр арга барил хэрэгтэй.

шийдвэр: саванд байгаа үйлчлүүлэгч механизмыг ашигладаг Эрүүл мэндийн үзлэгхост дээрх скриптэд статусын талаар мэдээлэх. Үйлчлүүлэгч холболт үүссэн даруйд /healthcheck гэх мэт тодорхой зам дээр файл үүсгэдэг. Докер файл дахь HealthCheck скрипт дараах байдалтай байна.

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

баг докер шалгана Савны хэвийн байдал, эрүүл мэндийн байдал, гарах кодыг харуулна.

Ньюманыг дуусгасны дараа скрипт нь үйлчлүүлэгчтэй бүх контейнерууд дууссан эсэхийг 0 кодоор шалгадаг.

Аз жаргал байдаг

Дээр дурдсан бэрхшээлийг даван туулсны дараа бид тогтвортой ажиллах туршилтуудыг хийсэн. Туршилтын хувьд үйлчилгээ бүр мэдээллийн сан болон Amazon LocalStack-тай харилцан үйлчилдэг нэг нэгж болж ажилладаг.

Эдгээр туршилтууд нь 30+ хөгжүүлэгчдийн багийг байнга суулгадаг 10+ микро үйлчилгээний нарийн төвөгтэй харилцан үйлчлэл бүхий програмын алдаанаас хамгаалдаг.

Эх сурвалж: www.habr.com