În contextul actual, metoda GitOps reușește, în mare măsură, să acopere problema volumului de lucru ridicat pe clusterele de tip Kubernetes, mai ales, atunci când aducem în discuție reconcilierea între starea actuală și starea dezirabilă.
Metoda în care sistemul de control de versiune de tip Git este folosit ca sursă unică de adevăr atât pentru infrastructura declarativă, cât și pentru codul aplicației în procesul de inginerie software este cunoscută sub numele de ,,GitOps". În metodologia GitOps, starea dezirabilă a sistemului este salvată în Git. Astfel, un sistem automatizat implementează modificările în mediul țintă atunci când se fac actualizări la nivelul stării dezirabile și sunt confirmate în Git. Prin utilizarea acestei strategii, este posibilă menținerea sistemului în condiții stabile și, de asemenea, să fie operate modificări ușor auditabile și/sau anulabile, după caz. Metoda GitOps poate fi utilizată pentru a gestiona atât aplicații, cât și infrastructură, fiind prezentă cu precădere în sistemele cloud-native, unde infrastructura este dinamică și efemeră.
Definirea și standardizarea proceselor este făcută de grupul non-profit Cloud Native Computing Foundation (CNCF), care este axat îndeosebi pe încurajarea utilizării tehnologiei de tip cloud-native. Acest grup constituie un cadru de dezvoltare și extindere pentru conceptele de tip cloud-native și găzduiește proiecte open-source, precum Kubernetes, Prometheus și Envoy.
Potrivit grupului CNCF, următoarele concepte compun nucleul cloud-native-computing:
Împachetarea aplicațiilor în containere pentru creșterea mobilității și permiterea separării resurselor - metodă cunoscută și sub numele de containerizare.
Orchestrarea dinamică: automatizarea implementării, scalării și administrării aplicațiilor containerizate cu ajutorul unor tehnologii precum Kubernetes.
Micro-servicii: împărțirea aplicațiilor în părți mai mici, care pot fi create, testate și implementate independent.
Dar, pentru ca aplicațiile să fie 100% compatibile cu mediile de tip cloud, infrastructura pe care rulează acestea trebuie să beneficieze, de asemenea, de capacitatea de reconciliere între starea actuală și starea dezirabilă.
Articolul de față abordează următoarele probleme:
costuri ridicate de infrastructură de dezvoltare care rulează non-stop;
timpi mari de așteptare (ai echipelor de dev, qa și ops);
O nouă paradigmă numită shift-left urmărește identificarea și corectarea erorilor cât mai devreme posibil în ciclul de dezvoltare, pentru a preveni intervenții costisitoare sau de lungă durată.
Cel mai frecvent, întâlnim medii de tip dev/qa/staging cu care se simulează cât mai fidel mediul de producție. Această infrastructură rulează 24/7, lucru care duce atât la creșterea costurilor, cât și la mărirea timpilor de așteptare a fiecărui membru din echipele menționate mai sus, pentru îndeplinirea sarcinilor zilnice.
Este mai profitabil ca echipele de dezvoltare și testare să poată să pună accent pe calitatea muncii decât pe preocuparea generată de complexitatea infrastructurii aplicației. Cu toate acestea, faptul că mediile de dezvoltare, testare și pre-producție trebuie să semene foarte mult cu producția, generează un șir infinit de discuții pe tema costurilor.
În aceste condiții, un mediu de dezvoltare 1:1 cu un mediu de producție, care este instanțiat doar evenimențial, este adesea mai rentabil decât un mediu asimetric 24/7.
De exemplu, atunci când un tester trebuie să opereze în regim de hot-fix, este de la sine înțeles că are nevoie de un mediu similar cu cel pe care rulează producția pentru a obține rezultate valide. În aceste condiții, el ar trebui să poată să lanseze o infrastructură identică pe care să poată opera procesele de validare, să colecteze rezultatele, după care să poată decomisiona această infrastructură.
Situații similare pot fi întâlnite și la nivelul programatorilor, al personalului care operează procese specifice de lucru (business processes), cât și al celorlalți membri ai echipelor de livrare. Crossplane, care rulează nativ pe Kubernetes și beneficiază de Kube-API și de RBAC-ul implicit este instrumentul care poate fi utilizat pentru atingerea acestui scop.
Echipele de dezvoltare pot obține o serie de avantaje de pe urma unei infrastructuri care este controlată de un control-plane central și care este implementată cu ajutorul așa-numitelor pipelines.
Capacitatea de a crea o infrastructură cu un timp de rulare prestabilit (TTL) și un control al accesului bazat pe roluri (RBAC) reprezintă un avantaj al unui astfel de sistem. Acest lucru presupune că accesul la infrastructură poate fi restricționat cu ajutorul rolurilor și că infrastructura poate fi lansată și distrusă automat în funcție de reguli predefinite. Astfel, este garantat că accesul la infrastructură este restricționat în mod corespunzător și că aceasta este utilizată numai când este necesar.
Monitorizarea facilă a unei astfel de infrastructuri constituie un alt avantaj. Este posibilă monitorizarea stării de funcționalitate a infrastructurii și să se țină evidența modificărilor de-a lungul timpului prin utilizarea unui control-plane.
În general, echipele de dezvoltare au de câștigat de pe urma unui control-plane central, care întreține infrastructura prin pipelines și permite crearea infrastructurii cu TTL și RBAC predefinite, având inclusiv nivelul de productivitate, securitate și observabilitate sporite.
Având implementată metoda GitOps, sunt mult mai ușor de evitat situațiile în care persoane fără o înțelegere adecvată a proceselor de lucru pot accesa interfața online a consolei clusterului și pot provoca inconsistențe în infrastructură.
Mai mult, echipele de infrastructură pot și ele profita, livrând echipelor de dezvoltare Internal Development Platforms (IDP).
Crossplane, un control-plane multi-cloud open-source, permite clienților să automatizeze și să gestioneze infrastructura între diferiți furnizori de cloud. Prin extinderea API-ului, Kubernetes cu conceptul de definiții de resurse personalizate (CRD), acesta permite utilizatorilor să își definească propriile resurse personalizate, care pot înlocui resursele specifice cloudului, cum ar fi mașinile virtuale sau bazele de date.
Crossplane utilizează API-ul eXtended Resource Definitions (XRD) pentru a permite utilizatorilor să își definească propriile resurse unice într-un mod care este decuplabil de implementările anumitor furnizori de servicii cloud. Acest lucru înseamnă că utilizatorii pot utiliza Crossplane pentru a implementa și opera infrastructura preferată pe orice platformă cloud suportată, după ce o definesc într-o manieră independentă de cloud.
O diferență notabilă între Crossplane și Terraform este că, în timp ce Terraform este un program independent care poate fi utilizat în orice context, Crossplane este integrat cu API-ul Kubernetes și este destinat utilizării într-un mediu Kubernetes. Acest lucru înseamnă că, în timp ce Terraform este mai mult utilizat pentru gestionarea infrastructurii, Crossplane poate utiliza caracteristicile și capacitățile Kubernetes, cum ar fi containerizarea și orchestrarea pentru a crea o buclă de control între starea dezirabilă (Git) și starea actuală (infrastructura din cloud).
Cu ajutorul obiectelor de tip XR(extended resource)+XRD(eXtended Resource Definitions), API-ul folosit de Crossplane le permite utilizatorilor să își definească propriile resurse personalizate într-un mod abstractizat de implementările specifice ale furnizorilor de cloud. Acest lucru înseamnă că utilizatorii își pot defini infrastructura dorită într-un mod independent de cloud, apoi pot folosi Crossplane pentru a implementa și gestiona această infrastructură pe orice platformă cloud suportată.
Fig. 1 Componentele Crossplane necesare pentru crearea resurselor
**Scenariu**: Vom aborda arhitectura în două etape, prima reprezentând-o infrastructura Cloud-agnostică, ce va facilita soluționarea celei de-a doua, controlată de client, prin care se vor putea instanția cu ușurință diverse aplicații, în exemplul de față, Wordpress.
Prin intermediul GitHub Actions și Terraform vom automatiza crearea unei instanțe de ArgoCD, ce va instala cu ușurință Crossplane. De aici, putem alege după preferința clientului orice furnizor public de servicii Cloud în care să avem un cluster de tip Kubernetes.
Partea controlată de client, găzduită de clusterul de tip Kubernetes menționat anterior, având o instanță ArgoCD, prin care se lansează aplicația Wordpress.
Fig. 2 Arhitectura scenariului
Dezvoltarea unei aplicații care respectă principiile CNCF și GitOps va da dovadă de funcționalitate și modularitate, ba mai mult, atâta timp cât va fi independentă de cloud, echipele de dezvoltatori se vor putea concentra pe calitatea produselor livrate. Totodată, un beneficiu vizibil va fi timpul câștigat prin eliminarea ceremoniilor specifice proceselor clasice de instanțiere a aplicațiilor în producție, chiar și în mediile de dezvoltare, testare și pre-producție. Modularitatea unei aplicații poate concentra echipele dedicate pe detalii și garantează o reziliență sporită. Perspectiva echipelor de DevOps deschide noi orizonturi înspre platformele interne de dezvoltare care, la rândul lor, vor garanta viteză sporită de livrare.
Bibliografie
https://docs.github.com/en/actions/learn-github-actions/understanding-github-actions
https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/eks_cluster
de Ovidiu Mățan
de Ovidiu Mățan
