Un fenomen foarte interesant își face apariția în peisajul cotidian. Se referă la toolurile specifice pe care le utilizăm în mediul de lucru al noastru. În multe situații, inginerii acționează pe baza intuiției când au de terminat o sarcină de lucru. Înțelegerea și cunoștințele noastre sunt limitate de multe ori la câteva tooluri specifice cu care avem experiență. Ne punem aceste cunoștințe în aplicare pentru a rezolva problemele pentru care toolurile nu oferă o soluție corectă. Mai există și o tendință să luăm tooluri la modă și să le folosim cu scopul pentu care nu au fost create și în contextul nepotrivit.
Cauza problemei poate fi faptul că nu suntem dispuși să înțelegem designul intenționat pentru toolul ales. Lipsa de comunicare între experți și cunoștințele deficitare pot fi o altă cauză.
Colaborarea DevOps eșuează și ne aflăm în situația ca partea Dev să știe mai puțin despre Ops, iar Ops mai puțin despre Dev. Fiecare suprautilizează toolurile cunoscute.
Ca rezultat avem:
Prezentăm câteva situații din viața reală ce apar când suprautilizăm toolurile.
Să analizăm cum stau lucrurile în lumea Ansible.
Ansible este un tool ce gestionează configurațiile. Unul din avantajele sale majore este stilul declarativ de a programa infrastructura. Trebuie doar să declarați ceea ce doriți, iar Ansible face restul.
În multe organizații exista mult cod Ansible ce încearcă să reproducă fiecare linie de Bash script în cod de Ansible. Aceste organizații nu sunt dispuse să își modifice procesele ca să adopte conceptele Ansible. De obicei, aceste organizații supra-utilizează modulele shell sau command. De ce este acest lucru rău? Aceste practici implică o serie de probleme pentru tool-ul în sine, de exemplu lipsa de Echipotență. Prin urmare, codul nu va verifica starea resurselor de pe mașină. Astfel, pierdem unul din cele mai mari avantaje ale Ansible și ale altor tooluri de configurare. Ne putem aștepta la mai mult consum CPU și la mai mult timp de execuție. Mai mult, acest lucru face codul OS dependent, iar puterea de abstracție Ansible devine inutilizabilă. Mai mult, este greu de corectat, de testat, de întreținut. Ansible nu este gândit să își ruleze propriul cod drept comenzi executate linie cu linie, dar este forțat să facă acest lucru. Este mai bine să folosim un stil de programare declarativă, iar toolul să decidă modul de execuție. Bunele practici spun că nu trebuie folosit shell sau command deloc. Acest lucru se întâmplă când inginerii cad în capcana tehnologiilor la modă, dar continuă să scrie cod așa cum sunt obișnuiți.
Este un caz interesant în care Docker este împachetat in scripturi bash: o livrare complet automatizată a unui produs multi-container Docker prin intermediul unor script-uri bash, ceea ce este un hack. Cu intenții bune, rezultatul a fost unul devastator care a adus cu sine multe probleme pentru acest produs fiind în producție. Aplicația cu taskuri automatizate care configura legătura la containerul bazei de date prin adresa IP internă docker. Nu e nimic special, rețeaua de default a Dockerului. Ca rezultat al acestei abordări, restartarea serverului a dus la modificarea adresei IP pentru containerul Docker. Aplicația nu a putut porni, nu s-a putut lega la baza de date, deoarece adresa IP se schimbase. Suprautilizarea bashului nu doar că a generat un defect în producție, ci a făcut greu de înțeles structura aplicației care a fost ulterior greu de corectat. Variabilele au fost greu de schimbat. Lipsa dorinței de a învăța ceva nou, precum docker-compose, și experiența cu scripturile bash, au facilitat apariția problemei, astfel încât avem acest exemplu de suprautilizare de scripturi shell.
Suprautilizarea unui limbaj de programare pentru a rula o comandă docker-compose. Nu este un lucru rău dacă se folosește un API specific. Cazurile în care avem o funcție exec într-un program pentru a acoperi o comandă docker-compose up este un hack urît. Docker nu a putut porni și nu au existat mesaje de eroare. Imperativul termenului limită "să fie gata acum" și zona de confort (limbajul de programare) au pus capac. O opțiune corectă și mai rapidă era un plug-in maven, un script bash (folosit corect) sau chiar un pas manual (o specificație).
Un exemplu bun de suprautilizare docker este folosirea acestuia ca mașină virtuală, deși acest lucru poate aduce probleme în mediul de producție. Cea mai bună practică este utilizarea docker ca serviciu pentru procese individuale. Utilizarea sa cu systemd sau un alt tool pentru gestionarea proceselor va face mai greoaie monitorizarea aplicației voastre în container. Acest lucru va da impresia falsă că aplicația voastră rulează. Tradiționala comandă "CTRL-C" nu va funcționa dacă realizați greșit imaginile docker.
Suprautilizarea toolurilor ne forțează pe noi, inginerii, să ne păstrăm nivelul de dezvoltare personală la același nivel pentru mulți ani, devenind dinozauri ai lumii IT. Dacă nu ținem pasul cu noile tehnologii, le vom folosi incorect pentru că nu le înțelegem.
Acest fapt aduce și mai multe probleme pentru organizații și proiecte, cel mai mare fiind codul învechit (legacy code) sau situații în care o singură persoană știe cum funcționează un sistem (pentru că nu funcționează ca în manual sau documentație). Codul este plin de hackuri. Întreținerea sa este costisitoare la nivel de timp, calitate, bani. Aducerea oamenilor noi în proiect este un proces greu și consumator de timp. În proiectele unde acest fenomen este prezent, acomodarea noilor ingineri poate dura un an sau mai mult. Timpul înseamnă bani.
Totuși, cel mai periculos lucru este să aduci practicile greșite în comunitate. În comunitate se învață, se face schimb de informație și se inovează. Mi s-au întâmplat aceste lucruri în comunitatea Terraform unde inginerii încercau să adapteze Terraform să facă ceva pentru care nu a fost menit: de exemplu, menținerea codului "la zi" în mediul de producție prin intermediul Terraform. Am pierdut multe ore încercând să rezolv problemele. Evident, se pierd multe resurse, dar se diminuează și entuziasmul echipelor și al indivizilor.
Toolurile trebuie folosite doar cu scopul pentru care au fost concepute. Dacă un astfel de tool nu există, creați-l și aduceți-l în comunitate.
Este recomandat să nu deviați de la documentația oficială. Uneori nu suntem suficient de flexibili în utilizarea unui tool, dar e bine să nu îl deturnați pentru scopuri proprii. Aduceți problema în atenția comunității și creați o funcție sau un plugin pentru tool.
Dacă suprautilizați tooluri DevOps și nu doar, vă rog să vă opriți. Dacă le folosiți cu scopul pentru care au fost concepute, contribuiți la comunitate. Contribuiți la Stack Overflow și îmbunătățiți-l. Intrați în comunitate și învățați-i pe ceilalți cum să procedeze. Utilizarea corectă a instrumentelor se reflectă în calitatea infrastructurii. Un element cheie pe care îl putem măsura este punctul de intrare al oamenilor în organizație. Dacă codul și programele ar vorbi de la sine, nu am avea nevoie de explicații. Nu ar exista drumuri secrete sau magice. Cu cât indivizii se integrează mai ușor într-o echipă și pot modifica programul, cu atât mai bine folosesc toolurile DevOps.
După cum știm DevOps nu este doar despre toolurile utilizate, dar acestea ne pot face viața mai ușoară și mai efervescentă. Haosul este foarte mare și trebuie să îl eliminăm. Construirea unei arhitecturi bune este mai importantă decât scrierea liniilor de cod. Trebuie să aprofundăm problema, să alegem soluția optimă.
Exista multe scheme care se actualizează în continuu cu tooluri DevOps. Impactul fiecărui tool este atent analizat. Fiecare tool trebuie potrivit unui scop și actualizat. Oamenii se vor integra mai repede, iar soluțiile vor fi produsul tehnologiilor și al echipelor. Soluția voastră nu se va axa pe o singură sursă nedocumentată cunoscuta ca "Colegul care le știe pe toate".
Stă în puterea voastră să facem lumea mai bună. Gândiți, programați, împărtășiți!
Nu uitați că putem măsura DevOps și ar trebui să o facem cu unitățile de măsură potrivite.
de Vasile Boris
de Ovidiu Mățan
