Am discutat în cadrul evenimentului de lansare de luna trecută despre DevOps și Kubernetes alături de invitații noștri:
Alexandru Dascăl - DevOps Engineer @ BoatyardX ,
Máté Lang - DevOps enthusiast @ Connatix ,
Ovidiu Mățan: Vă invit să începem cu o scurtă prezentare personală.
Marius Ciotloș: Lucrez în departamentul de Gaming, unde mă ocup alături de echipa mea, de toată partea operațională a departamentului. Avem multe servicii care oferă suport pentru componenta de betting (pariuri) pentru gaming. Echipa de DevOps se ocupă de toată partea de monitorizare, lucrând la optimizarea platformei pe care rulează microserviciile. Ne implicăm în tooling, ajutând echipele de dezvoltare să se descurce singure cu deploymentul.
Alexandru Dascăl: Sunt implicat în mai multe proiecte. Avem clienți care cumpără de la noi servicii de DevOps, ceea ce înseamnă că ne ocupăm de disciplina, de procesele lor, de automatizările pe care doresc să le obțină. Am câteva proiecte în care dezvoltăm produse cap-coadă pe arhitecturile noastre interne, folosind Kubernetes, Docker Helm etc.
Máté Lang: La Connatix ne ocupăm de un produs propriu care este o soluție video online pentru media organizations (organizații media). Printre clienții noștri se numără Reuters, AccuWeather și nu numai. Avem trei ramuri mari ale produsului: stocarea evenimentelor, monetizare (funcționăm ca o bursă pentru cei care vor să lanseze o reclamă pe pagina lor în format video), generare de conținut unde folosim Machine Learning și NLP pentru crearea eficientă de conținut în volum mare. Pentru ultima componentă, putem oferi clienților soluții de randare automată. Lucrăm cu microservicii, iar platforma rulează pe Kubernetes. Echipa de infrastructură se asigură că platforma funcționează în parametri optimi, dar ne ocupăm și de tooling, facilitând activitatea zilnică a colegilor noștri.
DevOps-ul este mai complex decât acum zece ani când vorbeam mai mult de administratorii de rețea. Care sunt cunoștințele necesare pentru acest job?
Máté Lang: După părerea multor persoane de la Google, DevOps este o cultură, nu neapărat un rol de tip DevOps Engineer. Pe de altă parte, Google în Reliability Engineering Handbook spune că DevOps este cultura unde pui ingineri normali din dezvoltarea de produse ca să rezolve niște probleme operaționale. Practic, în loc să rezolvi problemele operaționale manual, încerci să automatizezi cât de mult cu bunele practici din ciclul de dezvoltare software. Sunt necesare abilitățile de automatizare, networking, monitorizare, Linux, cloud.
Alexandru Dascăl: Máté a acoperit foarte bine subiectul. Ce contează pentru mine sunt și soft skillurile, deoarece, în mod normal, orice developer ar trebui să poată adera la ideologia DevOps. Prin urmare, un set de abilități precum comunicare eficientă, gândire critică te pot duce departe în DevOps.
E nevoie de cunoștințe complexe de programare sau un Python e suficient?
Alexandru Dascăl: Depinde ce urmărești ca produs finit. Sunt multe tooluri care te ajută să scrii aplicații și cod fără prea multe cunoștințe, deci un minim de logică e suficient.
Marius Ciotloș: Ce acoperă poziția de DevOps depinde de la companie la companie. Unele companii vor avea nevoie de cunoștințe din zona sistemelor de operare, de administrare. Alte companii folosesc multe servicii out of the box de la furnizorii cloud, deci vor avea nevoie de cunoștințe de API, automatizare. Într-o companie mare, o echipă nu are o descriere șablon. Trebuie să ai domenii de expertiză: rețelistică, programare, troubleshooting.
Să zicem că trebuie făcut deployment pe AWS sau Azure. Cât timp îi ia unei persoane să se simtă confortabil să facă deployment?
Marius Ciotloș: Pe public cloud avantajul este că există multă documentație. Când mergi într-un private cloud e mai dificil. Totul depinde de dimensiunea companiei, de gradul de customizare la nivel de deployment, de compliance (reguli de conformitate), de legislație locală, deoarece asta influențează volumul de servicii folosite out of the box sau customizate.
Acum 10-15 ani când instalai servere, acestea deveneau prietenii tăi cei mai buni, aveau nume. Acum, de când cu Docker și Kubernetes, serverele au devenit anonime, le pornești, le oprești, scalează. E corect să afirmăm că diferența dintre cele două realități seamănă cu diferența dintre Epoca de Piatră și Modernitate?
Alexandru Dascăl: Conceptual, vorbim în continuare de același lucru. Acuma că sunt servere pe net, public cloud, private cloud, tot sunt niște lucruri clasice pe care trebuie să le ai în vedere. În domeniul de deployment am evoluat foarte mult, iar acolo comparația cu Epoca de Piatră e relevantă.
Máté Lang: Kubernetes este bazat pe ideea că orice resursă creezi aici este una trecătoare, iar sistemul este construit pentru a avea reguli de recuperare a resurselor ce dispar din senin. Pe de altă parte, în Kubernetes există și ideea că vreau să știu unde anume se poziționează o anumită resursă, de exemplu la bazele de date. Aceste noțiuni sunt deja incluse în Kubernetes, iar operatorii nu au decât să folosească aceste noțiuni.
Cât de mare este un script, un YAML în producție? Câte linii de cod are?
Máté Lang: Depinde de serviciu. Recent am început să implementăm Istio în compania noastră. Are un YAML definition de vreo 10000 de rânduri. Nu îl gestionăm noi, ci doar îl folosim. În Connatix, la majoritatea serviciilor avem un template (șablon) cât de cât simplu (set stackuri de vreo 50 de linii, config maps triviale, Ingres-uri). Ceea ce e mai important este că poți să descrii într-un mod declarativ ce se va întâmpla după aplicare, după deployment.
Marius Ciotloș: Evoluția a fost naturală. Cei mai buni ingineri făceau automatizări cu toolurile lor proprii, nestandardizate, iar, de acolo, lucrurile au evoluat pentru a se face management la un volum mai mare de servere. La echipele de DevOps nu poți scala vertical atât de mult, deci nu îți vei putea permite prea multe resurse, iar prin tooling vei putea face mult mai multe procese cu mai multe servere, dar cu mai puțini oameni. Ce era în capul unui inginer bun se află acum în cod și se folosește codul acela pentru a se derula operațiuni repetitive. Cred că este important ca firmele să își ia ingineri care au lucrat cu tehnologia din trecut, deoarece și în Kubernetes, și în AWS, și peste tot se mai întâmplă să apară anomalii. Dacă nu ai pe cineva care să înțeleagă complexitatea din spate (de multe ori ascunsă de furnizor) va fi greu să faci troubleshooting. E nevoie de cei care au văzut cum se construiește și cum se face agregarea la nivel de servere.
Ce stack folosiți?
Marius Ciotlos: Ne bazăm pe OpenStack și private cloud. Avem și implementări în Azure și AWS. În AWS avem partea de warehouse (depozitare), iar în Azure partea de trading (tranzacționare). În departamentul meu, folosim OpenStack majoritar. Acum începem o implementare în AWS, dar am avut și tentative de implementare Kubernetes, dar nu s-a făcut pasul mai departe din motive de complexitate și restricții cu privire la compliance (reguli de confomitate), reguli din diferite țări, unde e mai greu să faci modificări de platformă fără suport legislativ.
Alexandru Dascăl: Noi folosim Kubernetes, Docker. Toate microserviciile din Cube le menținem prin Helm și în spatele acestui monstru stă Terraform. Noi automatizăm tot ce ține de Kubernetes. Chiar și release-urile de Helm le gestionăm cu Terraform. Suntem doar cloud. Nu lucrăm cu private cloud. Avem stackurile noastre de cod și încercăm să le menținem cloud agnostic, deși nu putem face asta cu toate definițiile. Nu putem scrie totul astfel încât să fie suportat și de Azure și de AWS. Terraform e componenta esențială, deoarece prin ea gestionăm nu doar Kubernetes/Docker/Helm, ci și componentele specifice cloud și tot ce mai e nevoie în proiect.
Máté Lang: Principala componentă este și la noi Terraform și încercăm să modularizăm cât mai mult componentele pentru a fi refolosibile între environmenturi și contexte. Infrastructura noastră se află în Amazon, în public cloud. Folosim Helm și pentru componentele noastre, și pentru cele third-party. Helm este un package manager pentru Kubernetes, adică eu am nodurile de Kubernetes de sine stătătoare fără niciun context. Pentru a face deployment la o aplicație, vei avea nevoie de mai multe resurse de Kubernetes. S-ar putea să ai nevoie de un deployment, de un config etc. În era pre-Helm trebuia să instalăm aceste resurse pe rând. Nu era nicio logică care să reunească componentele, să le dea o versiune, să spună cu ce sunt compatibile, să permită rollback. Pentru asta s-a inventat Helm. Pe de altă parte, Helm are un templating engine destul de puternic prin care poți instala un engine de 30 de ori pe un cluster cu un release name diferit. În era pre-Helm, lumea folosea tot felul de hackuri ca să mai parametrizeze, ca să facă un template (șablon), ca să refolosească fișiere.
Există bune practici pentru crearea corectă a unei imagini Docker?
Marius Ciotlos: E important să existe un proces, să se testeze local înainte de orice, să te asiguri că ai un registru unde pui imaginile Docker (de preferat, securizat), să ai integrat în procesul tău de livrare partea de validare/ scanare ca să te asiguri că nu livrezi pachete corupte. Pot apărea surprize inclusiv la partea de imagini publice. Nu știi niciodată când este preluat contul cuiva și se pun imagini compromise. Depinde de modalitatea în care faci versionare, de alegerea de a face lock sau get latest version. Dacă se merge pe get latest version, e problematic să nu faci validări sau scanări, deoarece nu poți ști ce conține ultima versiune.
Alexandru Dascăl: E bine să ai o singură aplicație per container, să nu rulezi zeci de procese în același container, să faci curățenie după tine. De exemplu, a fost nevoie de ceva cURL pentru a aduce niște componente, iar acel cURL a rămas în pachet, ceea ce nu e de dorit. Trebuie să te folosești foarte mult de modul în care lucrează Docker. Docker are un caching layer, chiar foarte puternic, iar dacă trebuie să rulezi același tip de comandă de mai multe ori în secvență, ar trebui să împachetezi totul într-o singură comandă de Docker, deoarece vor fi cachuite când reconstruiești imaginea și dai o comandă mai jos, deci nu mai treci prin toate layerele încă o dată.
Máté Lang: Cred că ordinea operațiilor este cea mai importantă. Trebuie să punem lucrurile care se schimbă rar, cel mai sus pentru a evita comportamentul de caching și a economisi timp de fiecare dată când facem build. Am observat în multe contexte că se folosește Docker pentru runtime, dar nu pentru builduri. Utilizarea de Docker pentru builduri ar elimina celebra "It works on my machine", astfel încât să ne asigurăm că totul funcționează nu doar local, ci și în mediul CI (sau alte medii). Docker are noțiunea multi-stage builds, adică poate seta mai multe containere, iar în imagine să fie doar rezultatul final creat, dar, între timp, să folosesc și alte containere de tip builder. De exemplu, vrem să facem o aplicație în Java. Pentru a rula această aplicație am nevoie de runtime environment, dar pentru a face build am nevoie de JDK. Pot face un fișier Docker în care, în prima parte să iau un JDK, să facă build la un .jar, iar apoi să-mi transfer acel .jar în a doua imagine. Diferența de dimensiune poate fi și de sute de mega, iar asta contează pentru un deployment mare.
Puteți da un exemplu de problemă din producție?
Máté Lang: Se spune că toată lumea testează în producție. La noi, totul este amplificat de cele zeci de milioane de requesturi pe minut. Noi am avut probleme cu race condition în kernel. O problemă pe care nu am rezolvat-o complet este că am încercat să introducem Istio în stackul nostru pentru a merge în producție cu un grad mai mare de securitate, totul automatizat cu sistemul nostru de monitorizare. Am ajuns să facem deploy la Istio fără probleme până când am pus pe el 10% din traficul nostru din producție, rezultatul fiind că numărul nostru de socketuri a crescut până la cer. Am descoperit că problema ține de ENVOY care are un timp de răspuns la API-uri foarte mic, având strategia de a crea conexiuni de tip TCP foarte agresiv. La un API care răspunde în câteva nanosecunde, acest lucru poate fi o problemă.
Marius Ciotloș: Am reușit să consumăm toate conexiunile unei baze de date, problema apărând dintr-o înșiruire de evenimente: trafic crescut, tabele cam mari, fragmentarea unei baze de date, timeout agresiv în zona de aplicație, retry-uri în cascadă. Fiind cauze multiple și adunate în timp, a durat până am identificat cauzele problemei. Avem alertare pe bază de metrici, loguri, filtre. De exemplu, avem alerte pe loguri pe partea de certificate.
Alexandru Dascăl: În context non-Kubernetes, doar Docker host simplu, am avut o problemă în care un disc din trei nu mai era disponibil. Când am investigat cauzele, am descoperit că avea mii de procese care rulau, un VM foarte mic. Mulți uită să aibă fișiere Init care să omoare orice proces zombie sau proces rămas fără părinți. Soluția a fost reconstruirea containerelor și adăugarea unui sistem foarte mic numit Tiny sub care trebuie rulat procesul principal.
Care sunt avantajele și dezavantajele diverșilor furnizori de cloud?
Alexandru Dascăl: Nu trebuie reinventată roata. Pentru niște procese esențiale din producție, ori nu le stăpânești cum trebuie, ori nu ai resursele să le stăpânești cum trebuie. Pentru date, orice soluție cloud este bună, beneficiind de uptime-ul furnizorului. Dar vei avea proleme de backup, disaster recovery dacă menții serverele pe cont propriu. Evident, dacă ai o echipă foarte bună care se ocupă doar cu servere și baza de date, e perfect. Altfel, un furnizor cloud e optim.
Máté Lang: Pentru o companie care se află la început, pentru un start-up, recomand orice furnizor de servicii cloud, public cloud. Pe măsură ce crești, poți lua decizia de a face hosting intern. De exemplu, pe măsură ce firma noastră a crescut, am luat decizia de a face noi hosting de Elasticsearch, pentru că alternativa era prea scumpă. La fel facem acum și cu monitorizarea.
Marius Ciotloș: Totul se rezumă la cost și educație. La început e ușor să folosești servicii cloud out of the box. Pe măsură ce crești, deciziile vor fi luate în funcție de cost. Un alt aspect când folosești servicii cloud și ai echipe multiple ce le folosesc este de a te asigura că reduci numărul de servicii folosite în paralel dacă acestea fac același lucru.
Cum vedeți viitorul DevOps?
Marius Ciotlos: Se merge foarte mult pe scris cod, automatizare chiar și în troubleshooting fără a fi nevoie de intervenție de specialitate.
Alexandru Dascăl: Poziția, cultura de DevOps va cam dispărea. Se merge în specializarea de ingineri de infrastructură sau platformă. Iar partea aceasta de DevOps începe să fie abordată de developeri clasici.
Máté Lang: Sunt total de acord cu colegii mei. Aș dori să reamintesc un episod de acum câțiva ani când s-a lansat un Operator SDK în Kubernetes. Creatorii Kubernetes au dat șansa programatorilor de a include toate conceptele și procesele operaționale (sau de mentenanță) în cod pentru a monitoriza, de exemplu, infrastructura ta de MongoDB.
de Ovidiu Mățan
de Mihai Talpoș
de Radu Saveanu
