Tes otomatis layanan mikro ing Docker kanggo integrasi terus-terusan

Ing proyek sing ana gandhengane karo pangembangan arsitektur layanan mikro, CI / CD pindhah saka kategori kesempatan sing nyenengake menyang kategori kabutuhan sing penting. Pengujian otomatis minangka bagean integral saka integrasi sing terus-terusan, pendekatan sing kompeten sing bisa menehi tim akeh sore sing nyenengake karo kulawarga lan kanca-kanca. Yen ora, risiko proyek ora bakal rampung.

Sampeyan bisa nutupi kabeh kode microservice kanthi tes unit kanthi obyek mock, nanging iki mung bisa ngrampungake masalah kasebut lan ninggalake akeh pitakonan lan kesulitan, utamane nalika nyoba nggarap data. Kaya biasane, sing paling penting yaiku nguji konsistensi data ing basis data relasional, nguji karya karo layanan awan, lan nggawe asumsi sing salah nalika nulis obyek mock.

Kabeh iki lan liya-liyane bisa ditanggulangi kanthi nyoba kabeh layanan mikro ing wadhah Docker. Kauntungan sing ora diragukan kanggo mesthekake validitas tes yaiku gambar Docker sing padha ing produksi diuji.

Otomasi pendekatan iki menehi sawetara masalah, solusi sing bakal diterangake ing ngisor iki:

• konflik tugas podo ing host docker padha;
• konflik pengenal ing basis data sajrone pengulangan tes;
• ngenteni microservices siap;
• nggabungake lan output log menyang sistem njaba;
• nguji panjalukan HTTP sing metu;
• testing soket web (nggunakake SignalR);
• nguji otentikasi lan wewenang OAuth.

Artikel iki adhedhasar pituturku ing SECR 2019. Dadi kanggo sing kesed maca, punika rekaman pidato.

Ing artikel iki aku bakal pitutur marang kowe carane nggunakake script kanggo mbukak layanan ing test, database lan layanan Amazon AWS ing Docker, banjur tes ing Postman lan, sawise padha rampung, mungkasi lan mbusak wadhah digawe. Tes dileksanakake saben-saben kode diganti. Kanthi cara iki, kita priksa manawa saben versi bisa digunakake kanthi bener karo basis data lan layanan AWS.

Skrip sing padha ditindakake dening pangembang dhewe ing desktop Windows lan server Gitlab CI ing Linux.

Kanggo dibenerake, ngenalake tes anyar ora mbutuhake instalasi alat tambahan ing komputer pangembang utawa ing server ing ngendi tes ditindakake kanthi komitmen Docker ngatasi masalah iki.

Tes kasebut kudu ditindakake ing server lokal amarga alasan ing ngisor iki:

• Jaringan kasebut ora bisa dipercaya. Saka sewu panjaluk, siji bisa gagal;
  Ing kasus iki, tes otomatis ora bakal bisa, karya bakal mandheg, lan sampeyan kudu nggoleki alesan ing log;
• Panjaluk sing kerep banget ora diidini dening sawetara layanan pihak katelu.

Kajaba iku, ora dikarepake nggunakake stand amarga:

• A stand bisa rusak ora mung dening kode ala mlaku ing, nanging uga dening data sing kode bener ora bisa proses;
• Ora ketompo carane hard kita nyoba kanggo mbalek maneh kabeh owah-owahan sing digawe dening test sak test dhewe, soko bisa salah (yen ora, kok nyoba?).

Babagan organisasi proyek lan proses

Perusahaan kita ngembangake aplikasi web layanan mikro sing mlaku ing Docker ing awan Amazon AWS. Tes unit wis digunakake ing proyek kasebut, nanging asring ana kesalahan sing ora dideteksi tes unit. Sampeyan kudu nyoba kabeh layanan mikro bebarengan karo database lan layanan Amazon.

Proyek kasebut nggunakake proses integrasi terus-terusan standar, sing kalebu nguji layanan mikro kanthi saben komitmen. Sawise menehi tugas, pangembang nggawe owah-owahan menyang layanan mikro, nyoba kanthi manual lan nindakake kabeh tes otomatis sing kasedhiya. Yen perlu, pangembang ngganti tes kasebut. Yen ora ana masalah sing ditemokake, komitmen digawe kanggo cabang masalah iki. Sawise saben komitmen, tes otomatis ditindakake ing server. Gabung menyang cabang umum lan ngluncurake tes otomatis kasebut sawise review sukses. Yen tes ing cabang sing dienggo bareng lulus, layanan kasebut kanthi otomatis dianyari ing lingkungan tes ing Amazon Elastic Container Service (bangku). Ngadeg perlu kanggo kabeh pangembang lan tester, lan iku ora dianjurake kanggo break. Penguji ing lingkungan iki mriksa ndandani utawa fitur anyar kanthi nindakake tes manual.

Arsitektur proyek

Aplikasi kasebut kalebu luwih saka sepuluh layanan. Sawetara ditulis ing .NET Core lan sawetara ing NodeJs. Saben layanan mlaku ing wadhah Docker ing Amazon Elastic Container Service. Saben duwe database Postgres dhewe, lan sawetara uga duwe Redis. Ora ana database umum. Yen sawetara layanan mbutuhake data sing padha, banjur data iki, nalika diganti, dikirim menyang saben layanan kasebut liwat SNS (Layanan Notifikasi Sederhana) lan SQS (Layanan Antrian Simple Amazon), lan layanan kasebut disimpen ing basis data sing kapisah.

SQS lan SNS

SQS ngidini sampeyan ngirim pesen menyang antrian lan maca pesen saka antrian nggunakake protokol HTTPS.

Yen sawetara layanan maca siji antrian, banjur saben pesen teka mung siji. Iki migunani nalika nglakokake sawetara conto layanan sing padha kanggo nyebarake beban ing antarane.

Yen sampeyan pengin saben pesen dikirim menyang macem-macem layanan, saben panampa kudu duwe antrian dhewe, lan SNS dibutuhake kanggo duplikat pesen menyang sawetara antrian.

Ing SNS sampeyan nggawe topik lan langganan, contone, antrian SQS. Sampeyan bisa ngirim pesen menyang topik. Ing kasus iki, pesen dikirim menyang saben antrian langganan topik iki. SNS ora duwe cara kanggo maca pesen. Yen sajrone debugging utawa testing sampeyan kudu mangerteni apa sing dikirim menyang SNS, sampeyan bisa nggawe antrian SQS, langganan topik sing dikarepake lan maca antrian.

Gerbang API

Umume layanan ora bisa diakses langsung saka Internet. Akses liwat API Gateway, sing mriksa hak akses. Iki uga layanan kita, lan ana tes uga.

Kabar wektu nyata

Aplikasi nggunakake SinyalRkanggo nuduhake kabar wektu nyata marang pangguna. Iki dileksanakake ing layanan notifikasi. Bisa diakses langsung saka Internet lan bisa digunakake karo OAuth, amarga ora praktis kanggo mbangun dhukungan kanggo soket Web menyang Gateway, dibandhingake karo nggabungake OAuth lan layanan kabar.

Pendekatan Testing Kondhang

Tes unit ngganti kaya database karo obyek mock. Yen microservice, umpamane, nyoba nggawe rekaman ing tabel kanthi kunci asing, lan rekaman sing dirujuk dening tombol kasebut ora ana, mula panyuwunan kasebut ora bisa rampung. Tes unit ora bisa ndeteksi iki.

В artikel saka Microsoft Disaranake nggunakake database ing memori lan ngleksanakake obyek mock.

Database ing memori minangka salah sawijining DBMS sing didhukung dening Entity Framework. Iku digawe khusus kanggo testing. Data ing basis data kasebut mung disimpen nganti proses nggunakake kasebut mandheg. Ora mbutuhake nggawe tabel lan ora mriksa integritas data.

Model obyek mock kelas sing diganti mung nganti pangembang tes ngerti cara kerjane.

Cara nggawe Postgres kanthi otomatis miwiti lan nindakake migrasi nalika sampeyan nganakake tes ora kasebut ing artikel Microsoft. Solusiku nindakake iki lan, saliyane, ora nambah kode khusus kanggo tes menyang microservice dhewe.

Ayo dadi pindhah menyang solusi

Sajrone proses pangembangan, dadi cetha yen tes unit ora cukup kanggo nemokake kabeh masalah ing wektu sing tepat, mula diputusake kanggo nyedhaki masalah iki saka sudut sing beda.

Nyetel lingkungan test

Tugas pisanan yaiku masang lingkungan tes. Langkah-langkah sing dibutuhake kanggo mbukak layanan mikro:

• Konfigurasi layanan sing diuji kanggo lingkungan lokal, nemtokake rincian kanggo nyambungake menyang database lan AWS ing variabel lingkungan;
• Miwiti Postgres lan nindakake migrasi kanthi mbukak Liquibase.
  Ing DBMS relasional, sadurunge nulis data menyang database, sampeyan kudu nggawe skema data, kanthi tembung liyane, tabel. Nalika nganyari aplikasi, tabel kudu digawa menyang formulir sing digunakake dening versi anyar, lan, luwih becik, tanpa kelangan data. Iki diarani migrasi. Nggawe tabel ing database pisanan kosong minangka kasus khusus migrasi. Migrasi bisa dibangun ing aplikasi kasebut dhewe. Loro .NET lan NodeJS duwe kerangka migrasi. Ing kasus kita, amarga alasan keamanan, microservices ora duwe hak kanggo ngganti skema data, lan migrasi ditindakake nggunakake Liquibase.
• Bukak Amazon LocalStack. Iki minangka implementasi layanan AWS kanggo mbukak ing omah. Ana gambar sing wis siap kanggo LocalStack ing Docker Hub.
• Jalanake skrip kanggo nggawe entitas sing dibutuhake ing LocalStack. Skrip Shell nggunakake AWS CLI.

Digunakake kanggo testing ing project Posmen. Wis ana sadurunge, nanging diluncurake kanthi manual lan nguji aplikasi sing wis dipasang ing stand. Alat iki ngidini sampeyan nggawe panjalukan HTTP(S) kanthi sewenang-wenang lan mriksa apa tanggapane kaya sing dikarepake. Pitakonan digabungake dadi koleksi, lan kabeh koleksi bisa ditindakake.

Kepiye cara tes otomatis?

Sajrone tes, kabeh bisa digunakake ing Docker: layanan sing diuji, Postgres, alat migrasi, lan Postman, utawa versi konsol - Newman.

Docker ngrampungake sawetara masalah:

• Kamardikan saka konfigurasi inang;
• Nginstal dependensi: Docker ndownload gambar saka Docker Hub;
• Mbalekake sistem menyang kahanan asline: mung mbusak wadhah kasebut.

Docker-ngarang nyawiji wadhah menyang jaringan virtual, diisolasi saka Internet, ing ngendi wadhah nemokake siji liyane kanthi jeneng domain.

Tes kasebut dikontrol dening skrip cangkang. Kanggo mbukak tes ing Windows kita nggunakake git-bash. Mangkono, siji skrip cukup kanggo Windows lan Linux. Git lan Docker diinstal dening kabeh pangembang ing proyek kasebut. Nalika nginstal Git ing Windows, git-bash wis diinstal, supaya saben wong uga duwe.

Skrip nindakake langkah-langkah ing ngisor iki:

• Gambar docker bangunan

  docker-compose build

• Bukak database lan LocalStack

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

• Migrasi database lan persiapan LocalStack

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

• Mbukak layanan ing test

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

• Running the test (Newman)
• Mungkasi kabeh kontaner

  docker-compose down

• Ngirim asil ing Slack
  We duwe chatting ngendi pesen karo checkmark ijo utawa salib abang lan link menyang log pindhah.

Gambar Docker ing ngisor iki melu langkah-langkah iki:

• Layanan sing diuji yaiku gambar sing padha karo produksi. Konfigurasi kanggo tes kasebut liwat variabel lingkungan.
• Kanggo Postgres, Redis lan LocalStack, gambar sing wis digawe saka Docker Hub digunakake. Ana uga gambar siap kanggo Liquibase lan Newman. We mbangun kita ing balung, nambah file kita ana.
• Kanggo nyiapake LocalStack, sampeyan nggunakake gambar AWS CLI sing wis siap lan nggawe gambar sing ngemot skrip adhedhasar.

Nggunakake volume, sampeyan ora kudu nggawe gambar Docker mung kanggo nambah file menyang wadhah. Nanging, volume ora cocog kanggo lingkungan kita amarga tugas Gitlab CI dhewe mlaku ing wadhah. Sampeyan bisa ngontrol Docker saka wadhah kasebut, nanging volume mung masang folder saka sistem inang, lan ora saka wadhah liyane.

Masalah sing bisa sampeyan temoni

Nunggu kesiapan

Nalika wadhah kanthi layanan mlaku, iki ora ateges wis siyap nampa sambungan. Sampeyan kudu ngenteni sambungan terus.

Masalah iki kadhangkala ditanggulangi kanthi nggunakake skrip ngenteni-kanggo-iku.sh, sing ngenteni kesempatan kanggo nggawe sambungan TCP. Nanging, LocalStack bisa mbuwang kesalahan 502 Bad Gateway. Kajaba iku, kasusun saka akeh layanan, lan yen salah siji saka wong-wong mau wis siyap, iki ora ngomong apa-apa bab liyane.

kaputusan: Skrip penyediaan LocalStack sing ngenteni 200 respon saka SQS lan SNS.

Konflik Tugas Paralel

Tes kaping pirang-pirang bisa mlaku bebarengan ing host Docker sing padha, saengga jeneng wadah lan jaringan kudu unik. Kajaba iku, tes saka macem-macem cabang layanan sing padha uga bisa mlaku bebarengan, saengga ora cukup nulis jenenge ing saben file sing digawe.

kaputusan: Skrip nyetel variabel COMPOSE_PROJECT_NAME dadi nilai unik.

Fitur Windows

Ana sawetara perkara sing pengin dakkandhakake nalika nggunakake Docker ing Windows, amarga pengalaman kasebut penting kanggo ngerti sebabe kesalahan.

1. Skrip cangkang ing wadhah kudu duwe ujung baris Linux.
   Simbol CR cangkang minangka kesalahan sintaks. Iku hard kanggo ngomong saka pesen kesalahan sing iki cilik. Nalika nyunting skrip kasebut ing Windows, sampeyan butuh editor teks sing tepat. Kajaba iku, sistem kontrol versi kudu dikonfigurasi kanthi bener.

Mangkene carane git dikonfigurasi:

git config core.autocrlf input

1. Git-bash niru folder Linux standar lan, nalika nelpon file exe (kalebu docker.exe), ngganti path Linux absolut karo jalur Windows. Nanging, iki ora nggawe pangertèn kanggo path ora ing mesin lokal (utawa path ing wadhah). Prilaku iki ora bisa dipateni.

kaputusan: nambah garis miring tambahan kanggo awal path: //bin tinimbang / bin. Linux ngerti dalan kasebut, sawetara garis miring padha karo siji. Nanging git-bash ora ngerteni dalan kasebut lan ora nyoba ngowahi.

Output log

Nalika mbukak tes, aku pengin ndeleng log saka Newman lan layanan sing dites. Amarga acara-acara log kasebut saling nyambungake, nggabungake ing siji konsol luwih trep tinimbang rong file sing kapisah. Newman diluncurake liwat docker-nyipta mbukak, lan output sawijining ends munggah ing console. Kabeh sing isih ana yaiku mesthekake yen output layanan kasebut uga ana.

Solusi asli kanggo nindakake docker-compose up ora gendéra -d, nanging nggunakake kemampuan cangkang, kirim proses iki menyang latar mburi:

docker-compose up <service> &

Iki bisa ditindakake nganti kudu ngirim log saka Docker menyang layanan pihak katelu. docker-compose up mandegake output log menyang console. Nanging, tim makarya docker attach.

kaputusan:

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

Konflik pengenal sajrone uji coba

Tes ditindakake ing pirang-pirang iterasi. Database ora dibusak. Cathetan ing basis data duwe ID unik. Yen kita nulis ID tartamtu ing panjalukan, kita bakal entuk konflik ing pengulangan kapindho.

Kanggo nyegah, ID kudu unik, utawa kabeh obyek sing digawe dening tes kudu dibusak. Sawetara obyek ora bisa dibusak amarga syarat.

kaputusan: ngasilake GUID nggunakake skrip Postman.

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

Banjur gunakake simbol ing pitakon {{myUUID}}, sing bakal diganti karo nilai variabel.

Kolaborasi liwat LocalStack

Yen layanan sing diuji maca utawa nulis menyang antrian SQS, banjur kanggo verifikasi iki, tes kasebut uga kudu bisa digunakake karo antrian iki.

kaputusan: panjalukan saka Postman kanggo LocalStack.

API layanan AWS didokumentasikake, ngidini pitakon digawe tanpa SDK.

Yen layanan nulis menyang antrian, banjur kita maca lan mriksa isi pesen kasebut.

Yen layanan ngirim pesen menyang SNS, ing tahap persiapan LocalStack uga nggawe antrian lan langganan topik SNS iki. Banjur iku kabeh nerangake apa sing wis diterangake ing ndhuwur.

Yen layanan kasebut kudu maca pesen saka antrian, banjur ing langkah tes sadurunge kita nulis pesen iki menyang antrian.

Nguji panjalukan HTTP sing asale saka layanan mikro sing dites

Sawetara layanan bisa digunakake liwat HTTP karo soko liyane saka AWS, lan sawetara fitur AWS ora dileksanakake ing LocalStack.

kaputusan: ing kasus iki bisa bantuan MockServer, sing nduweni gambar siap-digawe ing Hub Docker. Panjaluk lan tanggapan sing dikarepake dikonfigurasi kanthi panyuwunan HTTP. API kasebut didokumentasikake, mula kita njaluk saka Postman.

Nguji Authentication lan Wewenang OAuth

Kita nggunakake OAuth lan Token Web JSON (JWT). Tes kasebut mbutuhake panyedhiya OAuth sing bisa ditindakake sacara lokal.

Kabeh interaksi antarane layanan lan panyedhiya OAuth dadi rong panjalukan: pisanan, konfigurasi dijaluk /.kondhang/openid-configuration, banjur kunci umum (JWKS) dijaluk ing alamat saka konfigurasi. Kabeh iki isi statis.

kaputusan: Panyedhiya OAuth tes kita minangka server konten statis lan rong file ing kana. Token kasebut digawe sepisan lan setya marang Git.

Fitur tes SignalR

Tukang pos ora bisa nganggo soket web. Alat khusus digawe kanggo nyoba SignalR.

Klien SignalR bisa dadi luwih saka browser. Ana perpustakaan klien kanggo ing .NET Core. Klien, ditulis ing .NET Core, netepake sambungan, wis keasliane, lan ngenteni urutan tartamtu saka pesen. Yen pesen sing ora dikarepke ditampa utawa sambungan kasebut ilang, klien metu kanthi kode 1. Yen pesen pungkasan sing dikarepake ditampa, klien metu kanthi kode 0.

Newman dianggo bebarengan karo klien. Sawetara klien diluncurake kanggo mriksa manawa pesen dikirim menyang kabeh wong sing mbutuhake.

Kanggo mbukak sawetara klien nggunakake pilihan --skala ing baris perintah docker-compose.

Sadurunge mlaku, skrip Postman ngenteni kabeh klien nggawe sambungan.
Kita wis nemoni masalah ngenteni sambungan. Nanging ana server, lan iki klien. A pendekatan beda dibutuhake.

kaputusan: klien ing wadhah nggunakake mekanisme HealthCheckkanggo ngandhani skrip ing host babagan statuse. Klien nggawe file ing jalur tartamtu, ucapake /healthcheck, sanalika sambungan digawe. Skrip HealthCheck ing file docker katon kaya iki:

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

tim docker mriksa Nuduhake status normal, status kesehatan lan kode metu kanggo wadhah.

Sawise Newman rampung, skrip mriksa manawa kabeh wadhah karo klien wis mandheg, kanthi kode 0.

Happinnes ana

Sawise kita ngatasi kangelan kasebut ing ndhuwur, kita wis pesawat saka tes mlaku stabil. Ing tes, saben layanan dianggo minangka unit siji, sesambungan karo database lan Amazon LocalStack.

Tes iki nglindhungi tim 30+ pangembang saka kesalahan ing aplikasi kanthi interaksi kompleks 10+ layanan mikro kanthi panyebaran sing kerep.

Source: www.habr.com