ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 149
Numărul 148 Numărul 147 Numărul 146 Numărul 145 Numărul 144 Numărul 143 Numărul 142 Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 87
Abonament PDF

Dezastre DevOps: Suprautilizarea toolurilor și greșelile aferente

Iacob Nicolaev
DevOps Engineer @ msg systems Romania



PROGRAMARE

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:

Problemele

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.

Acum e timpul pentru Docker.

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.

Efectul fluture

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.

Comportați-vă ca un DevOps adevărat

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.

Concluzii

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.

NUMĂRUL 149 - Development with AI

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • P3 group
  • Ing Hubs
  • Cognizant Softvision
  • Colors in projects