Kita ing True Engineering wis nyiyapake proses kanggo ngirim nganyari terus menyang server pelanggan lan pengin nuduhake pengalaman iki.
Kanggo miwiti, kita ngembangake sistem online kanggo pelanggan lan nyebarake ing kluster Kubernetes dhewe. Saiki solusi beban dhuwur wis dipindhah menyang platform pelanggan, sing wis nyiyapake proses Penyebaran Terus-terusan kanthi otomatis. Thanks kanggo iki, kita nyepetake wektu-kanggo-pasar - pangiriman owah-owahan ing lingkungan produk.
Ing artikel iki kita bakal ngomong babagan kabeh tahapan proses Penyebaran Terus (CD) utawa pangiriman nganyari menyang platform pelanggan:
- Kepiye proses iki diwiwiti?
- sinkronisasi karo repositori Git pelanggan,
- perakitan backend lan frontend,
- panyebaran aplikasi otomatis ing lingkungan tes,
- penyebaran otomatis menyang Prod.
Kita bakal nuduhake rincian persiyapan ing dalan.
1. Miwiti CD
Penyebaran Terus-terusan diwiwiti kanthi pangembang nyurung owah-owahan menyang cabang rilis gudang Git kita.
Aplikasi kita nganggo arsitektur layanan mikro lan kabeh komponen disimpen ing siji gudang. Thanks kanggo iki, kabeh layanan mikro diklumpukake lan diinstal, sanajan salah sijine wis diganti.
Kita ngatur karya liwat siji repositori amarga sawetara alasan:
- Gampang pangembangan - aplikasi kasebut aktif berkembang, supaya sampeyan bisa nggarap kabeh kode bebarengan.
- Pipa CI / CD siji sing njamin yen aplikasi minangka sistem siji ngliwati kabeh tes lan dikirim menyang lingkungan produksi pelanggan.
- Kita ngilangi kebingungan ing versi - kita ora kudu nyimpen peta versi microservice lan njlèntrèhaké konfigurasi kanggo saben microservice ing skrip Helm.
2. Sinkronisasi karo repositori Git kode sumber pelanggan
Owah-owahan sing ditindakake kanthi otomatis disinkronake karo repositori Git pelanggan. Ana perakitan aplikasi dikonfigurasi, sing diluncurake sawise nganyari cabang, lan penyebaran menyang terusan. Kaloro proses kasebut asale saka lingkungane saka repositori Git.
Kita ora bisa nggarap gudang pelanggan kanthi langsung amarga kita butuh lingkungan dhewe kanggo pangembangan lan tes. Kita nggunakake repositori Git kanggo tujuan kasebut - disinkronake karo repositori Git. Sanalika pangembang ngirim owah-owahan menyang cabang repositori sing cocog, GitLab langsung nyurung owah-owahan kasebut menyang pelanggan.
Sawise iki sampeyan kudu nindakake perakitan. Iku kasusun saka sawetara orane tumrap sekolah: backend lan frontend perakitan, testing lan pangiriman kanggo produksi.
3. Ngrakit backend lan frontend
Mbangun backend lan frontend minangka rong tugas paralel sing ditindakake ing sistem GitLab Runner. Konfigurasi perakitan asli dumunung ing repositori sing padha.
.
GitLab Runner njupuk kode saka repositori sing dibutuhake, ngumpulake karo perintah mbangun aplikasi Java lan dikirim menyang registri Docker. Ing kene kita ngumpulake backend lan frontend, entuk gambar Docker, sing dilebokake ing gudang ing sisih pelanggan. Kanggo ngatur gambar Docker digunakake .
Kita nyinkronake versi gambar kita karo versi rilis sing bakal diterbitake ing Docker. Kanggo operasi lancar, kita wis nggawe sawetara pangaturan:
1. Wadhah ora dibangun maneh antarane lingkungan test lan lingkungan produksi. Kita nggawe parametrizasi supaya wadhah sing padha bisa digunakake karo kabeh setelan, variabel lingkungan lan layanan ing lingkungan tes lan ing produksi tanpa mbangun maneh.
2. Kanggo nganyari aplikasi liwat Helm, sampeyan kudu nemtokake versi. Kita mbangun backend, frontend lan nganyari aplikasi - iki telung tugas sing beda-beda, dadi penting kanggo nggunakake versi aplikasi sing padha ing endi wae. Kanggo tugas iki, kita nggunakake data saka riwayat Git, amarga konfigurasi kluster K8S lan aplikasi ana ing gudang Git sing padha.
Kita entuk versi aplikasi saka asil eksekusi perintah
git describe --tags --abbrev=7.
4. Penyebaran otomatis kabeh owah-owahan ing lingkungan tes (UAT)
Langkah sabanjure ing skrip mbangun iki yaiku nganyari kluster K8S kanthi otomatis. Iki kedadeyan yen kabeh aplikasi wis dibangun lan kabeh artefak wis diterbitake menyang Docker Registry. Sawise iki, nganyari lingkungan test diwiwiti.
Nganyari kluster wiwit digunakake . Yen, minangka asil, soko ora mlaku miturut rencana, Helm bakal kanthi otomatis lan independen muter kabeh owah-owahan sawijining. Karyane ora perlu dikontrol.
Kita nyedhiyakake konfigurasi kluster K8S bebarengan karo perakitan. Mula, langkah sabanjure yaiku nganyari: configMaps, penyebaran, layanan, rahasia lan konfigurasi K8S liyane sing wis diganti.
Helm banjur mbukak nganyari RollOut saka aplikasi dhewe ing lingkungan test. Sadurunge aplikasi disebarake menyang produksi. Iki ditindakake supaya pangguna bisa nyoba kanthi manual fitur bisnis sing dilebokake ing lingkungan tes.
5. Penyebaran otomatis kabeh owah-owahan menyang Prod
Kanggo nyebarake nganyari menyang lingkungan produksi, sampeyan mung kudu ngeklik tombol siji ing GitLab - lan wadhah kasebut langsung dikirim menyang lingkungan produksi.
Aplikasi sing padha bisa digunakake ing macem-macem lingkungan-tes lan produksi-tanpa mbangun maneh. Kita nggunakake artefak padha tanpa ngganti apa-apa ing aplikasi, lan kita nyetel paramèter externally.
Parameterisasi fleksibel setelan aplikasi gumantung ing lingkungan ing ngendi aplikasi bakal dieksekusi. Kita wis mindhah kabeh setelan lingkungan externally: kabeh wis parameterized liwat konfigurasi K8S lan paramèter Helm. Nalika Helm nyebarake perakitan menyang lingkungan tes, setelan tes ditrapake, lan setelan produk ditrapake ing lingkungan produksi.
Wangsulan: Bab ingkang paling angel ana parameterize kabeh layanan digunakake lan variabel sing gumantung ing lingkungan, lan nerjemahake menyang variabel lingkungan lan gambaran-konfigurasi paramèter lingkungan kanggo Helm.
Setelan aplikasi nggunakake variabel lingkungan. Nilai kasebut disetel ing kontaner nggunakake configmap K8S, sing digawe template nggunakake template Go. Contone, nyetel variabel lingkungan menyang jeneng domain bisa ditindakake kaya iki:
APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}
.Values.global.env – variabel iki nyimpen jeneng lingkungan (prod, panggung, UAT).
.Values.app.properties.app_external_domain – ing variabel iki kita nyetel domain sing dikarepake ing file .Values.yaml
Nalika nganyari aplikasi, nggawe Helm file configmap.yaml saka cithakan lan isi APP_EXTERNAL_DOMAIN Nilai karo nilai sing dikarepake gumantung ing lingkungan kang nganyari aplikasi diwiwiti. Variabel iki wis disetel ing wadhah. Bisa diakses saka aplikasi, supaya saben lingkungan aplikasi bakal duwe nilai beda kanggo variabel iki.
Relatif bubar, dhukungan K8S muncul ing Spring Cloud, kalebu nggarap configMaps: . Nalika proyek kasebut aktif berkembang lan ganti kanthi radikal, kita ora bisa nggunakake ing produksi. Nanging kita aktif ngawasi kondisi kasebut lan digunakake ing konfigurasi DEV. Sanalika stabil, kita bakal ngalih saka nggunakake variabel lingkungan.
Total
Dadi, Penyebaran Terus-terusan dikonfigurasi lan digunakake. Kabeh nganyari dumadi kanthi siji keystroke. Pangiriman owah-owahan menyang lingkungan produk kanthi otomatis. Lan, sing penting, nganyari ora mandhegake sistem kasebut.
Rencana mangsa ngarep: migrasi database otomatis
Kita mikir babagan nganyarke database lan kemungkinan nggulung maneh owah-owahan kasebut. Sawise kabeh, rong versi aplikasi sing beda-beda mlaku bebarengan: sing lawas mlaku, lan sing anyar munggah. Lan kita bakal mateni sing lawas mung yen kita yakin manawa versi anyar bisa digunakake. Migrasi basis data kudu ngidini sampeyan nggarap versi loro aplikasi kasebut.
Mulane, kita ora bisa mung ngganti jeneng kolom utawa data liyane. Nanging kita bisa nggawe kolom anyar, nyalin data saka kolom lawas menyang lan nulis pemicu sing, nalika nganyari data, bakal bebarengan nyalin lan nganyari ing kolom liyane. Lan sawise panyebaran sukses versi aplikasi anyar, sawise periode dhukungan pasca peluncuran, kita bakal bisa mbusak kolom lawas lan pemicu sing ora perlu.
Yen versi anyar saka aplikasi ora bisa digunakake kanthi bener, kita bisa muter maneh menyang versi sadurungé, kalebu versi sadurungé saka database. Ing cendhak, owah-owahan kita bakal ngidini sampeyan bisa bebarengan karo sawetara versi aplikasi.
Kita rencana kanggo ngotomatisasi migrasi database liwat proyek K8S, nggabungake menyang proses CD. Lan kita mesthi bakal nuduhake pengalaman iki ing Habré.
Source: www.habr.com