Awtomatikong pagsubok ng mga microservice sa Docker para sa patuloy na pagsasama

Sa mga proyektong nauugnay sa pagpapaunlad ng arkitektura ng microservice, ang CI/CD ay lumilipat mula sa kategorya ng isang magandang pagkakataon patungo sa kategorya ng isang kagyat na pangangailangan. Ang awtomatikong pagsubok ay isang mahalagang bahagi ng tuluy-tuloy na pagsasama, isang karampatang diskarte kung saan maaaring magbigay sa koponan ng maraming magagandang gabi kasama ang pamilya at mga kaibigan. Kung hindi, ang proyekto ay nanganganib na hindi makumpleto.

Posibleng sakupin ang buong microservice code na may mga unit test na may mga kunwaring bagay, ngunit bahagyang malulutas lamang nito ang problema at nag-iiwan ng maraming katanungan at kahirapan, lalo na kapag gumagana ang pagsubok gamit ang data. Gaya ng nakasanayan, ang pinakapinipilit ay ang pagsubok ng pagkakapare-pareho ng data sa isang relational database, pagsubok ng trabaho sa mga serbisyo ng cloud, at paggawa ng mga maling pagpapalagay kapag nagsusulat ng mga mock na bagay.

Ang lahat ng ito at kaunti pa ay malulutas sa pamamagitan ng pagsubok sa buong microservice sa isang lalagyan ng Docker. Ang isang hindi mapag-aalinlanganang bentahe para sa pagtiyak ng bisa ng mga pagsubok ay ang parehong mga imahe ng Docker na papasok sa produksyon ay nasubok.

Ang pag-automate ng diskarteng ito ay nagpapakita ng ilang mga problema, ang solusyon kung saan ay ilalarawan sa ibaba:

• mga salungatan ng magkatulad na mga gawain sa parehong docker host;
• mga salungatan sa identifier sa database sa panahon ng mga pag-ulit ng pagsubok;
• naghihintay para sa mga microservice na maging handa;
• pagsasama at pag-output ng mga log sa mga panlabas na sistema;
• pagsubok ng mga papalabas na kahilingan sa HTTP;
• pagsubok sa web socket (gamit ang SignalR);
• pagsubok sa pagpapatunay at pahintulot ng OAuth.

Ang artikulong ito ay batay sa ang aking talumpati sa SECR 2019. Kaya sa mga tamad magbasa, narito ang isang pagtatala ng talumpati.

Sa artikulong ito sasabihin ko sa iyo kung paano gumamit ng script upang patakbuhin ang serbisyo sa ilalim ng pagsubok, isang database at mga serbisyo ng Amazon AWS sa Docker, pagkatapos ay magsuri sa Postman at, pagkatapos makumpleto ang mga ito, ihinto at tanggalin ang mga nilikhang lalagyan. Ang mga pagsubok ay isinasagawa sa tuwing nagbabago ang code. Sa ganitong paraan, tinitiyak namin na gumagana nang tama ang bawat bersyon sa database at mga serbisyo ng AWS.

Ang parehong script ay parehong pinapatakbo ng mga developer mismo sa kanilang mga Windows desktop at ng Gitlab CI server sa ilalim ng Linux.

Upang mabigyang-katwiran, ang pagpapakilala ng mga bagong pagsubok ay hindi dapat mangailangan ng pag-install ng mga karagdagang tool alinman sa computer ng developer o sa server kung saan pinapatakbo ang mga pagsubok sa isang commit. Niresolba ng Docker ang problemang ito.

Dapat tumakbo ang pagsubok sa isang lokal na server para sa mga sumusunod na dahilan:

• Ang network ay hindi kailanman ganap na maaasahan. Sa isang libong kahilingan, maaaring mabigo ang isa;
  Sa kasong ito, ang awtomatikong pagsubok ay hindi gagana, ang trabaho ay titigil, at kailangan mong hanapin ang dahilan sa mga log;
• Ang masyadong madalas na mga kahilingan ay hindi pinapayagan ng ilang mga serbisyo ng third-party.

Bilang karagdagan, hindi kanais-nais na gamitin ang stand dahil:

• Ang isang stand ay maaaring masira hindi lamang sa pamamagitan ng masamang code na tumatakbo dito, kundi pati na rin ng data na hindi maproseso ng tamang code;
• Gaano man natin subukang ibalik ang lahat ng mga pagbabagong ginawa ng pagsubok sa panahon ng pagsubok mismo, may maaaring magkamali (kung hindi, bakit sumubok?).

Tungkol sa organisasyon ng proyekto at proseso

Ang aming kumpanya ay bumuo ng isang microservice web application na tumatakbo sa Docker sa Amazon AWS cloud. Nagamit na ang mga unit test sa proyekto, ngunit madalas na may mga error na hindi nakita ng mga unit test. Kinakailangang subukan ang isang buong microservice kasama ang database at mga serbisyo ng Amazon.

Gumagamit ang proyekto ng karaniwang tuluy-tuloy na proseso ng pagsasama, na kinabibilangan ng pagsubok sa microservice sa bawat commit. Pagkatapos magtalaga ng isang gawain, gagawa ang developer ng mga pagbabago sa microservice, manu-mano itong sinusubok at pinapatakbo ang lahat ng available na automated na pagsubok. Kung kinakailangan, babaguhin ng developer ang mga pagsubok. Kung walang nakitang mga problema, isang commit ang gagawin sa sangay ng isyung ito. Pagkatapos ng bawat commit, awtomatikong tatakbo ang mga pagsubok sa server. Ang pagsasama sa isang karaniwang sangay at ang paglulunsad ng mga awtomatikong pagsubok dito ay nangyayari pagkatapos ng matagumpay na pagsusuri. Kung pumasa ang mga pagsubok sa nakabahaging sangay, awtomatikong maa-update ang serbisyo sa kapaligiran ng pagsubok sa Amazon Elastic Container Service (bench). Ang stand ay kinakailangan para sa lahat ng mga developer at tester, at hindi ipinapayong sirain ito. Sinusuri ng mga tagasubok sa kapaligirang ito ang isang pag-aayos o isang bagong feature sa pamamagitan ng pagsasagawa ng mga manu-manong pagsubok.

Arkitektura ng proyekto

Ang application ay binubuo ng higit sa sampung mga serbisyo. Ang ilan sa mga ito ay nakasulat sa .NET Core at ang ilan sa NodeJs. Ang bawat serbisyo ay tumatakbo sa isang Docker container sa Amazon Elastic Container Service. Ang bawat isa ay may sariling database ng Postgres, at ang ilan ay mayroon ding Redis. Walang mga karaniwang database. Kung ang ilang mga serbisyo ay nangangailangan ng parehong data, pagkatapos ang data na ito, kapag ito ay nagbago, ay ipinapadala sa bawat isa sa mga serbisyong ito sa pamamagitan ng SNS (Simple Notification Service) at SQS (Amazon Simple Queue Service), at ang mga serbisyo ay i-save ito sa kanilang sariling hiwalay na mga database.

SQS at SNS

Binibigyang-daan ka ng SQS na maglagay ng mga mensahe sa isang queue at magbasa ng mga mensahe mula sa queue gamit ang HTTPS protocol.

Kung maraming serbisyo ang nagbasa ng isang pila, ang bawat mensahe ay darating lamang sa isa sa kanila. Ito ay kapaki-pakinabang kapag nagpapatakbo ng ilang mga pagkakataon ng parehong serbisyo upang ipamahagi ang load sa pagitan ng mga ito.

Kung gusto mong maihatid ang bawat mensahe sa maraming serbisyo, dapat may sariling pila ang bawat tatanggap, at kailangan ang SNS para i-duplicate ang mga mensahe sa maraming pila.

Sa SNS lumikha ka ng isang paksa at mag-subscribe dito, halimbawa, isang SQS queue. Maaari kang magpadala ng mga mensahe sa paksa. Sa kasong ito, ipinapadala ang mensahe sa bawat pila na naka-subscribe sa paksang ito. Ang SNS ay walang paraan para sa pagbabasa ng mga mensahe. Kung sa panahon ng pag-debug o pagsubok kailangan mong malaman kung ano ang ipinadala sa SNS, maaari kang lumikha ng isang SQS queue, i-subscribe ito sa nais na paksa at basahin ang queue.

Gateway ng API

Karamihan sa mga serbisyo ay hindi direktang naa-access mula sa Internet. Ang pag-access ay sa pamamagitan ng API Gateway, na sumusuri sa mga karapatan sa pag-access. Ito rin ang aming serbisyo, at may mga pagsubok din para dito.

Mga real-time na notification

Ang application ay gumagamit ng SignalRupang magpakita ng mga real-time na notification sa user. Ito ay ipinatupad sa serbisyo ng notification. Direkta itong naa-access mula sa Internet at gumagana mismo sa OAuth, dahil naging hindi praktikal na bumuo ng suporta para sa mga Web socket sa Gateway, kumpara sa pagsasama ng OAuth at serbisyo ng notification.

Kilalang Pamamaraan sa Pagsusulit

Pinapalitan ng mga unit test ang mga bagay tulad ng database ng mga mock object. Kung ang isang microservice, halimbawa, ay sumusubok na lumikha ng isang tala sa isang talahanayan na may isang dayuhang key, at ang talaan na isinangguni ng key na iyon ay hindi umiiral, kung gayon ang kahilingan ay hindi maisasagawa. Hindi ito matukoy ng mga unit test.

В artikulo mula sa Microsoft Iminungkahi na gumamit ng in-memory database at magpatupad ng mga mock object.

Ang in-memory database ay isa sa mga DBMS na sinusuportahan ng Entity Framework. Ito ay partikular na nilikha para sa pagsubok. Ang data sa naturang database ay iniimbak lamang hanggang sa matapos ang prosesong gumagamit nito. Hindi ito nangangailangan ng paglikha ng mga talahanayan at hindi sinusuri ang integridad ng data.

Itinulad ng mga mock object ang klase na pinapalitan lamang nila hanggang sa nauunawaan ng developer ng pagsubok kung paano ito gumagana.

Paano awtomatikong magsimula at magsagawa ng mga paglilipat ang Postgres kapag nagpatakbo ka ng pagsubok ay hindi tinukoy sa artikulo ng Microsoft. Ginagawa ito ng aking solusyon at, bilang karagdagan, ay hindi nagdaragdag ng anumang code na partikular para sa mga pagsubok sa microservice mismo.

Lumipat tayo sa solusyon

Sa panahon ng proseso ng pag-unlad, naging malinaw na ang mga pagsubok sa yunit ay hindi sapat upang mahanap ang lahat ng mga problema sa isang napapanahong paraan, kaya napagpasyahan na lapitan ang isyung ito mula sa ibang anggulo.

Pagse-set up ng isang kapaligiran sa pagsubok

Ang unang gawain ay mag-deploy ng isang pagsubok na kapaligiran. Mga hakbang na kinakailangan upang magpatakbo ng isang microservice:

• I-configure ang serbisyo sa ilalim ng pagsubok para sa lokal na kapaligiran, tukuyin ang mga detalye para sa pagkonekta sa database at AWS sa mga variable ng kapaligiran;
• Simulan ang Postgres at isagawa ang paglipat sa pamamagitan ng pagpapatakbo ng Liquibase.
  Sa mga relational na DBMS, bago isulat ang data sa database, kailangan mong lumikha ng schema ng data, sa madaling salita, mga talahanayan. Kapag nag-a-update ng isang application, ang mga talahanayan ay dapat dalhin sa form na ginamit ng bagong bersyon, at, mas mabuti, nang hindi nawawala ang data. Ito ay tinatawag na migration. Ang paglikha ng mga talahanayan sa isang walang laman na database sa una ay isang espesyal na kaso ng paglipat. Ang paglipat ay maaaring itayo sa mismong application. Parehong may mga migration framework ang .NET at NodeJS. Sa aming kaso, para sa mga kadahilanang pangseguridad, ang mga microservice ay inaalisan ng karapatang baguhin ang schema ng data, at ang paglipat ay isinasagawa gamit ang Liquibase.
• Ilunsad ang Amazon LocalStack. Isa itong pagpapatupad ng mga serbisyo ng AWS na tatakbo sa bahay. Mayroong isang handa na imahe para sa LocalStack sa Docker Hub.
• Patakbuhin ang script upang lumikha ng mga kinakailangang entity sa LocalStack. Ginagamit ng mga shell script ang AWS CLI.

Ginagamit para sa pagsubok sa proyekto Kartero. Ito ay umiral noon, ngunit ito ay inilunsad nang manu-mano at sinubukan ang isang application na na-deploy na sa stand. Nagbibigay-daan sa iyo ang tool na ito na gumawa ng mga arbitrary na HTTP(S) na kahilingan at suriin kung tumutugma ang mga tugon sa inaasahan. Ang mga query ay pinagsama sa isang koleksyon, at ang buong koleksyon ay maaaring patakbuhin.

Paano gumagana ang awtomatikong pagsubok?

Sa panahon ng pagsubok, gumagana ang lahat sa Docker: ang serbisyong nasa ilalim ng pagsubok, Postgres, ang tool sa paglilipat, at Postman, o sa halip ang bersyon ng console nito - Newman.

Nilulutas ng Docker ang ilang mga problema:

• Kalayaan mula sa pagsasaayos ng host;
• Pag-install ng mga dependency: Nagda-download ang Docker ng mga larawan mula sa Docker Hub;
• Ibinabalik ang system sa orihinal nitong estado: pag-alis lang ng mga lalagyan.

Docker-compose pinagsasama ang mga lalagyan sa isang virtual na network, na nakahiwalay sa Internet, kung saan ang mga lalagyan ay nahahanap ang isa't isa sa pamamagitan ng mga pangalan ng domain.

Ang pagsubok ay kinokontrol ng isang script ng shell. Upang patakbuhin ang pagsubok sa Windows ginagamit namin ang git-bash. Kaya, ang isang script ay sapat para sa parehong Windows at Linux. Ang Git at Docker ay na-install ng lahat ng mga developer sa proyekto. Kapag nag-i-install ng Git sa Windows, naka-install ang git-bash, kaya lahat ay mayroon din niyan.

Ginagawa ng script ang mga sumusunod na hakbang:

• Pagbuo ng mga larawan ng docker

  docker-compose build

• Paglulunsad ng database at LocalStack

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

• Paglipat ng database at paghahanda ng LocalStack

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

• Paglulunsad ng serbisyo sa ilalim ng pagsubok

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

• Pagpapatakbo ng pagsubok (Newman)
• Pinahinto ang lahat ng lalagyan

  docker-compose down

• Pag-post ng mga resulta sa Slack
  Mayroon kaming chat kung saan pupunta ang mga mensaheng may berdeng checkmark o pulang krus at link sa log.

Ang mga sumusunod na larawan ng Docker ay kasangkot sa mga hakbang na ito:

• Ang serbisyong sinusubok ay ang parehong imahe tulad ng para sa produksyon. Ang pagsasaayos para sa pagsubok ay sa pamamagitan ng mga variable ng kapaligiran.
• Para sa Postgres, Redis at LocalStack, ginagamit ang mga yari na larawan mula sa Docker Hub. Mayroon ding mga yari na larawan para sa Liquibase at Newman. Binubuo namin ang sa amin sa kanilang balangkas, idinadagdag ang aming mga file doon.
• Upang ihanda ang LocalStack, gumamit ka ng isang handa na AWS CLI na imahe at lumikha ng isang imahe na naglalaman ng isang script batay dito.

Paggamit mga volume, hindi mo kailangang bumuo ng Docker image para lang magdagdag ng mga file sa container. Gayunpaman, ang mga volume ay hindi angkop para sa ating kapaligiran dahil ang mga gawain ng Gitlab CI mismo ay tumatakbo sa mga lalagyan. Maaari mong kontrolin ang Docker mula sa naturang lalagyan, ngunit ang mga volume ay nag-mount lamang ng mga folder mula sa host system, at hindi mula sa isa pang lalagyan.

Mga problemang maaari mong maranasan

Naghihintay ng kahandaan

Kapag tumatakbo ang isang lalagyan na may serbisyo, hindi ito nangangahulugan na handa na itong tumanggap ng mga koneksyon. Dapat mong hintayin na magpatuloy ang koneksyon.

Minsan nalulutas ang problemang ito gamit ang isang script wait-for-it.sh, na naghihintay ng pagkakataong magtatag ng koneksyon sa TCP. Gayunpaman, ang LocalStack ay maaaring magtapon ng 502 Bad Gateway error. Bilang karagdagan, ito ay binubuo ng maraming mga serbisyo, at kung ang isa sa kanila ay handa na, wala itong sinasabi tungkol sa iba.

desisyon: LocalStack provisioning script na naghihintay ng 200 na tugon mula sa parehong SQS at SNS.

Parallel Task Conflicts

Maaaring tumakbo nang sabay-sabay ang maraming pagsubok sa parehong host ng Docker, kaya dapat na natatangi ang mga pangalan ng container at network. Bukod dito, ang mga pagsubok mula sa iba't ibang sangay ng parehong serbisyo ay maaari ding tumakbo nang sabay-sabay, kaya hindi sapat na isulat ang kanilang mga pangalan sa bawat compose file.

desisyon: Itinatakda ng script ang variable na COMPOSE_PROJECT_NAME sa isang natatanging halaga.

Mga Tampok ng Windows

Mayroong ilang mga bagay na gusto kong ituro kapag gumagamit ng Docker sa Windows, dahil ang mga karanasang ito ay mahalaga sa pag-unawa kung bakit nangyayari ang mga error.

1. Ang mga script ng shell sa isang lalagyan ay dapat may mga dulo ng linya ng Linux.
   Ang simbolo ng shell CR ay isang syntax error. Mahirap sabihin mula sa mensahe ng error na ito ang kaso. Kapag nag-e-edit ng mga naturang script sa Windows, kailangan mo ng wastong text editor. Bilang karagdagan, ang sistema ng kontrol ng bersyon ay dapat na i-configure nang maayos.

Ito ay kung paano naka-configure ang git:

git config core.autocrlf input

1. Ginagaya ng Git-bash ang mga karaniwang folder ng Linux at, kapag tumatawag sa isang exe file (kabilang ang docker.exe), pinapalitan ang ganap na Linux path ng mga Windows path. Gayunpaman, hindi ito makatuwiran para sa mga landas na wala sa lokal na makina (o mga landas sa isang lalagyan). Ang pag-uugali na ito ay hindi maaaring i-disable.

desisyon: magdagdag ng karagdagang slash sa simula ng landas: //bin sa halip na /bin. Naiintindihan ng Linux ang gayong mga landas; para dito, maraming mga slash ang kapareho ng isa. Ngunit hindi kinikilala ng git-bash ang mga naturang landas at hindi sinusubukang i-convert ang mga ito.

Output ng log

Kapag nagpapatakbo ng mga pagsubok, gusto kong makakita ng mga log mula sa Newman at sa serbisyong sinusuri. Dahil ang mga kaganapan ng mga log na ito ay magkakaugnay, ang pagsasama-sama ng mga ito sa isang console ay mas maginhawa kaysa sa dalawang magkahiwalay na mga file. Inilunsad ni Newman sa pamamagitan ng docker-compose run, at sa gayon ang output nito ay napupunta sa console. Ang natitira na lang ay tiyaking mapupunta rin doon ang output ng serbisyo.

Ang orihinal na solusyon ay gawin docker-compose up walang bandila -d, ngunit gamit ang mga kakayahan ng shell, ipadala ang prosesong ito sa background:

docker-compose up <service> &

Nagtrabaho ito hanggang sa kinakailangan na magpadala ng mga log mula sa Docker sa isang third-party na serbisyo. docker-compose up huminto sa pag-output ng mga log sa console. Gayunpaman, nagtrabaho ang koponan maglagay ng docker.

desisyon:

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

Salungatan sa pagkakakilanlan sa panahon ng mga pag-ulit ng pagsubok

Ang mga pagsubok ay pinapatakbo sa ilang mga pag-ulit. Hindi na-clear ang database. Ang mga tala sa database ay may mga natatanging ID. Kung isusulat namin ang mga partikular na ID sa mga kahilingan, magkakaroon kami ng conflict sa pangalawang pag-ulit.

Upang maiwasan ito, dapat na natatangi ang mga ID, o dapat tanggalin ang lahat ng bagay na ginawa ng pagsubok. Ang ilang mga bagay ay hindi matatanggal dahil sa mga kinakailangan.

desisyon: bumuo ng mga GUID gamit ang mga script ng Postman.

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

Pagkatapos ay gamitin ang simbolo sa query {{myUUID}}, na papalitan ng halaga ng variable.

Pakikipagtulungan sa pamamagitan ng LocalStack

Kung ang serbisyong sinusuri ay nagbabasa o nagsusulat sa isang SQS queue, para ma-verify ito, ang pagsubok mismo ay dapat ding gumana sa queue na ito.

desisyon: mga kahilingan mula sa Postman hanggang LocalStack.

Nakadokumento ang AWS services API, na nagbibigay-daan sa mga query na magawa nang walang SDK.

Kung ang isang serbisyo ay sumulat sa isang pila, pagkatapos ay babasahin namin ito at suriin ang mga nilalaman ng mensahe.

Kung ang serbisyo ay nagpapadala ng mga mensahe sa SNS, sa yugto ng paghahanda, ang LocalStack ay gumagawa din ng isang pila at nag-subscribe sa paksang ito ng SNS. Pagkatapos ang lahat ay bumaba sa kung ano ang inilarawan sa itaas.

Kung ang serbisyo ay kailangang magbasa ng isang mensahe mula sa pila, pagkatapos ay sa nakaraang hakbang sa pagsubok isulat namin ang mensaheng ito sa pila.

Pagsubok sa mga kahilingan sa HTTP na nagmula sa microservice na sinusuri

Gumagana ang ilang serbisyo sa HTTP gamit ang isang bagay maliban sa AWS, at ang ilang feature ng AWS ay hindi ipinapatupad sa LocalStack.

desisyon: sa mga kasong ito ay makakatulong ito MockServer, na mayroong yari na larawan sa Docker hub. Ang mga inaasahang kahilingan at tugon sa mga ito ay na-configure ng isang kahilingan sa HTTP. Ang API ay dokumentado, kaya gumawa kami ng mga kahilingan mula sa Postman.

Pagsubok sa OAuth Authentication at Authorization

Ginagamit namin ang OAuth at JSON Web Token (JWT). Ang pagsubok ay nangangailangan ng OAuth provider na maaari naming patakbuhin nang lokal.

Ang lahat ng pakikipag-ugnayan sa pagitan ng serbisyo at ng OAuth provider ay bumaba sa dalawang kahilingan: una, hinihiling ang configuration /.well-known/openid-configuration, at pagkatapos ay ang public key (JWKS) ay hinihiling sa address mula sa configuration. Ang lahat ng ito ay static na nilalaman.

desisyon: Ang aming test OAuth provider ay isang static na content server at dalawang file dito. Ang token ay nabuo nang isang beses at nakatuon sa Git.

Mga tampok ng pagsubok sa SignalR

Hindi gumagana ang postman sa mga websocket. Ang isang espesyal na tool ay nilikha upang subukan ang SignalR.

Ang isang SignalR client ay maaaring higit pa sa isang browser. Mayroong isang client library para dito sa ilalim ng .NET Core. Ang kliyente, na nakasulat sa .NET Core, ay nagtatatag ng isang koneksyon, ay napatotohanan, at naghihintay para sa isang partikular na pagkakasunod-sunod ng mga mensahe. Kung natanggap ang isang hindi inaasahang mensahe o nawala ang koneksyon, lalabas ang kliyente na may code na 1. Kung natanggap ang huling inaasahang mensahe, lalabas ang kliyente na may code na 0.

Nagtatrabaho nang sabay-sabay si Newman sa kliyente. Ilang kliyente ang inilunsad upang suriin kung ang mga mensahe ay naihatid sa lahat ng nangangailangan nito.

Upang magpatakbo ng maraming kliyente, gamitin ang opsyon --scale sa docker-compose command line.

Bago tumakbo, ang script ng Postman ay naghihintay para sa lahat ng mga kliyente na magtatag ng mga koneksyon.
Nakaranas na kami ng problema sa paghihintay ng koneksyon. Ngunit may mga server, at narito ang kliyente. Kailangan ng ibang diskarte.

desisyon: ginagamit ng kliyente sa lalagyan ang mekanismo KalusuganCheckupang ipaalam sa script sa host ang tungkol sa status nito. Lumilikha ang kliyente ng isang file sa isang partikular na landas, sabihin /healthcheck, sa sandaling maitatag ang koneksyon. Ang script ng HealthCheck sa docker file ay ganito ang hitsura:

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

Koponan inspeksyon ng docker Ipinapakita ang normal na katayuan, katayuan sa kalusugan at exit code para sa lalagyan.

Pagkatapos makumpleto ni Newman, sinusuri ng script na ang lahat ng mga container na may kliyente ay natapos na, na may code 0.

Ang Happinnes ay umiiral

Pagkatapos naming malampasan ang mga paghihirap na inilarawan sa itaas, nagkaroon kami ng isang hanay ng mga matatag na pagsubok sa pagtakbo. Sa mga pagsubok, gumagana ang bawat serbisyo bilang isang yunit, nakikipag-ugnayan sa database at Amazon LocalStack.

Pinoprotektahan ng mga pagsubok na ito ang isang team ng 30+ developer mula sa mga error sa isang application na may kumplikadong pakikipag-ugnayan ng 10+ microservice na may madalas na pag-deploy.

Pinagmulan: www.habr.com