Kami di True Engineering parantos nyetél prosés pikeun pangiriman kontinyu apdet ka server palanggan sareng hoyong bagikeun pangalaman ieu.
Pikeun mimitian, kami ngembangkeun sistem online pikeun nasabah sareng nyebarkeun éta dina klaster Kubernetes urang sorangan. Ayeuna solusi beban tinggi kami parantos ngalih ka platform palanggan, dimana kami parantos nyetél prosés Deployment Kontinyu otomatis otomatis. Hatur nuhun kana ieu, urang ngagancangkeun waktos-ka-pasar - pangiriman parobahan lingkungan produk.
Dina artikel ieu kami bakal ngobrol ngeunaan sagala tahapan prosés Continuous Deployment (CD) atanapi pangiriman apdet kana platform palanggan:
- Kumaha prosés ieu dimimitian?
- singkronisasi sareng gudang Git palanggan,
- rakitan backend sareng frontend,
- deployment aplikasi otomatis dina lingkungan test,
- deployment otomatis pikeun Prod.
Kami bakal ngabagikeun detil setelan sapanjang jalan.
1. Mimitian CD
Panyebaran Kontinyu dimimitian ku pamekar ngadorong parobahan kana cabang sékrési gudang Git kami.
Aplikasi kami dijalankeun dina arsitektur microservice sareng sadaya komponénna disimpen dina hiji gudang. Hatur nuhun kana ieu, sadaya microservices dikumpulkeun sarta dipasang, sanajan salah sahijina geus robah.
Urang ngatur gawé ngaliwatan hiji gudang pikeun sababaraha alesan:
- Gampang pamekaran - aplikasi aktip berkembang, ku kituna anjeun tiasa damel sareng sadaya kode sakaligus.
- Pipa CI / CD tunggal anu ngajamin yén aplikasi salaku sistem tunggal ngalangkungan sadaya tés sareng dikirimkeun ka lingkungan produksi palanggan.
- Urang ngaleungitkeun kabingungan dina versi - urang teu kudu nyimpen peta ngeunaan versi microservice sarta ngajelaskeun konfigurasi na pikeun tiap microservice dina Aksara Helm.
2. Sinkronisasi sareng gudang Git kode sumber palanggan
Parobihan anu dilakukeun sacara otomatis disingkronkeun sareng gudang Git palanggan. Aya assembly aplikasi geus ngonpigurasi, nu dibuka sanggeus ngamutahirkeun cabang, sarta deployment kana tuluyan. Duanana prosés asalna di lingkunganana tina gudang Git.
Kami henteu tiasa damel langsung sareng gudang palanggan sabab kami peryogi lingkungan urang sorangan pikeun pangwangunan sareng uji. Kami nganggo gudang Git kami pikeun tujuan ieu - éta disingkronkeun sareng gudang Git na. Pas pamekar posting robah kana cabang luyu tina gudang urang, GitLab geuwat ngadorong parobahan ieu ka konsumén.
Sanggeus ieu anjeun kudu ngalakukeun assembly nu. Ieu diwangun ku sababaraha tahapan: backend na frontend assembly, nguji sarta pangiriman ka produksi.
3. Assembling backend na frontend
Ngawangun backend sareng frontend mangrupikeun dua tugas paralel anu dilakukeun dina sistem GitLab Runner. Konfigurasi assembly aslina ieu lokasina di gudang sarua.
.
GitLab Runner nyandak kodeu tina gudang anu diperyogikeun, ngumpulna nganggo paréntah ngawangun aplikasi Java sareng ngirimkeunana ka pendaptaran Docker. Di dieu urang ngumpul backend na frontend, ménta gambar Docker, nu urang nempatkeun kana gudang di sisi customer urang. Pikeun ngatur gambar Docker kami nganggo .
Kami nyingkronkeun versi gambar urang sareng versi pelepasan anu bakal dipedalkeun dina Docker. Pikeun operasi lancar kami parantos ngadamel sababaraha panyesuaian:
1. Wadahna henteu diwangun deui antara lingkungan uji sareng lingkungan produksi. Kami ngadamel parametrizasi supados wadah anu sami tiasa dianggo sareng sadaya setélan, variabel lingkungan sareng jasa boh dina lingkungan uji sareng dina produksi tanpa ngawangun deui.
2. Pikeun ngapdet hiji aplikasi via Helm, anjeun kudu nangtukeun versi na. Kami ngawangun backend, frontend sareng ngapdet aplikasi - ieu mangrupikeun tilu tugas anu béda, janten penting pikeun nganggo versi aplikasi anu sami dimana-mana. Pikeun tugas ieu, kami nganggo data tina sajarah Git, sabab konfigurasi kluster sareng aplikasi K8S kami aya dina gudang Git anu sami.
Kami nampi versi aplikasi tina hasil palaksanaan paréntah
git describe --tags --abbrev=7.
4. deployment otomatis sadaya parobahan lingkungan test (UAT)
Lengkah saterusna dina Aksara ngawangun ieu otomatis ngamutahirkeun klaster K8S. Ieu lumangsung upami sadayana aplikasi parantos diwangun sareng sadaya artefak parantos diterbitkeun kana Docker Registry. Saatos ieu, apdet lingkungan tés dimimitian.
Pembaruan klaster dimimitian nganggo . Lamun, salaku hasilna, hal teu balik nurutkeun rencana, Helm otomatis tur bebas gulung deui sagala parobahanana. Karyana teu perlu dikawasa.
Urang nyadiakeun konfigurasi klaster K8S sapanjang kalawan assembly nu. Ku alatan éta, lengkah saterusna nyaéta ngamutahirkeun eta: configMaps, deployments, jasa, Rahasia tur sagala konfigurasi K8S séjén yén kami geus robah.
Helm lajeng ngajalankeun update RollOut tina aplikasi sorangan dina lingkungan test. Sateuacan aplikasi ieu deployed ka produksi. Hal ieu dilakukeun supados pangguna tiasa nguji sacara manual fitur bisnis anu kami pasang kana lingkungan uji.
5. deployment otomatis sadaya parobahan Prod
Pikeun nyebarkeun pembaruan ka lingkungan produksi, anjeun ngan ukur kedah klik hiji tombol di GitLab - sareng wadahna langsung dikirimkeun ka lingkungan produksi.
Aplikasi anu sami tiasa dianggo dina lingkungan anu béda-uji sareng produksi-tanpa ngawangun deui. Urang make artefak sarua tanpa ngarobah nanaon dina aplikasi, sarta kami nyetél parameter externally.
Parameterisasi fleksibel tina setélan aplikasi gumantung kana lingkungan dimana aplikasi bakal dieksekusi. Kami geus dipindahkeun sakabéh setélan lingkungan externally: sagalana geus parameterized ngaliwatan konfigurasi K8S sarta parameter Helm. Nalika Helm nyebarkeun rakitan ka lingkungan tés, setélan tés diterapkeun ka dinya, sareng setélan produk diterapkeun ka lingkungan produksi.
Hal paling hese éta parameterize sakabeh jasa dipaké sarta variabel anu gumantung kana lingkungan, sarta narjamahkeun kana variabel lingkungan jeung déskripsi-konfigurasi parameter lingkungan pikeun Helm.
Setélan aplikasi ngagunakeun variabel lingkungan. Nilaina disetél dina wadah nganggo configmap K8S, anu dicitak nganggo témplat Go. Salaku conto, netepkeun variabel lingkungan kana nami domain tiasa dilakukeun sapertos kieu:
APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}
.Values.global.env - variabel ieu nyimpen nami lingkungan (prod, panggung, UAT).
.Values.app.properties.app_external_domain – dina variabel ieu urang nyetel domain nu dipikahoyong dina file .Values.yaml
Nalika ngamutahirkeun hiji aplikasi, nyieun Helm file configmap.yaml tina témplat sarta eusian nilai APP_EXTERNAL_DOMAIN kalawan nilai nu dipikahoyong gumantung kana lingkungan dimana apdet aplikasi dimimitian. Variabel ieu tos disetél dina wadahna. Éta tiasa diaksés tina aplikasi, janten unggal lingkungan aplikasi bakal gaduh nilai anu béda pikeun variabel ieu.
Relatip nembe, dukungan K8S muncul dina Spring Cloud, kalebet damel sareng configMaps: . Nalika proyék éta aktip ngembangkeun sareng robih sacara radikal, urang henteu tiasa dianggo dina produksi. Tapi kami aktip ngawas kaayaanana sareng dianggo dina konfigurasi DEV. Pas eta stabilizes, urang bakal pindah ti ngagunakeun variabel lingkungan eta.
dina total
Janten, Deployment Continuous dikonpigurasi sareng jalan. Sadaya apdet lumangsung kalawan hiji keystroke. Pangiriman parobahan ka lingkungan produk otomatis. Sareng, anu penting, pembaruan henteu ngeureunkeun sistem.
Rencana hareup: migrasi database otomatis
Urang panginten ngeunaan ningkatkeun pangkalan data sareng kamungkinan ngagulung deui parobihan ieu. Barina ogé, dua vérsi aplikasi anu béda dijalankeun dina waktos anu sami: anu lami dijalankeun, sareng anu énggal naék. Sarta kami bakal mareuman hiji heubeul ngan lamun urang yakin yén versi anyar jalan. Migrasi database kedah ngidinan Anjeun pikeun digawekeun ku duanana versi aplikasi.
Ku alatan éta, urang teu bisa saukur ngarobah ngaran kolom atawa data séjén. Tapi urang bisa nyieun hiji kolom anyar, nyalin data tina kolom heubeul ka dinya jeung nulis micu anu, nalika ngamutahirkeun data, sakaligus bakal nyalin tur ngamutahirkeun eta dina kolom sejen. Sareng saatos panyebaran anu suksés tina versi énggal tina aplikasi, saatos periode dukungan pos peluncuran, urang bakal tiasa ngahapus kolom anu lami sareng pemicu anu henteu diperyogikeun.
Lamun versi anyar tina aplikasi nu teu jalan leres, urang tiasa gulung deui ka versi saméméhna, kaasup versi saméméhna tina database. Pondokna, parobihan kami bakal ngamungkinkeun anjeun damel sakaligus sareng sababaraha vérsi aplikasi.
Kami ngarencanakeun pikeun ngajadikeun otomatis migrasi database ku padamelan K8S, ngahijikeun kana prosés CD. Sarta kami pasti bakal babagi pangalaman ieu dina Habré.
sumber: www.habr.com