Mi u True Engineeringu postavili smo proces za kontinuiranu isporuku ažuriranja korisničkim poslužiteljima i želimo podijeliti ovo iskustvo.
Za početak smo razvili online sustav za kupca i implementirali ga u vlastiti Kubernetes klaster. Sada se naše visokoopterećeno rješenje preselilo na platformu korisnika, za koju smo postavili potpuno automatski proces kontinuirane implementacije. Zahvaljujući tome, ubrzali smo vrijeme do tržišta - isporuku promjena u okruženju proizvoda.
U ovom ćemo članku govoriti o svim fazama procesa kontinuirane implementacije (CD) ili isporuke ažuriranja na platformu korisnika:
- Kako ovaj proces počinje?
- sinkronizacija s korisnikovim Git spremištem,
- sastavljanje backend-a i frontend-a,
- automatsku implementaciju aplikacije u testnom okruženju,
- automatska implementacija u proizv.
Usput ćemo podijeliti detalje postavljanja.
1. Pokrenite CD
Kontinuirana implementacija počinje tako da programer unese promjene u granu izdanja našeg Git repozitorija.
Naša aplikacija radi na mikroservisnoj arhitekturi i sve njene komponente pohranjene su u jednom repozitoriju. Zahvaljujući tome, svi mikroservisi su prikupljeni i instalirani, čak i ako je jedan od njih promijenjen.
Organizirali smo rad preko jednog repozitorija iz nekoliko razloga:
- Jednostavnost razvoja - aplikacija se aktivno razvija, tako da možete raditi sa svim kodom odjednom.
- Jedan CI/CD cjevovod koji jamči da aplikacija kao jedan sustav prolazi sve testove i isporučuje se proizvodnom okruženju kupca.
- Otklanjamo zabunu u verzijama - ne moramo pohranjivati mapu verzija mikroservisa i opisivati njegovu konfiguraciju za svaki mikroservis u Helm skriptama.
2. Sinkronizacija s Git repozitorijem izvornog koda korisnika
Promjene se automatski sinkroniziraju s korisnikovim Git spremištem. Tamo se konfigurira sklop aplikacije, koji se pokreće nakon ažuriranja grane i postavljanja na nastavak. Oba procesa potječu iz svog okruženja iz Git repozitorija.
Ne možemo izravno raditi s kupčevim repozitorijem jer su nam potrebna vlastita okruženja za razvoj i testiranje. U te svrhe koristimo naš Git repozitorij - sinkroniziran je s njihovim Git repozitorijem. Čim razvojni programer objavi promjene u odgovarajućoj grani našeg repozitorija, GitLab odmah šalje te promjene korisniku.
Nakon toga morate izvršiti montažu. Sastoji se od nekoliko faza: backend i frontend montaža, testiranje i isporuka u proizvodnju.
3. Sastavljanje pozadine i sučelja
Izgradnja backend-a i frontend-a dva su paralelna zadatka koja se izvode u sustavu GitLab Runner. Njegova izvorna konfiguracija sklopa nalazi se u istom repozitoriju.
.
GitLab Runner preuzima kod iz potrebnog repozitorija, sastavlja ga naredbom za izgradnju Java aplikacije i šalje u Docker registar. Ovdje sastavljamo backend i frontend, dobivamo Docker slike koje stavljamo u repozitorij na strani kupca. Za upravljanje Docker slikama koje koristimo .
Sinkroniziramo verzije naših slika s verzijom izdanja koja će biti objavljena u Dockeru. Za neometan rad napravili smo nekoliko prilagodbi:
1. Spremnici se ne izgrađuju između testnog okruženja i proizvodnog okruženja. Napravili smo parametre tako da isti spremnik može raditi sa svim postavkama, varijablama okruženja i uslugama u testnom okruženju iu produkciji bez ponovne izgradnje.
2. Da biste ažurirali aplikaciju putem Helma, morate navesti njezinu verziju. Izrađujemo backend, frontend i ažuriramo aplikaciju - to su tri različita zadatka, stoga je važno svugdje koristiti istu verziju aplikacije. Za ovaj zadatak koristimo podatke iz Git povijesti, budući da su naša konfiguracija K8S klastera i aplikacije u istom Git repozitoriju.
Iz rezultata izvršenja naredbe dobivamo verziju aplikacije
git describe --tags --abbrev=7.
4. Automatska implementacija svih promjena u testnom okruženju (UAT)
Sljedeći korak u ovoj skripti za izgradnju je automatsko ažuriranje K8S klastera. To se događa pod uvjetom da je cijela aplikacija izgrađena i da su svi artefakti objavljeni u Docker registru. Nakon toga počinje ažuriranje testnog okruženja.
Ažuriranje klastera je pokrenuto pomoću . Ako zbog toga nešto nije išlo po planu, Helm će automatski i samostalno vratiti sve svoje promjene. Njegov rad ne treba kontrolirati.
Konfiguraciju klastera K8S isporučujemo zajedno sa sklopom. Stoga je sljedeći korak njegovo ažuriranje: configMaps, implementacije, usluge, tajne i sve ostale konfiguracije K8S-a koje smo promijenili.
Helm zatim pokreće RollOut ažuriranje same aplikacije u testnom okruženju. Prije nego što se aplikacija postavi u proizvodnju. To je učinjeno kako bi korisnici mogli ručno testirati poslovne značajke koje stavljamo u testno okruženje.
5. Automatska implementacija svih promjena u Prod
Da biste implementirali ažuriranje u proizvodno okruženje, samo trebate kliknuti jedan gumb u GitLabu - i spremnici se odmah isporučuju u proizvodno okruženje.
Ista aplikacija može raditi u različitim okruženjima—testiranje i proizvodnja—bez ponovne izgradnje. Koristimo iste artefakte ne mijenjajući ništa u aplikaciji, a parametre postavljamo eksterno.
Fleksibilna parametrizacija postavki aplikacije ovisi o okruženju u kojem će se aplikacija izvoditi. Premjestili smo sve postavke okruženja izvana: sve je parametrizirano kroz konfiguraciju K8S i parametre Helma. 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 parametrizirati sve korištene usluge i varijable koje ovise o okruženju, te ih prevesti u varijable okruženja i opise-konfiguracije parametara okruženja za Helm.
Postavke aplikacije koriste varijable okruženja. Njihove vrijednosti postavljaju se u spremnike pomoću K8S configmapa, koji je predložak pomoću Go predložaka. Na primjer, postavljanje varijable okoline na naziv domene može se učiniti ovako:
APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}
.Vrijednosti.global.env – ova varijabla pohranjuje naziv okruženja (prod, stage, UAT).
.Values.app.properties.app_external_domain – u ovoj varijabli postavljamo željenu domenu u datoteci .Values.yaml
Prilikom ažuriranja aplikacije, Helm iz predložaka stvara datoteku configmap.yaml i ispunjava vrijednost APP_EXTERNAL_DOMAIN željenom vrijednošću ovisno o okruženju u kojem započinje ažuriranje aplikacije. Ova je varijabla već postavljena u spremniku. Može mu 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 Cloudu, uključujući rad s configMaps: . Dok se projekt aktivno razvija i radikalno mijenja, ne možemo ga koristiti u proizvodnji. Ali mi aktivno pratimo njegovo stanje i koristimo ga u DEV konfiguracijama. Čim se stabilizira, prijeći ćemo s korištenja varijabli okruženja na njega.
Ukupno
Dakle, Continuous Deployment je konfiguriran i radi. Sva ažuriranja se događaju jednim pritiskom tipke. Isporuka promjena u okruženju proizvoda je automatska. I, što je važno, ažuriranja ne zaustavljaju sustav.
Planovi za budućnost: automatska migracija baze podataka
Razmišljali smo o nadogradnji baze podataka i mogućnosti vraćanja tih promjena. Uostalom, dvije različite verzije aplikacije rade u isto vrijeme: stara radi, a nova radi. 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 novi stupac, u njega kopirati podatke iz starog stupca i upisati okidače koji će ih prilikom ažuriranja podataka istovremeno kopirati i ažurirati u drugom stupcu. A nakon uspješne implementacije nove verzije aplikacije, nakon razdoblja podrške nakon pokretanja, moći ćemo izbrisati stari stupac 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 omogućit će vam istovremeni rad s nekoliko verzija aplikacije.
Planiramo automatizirati migraciju baze podataka putem K8S posla, integrirajući ga u proces CD-a. A ovo ćemo iskustvo svakako podijeliti na Habréu.
Izvor: www.habr.com