Javën e kaluar shkova në konferencën DUMP IT (https://dump-ekb.ru/) në Yekaterinburg dhe dua t'ju tregoj se çfarë u diskutua në seksionet Backend dhe Devops dhe nëse konferencat rajonale të IT-së ia vlen t'i kushtohet vëmendje.
Nikolay Sverchkov nga Evil Martians rreth Serverless
Çfarë kishte gjithsesi?
Në total, konferenca kishte 8 seksione: Backend, Frontend, Mobile, Testing dhe QA, Devops, Design, Science dhe Management.
Sallat më të mëdha, meqë ra fjala, janë në Shkencë dhe Menaxhimi)) Për ~ 350 persona secila. Backend dhe Frontend nuk janë shumë më të vogla. Dhoma Devops ishte më e vogla, por aktive.
Dëgjova raportet në seksionet Devops dhe Backend dhe fola pak me folësit. Do të doja të flisja për temat e trajtuara dhe t'i rishikoja këto seksione në konferencë.
Përfaqësuesit e SKB-Kontur, DataArt, Evil Martians, Web studio Ekaterinburg Flag, Miro (RealTimeBoard) folën në seksionet Devops dhe Backend. Temat e mbuluara CI/CD, puna me shërbimet e radhës, regjistrimi; Temat pa server dhe puna me PostgreSQL në Go u trajtuan mirë.
Ka pasur edhe raportime nga Avito, Tinkoff, Yandex, Jetstyle, Megafon, Ak Bars Bank, por nuk kam pasur kohë t'i ndjek fizikisht (incizimet video dhe sllajdet e raporteve nuk janë ende të disponueshme, ata premtojnë t'i postojnë brenda 2 javësh në dump-ekb.ru).
Seksioni Devops
Ajo që ishte befasuese ishte se seksioni mbahej në sallën më të vogël, rreth 50 vende. Njerëzit madje po qëndronin në korridor :) Unë do t'ju tregoj për raportet që arrita të dëgjoja.
Elastik që peshon një petabajt
Seksioni filloi me një raport nga Vladimir Lil (SKB-Kontur) rreth Elasticsearch në Kontur. Ata kanë një Elastic mjaft të madh dhe të ngarkuar (~ 800 TB të dhëna, ~ 1.3 petabajt duke marrë parasysh tepricën). Elasticsearch për të gjitha shërbimet e Kontur është i vetëm, përbëhet nga 2 grupe (nga 7 dhe 9 serverë) dhe është aq i rëndësishëm sa Kontur ka një inxhinier të veçantë Elasticsearch (në fakt, vetë Vladimir).
Vladimiri gjithashtu ndau mendimet e tij mbi përfitimet e Elasticsearch dhe problemet që ai sjell.
përfitimet:
- Të gjitha shkrimet janë në një vend, qasje e lehtë në to
- Ruajtja e shkrimeve për një vit dhe analizimi i lehtë i tyre
- Shpejtësia e lartë e punës me shkrimet
- Vizualizimi i lezetshëm i të dhënave jashtë kutisë
Problemet:
- Ndërmjetësi i mesazheve është i domosdoshëm (për Konturin rolin e tij e luan Kafka)
- veçoritë e punës me Elasticsearch Curator (ngarkesa e lartë e krijuar periodikisht nga detyrat e rregullta në Curator)
- pa autorizim të integruar (vetëm për para të veçanta, mjaft të mëdha, ose si shtojca me burim të hapur të shkallëve të ndryshme të gatishmërisë për prodhim)
Kishte vetëm komente pozitive për Open Distro për Elasticsearch :) E njëjta çështje e autorizimit është zgjidhur atje.
Nga vjen petabyte?Nyjet e tyre përbëhen nga serverë me 12*8 Tb SATA + 2*2 Tb SSD. Magazinimi i ftohtë në SATA, SSD vetëm për cache të nxehtë (ruajtje e nxehtë).
7+9 serverë, (7 + 9) * 12 * 8 = 1536 Tb.
Një pjesë e hapësirës është rezervë, e lënë mënjanë për tepricë, etj.
Regjistrat nga rreth 90 aplikacione dërgohen në Elasticsearch, përfshirë të gjitha shërbimet e raportimit të Kontur, Elba, etj.
Karakteristikat e zhvillimit në server pa server
Më tej është një raport nga Ruslan Serkin nga DataArt në lidhje me Serverless.
Ruslan foli për atë që është zhvillimi me qasjen pa server në përgjithësi dhe cilat janë tiparet e tij.
Pa server është një qasje ndaj zhvillimit në të cilën zhvilluesit nuk e prekin infrastrukturën në asnjë mënyrë. Shembull - AWS Lambda Serverless, Kubeless.io (Pa server brenda Kubernetes), Funksionet e Google Cloud.
Një aplikacion ideal pa server është thjesht një funksion që dërgon një kërkesë te një ofrues pa server përmes një porte speciale API. Një mikroshërbim ideal, ndërsa AWS Lambda mbështet gjithashtu një numër të madh gjuhësh programimi moderne. Kostoja e mirëmbajtjes dhe vendosjes së infrastrukturës bëhet zero në rastin e ofruesve të cloud, mbështetja e aplikacioneve të vogla do të jetë gjithashtu shumë e lirë (AWS Lambda - 0.2 $ / 1 milion kërkesa të thjeshta).
Shkallueshmëria e një sistemi të tillë është pothuajse ideale - ofruesi i cloud kujdeset vetë për këtë, Kubeless shkallëzohet automatikisht brenda grupit Kubernetes.
Ka disavantazhe:
- zhvillimi i aplikacioneve të mëdha po bëhet më i vështirë
- ka vështirësi me profilizimin e aplikacioneve (ju keni akses vetëm në regjistrat, por jo profilizimin në kuptimin e zakonshëm)
- pa versionim
Për të qenë i sinqertë, kam dëgjuar për Serverless disa vjet më parë, por gjatë gjithë këtyre viteve nuk ishte e qartë për mua se si ta përdorja siç duhet. Pas raportit të Ruslanit, u shfaq mirëkuptimi dhe pas raportit të Nikolai Sverchkov (Martianët e Keq) nga seksioni Backend, ai u konsolidua. Jo më kot shkova në konferencë :)
CI është për të varfërit, apo ia vlen të shkruani CI-në tuaj për një studio në internet?
Mikhail Radionov, kreu i studios së internetit Flag nga Yekaterinburg, foli për CI/CD të shkruar vetë.
Studioja e tij ka kaluar nga "CI/CD manuale" (hyni në server nëpërmjet SSH, bëni një tërheqje git, përsërisni 100 herë në ditë) në Jenkins dhe në një mjet të vetë-shkruar që ju lejon të monitoroni kodin dhe të kryeni lëshime të quajtura Pullkins .
Pse nuk funksionoi Jenkins? Nuk ofroi fleksibilitet të mjaftueshëm si parazgjedhje dhe ishte shumë e vështirë për t'u personalizuar.
"Flamuri" zhvillohet në Laravel (korniza PHP). Kur zhvillonin një server CI/CD, Mikhail dhe kolegët e tij përdorën mekanizmat e integruar të Laravel të quajtur Teleskop dhe Envoy. Rezultati është një server në PHP (ju lutemi vini re) që përpunon kërkesat hyrëse të uebhook-it, mund të ndërtojë frontend dhe backend, të vendoset në serverë të ndryshëm dhe të raportojë te Slack.
Më pas, për të qenë në gjendje të kryejnë vendosjen blu/jeshile dhe të kenë cilësime uniforme në mjediset dev-stage-prod, ata kaluan në Docker. Përparësitë mbetën të njëjta, u shtuan mundësitë e homogjenizimit të mjedisit dhe vendosjes pa probleme dhe u shtua nevoja për të mësuar Docker për të punuar me të saktë.
Si e reduktuam numrin e rikthimeve të lëshimit të serverit me 99%
Raporti i fundit në seksionin Devops ishte nga Viktor Eremchenko, inxhinier kryesor devops në Miro.com (ish-RealTimeBoard).
RealTimeBoard, produkti kryesor i ekipit Miro, bazohet në një aplikacion monolit Java. Mbledhja, testimi dhe vendosja e tij pa ndërprerje është një detyrë e vështirë. Në këtë rast, është e rëndësishme të vendosni një version të tillë të kodit në mënyrë që të mos ketë nevojë të rikthehet (është një monolit i rëndë).
Gjatë rrugës për të ndërtuar një sistem që ju lejon ta bëni këtë, Miro kaloi nëpër një rrugë që përfshinte punën në arkitekturën, mjetet e përdorura (Atlassian Bamboo, Ansible, etj) dhe punën në strukturën e ekipeve (ata tani kanë një ekip i dedikuar Devops + shumë ekipe të veçanta Scrum nga zhvillues të profileve të ndryshme).
Rruga doli e vështirë dhe me gjemba dhe Viktori ndau dhimbjen dhe optimizmin e grumbulluar që nuk mbaroi me kaq.
Fitova një libër për të bërë pyetje
Seksioni i fundit
Arrita të marr pjesë në 2 raporte - nga Nikolay Sverchkov (Martianët e këqij), gjithashtu për Serverless, dhe nga Grigory Koshelev (kompania Kontur) për telemetrinë.
Pa server për të vdekshmit e thjeshtë
Nëse Ruslan Sirkin foli për atë që është Serverless, Nikolay tregoi aplikacione të thjeshta duke përdorur Serverless dhe foli për detajet që ndikojnë në koston dhe shpejtësinë e aplikacioneve në AWS Lambda.
Një detaj interesant: elementi minimal i paguar është 128 Mb memorie dhe 100 ms CPU, kushton 0,000000208 dollarë. Për më tepër, 1 milion kërkesa të tilla në muaj janë pa pagesë.
Disa nga funksionet e Nikolai shpesh e kalonin kufirin e 100 ms (aplikacioni kryesor ishte shkruar në Ruby), kështu që rishkrimi i tyre në Go siguroi kursime të shkëlqyera.
Vostok Hercules - bëje telemetrinë sërish të mrekullueshme!
Raporti i fundit i seksionit Backend nga Grigory Koshelev (kompania Kontur) rreth telemetrisë. Telemetri nënkupton regjistrat, metrikat, gjurmët e aplikimit.
Për këtë qëllim, Contour përdor mjete të vetë-shkruara të postuara në Github. Mjeti nga raporti - Hercules, , përdoret për të dhënë të dhëna telemetrike.
Raporti i Vladimir Lila në seksionin Devops diskutoi ruajtjen dhe përpunimin e regjistrave në Elasticsearch, por ende ekziston detyra për të ofruar regjistra nga mijëra pajisje dhe aplikacione, dhe mjete si Vostok Hercules i zgjidhin ato.
Qarku ndoqi një rrugë të njohur për shumë - nga RabbitMQ në Apache Kafka, por jo gjithçka është aq e thjeshtë)) Ata duhej të shtonin Zookeeper, Cassandra dhe Graphite në qark. Unë nuk do të zbuloj plotësisht informacionin mbi këtë raport (jo profilin tim), nëse jeni të interesuar, mund të prisni për rrëshqitjet dhe videot në faqen e internetit të konferencës.
Si krahasohet me konferencat e tjera?
Nuk mund ta krahasoj me konferencat në Moskë dhe Shën Petersburg, mund ta krahasoj me ngjarje të tjera në Urale dhe me 404fest në Samara.
DAMP mbahet në 8 seksione, ky është një rekord për konferencat e Uralit. Seksione shumë të mëdha të Shkencës dhe Menaxhimit, kjo është gjithashtu e pazakontë. Audienca në Yekaterinburg është mjaft e strukturuar - qyteti ka departamente të mëdha zhvillimi për Yandex, Kontur, Tinkoff, dhe kjo lë gjurmë në raportet.
Një pikë tjetër interesante është se shumë kompani kanë 3-4 folës në konferencë menjëherë (ky ishte rasti me Kontur, Evil Martians, Tinkoff). Shumë prej tyre ishin sponsorë, por raportet janë mjaft të barabarta me të tjerat, këto nuk janë raporte reklamuese.
Të shkosh apo të mos shkosh? Nëse jetoni në Urale ose afër, keni mundësinë dhe jeni të interesuar për temat - po, sigurisht. Nëse jeni duke menduar për një udhëtim të gjatë, unë do të shikoja temat e raporteve dhe raporteve video nga vitet e mëparshme dhe mori një vendim.
Një avantazh tjetër i konferencave në rajone, si rregull, është se është e lehtë të komunikosh me folësin pas raporteve; thjesht ka më pak aplikantë për një komunikim të tillë.
Falë Dump dhe Ekaterinburg! )
Burimi: www.habr.com
