Java javita në konferencën IT DUMP (https://dump-ekb.ru/) në Jekaterinburg javën e kaluar dhe dua të tregoj për temat që u diskutuan në seksionet Backend dhe Devops, dhe a vlejnë vëmendje konferencat rajonale të IT.
Nikolai Sverchkov nga Evil Martians për Serverless
ĂfarĂ« ndodhi atje nĂ« tĂ« vĂ«rtetĂ«?
Në total kishte 8 seksione në konferencë: Backend, Frontend, Mobil, Testim dhe QA, Devops, Dizajn, Shkencë dhe Menaxhim.
Sallat më të mëdha, për fat të keq, ishin të Shkencës dhe Menaxhimit )) Nga ~350 veta secila. Backend dhe Frontend ishin pak më të vogla. Salla e Devops ishte më e vogla, por ishte aktive.
Dëgjova ligjëratat në seksionet Devops dhe Backend dhe pak bëra biseda me ligjëruesit. Dua të tregoj për temat e trajtuara dhe të bëj një pasqyrë të këtyre seksioneve në konferencë.
Në seksionet Devops dhe Backend paraqitën përfaqësuesit e SKB-Kontur, DataArt, Evil Martians, studio e internetit Flag nga Jekaterinburg, Miro (RealTimeBoard). Temat përfshinin CI/CD, punë me shërbimet e radhës, logimin, tema të mira u trajtuan për Serverless dhe punën me PostgreSQL në Go.
Ishte gjithashtu ligjërata nga Avito, Tinkoff, Yandex, Jetstyle, Megafon, banka Ak Bars, por nuk arrita t'i vizitoj fizikisht (video-incizimet dhe diapozitivët e ligjëratave ende nuk janë të qasshëm, premtojnë t'i ngarkojnë brenda 2 javësh në dump-ekb.ru).
Seksioni Devops
Ajo qĂ« ma bĂ«ri pĂ«rshtypje ishte se sesioni u mbajt nĂ« sallĂ«n mĂ« tĂ« vogĂ«l, rreth 50 vende. NjerĂ«zit ishin duke qĂ«ndruar madje edhe nĂ« kalime đ Do tregoj pĂ«r prezantimet qĂ« arrita tĂ« dĂ«gjoj.
Elastiku me peshë një petabajt
Sesioni filloi me prezantimin e Vladimir Lilës (SKB-Kontur) mbi Elasticsearch në Kontur. Ata kanë një Elastik mjaft të madh dhe të ngarkuar (~800 TB të dhënash, ~1.3 petabajt duke marrë parasysh mbivendosjen). Elasticsearch është i njëjtë për të gjitha shërbimet e Konturit, përbëhet nga 2 klastera (nga 7 dhe 9 serverë), dhe është kaq i rëndësishëm sa që në Kontur ka një inxhinier të specializuar për Elasticsearch (vetë Vladimir).
Vladimir gjithashtu ndau mendime mbi përfitimet nga Elasticsearch dhe problemet që sjell.
PĂ«rfitimi:
- Të gjitha loget në një vend, qasje e lehtë në to
- Ruajtja e logeve për një vit dhe analiza e lehtë e tyre
- Shpejtësi e lartë në punën me loget
- Vizualizim i shkĂ«lqyer i tĂ« dhĂ«nave ânga kutiaâ
Problemet:
- Brokeri i mesazheve â must have (roli i tij nĂ« Kontur pĂ«rmbushet nga Kafka)
- Veçoritë e punës me Elasticsearch Curator (ngarkesë e lartë e krijuar periodikisht nga detyrat e rregullta në Curator)
- Nuk ka autorizim të integruar (vetëm për një shumë të madhe parash, ose si plugin-opensource me nivele të ndryshme gatishmërie për prodhim)
Rreth Open Distro pĂ«r Elasticsearch, komente kanĂ« qenĂ« vetĂ«m pozitive đ Po ashtu, problemi i autorizimit Ă«shtĂ« zgjidhur atje.
Nga vjen petabajti?Nodet e tyre përbëhen nga serverë me 12*8 Tb SATA + 2*2 Tb SSD. Ruajtja e ftohtë është në SATA, SSD vetëm për cache-në e nxehtë (ruajtja e nxehtë).
7+9 serverë, (7 + 9) * 12 * 8 = 1536 Tb.
Një pjesë e hapësirës është rezervuar për shpërndarje dhe redundancë.
Në Elasticsearch dërgohen loge nga rreth 90 aplikacionesh, përfshirë të gjitha shërbimet e raportimit të Konturit, Elba, etj.
Karakteristikat e zhvillimit në Serverless
Më pas, raporti i Ruslan Serkin nga DataArt për Serverless.
Ruslan tregoi se çfarë është zhvillimi me qasje Serverless në përgjithësi dhe cilat janë karakteristikat e tij.
Serverless është një qasje për zhvillimin, ku zhvilluesit nuk prekin aspak Infrastrukturën. Një shembull është AWS Lambda Serverless, Kubeless.io (Serverless brenda Kubernetes), Google Cloud Functions.
NjĂ« aplikacion ideal Serverless Ă«shtĂ« thjesht njĂ« funksion qĂ« dĂ«rgon njĂ« kĂ«rkesĂ« te ofruesi Serverless pĂ«rmes njĂ« API Gateway tĂ« veçantĂ«. NjĂ« mikroshĂ«rbim ideal, po ashtu nĂ« AWS Lambda, mbĂ«shtet njĂ« numĂ«r tĂ« madh gjuhĂ«sh moderne programuese. Kostoja e mbĂ«shtetjes dhe e shpĂ«rndarjes sĂ« infrastrukturĂ«s bĂ«het zero nĂ« rastin e ofruesve tĂ« cloud, mbĂ«shtetje pĂ«r aplikacione tĂ« vogla gjithashtu do tĂ« jetĂ« shumĂ« e lirĂ« (AWS Lambda â 0.2$ / 1 milion kĂ«rkesash tĂ« thjeshta).
MundĂ«sia e shkallĂ«zimit tĂ« njĂ« sistemi tĂ« tillĂ« Ă«shtĂ« pothuajse ideale â ofruesi i cloud kujdeset vetĂ« pĂ«r kĂ«tĂ«, Kubeless shkallĂ«zohet automatikisht brenda klasterit Kubernetes.
Ka disavantazhe:
- zhvillimi i aplikacioneve të mëdha bëhet më i komplikuar
- ka vështirësi me profilizimin e aplikacioneve (ju janë në dispozicion vetëm regjistrat, 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 tĂ« gjitha kĂ«to vite mĂ« ka qenĂ« e paqartĂ« se si ta aplikoj siç duhet. Pas fjalimit tĂ« Ruslanit kuptimi erdhi, dhe pas fjalimit tĂ« Nikolaj Sverkhovit (Evil Martians) nga Seksioni Backend u konsolidua. Nuk isha kot nĂ« konferencĂ« đ
CI për të varfrit, apo a ia vlen të shkruash CI-në tënde për një studio web?
Mikhail Radionov, drejtori i studio web-it Flag nga Jekaterinburg, diskutoi rreth CI/CD të shkruar vetë.
Studioja e tij ka kaluar nga 'CI/CD manuale' (hyri në server përmes SSH, bëri git pull, e përsëriti 100 herë në ditë) te Jenkins dhe një mjet të shkruar vetë që kontrollon kodin dhe ekzekuton publikime të quajtur Pullkins.
Pse nuk e përqafoi Jenkins? Ai nuk ofronte mjaft fleksibilitet nga vetë e përdefault 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 e përdorën mekanizmat e integruar të Laravel quajtur Telescope dhe Envoy. Si rezultat, u krijua një server në php (vini re), i cili përpunonte kërkesat webhook të ardhura, kishte aftësinë për të ndërtuar frontend-in, backend-in, për t'i deploy-uar në servera të ndryshëm dhe për të raportuar në Slack.
Më pas, për të mundësuar ekzekutimin e deploy-it blue/green, duke pasur konfigurime uniforme në ambientet dev-stage-prod, ata kaluan në Docker. Avantazhet mbetën të njëjta, u shtuan mundësitë për homogenizimin e ambientit dhe për deploy të qetë, si dhe u shfaq nevoja për të studiuar Docker për ta përdorur atë siç duhet.
Si e ulëm numrin e rikthimeve të lëshimeve serverike me 99%
Prezantimi i fundit në seksionin DevOps ishte nga Viktor Yeremchenko, inxhinieri kryesor i devops në Miro.com (ish RealTimeBoard).
NĂ« bazĂ« tĂ« RealTimeBoard, produktit kryesor tĂ« ekipit Miro, ndodhet njĂ« aplikacion monolitik nĂ« Java. TĂ« ndĂ«rtohet, testohen dhe tĂ« zhvillohet pa ndonjĂ« pushim Ă«shtĂ« njĂ« detyrĂ« e komplikuar. ĂshtĂ« e rĂ«ndĂ«sishme tĂ« bĂ«het zhvillimi i njĂ« versioni tĂ« tillĂ« tĂ« kodit, qĂ« nuk do tĂ« duhet tĂ« rikthehet (pasi Ă«shtĂ« njĂ« monolit i rĂ«ndĂ«).
Në rrugën drejt ndërtimit të një sistemi që lejon të bëhet kjo, Miro kaloi një rrugë që përfshinte punën në arkitekturë, instrumentet e përdorura (Atlassian Bamboo, Ansible, etj.) dhe ndërtimin e grupeve (ata tani kanë një ekip të dedikuar DevOps + shumë ekipe të ndara Scrum nga zhvillues të profileve të ndryshme).
Rruga doli të ishte e vështirë dhe me pengesa, dhe Viktor ndau dhimbjen e grumbulluar dhe optimizmin e pambaruar.
Fitova një libër për pyetjet
Seksioni Backend
Arrita nĂ« 2 prezantime â nga Nikolai Sverchkov (Evil Martians), gjithashtu pĂ«r Serverless, dhe nga Grigory Koshelev (kompania Kontur) pĂ«r telemetrinĂ«.
Serverless për vdekatarët e thjeshtë
Nëse Ruslan Sierkin fliste për atë çfarë është Serverless, Nikolai tregoi aplikacione të thjeshta me përdorimin e Serverless dhe shpjegoi detajet që ndikojnë në kostot dhe shpejtësinë e funksionimit të aplikacioneve në AWS Lambda.
NjĂ« detaj interesant: elementi minimal i pagueshĂ«m â 128 Mb memorie dhe 100 ms CPU, kushton 0,000000208$. NdĂ«rkohĂ«, 1 milion kĂ«rkesa tĂ« tilla nĂ« muaj janĂ« falas.
Disa funksione të Nikolait shpesh kalonin kufirin e 100 ms (kryesori ishte shkruar në Ruby), prandaj rikodimi i tyre në Go solli një kursim të shkëlqyer.
Vostok Hercules â bĂ«j telemetrin tĂ« shkĂ«lqejĂ« pĂ«rsĂ«ri!
Prezantimi i fundit i seksionit Backend nga Grigori Koshelev (kompania Kontur) mbi telemetrinĂ«. Telemetria â janĂ« log-et, metrikat, gjurmĂ«t e aplikacioneve.
Kontur pĂ«rdor pĂ«r kĂ«tĂ« vegla tĂ« shkruara me dorĂ«, tĂ« publikuara nĂ« Github. Vegla nga prezantimi â Hercules, , pĂ«rdoret pĂ«r dĂ«rgimin e tĂ« dhĂ«nave tĂ« telemetrisĂ«.
Në prezantimin e Vladimir Lilës në seksionin DevOps u shqyrtua ruajtja dhe procesimi i log-eve në Elasticsearch, por ka edhe detyrën për të dërguar log-e nga mijëra pajisje dhe aplikacione, dhe për këtë zgjidhen mjete si Vostok Hercules.
Konturi ka kaluar njĂ« rrugĂ« tĂ« njohur pĂ«r shumĂ« â nga RabbitMQ te Apache Kafka, por nuk Ă«shtĂ« aq e thjeshtĂ« )) I duhej tĂ« shtonin nĂ« skemĂ« Zookeeper, Cassandra dhe Graphite. Nuk do tĂ« zbuloj plotĂ«sisht informacionin e 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 SPb, mund ta krahasoj me ngjarjet e tjera në Ural dhe me 404fest në Samara.
DAMP zhvillohet nĂ« 8 seksione, kjo Ă«shtĂ« njĂ« rekord pĂ«r konferencat nĂ« Ural. Seksionet e mĂ«dha tĂ« ShkencĂ«s dhe Menaxhimit janĂ« gjithashtu tĂ« pazakonta. Audienca nĂ« Jekaterinburg Ă«shtĂ« mjaft e strukturuar â nĂ« qytet ka departamente tĂ« mĂ«dha zhvillimi tĂ« Yandex, Kontur, Tinkoff, kjo lĂ« njĂ« shenjĂ« gjithashtu nĂ« raportet.
NjĂ« moment tjetĂ«r interesant â shumĂ« kompani kanĂ« menjĂ«herĂ« 3-4 raportues nĂ« konferencĂ« (ashtu ishte me Konturin, Evil Martians, Tinkoff). Shumica prej tyre ishin sponsorizues, por raportet ishin tĂ« njĂ« niveli tĂ« barabartĂ« me tĂ« tjerĂ«t, nuk ishin raportet reklamative.
Të shkosh apo të mos shkosh? Nëse jetoni në Ural ose afër, keni mundësinë dhe tema interesante - po, sigurisht. Nëse po mendoni për një udhëtim më të gjatë - do t'i shikoja temat e raporteve dhe videot nga vitet e kaluara. dhe mora vendim.
Një tjetër avantazh i konferencave në rajone është se zakonisht është e lehtë të bisedosh me folësin pas raporteve, thjesht sepse ka më pak pretendues për një të tillë bisedë.
Faleminderit DUMP dhe Ekaterinburg! )
Burimi: habr.com
