Noi, cei de la True Engineering, am stabilit un proces pentru livrarea continuă a actualizărilor către serverele clienților și dorim să împărtășim această experiență.
Pentru început, am dezvoltat un sistem online pentru client și l-am implementat în propriul nostru cluster Kubernetes. Acum, soluția noastră de mare sarcină s-a mutat pe platforma clientului, pentru care am configurat un proces de implementare continuă complet automat. Datorită acestui fapt, am accelerat timpul de lansare pe piață - livrarea de schimbări în mediul produsului.
În acest articol vom vorbi despre toate etapele procesului de Implementare Continuă (CD) sau livrarea actualizărilor către platforma clientului:
- Cum începe acest proces?
- sincronizare cu depozitul Git al clientului,
- asamblare de backend și frontend,
- implementarea automată a aplicațiilor într-un mediu de testare,
- implementare automată la Prod.
Vom împărtăși detaliile de configurare pe parcurs.
1. Porniți CD-ul
Implementarea continuă începe cu dezvoltatorul împingând modificări în ramura de lansare a depozitului nostru Git.
Aplicația noastră rulează pe o arhitectură de microservicii și toate componentele sale sunt stocate într-un singur depozit. Datorită acestui fapt, toate microserviciile sunt colectate și instalate, chiar dacă unul dintre ele s-a schimbat.
Am organizat munca printr-un singur depozit din mai multe motive:
- Ușurință de dezvoltare - aplicația se dezvoltă activ, astfel încât să puteți lucra cu tot codul simultan.
- O singură conductă CI/CD care garantează că aplicația ca sistem unic trece toate testele și este livrată în mediul de producție al clientului.
- Eliminam confuzia în versiuni - nu trebuie să stocăm o hartă a versiunilor de microservicii și să descriem configurația acesteia pentru fiecare microserviciu în scripturile Helm.
2. Sincronizarea cu depozitul Git a codului sursă al clientului
Modificările efectuate sunt sincronizate automat cu depozitul Git al clientului. Acolo este configurat ansamblul aplicației, care este lansat după actualizarea ramurului și implementarea în continuare. Ambele procese își au originea în mediul lor dintr-un depozit Git.
Nu putem lucra direct cu depozitul clientului, deoarece avem nevoie de mediile noastre proprii pentru dezvoltare și testare. Folosim depozitul nostru Git în aceste scopuri - este sincronizat cu depozitul lor Git. De îndată ce un dezvoltator postează modificări în ramura corespunzătoare a depozitului nostru, GitLab trimite imediat aceste modificări către client.
După aceasta, trebuie să faceți asamblarea. Acesta constă din mai multe etape: asamblare backend și frontend, testare și livrare la producție.
3. Asamblarea backend-ului și a front-end-ului
Construirea backend-ului și a frontend-ului sunt două sarcini paralele care sunt efectuate în sistemul GitLab Runner. Configurația sa originală de asamblare este localizată în același depozit.
.
GitLab Runner preia codul din depozitul necesar, îl asamblează cu comanda de compilare a aplicației Java și îl trimite la registrul Docker. Aici asamblam backend-ul și frontend-ul, obținem imagini Docker, pe care le punem într-un depozit de partea clientului. Pentru a gestiona imaginile Docker pe care le folosim .
Sincronizăm versiunile imaginilor noastre cu versiunea de lansare care va fi publicată în Docker. Pentru o funcționare fără probleme, am făcut câteva ajustări:
1. Containerele nu sunt reconstruite între mediul de testare și mediul de producție. Am făcut parametrizări astfel încât același container să poată funcționa cu toate setările, variabilele de mediu și serviciile atât în mediul de testare, cât și în producție, fără reconstrucție.
2. Pentru a actualiza o aplicație prin Helm, trebuie să specificați versiunea acesteia. Construim backend-ul, frontend-ul și actualizăm aplicația - acestea sunt trei sarcini diferite, așa că este important să folosim aceeași versiune a aplicației peste tot. Pentru această sarcină, folosim date din istoricul Git, deoarece configurația și aplicațiile noastre cluster K8S sunt în același depozit Git.
Obținem versiunea aplicației din rezultatele execuției comenzii
git describe --tags --abbrev=7.
4. Implementarea automată a tuturor modificărilor aduse mediului de testare (UAT)
Următorul pas în acest script de compilare este actualizarea automată a clusterului K8S. Acest lucru se întâmplă cu condiția ca întreaga aplicație să fi fost construită și toate artefactele să fi fost publicate în Registrul Docker. După aceasta, începe actualizarea mediului de testare.
Actualizarea clusterului este începută utilizând . Dacă, ca urmare, ceva nu a mers conform planului, Helm va anula automat și independent toate modificările. Munca lui nu trebuie controlată.
Furnizăm configurația cluster K8S împreună cu ansamblul. Prin urmare, următorul pas este să îl actualizăm: configMaps, implementări, servicii, secrete și orice alte configurații K8S pe care le-am schimbat.
Helm rulează apoi o actualizare RollOut a aplicației în sine în mediul de testare. Înainte ca aplicația să fie implementată în producție. Acest lucru se face astfel încât utilizatorii să poată testa manual caracteristicile de afaceri pe care le-am introdus în mediul de testare.
5. Implementarea automată a tuturor modificărilor aduse Prod
Pentru a implementa o actualizare a mediului de producție, trebuie doar să faceți clic pe un buton din GitLab - iar containerele sunt livrate imediat în mediul de producție.
Aceeași aplicație poate funcționa în medii diferite – testare și producție – fără reconstrucție. Folosim aceleași artefacte fără a schimba nimic în aplicație și setăm parametrii extern.
Parametrizarea flexibilă a setărilor aplicației depinde de mediul în care va fi executată aplicația. Am mutat toate setările de mediu în exterior: totul este parametrizat prin configurația K8S și parametrii Helm. Când Helm implementează un ansamblu în mediul de testare, setările de testare sunt aplicate acestuia, iar setările produsului sunt aplicate mediului de producție.
Cel mai dificil lucru a fost să parametrizezi toate serviciile și variabilele utilizate care depind de mediu, și să le traduc în variabile de mediu și descriere-configurații ale parametrilor de mediu pentru Helm.
Setările aplicației folosesc variabile de mediu. Valorile lor sunt setate în containere folosind configurația K8S, care este modelată folosind șabloane Go. De exemplu, setarea unei variabile de mediu la numele domeniului se poate face astfel:
APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}
.Valori.global.env – această variabilă stochează numele mediului (prod, stage, UAT).
.Valori.proprietăți.aplicație.domeniul_extern_aplicației – în această variabilă setăm domeniul dorit în fișierul .Values.yaml
Când actualizează o aplicație, Helm creează un fișier configmap.yaml din șabloane și completează valoarea APP_EXTERNAL_DOMAIN cu valoarea dorită în funcție de mediul în care începe actualizarea aplicației. Această variabilă este deja setată în container. Poate fi accesat din aplicație, astfel încât fiecare mediu de aplicație va avea o valoare diferită pentru această variabilă.
Relativ recent, suportul K8S a apărut în Spring Cloud, inclusiv lucrul cu configMaps: . În timp ce proiectul se dezvoltă activ și se schimbă radical, nu îl putem folosi în producție. Dar monitorizăm în mod activ starea acestuia și îl folosim în configurațiile DEV. De îndată ce se stabilizează, vom trece de la utilizarea variabilelor de mediu la acesta.
În total
Deci, implementarea continuă este configurată și funcționează. Toate actualizările au loc cu o singură apăsare de tastă. Livrarea modificărilor mediului de produs este automată. Și, important, actualizările nu opresc sistemul.
Planuri de viitor: migrarea automată a bazei de date
Ne-am gândit la actualizarea bazei de date și la posibilitatea de a anula aceste modificări. La urma urmei, două versiuni diferite ale aplicației rulează în același timp: cea veche rulează și cea nouă. Și o vom opri pe cea veche doar când suntem siguri că noua versiune funcționează. Migrarea bazei de date ar trebui să vă permită să lucrați cu ambele versiuni ale aplicației.
Prin urmare, nu putem schimba pur și simplu numele coloanei sau alte date. Dar putem crea o coloană nouă, să copiem datele din vechea coloană în ea și să scriem declanșatoare care, la actualizarea datelor, le vor copia și actualiza simultan într-o altă coloană. Și după implementarea cu succes a noii versiuni a aplicației, după perioada de suport post-lansare, vom putea șterge coloana veche și declanșatorul care a devenit inutil.
Dacă noua versiune a aplicației nu funcționează corect, putem reveni la versiunea anterioară, inclusiv la versiunea anterioară a bazei de date. Pe scurt, modificările noastre vă vor permite să lucrați simultan cu mai multe versiuni ale aplicației.
Intenționăm să automatizăm migrarea bazei de date prin job K8S, integrându-l în procesul CD. Și cu siguranță vom împărtăși această experiență pe Habré.
Sursa: www.habr.com