U iščekivanju Vitalij Khabarov intervjuiran Dmitrij Stoljarov (), tehnički direktor i suosnivač tvrtke Flant. Vitalij je pitao Dmitrija o tome što Flant radi, o Kubernetesu, razvoju ekosustava, podršci. Razgovarali smo o tome zašto je Kubernetes potreban i je li uopće potreban. I također o mikroservisima, Amazon AWS-u, pristupu DevOps-a “Imat ću sreće”, budućnosti samog Kubernetesa, zašto, kada i kako će preuzeti svijet, izgledima DevOps-a i na što bi se inženjeri trebali pripremiti u svijetla i bliska budućnost s pojednostavljenjem i neuronskim mrežama.
slušajte kao podcast na DevOps Deflop - podcast na ruskom jeziku o DevOpsu, a ispod je tekstualna verzija.
Ovdje i dolje postavlja pitanja inženjer iz Express42.
O "Flantu"
- Zdravo Dima. Vi ste tehnički direktor"“ i ujedno njegov osnivač. Recite nam čime se tvrtka bavi i što ste Vi u njoj?
Dmitry: Izvana se čini da smo mi tipovi koji instaliraju Kubernetes za sve i rade nešto s njim. Ali to nije istina. Počeli smo kao tvrtka koja se bavi Linuxom, ali nam je već jako dugo glavna djelatnost servisiranje proizvodnih i opterećenih projekata po principu ključ u ruke. Obično gradimo cijelu infrastrukturu od nule i onda smo odgovorni za nju dugo, dugo vremena. Dakle, glavni posao koji “Flant” radi, a za koji dobiva novac je preuzimanje odgovornosti i realizacija proizvodnje po principu ključ u ruke.
Ja, kao tehnički direktor i jedan od osnivača tvrtke, provodim cijele dane i noći pokušavajući smisliti kako povećati dostupnost proizvodnje, pojednostaviti njezin rad, učiniti život administratora lakšim, a život programera ugodnijim .
O Kubernetesu
— U posljednje vrijeme vidim puno izvještaja iz Flanta i o Kubernetesu. Kako ste došli do toga?
Dmitry: O tome sam već govorio mnogo puta, ali nemam ništa protiv da to ponovim. Mislim da je ispravno ponoviti ovu temu jer postoji zbrka između uzroka i posljedice.
Stvarno nam je trebao alat. Suočavali smo se s puno problema, borili, svladavali ih raznim štakama i osjećali potrebu za alatom. Prošli smo kroz mnogo različitih opcija, izradili vlastite bicikle i stekli iskustvo. Postupno smo došli do točke da smo počeli koristiti Docker gotovo čim se pojavio – oko 2013. godine. U vrijeme kada se pojavio, već smo imali puno iskustva s kontejnerima, već smo napisali analogni "Docker" - neke od naših vlastitih štaka u Pythonu. S pojavom Dockera, postalo je moguće odbaciti štake i koristiti pouzdano rješenje koje podržava zajednica.
S Kubernetesom je priča slična. Dok je počelo dobivati zamah - za nas je ovo verzija 1.2 - već smo imali hrpu štaka i na Shellu i na Chefu, koje smo nekako pokušali uskladiti s Dockerom. Ozbiljno smo gledali prema Rancheru i raznim drugim rješenjima, ali onda se pojavio Kubernetes u kojem je sve implementirano točno onako kako bismo mi to napravili ili čak i bolje. Nema se što prigovoriti.
Da, postoji neka vrsta nesavršenosti ovdje, postoji neka vrsta nesavršenosti tamo - ima puno nesavršenosti, a 1.2 je općenito užasna, ali... Kubernetes je kao zgrada u izgradnji - pogledate projekt i shvatite da će biti cool. Ako zgrada sada ima temelje i dva kata, onda razumijete da je bolje da se još ne useljavate, ali nema takvih problema sa softverom - već ga možete koristiti.
Nismo imali trenutak u kojem smo razmišljali hoćemo li koristiti Kubernetes ili ne. Čekali smo ga mnogo prije nego što se pojavio i pokušali sami stvoriti analoge.
O Kubernetesu
— Jeste li izravno uključeni u razvoj samog Kubernetesa?
Dmitry: osrednji. Dapače, sudjelujemo u razvoju ekosustava. Šaljemo određeni broj pull zahtjeva: Prometheusu, raznim operaterima, Helmu – ekosustavu. Nažalost, ne mogu pratiti sve što radimo i mogao bih biti u krivu, ali nema niti jednog bazena od nas do jezgre.
— U isto vrijeme, razvijate li mnogo svojih alata oko Kubernetesa?
Dmitry: Strategija je sljedeća: idemo i povlačimo zahtjeve za sve što već postoji. Ako zahtjevi za povlačenjem tamo nisu prihvaćeni, jednostavno ih sami račvamo i živimo dok ne budu prihvaćeni s našim buildovima. Zatim, kada dosegne uzvodno, vraćamo se na uzvodnu verziju.
Na primjer, imamo Prometheus operatera, s kojim smo se prebacivali naprijed-natrag na uzvodno od našeg sklopa vjerojatno već 5 puta. Trebamo neku značajku, poslali smo zahtjev za povlačenjem, moramo je objaviti sutra, ali ne želimo čekati da bude puštena uzvodno. U skladu s tim, sastavljamo za sebe, izbacujemo svoj sklop s našom značajkom, koja nam je iz nekog razloga potrebna, na sve naše klastere. Onda nam ga, na primjer, okrenu uzvodno s riječima: "Ljudi, ajmo to za općenitiji slučaj", mi ili netko drugi to završi i s vremenom se opet spoji.
Trudimo se razvijati 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 proizvodnju bicikla kao industriju, već jednostavno zato što nam je potreban ovaj alat. Često se postavlja pitanje zašto smo učinili ovo ili ono? Odgovor je jednostavan - da, jer smo morali ići dalje, riješiti neki praktični problem, a mi smo ga ovom tulom riješili.
Put je uvijek takav: vrlo pažljivo tražimo i, ako ne nađemo rješenje kako od štruce kruha napraviti trolejbus, onda napravimo svoju štrucu i svoj trolejbus.
Alati Flanta
— 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 Flaunta. To je istina?
Dmitry: Imamo puno više na GitHubu. Koliko se sada sjećam, imamo statusmap - panel za Grafanu na koji su svi nailazili. Spominje se u gotovo svakom drugom članku o Kubernetes nadzoru na Mediumu. Nemoguće je ukratko objasniti što je mapa statusa - za to treba poseban članak, ali je vrlo korisna stvar za praćenje statusa kroz vrijeme, budući da u Kubernetesu često moramo prikazati status kroz vrijeme. Imamo i LogHouse - to je stvar bazirana na ClickHouseu i crnoj magiji za skupljanje logova u Kubernetesu.
Mnogo komunalnih usluga! A bit će ih još više jer ove godine izlazi niz internih rješenja. Od onih jako velikih baziranih na addon operatoru, postoji hrpa addona za Kubernetes, ala kako pravilno instalirati sert manager - alat za upravljanje certifikatima, kako pravilno instalirati Prometheus sa hrpom dodataka - to je dvadesetak različitih binarne datoteke koje izvoze podatke i prikupljaju nešto, na ovaj Prometheus ima najnevjerojatnije grafike i upozorenja. Sve je to samo hrpa dodataka Kubernetesu koji se instaliraju u klasteru, a on iz jednostavnog postaje cool, sofisticiran, automatski, u kojem su mnogi problemi već riješeni. Da, radimo puno.
Razvoj ekosustava
“Čini mi se da je ovo vrlo veliki doprinos razvoju ovog instrumenta i načina njegove uporabe.” Možete li okvirno procijeniti tko bi još dao isti doprinos razvoju ekosustava?
Dmitry: U Rusiji, od tvrtki koje posluju na našem tržištu, nitko nije ni blizu. Naravno, ovo je glasna izjava, jer postoje veliki igrači kao što su Mail i Yandex - oni također rade nešto s Kubernetesom, ali ni oni nisu blizu doprinosu kompanija u cijelom svijetu koje rade mnogo više od nas. Teško je usporediti 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 uspoređivati. Imamo 6 ljudi u RnD odjelu, uključujući mene, koji režemo sav naš alat. 6 ljudi naspram 300 Red Hat inženjera - nekako je teško usporediti.
- Međutim, kada i tih 6 ljudi može učiniti nešto stvarno korisno i otuđujuće, kada se suoče s praktičnim problemom i daju rješenje zajednici - zanimljiv slučaj. Razumijem da se u velikim tehnološkim tvrtkama, gdje imaju vlastiti tim za razvoj i podršku Kubernetesa, u načelu mogu razvijati isti alati. Ovo im je primjer što se može razviti i dati zajednici, dati poticaj cijeloj zajednici koja koristi Kubernetes.
Dmitry: To je vjerojatno značajka integratora, njegova posebnost. Imamo mnogo projekata i vidimo mnogo različitih situacija. Za nas je glavni način stvaranja dodane vrijednosti analizirati te slučajeve, pronaći sličnosti i učiniti ih što jeftinijima za nas. Aktivno radimo na tome. Teško mi je govoriti o Rusiji i svijetu, ali imamo oko 40 DevOps inženjera u tvrtki koji rade na Kubernetesu. Mislim da u Rusiji nema mnogo tvrtki s usporedivim brojem stručnjaka koji razumiju Kubernetes, ako ih uopće ima.
Razumijem sve o nazivu radnog mjesta DevOps inženjer, svi razumiju sve i navikli su DevOps inženjere zvati DevOps inženjeri, o tome nećemo raspravljati. Svih ovih 40 nevjerojatnih DevOps inženjera suočavaju se i rješavaju probleme svaki dan, mi samo analiziramo ovo iskustvo i pokušavamo generalizirati. Razumijemo da ako ostane u nama, onda će za godinu ili dvije alat biti beskoristan, jer će se negdje u zajednici pojaviti gotova Tula. Nema svrhe akumulirati ovo iskustvo interno - to je jednostavno crpljenje energije i vremena u dev/null. I uopće nam nije žao zbog toga. Sve objavljujemo s velikim zadovoljstvom i razumijemo da to treba objavljivati, razvijati, promovirati, promovirati, da ljudi to koriste i dodaju svoje iskustvo - onda sve raste i živi. Onda nakon dvije godine instrument ne ide u smeće. Nije šteta dalje ulijevati snagu, jer jasno je da netko koristi tvoj alat, a nakon dvije godine svi ga koriste.
Ovo je dio naše velike strategije s dapp/werf. Ne sjećam se kada smo ga počeli praviti, čini mi se prije 3 godine. U početku je uglavnom bio na ljusci. Bio je to super dokaz koncepta, riješili smo neke svoje probleme - uspjelo je! Ali postoje problemi s ljuskom, nemoguće ju je dalje proširivati, programiranje na ljusci je drugi zadatak. Imali smo naviku pisati u Rubyju, shodno tome nešto smo prepravljali u Rubyju, razvijali, razvijali, razvijali i naletjeli na to da zajednica, gomila koja ne kaže “hoćemo ili ne želimo, ” podiže nos prema Ruby, koliko je to smiješno? Shvatili smo da bismo sve ove stvari trebali pisati u Go samo da ispunimo prvu točku na popisu za provjeru: Alat DevOps trebao bi biti statički binarni. Biti Go ili ne nije toliko važno, ali statična binarna datoteka napisana u Go-u 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 slijediti.
Zašto je dapp stvoren?
— Možete li nam ukratko reći zašto je dapp nastao, koje probleme rješava?
Dmitry: Prvi razlog je u skupštini. U početku smo imali ozbiljnih problema s izgradnjom kada Docker nije imao višestupanjske mogućnosti, pa smo sami napravili višestupanjski. Zatim smo imali još hrpu problema s čišćenjem slike. Svi koji rade CI/CD prije nego kasnije susreću se s problemom da postoji hrpa skupljenih slika, treba nekako počistiti ono što ne treba i ostaviti ono što treba.
Drugi razlog je raspoređivanje. Da, postoji Helm, ali on rješava samo neke od problema. Zanimljivo je da je napisano da je "Helm upravitelj paketa za Kubernetes." Točno ono "the". Tu su i riječi "Upravitelj paketa" - što se obično očekuje od Upravitelja paketa? Kažemo: “Package Manager - instaliraj paket!” i očekujemo da nam kaže: "Paket je isporučen."
Zanimljivo je da kažemo: “Helm, instaliraj paket”, a kad on odgovori da ga je instalirao, ispada da je upravo pokrenuo instalaciju - pokazao je Kubernetes: “Pokreni ovu stvar!”, a da li je krenula ili ne , bez obzira radi li ili ne, Helm uopće ne rješava ovaj problem.
Ispada da je Helm samo pretprocesor teksta koji učitava podatke u Kubernetes.
Ali kao dio bilo koje implementacije, želimo znati je li aplikacija puštena u proizvodnju ili ne? Izvedeno na proizvod znači da je aplikacija tamo premještena, da je nova verzija implementirana i da se barem tamo ne ruši i da ispravno reagira. Helm ni na koji način ne rješava ovaj problem. Da biste to riješili, morate uložiti puno truda, jer Kubernetesu morate dati naredbu za izvođenje i pratiti što se tamo događa - je li postavljen ili izvaljen. A tu je i puno zadataka vezanih uz postavljanje, čišćenje i sastavljanje.
Planovi
Ove godine krenut ćemo s lokalnim razvojem. Želimo postići ono što je prije bilo u Vagrantu - upisali smo "vagrant up" i postavili virtualne strojeve. Želimo doći do točke gdje postoji projekt u Gitu, tamo napišemo "werf up", i to donosi lokalnu kopiju ovog projekta, raspoređenu u lokalnom mini-Kubu, sa svim povezanim direktorijima pogodnim za razvoj . Ovisno o razvojnom jeziku, to se radi drugačije, ali svejedno, tako da se lokalni razvoj može prikladno izvesti pod montiranim datotekama.
Sljedeći korak za nas je ulagati u pogodnosti za programere. Da biste brzo implementirali projekt lokalno s jednim alatom, razvijte ga, gurnite u Git, a također će se razviti u fazu ili testirati, ovisno o cjevovodima, a zatim koristiti isti alat za prelazak u proizvodnju. To jedinstvo, unificiranost, ponovljivost infrastrukture od lokalne sredine do prodaje za nas je vrlo važna točka. Ali ovo još nije u werf-u - tek planiramo to učiniti.
Ali put do dapp/werf je uvijek bio isti kao i kod Kubernetesa na početku. Nailazili smo na probleme, rješavali ih zaobilaznim rješenjima - došli smo do nekih rješenja za sebe na ljusci, na bilo čemu. Zatim su pokušali nekako ispraviti ta zaobilazna rješenja, generalizirati ih i konsolidirati u binarne datoteke u ovom slučaju, koje jednostavno dijelimo.
Postoji i drugi način gledanja na cijelu ovu priču, uz analogije.
Kubernetes je okvir automobila s motorom. Nema vrata, stakla, radija, božićnog drvca - baš ničega. Samo okvir i motor. A tu je i Helm - ovo je volan. Cool - postoji volan, ali treba vam i osovina volana, letva volana, mjenjač i kotači, a bez njih ne možete.
U slučaju werfa, ovo je još jedna komponenta Kubernetesa. Samo sada u alfa verziji werfa, na primjer, Helm je kompiliran unutar werfa, jer smo umorni od toga da to radimo sami. Mnogo je razloga da to učinimo, detaljno ću vam reći zašto smo sastavili cijeli helm zajedno s rudilom unutar werfa .
Sada je werf integriranija komponenta. Dobivamo gotov volan, iglu upravljača - nisam baš dobar u automobilima, ali ovo je veliki blok koji već rješava prilično širok raspon problema. Ne trebamo sami prolaziti kroz katalog, birati jedan dio za drugim, razmišljati kako ih spojiti. Dobivamo gotov kombajn koji rješava veliki broj problema odjednom. Ali iznutra je izgrađen od istih komponenti otvorenog koda, još uvijek koristi Docker za sastavljanje, Helm za neke funkcionalnosti, a postoji i nekoliko drugih biblioteka. Ovo je integrirani alat za brzo i praktično dobivanje cool CI/CD-a iz kutije.
Je li Kubernetes težak za održavanje?
— Govorite o iskustvu da ste počeli koristiti Kubernetes, ovo je okvir za vas, motor, i da na njega možete objesiti puno različitih stvari: karoseriju, volan, pričvrstiti pedale, sjedala. Postavlja se pitanje – koliko vam je teška podrška za Kubernetes? Imate puno iskustva, koliko vremena i resursa trošite na podršku Kubernetesa odvojeno od svega ostalog?
Dmitry: Ovo je vrlo teško pitanje i da bismo odgovorili, moramo razumjeti što je podrška i što želimo od Kubernetesa. Možda možete otkriti?
— Koliko ja znam i koliko vidim, sada mnogi timovi žele isprobati Kubernetes. Svi se upregnu u nju, stave je na koljena. Imam osjećaj da ljudi ne razumiju uvijek složenost ovog sustava.
Dmitry: Tako je.
— Koliko je teško uzeti i instalirati Kubernetes od nule tako da bude spreman za proizvodnju?
Dmitry: Što mislite, koliko je teško presaditi srce? Razumijem da je ovo kompromitirajuće pitanje. Koristiti skalpel i ne pogriješiti nije tako teško. Ako vam kažu gdje rezati, a gdje šivati, onda sam postupak nije kompliciran. Teško je svaki put jamčiti da će sve uspjeti.
Lako je instalirati Kubernetes i pokrenuti ga: curo! — instaliran, postoji mnogo načina instalacije. Ali što se događa kada se pojave problemi?
Uvijek se nameću pitanja – što još nismo uzeli u obzir? Što još nismo napravili? Koji su parametri jezgre Linuxa netočno navedeni? Gospode, jesmo li ih uopće spomenuli?! Koje Kubernetes komponente smo isporučili, a koje nismo? Pojavljuju se tisuće pitanja, a za odgovor na njih potrebno je provesti 15-20 godina u ovoj industriji.
Imam nedavni primjer o ovoj temi koji bi mogao otkriti značenje problema "Je li Kubernetes teško održavati?" Prije nekog vremena ozbiljno smo razmišljali trebamo li pokušati implementirati Cilium kao mrežu u Kubernetes.
Dopustite mi da objasnim što je Cilium. Kubernetes ima mnogo različitih implementacija mrežnog podsustava, a jedna od njih je jako cool – Cilium. Koje je njegovo značenje? U kernelu je prije nekog vremena postalo moguće pisati kuke za kernel, koje na ovaj ili onaj način napadaju mrežni podsustav i razne druge podsustave, i omogućuju vam da zaobiđete velike dijelove u kernelu.
Linux kernel povijesno ima ip rout, overfilter, mostove i mnogo različitih starih komponenti koje su stare 15, 20, 30 godina. Općenito rade, sve je super, ali sad su nagomilali kontejnere, i to izgleda kao kula od 15 cigli jedna na drugoj, a vi stojite na njoj na jednoj nozi - čudan osjećaj. Ovaj sustav se kroz povijest razvijao s mnogo nijansi, poput slijepog crijeva u tijelu. U nekim situacijama, na primjer, postoje problemi s izvedbom.
Postoji prekrasan BPF i mogućnost pisanja kuka za kernel - dečki su napisali vlastite kuke za kernel. Paket dođe u Linux kernel, oni ga odmah na ulazu izvade, sami obrade kako treba bez bridgeova, bez TCP-a, bez IP stacka - ukratko, zaobiđu sve što piše u Linux kernelu, i onda pljuju. van u spremnik.
Što se dogodilo? Vrlo cool performanse, cool značajke - jednostavno cool! Ali gledamo ovo i vidimo da na svakom stroju postoji program koji se spaja na Kubernetes API i, na temelju podataka koje prima od ovog API-ja, generira C kod i kompajlira binarne datoteke koje učitava u kernel tako da ove kuke rade u prostoru jezgre .
Što ako nešto pođe po zlu? Ne znamo. Da biste ovo razumjeli, trebate pročitati sav ovaj kod, razumjeti svu logiku, a nevjerojatno je koliko je to teško. Ali, s druge strane, tu su ti mostovi, net filteri, ip rout - nisam pročitao njihov izvorni kod, kao ni 40 inženjera koji rade u našoj tvrtki. Možda samo rijetki razumiju neke dijelove.
I koja je razlika? Ispostavilo se da postoji ip rout, Linux kernel i postoji novi alat - kakve veze ima, ne razumijemo ni jedno ni drugo. Ali bojimo se koristiti nešto novo - zašto? Jer ako je alat star 30 godina, onda su u 30 godina svi bugovi pronađeni, sve greške su ugažene i ne morate sve znati - radi kao crna kutija i uvijek radi. Svatko zna koji dijagnostički odvijač zabiti na koje mjesto, koji tcpdump u kojem trenutku pokrenuti. Svatko dobro poznaje dijagnostičke uslužne programe i razumije kako ovaj skup komponenti radi u jezgri Linuxa - ne kako radi, već kako se njime služi.
A nevjerojatno cool Cilium nema 30 godina, još nije ostario. Kubernetes ima isti problem, kopiraj. Da je Cilium instaliran savršeno, da je Kubernetes instaliran savršeno, ali kada nešto pođe po zlu u produkciji, možete li u kritičnoj situaciji brzo shvatiti što je pošlo po zlu?
Kad kažemo je li teško održavati Kubernetes – ne, vrlo je lako, i da, nevjerojatno je teško. Kubernetes radi odlično sam, ali s milijardu nijansi.
O pristupu "imat ću sreće".
— Postoje li tvrtke u kojima je gotovo zajamčeno da će se pojaviti ove nijanse? Pretpostavimo da Yandex iznenada prebaci sve usluge na Kubernetes, tamo će biti ogromno opterećenje.
Dmitry: Ne, ovo nije razgovor o teretu, nego o najjednostavnijim stvarima. Na primjer, imamo Kubernetes, tamo smo implementirali aplikaciju. Kako znaš da radi? Jednostavno ne postoji gotov alat za razumijevanje da se aplikacija ne ruši. Ne postoji gotov sustav koji šalje upozorenja; morate konfigurirati ova upozorenja i svaki raspored. I ažuriramo Kubernetes.
Imam Ubuntu 16.04. Možete reći da je ovo stara verzija, ali još uvijek smo na njoj jer je LTS. Postoji systemd, čija je nijansa ta što ne čisti C-grupe. Kubernetes pokreće podove, stvara C-grupe, zatim briše podove i nekako ispada - ne sjećam se detalja, oprostite - da systemd isječci ostaju. To dovodi do činjenice da s vremenom bilo koji automobil počinje snažno usporavati. Ovdje čak nije riječ ni o visokom opterećenju. Ako se pokrenu stalni podovi, na primjer, ako postoji Cron Job koji stalno generira podove, tada će stroj s Ubuntu 16.04 početi usporavati nakon tjedan dana. Bit će stalno visok prosjek opterećenja zbog činjenice da je stvorena hrpa C-grupa. Ovo je problem s kojim će se suočiti svaka osoba koja jednostavno instalira Ubuntu 16 i Kubernetes na vrhu.
Recimo, on nekako ažurira systemd ili nešto drugo, ali u Linux kernelu do 4.16 to je još smješnije - kada izbrišete C-grupe, one cure u kernelu i zapravo se ne brišu. Stoga će nakon mjesec dana rada na ovom stroju biti nemoguće pogledati statistiku memorije za ognjišta. Izvadimo datoteku, zavrtamo je u programu, a jedna datoteka se vrti 15 sekundi, jer kernelu treba jako puno vremena da izbroji milijun C-grupa u sebi, koje kao da su izbrisane, ali ne - cure .
Ima tu i tamo još puno takvih sitnica. Ovo nije problem s kojim se divovske tvrtke ponekad mogu suočiti pod vrlo velikim opterećenjem - ne, to su svakodnevne stvari. Ljudi mogu ovako živjeti mjesecima - instalirali su Kubernetes, postavili aplikaciju - čini se da radi. Za mnoge ljude to je normalno. Neće ni znati da će se ova aplikacija iz nekog razloga srušiti, neće primiti upozorenje, ali za njih je to norma. Prije smo živjeli na virtualnim strojevima bez nadzora, sada smo prešli na Kubernetes, također bez nadzora - koja je razlika?
Pitanje je da kada hodamo po ledu, nikad ne znamo njegovu debljinu osim ako je ne izmjerimo unaprijed. Mnogi ljudi hodaju i ne brinu se, jer su već hodali.
S moje točke gledišta, nijansa i složenost upravljanja bilo kojim sustavom je osigurati da je debljina leda točno dovoljna da riješi naše probleme. Ovo je ono o čemu pričamo.
U IT-u, čini mi se, ima previše pristupa tipa "imat ću sreće". Mnogi ljudi instaliraju softver i koriste softverske biblioteke u nadi da će im se posrećiti. Općenito, mnogi ljudi imaju sreće. Vjerojatno zato i funkcionira.
— Prema mojoj pesimističkoj procjeni, to izgleda ovako: kada su rizici visoki, a aplikacija mora raditi, tada je potrebna podrška od Flaunta, možda od Red Hata, ili vam treba vlastiti interni tim posvećen posebno Kubernetesu, koji je spreman povući ga.
Dmitry: Objektivno je tako. Samostalno ulazak u priču o Kubernetesu za mali tim uključuje brojne rizike.
Trebamo li kontejnere?
— Možete li nam reći koliko je Kubernetes raširen u Rusiji?
Dmitry: Nemam te podatke, a nisam siguran da ih itko drugi ima. Kažemo: "Kubernetes, Kubernetes", ali postoji i drugi način gledanja na ovo pitanje. Također ne znam koliko su kontejneri rašireni, ali znam podatak iz izvješća na internetu da 70% kontejnera dirigira Kubernetes. Bio je to pouzdan izvor za prilično velik uzorak diljem svijeta.
Onda još jedno pitanje - trebaju li nam kontejneri? Moj osobni osjećaj i opći stav tvrtke Flant je da je Kubernetes de facto standard.
Neće biti ničega osim Kubernetesa.
Ovo je apsolutna promjena u polju upravljanja infrastrukturom. Samo apsolutno - to je to, nema više Ansiblea, Chefa, virtualnih strojeva, Terraforma. Ne govorim o starim kolektivnim metodama. Kubernetes je apsolutni mjenjač, a sada će biti samo ovako.
Jasno je da je nekima potrebno nekoliko godina, a drugima nekoliko desetljeća da to shvate. Ne sumnjam da neće biti ničega osim Kubernetesa i ovog novog izgleda: više ne oštećujemo operativni sustav, već koristimo infrastruktura kao kod, samo ne kodom, nego yml-om - deklarativno opisanom infrastrukturom. Imam osjećaj da će uvijek biti ovako.
— Odnosno, one tvrtke koje još nisu prešle na Kubernetes definitivno će prijeći na njega ili će ostati u zaboravu. dobro sam te razumio?
Dmitry: Ovo također nije sasvim točno. Na primjer, ako imamo zadatak pokrenuti DNS poslužitelj, 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 se za 20 godina jednom morati nešto ažurirati. Ako govorimo o softveru u formatu koji smo pokrenuli i on zapravo radi mnogo godina bez ikakvih ažuriranja, bez izmjena, onda, naravno, neće biti Kubernetesa. On tamo nije potreban.
Sve vezano za CI/CD - gdje god je potrebna Continuous Delivery, gdje trebate ažurirati verzije, napraviti aktivne promjene, gdje god trebate izgraditi toleranciju na pogreške - samo Kubernetes.
O mikroservisima
- Ovdje imam malu disonancu. Za rad s Kubernetesom potrebna vam je vanjska ili unutarnja podrška - ovo je prva točka. Drugo, kad tek krećemo s razvojem, mi smo mali startup, nemamo još ništa, razvoj za Kubernetes ili mikroservisnu arhitekturu općenito može biti složen i ne uvijek ekonomski opravdan. Zanima me vaše mišljenje - trebaju li startupi odmah početi pisati za Kubernetes od nule ili ipak mogu napisati monolit, pa tek onda doći u Kubernetes?
Dmitry: Cool pitanje. Razgovarao sam o mikroservisima Mnogo sam puta susreo ljude koji pokušavaju zakucati čavle pomoću mikroskopa. Sam pristup je ispravan, mi sami tako dizajniramo svoj interni softver. Ali kada to radite, morate jasno razumjeti što radite. Riječ koju najviše mrzim kod mikroservisa je "mikro". Povijesno gledano, ova riječ je tamo nastala, a ljudi iz nekog razloga misle da je mikro vrlo malen, manji od milimetra, poput mikrometra. To je pogrešno.
Na primjer, postoji monolit koji piše 300 ljudi, a svi koji su sudjelovali u razvoju shvaćaju da tu ima problema, i treba ga razbiti na mikrokomadiće - oko 10 komada, od kojih svaki piše 30 ljudi u minimalnoj verziji. Ovo je važno, potrebno i cool. Ali kad nam dođe startup, gdje su 3 jako kul i talentirana tipa napisala 60 mikroservisa na koljenima, svaki put tražim Corvalol.
Čini mi se da je o tome već tisuće puta rečeno - dobili smo distribuirani monolit u ovom ili onom obliku. To nije ekonomski opravdano, jako je teško općenito u svemu. Upravo sam ovo vidio toliko puta da me stvarno boli, pa nastavljam pričati o tome.
Na početno pitanje, postoji sukob između činjenice da je, s jedne strane, Kubernetes strašno koristiti, jer nije jasno što bi se tamo moglo pokvariti ili ne raditi, s druge strane, jasno je da sve ide tamo i ništa osim Kubernetesa neće postojati. odgovor - odvažite količinu koristi koja dolazi, količinu zadataka koje možete riješiti. Ovo je na jednoj strani ljestvice. S druge strane, postoje rizici povezani sa zastojem ili sa smanjenjem vremena odziva, razine dostupnosti - sa smanjenjem pokazatelja učinka.
Evo ga - ili se krećemo brzo, a Kubernetes nam omogućuje da mnoge stvari radimo mnogo brže i bolje, ili koristimo pouzdana, vremenski testirana rješenja, ali se krećemo mnogo sporije. To je izbor koji svaka tvrtka mora napraviti. Možete to zamisliti kao stazu u džungli - kad hodate prvi put, možete sresti zmiju, tigra ili bijesnog jazavca, a kad hodate 10 puta, utabali ste stazu, maknuli grane i lakše hodati. Svaki put put postaje sve širi. Tada je to asfaltirana cesta, a kasnije prekrasan bulevar.
Kubernetes ne miruje. Ponovno pitanje: Kubernetes je s jedne strane 4-5 binarnih datoteka, s druge strane cijeli ekosustav. Ovo je operativni sustav koji imamo na našim strojevima. Što je to? Ubuntu ili Curios? Ovo je Linux kernel, hrpa dodatnih komponenti. Sve ovo ovdje, jedna zmija otrovnica je izbačena s ceste, tu je podignuta ograda. Kubernetes se razvija vrlo brzo i dinamično, a količina rizika, količina nepoznatog se svakim mjesecom smanjuje i shodno tome se ta vaga ponovno uravnotežuje.
Odgovarajući na pitanje što startup treba raditi, rekao bih - dođite u Flaunt, platite 150 tisuća rubalja i dobijte DevOps jednostavnu uslugu po principu "ključ u ruke". Ako ste mali startup s nekoliko programera, ovo funkcionira. Umjesto angažiranja vlastitog DevOps-a, koji će morati naučiti rješavati vaše probleme i isplaćivati plaću u ovom trenutku, dobit ćete ključ u ruke rješenje za sve probleme. Da, postoje neki nedostaci. Mi kao vanjski naručitelj ne možemo biti toliko uključeni i brzo reagirati na promjene. Ali imamo puno stručnog znanja i gotovih praksi. Jamčimo da ćemo u svakoj situaciji sigurno brzo shvatiti i podići bilo koji Kubernete iz mrtvih.
Toplo preporučujem outsourcing startupima i etabliranim tvrtkama do veličine u kojoj možete posvetiti tim od 10 ljudi operacijama, jer inače nema smisla. Definitivno ima smisla ovo angažirati vanjske tvrtke.
O Amazonu i Googleu
— Može li se host iz rješenja Amazona ili Googlea smatrati vanjskim dobavljačem?
Dmitry: Da, naravno, ovo rješava niz problema. Ali opet postoje nijanse. Još uvijek morate razumjeti kako ga koristiti. Na primjer, postoji tisuću sitnica u radu Amazon AWS-a: potrebno je zagrijati Load Balancer ili unaprijed napisati zahtjev da "dečki, dobit ćemo promet, zagrijte Load Balancer za nas!" Morate znati ove nijanse.
Kad se obratite ljudima koji su se za to specijalizirali, zatvorite gotovo sve tipične stvari. Sada imamo 40 inženjera, do kraja godine vjerojatno će ih biti 60 - sa svim tim stvarima smo se definitivno susreli. Čak i ako se opet susrećemo s tim problemom na nekom projektu, brzo se zapitamo i znamo kako to riješiti.
Vjerojatno je odgovor - naravno, hostirana priča olakšava neki dio. Pitanje je jeste li spremni vjerovati tim hosterima i hoće li oni riješiti vaše probleme. Amazon i Google su dobro prošli. Za sve naše slučajeve - točno. Nemamo više pozitivnih iskustava. Svi ostali oblaci s kojima smo pokušali raditi stvaraju puno problema - Ager, i sve što je u Rusiji, i sve vrste OpenStacka u različitim implementacijama: Headster, Overage - što god želite. Svi oni stvaraju probleme koje ne želite riješiti.
Stoga je odgovor da, ali zapravo nema puno zrelih hostiranih rješenja.
Kome treba Kubernetes?
— Pa ipak, kome treba Kubernetes? Tko bi već trebao prijeći na Kubernetes, tko je tipični Flaunt klijent koji dolazi posebno za Kubernetes?
Dmitry: Ovo je zanimljivo pitanje, jer upravo sada, nakon Kubernetesa, mnogi nam se javljaju: "Dečki, znamo da radite Kubernetes, napravite to za nas!" Mi im odgovaramo: “Gospodo, mi ne radimo Kubernetes, mi radimo prod i sve što je povezano s tim.” Jer trenutno je jednostavno nemoguće napraviti proizvod bez da se napravi sav CI/CD i cijela ova priča. Svi su se odmaknuli 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đene probleme, a sad - hop! — Kubernetes će ih riješiti. Ljudi vjeruju u čuda. U mislima shvaćaju da čuda neće biti, ali u duši se nadaju – što ako će nam sad ovaj Kubernetes sve riješiti, toliko pričaju o tome! Odjednom on sad - kihne! - i srebrni metak, kihni! — i imamo 100% neprekidnog rada, svi programeri mogu izdati sve što uđe u proizvodnju 50 puta, a da se ne sruši. Općenito, čudo!
Kad takvi ljudi dođu kod nas, kažemo: “Oprostite, ali čudo ne postoji.” Da biste bili zdravi, morate se dobro hraniti i vježbati. Da bismo imali pouzdan proizvod, on mora biti pouzdano izrađen. Da biste imali prikladan CI/CD, morate ga napraviti ovakvim. To je puno posla koji treba obaviti.
Odgovarajući na pitanje kome treba Kubernetes – nikome ne treba Kubernetes.
Neki ljudi imaju pogrešno mišljenje da im treba Kubernetes. Ljudi trebaju, imaju duboku potrebu prestati razmišljati, proučavati i biti zainteresirani za sve probleme infrastrukture i probleme pokretanja svojih aplikacija. Oni žele da aplikacije samo rade i samo se implementiraju. Za njih je Kubernetes nada da će prestati slušati priče kako "ležali smo tamo", ili "ne možemo se otkotrljati", ili nešto treće.
Kod nas obično dolazi tehnički direktor. Od njega traže dvije stvari: s jedne strane da nam da osobine, s druge strane stabilnost. Predlažemo da to preuzmete na sebe i učinite to. Srebrni metak, bolje rečeno posrebreni, je to što ćete prestati razmišljati o tim problemima i gubiti vrijeme. Imat ćete posebne ljude koji će zatvoriti ovaj problem.
Formulacija da mi ili bilo tko drugi treba Kubernetes je netočna.
Admini stvarno trebaju Kubernetes, jer je to vrlo zanimljiva igračka s kojom se možete igrati i petljati. Budimo iskreni – svi vole igračke. Svi smo mi negdje djeca, a kad vidimo novu, poželimo je igrati. Neke su to obeshrabrili, primjerice, u upravi, 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 u području sistemske administracije i DevOpsa, onda još uvijek volim igračke, i dalje kupujem neke nove. Svi ljudi, na ovaj ili onaj način, ipak žele nekakve igračke.
Ne treba se igrati s proizvodnjom. Što god kategorički preporučam da ne radim i što sada masovno vidim: "O, nova igračka!" — otrčali su ga kupiti, kupili ga i: „Ajmo sad to odnijeti u školu i pokazati svim našim prijateljima.“ nemoj to raditi Ispričavam se, moja djeca tek odrastaju, stalno nešto vidim kod djece, primjećujem kod sebe, pa 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 pasti, znamo za to unaprijed, i možemo nešto staviti u to;
- možemo ga mijenjati brzinom kojom to naš posao zahtijeva i možemo to učiniti zgodno; ne stvara nam nikakve probleme.
Postoje dvije stvarne potrebe: pouzdanost i dinamičnost/fleksibilnost uvođenja. Svatko tko se trenutno bavi nekakvim IT projektima, bez obzira kojim se poslom bavio - soft za olakšanje svijeta, i tko se u to razumije, mora riješiti te potrebe. Kubernetes s pravim pristupom, s pravim razumijevanjem i s dovoljno iskustva omogućuje vam da ih riješite.
O bez poslužitelja
— Ako pogledate malo dalje u budućnost, pokušavajući riješiti problem nepostojanja glavobolje s infrastrukturom, brzinom rollouta i brzinom izmjene aplikacija, pojavljuju se nova rješenja, na primjer, bez servera. Osjećate li u tom smjeru potencijal i, recimo, opasnost za Kubernetes i slična rješenja?
Dmitry: Ovdje opet trebamo reći da ja nisam vidovnjak koji gleda naprijed i kaže - bit će ovako! Iako sam upravo učinio istu stvar. Gledam u noge i vidim tamo hrpu problema, na primjer, kako rade tranzistori u računalu. Smiješno je, zar ne? Susrećemo se s greškama u procesoru.
Učinite bez poslužitelja prilično pouzdanim, jeftinim, učinkovitim i praktičnim, rješavajući sve probleme ekosustava. Ovdje se slažem s Elonom Muskom da je potreban drugi planet kako bi se stvorila tolerancija grešaka za čovječanstvo. Iako ne znam što govori, shvaćam da nisam spreman sam odletjeti na Mars i da se to neće dogoditi sutra.
S serverlessom jasno je da je to ideološki ispravna stvar, poput tolerancije grešaka za čovječanstvo - imati dva planeta bolje je nego jedan. Ali kako to učiniti sada? Slanje jedne ekspedicije nije problem ako se na to koncentrirate. Poslati nekoliko ekspedicija i tamo smjestiti nekoliko tisuća ljudi, mislim da je također realno. Ali učiniti ga potpuno tolerantnim na pogreške tako da pola čovječanstva živi tamo, čini mi se sada nemogućim, ne razmišljam o tome.
S jedan na jedan bez poslužitelja: stvar je cool, ali je daleko od problema 2019. godine. Bliži se 2030. – živi bili i vidjeli. Ne sumnjam da ćemo živjeti, sigurno ćemo živjeti (ponoviti prije spavanja), ali sada treba riješiti druge probleme. Kao da vjerujete u ponija Dugu iz bajke. Da, par posto slučajeva se riješi, i to savršeno, ali subjektivno, serverless je duga... Meni je ova tema predaleka i previše neshvatljiva. Nisam spreman za razgovor. U 2019. ne možete napisati niti jednu aplikaciju bez poslužitelja.
Kako će se Kubernetes razvijati
— Što mislite kako će se razvijati Kubernetes i ekosustav oko njega, kako se krećemo prema ovoj potencijalno prekrasnoj dalekoj budućnosti?
Dmitry: Puno sam razmišljao o ovome i imam jasan odgovor. Prvi je sa statusom - na kraju krajeva, bez statusa je lakše napraviti. Kubernetes je u početku uložio više u ovo, sve je počelo s tim. Stateless radi gotovo savršeno u Kubernetesu, nema se što prigovoriti. Još uvijek ima puno problema, ili bolje rečeno, nijansi. Tamo nam već sve odlično funkcionira, ali to smo mi. Trebat će još barem nekoliko godina da ovo počne funkcionirati za sve. Ovo nije izračunati pokazatelj, već moj osjećaj iz glave.
Ukratko, statefull bi se trebao - i hoće - razvijati vrlo snažno, jer sve naše aplikacije pohranjuju status; nema aplikacija bez stanja. To je iluzija, uvijek treba neka baza podataka i još nešto. Statefull je ispravljanje svega što je moguće, popravljanje svih grešaka, poboljšanje svih problema s kojima se trenutno suočavate - nazovimo to usvajanjem.
Razina nepoznatog, razina neriješenih problema, razina vjerojatnosti susreta s nečim značajno će pasti. Ovo je važna priča. I operatori - sve što se odnosi na kodifikaciju administrativne logike, upravljačke logike kako bi se dobila jednostavna usluga: MySQL jednostavna usluga, RabbitMQ jednostavna usluga, Memcache jednostavna usluga - općenito, sve ove komponente za koje trebamo jamčiti da rade kutija. Ovo samo rješava problem da želimo bazu podataka, ali je ne želimo administrirati, ili želimo Kubernetes, ali ne želimo da je administriramo.
Ova priča o razvoju operatera u ovom ili onom obliku bit će važna u sljedećih nekoliko godina.
Mislim da bi se jednostavnost korištenja trebala znatno povećati - kutija će postajati sve crnija, sve pouzdanija, sa sve više jednostavnih gumba.
Jednom sam slušao stari intervju s Isaacom Asimovim iz 80-ih na YouTubeu u Saturday Night Live - program poput Urganta, samo zanimljiv. Pitali su ga o budućnosti računala. Rekao je da je budućnost u jednostavnosti, baš kao i radiju. Radio prijamnik je izvorno bio složena stvar. Da biste uhvatili val, morali ste 15 minuta okretati gumbe, okretati ražnjeve i općenito znati kako sve funkcionira, razumjeti fiziku prijenosa radiovalova. Kao rezultat toga, na radiju je ostao samo jedan gumb.
Sada u 2019. koji radio? U autu radio prijemnik pronalazi sve valove i nazive postaja. Fizika procesa nije se promijenila u 100 godina, ali jednostavnost upotrebe jest. Sada, i ne samo sada, već 1980. godine, kada je bio intervju s Azimovom, svi su koristili radio i nitko nije razmišljao o tome kako radi. Uvijek je funkcioniralo - to se podrazumijeva.
Azimov je tada rekao da će tako biti i s računalima - jednostavnost korištenja će se povećati. Dok ste 1980. morali biti obučeni za pritiskanje tipki na računalu, to u budućnosti neće biti slučaj.
Imam osjećaj da će s Kubernetesom i infrastrukturom također doći do velikog povećanja jednostavnosti korištenja. To je, po mom mišljenju, očito - leži na površini.
Što učiniti s inženjerima?
— Što će se onda dogoditi s inženjerima i administratorima sustava koji podržavaju Kubernetes?
Dmitry: Što se dogodilo s računovođom nakon pojave 1C? Otprilike isto. Prije ovoga su brojali na papiru - sada u programu. Produktivnost rada se povećala za redove veličine, ali sam rad nije nestao. Ako je prije bilo potrebno 10 inženjera da uvije žarulju, sada će biti dovoljan jedan.
Količina softvera i broj zadataka, čini mi se, sada raste brže nego što se pojavljuju novi DevOps i učinkovitost raste. Trenutno postoji specifična nestašica na tržištu i trajat će dugo. Kasnije će se sve vratiti u nekakvu normalu, u kojoj će se povećati učinkovitost rada, bit će sve više serverlessa, na Kubernetes će se priključiti neuron koji će birati sve resurse točno po potrebi i općenito će učiniti sve sama, kako treba - osoba se samo odmakne i ne miješa se.
Ali netko će ipak morati donositi odluke. Jasno je da je razina kvalifikacija i specijalizacije te osobe viša. U današnje vrijeme u računovodstvu ne treba 10 djelatnika koji vode knjige da im se ruke ne umaraju. Jednostavno nije potrebno. Sustav za elektroničko upravljanje dokumentima automatski skenira i prepoznaje mnoge dokumente. Dovoljan je jedan pametan šef računovodstva, već s mnogo većim vještinama, s dobrim razumijevanjem.
Općenito, tako treba ići u svim industrijama. Isto je i s automobilima: prije je automobil dolazio s mehaničarom i tri vozača. Danas je vožnja automobila jednostavan proces u kojem svi sudjelujemo svaki dan. Nitko ne misli da je auto nešto komplicirano.
DevOps ili sistemski inženjering neće nestati - rad na visokoj razini i učinkovitost će se povećati.
— Čuo sam i zanimljivu ideju da će se posao zapravo povećati.
Dmitry: Naravno, sto posto! Jer 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 i po očekivanim plaćama. Na dobar način, ne ulazeći u detalje, trebali bi postojati juniori koji žele X, srednji koji žele 1,5X i stariji koji žele 2X. A sada, ako pogledate moskovsko DevOps tržište plaća, junior želi od X do 3X, a stariji želi od X do 3X.
Nitko ne zna koliko košta. Visina plaće se mjeri vašim povjerenjem - potpuna ludnica, da budemo iskreni, užasno pregrijano tržište.
Naravno, ta će se situacija vrlo brzo promijeniti – trebalo bi doći do nekog zasićenja. To nije slučaj s razvojem softvera – unatoč tome što svi trebaju programere, a svi trebaju dobre programere, tržište razumije tko koliko vrijedi – industrija se ustalila. To nije slučaj s DevOps-om ovih dana.
— Iz onoga što sam čuo zaključio sam da sadašnji sistemski administrator ne treba previše brinuti, već je vrijeme da unaprijedi svoje vještine i pripremi se na to da će sutra biti više posla, ali više kvalificiranog.
Dmitry: Sto posto. Generalno, živimo u 2019. godini i pravilo života je ovo: cjeloživotno učenje – učimo cijeli život. Čini mi se da to sada već svi znaju i osjećaju, ali nije dovoljno znati - morate to učiniti. Svaki dan se moramo mijenjati. Ako to ne učinimo, prije ili kasnije ćemo pasti na marginu struke.
Budite spremni na oštre zaokrete od 180 stupnjeva. Ne isključujem situaciju da se nešto radikalno promijeni, izmisli nešto novo - to se dogodi. hop! - i sada se ponašamo drugačije. Važno je biti spreman na to i ne brinuti se. Može se dogoditi da se sutra sve što radim pokaže nepotrebnim - ništa, učio sam cijeli život i spreman sam naučiti još nešto. Nije problem. Ne treba se bojati sigurnosti posla, ali morate biti spremni stalno učiti nešto novo.
Želje i minuta reklame
- Imate li kakvu želju?
Dmitry: Da, imam nekoliko želja.
Prvi i trgovački - pretplatite se na . Dragi čitatelji, idite na YouTube i pretplatite se na naš kanal. Za otprilike mjesec dana započet ćemo s aktivnim širenjem video usluge. Imat ćemo mnogo edukativnog sadržaja o Kubernetesu, otvorenog i raznolikog: od praktičnih stvari, sve do laboratorija, do dubokih temeljnih teorijskih stvari i načina korištenja Kubernetesa na razina principa i obrazaca.
Druga merkantilna želja - idite na i stavljati zvijezde jer se njima hranimo. Ako nam ne daš zvjezdice, nećemo imati što jesti. To je kao mana u kompjuterskoj igrici. Nešto radimo, radimo, trudimo se, netko kaže da su to strašni bicikli, netko da je sve potpuno krivo, ali mi nastavljamo i ponašamo se apsolutno pošteno. Vidimo problem, rješavamo ga i dijelimo svoje iskustvo. Zato, dajte nam zvijezdu, ona neće otići od vas, ali će doći k nama, jer mi se njima hranimo.
Treća, važna i ne više merkantilna želja - prestani vjerovati u bajke. Vi ste profesionalci. DevOps je vrlo ozbiljna i odgovorna profesija. Prestanite se igrati na radnom mjestu. Neka klikne za vas i shvatit ćete to. Zamislite da dođete u bolnicu, a tamo liječnik eksperimentira na vama. Razumijem da je ovo nekome možda uvredljivo, ali najvjerojatnije se ne radi o vama, nego o nekom drugom. Reci i drugima da prestanu. Ovo nam svima stvarno uništava život - mnogi počinju tretirati operacije, administratore i DevOps kao tipove koji su opet nešto pokvarili. To se “kršilo” najčešće zbog činjenice da smo išli igrati, a ne gledali hladnom sviješću da je to tako, a to je tako.
To ne znači da ne biste trebali eksperimentirati. Moramo eksperimentirati, sami to radimo. Da budem iskren, mi sami ponekad igramo igrice - to je, naravno, vrlo loše, ali ništa ljudsko nije nam strano. Proglasimo 2019. godinom ozbiljnih, dobro promišljenih eksperimenata, a ne igrica na produkciji. Vjerojatno je tako.
- Hvala vam puno!
Dmitry: Hvala, Vitaly, i na vremenu i na intervjuu. Dragi čitatelji, hvala vam puno ako ste iznenada došli do ove točke. Nadam se da smo vam donijeli barem par misli.
U intervjuu se Dmitry dotaknuo pitanja werfa. Sada je ovo univerzalni švicarski nož koji rješava gotovo sve probleme. Ali nije uvijek bilo tako. Na na festivalu Dmitry Stolyarov će vam detaljno reći o ovom alatu. u izvješću bit će svega: problemi i skrivene nijanse Kubernetesa, opcije za rješavanje tih poteškoća i detaljna trenutna implementacija werfa. Pridružite nam se 27. i 28. svibnja, kreirat ćemo savršene alate.
Izvor: www.habr.com