Mi u True Engineering-u smo postavili proces za kontinuiranu isporuku ažuriranja na servere korisnika i želimo da podijelimo ovo iskustvo.
Za početak smo razvili online sistem za kupca i implementirali ga u vlastiti Kubernetes klaster. Sada se naše rješenje s velikim opterećenjem preselilo na platformu korisnika, za koju smo postavili potpuno automatski proces kontinuirane implementacije. Zahvaljujući tome, ubrzali smo vrijeme izlaska na tržište - isporuku promjena u okruženju proizvoda.
U ovom članku ćemo govoriti o svim fazama procesa kontinuirane implementacije (CD) ili isporuke ažuriranja na platformu korisnika:
- Kako počinje ovaj proces?
- sinhronizacija sa Git repozitorijumom korisnika,
- sklapanje backenda i frontenda,
- automatska implementacija aplikacije u testnom okruženju,
- automatsko raspoređivanje na Prod.
Usput ćemo podijeliti detalje o postavljanju.
1. Pokrenite CD
Kontinuirana implementacija počinje tako što programer gura promjene u granu izdanja našeg Git repozitorija.
Naša aplikacija radi na mikroservisnoj arhitekturi i sve njene komponente su pohranjene u jednom spremištu. Zahvaljujući tome, sve mikroservise se prikupljaju i instaliraju, čak i ako se jedan od njih promijenio.
Organizovali smo rad kroz jedno spremište iz nekoliko razloga:
- Lakoća razvoja - aplikacija se aktivno razvija, tako da možete raditi sa svim kodom odjednom.
- Jedinstveni CI/CD cevovod koji garantuje da aplikacija kao jedinstven sistem prolazi sve testove i isporučuje se u proizvodno okruženje korisnika.
- Uklanjamo zabunu u verzijama - ne moramo pohranjivati mapu verzija mikroservisa i opisivati njihovu konfiguraciju za svaku mikroservis u Helm skriptama.
2. Sinhronizacija sa Git repozitorijumom izvornog koda korisnika
Izmjene se automatski sinkroniziraju sa Git repozitorijumom korisnika. Tamo se konfiguriše sklop aplikacije, koji se pokreće nakon ažuriranja grane i implementacije do nastavka. Oba procesa potiču u svom okruženju iz Git repozitorija.
Ne možemo direktno raditi sa kupčevim repozitorijumom jer su nam potrebna vlastita okruženja za razvoj i testiranje. Mi koristimo naše Git spremište za ove svrhe - sinkronizirano je s njihovim Git repozitorijumom. Čim programer objavi promjene u odgovarajućoj grani našeg spremišta, GitLab odmah prosljeđuje ove promjene korisniku.
Nakon toga morate obaviti montažu. Sastoji se od nekoliko faza: backend i frontend montaža, testiranje i isporuka u proizvodnju.
3. Sastavljanje pozadine i frontenda
Izgradnja pozadine i frontenda su dva paralelna zadatka koja se izvode u GitLab Runner sistemu. Njegova originalna konfiguracija sklopa nalazi se u istom spremištu.
.
GitLab Runner uzima kod iz potrebnog spremišta, sklapa ga komandom za izgradnju Java aplikacije i šalje ga u Docker registar. Ovdje sastavljamo backend i frontend, dobijamo Docker slike, koje stavljamo u spremište na strani korisnika. Za upravljanje Docker slikama koje koristimo .
Sinkroniziramo verzije naših slika s izdanom verzijom koja će biti objavljena u Dockeru. Za nesmetan rad napravili smo nekoliko podešavanja:
1. Kontejneri se ne rekonstruišu između testnog okruženja i proizvodnog okruženja. Napravili smo parametre tako da isti kontejner može raditi sa svim postavkama, varijablama okruženja i uslugama kako u testnom okruženju tako iu produkciji bez rekonstrukcije.
2. Da biste ažurirali aplikaciju putem Helm-a, morate navesti njenu verziju. Gradimo backend, frontend i ažuriramo aplikaciju – to su tri različita zadatka, pa je važno svuda koristiti istu verziju aplikacije. Za ovaj zadatak koristimo podatke iz Git historije, budući da se naša K8S konfiguracija klastera i aplikacije nalaze u istom Git spremištu.
Verziju aplikacije dobijamo iz rezultata izvršenja naredbe
git describe --tags --abbrev=7.
4. Automatsko uvođenje svih promjena u test okruženje (UAT)
Sljedeći korak u ovoj skripti za izgradnju je automatsko ažuriranje K8S klastera. Ovo se događa pod uvjetom da je cijela aplikacija izgrađena i da su svi artefakti objavljeni u Docker Registry. Nakon toga počinje ažuriranje testnog okruženja.
Ažuriranje klastera je pokrenuto korištenjem . Ako, kao rezultat, nešto nije išlo po planu, Helm će automatski i samostalno poništiti sve svoje promjene. Njegov rad ne treba kontrolisati.
Isporučujemo K8S klaster konfiguraciju zajedno sa sklopom. Stoga je sljedeći korak da ga ažuriramo: configMaps, implementacije, usluge, tajne i sve druge K8S konfiguracije koje smo promijenili.
Helm zatim pokreće RollOut ažuriranje same aplikacije u testnom okruženju. Prije nego što se aplikacija implementira u proizvodnju. Ovo se radi kako bi korisnici mogli ručno testirati poslovne karakteristike koje smo stavili u testno okruženje.
5. Automatsko postavljanje svih promjena u Proz
Da biste implementirali ažuriranje u proizvodno okruženje, potrebno je samo da kliknete na jedno dugme u GitLabu - i kontejneri se odmah isporučuju u proizvodno okruženje.
Ista aplikacija može raditi u različitim okruženjima – testnim i proizvodnim – bez ponovne izgradnje. Koristimo iste artefakte bez promjene bilo čega u aplikaciji, a parametre postavljamo eksterno.
Fleksibilno parametriranje postavki aplikacije ovisi o okruženju u kojem će se aplikacija izvršavati. Sve postavke okruženja smo pomerili spolja: sve je parametrizovano kroz K8S konfiguraciju i Helm parametre. Kada Helm implementira sklop u testno okruženje, testne postavke se primjenjuju na njega, a postavke proizvoda primjenjuju se na proizvodno okruženje.
Najteže je bilo parametrizovati sve korišćene servise i varijable koje zavise od okruženja i prevesti ih u varijable okruženja i opis-konfiguracije parametara okruženja za Helm.
Postavke aplikacije koriste varijable okruženja. Njihove vrijednosti se postavljaju u kontejnere koristeći K8S configmap, koji je šabloniziran pomoću Go predložaka. Na primjer, postavljanje varijable okruženja na ime domene može se učiniti ovako:
APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}
.Values.global.env – ova varijabla pohranjuje ime okruženja (prod, stage, UAT).
.Values.app.properties.app_external_domain – u ovoj varijabli postavljamo željeni domen u datoteci .Values.yaml
Prilikom ažuriranja aplikacije, Helm kreira datoteku configmap.yaml iz predložaka i popunjava vrijednost APP_EXTERNAL_DOMAIN željenom vrijednošću ovisno o okruženju u kojem započinje ažuriranje aplikacije. Ova varijabla je već postavljena u kontejneru. Može se pristupiti iz aplikacije, tako da će svako okruženje aplikacije imati različitu vrijednost za ovu varijablu.
Relativno nedavno, podrška za K8S pojavila se u Spring Cloud-u, uključujući rad sa configMaps: . Dok se projekat aktivno razvija i radikalno se mijenja, ne možemo ga koristiti u proizvodnji. Ali mi aktivno pratimo njegovo stanje i koristimo ga u DEV konfiguracijama. Čim se stabilizira, prebacit ćemo se s korištenja varijabli okruženja na njega.
Ukupno
Dakle, kontinuirana implementacija je konfigurirana i radi. Sva ažuriranja se odvijaju jednim pritiskom na tipku. Dostava izmjena u okruženje proizvoda je automatska. I, što je najvažnije, ažuriranja ne zaustavljaju sistem.
Planovi za budućnost: automatska migracija baze podataka
Razmišljali smo o nadogradnji baze podataka i mogućnosti vraćanja ovih promjena. Na kraju krajeva, dvije različite verzije aplikacije rade u isto vrijeme: stara je pokrenuta, a nova je pokrenuta. A staru ćemo isključiti tek kada budemo sigurni da nova verzija radi. Migracija baze podataka trebala bi vam omogućiti rad s obje verzije aplikacije.
Stoga ne možemo jednostavno promijeniti naziv stupca ili druge podatke. Ali možemo kreirati novu kolonu, kopirati podatke iz stare kolone u nju i napisati okidače koji će ih, prilikom ažuriranja podataka, istovremeno kopirati i ažurirati u drugoj koloni. A nakon uspješnog postavljanja nove verzije aplikacije, nakon perioda podrške nakon pokretanja, moći ćemo izbrisati staru kolonu i okidač koji je postao nepotreban.
Ako nova verzija aplikacije ne radi ispravno, možemo se vratiti na prethodnu verziju, uključujući prethodnu verziju baze podataka. Ukratko, naše promjene će vam omogućiti da radite istovremeno s nekoliko verzija aplikacije.
Planiramo automatizirati migraciju baze podataka putem K8S posla, integrirajući je u CD proces. I definitivno ćemo ovo iskustvo podijeliti na Habréu.
izvor: www.habr.com