Ootuses Vitali Habarov intervjueeritud Dmitri Stoljarov (), ettevõtte Flant tehniline direktor ja kaasasutaja. Vitali küsis Dmitrilt, mida Flant teeb, Kubernetese, ökosüsteemi arengu ja toe kohta. Arutasime, miks Kubernetes on vaja ja kas seda üldse vaja on. Ja ka mikroteenustest, Amazon AWS-ist, "mul veab" lähenemisest DevOpsile, Kubernetese enda tulevikule, miks, millal ja kuidas see maailma vallutab, DevOpsi väljavaadetest ja sellest, milleks insenerid peaksid valmistuma helge ja lähitulevik koos lihtsustamise ja närvivõrkudega.
kuulake taskuhäälingusaadet DevOps Deflopist - venekeelne taskuhääling DevOpsi kohta ja allpool on tekstiversioon.
Siin ja allpool esitab ta küsimusi Express42 insener.
"Flanti" kohta
- Tere Dima. Sa oled tehniline direktor""ja ka selle asutaja. Palun öelge meile, millega ettevõte tegeleb ja millega te tegelete?
Dmitri: Väljastpoolt vaadates tundub, et me oleme need tüübid, kes installivad Kubernetes kõigile ja teevad sellega midagi. Aga see pole tõsi. Alustasime Linuxiga tegeleva ettevõttena, kuid väga pikka aega on meie põhitegevuseks olnud tootmis- ja suure koormusega võtmed kätte projektide teenindamine. Tavaliselt ehitame kogu taristu nullist üles ja siis vastutame selle eest kaua-kaua. Seetõttu on “Flanti” põhitöö, mille eest ta raha saab vastutuse võtmine ja võtmed-kätte tootmise juurutamine.
Ettevõtte tehnilise direktori ja ühe asutajana proovin terve päeva ja ööd välja mõelda, kuidas suurendada tootmise juurdepääsetavust, lihtsustada selle toimimist, muuta administraatorite elu lihtsamaks ja arendajate elu meeldivamaks. .
Kubernetese kohta
— Viimasel ajal olen näinud palju teateid Flantist ja Kubernetese kohta. Kuidas sa selleni jõudsid?
Dmitri: Olen sellest juba mitu korda rääkinud, kuid ma ei viitsi seda üldse korrata. Arvan, et seda teemat on õige korrata, sest põhjuse ja tagajärje vahel on segadus.
Meil oli tõesti tööriista vaja. Olime silmitsi paljude probleemidega, rabelesime, ületasime neid erinevate karkudega ja tundsime vajadust tööriista järele. Läbisime palju erinevaid võimalusi, ehitasime ise rattaid ja saime kogemusi. Järk-järgult jõudsime selleni, et hakkasime Dockerit kasutama peaaegu kohe pärast selle ilmumist – 2013. aasta paiku. Selle ilmumise ajal oli meil konteineritega juba palju kogemusi, olime juba kirjutanud “Dockeri” analoogi - mõned meie enda kargud Pythonis. Dockeri tulekuga sai võimalikuks kargud välja visata ning kasutada usaldusväärset ja kogukonna toetatud lahendust.
Kubernetesega on lugu sarnane. Selleks ajaks, kui see hoogu koguma hakkas – meie jaoks on see versioon 1.2 –, oli meil nii Shellil kui ka Chefil juba hunnik karkusid, mida me kuidagi Dockeriga orkestreerida proovisime. Vaatasime tõsiselt Rancheri ja erinevate muude lahenduste poole, kuid siis ilmus Kubernetes, milles kõik on ellu viidud täpselt nii, nagu oleksime teinud või isegi paremini. Kurta pole millegi üle.
Jah, siin on mingi ebatäiuslikkus, seal on mingi ebatäiuslikkus - puudusi on palju ja 1.2 on üldiselt kohutav, aga... Kubernetes on nagu ehitusjärgus hoone - vaatad projekti ja saad aru et lahe saab olema. Kui nüüd on hoonel vundament ja kaks korrust, siis saate aru, et parem on veel mitte sisse kolida, aga tarkvaraga selliseid probleeme pole - saab juba kasutada.
Meil ei olnud hetkegi, mil oleksime mõelnud, kas kasutada Kubernetest või mitte. Ootasime seda ammu enne selle ilmumist ja proovisime ise analooge luua.
Kubernetese kohta
— Kas olete otseselt seotud Kubernetese enda arendamisega?
Dmitri: Keskpärane. Pigem osaleme ökosüsteemi arendamisel. Saadame teatud arvu tõmbetaotlusi: Prometheusele, erinevatele operaatoritele, Helmile - ökosüsteemile. Kahjuks ei saa ma kõigel meie tegemistel silma peal hoida ja võin eksida, kuid meilt pole ühtegi basseini tuumani.
— Samas arendate paljusid oma tööriistu Kubernetese ümber?
Dmitri: Strateegia on järgmine: me läheme ja tõmbame päringud kõigele, mis juba olemas on. Kui tõmbetaotlusi seal vastu ei võeta, harutame need lihtsalt ise ja elame, kuni need meie ehitustega vastu võetakse. Seejärel, kui see jõuab ülesvoolu, läheme tagasi ülesvoolu versiooni juurde.
Meil on näiteks Prometheuse operaator, millega me vist juba 5 korda oma koostu ülesvoolu edasi-tagasi lülitasime. Meil on vaja mingit funktsiooni, saatsime tõmbamistaotluse, peame selle homme avaldama, kuid me ei taha oodata, kuni see ülesvoolu avaldatakse. Vastavalt sellele monteerime ise kokku, levitame koostu koos oma funktsiooniga, mida me mingil põhjusel vajame, kõikidesse oma klastritesse. Siis näiteks annavad nad selle meile ülesvoolus üle sõnadega: "Poisid, teeme seda üldisema juhtumi jaoks," meie või keegi teine lõpetame selle ja aja jooksul sulandub see uuesti tagasi.
Püüame arendada kõike, mis on olemas. Paljud elemendid, mida veel ei eksisteeri, pole veel leiutatud või on leiutatud, kuid pole jõudnud ellu viia – me teeme seda. Ja mitte sellepärast, et meile meeldiks protsess või jalgratta ehitamine kui tööstus, vaid lihtsalt sellepärast, et me vajame seda tööriista. Tihti küsitakse, miks me seda või teist asja tegime? Vastus on lihtne - jah, sest me pidime minema kaugemale, lahendama mõne praktilise probleemi ja selle tuliga me ka lahendasime.
Tee on alati selline: otsime väga hoolega ja kui ei leia lahendust, kuidas leivast trolli teha, siis teeme ise pätsi ja trolli.
Flanta tööriistad
— Ma tean, et Flantil on nüüd lisaoperaatorid, shelloperaatorid ja dapp/werf-tööriistad. Nagu ma aru saan, on see sama instrument erinevates kehastustes. Saan ka aru, et Flauntis on palju rohkem erinevaid tööriistu. See on tõsi?
Dmitri: Meil on GitHubis palju muud. Praegu mäletan, et meil on olekukaart – Grafana paneel, mis on kõigile meeldinud. Seda mainitakse peaaegu igas teises artiklis Kubernetese seire kohta Mediumis. On võimatu lühidalt selgitada, mis on olekukaart - see vajab eraldi artiklit, kuid see on väga kasulik asi oleku jälgimiseks aja jooksul, kuna Kuberneteses peame sageli näitama olekut aja jooksul. Meil on ka LogHouse - see on ClickHouse'il ja mustal maagial põhinev asi Kubernetes palkide kogumiseks.
Palju kommunaalteenuseid! Ja neid tuleb veelgi, sest sel aastal tuleb välja mitmeid siselahendusi. Väga suurtest, mis põhinevad lisandmooduli operaatoril, on Kubernetese jaoks hunnik lisandmooduleid, ah kuidas õigesti installida sert manager - tööriist sertifikaatide haldamiseks, kuidas Prometheust koos hulga tarvikutega õigesti installida - neid on umbes paarkümmend erinevat binaarfailid, mis ekspordivad andmeid ja koguvad midagi, on Prometheusel kõige hämmastavam graafika ja hoiatused. Kõik see on vaid hunnik Kubernetese lisandmooduleid, mis on installitud klastrisse ja mis muutub lihtsast lahedaks, keerukaks, automaatseks, milles paljud probleemid on juba lahendatud. Jah, me teeme palju.
Ökosüsteemi areng
"Mulle tundub, et see on väga suur panus selle instrumendi ja selle kasutusmeetodite arendamisse." Kas oskate ligikaudselt hinnata, kes veel annaks sama panuse ökosüsteemi arengusse?
Dmitri: Venemaal pole meie turul tegutsevatest ettevõtetest keegi lähedalgi. See on muidugi kõva avaldus, sest on suuri tegijaid nagu Mail ja Yandex – ka nemad teevad Kubernetesega midagi, kuid isegi nemad ei jõua ligilähedalegi kogu maailma ettevõtete panusele, kes teevad meiest palju rohkem. Raske on võrrelda Flanti, kus töötab 80 inimest, ja Red Hati, kus ainuüksi Kubernetese kohta on 300 inseneri, kui ma ei eksi. Seda on raske võrrelda. Meil on RnD osakonnas 6 inimest, sealhulgas mina, kes lõikavad kõik meie tööriistad. 6 inimest versus 300 Red Hati inseneri – seda on kuidagi raske võrrelda.
- Kui aga isegi need 6 inimest saavad teha midagi tõeliselt kasulikku ja võõrastavat, kui nad seisavad silmitsi praktilise probleemiga ja annavad kogukonnale lahenduse - huvitav juhtum. Saan aru, et suurtes tehnoloogiaettevõtetes, kus neil on oma Kubernetese arendus- ja tugimeeskond, saab põhimõtteliselt arendada samu tööriistu. See on neile eeskujuks, mida saab arendada ja kogukonnale anda, mis annab tõuke kogu Kubernetest kasutavale kogukonnale.
Dmitri: See on ilmselt integraatori omadus, selle eripära. Meil on palju projekte ja me näeme palju erinevaid olukordi. Meie jaoks on peamine lisandväärtuse loomise viis nende juhtumite analüüsimine, ühisosa leidmine ja nende enda jaoks võimalikult odav tegemine. Töötame selle nimel aktiivselt. Mul on raske rääkida Venemaast ja maailmast, kuid meil on ettevõttes umbes 40 DevOpsi inseneri, kes töötavad Kubernetese kallal. Ma arvan, et Venemaal ei ole palju ettevõtteid, kus oleks võrreldava arvu spetsialiste, kes mõistaksid Kubernetest, kui üldse.
Ma saan DevOpsi insener ametinimetuse kohta kõigest aru, kõik saavad kõigest aru ja on harjunud DevOpsi insenere kutsuma DevOpsi inseneriks, seda me ei aruta. Kõik need 40 hämmastavat DevOpsi inseneri seisavad iga päev silmitsi probleemidega ja lahendavad neid, me lihtsalt analüüsime seda kogemust ja proovime üldistada. Mõistame, et kui see jääb meie sisse, siis aasta-kahe pärast on tööriist kasutu, sest kuskil kogukonnas ilmub valmis Tula. Seda kogemust pole mõtet sisemiselt koguda – see lihtsalt tõmbab energiat ja aega dev/null-i. Ja meil pole sellest üldse kahju. Avaldame kõike suure rõõmuga ja mõistame, et seda tuleb avaldada, arendada, reklaamida, reklaamida, et inimesed seda kasutaksid ja oma kogemusi lisaksid – siis kõik kasvab ja elab. Siis kahe aasta pärast pill prügikasti ei lähe. Pole kahju jätkata tugevuse valamist, sest on selge, et keegi kasutab teie tööriista ja kahe aasta pärast kasutavad seda kõik.
See on osa meie suurest strateegiast dapp/werfiga. Ma ei mäleta, millal me seda tegema hakkasime, tundub nagu 3 aastat tagasi. Algselt oli see üldiselt kesta peal. See oli kontseptsiooni suurepärane tõestus, lahendasime mõned meie konkreetsed probleemid – see töötas! Kuid shellis on probleeme, seda pole võimalik edasi laiendada, kestal programmeerimine on teine ülesanne. Meil oli kombeks kirjutada Ruby keeles, vastavalt sellele tegime midagi Ruby keeles ümber, arendasime, arendasime, arendasime ja sattusime tõsiasjaga, et kogukond, rahvahulk, kes ei ütle "me tahame seda või me ei taha, ” keerab Rubyle nina püsti, kui naljakas see on? Saime aru, et peaksime kõik need asjad Go-sse kirjutama, et täita kontrollnimekirja esimest punkti: DevOpsi tööriist peaks olema staatiline kahendfail. Kas olla Go või mitte, pole nii oluline, kuid Go-s kirjutatud staatiline binaar on parem.
Kulutasime oma energiat, kirjutasime Go-s dappi ümber ja nimetasime selle werfiks. Dappi ei toetata enam, seda ei arendata, see töötab mõnes uusimas versioonis, kuid tippu on absoluutne täiendustee ja saate seda jälgida.
Miks dapp loodi?
— Kas saate lühidalt öelda, miks dapp loodi, milliseid probleeme see lahendab?
Dmitri: Esimene põhjus on koost. Esialgu oli meil ehitamisega tõsiseid probleeme, kui Dockeril polnud mitmeastmelise võimekust, nii et tegime mitmeastmelise iseseisva. Siis oli meil pildi puhastamisega veel hunnik probleeme. Kõik, kes CI/CD-d teevad, seisavad pigem varem kui hiljem silmitsi probleemiga, et kogutud pilte on hunnik, vajaminev tuleb kuidagi ära koristada ja vajaminev jätta.
Teine põhjus on juurutamine. Jah, Helm on olemas, kuid see lahendab vaid mõned probleemid. Naljakalt on kirjutatud, et "Helm on Kubernetese paketihaldur." Täpselt see, mis "the". Seal on ka sõnad “Pakihaldur” – mida tavaliselt paketihaldurilt oodatakse? Me ütleme: "Pakihaldur - installige pakett!" ja me eeldame, et ta ütleb meile: "Pakk on kohale toimetatud."
Huvitav on see, et me ütleme: "Helm, installige pakett" ja kui ta vastab, et installis, selgub, et ta just alustas installimist - ta märkis Kubernetesile: "Käivita see asi!" Ja kas see algas või mitte. , kas see töötab või mitte, Helm ei lahenda seda probleemi üldse.
Selgub, et Helm on lihtsalt teksti eeltöötleja, mis laadib andmed Kubernetesesse.
Kuid mis tahes juurutamise osana tahame teada, kas rakendus on tootmiseks välja antud või mitte? Tootmisversioonis avaldamine tähendab, et rakendus on sinna kolinud, uus versioon on juurutatud ja vähemalt ei jookse see seal kokku ja reageerib õigesti. Helm ei lahenda seda probleemi kuidagi. Selle lahendamiseks peate palju vaeva nägema, sest peate andma Kubernetesile käsu välja rullida ja jälgida, mis seal toimub - kas see on juurutatud või välja lastud. Samuti on palju juurutamise, puhastamise ja kokkupanemisega seotud ülesandeid.
Plaanid
Sel aastal alustame kohaliku arenguga. Tahame saavutada seda, mis oli varem Vagrantis – sisestasime “vagrant up” ja juurutasime virtuaalsed masinad. Tahame jõuda selleni, et Gitis on projekt, kirjutame sinna “werf up” ja see avab selle projekti kohaliku koopia, mis on juurutatud kohalikus mini-Kubis ja kõik arendamiseks mugavad kataloogid on ühendatud. . Olenevalt arenduskeelest tehakse seda erinevalt, kuid siiski, et lokaalset arendust saaks mugavalt monteeritud failide all läbi viia.
Järgmine samm meie jaoks on investeerige arendajate mugavusse. Projekti kiireks kohalikuks juurutamiseks ühe tööriistaga arendage see välja, suruge see Giti ning see rullub olenevalt konveieritest ka lavale või testimisele ning seejärel kasutage tootmisse minemiseks sama tööriista. See ühtsus, ühtsus, infrastruktuuri taastoodetavus kohalikust keskkonnast müügini on meie jaoks väga oluline punkt. Kuid see pole veel werfis – me alles plaanime seda teha.
Kuid tee dapp/werfini on alati olnud sama, mis Kubernetese puhul alguses. Me puutusime kokku probleemidega, lahendasime need lahendustega – leidsime enda jaoks lahendused kesta ja kõige kohta. Seejärel prooviti neid lahendusi kuidagi sirgendada, üldistada ja koondada antud juhul kahendfailidesse, mida me lihtsalt jagame.
Kogu seda lugu saab analoogia abil vaadata ka muul viisil.
Kubernetes on mootoriga autoraam. Pole uksi, klaase, raadiot, jõulupuud – üldse mitte midagi. Ainult raam ja mootor. Ja seal on Helm - see on rool. Lahe - rool on, kuid vajate ka roolipolti, roolilatti, käigukasti ja rattaid ning ilma nendeta ei saa.
Werfi puhul on see veel üks Kubernetese komponent. Alles nüüd on näiteks werfi alfaversioonis Helm kompileeritud werfi sees, sest oleme ise tegemisest väsinud. Sellel on palju põhjuseid, ma räägin teile üksikasjalikult, miks me koostasime kogu tüüri koos werfi sees oleva tiisliga .
Nüüd on werf integreeritum komponent. Saame valmis rooliratta, roolipoldi - ma pole autodes eriti hea, kuid see on suur plokk, mis lahendab juba üsna laia valikut probleeme. Me ei pea ise kataloogi läbi vaatama, ühte osa teise jaoks valima, mõtlema, kuidas neid kokku keerata. Saame valmis kombaini, mis lahendab korraga suure hulga probleeme. Kuid selle sees on ehitatud samadest avatud lähtekoodiga komponentidest, monteerimiseks kasutab see endiselt Dockerit, mõne funktsiooni jaoks Helmi ja on veel mitmeid teeke. See on integreeritud tööriist laheda CI/CD kiireks ja mugavaks karbist väljavõtmiseks.
Kas Kubernetes on raske hooldada?
— Räägid kogemusest, et hakkasid kasutama Kubernetes, see on sulle raam, mootor ja et selle külge saab riputada palju erinevaid asju: kere, rool, pedaalide külge kruvid, istmed. Tekib küsimus – kui raske on teie jaoks Kubernetese tugi? Teil on palju kogemusi, kui palju aega ja ressursse kulutate Kubernetese toetamisele kõigest muust eraldatuna?
Dmitri: See on väga raske küsimus ja sellele vastamiseks peame mõistma, mis on tugi ja mida me Kuberneteselt tahame. Ehk saad paljastada?
— Minu teada ja nagu ma näen, tahavad paljud meeskonnad nüüd Kubernetest proovida. Igaüks rakendab end selle jaoks, paneb selle põlvili. Mul on tunne, et inimesed ei saa alati aru selle süsteemi keerukusest.
Dmitri: See on nii.
— Kui keeruline on Kubernetes nullist võtta ja paigaldada, et see oleks tootmisvalmis?
Dmitri: Kui raske on teie arvates südame siirdamine? Ma saan aru, et see on kompromiteeriv küsimus. Skalpelli kasutamine ja vea mitte tegemine polegi nii keeruline. Kui nad ütlevad teile, kus lõigata ja kus õmmelda, pole protseduur iseenesest keeruline. Aeg-ajalt on raske garanteerida, et kõik läheb korda.
Kubernetese installimine ja selle tööle panemine on lihtne: tibu! - installitud, paigaldusviise on palju. Aga mis saab siis, kui probleemid tekivad?
Alati tekivad küsimused – millega me pole veel arvestanud? Mida me pole veel teinud? Millised Linuxi kerneli parameetrid määrati valesti? Issand, kas me üldse mainisime neid?! Milliseid Kubernetese komponente oleme tarninud ja milliseid mitte? Tekib tuhandeid küsimusi ja neile vastamiseks tuleb selles valdkonnas veeta 15-20 aastat.
Mul on sellel teemal hiljutine näide, mis võib paljastada probleemi „Kas Kubernetes on raske hooldada?” tähenduse. Mõni aeg tagasi kaalusime tõsiselt, kas peaksime proovima Ciliumi Kubernetes võrgustikuna juurutada.
Lubage mul selgitada, mis on Cilium. Kubernetes on palju erinevaid võrgu alamsüsteemi rakendusi ja üks neist on väga lahe - Cilium. Mis on selle tähendus? Kernelis sai mõni aeg tagasi võimalikuks kirjutada kernelile konksud, mis ühel või teisel moel tungivad võrgu alamsüsteemi ja mitmetesse teistesse alamsüsteemidesse ning võimaldavad kernelis suurtest tükkidest mööda minna.
Linuxi tuumal on ajalooliselt IP-marsruut, ülefilter, sillad ja palju erinevaid vanu komponente, mis on 15, 20, 30 aastat vanad. Üldiselt nad töötavad, kõik on suurepärane, aga nüüd on nad konteinerid kuhjanud ja see näeb välja nagu 15-st tellisest koosnev torn üksteise otsas ja sa seisad selle peal ühel jalal - imelik tunne. See süsteem on ajalooliselt välja kujunenud paljude nüanssidega, nagu pimesool kehas. Mõnes olukorras on näiteks jõudlusprobleeme.
Seal on imeline BPF ja võimalus tuumale konksud kirjutada – poisid kirjutasid tuumale oma konksud. Pakett tuleb Linuxi kernelisse, nad võtavad selle kohe sisendist välja, töötlevad seda ise nii nagu peab ilma sildadeta, ilma TCP-ta, ilma IP-pinuta – ühesõnaga, minnes mööda kõigest, mis Linuxi tuumas on kirjutatud, ja seejärel sülitada see konteinerisse välja.
Mis juhtus? Väga lahe jõudlus, lahedad funktsioonid – lihtsalt lahe! Kuid me vaatame seda ja näeme, et igas masinas on programm, mis loob ühenduse Kubernetes API-ga ja genereerib sellelt API-lt saadud andmete põhjal C-koodi ja kompileerib binaarfaile, mida see kernelisse laadib, et need konksud töötaksid. tuuma ruumis .
Mis juhtub, kui midagi läheb valesti? Me ei tea. Selle mõistmiseks peate lugema kogu selle koodi, mõistma kogu loogikat ja on hämmastav, kui raske see on. Kuid teisest küljest on need sillad, võrgufiltrid, IP-marsruut – ma pole nende lähtekoodi lugenud ega ka meie ettevõttes töötavad 40 inseneri. Võib-olla ainult vähesed saavad mõnest osast aru.
Ja mis vahet sellel on? Selgub, et on olemas ip rout, Linuxi tuum ja uus tööriist – mis vahet sellel on, me ei saa ühest ega teisest aru. Kuid me kardame midagi uut kasutada – miks? Sest kui tööriist on 30 aastat vana, siis 30 aastaga on kõik vead leitud, kõik vead peale astutud ja kõigest pole vaja teada - see töötab nagu must kast ja töötab alati. Igaüks teab, milline diagnostiline kruvikeeraja millisesse kohta torgata, milline tcpdump mis hetkel käivitada. Kõik teavad hästi diagnostikautiliite ja mõistavad, kuidas see komponentide komplekt Linuxi tuumas töötab – mitte kuidas see töötab, vaid kuidas seda kasutada.
Ja vingelt lahe Cilium pole 30 aastat vana, ta pole veel vananenud. Kubernetesel on sama probleem, kopeeri. Et Cilium on paigaldatud ideaalselt, et Kubernetes on paigaldatud ideaalselt, aga kui tootmises läheb midagi valesti, kas suudate kriitilises olukorras kiiresti aru saada, mis valesti läks?
Kui me ütleme, kas Kubernetese hooldamine on keeruline – ei, see on väga lihtne ja jah, see on uskumatult keeruline. Kubernetes töötab suurepäraselt iseseisvalt, kuid miljardi nüansiga.
Lähenemisviisist "Mul veab".
— Kas on ettevõtteid, kus nende nüansside ilmnemine on peaaegu garanteeritud? Oletame, et Yandex edastab kõik teenused ootamatult Kubernetesesse, seal on tohutu koormus.
Dmitri: Ei, see pole vestlus koormast, vaid kõige lihtsamatest asjadest. Meil on näiteks Kubernetes, juurutasime seal rakenduse. Kuidas sa tead, et see töötab? Lihtsalt pole valmis tööriista, mis mõistaks, et rakendus ei jookse kokku. Puudub valmis süsteem, mis hoiatusi saadaks; peate need hoiatused ja iga ajakava konfigureerima. Ja me värskendame Kubernetes.
Mul on Ubuntu 16.04. Võib öelda, et see on vana versioon, kuid oleme endiselt selle peal, sest see on LTS. Seal on systemd, mille nüanss on see, et see ei puhasta C-gruppe. Kubernetes käivitab kaustad, loob C-rühmad, seejärel kustutab kaustad ja millegipärast selgub - ma ei mäleta üksikasju, vabandust -, et süsteemsed lõigud jäävad alles. See toob kaasa asjaolu, et aja jooksul hakkab iga auto tugevalt aeglustuma. See pole isegi küsimus suure koormuse kohta. Kui käivitada püsivad podid, näiteks kui on Cron Job, mis pidevalt podeid genereerib, siis Ubuntu 16.04-ga masin hakkab nädala pärast aeglustuma. Pidevalt kõrge koormuse keskmine on tingitud sellest, et on tekkinud hunnik C-gruppe. See on probleem, millega seisavad silmitsi kõik inimesed, kes installivad lihtsalt Ubuntu 16 ja Kubernetese.
Oletame, et ta värskendab kuidagi systemd või midagi muud, kuid Linuxi tuumas kuni versioonini 4.16 on see veelgi naljakam – kui kustutate C-rühmad, lekivad need kernelisse ja neid tegelikult ei kustutata. Seetõttu on pärast kuu aega selle masina kallal töötamist võimatu kollete mälustatistikat vaadata. Võtame faili välja, veeretame programmis ja üks fail veereb 15 sekundit, sest kernel võtab enda sees miljoni C-rühma kokkulugemiseks väga kaua aega, mis justkui kustutatud, aga ei - lekivad .
Selliseid pisiasju on siin-seal ikka palju. See ei ole probleem, millega hiigelettevõtted mõnikord väga suure koormuse all kokku puutuvad – ei, see on igapäevaste asjade küsimus. Inimesed võivad niimoodi elada kuid – nad installisid Kubernetese, juurutasid rakenduse – tundub, et see töötab. Paljude inimeste jaoks on see normaalne. Nad isegi ei tea, et see rakendus mingil põhjusel jookseb kokku, nad ei saa hoiatust, kuid nende jaoks on see norm. Varem elasime ilma jälgimiseta virtuaalmasinates, nüüd kolisime Kubernetesse, samuti ilma jälgimiseta - mis vahet seal on?
Küsimus on selles, et jääl kõndides ei tea me kunagi selle paksust, kui me seda ette ei mõõda. Paljud inimesed kõnnivad ega muretse, sest nad on varem kõndinud.
Minu seisukohast on iga süsteemi toimimise nüanss ja keerukus tagada, et jää paksus on täpselt piisav meie probleemide lahendamiseks. Sellest me räägimegi.
Mulle tundub, et IT-valdkonnas on liiga palju lähenemisi "mul veab". Paljud inimesed installivad tarkvara ja kasutavad tarkvarateeke lootuses, et neil veab. Üldiselt on paljudel vedanud. Ilmselt sellepärast see ka töötab.
— Minu pessimistliku hinnangu järgi näeb see välja nii: kui riskid on suured ja rakendus peab töötama, siis on vaja tuge Flauntilt, võib-olla Red Hatilt või on vaja oma sisemist meeskonda, mis on pühendatud spetsiaalselt Kubernetesele ja mis on valmis. et see ära tõmmata.
Dmitri: Objektiivselt on see nii. Üksinda väikese meeskonna jaoks Kubernetese loosse sattumine hõlmab mitmeid riske.
Kas me vajame konteinereid?
— Kas oskate öelda, kui laialt levinud on Kubernetes Venemaal?
Dmitri: Mul ei ole neid andmeid ja ma pole kindel, et kellelgi teisel on. Me ütleme: "Kubernetes, Kubernetes", kuid sellele probleemile on veel üks viis. Ma ei tea ka, kui laialt levinud on konteinerid, kuid tean Interneti-aruannetest arvu, et 70% konteineritest on Kubernetesi orkestreeritud. See oli usaldusväärne allikas üsna suurele valimile kogu maailmas.
Siis teine küsimus – kas meil on konteinereid vaja? Minu isiklik tunne ja Flanti ettevõtte üldine seisukoht on, et Kubernetes on de facto standard.
Ei tule midagi peale Kubernetes.
See on infrastruktuuri haldamise valdkonnas absoluutne muutus. Lihtsalt absoluutne – see on kõik, pole enam Ansible, Chef, virtuaalsed masinad, Terraform. Ma ei räägi vanadest kolhoosimeetoditest. Kubernetes on absoluutne muutja, ja nüüd on see ainult nii.
On selge, et mõnel kulub selle mõistmiseks paar aastat, teisel paarkümmend aastat. Ma ei kahtle, et peale Kubernetese ja selle uue välimuse ei tule midagi muud: me ei kahjusta enam operatsioonisüsteemi, vaid kasutame infrastruktuur koodina, ainult mitte koodiga, vaid yml-ga – deklaratiivselt kirjeldatud taristu. Mul on tunne, et see jääb alati nii.
— See tähendab, et need ettevõtted, kes pole veel Kubernetesele üle läinud, lähevad sellele kindlasti üle või jäävad unustuse hõlma. ma sain sinust õigesti aru?
Dmitri: Ka see pole päris tõsi. Näiteks kui meie ülesandeks on DNS-serveri käitamine, siis saab seda käivitada FreeBSD 4.10 peal ja see võib töötada ideaalselt 20 aastat. Lihtsalt tööta ja ongi kõik. Võib-olla tuleb 20 aasta pärast ükskord midagi uuendada. Kui me räägime tarkvarast selles vormingus, mille me käivitasime ja see töötab tegelikult palju aastaid ilma värskendusteta, muudatusi tegemata, siis loomulikult Kubernetest ei tule. Teda pole seal vaja.
Kõik, mis on seotud CI/CD-ga - kõikjal, kus on vaja pidevat tarnimist, kus on vaja värskendada versioone, teha aktiivseid muudatusi, kus iganes on vaja luua veataluvus - ainult Kubernetes.
Mikroteenustest
- Siin on mul kerge dissonants. Kubernetesiga töötamiseks vajate välist või sisemist tuge - see on esimene punkt. Teiseks, kui me alles alustame arendust, oleme väike startup, meil pole veel midagi, Kubernetese või laiemalt mikroteenuste arhitektuuri arendamine võib olla keeruline ja mitte alati majanduslikult põhjendatud. Mind huvitab teie arvamus - kas idufirmad peavad Kubernetese jaoks kohe nullist kirjutama hakkama või võivad nad ikkagi kirjutada monoliiti ja alles siis Kubernetese juurde tulla?
Dmitri: Lahe küsimus. Ma räägin mikroteenustest Olen korduvalt kohanud inimesi, kes üritavad mikroskoobiga naelu lüüa. Lähenemine iseenesest on õige, me ise kujundame oma sisemise tarkvara nii. Kuid kui teete seda, peate selgelt aru saama, mida teete. Sõna, mida ma mikroteenuste juures kõige rohkem vihkan, on "mikro". Ajalooliselt on see sõna sealt alguse saanud ja millegipärast arvatakse, et mikro on väga väike, alla millimeetri, nagu mikromeeter. See on vale.
Näiteks on monoliit, mida kirjutavad 300 inimest ja kõik, kes arenduses osalesid, saavad aru, et seal on probleeme ja see tuleks jagada mikrotükkideks - umbes 10 tükki, millest igaüks on kirjutatud 30 inimese poolt. minimaalses versioonis. See on oluline, vajalik ja lahe. Aga kui meie juurde tuleb startup, kus 3 väga lahedat ja andekat kutti kirjutasid põlvili 60 mikroteenust, otsin iga kord Corvaloli.
Mulle tundub, et sellest on juba tuhandeid kordi räägitud - saime ühel või teisel kujul hajutatud monoliidi. See ei ole majanduslikult põhjendatud, see on üldiselt kõiges väga raske. Olen seda just nii palju kordi näinud, et see teeb mulle väga haiget, nii et ma jätkan sellest rääkimist.
Esialgsele küsimusele on vastuolu selles, et ühest küljest on Kubernetes hirmus kasutada, sest pole selge, mis seal võib puruneda või mitte töötada, teisalt on selge, et kõik läheb sinna ja ei eksisteeri muud kui Kubernetes. Vastus - kaaluge saadava kasu suurust, ülesannete hulka, mida saate lahendada. See on skaala ühel küljel. Teisest küljest on riske seotud seisakutega või reageerimisaja, kättesaadavuse taseme vähenemisega - tulemusnäitajate vähenemisega.
Siin see on – kas liigume kiiresti ja Kubernetes võimaldab meil paljusid asju palju kiiremini ja paremini teha või kasutame töökindlaid, ajaproovitud lahendusi, kuid liigume palju aeglasemalt. See on valik, mida iga ettevõte peab tegema. Võid mõelda sellest kui teest džunglis – esimest korda kõndides võid kohata madu, tiigrit või hullu mägra ja kui oled 10 korda kõndinud, siis oled teed tallanud, eemaldunud. oksad ja kõndida kergemini. Iga korraga läheb tee laiemaks. Siis on see asfalttee ja hiljem ilus puiestee.
Kubernetes ei seisa paigal. Küsimus uuesti: Kubernetes on ühelt poolt 4-5 binaarist, teiselt poolt on see kogu ökosüsteem. See on operatsioonisüsteem, mis meie masinates on. Mis see on? Ubuntu või Curios? See on Linuxi tuum, hunnik lisakomponente. Kõik need asjad siin, üks mürkmadu visati teelt välja, sinna püstitati tara. Kubernetes areneb väga kiiresti ja dünaamiliselt ning riskide maht, tundmatu maht väheneb iga kuuga ning vastavalt sellele ka need mastaabid tasakaalustuvad.
Vastates küsimusele, mida startup peaks tegema, ütleksin - tulge Flaunti, makske 150 tuhat rubla ja hankige DevOpsi võtmed kätte lihtne teenus. Kui olete mõne arendajaga väike idufirma, siis see toimib. Selle asemel, et palgata oma DevOpsi, kes peavad õppima, kuidas teie probleeme lahendada ja praegu palka maksta, saate kõikidele probleemidele võtmed kätte lahenduse. Jah, on mõned miinused. Meie kui sisseostja ei saa olla nii kaasatud ja muutustele kiiresti reageerida. Kuid meil on palju teadmisi ja valmis praktikaid. Garanteerime, et igas olukorras saame selle kindlasti kiiresti selgeks ja äratame iga Kubernete surnuist üles.
Soovitan tungivalt teha sisseostmist alustavatele ja väljakujunenud ettevõtetele kuni suuruseni, kus saab 10-liikmelise meeskonna tegevusele pühendada, sest muidu pole mõtet. See on kindlasti mõttekas allhanke korras hankida.
Amazoni ja Google'i kohta
— Kas Amazoni või Google'i lahendusest pärit hosti võib pidada allhankeks?
Dmitri: Jah, muidugi, see lahendab mitmed probleemid. Kuid jällegi on nüansse. Peate ikkagi aru saama, kuidas seda kasutada. Näiteks Amazon AWS-i töös on tuhat pisiasja: Load Balancer tuleb soojendada või tuleb eelnevalt kirjutada soov, et "kutid, me võtame liikluse vastu, soojendage meie jaoks Load Balancer!" Peate teadma neid nüansse.
Kui pöördute sellele spetsialiseerunud inimeste poole, saate peaaegu kõik tüüpilised asjad suletud. Meil on praegu 40 inseneri, aasta lõpuks on arvatavasti 60 - kõigi nende asjadega oleme kindlasti kokku puutunud. Isegi kui me mõne projekti puhul selle probleemiga uuesti kokku puutume, küsime kiiresti üksteiselt ja teame, kuidas seda lahendada.
Tõenäoliselt on vastus – loomulikult teeb hostitud lugu mõne osa lihtsamaks. Küsimus on selles, kas olete valmis neid majutajaid usaldama ja kas nad lahendavad teie probleemid. Amazonil ja Google'il on hästi läinud. Kõigil meie juhtudel – täpselt. Meil pole rohkem positiivseid kogemusi. Kõik muud pilved, millega proovisime töötada, tekitavad palju probleeme - Ager ja kõik, mis on Venemaal, ja kõikvõimalikud OpenStackid erinevates rakendustes: Headster, Overage - mida iganes soovite. Kõik need tekitavad probleeme, mida te ei soovi lahendada.
Seetõttu on vastus jah, kuid tegelikult pole küpseid hostitud lahendusi väga palju.
Kes vajab Kubernetes?
— Ja veel, kes vajab Kubernetest? Kes peaks juba Kubernetesele üle minema, kes on tüüpiline Flaunti klient, kes tuleb spetsiaalselt Kubernetese jaoks?
Dmitri: See on huvitav küsimus, sest just praegu, Kubernetese kiiluvees, tulevad paljud inimesed meie juurde: "Poisid, me teame, et teete Kubernetes, tehke seda meie heaks!" Vastame neile: "Härrased, me ei tee Kubernetest, vaid prod ja kõike sellega seonduvat." Sest praegu on lihtsalt võimatu toodet teha ilma kogu CI/CD-d ja kogu seda lugu tegemata. Kõik on eemaldunud jaotusest, et meil on areng arendamise teel ja seejärel ekspluateerimine ekspluateerimise teel.
Meie kliendid ootavad erinevaid asju, kuid kõik ootavad mõnda head imet, et tal on mingid probleemid ja nüüd - hops! — Kubernetes lahendab need. Inimesed usuvad imedesse. Mõttes saavad nad aru, et imet ei tule, aga hinges loodavad - mis siis, et see Kubernetes nüüd meie eest kõik ära lahendab, sellest räägitakse nii palju! Järsku ta nüüd – aevastama! - ja hõbekuul, aevastage! – ja meil on 100% tööaeg, kõik arendajad saavad 50 korda välja anda kõik, mis tootmisse jõuab, ja see ei jookse kokku. Üldiselt ime!
Kui sellised inimesed meie juurde tulevad, ütleme: "Vabandust, aga sellist asja nagu ime pole olemas." Et olla terve, tuleb korralikult süüa ja trenni teha. Usaldusväärse toote saamiseks tuleb see usaldusväärselt valmistada. Mugava CI/CD saamiseks peate selle selliseks tegema. See on palju tööd, mis tuleb ära teha.
Vastates küsimusele, kellele Kubernetes on vaja – Kubernetes pole kellelegi vaja.
Mõnel inimesel on eksiarvamus, et nad vajavad Kubernetest. Inimesed vajavad, neil on sügav vajadus lõpetada mõtlemine, õppimine ja huvi tundmine kõigi infrastruktuuri ja rakenduste käitamise probleemide vastu. Nad tahavad, et rakendused lihtsalt töötaksid ja lihtsalt juurutaksid. Nende jaoks on Kubernetes lootus, et nad ei kuule enam juttu, et "me lamasime seal" või "me ei saa välja veereda" või midagi muud.
Tavaliselt tuleb meie juurde tehniline direktor. Nad küsivad temalt kahte asja: ühest küljest andke meile tunnuseid, teiselt poolt stabiilsust. Soovitame teil selle enda peale võtta ja teha. Hõbekuul või õigemini hõbetatud on see, et te lõpetate nendele probleemidele mõtlemise ja aja raiskamise. Teil on erilised inimesed, kes selle teema sulgevad.
Sõnastus, et meil või kellelgi teisel on Kubernetest vaja, on vale.
Administraatorid vajavad Kubernetest väga, sest see on väga huvitav mänguasi, millega saab mängida ja nokitseda. Olgem ausad – mänguasju armastavad kõik. Me kõik oleme kuskil lapsed ja kui näeme uut, tahame seda mängida. Mõne jaoks on see heidutatud näiteks administratsioonis, sest nad on juba piisavalt mänginud ja on juba nii väsinud, et nad lihtsalt ei taha. Kuid see pole kellelegi täielikult kadunud. Näiteks kui olen juba ammu tüdinud mänguasjadest süsteemihalduse ja DevOpsi vallas, siis mänguasjad mulle ikka meeldivad, ikka ostan mõned uued. Kõik inimesed tahavad nii või teisiti ikka mingeid mänguasju.
Tootmisega pole vaja mängida. Mida iganes soovitan kategooriliselt mitte teha ja mida ma nüüd massiliselt näen: "Oh, uus mänguasi!" - nad jooksid seda ostma, ostsid ja: "Viime selle kohe kooli ja näitame seda kõigile oma sõpradele." Ära tee seda. Vabandan, mu lapsed alles kasvavad, ma näen lastes pidevalt midagi, märkan seda endas ja siis üldistan seda teistele.
Lõplik vastus on: te ei vaja Kubernetes. Peate oma probleemid lahendama.
Mida saate saavutada, on:
- prod ei lange;
- isegi kui ta üritab kukkuda, teame sellest ette ja saame sinna midagi sisse panna;
- saame seda muuta kiirusega, millega meie äri seda nõuab, ja saame seda teha mugavalt; see ei tekita meile probleeme.
On kaks tegelikku vajadust: töökindlus ja kasutuselevõtu dünaamilisus/paindlikkus. Need vajadused peavad lahendama kõik, kes parajasti teevad mingeid IT-projekte, ükskõik mis äris - maailma kergendamiseks pehmed ja sellest aru saavad. Õige lähenemise, õige arusaamise ja piisava kogemusega Kubernetes võimaldab neid lahendada.
Umbes serverita
— Kui vaadata veidi kaugemasse tulevikku, siis proovides peavalu puudumise probleemi infrastruktuuriga lahendada, koos juurutamise ja rakenduste muutumise kiirusega ilmuvad uued lahendused, näiteks serverita. Kas tunnete selles suunas potentsiaali ja, ütleme, ohtu Kubernetesele jms lahendustele?
Dmitri: Siin tuleb jälle teha märkus, et ma ei ole nägija, kes vaatab ette ja ütleb - saab nii! Kuigi ma just tegin sama asja. Vaatan oma jalgu ja näen seal hunnikut probleeme, näiteks kuidas arvutis transistorid töötavad. See on naljakas, eks? Meil on protsessoris mõned vead.
Muutke serverita üsna usaldusväärseks, odavaks, tõhusaks ja mugavaks, lahendades kõik ökosüsteemi probleemid. Siin nõustun Elon Muskiga, et inimkonna veataluvuse loomiseks on vaja teist planeeti. Kuigi ma ei tea, mida ta ütleb, saan ma aru, et ma ei ole valmis ise Marsile lendama ja seda ei juhtu ka homme.
Serverita on selgelt selge, et see on ideoloogiliselt õige asi, nagu inimkonna veataluvus – parem omada kahte planeeti kui üks. Aga kuidas seda nüüd teha? Ühe ekspeditsiooni saatmine pole probleem, kui keskendute sellele. Mitme ekspeditsiooni saatmine ja mitme tuhande inimese sinna elama asumine, ma arvan, on samuti reaalne. Aga teha see täiesti veataluvuseks nii, et pool inimkonnast seal elaks, tundub mulle praegu võimatu, mitte mõelda.
Serverita üks ühele: asi on lahe, kuid 2019. aasta probleemidest on asi kaugel. Aastale 2030 lähemal – elame, et seda näha. Ma ei kahtle, et elame, kindlasti elame (korda enne magamaminekut), aga nüüd on vaja muid probleeme lahendada. See on nagu muinasjutulist poni Vikerkaar uskumine. Jah, paar protsenti juhtudest laheneb ja need lahenevad suurepäraselt, aga subjektiivselt on serverita vikerkaar... Minu jaoks on see teema liiga kauge ja liiga arusaamatu. Ma ei ole valmis rääkima. 2019. aastal ei saa serverita kirjutada ühtegi rakendust.
Kuidas Kubernetes areneb
— Kui me liigume selle potentsiaalselt imelise kauge tuleviku poole, kuidas teie arvates Kubernetes ja seda ümbritsev ökosüsteem areneb?
Dmitri: Olen sellele palju mõelnud ja mul on selge vastus. Esimene on statefull – kodakondsuseta on ju lihtsam teha. Kubernetes investeeris alguses sellesse rohkem, kõik algas sellest. Stateless töötab Kubernetes peaaegu ideaalselt, pole lihtsalt midagi ette heita. Probleeme, õigemini nüansse on ikka palju. Kõik seal juba toimib meie jaoks suurepäraselt, kuid need oleme meie. See võtab veel vähemalt paar aastat, et see kõigi jaoks toimiks. See pole kalkuleeritud näitaja, vaid minu tunnetus peast.
Lühidalt öeldes peaks Statefull arenema ja arenema väga tugevalt, sest kõik meie rakendused salvestavad oleku; olekuta rakendusi pole olemas. See on illusioon; alati on vaja mingit andmebaasi ja midagi muud. Statefull seisneb kõige võimaliku väljakujundamises, kõigi vigade parandamises, kõigi praegu esinevate probleemide parandamises – nimetagem seda omaksvõtuks.
Tundmatu tase, lahendamata probleemide tase, millegagi kokku puutumise tõenäosus langeb oluliselt. See on oluline lugu. Ja operaatorid - kõik, mis on seotud haldusloogika kodifitseerimisega, juhtimisloogikaga, et saada lihtsat teenust: MySQL lihtne teenus, RabbitMQ lihtne teenus, Memcache lihtne teenus - üldiselt kõik need komponendid, mille väljatöötamine peab olema garanteeritud kast. See lihtsalt lahendab valu, et me tahame andmebaasi, kuid me ei taha seda hallata või me tahame Kubernetest, kuid me ei taha seda hallata.
See operaatorite arendamise lugu ühel või teisel kujul on järgmise paari aasta jooksul oluline.
Arvan, et kasutusmugavus peaks kõvasti tõusma - karp muutub aina mustamaks, töökindlamaks, järjest rohkemate lihtsate nuppudega.
Kuulasin kunagi Youtube'i vahendusel Saturday Night Live'ist vana intervjuu Isaac Asimoviga 80ndatest – selline saade nagu Urgant, ainult huvitav. Nad küsisid temalt arvutite tuleviku kohta. Ta ütles, et tulevik on lihtsuses, nagu raadios. Raadiovastuvõtja oli algselt keeruline asi. Laine püüdmiseks tuli 15 minutit nuppe keerata, vardasid keerata ja üldiselt teada, kuidas kõik töötab, raadiolainete edastamise füüsikast aru saada. Selle tulemusena jäi raadiosse ainult üks nupp.
Mis raadio nüüd aastal 2019? Autos leiab raadiovastuvõtja kõik lained ja jaamade nimed. Protsessi füüsika pole 100 aastaga muutunud, küll aga kasutusmugavus. Nüüd ja mitte ainult praegu, juba 1980. aastal, kui oli intervjuu Azimoviga, kasutasid kõik raadiot ja keegi ei mõelnud, kuidas see töötab. Alati töötas – see on antud.
Azimov ütles siis, et sama oleks arvutitega - kasutusmugavus suureneb. Kui 1980. aastal tuli õpetada arvutis nuppe vajutama, siis tulevikus see enam nii ei ole.
Mul on tunne, et Kubernetese ja infrastruktuuriga kaasneb ka kasutusmugavuse tohutu kasv. See on minu arvates ilmne - see on pinnal.
Mida teha inseneridega?
— Mis saab siis Kubernetest toetavatest inseneridest ja süsteemiadministraatoritest?
Dmitri: Mis juhtus raamatupidajaga pärast 1C tulekut? Umbes sama. Enne seda arvestasid nad paberil – nüüd programmis. Tööviljakus on küll suurusjärgu võrra tõusnud, kuid tööjõud ise pole kuhugi kadunud. Kui varem kulus lambipirni kruvimiseks 10 inseneri, siis nüüd piisab ühest.
Mulle tundub, et tarkvara hulk ja ülesannete arv kasvab praegu kiiremini kui uued DevOpid ilmuvad ja tõhusus suureneb. Praegu on turul konkreetne defitsiit ja see kestab kaua. Hiljem naaseb kõik mingisse normaalsusesse, mille puhul töö efektiivsus tõuseb, serverita on aina rohkem, Kubernetese külge kinnitatakse neuron, mis valib kõik ressursid täpselt nii nagu vaja ja üldiselt hakkab tee kõike ise, nagu peab – inimene astub lihtsalt eemale ja ära sekku.
Kuid keegi peab ikkagi otsuseid langetama. On selge, et selle inimese kvalifikatsioonitase ja spetsialiseerumine on kõrgem. Tänapäeval pole raamatupidamises vaja 10 töötajat raamatuid pidama, et käed ära ei väsiks. See pole lihtsalt vajalik. Paljud dokumendid skannitakse ja tuvastatakse automaatselt elektroonilise dokumendihaldussüsteemiga. Piisab ühest targast pearaamatupidajast, juba palju suuremate oskustega, hea arusaamisega.
Üldiselt on see tee kõigis tööstusharudes. Autodega on sama lugu: varem oli autoga kaasas mehaanik ja kolm juhti. Tänapäeval on autojuhtimine lihtne protsess, milles me kõik iga päev osaleme. Keegi ei arva, et auto on midagi keerulist.
DevOps ehk süsteemitehnika ei kao kuhugi – kõrgel tasemel töö ja efektiivsus tõuseb.
— Kuulsin ka huvitavat mõtet, et töö reaalselt suureneb.
Dmitri: Muidugi, sada protsenti! Sest meie kirjutatava tarkvara hulk kasvab pidevalt. Tarkvaraga lahendatavate probleemide arv kasvab pidevalt. Tööde hulk kasvab. Nüüd on DevOpsi turg kohutavalt ülekuumenenud. Seda on näha palgaootustes. Heas mõttes, detailidesse laskumata, peaks olema juuniorid, kes tahavad X-i, keskmised, kes tahavad 1,5X, ja seeniorid, kes tahavad 2X-i. Ja kui nüüd vaadata Moskva DevOpsi palgaturgu, siis juunior tahab X-lt 3X-ni ja seenior X-lt 3X-ni.
Keegi ei tea, kui palju see maksab. Palgataset mõõdetakse sinu enesekindlusega – täielik hullumaja, ausalt öeldes kohutavalt ülekuumenenud turg.
Muidugi muutub see olukord väga kiiresti - peaks tekkima mõningane küllastumine. Tarkvaraarenduse puhul see nii ei ole – vaatamata sellele, et kõigil on vaja arendajaid ja kõik vajavad häid arendajaid, saab turg aru, kes on mida väärt –, tööstus on paika loksunud. Tänapäeval DevOpsi puhul see nii ei ole.
— Kuuldu põhjal jõudsin järeldusele, et praegune süsteemiadministraator ei peaks liigselt muretsema, vaid on aeg oma oskusi täiendada ja valmistuda selleks, et homme on tööd rohkem, aga see on kõrgema kvalifikatsiooniga.
Dmitri: Sada protsenti. Üldiselt elame 2019. aastal ja elu reegel on järgmine: elukestev õpe – õpime kogu elu. Mulle tundub, et nüüd teavad ja tunnevad seda kõik juba, kuid teadmisest ei piisa - sa pead seda tegema. Iga päev peame muutuma. Kui me seda ei tee, siis varem või hiljem kukume selle eriala kõrvale.
Olge valmis järskudeks 180-kraadisteks pööreteks. Ma ei välista olukorda, kus midagi radikaalselt muutub, leiutatakse midagi uut – see juhtub. Hop! - ja me tegutseme nüüd teisiti. Oluline on olla selleks valmis ja mitte muretseda. Võib juhtuda, et homme osutub kõik, mida teen, mittevajalikuks – ei midagi, olen terve elu õppinud ja valmis midagi muud õppima. See pole probleem. Töökindlust pole vaja karta, küll aga tuleb olla valmis pidevalt midagi uut õppima.
Soovid ja minut reklaami
- Kas teil on soov?
Dmitri: Jah, mul on mitu soovi.
Esimene ja kaubanduslik - tellige . Head lugejad, minge YouTube'i ja tellige meie kanal. Umbes kuu aja pärast alustame videoteenuse aktiivset laienemist. Meil on Kubernetese kohta palju harivat sisu, avatud ja mitmekülgset: praktilistest asjadest laboriteni, sügavate fundamentaalsete teoreetiliste asjadeni ja Kubernetese kasutamiseni. põhimõtete ja mustrite tase.
Teine merkantiilne soov – mine ja paneme tähed, sest me toitume neist. Kui te meile tähti ei anna, pole meil midagi süüa. See on nagu mana arvutimängus. Teeme midagi, teeme, proovime, keegi ütleb, et need on kohutavad jalgrattad, keegi, et kõik on täiesti valesti, aga me jätkame ja tegutseme täiesti ausalt. Näeme probleemi, lahendame selle ja jagame oma kogemusi. Seetõttu kingi meile täht, see ei kao sinust, vaid tuleb meile, sest me toitume neist.
Kolmandaks, oluline ja mitte enam merkantiilne soov - lõpetage muinasjutte uskumine. Te olete professionaalid. DevOps on väga tõsine ja vastutustundlik elukutse. Lõpetage töökohal mängimine. Laske sellel enda eest klõpsata ja saate sellest aru. Kujutage ette, et tulete haiglasse ja seal teeb arst teiega katseid. Ma saan aru, et see võib kellegi jaoks solvav olla, kuid tõenäoliselt pole see sinu, vaid kellegi teise kohta. Ütle ka teistele, et nad lõpetaksid. See rikub tõesti meie kõigi elu – paljud hakkavad kohtlema operaatoreid, administraatoreid ja arendajaid kui kutte, kes on jälle midagi rikkunud. See oli kõige sagedamini "katki" tänu sellele, et käisime mängimas, mitte ei vaadanud külma teadvusega, mis siin ja mis siin on.
See ei tähenda, et te ei peaks katsetama. Me peame katsetama, me teeme seda ise. Kui aus olla, siis me ise mängime vahel mänge – see on muidugi väga halb, aga miski inimlik pole meile võõras. Kuulutagem 2019. aasta tõsiste, läbimõeldud eksperimentide, mitte tootmismängude aastaks. Ilmselt nii.
- Tänan teid väga!
Dmitri: Aitäh, Vitali, nii aja kui ka intervjuu eest. Head lugejad, tänan teid väga, kui olete ootamatult selleni jõudnud. Loodan, et tõime teieni vähemalt paar mõtet.
Dmitri puudutas intervjuus werfi küsimust. Nüüd on see universaalne Šveitsi nuga, mis lahendab peaaegu kõik probleemid. Kuid see ei olnud alati nii. Peal festivalidele Dmitri Stolyarov räägib teile selle tööriista kohta üksikasjalikult. aruandes seal on kõike: Kubernetese probleemid ja varjatud nüansid, võimalused nende raskuste lahendamiseks ja werfi praegune rakendamine üksikasjalikult. Liituge meiega 27. ja 28. mail, loome ideaalsed tööriistad.
Allikas: www.habr.com