Eelmisel nädalal käisin Jekaterinburgis DUMP IT konverentsil (https://dump-ekb.ru/) ja tahan teile rääkida, mida arutati Backendi ja Devopsi rubriikides ning kas piirkondlikud IT-konverentsid väärivad tähelepanu.
Nikolai Sverchkov filmist Kurjad marslased serveriteta
Mis seal ikkagi oli?
Kokku oli konverentsil 8 sektsiooni: Backend, Frontend, Mobile, Testing and QA, Devops, Design, Science and Management.
Suurimad saalid, muide, on Science and Managementis)) Igaüks ~350 inimesele. Backend ja Frontend pole palju väiksemad. Devopsi tuba oli väikseim, kuid aktiivne.
Kuulasin Devopsi ja Backendi sektsioonide aruandeid ja rääkisin veidi esinejatega. Tahaksin konverentsil käsitletavatest teemadest rääkida ja need lõigud üle vaadata.
Devopsi ja taustaprogrammi rubriikides esinesid SKB-Konturi, DataArti, Evil Martiansi, Jekaterinburgi veebistuudio Flag, Miro (RealTimeBoard) esindajad. Teemad hõlmasid CI/CD-d, järjekorrateenustega töötamist, logimist; Serverita teemad ja PostgreSQL-iga töötamine Go-s olid hästi käsitletud.
Samuti olid aruanded Avito, Tinkoff, Yandex, Jetstyle, Megafon, Ak Bars Bank, kuid mul ei olnud aega nendega füüsiliselt kohal olla (aruannete videosalvestused ja slaidid pole veel saadaval, nad lubavad need postitada 2 nädala jooksul saidil dump-ekb.ru).
Devopsi jaotis
Üllatav oli see, et sektsioon peeti kõige väiksemas, umbes 50-kohalises saalis. Inimesed seisid isegi vahekäikudes :) Ma räägin teile reportaažidest, mida mul õnnestus kuulata.
Petabaiti kaaluv elastne
Rubriik algas Vladimir Lili (SKB-Kontur) ettekandega Elasticsearchist Konturis. Neil on üsna suur ja koormatud Elastic (~800 TB andmemahtu, ~1.3 petabaiti arvestades koondamist). Kõigi Konturi teenuste jaoks mõeldud Elasticsearch on üksik, koosneb 2 klastrist (7 ja 9 serverist) ning on nii oluline, et Konturil on spetsiaalne Elasticsearchi insener (tegelikult Vladimir ise).
Vladimir jagas ka oma mõtteid Elasticsearchi eeliste ja sellega kaasnevate probleemide kohta.
Kasu:
- Kõik logid on ühes kohas, neile lihtne juurdepääs
- Palkide säilitamine aastaks ja nende lihtne analüüsimine
- Suur palkidega töötamise kiirus
- Lahe andmete visualiseerimine karbist välja
Probleemid:
- sõnumimaakler on must have (Konturi jaoks mängib selle rolli Kafka)
- Elasticsearch Curatoriga töötamise funktsioonid (kuraatoris tavapärastest ülesannetest perioodiliselt loodud suur koormus)
- sisseehitatud autoriseerimata (ainult eraldi, üsna suure raha eest või erineva tootmisvalmidusastmega avatud lähtekoodiga pistikprogrammidena)
Open Distro for Elasticsearch kohta olid ainult positiivsed arvustused :) Seal on sama volituste probleem lahendatud.
Kust petabait tuleb?Nende sõlmed koosnevad 12*8 Tb SATA + 2*2 Tb SSD-ga serveritest. Külmsalvestusruum SATA-l, SSD ainult kuuma vahemälu jaoks (kuum salvestusruum).
7+9 serverit, (7 + 9) * 12 * 8 = 1536 Tb.
Osa ruumist on reservis, koondamiseks eraldatud jne.
Elasticsearchi saadetakse logid umbes 90 taotlusest, sealhulgas kõik Konturi, Elba jne aruandlusteenused.
Serverlessi arendamise omadused
Järgmine on Ruslan Serkini aruanne DataArtist Serverlessi kohta.
Ruslan rääkis, mis on serverivaba lähenemisega arendus üldiselt ja millised on selle omadused.
Serverivaba on lähenemine arendusele, mille puhul arendajad ei puutu kuidagi infrastruktuuri. Näide – AWS Lambda Serverless, Kubeless.io (Serverless Kubernetes), Google'i pilvefunktsioonid.
Ideaalne serverita rakendus on lihtsalt funktsioon, mis saadab serverita teenusepakkujale päringu spetsiaalse API lüüsi kaudu. Ideaalne mikroteenus, samas kui AWS Lambda toetab ka suurt hulka kaasaegseid programmeerimiskeeli. Infrastruktuuri ülalpidamise ja juurutamise kulud muutuvad pilvepakkujate puhul nulliks, ka väikeste rakenduste toetamine on väga odav (AWS Lambda - 0.2 $ / 1 miljon lihtsat päringut).
Sellise süsteemi skaleeritavus on peaaegu ideaalne – pilvepakkuja hoolitseb selle eest ise, Kubeless skaleerib automaatselt Kubernetese klastri sees.
Puudused on:
- suurte rakenduste arendamine muutub keerulisemaks
- raskusi on rakenduste profileerimisega (teile on saadaval ainult logid, kuid tavamõistes profileerimine mitte)
- ei mingit versioonimist
Ausalt öeldes kuulsin Serverlessist paar aastat tagasi, kuid kõik need aastad polnud mulle selge, kuidas seda õigesti kasutada. Pärast Ruslani aruannet ilmnes mõistmine ja pärast Nikolai Sverchkovi (Kurjad marslased) aruannet Backendi sektsioonist see konsolideeriti. Ega ma asjata konverentsile ei läinud :)
CI on vaestele või tasub veebistuudio jaoks oma CI kirjutada?
Mihhail Radionov, Jekaterinburgi lipu veebistuudio juht, rääkis omakirjutatud CI/CD-st.
Tema stuudio on läinud "käsitsi CI/CD-lt" (logige serverisse SSH kaudu, tehke git-tõmme, korrake 100 korda päevas) Jenkinsile ja ise kirjutatud tööriistale, mis võimaldab teil jälgida koodi ja esitada Pullkinsi väljaandeid. .
Miks Jenkins ei töötanud? See ei pakkunud vaikimisi piisavalt paindlikkust ja seda oli liiga raske kohandada.
“Lipp” areneb Laravelis (PHP raamistik). CI/CD serveri arendamisel kasutasid Mihhail ja tema kolleegid Laraveli sisseehitatud mehhanisme nimega Telescope and Envoy. Tulemuseks on PHP-s server (pange tähele), mis töötleb sissetulevaid veebihaagi päringuid, saab luua esi- ja taustaprogrammi, juurutada erinevatesse serveritesse ja annab Slackile aru.
Seejärel lülitusid nad üle Dockerile, et saaksid teostada sinist/rohelist juurutamist ja omada ühtseid sätteid dev-stage-prod keskkondades. Eelised jäid samaks, lisandusid keskkonna homogeniseerimise ja sujuva juurutamise võimalused ning vajadus õppida Dockerit sellega õigesti töötama.
Kuidas vähendasime serveri väljalaske tagasipööramiste arvu 99%
Viimane aruanne Devopsi jaotises oli Viktor Eremchenkolt, Miro.com-i (endine RealTimeBoard) juhtiv devopsi insener.
RealTimeBoard, Miro meeskonna lipulaev, põhineb monoliitsel Java-rakendusel. Selle kogumine, testimine ja kasutuselevõtt ilma seisakuta on keeruline ülesanne. Sel juhul on oluline juurutada selline koodi versioon, et seda ei peaks tagasi kerima (see on raske monoliit).
Teel seda võimaldava süsteemi loomisel läbis Miro tee, mis hõlmas arhitektuuri, kasutatud tööriistade (Atlassian Bamboo, Ansible jne) kallal töötamist ja meeskondade struktuuri kallal töötamist (nüüd on neil pühendunud Devopsi meeskond + palju erinevaid Scrumi meeskondi erinevate profiilide arendajatelt).
Tee osutus raskeks ja okkaliseks ning Victor jagas kogunenud valu ja optimismi, mis sellega ei lõppenud.
Võitis küsimuste esitamise raamatu
Taustaprogrammi jaotis
Mul õnnestus osaleda 2 raportis - Nikolai Sverchkovilt (Kurjad marslased), samuti serverita ja Grigory Koshelev (ettevõte Kontur) telemeetria kohta.
Serverita lihtsurelike jaoks
Kui Ruslan Sirkin rääkis sellest, mis on Serverless, siis Nikolay näitas lihtsaid Serverlessi kasutavaid rakendusi ning rääkis üksikasjadest, mis mõjutavad AWS Lambda rakenduste maksumust ja kiirust.
Huvitav detail: minimaalne tasuline element on 128 Mb mälu ja 100 ms CPU, see maksab 0,000000208 $. Lisaks on 1 miljon sellist päringut kuus tasuta.
Mõned Nikolai funktsioonid ületasid sageli 100 ms piiri (peamine rakendus oli kirjutatud Ruby keeles), nii et nende Go-s ümberkirjutamine andis suurepärase säästu.
Vostok Hercules – muutke telemeetria taas suurepäraseks!
Grigory Koshelev (ettevõte Kontur) viimane aruanne telemeetria kohta Backendi sektsioonist. Telemeetria tähendab logisid, mõõdikuid, rakenduste jälgi.
Sel eesmärgil kasutab Contour Githubi postitatud enda kirjutatud tööriistu. Tööriist raportist – Hercules, , kasutatakse telemeetriaandmete edastamiseks.
Vladimir Lila aruandes jaotises Devops käsitleti logide salvestamist ja töötlemist Elasticsearchis, kuid endiselt on ülesanne toimetada logid paljudest tuhandetest seadmetest ja rakendustest ning sellised tööriistad nagu Vostok Hercules lahendavad need.
Ringrada kulges paljudele tuntud rada - RabbitMQ-st Apache Kafkani, kuid kõik pole nii lihtne)) Nad pidid ringrajale lisama Zookeeperi, Cassandra ja Graphite. Selle raporti (mitte minu profiili) teavet ma täielikult ei avalda, huvi korral võite oodata slaide ja videoid konverentsi veebisaidil.
Kuidas see teiste konverentsidega võrreldes on?
Ma ei saa seda võrrelda Moskva ja Peterburi konverentsidega, võin võrrelda teiste sündmustega Uuralites ja 404festiga Samaras.
DAMP toimub 8 sektsioonis, see on Uurali konverentside rekord. Väga suured teaduse ja juhtimise rubriigid, see on samuti ebatavaline. Jekaterinburgi publik on üsna struktureeritud - linnas on suured arendusosakonnad Yandexi, Konturi, Tinkoffi jaoks ja see jätab aruannetele oma jälje.
Huvitav on ka see, et paljudel ettevõtetel on konverentsil korraga 3-4 esinejat (nii oli Kontur, Evil Martians, Tinkoff). Paljud neist olid sponsorid, kuid aruanded on üsna võrdsed teistega, need pole reklaamraportid.
Kas minna või mitte minna? Kui elad Uuralites või selle lähedal, siis on sul võimalus ja teemad huvilised – jah, muidugi. Kui mõtled pikale reisile, siis vaataks varasemate aastate reportaažide ja videoreportaažide teemasid ja tegi otsuse.
Piirkondades toimuvate konverentside eeliseks on reeglina ka see, et pärast ettekannet on kõnelejaga lihtne suhelda, soovijaid on lihtsalt vähem.
Aitäh Dumpile ja Jekaterinburgile! )
Allikas: www.habr.com