După doi ani de doar evenimente virtuale KubeCon, echipa de produse GitLab a fost încântată să participe și să se întâlnească cu colegi, parteneri și multe altele din industria noastră la KubeCon EU 2022, care a avut loc în Valencia, Spania. Am fost prezenți cu patru lideri de produse, un dezvoltator de software și un cercetător UX. Această postare rezumă principalele noastre concluzii de la conferință, o experiență care ne va afecta foile de parcurs.

Vom discuta următoarele subiecte:

• Platforme interne și GitOps
• Managementul secretelor
• Integrarea infrastructurii
• WebAssembly aka WASM

Au existat 32 de tipuri de subiecte și mai multe evenimente de 0 zile la KubeCon. Multe discuții s-au concentrat pe câteva instrumente. Multe proiecte Cloud Native Computing Foundation ( CNCF ) au avut întâlniri ale comunității în aceste zile. Unele discuții au fost date IRL, iar altele au fost difuzate virtual cu întrebări și răspunsuri în direct. Au fost o varietate de subiecte și abordări. Au existat multe discuții și despre diferitele aspecte ale managementului clusterelor. Cu toate acestea, am lăsat acest subiect în mod intenționat, deoarece la GitLab dorim să ne concentrăm pe dezvoltatorii de software și să oferim o platformă DevOps care să le susțină munca. Managementul clusterelor este la un pas de această focalizare. Totuși, am observat câteva modele remarcabile, așa cum sunt evidențiate de cele patru elemente ale listei noastre.

Ești invitat! Alăturați-vă nouă pe 23 iunie pentru evenimentul de lansare a GitLab 15 cu guruul DevOps Gene Kim și câțiva lideri GitLab. Vă vor arăta ce văd pentru viitorul DevOps și The One DevOps Platform.

Platforme interne și GitOps

Companiile doresc ca dezvoltatorii lor să se concentreze pe activitatea lor de bază. Ei creează platforme interne pentru a ascunde complexitatea operațiunilor din Zilele 0-2 de inginerii lor software și permit în continuare mișcarea „deplasare la stânga” a DevOps. Aceste platforme presupun adesea sudarea mai multor scule.

Multe discuții au prezentat modul în care echipa sau compania respectivă și-a abordat problema platformei și ce instrumente au folosit, și de multe ori se putea simți transpirația de 18 luni a unei întregi echipe de platformă care încearcă să găsească o soluție.

Aceste platforme folosesc fie un model bazat pe push-sau pull-ul pentru implementări. Nu apare nicio abordare unică din cauza aplicațiilor vechi și a cerințelor diferite. Deși există o definiție a GitOps oferită de inițiativa OpenGitOps , mai mulți prezentatori și-au oferit propriile definiții, inclusiv a implementărilor bazate pe pull.

Am desfășurat un sondaj la scară largă legat de secrete la KubeCon și am aflat că utilizatorii ar dori ajutor cu fluxul de lucru Pipeline Authoring .

Pe lângă cablarea instrumentelor, industria încă caută o abordare unificată a multi-chiriei (s-ar putea să nu existe una), iar uneori integrarea proceselor de securitate pare prea dificilă.

Cum ne afectează acest lucru foaia de parcurs?

Există mult potențial în construirea unei platforme folosită ca punct de plecare pentru platformele interne. Imaginați-vă un „instrument” care scurtează timpul necesar pentru a crea o platformă internă la zile sau săptămâni în loc de un an întreg. Aceasta este viziunea GitLab a platformei The One DevOps.

Drept urmare, nu planificăm nicio schimbare în direcția noastră. Vom continua să investim în direcția de implementare recent începută pentru a oferi toate elementele de bază ale unei platforme într-un singur instrument și căutăm deja în mod activ experiențe integrate în oferta noastră.

Lucrăm la un catalog de componente CI/CD care include șabloane CI. Acest lucru va sprijini fluxul de lucru Pipeline Authoring .

Managementul secretelor

Unul dintre lucrurile care au apărut adesea în discuțiile noastre este managementul secretelor. Am desfășurat un sondaj la scară largă legat de secrete la KubeCon, iar participanții au fost bucuroși că ne gândim la acest subiect. Securitatea face parte din discuția DevOps, iar gestionarea secretelor este o problemă serioasă, mai ales în aspectul cloud-native.

• Jenkins, GitHub și GitLab au fost toate menționate în timpul discuțiilor secrete de management.
• Utilizatorii ar dori să transfere responsabilitatea de gestionare a secretelor către un alt produs. În multe cazuri, cerințele lor de securitate sunt stricte, așa că nu doresc/nu pot gestiona singuri secretele.
• Hashicorp Vault este un instrument preferat (în primul rând în companiile mari care lucrează în finanțe sau guvern) pentru a gestiona și gestiona secretele. În același timp, majoritatea companiilor ar dori să evite să opereze încă o aplicație în stiva lor.
• Open ID Conectați OIDC cu tokenul web JSON (JWT) este o direcție esențială pentru noi.

Cum ne afectează acest lucru foaia de parcurs?

Ar trebui să investim mai mult în gestionarea secretelor, deoarece aceasta este o durere pe care clienții noștri ar dori să o rezolvăm și devine o caracteristică neîncepătoare pentru multe organizații.

Dorim să avansăm în trei vectori principali:

• Îmbunătățiți soluția noastră existentă de gestionare a secretelor – deși nu avem o soluție clară, ar trebui să ne îmbunătățim capabilitățile actuale ale variabilelor pentru a include funcții suplimentare care ar putea ajuta utilizatorii să folosească variabilele pentru secrete. Deci, ar fi o caracteristică „destul de bună” pe care o pot folosi. Lucrăm activ în această direcție eliminând unele dintre limitările pe care le avem în jurul variabilelor și mascării .
• Îmbunătățiți integrarea noastră existentă Hashicorp Vault folosind simbolul JWT, permițându-ne să ne integrăm cu furnizori suplimentari (AWS, AZURE, GCP). La fel ca și punctul anterior, ne îndreptăm spre această direcție, sprijinind OIDC și adăugând revendicări ale publicului la simbolul nostru JWT .
• Trebuie să dezvoltăm o strategie clară pentru o soluție încorporată de gestionare a secretelor . Pentru a oferi utilizatorilor/clienților noștri posibilitatea de a alege, GitLab dorește să folosească Hashicorp Vault pentru gestionarea secretelor. Credem că abordarea noastră nu ar trebui să fie să construim noi înșine logica, ci să folosim un proiect open source, nativ în cloud, pe care l-am putea integra în GitLab.

Integrarea infrastructurii

Integrările de infrastructură au apărut în mai multe variante în timpul discuțiilor. Unele sunt despre managementul clusterelor, acesta nu este punctul nostru de interes în acest blog. Mai multe prezentări arată că platformele interne au nevoie și de un aspect puternic de infrastructură. Când este pornit un nou proiect/microserviciu, ar putea necesita un nou spațiu de nume în cluster cu RBAC și politici asociate, opțional stocare, un depozit de gestionare a codului sursă cu automatizare și permisiunile corespunzătoare. Implementările pot crea medii efemere sau pot modifica mediul de bază în cadrul unor constrângeri predefinite.

Instrumentele de top menționate în acest domeniu sunt:

• Terraform
• Crossplane
• Pulumi

Cum ne afectează acest lucru foaia de parcurs?

GitLab are deja integrări excelente pentru Terraform , iar celelalte instrumente sunt, de asemenea, pe radarul nostru.

Suntem deschiși la integrări, dar în prezent nu putem prioritiza celelalte integrări pe cont propriu. Sperăm că comunitatea va fi interesată să contribuie în beneficiul tuturor.

Construirea containerelor Docker ar putea să nu fie necesară pentru a obține binare de containere ușor de gestionat. Timpurile de execuție WASM devin disponibile pentru Kubernetes și multe limbaje de programare se pot compila în mod nativ în WASM. WASM poate oferi un mediu de rulare sigur fără Docker și ar putea să simplifice lanțul de instrumente pe care dezvoltatorii trebuie să învețe.

Nu intenționăm să adăugăm încă suport direct WASM la GitLab. Registrul de pachete generice poate deține module WASM în timp ce implementarea acestora este la latitudinea utilizatorului.

În același timp, vedem mult potențial în mediile de rulare simple construite în jurul WASM. Deși GitLab nu se ocupă de a oferi servicii de rulare, vom monitoriza activ piața. S-ar putea să ne uităm la mai multe integrări WASM, deoarece vedem mai multe cereri și instrumente și servicii care se maturizează în acest spațiu.

Feedback GitLab

Este grozav să lucrezi la un produs în care sentimentul general este pozitiv, atât din partea clienților care se bazează intens pe el, cât și din partea participanților care trebuie să folosească alte instrumente, dar care și-ar plăcea să folosească GitLab sau au început să se joace cu el recent.

Am primit următoarele mențiuni notabile ca feedback:

• Stabilitatea și fiabilitatea s-au îmbunătățit în ultimele câteva luni.
• Utilizatorii adoră documentația noastră (în primul rând despre CI) – au menționat că este ușor de utilizat și de a începe.
• Având în vedere dimensiunea GitLab și numărul utilizatorilor noștri, am primit feedback despre probleme de mult timp restante. Am fost bucuroși să răspundem că ne vom adresa cel puțin unora dintre ei în curând.
• Mai mulți clienți au întrebat dacă avem niște resurse pentru migrarea de la Jenkins la GitLab.
• Câțiva clienți au menționat că au fost nevoiți să se îndepărteze de GitLab în principal din cauza unei decizii de nivel superior, în ciuda faptului că au favorizat GitLab.

Concluzii

Ne-au plăcut toate discuțiile și am fost încântați să întâlnim și să vorbim cu utilizatorii și clienții noștri. Vă mulțumim tuturor, am putea „simți pulsul” despre cum ne descurcăm și să ne validăm direcția.

Sperăm că acest blog îi va ghida pe cei care nu au putut participa la KubeCon și va servi drept rezumat pentru cei care au participat. Toate înregistrările vor fi probabil disponibile pe YouTube începând cu 6 iunie 2022.

Spuneți-ne în comentarii dacă credeți că am ratat o direcție importantă.

Această postare de blog și paginile asociate conțin informații legate de produsele, caracteristicile și funcționalitățile viitoare. Este important de reținut că informațiile prezentate au doar scop informativ. Vă rugăm să nu vă bazați pe aceste informații în scopuri de achiziție sau planificare. Ca și în cazul tuturor proiectelor, articolele menționate în acest blog și paginile asociate pot fi modificate sau întârziate. Dezvoltarea, lansarea și sincronizarea oricăror produse, caracteristici sau funcționalități rămân la discreția exclusivă a GitLab Inc.

„Aflați cum ceea ce am învățat la KubeCon EU 2022 despre integrările platformei și gestionarea secretelor va avea impact asupra foilor noastre de parcurs pentru produse.” – Viktor Nagy

Faceți clic pentru a tweet