Anticipand Vitali Khabarov intervievat Dmitri Stolyarov (), director tehnic și co-fondator al companiei Flant. Vitaly l-a întrebat pe Dmitry despre ce face Flant, despre Kubernetes, dezvoltarea ecosistemului, suport. Am discutat de ce este necesar Kubernetes și dacă este necesar. Și, de asemenea, despre microservicii, Amazon AWS, abordarea „Voi fi norocos” a DevOps, viitorul Kubernetes în sine, de ce, când și cum va prelua lumea, perspectivele DevOps și pentru ce ar trebui să se pregătească inginerii în viitor luminos și apropiat cu simplificare și rețele neuronale.
ascultați sub formă de podcast pe DevOps Deflop - un podcast în limba rusă despre DevOps, iar mai jos este versiunea text.
Aici și mai jos pune întrebări inginer de la Express42.
Despre „Flant”
- Bună Dima. Sunteți directorul tehnic"" și, de asemenea, fondatorul acesteia. Vă rugăm să ne spuneți ce face compania și ce sunteți în ea?
Dmitry: Din exterior, se pare că suntem tipii care instalează Kubernetes pentru toată lumea și face ceva cu el. Dar asta nu este adevărat. Am început ca o companie care se ocupă de Linux, dar de foarte multă vreme activitatea noastră principală a fost deservirea de producție și proiecte la cheie. De obicei construim întreaga infrastructură de la zero și apoi suntem responsabili pentru ea mult, mult timp. Prin urmare, principala lucrare pe care o face „Flant”, pentru care primește bani, este asumarea responsabilității și implementarea producției la cheie.
Eu, în calitate de director tehnic și unul dintre fondatorii companiei, petrec toată ziua și noaptea încercând să-mi dau seama cum să măresc accesibilitatea producției, să simplific funcționarea acesteia, să fac viața administratorilor mai ușoară și viața dezvoltatorilor mai plăcută. .
Despre Kubernetes
— În ultimul timp, am văzut o mulțime de rapoarte de la Flant și despre Kubernetes. Cum ai ajuns la asta?
Dmitry: Am vorbit deja despre asta de multe ori, dar nu mă deranjează să o repet deloc. Cred că este corect să repet acest subiect pentru că există o confuzie între cauză și efect.
Chiar aveam nevoie de un instrument. Ne-am confruntat cu multe probleme, ne-am luptat, le-am depășit cu diverse cârje și am simțit nevoia unui instrument. Am trecut prin multe opțiuni diferite, ne-am construit propriile biciclete și am câștigat experiență. Treptat, am ajuns la punctul în care am început să folosim Docker aproape de îndată ce a apărut - în jurul anului 2013. La momentul apariției sale, aveam deja multă experiență cu containerele, scrisesem deja un analog al „Docker” - unele dintre propriile noastre cârje în Python. Odată cu apariția lui Docker, a devenit posibil să aruncați cârjele și să utilizați o soluție de încredere și susținută de comunitate.
Cu Kubernetes povestea este similară. Până când a început să capete amploare - pentru noi aceasta este versiunea 1.2 - aveam deja o grămadă de cârje atât pe Shell, cât și pe Chef, pe care am încercat cumva să le orchestrăm cu Docker. Ne uitam serios către Rancher și diverse alte soluții, dar apoi a apărut Kubernetes, în care totul este implementat exact așa cum am fi făcut noi sau chiar mai bine. Nu este nimic de reproșat.
Da, există un fel de imperfecțiune aici, există un fel de imperfecțiune acolo - sunt o mulțime de imperfecțiuni, iar 1.2 este în general groaznic, dar... Kubernetes este ca o clădire în construcție - te uiți la proiect și înțelegi ca va fi misto. Dacă clădirea are acum o fundație și două etaje, atunci înțelegeți că este mai bine să nu vă mutați încă, dar nu există astfel de probleme cu software-ul - îl puteți utiliza deja.
Nu am avut un moment în care să ne gândim să folosim Kubernetes sau nu. L-am așteptat cu mult înainte să apară și am încercat să creăm noi înșine analogi.
Despre Kubernetes
— Sunteți direct implicat în dezvoltarea Kubernetes în sine?
Dmitry: Mediocru. Mai degrabă, participăm la dezvoltarea ecosistemului. Trimitem un anumit număr de solicitări pull: către Prometheus, către diverși operatori, către Helm - către ecosistem. Din păcate, nu sunt în stare să țin evidența a tot ceea ce facem și aș putea să greșesc, dar nu există un singur grup de la noi în miez.
— În același timp, dezvoltați multe dintre instrumentele dvs. în jurul Kubernetes?
Dmitry: Strategia este aceasta: mergem și tragem cereri la tot ce există deja. Dacă cererile de extragere nu sunt acceptate acolo, pur și simplu le furcăm noi înșine și trăim până când sunt acceptate cu versiunile noastre. Apoi, când ajunge în amonte, ne întoarcem la versiunea în amonte.
De exemplu, avem un operator Prometheus, cu care am trecut probabil de 5 ori înainte și înapoi în amonte de ansamblul nostru. Avem nevoie de un fel de caracteristică, am trimis o cerere de extragere, trebuie să o lansăm mâine, dar nu vrem să așteptăm ca aceasta să fie lansată în amonte. În consecință, asamblam pentru noi înșine, lansăm ansamblul nostru cu caracteristica noastră, de care avem nevoie dintr-un motiv oarecare, în toate clusterele noastre. Apoi, de exemplu, ni-l întorc în amonte cu cuvintele: „Băieți, să o facem pentru un caz mai general”, noi sau altcineva îl terminăm și, în timp, se îmbină din nou.
Încercăm să dezvoltăm tot ce există. Multe elemente care încă nu există, nu au fost încă inventate sau au fost inventate, dar nu au avut timp să le implementeze – o facem. Și nu pentru că ne place procesul sau construirea bicicletelor ca industrie, ci pur și simplu pentru că avem nevoie de acest instrument. Se pune adesea întrebarea, de ce am făcut asta sau aia? Răspunsul este simplu - da, pentru că a trebuit să mergem mai departe, să rezolvăm o problemă practică și am rezolvat-o cu această tulă.
Calea este întotdeauna așa: căutăm foarte atent și, dacă nu găsim nicio soluție pentru a face un troleibuz dintr-o pâine, atunci ne facem propria pâine și propriul troleibuz.
Instrumente Flanta
— Știu că Flant are acum operatori de suplimente, operatori shell și instrumente dapp/werf. După cum am înțeles, acesta este același instrument în diferite încarnări. Înțeleg, de asemenea, că există mai multe instrumente diferite în Flaunt. Asta este adevărat?
Dmitry: Avem mult mai multe pe GitHub. Din câte îmi amintesc acum, avem o hartă de stare - un panou pentru Grafana pe care toată lumea l-a întâlnit. Este menționat în aproape fiecare al doilea articol despre monitorizarea Kubernetes pe Medium. Este imposibil să explici pe scurt ce este o hartă de stare - are nevoie de un articol separat, dar este un lucru foarte util pentru monitorizarea stării în timp, deoarece în Kubernetes trebuie adesea să arătăm starea în timp. Avem, de asemenea, LogHouse - acesta este un lucru bazat pe ClickHouse și magie neagră pentru colectarea jurnalelor în Kubernetes.
O mulțime de utilități! Și vor fi și mai multe, pentru că o serie de soluții interne vor fi lansate în acest an. Dintre cele foarte mari bazate pe operatorul de suplimente, există o grămadă de suplimente pentru Kubernetes, cum să instalați corect sert manager - un instrument pentru gestionarea certificatelor, cum să instalați corect Prometheus cu o grămadă de accesorii - acestea sunt aproximativ douăzeci diferite binare care exportă date și colectează ceva, la acest Prometheus are cele mai uimitoare grafice și alerte. Toate acestea sunt doar o grămadă de suplimente pentru Kubernetes, care sunt instalate într-un cluster, și se transformă de la simplu la cool, sofisticat, automat, în care multe probleme au fost deja rezolvate. Da, facem multe.
Dezvoltarea ecosistemului
„Mi se pare că aceasta este o contribuție foarte mare la dezvoltarea acestui instrument și a metodelor sale de utilizare.” Puteți estima aproximativ cine altcineva ar aduce aceeași contribuție la dezvoltarea ecosistemului?
Dmitry: În Rusia, dintre companiile care operează pe piața noastră, nimeni nu este nici măcar aproape. Desigur, aceasta este o declarație tare, deoarece există jucători importanți precum Mail și Yandex - fac și ei ceva cu Kubernetes, dar nici măcar ei nu se apropie de contribuția companiilor din întreaga lume care fac mult mai mult decât noi. Este greu de comparat Flant, care are un personal de 80 de oameni, și Red Hat, care are 300 de ingineri doar pe Kubernetes, dacă nu mă înșel. E greu de comparat. Avem 6 oameni în departamentul RnD, printre care și eu, care ne tăiau toate sculele. 6 oameni față de 300 de ingineri Red Hat - este cumva dificil de comparat.
- Totuși, când chiar și acești 6 oameni pot face ceva cu adevărat util și alienant, când se confruntă cu o problemă practică și dau soluția comunității - un caz interesant. Înțeleg că în marile companii de tehnologie, unde au propria lor echipă de dezvoltare și suport Kubernetes, în principiu, se pot dezvolta aceleași instrumente. Acesta este un exemplu pentru ei a ceea ce poate fi dezvoltat și dat comunității, dând un impuls întregii comunități care utilizează Kubernetes.
Dmitry: Aceasta este probabil o caracteristică a integratorului, particularitatea sa. Avem multe proiecte și vedem multe situații diferite. Pentru noi, principala modalitate de a crea valoare adăugată este să analizăm aceste cazuri, să găsim elemente comune și să le facem cât mai ieftine pentru noi. Lucrăm activ la acest lucru. Îmi este greu să vorbesc despre Rusia și despre lume, dar avem aproximativ 40 de ingineri DevOps în companie care lucrează pe Kubernetes. Nu cred că există multe companii în Rusia cu un număr comparabil de specialiști care să înțeleagă Kubernetes, dacă există.
Înțeleg totul despre titlul postului Inginer DevOps, toată lumea înțelege totul și este obișnuit să numească inginerii DevOps ingineri DevOps, nu vom discuta despre asta. Toți acești 40 de ingineri uimitori DevOps se confruntă și rezolvă probleme în fiecare zi, doar analizăm această experiență și încercăm să generalizăm. Înțelegem că dacă rămâne în interiorul nostru, atunci într-un an sau doi instrumentul va fi inutil, pentru că undeva în comunitate va apărea un Tula gata făcut. Nu are rost să acumulezi această experiență în interior - pur și simplu consumă energie și timp în dev/null. Și nu ne pare deloc rău pentru asta. Publicăm totul cu mare plăcere și înțelegem că trebuie publicat, dezvoltat, promovat, promovat, astfel încât oamenii să-l folosească și să-și adauge experiența - apoi totul crește și trăiește. Apoi, după doi ani, instrumentul nu ajunge la gunoi. Nu este păcat să continui să dai putere, pentru că este clar că cineva folosește unealta ta, iar după doi ani toată lumea o folosește.
Aceasta face parte din marea noastră strategie cu dapp/werf. Nu-mi amintesc când am început să-l facem, se pare că acum 3 ani. Inițial, era în general pe coajă. A fost o super dovadă de concept, am rezolvat unele dintre problemele noastre particulare - a funcționat! Dar există probleme cu shell-ul, este imposibil să-l extinzi mai departe, programarea pe shell este o altă sarcină. Aveam obiceiul de a scrie în Ruby, în consecință, am refăcut ceva în Ruby, am dezvoltat, dezvoltat, dezvoltat și am dat peste faptul că comunitatea, mulțimea care nu spune „vrem sau nu vrem, ” ridică nasul la Ruby, Cum nu e amuzant? Ne-am dat seama că ar trebui să scriem toate aceste lucruri în Go doar pentru a îndeplini primul punct din lista de verificare: Instrumentul DevOps ar trebui să fie un binar static. A fi Go sau nu nu este atât de important, dar un binar static scris în Go este mai bine.
Ne-am cheltuit energia, am rescris dapp-ul în Go și l-am numit werf. Dapp nu mai este acceptat, nu mai este dezvoltat, rulează în cea mai recentă versiune, dar există o cale de actualizare absolută către vârf și o puteți urma.
De ce a fost creat dapp-ul?
— Ne puteți spune pe scurt de ce a fost creat dapp-ul, ce probleme rezolvă?
Dmitry: Primul motiv este în adunare. Inițial, am avut probleme serioase cu construcția când Docker nu avea capabilități în mai multe etape, așa că am făcut singuri mai multe etape. Apoi am avut o grămadă de probleme cu curățarea imaginii. Toți cei care fac CI/CD, mai devreme decât mai târziu, se confruntă cu problema că există o grămadă de imagini colectate, trebuie să curățați cumva ceea ce nu este necesar și să lăsați ceea ce este necesar.
Al doilea motiv este desfășurarea. Da, există Helm, dar rezolvă doar câteva dintre probleme. Destul de amuzant, este scris că „Helm este managerul de pachete pentru Kubernetes”. Exact ce „cel”. Există, de asemenea, cuvintele „Manager de pachete” - care este așteptarea obișnuită de la un Manager de pachete? Spunem: „Manager de pachete - instalați pachetul!” și ne așteptăm să ne spună: „Pachetul a fost livrat”.
Este interesant că spunem: „Helm, instalează pachetul”, iar când el răspunde că l-a instalat, se dovedește că tocmai a început instalarea - el a indicat Kubernetes: „Lansează chestia asta!” și dacă a început sau nu , indiferent dacă funcționează sau nu, Helm nu rezolvă deloc această problemă.
Se pare că Helm este doar un preprocesor de text care încarcă date în Kubernetes.
Dar, ca parte a oricărei implementări, vrem să știm dacă aplicația a fost lansată pentru producție sau nu? Lansat la prod înseamnă că aplicația s-a mutat acolo, noua versiune a fost implementată și cel puțin nu se blochează acolo și răspunde corect. Helm nu rezolvă această problemă în niciun fel. Pentru a o rezolva, trebuie să depui mult efort, pentru că trebuie să îi dai lui Kubernetes comanda să lanseze și să monitorizeze ceea ce se întâmplă acolo - indiferent dacă a fost implementat sau lansat. Și există, de asemenea, o mulțime de sarcini legate de implementare, curățare și asamblare.
Planuri
Anul acesta vom începe dezvoltarea locală. Vrem să realizăm ceea ce era anterior în Vagrant - am tastat „vagrant up” și am implementat mașini virtuale. Vrem să ajungem la punctul în care există un proiect în Git, scriem „werf sus” acolo și aduce o copie locală a acestui proiect, implementată într-un mini-Kub local, cu toate directoarele convenabile pentru dezvoltare conectate . În funcție de limbajul de dezvoltare, acest lucru se face diferit, dar totuși, astfel încât dezvoltarea locală să poată fi realizată convenabil sub fișiere montate.
Următorul pas pentru noi este investiți în comoditate pentru dezvoltatori. Pentru a implementa rapid un proiect la nivel local cu un singur instrument, dezvoltați-l, împingeți-l în Git și, de asemenea, va fi lansat în scenă sau testare, în funcție de conducte, apoi utilizați același instrument pentru a trece la producție. Această unitate, unificare, reproductibilitate a infrastructurii de la mediul local până la vânzări este un punct foarte important pentru noi. Dar acest lucru nu este încă în werf - doar plănuim să o facem.
Dar calea către dapp/werf a fost întotdeauna aceeași ca și cu Kubernetes la început. Am întâmpinat probleme, le-am rezolvat cu soluții - am venit cu niște soluții pentru noi înșine pe shell, pe orice. Apoi au încercat să îndrepte cumva aceste soluții, să le generalizeze și să le consolideze în binare în acest caz, pe care pur și simplu le împărtășim.
Există un alt mod de a privi toată această poveste, cu analogii.
Kubernetes este un cadru de mașină cu motor. Nu există uși, sticlă, radio, brad - nimic. Doar cadrul și motorul. Și există Helm - acesta este volanul. Cool - există un volan, dar aveți nevoie și de un știft de direcție, cremalieră de direcție, cutie de viteze și roți și nu vă puteți descurca fără ele.
În cazul werf, aceasta este o altă componentă a Kubernetes. Abia acum, în versiunea alfa a werf, de exemplu, Helm este compilat în interiorul werf, pentru că ne-am săturat să o facem singuri. Există multe motive pentru a face acest lucru, vă voi spune în detaliu de ce am compilat întreaga cârmă împreună cu tiller în interiorul werf .
Acum werf este o componentă mai integrată. Obținem un volan terminat, un știft de direcție - nu sunt foarte bun la mașini, dar acesta este un bloc mare care rezolvă deja o gamă destul de largă de probleme. Nu trebuie să parcurgem singuri catalogul, să selectăm o piesă pentru alta, să ne gândim cum să le înșurubam. Obținem o combină gata făcută care rezolvă un număr mare de probleme simultan. Dar în interiorul său este construit din aceleași componente open source, încă folosește Docker pentru asamblare, Helm pentru unele dintre funcționalități și există câteva alte biblioteci. Acesta este un instrument integrat pentru a scoate CI/CD cool din cutie rapid și convenabil.
Este Kubernetes greu de întreținut?
— Vorbești despre experiența în care ai început să folosești Kubernetes, acesta este un cadru pentru tine, un motor, și pe care poți agăța o mulțime de lucruri diferite: o caroserie, un volan, pedale cu șuruburi, scaune. Apare întrebarea - cât de dificil este suportul Kubernetes pentru dvs.? Aveți multă experiență, cât timp și cât resurse cheltuiți pentru a susține Kubernetes izolat de orice altceva?
Dmitry: Aceasta este o întrebare foarte dificilă și pentru a răspunde, trebuie să înțelegem ce este suportul și ce dorim de la Kubernetes. Poate poți dezvălui?
— Din câte știu și din câte văd, acum multe echipe vor să încerce Kubernetes. Toată lumea se înhamează de ea, o pune în genunchi. Am sentimentul că oamenii nu înțeleg întotdeauna complexitatea acestui sistem.
Dmitry: Este ca asta.
— Cât de dificil este să luați și să instalați Kubernetes de la zero, astfel încât să fie gata de producție?
Dmitry: Cât de dificil crezi că este să transplantezi o inimă? Înțeleg că aceasta este o întrebare compromițătoare. Folosirea unui bisturiu și a nu greși nu este atât de dificil. Dacă vă spun unde să tăiați și unde să coaseți, atunci procedura în sine nu este complicată. Este dificil să garantezi din când în când că totul va funcționa.
Instalarea Kubernetes și punerea în funcțiune este ușor: pui! — instalat, există o mulțime de metode de instalare. Dar ce se întâmplă când apar probleme?
Întotdeauna apar întrebări - ce nu am luat încă în considerare? Ce nu am făcut încă? Ce parametri ai nucleului Linux au fost specificați incorect? Doamne, chiar le-am pomenit?! Ce componente Kubernetes am livrat și care nu? Apar mii de întrebări, iar pentru a le răspunde, trebuie să petreci 15-20 de ani în această industrie.
Am un exemplu recent pe acest subiect care poate dezvălui semnificația problemei „Este Kubernetes dificil de întreținut?” În urmă cu ceva timp, ne-am gândit serios dacă ar trebui să încercăm să implementăm Cilium ca rețea în Kubernetes.
Lasă-mă să explic ce este Cilium. Kubernetes are multe implementări diferite ale subsistemului de rețea, iar una dintre ele este foarte cool - Cilium. Care este sensul lui? În nucleu, cu ceva timp în urmă a devenit posibil să scrieți cârlige pentru nucleu, care într-un fel sau altul invadează subsistemul de rețea și diverse alte subsisteme și vă permit să ocoliți bucăți mari din nucleu.
Nucleul Linux are în mod istoric o rută IP, un filtru excesiv, punți și multe componente vechi diferite care au 15, 20, 30 de ani. În general, funcționează, totul este grozav, dar acum au îngrămădit containere și arată ca un turn de 15 cărămizi una peste alta și stai pe el pe un picior - un sentiment ciudat. Acest sistem s-a dezvoltat istoric cu multe nuanțe, cum ar fi apendicele din corp. În unele situații există probleme de performanță, de exemplu.
Există un BPF minunat și abilitatea de a scrie cârlige pentru nucleu - băieții și-au scris propriile cârlige pentru nucleu. Pachetul vine în nucleul Linux, îl scot chiar la intrare, îl procesează ei înșiși așa cum ar trebui, fără punți, fără TCP, fără o stivă IP - pe scurt, ocolind tot ce este scris în nucleul Linux și apoi scuipă scoate-l în recipient.
Ce s-a întâmplat? Performanță foarte grozavă, caracteristici interesante - doar grozav! Dar ne uităm la asta și vedem că pe fiecare mașină există un program care se conectează la API-ul Kubernetes și, pe baza datelor pe care le primește de la acest API, generează cod C și compilează binare pe care le încarcă în kernel, astfel încât aceste cârlige să funcționeze în spațiul nucleului.
Ce se întâmplă dacă ceva nu merge bine? Nu știm. Pentru a înțelege acest lucru, trebuie să citiți tot acest cod, să înțelegeți toată logica și este uimitor cât de dificil este. Dar, pe de altă parte, există aceste punți, filtre de rețea, rută IP - nu le-am citit codul sursă și nici cei 40 de ingineri care lucrează în compania noastră. Poate doar câțiva înțeleg unele părți.
Și care este diferența? Se pare că există ruta IP, nucleul Linux și există un instrument nou - ce diferență face, nu înțelegem una sau alta. Dar ne este frică să folosim ceva nou - de ce? Pentru că dacă instrumentul are 30 de ani, atunci în 30 de ani au fost găsite toate bug-urile, toate greșelile au fost călcate și nu trebuie să știi despre totul - funcționează ca o cutie neagră și funcționează întotdeauna. Toată lumea știe ce șurubelniță de diagnosticare să bage în ce loc, care tcpdump să ruleze în ce moment. Toată lumea cunoaște bine utilitatile de diagnosticare și înțelege cum funcționează acest set de componente în nucleul Linux - nu cum funcționează, ci cum să-l folosească.
Și uimitor de cool Cilium nu are 30 de ani, nu a îmbătrânit încă. Kubernetes are aceeași problemă, copiați. Că Cilium este instalat perfect, că Kubernetes este instalat perfect, dar când ceva nu merge bine în producție, ești capabil să înțelegi rapid într-o situație critică ce a mers prost?
Când spunem că este dificil să întreținem Kubernetes - nu, este foarte ușor și da, este incredibil de dificil. Kubernetes funcționează excelent singur, dar cu un miliard de nuanțe.
Despre abordarea „Voi fi norocos”.
— Există companii unde aceste nuanțe sunt aproape garantate să apară? Să presupunem că Yandex transferă brusc toate serviciile către Kubernetes, acolo va fi o sarcină uriașă.
Dmitry: Nu, aceasta nu este o conversație despre încărcătură, ci despre cele mai simple lucruri. De exemplu, avem Kubernetes, am implementat aplicația acolo. De unde știi că funcționează? Pur și simplu nu există un instrument gata făcut pentru a înțelege că aplicația nu se prăbușește. Nu există un sistem gata făcut care să trimită alerte; trebuie să configurați aceste alerte și fiecare program. Și actualizăm Kubernetes.
Am Ubuntu 16.04. Puteți spune că aceasta este o versiune veche, dar suntem încă pe ea pentru că este LTS. Există systemd, a cărui nuanță este că nu curăță grupurile C. Kubernetes lansează pod-uri, creează grupuri C, apoi șterge pod-uri și, cumva, se dovedește - nu-mi amintesc detaliile, îmi pare rău - că rămân fragmente systemd. Acest lucru duce la faptul că, în timp, orice mașină începe să încetinească puternic. Aceasta nu este nici măcar o întrebare despre încărcare mare. Dacă sunt lansate poduri permanente, de exemplu, dacă există un Cron Job care generează constant poduri, atunci mașina cu Ubuntu 16.04 va începe să încetinească după o săptămână. Va exista o medie de încărcare constantă ridicată datorită faptului că au fost create o grămadă de grupuri C. Aceasta este problema cu care se va confrunta orice persoană care instalează pur și simplu Ubuntu 16 și Kubernetes deasupra.
Să presupunem că actualizează cumva systemd sau altceva, dar în nucleul Linux până la 4.16 este și mai amuzant - când ștergeți grupurile C, acestea se scurg în nucleu și nu sunt de fapt șterse. Prin urmare, după o lună de lucru la această mașină, va fi imposibil să ne uităm la statisticile de memorie pentru vetre. Scoatem un fișier, îl rulăm în program și un fișier rulează timp de 15 secunde, deoarece nucleul durează foarte mult timp pentru a număra un milion de grupuri C în sine, care par să fie șterse, dar nu - se scurg .
Există încă o mulțime de astfel de lucruri mărunte ici și colo. Aceasta nu este o problemă cu care companiile gigantice se pot confrunta uneori sub sarcini foarte grele - nu, este o chestiune de lucruri de zi cu zi. Oamenii pot trăi astfel luni de zile - au instalat Kubernetes, au implementat aplicația - se pare că funcționează. Pentru mulți oameni acest lucru este normal. Nici măcar nu vor ști că această aplicație se va bloca dintr-un motiv oarecare, nu vor primi o alertă, dar pentru ei aceasta este norma. Anterior, trăiam pe mașini virtuale fără monitorizare, acum ne-am mutat la Kubernetes, tot fără monitorizare - care este diferența?
Întrebarea este că atunci când mergem pe gheață, nu știm niciodată grosimea acesteia decât dacă o măsurăm în avans. Mulți oameni merg și nu își fac griji, pentru că au mai umblat.
Din punctul meu de vedere, nuanța și complexitatea operațiunii oricărui sistem este să ne asigurăm că grosimea gheții este exact suficientă pentru a ne rezolva problemele. Despre asta vorbim.
În IT, mi se pare, există prea multe abordări „voi fi norocos”. Mulți oameni instalează software și folosesc biblioteci de software în speranța că vor avea noroc. În general, mulți oameni sunt norocoși. Probabil de aceea funcționează.
— Din evaluarea mea pesimistă, arată așa: când riscurile sunt mari și aplicația trebuie să funcționeze, atunci este nevoie de sprijin de la Flaunt, poate de la Red Hat, sau aveți nevoie de propria echipă internă dedicată special Kubernetes, care este gata să-l scoată.
Dmitry: În mod obiectiv, așa este. A intra în povestea Kubernetes pentru o echipă mică pe cont propriu implică o serie de riscuri.
Avem nevoie de containere?
— Ne puteți spune cât de răspândit este Kubernetes în Rusia?
Dmitry: Nu am aceste date și nu sunt sigur că le are altcineva. Spunem: „Kubernetes, Kubernetes”, dar există un alt mod de a privi această problemă. De asemenea, nu știu cât de răspândite sunt containerele, dar știu o cifră din rapoartele de pe internet că 70% dintre containere sunt orchestrate de Kubernetes. A fost o sursă de încredere pentru un eșantion destul de mare din întreaga lume.
Apoi o altă întrebare - avem nevoie de containere? Sentimentul meu personal și poziția generală a companiei Flant este că Kubernetes este un standard de facto.
Nu va exista altceva decât Kubernetes.
Acesta este o schimbare absolută în domeniul managementului infrastructurii. Doar absolut - asta e, nu mai Ansible, Chef, mașini virtuale, Terraform. Nu vorbesc despre vechile metode de fermă colectivă. Kubernetes este un schimbător absolut, iar acum va fi doar așa.
Este clar că pentru unii este nevoie de câțiva ani, iar pentru alții de câteva decenii, pentru a realiza acest lucru. Nu am nicio îndoială că nu va exista altceva decât Kubernetes și acest nou aspect: nu mai deterioram sistemul de operare, ci folosim infrastructura ca cod, numai că nu cu cod, ci cu yml - o infrastructură descrisă declarativ. Am senzația că așa va fi mereu.
— Adică acele companii care nu au trecut încă la Kubernetes vor trece cu siguranță la el sau vor rămâne în uitare. te-am inteles bine?
Dmitry: Nici acest lucru nu este în întregime adevărat. De exemplu, dacă avem sarcina de a rula un server DNS, atunci acesta poate fi rulat pe FreeBSD 4.10 și poate funcționa perfect timp de 20 de ani. Doar muncește și atât. Poate că peste 20 de ani va trebui actualizat ceva o dată. Dacă vorbim de software în formatul pe care l-am lansat și chiar funcționează mulți ani fără nicio actualizare, fără a face modificări, atunci, desigur, nu va exista Kubernetes. Nu e nevoie de el acolo.
Tot ce ține de CI/CD - oriunde este nevoie de livrare continuă, acolo unde trebuie să actualizați versiunile, să faceți modificări active, oriunde aveți nevoie să construiți toleranță la erori - numai Kubernetes.
Despre microservicii
- Aici am o uşoară disonanţă. Pentru a lucra cu Kubernetes, aveți nevoie de suport extern sau intern - acesta este primul punct. În al doilea rând, când abia începem dezvoltarea, suntem un mic startup, nu avem încă nimic, dezvoltarea pentru Kubernetes sau arhitectura de microservicii în general poate fi complexă și nu întotdeauna justificată economic. Sunt interesat de părerea ta - startup-urile trebuie să înceapă imediat să scrie pentru Kubernetes de la zero sau pot să scrie un monolit și apoi să vină doar la Kubernetes?
Dmitry: Frumoasa intrebare. Am o discuție despre microservicii De multe ori am întâlnit oameni care încearcă să bată cuie cu un microscop. Abordarea în sine este corectă; noi înșine proiectăm software-ul nostru intern în acest fel. Dar când faci asta, trebuie să înțelegi clar ce faci. Cuvântul pe care îl urăsc cel mai mult despre microservicii este „micro”. Din punct de vedere istoric, acest cuvânt își are originea acolo și, din anumite motive, oamenii cred că micro este foarte mic, mai puțin de un milimetru, ca un micrometru. Este gresit.
De exemplu, există un monolit care este scris de 300 de oameni și toți cei care au participat la dezvoltare înțeleg că există probleme acolo și ar trebui să fie împărțit în micro-bucăți - aproximativ 10 bucăți, fiecare dintre acestea scrisă de 30 de persoane. într-o versiune minimă. Acest lucru este important, necesar și cool. Dar când vine la noi un startup, unde 3 tipi foarte cool și talentați au scris 60 de microservicii în genunchi, de fiecare dată când îl caut pe Corvalol.
Mi se pare că despre asta s-a vorbit deja de mii de ori - am primit un monolit distribuit într-o formă sau alta. Acest lucru nu este justificat din punct de vedere economic, este foarte dificil în general în toate. Tocmai am văzut asta de atâtea ori încât mă doare cu adevărat, așa că continui să vorbesc despre asta.
La întrebarea inițială, există un conflict între faptul că, pe de o parte, Kubernetes este înfricoșător de folosit, pentru că nu este clar ce s-ar putea rupe acolo sau nu funcționează, pe de altă parte, este clar că totul merge acolo. și nimic altceva decât Kubernetes nu va exista. Răspuns - cântăriți cantitatea de beneficii care vine, cantitatea de sarcini pe care le puteți rezolva. Aceasta este pe o parte a scalei. Pe de altă parte, există riscuri asociate cu timpul de nefuncționare sau cu o scădere a timpului de răspuns, a nivelului de disponibilitate - cu o scădere a indicatorilor de performanță.
Aici este - fie ne mișcăm rapid, iar Kubernetes ne permite să facem multe lucruri mult mai rapid și mai bine, fie folosim soluții fiabile, testate în timp, dar ne mișcăm mult mai încet. Aceasta este o alegere pe care trebuie să o facă fiecare companie. Te poți gândi la ea ca la o potecă în junglă - când mergi pentru prima dată, poți întâlni un șarpe, un tigru sau un bursuc nebun, iar când ai mers de 10 ori, ai călcat poteca, ai îndepărtat crengile și merg mai ușor. De fiecare dată calea devine mai largă. Apoi este un drum asfaltat, iar mai târziu un bulevard frumos.
Kubernetes nu sta pe loc. Din nou întrebare: Kubernetes, pe de o parte, este 4-5 binare, pe de altă parte, este întregul ecosistem. Acesta este sistemul de operare pe care îl avem pe mașinile noastre. Ce este asta? Ubuntu sau Curios? Acesta este nucleul Linux, o grămadă de componente suplimentare. Toate aceste lucruri aici, un șarpe veninos a fost aruncat de pe drum, acolo a fost ridicat un gard. Kubernetes se dezvoltă foarte rapid și dinamic, iar volumul riscurilor, volumul necunoscutului scade în fiecare lună și, în consecință, aceste scale se reechilibrează.
Răspunzând la întrebarea ce ar trebui să facă un startup, aș spune - vino la Flaunt, plătește 150 de mii de ruble și obține un serviciu ușor DevOps la cheie. Dacă sunteți un mic startup cu câțiva dezvoltatori, acest lucru funcționează. În loc să-ți angajezi propriul DevOps, care va trebui să învețe cum să-ți rezolve problemele și să plătească un salariu în acest moment, vei primi o soluție la cheie pentru toate problemele. Da, există câteva dezavantaje. Noi, ca externalizatori, nu putem fi atât de implicați și nu putem răspunde rapid la schimbări. Dar avem multă expertiză și practici gata făcute. Vă garantăm că, în orice situație, cu siguranță ne vom da seama rapid și vom ridica orice Kubernetes din morți.
Recomand cu tarie externalizarea startup-urilor si afacerilor consacrate pana la o dimensiune in care sa poti dedica operatiunilor o echipa de 10 oameni, pentru ca altfel nu are rost. Cu siguranță are sens să externalizezi acest lucru.
Despre Amazon și Google
— O gazdă dintr-o soluție de la Amazon sau Google poate fi considerată ca o externalizare?
Dmitry: Da, desigur, aceasta rezolvă o serie de probleme. Dar din nou există nuanțe. Încă trebuie să înțelegi cum să-l folosești. De exemplu, există o mie de lucruri mici în activitatea Amazon AWS: Load Balancer trebuie încălzit sau trebuie scrisă în prealabil o solicitare că „băieți, vom primi trafic, încălziți Load Balancer pentru noi!” Trebuie să cunoașteți aceste nuanțe.
Când apelezi la oameni care sunt specializați în asta, vei închide aproape toate lucrurile tipice. Acum avem 40 de ingineri, până la sfârșitul anului probabil vor fi 60 - cu siguranță ne-am întâlnit cu toate aceste lucruri. Chiar dacă întâlnim din nou această problemă la un proiect, ne întrebăm rapid unul pe celălalt și știm cum să o rezolvăm.
Probabil că răspunsul este - desigur, o poveste găzduită face o parte mai ușoară. Întrebarea este dacă ești gata să ai încredere în acești hosteri și dacă îți vor rezolva problemele. Amazon și Google s-au descurcat bine. Pentru toate cazurile noastre - exact. Nu mai avem experiențe pozitive. Toți ceilalți nori cu care am încercat să lucrăm creează o mulțime de probleme - Ager și tot ce este în Rusia și tot felul de OpenStack în diferite implementări: Headster, Overage - orice doriți. Toate creează probleme pe care nu vrei să le rezolvi.
Prin urmare, răspunsul este da, dar, de fapt, nu există foarte multe soluții găzduite mature.
Cine are nevoie de Kubernetes?
— Și totuși, cine are nevoie de Kubernetes? Cine ar trebui să treacă deja la Kubernetes, care este clientul tipic Flaunt care vine special pentru Kubernetes?
Dmitry: Aceasta este o întrebare interesantă, pentru că acum, în urma lui Kubernetes, mulți oameni vin la noi: „Băieți, știm că faceți Kubernetes, faceți-o pentru noi!” Le răspundem: „Domnilor, noi nu facem Kubernetes, facem prod și tot ce este legat de acesta.” Pentru că în prezent este pur și simplu imposibil să faci un produs fără a face tot CI/CD și toată povestea asta. Toată lumea s-a îndepărtat de diviziunea pe care o avem dezvoltare prin dezvoltare și apoi exploatare prin exploatare.
Clienții noștri se așteaptă la lucruri diferite, dar toată lumea așteaptă o minune bună că au anumite probleme, iar acum - hop! — Kubernetes le va rezolva. Oamenii cred în miracole. În mintea lor ei înțeleg că nu va exista nicio minune, dar în sufletul lor speră - dacă acest Kubernetes ne va rezolva totul acum, vorbesc atât de mult despre asta! Deodată el acum - strănută! - și un glonț de argint, strănută! — și avem un timp de funcționare de 100%, toți dezvoltatorii pot lansa orice intră în producție de 50 de ori și nu se blochează. In general, un miracol!
Când astfel de oameni vin la noi, spunem: „Îmi pare rău, dar nu există un miracol”. Pentru a fi sănătos, trebuie să mănânci bine și să faci sport. Pentru a avea un produs de încredere, acesta trebuie să fie realizat în mod fiabil. Pentru a avea un CI/CD convenabil, trebuie să îl faceți așa. Este multă muncă care trebuie făcută.
Răspunzând la întrebarea cine are nevoie de Kubernetes - nimeni nu are nevoie de Kubernetes.
Unii oameni au concepția greșită că au nevoie de Kubernetes. Oamenii au nevoie, au o nevoie profundă să nu mai gândească, să studieze și să fie interesați de toate problemele de infrastructură și de problemele rulării aplicațiilor lor. Ei vor ca aplicațiile să funcționeze și să fie implementate. Pentru ei, Kubernetes este speranța că vor înceta să mai audă povestea că „stăteam întinși acolo” sau „nu putem lansa” sau altceva.
Directorul tehnic vine de obicei la noi. Îi întreabă două lucruri: pe de o parte, să ne ofere caracteristici, pe de altă parte, stabilitate. Vă sugerăm să vă luați asupra dumneavoastră și să o faceți. Glonțul de argint, sau mai degrabă placat cu argint, este că nu te vei mai gândi la aceste probleme și vei pierde timpul. Vei avea oameni speciali care vor închide această problemă.
Formularea că noi sau oricine altcineva avem nevoie de Kubernetes este incorectă.
Administratorii au mare nevoie de Kubernetes, pentru că este o jucărie foarte interesantă cu care te poți juca și cu care te poți juca. Să fim sinceri - toată lumea iubește jucăriile. Toți suntem copii undeva și când vedem unul nou, vrem să ne jucăm. Pentru unii, acest lucru a fost descurajat, de exemplu, în administrație, pentru că au jucat deja suficient și sunt deja obosiți până la punctul în care pur și simplu nu vor. Dar acest lucru nu este complet pierdut pentru nimeni. De exemplu, dacă m-am săturat de jucării în domeniul administrării de sistem și DevOps de multă vreme, atunci încă ador jucăriile, mai cumpăr unele noi. Toți oamenii, într-un fel sau altul, mai doresc un fel de jucării.
Nu este nevoie să te joci cu producția. Orice recomand categoric să nu faci și ceea ce văd acum în masă: „O, o jucărie nouă!” — au alergat să-l cumpere, l-au cumpărat și: „Să o ducem acum la școală și să o arătăm tuturor prietenilor noștri.” Nu face asta. Îmi cer scuze, copiii mei doar cresc, văd în mod constant ceva la copii, îl observ în mine și apoi îl generalizez altora.
Răspunsul final este: nu aveți nevoie de Kubernetes. Trebuie să-ți rezolvi problemele.
Ceea ce puteți obține este:
- prod nu cade;
- chiar dacă încearcă să cadă, știm despre asta dinainte și putem pune ceva în el;
- îl putem schimba cu viteza cu care o cere afacerea noastră și o putem face convenabil; nu ne creează probleme.
Există două nevoi reale: fiabilitatea și dinamism/flexibilitatea lansării. Toți cei care realizează în prezent un fel de proiecte IT, indiferent în ce fel de afacere - soft pentru uşurarea lumii și care înțelege acest lucru, trebuie să rezolve aceste nevoi. Kubernetes cu abordarea corectă, cu înțelegerea corectă și cu suficientă experiență vă permite să le rezolvați.
Despre serverless
— Dacă te uiți puțin mai departe în viitor, atunci încercând să rezolvi problema absenței durerilor de cap cu infrastructura, cu viteza de lansare și viteza modificărilor aplicațiilor, apar noi soluții, de exemplu, serverless. Simțiți vreun potențial în această direcție și, să spunem, un pericol pentru Kubernetes și soluții similare?
Dmitry: Aici trebuie să facem din nou o remarcă că nu sunt un văzător care privește înainte și spune - va fi așa! Deși am făcut același lucru. Mă uit la picioarele mele și văd acolo o grămadă de probleme, de exemplu, cum funcționează tranzistorii într-un computer. E amuzant, nu? Întâmpinăm câteva erori în procesor.
Faceți fără server destul de fiabil, ieftin, eficient și convenabil, rezolvând toate problemele ecosistemului. Aici sunt de acord cu Elon Musk că este nevoie de o a doua planetă pentru a crea toleranță la greșeală pentru umanitate. Deși nu știu ce spune, înțeleg că eu nu sunt pregătit să zbor pe Marte și nu se va întâmpla mâine.
Cu serverless, este clar că acesta este un lucru corect din punct de vedere ideologic, cum ar fi toleranța la greșeală pentru umanitate - a avea două planete este mai bine decât una. Dar cum se face acum? Trimiterea unei expediții nu este o problemă dacă vă concentrați eforturile asupra ei. Trimiterea mai multor expediții și stabilirea a câteva mii de oameni acolo cred că este, de asemenea, realist. Dar ca să fie complet tolerant la greșeli, astfel încât jumătate din umanitate să trăiască acolo, acum mi se pare imposibil, nefiind luat în considerare.
Cu unul la unu fără server: treaba este cool, dar este departe de problemele din 2019. Mai aproape de 2030 - hai să trăim să-l vedem. Nu am nicio îndoială că vom trăi, cu siguranță vom trăi (repetăm înainte de a merge la culcare), dar acum trebuie să rezolvăm alte probleme. E ca și cum ai crede în poneiul de basm Rainbow. Da, câteva procente din cazuri sunt rezolvate și sunt rezolvate perfect, dar subiectiv, serverless este un curcubeu... Pentru mine, acest subiect este prea îndepărtat și prea de neînțeles. Nu sunt pregătit să vorbesc. În 2019, nu puteți scrie o singură aplicație cu serverless.
Cum va evolua Kubernetes
— Pe măsură ce ne îndreptăm către acest viitor îndepărtat potențial minunat, cum credeți că se vor dezvolta Kubernetes și ecosistemul din jurul lui?
Dmitry: M-am gândit mult la asta și am un răspuns clar. Primul este cu stare - la urma urmei, apatrid este mai ușor de făcut. Kubernetes a investit inițial mai mult în asta, totul a început cu asta. Stateless funcționează aproape perfect în Kubernetes, pur și simplu nu există nimic de plâns. Există încă o mulțime de probleme, sau mai degrabă, de nuanțe. Totul acolo funcționează deja grozav pentru noi, dar noi suntem. Va mai dura cel puțin câțiva ani pentru ca acest lucru să funcționeze pentru toată lumea. Acesta nu este un indicator calculat, ci sentimentul meu din capul meu.
Pe scurt, statefull ar trebui - și se va dezvolta - foarte puternic, deoarece toate aplicațiile noastre stochează starea; nu există aplicații fără stat. Aceasta este o iluzie; întotdeauna aveți nevoie de un fel de bază de date și altceva. Statefull înseamnă îndreptarea a tot ceea ce este posibil, remedierea tuturor erorilor, îmbunătățirea tuturor problemelor cu care se confruntă în prezent - să-i numim adoptare.
Nivelul necunoscutului, nivelul problemelor nerezolvate, nivelul probabilității de a întâlni ceva va scădea semnificativ. Aceasta este o poveste importantă. Și operatori - tot ce ține de codificarea logicii de administrare, logica de control pentru a obține un serviciu ușor: MySQL easy service, RabbitMQ easy service, Memcache easy service - în general, toate aceste componente din care trebuie să fim garantați să le rezolvăm cutia. Acest lucru rezolvă doar durerea că vrem o bază de date, dar nu vrem să o administrăm, sau vrem Kubernetes, dar nu vrem să o administrăm.
Această poveste a dezvoltării operatorilor într-o formă sau alta va fi importantă în următorii doi ani.
Cred că ușurința de utilizare ar trebui să crească foarte mult - cutia va deveni din ce în ce mai neagră, din ce în ce mai fiabilă, cu butoane din ce în ce mai simple.
Am ascultat odată un vechi interviu cu Isaac Asimov din anii 80 pe YouTube la Saturday Night Live - un program ca Urgant, doar interesant. L-au întrebat despre viitorul computerelor. El a spus că viitorul este în simplitate, la fel ca radioul. Receptorul radio a fost inițial un lucru complex. Pentru a prinde un val, trebuia să rotiți butoanele timp de 15 minute, să răsuciți frigăruile și, în general, să știți cum funcționează totul, să înțelegeți fizica transmisiei undelor radio. Ca urmare, a rămas doar un buton în radio.
Acum, în 2019, ce radio? În mașină, receptorul radio găsește toate undele și numele posturilor. Fizica procesului nu s-a schimbat în 100 de ani, dar ușurința de utilizare s-a schimbat. Acum, și nu numai acum, deja în 1980, când a fost un interviu cu Azimov, toată lumea folosea radioul și nimeni nu s-a gândit la cum funcționează. Mereu a funcționat - asta e un dat.
Azimov a spus apoi că va fi la fel și cu computerele - ușurința de utilizare va crește. În timp ce în 1980 trebuia să fii instruit să apeși butoanele de pe un computer, nu va fi cazul în viitor.
Am senzația că cu Kubernetes și cu infrastructura va exista și o creștere uriașă a ușurinței de utilizare. Acest lucru, în opinia mea, este evident - se află la suprafață.
Ce să faci cu inginerii?
— Ce se va întâmpla atunci cu inginerii și administratorii de sistem care sprijină Kubernetes?
Dmitry: Ce s-a întâmplat cu contabilul după apariția lui 1C? Cam la fel. Înainte de aceasta, ei contau pe hârtie - acum în program. Productivitatea muncii a crescut cu ordine de mărime, dar munca în sine nu a dispărut. Dacă înainte era nevoie de 10 ingineri pentru a înșuruba un bec, acum unul va fi suficient.
Cantitatea de software și numărul de sarcini, mi se pare, crește acum într-un ritm mai rapid decât apar noile DevOps și eficiența crește. Există o lipsă specifică pe piață chiar acum și va dura mult timp. Mai târziu, totul va reveni la un fel de normalitate, în care eficiența muncii va crește, vor fi din ce în ce mai multe serverless, un neuron va fi atașat la Kubernetes, care va selecta toate resursele exact așa cum este necesar și, în general, va fi face totul de la sine, așa cum ar trebui - persoana se îndepărtează și nu se amestecă.
Dar cineva va trebui totuși să ia decizii. Este clar că nivelul de calificare și specializarea acestei persoane este mai ridicat. În ziua de azi, în departamentul de contabilitate, nu ai nevoie de 10 angajați care să țină evidența ca să nu le obosească mâinile. Pur și simplu nu este necesar. Multe documente sunt scanate și recunoscute automat de sistemul electronic de gestionare a documentelor. Un contabil șef inteligent este suficient, deja cu abilități mult mai mari, cu bună înțelegere.
În general, aceasta este calea de urmat în toate industriile. La fel este și cu mașinile: anterior, o mașină venea cu un mecanic și trei șoferi. În zilele noastre, conducerea unei mașini este un proces simplu la care participăm cu toții în fiecare zi. Nimeni nu crede că o mașină este ceva complicat.
DevOps sau ingineria sistemelor nu vor dispărea - munca la nivel înalt și eficiența vor crește.
— Am auzit și o idee interesantă că munca chiar va crește.
Dmitry: Desigur, sută la sută! Pentru că cantitatea de software pe care o scriem este în continuă creștere. Numărul de probleme pe care le rezolvăm cu software este în continuă creștere. Cantitatea de muncă este în creștere. Acum piața DevOps este teribil de supraîncălzită. Acest lucru se vede în așteptările salariale. Într-un sens bun, fără a intra în detalii, ar trebui să existe juniori care vor X, mijlocii care vor 1,5X și seniori care vor 2X. Și acum, dacă te uiți la piața salarială DevOps din Moscova, un junior vrea de la X la 3X, iar un senior vrea de la X la 3X.
Nimeni nu știe cât costă. Nivelul salariului se măsoară după încrederea ta – un complet casă de nebuni, să fiu sincer, o piață teribil de supraîncălzită.
Desigur, această situație se va schimba foarte curând - ar trebui să apară o anumită saturație. Nu este cazul dezvoltării software - în ciuda faptului că toată lumea are nevoie de dezvoltatori și toată lumea are nevoie de dezvoltatori buni, piața înțelege cine merită ce - industria s-a stabilit. Nu este cazul cu DevOps în zilele noastre.
— Din câte am auzit, am concluzionat că actualul administrator de sistem nu ar trebui să-și facă prea multe griji, dar este timpul să-și îmbunătățească abilitățile și să se pregătească pentru faptul că mâine va fi mai multă muncă, dar va fi mai înalt calificată.
Dmitry: Suta la suta. În general, trăim în 2019 și regula de viață este aceasta: învăţare de-a lungul vieţii - învăţăm de-a lungul vieţii. Mi se pare că acum toată lumea știe deja și simte acest lucru, dar nu este suficient să știi - trebuie să o faci. În fiecare zi trebuie să ne schimbăm. Dacă nu facem asta, atunci mai devreme sau mai târziu vom fi lăsați pe marginea profesiei.
Fii pregătit pentru virajele strânse de 180 de grade. Nu exclud o situație în care ceva se schimbă radical, se inventează ceva nou - se întâmplă. Hop! - și acum acționăm diferit. Este important să fiți pregătiți pentru asta și să nu vă faceți griji. Se poate întâmpla ca mâine tot ceea ce fac să se dovedească a fi inutil - nimic, am studiat toată viața și sunt gata să învăț altceva. Nu este o problemă. Nu trebuie să-ți fie frică de securitatea locului de muncă, dar trebuie să fii pregătit să înveți constant ceva nou.
Dorințe și un minut de reclamă
- Ai vreo dorință?
Dmitry: Da, am mai multe dorințe.
În primul rând și comercial - abonați-vă la . Dragi cititori, accesați YouTube și abonați-vă la canalul nostru. În aproximativ o lună vom începe extinderea activă a serviciului video Vom avea o mulțime de conținut educațional despre Kubernetes, deschis și variat: de la lucruri practice, până la laboratoare, la lucruri teoretice fundamentale profunde și cum să folosim Kubernetes la nivel de principii și modele.
A doua dorință comercială - du-te la și pune stele pentru că ne hrănim cu ele. Daca nu ne dai stele, nu vom avea ce manca. Este ca mana într-un joc pe calculator. Facem ceva, facem, încercăm, cineva spune că acestea sunt biciclete groaznice, cineva că totul este complet greșit, dar continuăm și acționăm absolut sincer. Vedem o problemă, o rezolvăm și împărtășim experiența noastră. De aceea, dă-ne o stea, ea nu va pleca de la tine, ci va veni la noi, pentru că ne hrănim cu ei.
A treia dorință, importantă și nu mai comercială - nu mai crede în basme. Sunteți profesioniști. DevOps este o profesie foarte serioasă și responsabilă. Nu mai jucați la locul de muncă. Lasă-l să dea clic pentru tine și îl vei înțelege. Imaginați-vă că vii la spital și acolo doctorul experimentează pe tine. Înțeleg că acest lucru poate fi jignitor pentru cineva, dar, cel mai probabil, nu este vorba despre tine, ci despre altcineva. Spune-le și altora să se oprească. Acest lucru distruge cu adevărat viața pentru noi toți - mulți încep să trateze operațiunile, administratorii și DevOps ca pe niște tipi care au spart ceva din nou. Acest lucru a fost „rupt” cel mai adesea din cauza faptului că ne-am dus să ne jucăm și nu ne-am uitat cu o conștiință rece că așa este și așa este.
Asta nu înseamnă că nu ar trebui să experimentezi. Trebuie să experimentăm, o facem singuri. Sincer să fiu, noi înșine jucăm uneori jocuri - acest lucru, desigur, este foarte rău, dar nimic uman nu ne este străin. Să declarăm 2019 un an al experimentelor serioase, bine gândite, și nu al jocurilor în producție. Probabil asa.
- Mulțumesc foarte mult!
Dmitry: Mulțumesc, Vitaly, atât pentru timp cât și pentru interviu. Dragi cititori, vă mulțumesc foarte mult dacă ați ajuns brusc în acest punct. Sper că v-am adus măcar câteva gânduri.
În interviu, Dmitry a atins problema werf. Acum acesta este un cuțit elvețian universal care rezolvă aproape toate problemele. Dar nu a fost întotdeauna așa. Pe la festival Dmitri Stolyarov vă va spune despre acest instrument în detaliu. în raport va exista totul: probleme și nuanțe ascunse ale Kubernetes, opțiuni pentru rezolvarea acestor dificultăți și implementarea actuală a werf în detaliu. Alăturați-vă nouă pe 27 și 28 mai, vom crea instrumentele perfecte.
Sursa: www.habr.com