Javë e kaluar, shkova në konferencën IT DUMP (https://dump-ekb.ru/) në Jekaterinburg dhe dua të flas për çfarë u përmend në seksionet Backend dhe Devops, dhe a ia vlen të frekuentohen konferencat rajonale IT.
Nikolaj Sverchkov nga Evil Martians për Serverless
ĂfarĂ« ndodhi atje?
Në total, konferenca kishte 8 seksione: Backend, Frontend, Mobile, Testim dhe QA, Devops, Dizajn, Shkencë dhe Menaxhim.
Sallat më të mëdha, në fakt, ishin për Shkencën dhe Menaxhimin )) Afërsisht 350 persona secila. Backend dhe Frontend ishin pak më të vogla. Salla e Devops ishte më e vogla, por shumë aktive.
Unë dëgjova raportet në seksionet Devops dhe Backend dhe bisedova pak me ligjëruesit. Dua të flas për temat e trajtuara dhe të bëj një përmbledhje të këtyre seksioneve në konferencë.
Në seksionet Devops dhe Backend folën përfaqësues nga SKB-Kontur, DataArt, Evil Martians, studioja e uebit të Jekaterinburgut Flag, Miro (RealTimeBoard). Temat përfshinin CI/CD, punën me shërbimet e radhëve, logimin, dhe ishin trajtuar mirë temat Serverless dhe punën me PostgreSQL në Go.
Gjithashtu kishte raporte nga Avito, Tinkoff, Yandex, Jetstyle, Megafon, banka Ak Bars, por ato nuk arrita t'i ndjek fizikisht (video incizimet dhe slidet e raporteve akoma nuk janë të disponueshme, premtojnë t'i publikojnë brenda 2 javëve në dump-ekb.ru).
Seksioni Devops
ĂfarĂ« e befasoi â seksioni u zhvillua nĂ« sallĂ«n mĂ« tĂ« vogĂ«l, rreth 50 vendesh. NjerĂ«zit qĂ«ndronin madje edhe nĂ« kalime đ Do tĂ« tregoj pĂ«r raportet qĂ« arrita tĂ« dĂ«gjoj.
Elastik me peshë një petabajt
Seksi filloi me raportin e Vladimir Lilës (SKB-Kontur) për Elasticsearch në Kontur. Ata kanë një Elasticsearch të madh dhe të ngarkuar (~800 TB të dhënash, ~1.3 petabajt me marrë parasysh tepricën). Elasticsearch për të gjitha shërbimet e Konturit është unik, përbëhet nga 2 grupe (nga 7 dhe 9 serverë), dhe është kaq i rëndësishëm saqë në Kontur ka një inxhinier të veçantë Elasticsearch (vetë Vladimir).
Vladimir gjithashtu ndau mendimet e tij për përfitimin nga Elasticsearch dhe problemet që ai sjell.
PĂ«rfitimi:
- Të gjitha log-et në një vend, qasje e lehtë në to
- Ruajtja e log-eve për një vit dhe analiza e lehtë e tyre
- Shpejtësi e lartë në punën me log-et
- Vizualizim të shkëlqyer të të dhënave "nga kutia"
Problemet:
- broker mesazhesh â must have (nĂ« Kontur rolin e saj e luan Kafka)
- veçoritë e punës me Elasticsearch Curator (ngarkesë e lartë periodike nga detyrat që kryhen rregullisht në Curator)
- nuk ka autorizim të integruar (vetëm për para të konsiderueshme, ose si plugin nga burimi i hapur me nivel të ndryshëm gatishmërie për prodhim)
Mbi Open Distro pĂ«r Elasticsearch ka vetĂ«m komente pozitive đ Po ashtu Ă«shtĂ« zgjidhur problemi i autentifikimit atje.
Nga vjen petabaiti?Node-t e tyre përbëhen nga serverë me 12*8 Tb SATA + 2*2 Tb SSD. Ruajtja e ftohtë në SATA, SSD vetëm për cache të nxehtë (hot storage).
7+9 serverë, (7 + 9) * 12 * 8 = 1536 Tb.
Një pjesë e hapësirës është rezervë, e vendosur për redundant dhe të tjera.
Në Elasticsearch dërgohen logët e rreth 90 aplikacioneve, përfshirë të gjitha shërbimet e raportimit të Konturit, Elba dhe të tjera.
Veçoritë e zhvillimit në Serverless
MĂ« pas, referati i Ruslan Serkin nga DataArt mbi Serverless.
Ruslan tregoi se çfarë është zhvillimi me qasjen Serverless dhe cilat janë veçoritë e saj.
Serverless Ă«shtĂ« njĂ« qasje nĂ« zhvillim, ku zhvilluesit nuk prekin aspak infrastrukturĂ«n. Shembuj â AWS Lambda Serverless, Kubeless.io (Serverless brenda Kubernetes), Google Cloud Functions.
Aplikimi ideal Serverless Ă«shtĂ« thjesht njĂ« funksion qĂ« dĂ«rgon njĂ« kĂ«rkesĂ« te ofruesi Serverless pĂ«rmes njĂ« API Gateway tĂ« veçantĂ«. NjĂ« mikrosherbim ideal, nĂ« tĂ« njĂ«jtĂ«n kohĂ« nĂ« AWS Lambda mbĂ«shtetet njĂ« numĂ«r i madh gjuhĂ«sh moderne tĂ« programimit. Kostoja e mbĂ«shtetjes dhe implementimit tĂ« infrastrukturĂ«s bĂ«het zero nĂ« rastin e ofruesve tĂ« shĂ«rbimeve nĂ« cloud, mbĂ«shtetja e aplikacioneve tĂ« vogla gjithashtu do tĂ« jetĂ« shumĂ« e lirĂ« (AWS Lambda â 0.2$ / 1 milion kĂ«rkesa tĂ« thjeshta).
ShkallĂ«zimi i kĂ«tij sistemi Ă«shtĂ« praktikisht ideal â ofruesi i shĂ«rbimeve nĂ« cloud merret me kĂ«tĂ« vetĂ«, Kubeless shkallĂ«zohet automatikisht brenda klasterit Kubernetes.
Ka disa disavantazhe:
- zhvillimi i aplikacioneve të mëdha bëhet më i komplikuar
- ka vështirësi me profilizimin e aplikacioneve (ju janë të aksesueshme vetëm logët, por jo profilizimi në kuptimin e zakonshëm)
- nuk ka versionim
TĂ« them sinqerisht, pĂ«r Serverless kam dĂ«gjuar disa vite mĂ« parĂ«, por gjithĂ« kĂ«to vite mĂ« ka qenĂ« e paqartĂ« se si ta aplikoj atĂ« saktĂ«sisht. Pas referatit tĂ« Ruslanit kuptimi u shfaq, dhe pas referatit tĂ« Nikolaj Sverkhovit (Evil Martians) nga seksioni Backend u konsolidua. Tani, nuk shkuam kot nĂ« konferencĂ« đ
CI për të varfrit, apo a duhen shkruar CI të vetat për një studio web-i
Mikhail Radionov, drejtori i studio web-i Flag nga Ekaterinburg, foli mbi CI/CD të shkruar vetë.
Studia e tij kaloi nga âCI/CD manualâ (hyri nĂ« server pĂ«rmes SSH, bĂ«ri git pull, pĂ«rsĂ«ritje 100 herĂ« nĂ« ditĂ«) nĂ« Jenkins dhe nĂ« njĂ« mjet tĂ« krijuar vetĂ«, qĂ« lejon kontrollin e kodit dhe realizimin e lirimeve tĂ« quajtur Pullkins.
Pse nuk e pranove Jenkins? Ai nuk ofronte mjaft fleksibilitet nga default dhe ishte tepër i komplikuar për t'u personalizuar.
âFlagâ zhvillon nĂ« Laravel (framework PHP). GjatĂ« zhvillimit tĂ« serverit CI/CD, Mikhail me kolegĂ«t e tij pĂ«rdorĂ«n mekanizmat e integruar tĂ« Laravel, tĂ« quajtur Telescope dhe Envoy. Si rezultat, u krijua njĂ« server nĂ« php (vini re), qĂ« trajton kĂ«rkesat webhook, Ă«shtĂ« nĂ« gjendje tĂ« kryejĂ« ndĂ«rrimin e frontend-it, backend-it, tĂ« bĂ«jĂ« deploy nĂ« servera tĂ« ndryshĂ«m dhe tĂ« raportojĂ« nĂ« Slack.
Pastaj, për të realizuar blue/green deploy, për të pasur konfigurime uniforme në mjediset dev-stage-prod, ata kaluan në Docker. Avantazhet mbetën të njëjta, u shtuan mundësitë e homogenizimit të mjedisit dhe deploy-it pa probleme, dhe u shtua nevoja për të studiuar Docker për të punuar me të siç duhet.
Si e uli numrin e rikthimeve të lansimeve serverike me 99%
Referati i fundit në seksionin DevOps ishte nga Viktor Yeremchenko, inxhinieri kryesor DevOps në Miro.com (ish RealTimeBoard).
NĂ« thelb tĂ« RealTimeBoard, produktit kryesor tĂ« ekipit Miro, qĂ«ndron njĂ« aplikacion monolit nĂ« Java. NdĂ«rtimi, testimi dhe deploy-i i tij pa ndalesa Ă«shtĂ« njĂ« detyrĂ« e vĂ«shtirĂ«. ĂshtĂ« thelbĂ«sore tĂ« realizohet deploy i njĂ« versioni tĂ« tillĂ« tĂ« kodit, qĂ« tĂ« mos nevojitet rikthim (sepse Ă«shtĂ« njĂ« monolit i rĂ«ndĂ«).
Në rrugën për të krijuar një sistem që mund ta bëjë këtë, Miro përshkoi një rrugë që përfshinte punën në arkitekturë, mjetet që përdoren (Atlassian Bamboo, Ansible, etj.), dhe ndërtimin e ekipeve (ata tani kanë një ekip të dedikuar DevOps + shumë ekipe të veçanta Scrum nga zhvillues të profileve të ndryshme).
Rruga u tregua e vështirë dhe e lëvizshme, dhe Viktor ndau dhimbjen që kishte grumbulluar dhe një optimizëm që nuk kishte përfunduar.
Fitova një libër për pyetje
Seksioni Backend
Kam arritur në 2 referate - nga Nikolai Sverchkov (Evil Martians), gjithashtu mbi Serverless, dhe nga Grigory Koshelev (kompania Kontur) mbi telemetrinë.
Serverless për njerëzit e zakonshëm
Nëse Ruslan Sirkin fliste për atë se çfarë është Serverless, Nikolai tregoi aplikacione të thjeshta duke përdorur Serverless, dhe tregoi detajet që ndikojnë në kostot dhe shpejtësinë e funksionimit të aplikacioneve në AWS Lambda.
Një detaj interesant: elementi më i vogël i paguar - 128 Mb memorie dhe 100 ms CPU, kushton 0,000000208$. Në të njëjtën kohë, 1 milion të tillë kërkesa në muaj janë falas.
Disa disa funksionet e Nikolait shpesh kalonin limitin prej 100 ms (aplikacioni kryesor ishte shkruar në Ruby), prandaj ri-shkrimi i tyre në Go ofroi një kursim të shkëlqyer.
Vostok Hercules â bĂ«je telemetrinĂ« tĂ« madhe pĂ«rsĂ«ri!
Raporti i fundit nga sekcioni Backend i Grigorit Koshalev (kompania Kontur) mbi telemetrinë. Telemetria përfshin loge, metrika, gjurmë aplikacionesh.
Kontur pĂ«rdor pĂ«r kĂ«tĂ« mjete tĂ« shkruara me dorĂ«, tĂ« publikuara nĂ« Github. Instrumenti nga raporti â Hercules, , pĂ«rdoret pĂ«r dĂ«rgimin e tĂ« dhĂ«nave tĂ« telemetrisĂ«.
Në raportin e Vladimirit Lila në sekcionin Devops, u shqyrtua ruajtja dhe përpunimi i logeve në Elasticsearch, por ekziston edhe detyra për të dërguar loge nga mijëra pajisje dhe aplikacione, dhe këto zgjidhen me mjete si Vostok Hercules.
Kontur ka ndjekur njĂ« rrugĂ« tĂ« njohur pĂ«r shumĂ« â nga RabbitMQ nĂ« Apache Kafka, por nuk Ă«shtĂ« aq e thjeshtĂ«. Musht u detyruan tĂ« shtonin nĂ« skemĂ« Zookeeper, Cassandra dhe Graphite. Nuk do tĂ« zbuloj plotĂ«sisht informacionin rreth kĂ«tij raporti (nuk Ă«shtĂ« profili im), nĂ«se jeni tĂ« interesuar mund tĂ« prisni diapozitivĂ«t dhe videon nĂ« faqen e 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ë Ural dhe me 404fest në Samara.
DAMP zhvillohet nĂ« 8 seksione, qĂ« Ă«shtĂ« njĂ« rekord pĂ«r konferencat e Uralit. Seksionet ShkencĂ« dhe Menaxhim janĂ« shumĂ« tĂ« mĂ«dha, kjo gjithashtu Ă«shtĂ« e pazakontĂ«. Publiku nĂ« Jekaterinburg Ă«shtĂ« mjaft i strukturuar â nĂ« qytet ka departamente tĂ« mĂ«dha tĂ« zhvillimit nga Yandex, Kontur, Tinkoff, kjo lĂ« njĂ« shenjĂ« edhe nĂ« raportet.
NjĂ« tjetĂ«r moment interesant â shumĂ« kompanive u kishte nĂ« konferencĂ« 3â4 folĂ«s tĂ« menjĂ«hershĂ«m (ashtu ishte me Kontur, Evil Martians, Tinkoff). Shumica prej tyre ishin sponsorizues, por raportet ishin nĂ« nivel tĂ« krahasueshĂ«m me tĂ« tjerĂ«t, nuk ishin raporte reklamuese.
TĂ« shkosh apo jo? NĂ«se jetoni nĂ« Ural apo pĂ«rreth, keni mundĂ«si dhe temat janĂ« interesante â po, sigurisht. NĂ«se po mendoni pĂ«r njĂ« udhĂ«tim mĂ« tĂ« largĂ«t â do tĂ« shikoja temat e raporteve dhe videot e raporteve nga vitet e kaluara. dhe do merrja njĂ« vendim.
NjĂ« avantazh tjetĂ«r i konferencave nĂ« rajone, zakonisht â Ă«shtĂ« e lehtĂ« tĂ« bisedosh me folĂ«sin pas raporteve, thjesht ka mĂ« pak pretendues pĂ«r njĂ« tĂ« tillĂ« bisedĂ«.
Faleminderit DAMP-it dhe Jekaterinburgut! )
Burimi: habr.com
