U iščekivanju Vitalij Habarov intervjuisan Dmitry Stolyarov (), tehnički direktor i suosnivač kompanije Flant. Vitalij je pitao Dmitrija o tome šta Flant radi, o Kubernetesu, razvoju ekosistema, podršci. Razgovarali smo zašto je Kubernetes potreban i da li je uopšte potreban. I takođe o mikrouslugama, Amazon AWS-u, pristupu „I'll be lucky“ DevOps-u, budućnosti samog Kubernetesa, zašto, kada i kako će preuzeti svijet, izgledima DevOps-a i na šta bi se inženjeri trebali pripremiti u svijetla i bliska budućnost sa pojednostavljenjem i neuronskim mrežama.
slušajte kao podcast na DevOps Deflop - podcastu na ruskom jeziku o DevOps-u, a ispod je tekstualna verzija.
Ovdje i ispod postavlja pitanja inženjer iz Express42.
O "Flant"
- Zdravo Dima. Ti si tehnički direktor"“, kao i njegov osnivač. Recite nam šta kompanija radi i šta ste u njoj?
Dmitri: Izvana izgleda kao da smo mi tipovi koji instaliraju Kubernetes za svakoga i rade nešto s njim. Ali to nije istina. Počeli smo kao kompanija koja se bavi Linuxom, ali već duže vrijeme naša osnovna djelatnost je servisiranje proizvodnje i visoko opterećenih projekata po principu ključ u ruke. Obično kompletnu infrastrukturu gradimo od nule i onda smo odgovorni za nju dugo, dugo vremena. Dakle, glavni posao koji “Flant” radi, za koji dobija novac, jeste preuzimanje odgovornosti i implementacija proizvodnje po sistemu ključ u ruke.
Ja, kao tehnički direktor i jedan od osnivača kompanije, po cijele dane i noći pokušavam smisliti kako da povećam dostupnost produkcije, pojednostavim njen rad, olakšam život administratorima, a život programera ugodnijim .
O Kubernetesu
— U posljednje vrijeme viđam dosta izvještaja od Flanta i o Kubernetesu. Kako ste došli do toga?
Dmitri: O tome sam već govorio mnogo puta, ali nemam ništa protiv da to ponovim. Mislim da je ispravno ponoviti ovu temu jer postoji zabuna između uzroka i posljedice.
Zaista nam je trebao alat. Suočavali smo se sa puno problema, borili se, savladavali ih raznim štakama i osjećali potrebu za alatom. Prošli smo kroz mnogo različitih opcija, napravili vlastite bicikle i stekli iskustvo. Postepeno smo došli do tačke kada smo počeli da koristimo Docker skoro čim se pojavio - oko 2013. U vrijeme njegovog pojavljivanja već smo imali dosta iskustva s kontejnerima, već smo napisali analogni “Docker” - neke od naših vlastitih štaka u Pythonu. Pojavom Dockera postalo je moguće izbaciti štake i koristiti pouzdano rješenje koje podržava zajednica.
S Kubernetesom je priča slična. U trenutku kada je počeo da dobija na zamahu - za nas je ovo verzija 1.2 - već smo imali gomilu štaka i na Shell-u i na Chefu, što smo nekako pokušali da orkestriramo sa Docker-om. Ozbiljno smo gledali Rancher i razna druga rješenja, ali onda se pojavio Kubernetes u kojem je sve implementirano baš onako kako bismo mi to uradili ili još bolje. Nema se na šta žaliti.
Da, postoji neka vrsta nesavršenosti ovde, ima neka vrsta nesavršenosti - ima puno nesavršenosti, a 1.2 je generalno užasan, ali... Kubernetes je kao zgrada u izgradnji - pogledate projekat i shvatite da će biti cool. Ako zgrada sada ima temelj i dva sprata, onda shvatite da je bolje da se još ne useljavate, ali nema takvih problema sa softverom - već ga možete koristiti.
Nismo imali trenutak kada smo razmišljali o tome da koristimo Kubernetes ili ne. Čekali smo ga mnogo prije nego što se pojavio, i pokušali sami stvoriti analoge.
O Kubernetesu
— Da li ste direktno uključeni u razvoj samog Kubernetesa?
Dmitri: osrednji. Umjesto toga, mi učestvujemo u razvoju ekosistema. Šaljemo određeni broj pull zahtjeva: Prometeju, raznim operaterima, Helmu - ekosistemu. Nažalost, nisam u mogućnosti da pratim sve što radimo i možda griješim, ali nema ni jednog bazena od nas u jezgru.
— Da li u isto vrijeme razvijate mnoge svoje alate oko Kubernetesa?
Dmitri: Strategija je sledeća: idemo i povlačimo zahteve za sve što već postoji. Ako zahtjevi za povlačenje nisu prihvaćeni tamo, jednostavno ih sami račvamo i živimo dok ne budu prihvaćeni s našim buildovima. Zatim, kada dođe do uzvodne, vraćamo se na uzvodnu verziju.
Na primjer, imamo Prometheus operator, s kojim smo se prebacivali naprijed-natrag na uzvodno od našeg sklopa vjerovatno već 5 puta. Potrebna nam je neka vrsta funkcije, poslali smo zahtjev za povlačenjem, moramo je objaviti sutra, ali ne želimo čekati da bude pušten uzvodno. U skladu s tim, sastavljamo za sebe, razvijamo naš sklop s našom funkcijom, koja nam je iz nekog razloga potrebna, na sve naše klastere. Onda nam ga, na primjer, predaju u uzvodnom smjeru uz riječi: „Momci, hajde da uradimo to za opštiji slučaj“, završimo ga mi ili neko drugi i vremenom se ponovo spoji.
Trudimo se da razvijamo sve što postoji. Mnogi elementi koji još ne postoje, još nisu izmišljeni, ili su izmišljeni, ali nisu imali vremena za implementaciju - mi to radimo. I to ne zato što volimo proces ili izgradnju bicikala kao industriju, već jednostavno zato što nam je potreban ovaj alat. Često se postavlja pitanje zašto smo uradili ovo ili ono? Odgovor je jednostavan - da, jer smo morali ići dalje, riješiti neki praktični problem, a riješili smo ga ovom tulom.
Put je uvijek ovakav: vrlo pažljivo tražimo i, ako ne nađemo rješenje kako od vekne hleba napraviti trolejbus, onda pravimo svoju veknu i svoj trolejbus.
Flanta alati
— Znam da Flant sada ima addon operatore, shell operatore i dapp/werf alate. Koliko ja razumijem, ovo je isti instrument u različitim inkarnacijama. Također razumijem da postoji mnogo više različitih alata unutar Flaunt-a. Istina je?
Dmitri: Imamo mnogo više na GitHubu. Koliko se sada sjećam, imamo statusnu mapu - tablu za Grafanu na koju su svi nailazili. Pominje se u skoro svakom drugom članku o Kubernetes praćenju na Medijumu. Nemoguće je ukratko objasniti šta je statusna mapa – za nju je potreban poseban članak, ali je veoma korisna stvar za praćenje statusa tokom vremena, pošto u Kubernetesu često moramo da prikažemo status tokom vremena. Imamo i LogHouse - ovo je stvar bazirana na ClickHouse-u i crnoj magiji za prikupljanje trupaca u Kubernetesu.
Puno uslužnih programa! A biće ih još više, jer će ove godine biti objavljeno niz internih rješenja. Od vrlo velikih baziranih na addon operatoru, postoji gomila dodataka za Kubernetes, ala kako pravilno instalirati sert manager - alat za upravljanje certifikatima, kako pravilno instalirati Prometheus sa gomilom dodataka - ovo je dvadesetak različitih binarne datoteke koje izvoze podatke i prikupljaju nešto, na ovaj Prometheus ima nevjerovatnu grafiku i upozorenja. Sve je ovo samo gomila dodataka za Kubernetes, koji se instaliraju u klaster, a iz jednostavnog se pretvara u cool, sofisticiran, automatski, u kojem su mnogi problemi već riješeni. Da, radimo puno.
Razvoj ekosistema
“Čini mi se da je ovo veoma veliki doprinos razvoju ovog instrumenta i načina njegove upotrebe.” Možete li otprilike procijeniti ko bi još dao isti doprinos razvoju ekosistema?
Dmitri: U Rusiji, od kompanija koje posluju na našem tržištu, niko nije ni blizu. Naravno, ovo je glasna izjava, jer postoje veliki igrači poput Mail-a i Yandexa – i oni rade nešto sa Kubernetesom, ali ni oni se ne približavaju doprinosu kompanija u cijelom svijetu koje rade mnogo više od nas. Teško je porediti Flant, koji ima osoblje od 80 ljudi, i Red Hat, koji ima 300 inženjera samo po Kubernetesu, ako se ne varam. Teško je to uporediti. Imamo 6 ljudi u RnD odjelu, uključujući i mene, koji seku sav naš alat. 6 ljudi naspram 300 Red Hat inženjera - to je nekako teško uporediti.
- Međutim, kada i ovih 6 ljudi mogu učiniti nešto zaista korisno i otuđujuće, kada se suoče sa praktičnim problemom i daju rješenje zajednici - zanimljiv slučaj. Razumijem da se u velikim tehnološkim kompanijama, gdje imaju vlastiti tim za razvoj i podršku Kubernetesa, u principu mogu razviti isti alati. Ovo je za njih primjer šta se može razviti i dati zajednici, dajući poticaj cijeloj zajednici koja koristi Kubernetes.
Dmitri: Ovo je vjerovatno karakteristika integratora, njegova posebnost. Imamo mnogo projekata i vidimo mnogo različitih situacija. Za nas je glavni način stvaranja dodatne vrijednosti da analiziramo ove slučajeve, pronađemo zajedničko i učinimo ih što jeftinijim za nas. Aktivno radimo na tome. Teško mi je govoriti o Rusiji i svijetu, ali u kompaniji imamo oko 40 DevOps inženjera koji rade na Kubernetesu. Mislim da u Rusiji nema mnogo kompanija sa uporedivim brojem stručnjaka koji razumeju Kubernetes, ako ih uopšte ima.
Razumijem sve o nazivu posla DevOps inženjer, svi sve razumiju i navikli su da DevOps inženjere nazivaju DevOps inženjerima, o tome nećemo raspravljati. Svih ovih 40 neverovatnih DevOps inženjera svakodnevno se suočavaju i rešavaju probleme, mi samo analiziramo ovo iskustvo i pokušavamo da generalizujemo. Razumijemo da ako ostane u nama, onda će za godinu ili dvije alat biti beskorisan, jer će se negdje u zajednici pojaviti gotova Tula. Nema smisla interno akumulirati ovo iskustvo - to jednostavno odvodi energiju i vrijeme u dev/null. I uopšte nam nije žao zbog toga. Sve objavljujemo sa velikim zadovoljstvom i razumijemo da to treba objavljivati, razvijati, promovirati, promovirati, da ljudi to koriste i dodaju svoje iskustvo - onda sve raste i živi. Zatim nakon dvije godine instrument ne ide u smeće. Nije šteta nastaviti ulijevati snagu, jer je jasno da neko koristi tvoj alat, a nakon dvije godine svi ga koriste.
Ovo je dio naše velike strategije s dapp/werf. Ne sećam se kada smo počeli da ga pravimo, čini mi se pre 3 godine. U početku je uglavnom bio na ljusci. Bio je to super dokaz koncepta, riješili smo neke od naših konkretnih problema - uspjelo je! Ali postoje problemi sa ljuskom, nemoguće ju je dalje proširiti, programiranje na ljusci je drugi zadatak. Imali smo naviku da pišemo u Ruby-u, shodno tome, prepravljali smo nešto u Ruby-u, razvijali, razvijali, razvijali i naleteli na to da je zajednica, gomila koja ne kaže „hoćemo to ili nećemo, ” okreće nos prema Ruby, koliko je to smiješno? Shvatili smo da bismo sve ove stvari trebali napisati u Go samo da bismo ispunili prvu tačku na kontrolnoj listi: DevOps alat bi trebao biti statički binarni. Biti Go ili ne nije toliko važno, ali statička binarna datoteka napisana u Go je bolja.
Potrošili smo svoju energiju, prepisali dapp u Go i nazvali ga werf. Dapp više nije podržan, nije razvijen, radi u nekoj najnovijoj verziji, ali postoji apsolutni put nadogradnje do vrha i možete ga pratiti.
Zašto je dapp kreiran?
— Možete li nam ukratko reći zašto je dapp kreiran, koje probleme rješava?
Dmitri: Prvi razlog je u montaži. U početku smo imali ozbiljnih problema sa build-om kada Docker nije imao višestepene mogućnosti, pa smo sami napravili multi-stage. Tada smo imali još hrpu problema sa čišćenjem slike. Svi koji rade CI/CD, prije nego kasnije se susreću s problemom da ima gomila sakupljenih slika, treba nekako očistiti ono što nije potrebno i ostaviti ono što treba.
Drugi razlog je raspoređivanje. Da, postoji Helm, ali on rješava samo neke probleme. Zabavno, piše da je “Helm menadžer paketa za Kubernetes”. Tačno ono "ono". Tu su i riječi “Upravitelj paketima” – šta se uobičajeno očekuje od menadžera paketa? Kažemo: "Upravitelj paketima - instalirajte paket!" i očekujemo da nam kaže: “Paket je isporučen.”
Zanimljivo je da mi kažemo: "Helm, instaliraj paket", a kada on odgovori da ga je instalirao, ispostavilo se da je upravo započeo instalaciju - naznačio je Kubernetes: "Pokreni ovu stvar!", i da li je počela ili ne , bilo da radi ili ne, Helm uopće ne rješava ovaj problem.
Ispostavilo se da je Helm samo tekstualni pretprocesor koji učitava podatke u Kubernetes.
Ali kao dio svake implementacije, želimo znati da li je aplikacija puštena za proizvodnju ili ne? Uvedeno u prod znači da se aplikacija preselila tamo, da je nova verzija implementirana i da se barem tamo ne ruši i da odgovara ispravno. Helm ni na koji način ne rješava ovaj problem. Da biste to riješili, morate uložiti mnogo truda, jer morate dati naredbu Kubernetesu da se pokrene i nadgleda šta se tamo dešava - da li je raspoređen ili uveden. A tu je i puno zadataka vezanih za postavljanje, čišćenje i montažu.
Planovi
Ove godine počinjemo lokalni razvoj. Želimo postići ono što je ranije bilo u Vagrantu - otkucali smo “vagrant up” i postavili virtuelne mašine. Želimo da dođemo do tačke u kojoj postoji projekat u Gitu, tamo napišemo „werf“ i pojaviće se lokalna kopija ovog projekta, postavljena u lokalni mini-Kub, sa povezanim svim direktorijumima pogodnim za razvoj . U zavisnosti od razvojnog jezika, to se radi drugačije, ali ipak, tako da se lokalni razvoj može lako izvesti pod montiranim datotekama.
Sledeći korak za nas je investirajte u udobnost za programere. Da biste brzo implementirali projekt lokalno s jednim alatom, razvijte ga, gurnite ga u Git, a on će se također pokrenuti na pozornicu ili testove, ovisno o cjevovodima, a zatim koristiti isti alat za prelazak u proizvodnju. Ovo jedinstvo, objedinjavanje, ponovljivost infrastrukture od lokalnog okruženja do prodaje je za nas veoma važna tačka. Ali ovo još nije u redu - tek planiramo to učiniti.
Ali put do dapp/werf-a je uvijek bio isti kao kod Kubernetesa na početku. Nailazili smo na probleme, rješavali ih zaobilaznim rješenjima - sami smo smislili neka rješenja na ljusci, na bilo čemu. Zatim su pokušali nekako ispraviti ova rješenja, generalizirati ih i konsolidirati u binarne datoteke u ovom slučaju, koje jednostavno dijelimo.
Postoji još jedan način da se sagleda čitava ova priča, uz analogije.
Kubernetes je okvir automobila sa motorom. Nema vrata, stakla, radija, jelke - baš ništa. Samo okvir i motor. A tu je i Helm - ovo je volan. Cool - postoji volan, ali vam je potreban i pin, letva volana, mjenjač i kotači, a ne možete bez njih.
U slučaju werf-a, ovo je još jedna komponenta Kubernetesa. Tek sada u alfa verziji werfa, na primjer, Helm je kompajliran unutar werfa, jer smo umorni od toga da to sami radimo. Postoji mnogo razloga da to učinite, reći ću vam detaljno zašto smo sastavili cijelo kormilo zajedno sa kormilom unutar werfa .
Sada je werf integrisanija komponenta. Dobijamo gotov volan, iglu upravljača - nisam baš dobar u automobilima, ali ovo je veliki blok koji već rješava prilično širok spektar problema. Ne moramo sami da prolazimo kroz katalog, biramo jedan deo za drugi, razmišljamo kako da ih spojimo. Dobijamo gotov kombajn koji rješava veliki broj problema odjednom. Ali unutra je izgrađen od istih komponenti otvorenog koda, još uvijek koristi Docker za sklapanje, Helm za neke od funkcionalnosti, a postoji i nekoliko drugih biblioteka. Ovo je integrirani alat za brzo i praktično vađenje hladnog CI/CD-a iz kutije.
Da li je Kubernetes teško održavati?
— Govorite o iskustvu da ste počeli da koristite Kubernetes, ovo je okvir za vas, motor, i da na njega možete okačiti mnogo različitih stvari: karoseriju, volan, šrafove pedale, sedišta. Postavlja se pitanje - koliko vam je teška podrška za Kubernetes? Imate puno iskustva, koliko vremena i resursa trošite na podršku Kubernetesu izolovano od svega ostalog?
Dmitri: Ovo je veoma teško pitanje i za odgovor treba da razumemo šta je podrška i šta želimo od Kubernetesa. Možda možete otkriti?
— Koliko ja znam i koliko vidim, sada mnogi timovi žele isprobati Kubernetes. Svako se upregne u to, stavi na koljena. Imam osjećaj da ljudi ne razumiju uvijek kompleksnost ovog sistema.
Dmitri: Tako je.
— Koliko je teško uzeti i instalirati Kubernetes od nule da bude spreman za proizvodnju?
Dmitri: Šta mislite koliko je teško presaditi srce? Razumijem da je ovo kompromitujuće pitanje. Nije tako teško koristiti skalpel i ne pogriješiti. Ako vam kažu gdje da krojite, a gdje da šijete, onda sama procedura nije komplikovana. Teško je s vremena na vrijeme garantirati da će sve uspjeti.
Instaliranje Kubernetesa i njegovo pokretanje je jednostavno: curo! — instaliran, postoji mnogo metoda instalacije. Ali šta se dešava kada se pojave problemi?
Uvijek se postavljaju pitanja – šta još nismo uzeli u obzir? Šta još nismo uradili? Koji parametri Linux kernela su pogrešno navedeni? Gospode, jesmo li ih uopšte spomenuli?! Koje smo Kubernetes komponente isporučili, a koje nismo? Pojavljuje se na hiljade pitanja, a da biste na njih odgovorili, morate provesti 15-20 godina u ovoj industriji.
Imam nedavni primjer na ovu temu koji može otkriti značenje problema „Da li je Kubernetes teško održavati?“ Prije nekog vremena smo ozbiljno razmišljali da li da pokušamo implementirati Cilium kao mrežu u Kubernetes.
Dozvolite mi da objasnim šta je Cilium. Kubernetes ima mnogo različitih implementacija mrežnog podsistema, a jedna od njih je vrlo cool - Cilium. Šta je njegovo značenje? U kernelu je prije nekog vremena postalo moguće pisati kuke za kernel, koje na ovaj ili onaj način prodiru u mrežni podsistem i razne druge podsisteme, i omogućavaju vam da zaobiđete velike komade u kernelu.
Linux kernel istorijski ima ip rut, overfilter, mostove i mnogo različitih starih komponenti koje su stare 15, 20, 30 godina. Uglavnom, rade, sve je super, ali sad su nagomilali kontejnere, i izgleda kao kula od 15 cigli jedna na drugoj, a stojiš na njoj na jednoj nozi - čudan osjećaj. Ovaj sistem se istorijski razvijao sa mnogo nijansi, kao što je slijepo crijevo u tijelu. U nekim situacijama, na primjer, postoje problemi s performansama.
Postoji prekrasan BPF i mogućnost pisanja zakačivaca za kernel - momci su napisali svoje vlastite kuke za kernel. Paket dolazi u Linux kernel, izvade ga odmah na ulazu, sami ga obrađuju kako treba bez mostova, bez TCP-a, bez IP steka - ukratko, zaobilazeći sve što je napisano u Linux kernelu, pa pljunu to van u kontejner.
Šta se desilo? Vrlo cool performanse, cool karakteristike - jednostavno cool! Ali pogledamo ovo i vidimo da na svakoj mašini postoji program koji se povezuje na Kubernetes API i, na osnovu podataka koje prima od ovog API-ja, generiše C kod i kompajlira binarne datoteke koje učitava u kernel tako da ove zakačice rade u prostoru kernela.
Šta se dešava ako nešto krene po zlu? Ne znamo. Da biste ovo razumjeli, morate pročitati sav ovaj kod, razumjeti svu logiku i nevjerovatno je koliko je to teško. Ali, sa druge strane, tu su ovi mostovi, net filteri, ip rut - nisam pročitao njihov izvorni kod, a nema ni 40 inženjera koji rade u našoj kompaniji. Možda samo nekolicina razume neke delove.
I koja je razlika? Ispostavilo se da postoji ip rut, Linux kernel, a postoji i novi alat - kakva je razlika, ne razumijemo ni jedno ni drugo. Ali bojimo se koristiti nešto novo – zašto? Jer ako je alat star 30 godina, onda su za 30 godina pronađene sve greške, sve greške su nagazile i ne morate znati sve - radi kao crna kutija i uvijek radi. Svi znaju koji dijagnostički odvijač zalijepiti na koje mjesto, koji tcpdump pokrenuti u kojem trenutku. Svi dobro poznaju dijagnostičke uslužne programe i razumiju kako ovaj skup komponenti funkcionira u Linux kernelu - ne kako funkcionira, već kako ga koristiti.
A strašno cool Cilium nema 30 godina, nije još ostario. Kubernetes ima isti problem, kopija. Da je Cilium savršeno instaliran, da je Kubernetes savršeno instaliran, ali kada nešto krene po zlu u proizvodnji, da li ste u stanju brzo shvatiti u kritičnoj situaciji šta je pošlo po zlu?
Kada kažemo da li je teško održavati Kubernetes – ne, veoma je lako, i da, neverovatno je teško. Kubernetes radi odlično sam po sebi, ali sa milijardu nijansi.
O pristupu „imaću sreću“.
— Postoje li kompanije u kojima se ove nijanse gotovo sigurno pojavljuju? Pretpostavimo da Yandex odjednom prenese sve usluge na Kubernetes, tamo će biti ogromno opterećenje.
Dmitri: Ne, ovo nije razgovor o opterećenju, već o najjednostavnijim stvarima. Na primjer, imamo Kubernetes, tamo smo postavili aplikaciju. Kako znaš da radi? Jednostavno ne postoji gotov alat koji bi razumio da se aplikacija ne ruši. Ne postoji gotov sistem koji šalje upozorenja; potrebno je da konfigurišete ova upozorenja i svaki raspored. A mi ažuriramo Kubernetes.
Imam Ubuntu 16.04. Možete reći da je ovo stara verzija, ali mi smo još uvijek na njoj jer je LTS. Postoji systemd, čija je nijansa da ne čisti C-grupe. Kubernetes pokreće podove, kreira C-grupe, zatim briše podove i nekako se ispostavilo - ne sjećam se detalja, izvini - da su sistemski dijelovi ostali. To dovodi do činjenice da s vremenom svaki automobil počinje snažno usporavati. Ovo čak nije ni pitanje o visokom opterećenju. Ako se pokrenu trajni podovi, na primjer, ako postoji Cron Job koji konstantno generiše podove, onda će mašina sa Ubuntu 16.04 početi da usporava nakon nedelju dana. Postojat će konstantno visok prosjek opterećenja zbog činjenice da je stvorena gomila C-grupa. Ovo je problem sa kojim će se suočiti svaka osoba koja jednostavno instalira Ubuntu 16 i Kubernetes na vrhu.
Recimo da nekako ažurira systemd ili nešto drugo, ali u Linux kernelu do 4.16 je još smiješnije - kada izbrišete C-grupe, one procure u kernelu i zapravo se ne brišu. Stoga će nakon mjesec dana rada na ovoj mašini biti nemoguće pogledati statistiku memorije za ognjišta. Izvadimo fajl, umotamo ga u program i jedan fajl se kotrlja 15 sekundi, jer kernelu treba jako dugo da prebroji milion C-grupa u sebi, koje izgledaju kao da su obrisane, ali ne - cure .
Takvih sitnica tu i tamo ima još dosta. Ovo nije problem sa kojim se gigantske kompanije ponekad mogu suočiti pod veoma velikim opterećenjima – ne, to je stvar svakodnevnih stvari. Ljudi mogu živjeti ovako mjesecima - instalirali su Kubernetes, postavili aplikaciju - izgleda da radi. Za mnoge ljude to je normalno. Neće ni znati da će se ova aplikacija iz nekog razloga srušiti, neće dobiti upozorenje, ali za njih je to norma. Ranije smo živeli na virtuelnim mašinama bez nadzora, sada smo prešli na Kubernetes, takođe bez nadgledanja - u čemu je razlika?
Pitanje je da kada hodamo po ledu, nikada ne znamo njegovu debljinu osim ako je ne izmjerimo unaprijed. Mnogi ljudi hodaju i ne brinu, jer su hodali i prije.
Sa moje tačke gledišta, nijansa i složenost rada bilo kojeg sistema je u tome da se osigura da je debljina leda upravo dovoljna da riješi naše probleme. To je ono o čemu pričamo.
U IT-u, čini mi se, ima previše pristupa „imaću sreću“. Mnogi ljudi instaliraju softver i koriste softverske biblioteke u nadi da će im se posrećiti. Generalno, mnogi ljudi imaju sreće. Vjerovatno zato i funkcionira.
— Prema mojoj pesimističkoj procjeni, to izgleda ovako: kada su rizici visoki, a aplikacija mora funkcionirati, tada je potrebna podrška Flaunt-a, možda Red Hata, ili vam je potreban vlastiti interni tim posvećen Kubernetesu, koji je spreman da to izvedem.
Dmitri: Objektivno, to je tako. Ulazak u priču o Kubernetesu za mali tim uključuje brojne rizike.
Trebaju li nam kontejneri?
— Možete li nam reći koliko je Kubernetes rasprostranjen u Rusiji?
Dmitri: Nemam te podatke i nisam siguran da ih neko drugi ima. Mi kažemo: „Kubernetes, Kubernetes“, ali postoji drugi način da se ovo pitanje posmatra. Također ne znam koliko su kontejneri rasprostranjeni, ali znam brojku iz izvještaja na internetu da 70% kontejnera orkestrira Kubernetes. Bio je to pouzdan izvor za prilično veliki uzorak širom svijeta.
Onda još jedno pitanje - da li su nam potrebni kontejneri? Moj lični osjećaj i ukupna pozicija kompanije Flant je da je Kubernetes de facto standard.
Neće biti ništa osim Kubernetesa.
Ovo je apsolutna promjena u polju upravljanja infrastrukturom. Samo apsolutno - to je to, nema više Ansiblea, Chefa, virtuelnih mašina, Terraforma. Ne govorim o starim metodama kolektivne farme. Kubernetes je apsolutni menjač, a sada će biti samo ovako.
Jasno je da je nekima potrebno nekoliko godina, a drugima par decenija da to shvate. Ne sumnjam da neće biti ništa osim Kubernetesa i ovog novog izgleda: više ne oštećujemo operativni sistem, već koristimo infrastruktura kao kod, samo ne sa kodom, već sa yml - deklarativno opisanom infrastrukturom. Imam osjećaj da će uvijek tako biti.
— Odnosno, one kompanije koje još nisu prešle na Kubernetes će sigurno preći na njega ili će ostati u zaboravu. Dobro sam te razumeo?
Dmitri: Ovo takođe nije sasvim tačno. Na primjer, ako imamo zadatak da pokrenemo DNS server, onda se on može pokrenuti na FreeBSD 4.10 i može savršeno raditi 20 godina. Samo radi i to je to. Možda će za 20 godina nešto jednom morati da se ažurira. Ako govorimo o softveru u formatu koji smo lansirali i on zapravo radi dugi niz godina bez ikakvih ažuriranja, bez izmjena, onda, naravno, neće biti Kubernetesa. On tamo nije potreban.
Sve što se odnosi na CI/CD - gdje god je potrebna kontinuirana isporuka, gdje trebate ažurirati verzije, vršiti aktivne promjene, gdje god trebate izgraditi toleranciju grešaka - samo Kubernetes.
O mikroservisima
- Ovdje imam malu neskladu. Za rad sa Kubernetesom potrebna vam je eksterna ili interna podrška - ovo je prva stvar. Drugo, kada tek počinjemo razvoj, mi smo mali startup, nemamo još ništa, razvoj za Kubernetes ili mikroservisnu arhitekturu općenito može biti složen i nije uvijek ekonomski opravdan. Zanima me vaše mišljenje - da li startupi moraju odmah da počnu pisati za Kubernetes od nule, ili mogu i dalje da napišu monolit, pa tek onda dođu u Kubernetes?
Dmitri: Kul pitanje. Govorim o mikrouslugama Mnogo puta sam sreo ljude koji pokušavaju da zakucaju eksere mikroskopom. Sam pristup je ispravan, mi sami dizajniramo svoj interni softver na ovaj način. Ali kada to radite, morate jasno razumjeti šta radite. Riječ koju najviše mrzim kod mikrousluga je "mikro". Istorijski, ova riječ je nastala tamo, i iz nekog razloga ljudi misle da je mikro vrlo mali, manji od milimetra, kao mikrometar. Ovo je pogrešno.
Na primjer, postoji monolit koji piše 300 ljudi, a svi koji su učestvovali u razvoju razumiju da tu postoje problemi i treba ga razbiti na mikro-dijelove - oko 10 komada, od kojih svaki piše 30 ljudi. u minimalnoj verziji. Ovo je važno, neophodno i cool. Ali kada nam dođe startap, gdje su 3 vrlo kul i talentovana momka napisala 60 mikroservisa na koljenima, svaki put kada tražim Corvalol.
Čini mi se da se o tome već govorilo hiljade puta – dobili smo distribuirani monolit u ovom ili onom obliku. To nije ekonomski opravdano, vrlo je teško generalno u svemu. Upravo sam ovo vidio toliko puta da me stvarno boli, pa nastavljam da pričam o tome.
Na početno pitanje postoji sukob između činjenice da je, s jedne strane, Kubernetes zastrašujuće koristiti, jer nije jasno šta se tu može pokvariti ili ne radi, s druge strane, jasno je da sve ide tamo i ništa osim Kubernetesa neće postojati. Odgovor - odmjerite količinu koristi koja dolazi, količinu zadataka koje možete riješiti. Ovo je na jednoj strani vage. S druge strane, postoje rizici povezani sa prekidom rada ili smanjenjem vremena odziva, nivoa dostupnosti - sa smanjenjem pokazatelja učinka.
Evo ga - ili se krećemo brzo, a Kubernetes nam omogućava da mnoge stvari radimo mnogo brže i bolje, ili koristimo pouzdana, vremenski testirana rješenja, ali se krećemo mnogo sporije. Ovo je izbor koji svaka kompanija mora napraviti. O tome možete razmišljati kao o stazi u džungli - kada prvi put hodate, možete sresti zmiju, tigra ili ludog jazavca, a kada ste hodali 10 puta, pregazili ste stazu, uklonjeni grane i hodanje lakše. Svaki put staza postaje šira. Zatim je to asfaltni put, a kasnije prelijepi bulevar.
Kubernetes ne stoji mirno. Ponovo pitanje: Kubernetes je, s jedne strane, 4-5 binarnih datoteka, s druge strane, to je cijeli ekosistem. Ovo je operativni sistem koji imamo na našim mašinama. Šta je ovo? Ubuntu ili Curios? Ovo je Linux kernel, gomila dodatnih komponenti. Sve te stvari ovdje, jedna zmija otrovnica je izbačena sa puta, tu je podignuta ograda. Kubernetes se razvija vrlo brzo i dinamično, a obim rizika, obim nepoznatog se svakog mjeseca smanjuje i, shodno tome, ove vage se ponovo balansiraju.
Odgovarajući na pitanje šta startup treba da radi, rekao bih - dođite u Flaunt, platite 150 hiljada rubalja i dobijte DevOps laku uslugu po principu „ključ u ruke“. Ako ste mali startup s nekoliko programera, ovo funkcionira. Umjesto da angažujete vlastite DevOps-e, koji će morati naučiti kako riješiti vaše probleme i isplatiti platu u ovom trenutku, dobićete rješenje po sistemu ključ u ruke za sve probleme. Da, postoje neki nedostaci. Mi, kao autsorser, ne možemo biti toliko uključeni i brzo reagirati na promjene. Ali imamo puno stručnosti i gotovih praksi. Garantujemo da ćemo u svakoj situaciji sigurno brzo shvatiti i podići bilo koji Kubernetes iz mrtvih.
Toplo preporučujem outsourcing startupima i osnovanim preduzećima do veličine u kojoj možete posvetiti tim od 10 ljudi za operacije, jer inače nema smisla. Definitivno ima smisla povjeriti ovo.
O Amazonu i Googleu
— Može li se host iz rješenja iz Amazona ili Google-a smatrati outsource?
Dmitri: Da, naravno, ovo rješava niz problema. Ali opet postoje nijanse. Još uvijek morate razumjeti kako ga koristiti. Na primjer, postoji hiljadu sitnica u radu Amazon AWS-a: potrebno je zagrijati Load Balancer ili unaprijed napisati zahtjev „momci, primićemo promet, zagrijte Load Balancer za nas!“ Morate znati ove nijanse.
Kada se obratite ljudima koji su specijalizovani za ovo, gotovo sve tipične stvari se zatvaraju. Sada imamo 40 inženjera, do kraja godine će ih vjerovatno biti 60 - sa svim tim stvarima smo se sigurno susreli. Čak i ako na nekom projektu ponovo naiđemo na ovaj problem, brzo se pitamo i znamo kako ga riješiti.
Vjerovatno je odgovor - naravno, hostirana priča olakšava neki dio. Pitanje je jeste li spremni vjerovati ovim hosterima i hoće li oni riješiti vaše probleme. Amazon i Google su dobro prošli. Za sve naše slučajeve - tačno. Nemamo više pozitivnih iskustava. Svi ostali oblaci sa kojima smo pokušali da radimo stvaraju mnogo problema - Ager, i sve što postoji u Rusiji, i sve vrste OpenStack-a u različitim implementacijama: Headster, Overage - šta god želite. Svi oni stvaraju probleme koje ne želite riješiti.
Stoga je odgovor potvrdan, ali, u stvari, nema mnogo zrelih hostiranih rješenja.
Kome treba Kubernetes?
— Pa ipak, kome treba Kubernetes? Ko bi već trebao preći na Kubernetes, ko je tipičan Flaunt klijent koji dolazi posebno za Kubernetes?
Dmitri: Ovo je zanimljivo pitanje, jer upravo sada, nakon Kubernetesa, mnogi ljudi nam dolaze: „Momci, znamo da radite Kubernetes, uradite to za nas!“ Odgovaramo im: "Gospodo, mi ne radimo Kubernetes, mi radimo prod i sve što je s tim povezano." Jer trenutno je jednostavno nemoguće napraviti proizvod a da se ne uradi sav CI/CD i cijela ova priča. Svi su se odmakli od podjele da imamo razvoj po razvoj, pa eksploataciju po eksploataciju.
Naši klijenti očekuju različite stvari, ali svi čekaju neko dobro čudo da imaju određenih problema, a sada - hop! — Kubernetes će ih riješiti. Ljudi vjeruju u čuda. U mislima shvataju da neće biti čuda, ali u duši se nadaju - šta ako će nam ovaj Kubernetes sada sve rešiti, toliko pričaju o tome! Odjednom je sada - kijao! - i srebrni metak, kihni! — i imamo 100% produženje rada, svi programeri mogu pustiti sve što uđe u proizvodnju 50 puta, i ne ruši. Općenito, čudo!
Kada nam takvi dođu, mi kažemo: „Izvinite, ali ne postoji čudo“. Da biste bili zdravi, morate se dobro hraniti i vježbati. Da biste imali pouzdan proizvod, potrebno ga je napraviti pouzdano. Da biste imali zgodan CI/CD, morate ga napraviti ovako. To je mnogo posla koji treba da se uradi.
Odgovarajući na pitanje kome treba Kubernetes - nikome ne treba Kubernetes.
Neki ljudi imaju zabludu da im je potreban Kubernetes. Ljudima je potrebna, imaju duboku potrebu da prestanu razmišljati, proučavati i zanimati se za sve probleme infrastrukture i probleme pokretanja svojih aplikacija. Oni žele da aplikacije samo rade i samo se postavljaju. Za njih je Kubernetes nada da će prestati da slušaju priču da smo „ležali tamo“, ili „ne možemo da se izvučemo“, ili nešto drugo.
Tehnički direktor obično dolazi kod nas. Pitaju ga dvije stvari: s jedne strane, dati nam karakteristike, s druge strane, stabilnost. Predlažemo da to preuzmete na sebe i uradite. Srebrni metak, odnosno posrebreni, je da ćete prestati razmišljati o ovim problemima i gubiti vrijeme. Imat ćete posebne ljude koji će zatvoriti ovo pitanje.
Formulacija da nama ili bilo kome drugom treba Kubernetes je netačna.
Adminima je zaista potreban Kubernetes, jer je to vrlo zanimljiva igračka sa kojom se možete igrati i poigravati. Budimo iskreni - svi vole igračke. Svi smo negdje djeca, a kad vidimo novu, poželimo da je igramo. Nekima je to obeshrabreno, na primjer, u administraciji, jer su već dovoljno igrali i već su umorni do te mjere da jednostavno ne žele. Ali to nikome nije potpuno izgubljeno. Na primjer, ako sam već dugo umoran od igračaka iz oblasti sistemske administracije i DevOps-a, onda još uvijek volim igračke, još uvijek kupujem neke nove. Svi ljudi, na ovaj ili onaj način, i dalje žele neku vrstu igračaka.
Nema potrebe da se igrate sa produkcijom. Šta god kategorički preporučujem da ne radite i što sada masovno vidim: „Oh, nova igračka!“ — otrčali su da ga kupe, kupili i: „Hajde da ga sada odnesemo u školu i pokažimo ga svim prijateljima.“ Ne radi to. Izvinjavam se, moja djeca tek odrastaju, stalno nešto vidim kod djece, primjećujem to kod sebe, pa onda generaliziram na druge.
Konačni odgovor je: ne treba vam Kubernetes. Morate riješiti svoje probleme.
Ono što možete postići je:
- prod ne pada;
- čak i ako pokuša da padne, znamo za to unapred i možemo nešto da stavimo u to;
- možemo ga promijeniti brzinom kojom naše poslovanje to zahtijeva, i možemo to učiniti povoljno; ne stvara nam nikakve probleme.
Postoje dvije stvarne potrebe: pouzdanost i dinamičnost/fleksibilnost uvođenja. Svako ko se trenutno bavi nekim IT projektima, bez obzira na to u kakvom poslu - mekom za olakšanje svijeta, i koji se u to razumije, treba da riješi te potrebe. Kubernetes sa pravim pristupom, sa pravim razumevanjem i sa dovoljno iskustva vam omogućava da ih rešite.
O bez servera
— Ako pogledate malo dalje u budućnost, onda pokušavajući da infrastrukturom rešite problem odsustva glavobolje, uz brzinu uvođenja i brzinu promene aplikacija, pojavljuju se nova rešenja, na primer, bez servera. Osjećate li potencijal u tom pravcu i, recimo, opasnost za Kubernetes i slična rješenja?
Dmitri: Evo opet treba da napomenemo da ja nisam vidovnjak koji gleda napred i kaže – ovako će biti! Iako sam upravo uradio istu stvar. Gledam u svoja stopala i vidim tu gomilu problema, na primjer, kako tranzistori rade u kompjuteru. Smiješno je, zar ne? Nailazimo na neke greške u CPU-u.
Učinite bez servera prilično pouzdanim, jeftinim, efikasnim i praktičnim, rješavajući sve probleme ekosistema. Ovdje se slažem sa Elonom Muskom da je potrebna druga planeta da bi se stvorila tolerancija na greške za čovječanstvo. Iako ne znam šta govori, razumem da nisam spreman da lično letim na Mars i da se to neće desiti sutra.
Sa serverless-om je jasno da je to ideološki ispravna stvar, kao što je tolerancija grešaka za čovječanstvo - imati dvije planete je bolje nego jednu. Ali kako to sada učiniti? Slanje jedne ekspedicije nije problem ako se na nju koncentrišete. Ja mislim da je i poslati nekoliko ekspedicija i smjestiti nekoliko hiljada ljudi tamo. Ali učiniti ga potpuno tolerantnim na greške tako da tamo živi pola čovječanstva, čini mi se sada nemoguće, ne uzimajući u obzir.
Sa jedan na jedan bez servera: stvar je kul, ali je daleko od problema 2019. Bliže 2030. - doživimo da to vidimo. Ne sumnjam da ćemo živeti, sigurno ćemo živeti (ponoviti pred spavanje), ali sada treba da rešavamo druge probleme. To je kao vjerovati u ponija iz bajke Rainbow. Da, par posto slučajeva je riješeno, i to savršeno, ali subjektivno, bez servera je duga... Za mene je ova tema predaleka i previše nerazumljiva. Nisam spreman za razgovor. U 2019. ne možete napisati nijednu aplikaciju bez servera.
Kako će se Kubernetes razvijati
— Kako se krećemo ka ovoj potencijalno divnoj dalekoj budućnosti, kako mislite da će se razvijati Kubernetes i ekosistem oko njega?
Dmitri: Mnogo sam razmišljao o ovome i imam jasan odgovor. Prvo je stanje bez državljanstva - na kraju krajeva, lakše je napraviti apatrid. Kubernetes je u početku više ulagao u ovo, s tim je sve počelo. Stateless radi skoro savršeno u Kubernetesu, jednostavno se nema na šta zamjeriti. Još uvijek ima puno problema, tačnije, nijansi. Tamo nam već sve radi odlično, ali to smo mi. Trebat će još barem nekoliko godina da ovo funkcionira za sve. Ovo nije proračunat pokazatelj, već moj osjećaj iz moje glave.
Ukratko, statefull bi se trebao - i hoće - razvijati vrlo snažno, jer sve naše aplikacije pohranjuju status; nema aplikacija bez državljanstva. Ovo je iluzija; uvijek vam treba neka baza podataka i nešto drugo. Statefull se odnosi na ispravljanje svega što je moguće, ispravljanje svih grešaka, poboljšanje svih problema sa kojima se trenutno suočavaju – nazovimo to usvajanjem.
Nivo nepoznatog, nivo nerešenih problema, nivo verovatnoće da ćete naići na nešto značajno će pasti. Ovo je važna priča. I operateri - sve što se odnosi na kodifikaciju administrativne logike, kontrolnu logiku da bismo dobili laku uslugu: MySQL laka usluga, RabbitMQ laka usluga, Memcache laka usluga - generalno, sve ove komponente za koje moramo garantovano raditi kutije. Ovo samo rješava bol da želimo bazu podataka, ali ne želimo njome administrirati, ili želimo Kubernetes, ali ne želimo njome administrirati.
Ova priča o razvoju operatera u ovom ili onom obliku bit će važna u narednih nekoliko godina.
Mislim da bi se jednostavnost korištenja trebala znatno povećati - kutija će postajati sve crnija, sve pouzdanija, sa sve jednostavnijim dugmadima.
Jednom sam slušao stari intervju sa Isaacom Asimovim iz 80-ih na YouTube-u u Saturday Night Live - program poput Urganta, samo zanimljiv. Pitali su ga o budućnosti kompjutera. Rekao je da je budućnost u jednostavnosti, baš kao i radio. Radio prijemnik je prvobitno bio složena stvar. Da biste uhvatili talas, morali ste 15 minuta okretati dugmad, okretati ražnjiće i općenito znati kako sve funkcionira, razumjeti fiziku prijenosa radio valova. Kao rezultat toga, u radiju je ostalo samo jedno dugme.
Sada u 2019. koji radio? U automobilu, radio prijemnik pronalazi sve talase i nazive stanica. Fizika procesa se nije promijenila u 100 godina, ali se jednostavnost korištenja promijenila. Sada, i ne samo sada, već 1980. godine, kada je bio intervju sa Azimovim, svi su koristili radio i niko nije razmišljao o tome kako on funkcioniše. Uvek je funkcionisalo - to je dato.
Azimov je tada rekao da će tako biti i sa kompjuterima - jednostavnost upotrebe će se povećati. Dok ste 1980. morali biti obučeni da pritiskate dugmad na računaru, u budućnosti to neće biti slučaj.
Imam osjećaj da će uz Kubernetes i infrastrukturu doći do ogromnog povećanja jednostavnosti korištenja. To je, po mom mišljenju, očigledno – leži na površini.
Šta raditi sa inženjerima?
— Šta će se onda dogoditi sa inženjerima i sistem administratorima koji podržavaju Kubernetes?
Dmitri: Šta se dogodilo s računovođom nakon pojave 1C? Otprilike isto. Ranije su računali na papiru - sada u programu. Produktivnost rada je porasla za redove veličine, ali sam rad nije nestao. Ako je ranije bilo potrebno 10 inženjera da uvrnu sijalicu, sada će biti dovoljna jedna.
Količina softvera i broj zadataka, čini mi se, sada raste brže nego što se pojavljuju novi DevOpsi, a efikasnost raste. Trenutno postoji specifična nestašica na tržištu i to će trajati dugo. Kasnije će se sve vratiti u neku vrstu normalnosti, u kojoj će se povećavati efikasnost rada, biće sve više servera bez servera, na Kubernetes će biti priključen neuron koji će birati sve resurse tačno po potrebi i općenito će uradi sve sam, kako treba - osoba se samo odmakne i ne miješaj se.
Ali neko će ipak morati da donosi odluke. Jasno je da je nivo kvalifikacija i specijalizacije ove osobe viši. Danas vam u računovodstvu ne treba 10 radnika koji vode knjige da im se ruke ne umore. To jednostavno nije potrebno. Mnogi dokumenti se automatski skeniraju i prepoznaju od strane elektronskog sistema za upravljanje dokumentima. Dovoljan je jedan pametan šef računovodstva, već sa mnogo većim veštinama, sa dobrim razumevanjem.
Općenito, to je put kojim se ide u svim industrijama. Isto je i sa automobilima: ranije je dolazio auto sa mehaničarom i tri vozača. Danas je vožnja automobila jednostavan proces u kojem svi svakodnevno učestvujemo. Niko ne misli da je automobil nešto komplikovano.
DevOps ili sistemski inženjering neće nestati - rad na visokom nivou i efikasnost će se povećati.
— Čuo sam i jednu zanimljivu ideju da će se posao zapravo povećati.
Dmitri: Naravno, sto posto! Zato što količina softvera koji pišemo stalno raste. Broj problema koje rješavamo softverom stalno raste. Količina posla raste. Sada je DevOps tržište užasno pregrijano. To se vidi u očekivanjima plata. Na dobar način, ne ulazeći u detalje, trebalo bi da postoje juniori koji žele X, srednji koji žele 1,5X i seniori koji žele 2X. A sada, ako pogledate moskovsko DevOps tržište plata, junior želi od X do 3X, a stariji od X do 3X.
Niko ne zna koliko košta. Visina plata se mjeri vašim samopouzdanjem - potpuna ludnica, da budem iskren, užasno pregrijano tržište.
Naravno, ova situacija će se vrlo brzo promijeniti - trebalo bi doći do određenog zasićenja. To nije slučaj sa razvojem softvera - uprkos činjenici da su svima potrebni programeri, a svima trebaju dobri programeri, tržište razumije ko šta vrijedi - industrija se smirila. To nije slučaj sa DevOps-om ovih dana.
— Iz onoga što sam čuo zaključio sam da sadašnji sistem administrator ne treba previše da brine, ali da je vreme da unapredi svoje veštine i pripremi se za to da će sutra biti više posla, ali da će biti više kvalifikovan.
Dmitri: Sto posto. Generalno, živimo u 2019. godini i životno pravilo je ovo: doživotno učenje – učimo tokom života. Čini mi se da to sada već svi znaju i osjećaju, ali nije dovoljno znati - to morate učiniti. Svaki dan se moramo mijenjati. Ako to ne učinimo, prije ili kasnije ćemo biti bačeni na marginu struke.
Budite spremni na oštra skretanja od 180 stepeni. Ne isključujem situaciju da se nešto radikalno promijeni, nešto novo se izmisli - dogodi se. Hop! - i sada se ponašamo drugačije. Važno je da se na to pripremite i da ne brinete. Može se desiti da sutra sve što radim bude nepotrebno – ništa, učio sam cijeli život i spreman sam još nešto naučiti. Nije problem. Nema potrebe da se plašite sigurnosti posla, ali morate biti spremni da stalno učite nešto novo.
Želje i minut reklame
- Imate li neku želju?
Dmitri: Da, imam nekoliko želja.
Prvo i merkantilno - pretplatite se na . Dragi čitaoci, idite na YouTube i pretplatite se na naš kanal. Za otprilike mjesec dana počinjemo aktivno širenje video servisa. Imat ćemo puno obrazovnog sadržaja o Kubernetesu, otvorenog i raznolikog: od praktičnih stvari, sve do laboratorija, do dubokih temeljnih teorijskih stvari i kako koristiti Kubernetes na nivo principa i obrazaca.
Druga merkantilna želja - idi na i stavljamo zvijezde jer se njima hranimo. Ako nam ne date zvezdice, nećemo imati šta da jedemo. To je kao mana u kompjuterskoj igrici. Radimo nešto, radimo, trudimo se, neko kaže da su to strašni bicikli, neko da je sve potpuno pogrešno, ali mi nastavljamo i ponašamo se apsolutno pošteno. Vidimo problem, rješavamo ga i dijelimo svoja iskustva. Zato, daj nam zvijezdu, neće ti otići, nego će doći nama, jer se mi njima hranimo.
Treća, važna i više ne merkantilna želja - prestanite vjerovati u bajke. Vi ste profesionalci. DevOps je veoma ozbiljna i odgovorna profesija. Prestanite da se igrate na radnom mestu. Neka klikne umjesto vas i razumjet ćete. Zamislite da dođete u bolnicu, a tamo doktor eksperimentiše na vama. Razumijem da ovo može biti uvredljivo za nekoga, ali najvjerovatnije se ne radi o vama, već o nekom drugom. Reci i drugima da prestanu. Ovo zaista uništava život za sve nas - mnogi počinju tretirati operacije, administratore i DevOps kao tipove koji su opet nešto pokvarili. Ovo se „kvarilo“ najčešće zbog činjenice da smo išli da se igramo, a nismo gledali sa hladnom svešću da je tako, i tako je.
To ne znači da ne treba eksperimentisati. Moramo da eksperimentišemo, sami to radimo. Da budem iskren, i sami ponekad igramo igrice - to je, naravno, jako loše, ali ništa nam ljudsko nije strano. Proglasimo 2019. godinom ozbiljnih, dobro osmišljenih eksperimenata, a ne produkcijskih igara. Verovatno je tako.
- Hvala vam puno!
Dmitri: Hvala, Vitalij, i na vremenu i na intervjuu. Dragi čitaoci, hvala vam puno ako ste iznenada došli do ove tačke. Nadam se da smo vam doneli bar par misli.
U intervjuu, Dmitrij se dotakao pitanja werfa. Sada je ovo univerzalni švicarski nož koji rješava gotovo sve probleme. Ali nije uvijek bilo tako. On na festivalu Dmitry Stolyarov će vam detaljno reći o ovom alatu. u izvještaju biće svega: problema i skrivenih nijansi Kubernetesa, opcija za rešavanje ovih poteškoća i trenutne implementacije werf-a do detalja. Pridružite nam se 27. i 28. maja, kreiraćemo savršene alate.
izvor: www.habr.com