Ek het verlede week na die DUMP IT-konferensie (https://dump-ekb.ru/) in Jekaterinburg gegaan en ek wil jou vertel wat in die Backend- en Devops-afdelings bespreek is, en of streeks-IT-konferensies aandag werd is.
Nikolay Sverchkov van Evil Martians oor Serverless
Wat was daar in elk geval?
In totaal het die konferensie 8 afdelings gehad: Backend, Frontend, Mobile, Toetsing en QA, Devops, Ontwerp, Wetenskap en Bestuur.
Die grootste sale, terloops, is by Science and Management)) Vir ~350 mense elk. Backend en Frontend is nie veel kleiner nie. Die Devops-kamer was die kleinste, maar aktief.
Ek het na die berigte in die Devops- en Backend-afdelings geluister en bietjie met die sprekers gesels. Ek wil graag praat oor die onderwerpe wat gedek word en hierdie afdelings by die konferensie hersien.
Verteenwoordigers van SKB-Kontur, DataArt, Evil Martians, Ekaterinburg-webateljee Flag, Miro (RealTimeBoard) het in die Devops- en Backend-afdelings gepraat. Onderwerpe gedek CI/CD, werk met toudienste, aanteken; Bedienerlose onderwerpe en werk met PostgreSQL in Go is goed gedek.
Daar was ook verslae deur Avito, Tinkoff, Yandex, Jetstyle, Megafon, Ak Bars Bank, maar ek het nie tyd gehad om dit fisies by te woon nie (video-opnames en skyfies van die verslae is nog nie beskikbaar nie, hulle belowe om dit binne 2 weke te plaas op dump-ekb.ru).
Devops afdeling
Wat verbasend was, was dat die afdeling in die kleinste saal, sowat 50 sitplekke, gehou is. Mense het selfs in die gange gestaan :) Ek sal jou vertel van die berigte waarna ek kon luister.
Elastiek wat 'n petagreep weeg
Die afdeling het begin met 'n verslag deur Vladimir Lil (SKB-Kontur) oor Elasticsearch in Kontur. Hulle het 'n redelik groot en gelaaide elastiek (~ 800 TB data, ~ 1.3 petagrepe met inagneming van oortolligheid). Elasticsearch vir alle Kontur-dienste is enkel, bestaan uit 2 groepe (van 7 en 9 bedieners), en is so belangrik dat Kontur 'n spesiale Elasticsearch-ingenieur het (in werklikheid Vladimir self).
Vladimir het ook sy gedagtes gedeel oor die voordele van Elasticsearch en die probleme wat dit meebring.
voordele:
- Alle logs is op een plek, maklike toegang daartoe
- Stoor logs vir 'n jaar en ontleed dit maklik
- Hoë spoed van werk met logs
- Cool datavisualisering uit die boks
Probleme:
- Boodskapmakelaar is 'n moet-hê (vir Kontur word sy rol vertolk deur Kafka)
- kenmerke om met Elasticsearch Curator te werk (het periodiek hoë las geskep deur gereelde take in Curator)
- geen ingeboude magtiging nie (slegs vir afsonderlike, redelik groot geld, of as oopbron-inproppe van verskillende grade van gereedheid vir produksie)
Daar was net positiewe resensies oor Open Distro vir Elasticsearch :) Dieselfde kwessie van magtiging is daar opgelos.
Waar kom die petagreep vandaan?Hul nodusse bestaan uit bedieners met 12*8 Tb SATA + 2*2 Tb SSD. Koue berging op SATA, SSD slegs vir warm kas (warm berging).
7+9 bedieners, (7 + 9) * 12 * 8 = 1536 Tb.
'n Deel van die spasie is in reserwe, opsy gesit vir oortolligheid, ens.
Logs van ongeveer 90 aansoeke word na Elasticsearch gestuur, insluitend alle verslagdoeningsdienste van Kontur, Elba, ens.
Kenmerke van ontwikkeling op Serverless
Volgende is 'n verslag deur Ruslan Serkin van DataArt oor Serverless.
Ruslan het gepraat oor wat ontwikkeling met die Serverless-benadering in die algemeen is, en wat die kenmerke daarvan is.
Bedienerloos is 'n benadering tot ontwikkeling waarin ontwikkelaars op geen manier aan die infrastruktuur raak nie. Voorbeeld - AWS Lambda Serverless, Kubeless.io (Bedienerloos binne Kubernetes), Google Cloud Functions.
'n Ideale bedienerlose toepassing is bloot 'n funksie wat 'n versoek aan 'n bedienerlose verskaffer stuur deur 'n spesiale API-poort. 'n Ideale mikrodiens, terwyl AWS Lambda ook 'n groot aantal moderne programmeertale ondersteun. Die koste van instandhouding en ontplooiing van infrastruktuur word nul in die geval van wolkverskaffers, die ondersteuning van klein toepassings sal ook baie goedkoop wees (AWS Lambda - $0.2 / 1 miljoen eenvoudige versoeke).
Die skaalbaarheid van so 'n stelsel is amper ideaal - die wolkverskaffer sorg self daarvoor, Kubeless skaal outomaties binne die Kubernetes-kluster.
Daar is nadele:
- die ontwikkeling van groot toepassings word moeiliker
- daar is probleme met profieltoepassings (slegs logs is vir jou beskikbaar, maar nie profilering in die gewone sin nie)
- geen weergawe nie
Om eerlik te wees, ek het 'n paar jaar gelede van Serverless gehoor, maar dit was al die jare nie vir my duidelik hoe om dit reg te gebruik nie. Na Ruslan se verslag het begrip verskyn, en na die verslag van Nikolai Sverchkov (Evil Martians) van die Backend-afdeling, is dit gekonsolideer. Dit was nie verniet dat ek na die konferensie gegaan het nie :)
CI is vir die armes, of is dit die moeite werd om jou eie CI vir 'n webateljee te skryf?
Mikhail Radionov, hoof van die Flag-webateljee van Jekaterinburg, het gepraat oor selfgeskrewe CI/CD.
Sy ateljee het gegaan van "manual CI/CD" (log by die bediener aan via SSH, doen 'n git pull, herhaal 100 keer per dag) na Jenkins en na 'n selfgeskrewe hulpmiddel wat jou toelaat om kode te monitor en vrystellings genaamd Pullkins uit te voer .
Hoekom het Jenkins nie gewerk nie? Dit het by verstek nie genoeg buigsaamheid verskaf nie en was te moeilik om aan te pas.
"Vlag" ontwikkel in Laravel (PHP-raamwerk). Toe hulle 'n CI/CD-bediener ontwikkel het, het Mikhail en sy kollegas Laravel se ingeboude meganismes genaamd Telescope and Envoy gebruik. Die resultaat is 'n bediener in PHP (let wel) wat inkomende webhook-versoeke verwerk, die frontend en backend kan bou, na verskillende bedieners kan ontplooi en aan Slack rapporteer.
Toe, om blou/groen-ontplooiing uit te voer en eenvormige instellings te hê in dev-stage-prod-omgewings, het hulle na Docker oorgeskakel. Die voordele het dieselfde gebly, die moontlikhede om die omgewing te homogeniseer en naatlose ontplooiing is bygevoeg, en die behoefte om Docker te leer om korrek daarmee te werk, is bygevoeg.
Hoe ons die aantal terugskrywings van bedienervrystellings met 99% verminder het
Die laaste verslag in die Devops-afdeling was van Viktor Eremchenko, hoof-devops-ingenieur by Miro.com (voorheen RealTimeBoard).
RealTimeBoard, die Miro-span se vlagskipproduk, is gebaseer op 'n monolitiese Java-toepassing. Om dit in te samel, te toets en te ontplooi sonder stilstand is 'n moeilike taak. In hierdie geval is dit belangrik om so 'n weergawe van die kode te ontplooi sodat dit nie teruggerol hoef te word nie (dit is 'n swaar monoliet).
Op pad na die bou van 'n stelsel wat jou toelaat om dit te doen, het Miro deur 'n pad gegaan wat ingesluit het werk aan die argitektuur, die gereedskap wat gebruik word (Atlassian Bamboo, Ansible, ens.), en werk aan die struktuur van die spanne (hulle het nou 'n toegewyde Devops-span + baie aparte Scrum-spanne van ontwikkelaars van verskillende profiele).
Die pad blyk moeilik en netelig te wees, en Victor het die opgehoopte pyn en optimisme gedeel wat nie daar geëindig het nie.
Het 'n boek gewen om vrae te vra
Agterkant afdeling
Ek het daarin geslaag om 2 verslae by te woon - van Nikolay Sverchkov (Evil Martians), ook oor Serverless, en van Grigory Koshelev (Kontur-maatskappy) oor telemetrie.
Bedienerloos vir blote sterflinge
As Ruslan Sirkin gepraat het oor wat Serverless is, het Nikolay eenvoudige toepassings gewys wat Serverless gebruik, en gepraat oor die besonderhede wat die koste en spoed van toepassings in AWS Lambda beïnvloed.
'n Interessante detail: die minimum betaalde element is 128 Mb geheue en 100 ms SVE, dit kos $0,000000208. Boonop is 1 miljoen sulke versoeke per maand gratis.
Sommige van Nikolai se funksies het dikwels die 100 ms-limiet oorskry (die hooftoepassing is in Ruby geskryf), so die herskryf daarvan in Go het uitstekende besparings verskaf.
Vostok Hercules — maak telemetrie weer wonderlik!
Die jongste verslag van die Backend-afdeling van Grigory Koshelev (Kontur-maatskappy) oor telemetrie. Telemetrie beteken logs, metrieke, toepassingspore.
Vir hierdie doel gebruik Contour selfgeskrewe gereedskap wat op Github geplaas is. Gereedskap uit die verslag - Hercules, , word gebruik om telemetriedata te lewer.
Vladimir Lila se verslag in die Devops-afdeling het die berging en verwerking van logs in Elasticsearch bespreek, maar daar is steeds die taak om logs van baie duisende toestelle en toepassings af te lewer, en gereedskap soos Vostok Hercules los dit op.
Die kring het 'n pad gevolg wat aan baie bekend is - van RabbitMQ tot Apache Kafka, maar nie alles is so eenvoudig nie)) Hulle moes Zookeeper, Cassandra en Graphite by die kring voeg. Ek sal nie die inligting oor hierdie verslag volledig bekend maak nie (nie my profiel nie), as jy belangstel, kan jy wag vir die skyfies en video's op die konferensie webwerf.
Hoe vergelyk dit met ander konferensies?
Ek kan dit nie vergelyk met konferensies in Moskou en St Petersburg nie, ek kan dit vergelyk met ander geleenthede in die Oeral en met 404fest in Samara.
DAMP word in 8 afdelings gehou, dit is 'n rekord vir Oeral-konferensies. Baie groot Wetenskap- en Bestuursafdelings, dit is ook ongewoon. Die gehoor in Jekaterinburg is redelik gestruktureerd - die stad het groot ontwikkelingsafdelings van Yandex, Kontur, Tinkoff, dit laat sy merk op die verslae.
Nog 'n interessante punt is dat baie maatskappye 3-4 sprekers tegelyk by die konferensie het (dit was die geval met Kontur, Evil Martians, Tinkoff). Baie van hulle was borge, maar die verslae is nogal op gelyke voet met ander, dit is nie advertensieverslae nie.
Om te gaan of nie te gaan nie? As jy in die Oeral of naby woon, het jy die geleentheid en stel jy belang in die onderwerpe - ja, natuurlik. As jy aan 'n lang reis dink, sal ek na die onderwerpe van verslae en videoverslae van vorige jare kyk en 'n besluit geneem.
Nog 'n voordeel van konferensies in die streke, as 'n reël, is dat dit maklik is om na die verslae met die spreker te kommunikeer; daar is eenvoudig minder aansoekers vir sulke kommunikasie.
Dankie aan Dump en Ekaterinburg! )
Bron: will.com