La setmana passada vaig anar a la conferència de DUMP IT (https://dump-ekb.ru/) a Iekaterinburg i vull explicar-vos què es va parlar a les seccions Backend i Devops, i si les conferències regionals de TI mereixen la pena.
Nikolay Sverchkov de Evil Martians sobre Serverless
Què hi havia de totes maneres?
En total, la conferència va tenir 8 seccions: Backend, Frontend, Mobile, Testing and QA, Devops, Design, Science and Management.
Les sales més grans, per cert, són a Science and Management)) Per a ~ 350 persones cadascuna. Backend i Frontend no són molt més petits. La sala Devops era la més petita, però activa.
Vaig escoltar els informes de les seccions Devops i Backend i vaig parlar una mica amb els ponents. M'agradaria parlar dels temes tractats i repassar aquestes seccions a la conferència.
Representants de SKB-Kontur, DataArt, Evil Martians, Ekaterinburg web studio Flag, Miro (RealTimeBoard) van parlar a les seccions Devops i Backend. Els temes tractats CI/CD, el treball amb serveis de cua, el registre; Els temes sense servidor i el treball amb PostgreSQL a Go es van tractar bé.
També hi havia informes d'Avito, Tinkoff, Yandex, Jetstyle, Megafon, Ak Bars Bank, però no vaig tenir temps per assistir-los físicament (encara no estan disponibles les gravacions de vídeo i les diapositives dels informes, prometen publicar-los en 2 setmanes). a dump-ekb.ru).
Secció Devops
El que va sorprendre va ser que la secció es fes a la sala més petita, unes 50 places. Fins i tot hi havia gent parada als passadissos :) Us explicaré els reportatges que vaig aconseguir escoltar.
Elàstic que pesa un petabyte
La secció va començar amb un informe de Vladimir Lil (SKB-Kontur) sobre Elasticsearch a Kontur. Tenen un Elàstic força gran i carregat (~800 TB de dades, ~1.3 petabytes tenint en compte la redundància). Elasticsearch per a tots els serveis de Kontur és únic, consta de 2 clústers (de 7 i 9 servidors) i és tan important que Kontur té un enginyer especial d'Elasticsearch (de fet, el mateix Vladimir).
Vladimir també va compartir els seus pensaments sobre els beneficis d'Elasticsearch i els problemes que comporta.
Benefici:
- Tots els registres estan en un sol lloc, fàcil accés a ells
- Emmagatzemar registres durant un any i analitzar-los fàcilment
- Alta velocitat de treball amb registres
- Visualització de dades genial fora de la caixa
Problemes:
- L'agent de missatges és imprescindible (per a Kontur el seu paper el fa Kafka)
- característiques de treballar amb Elasticsearch Curator (càrrega elevada creada periòdicament a partir de tasques habituals a Curator)
- sense autorització integrada (només per a diners separats, bastant grans o com a connectors de codi obert amb diferents graus de preparació per a la producció)
Només hi va haver ressenyes positives sobre Open Distro for Elasticsearch :) El mateix problema d'autorització s'ha resolt allà.
D'on ve el petabyte?Els seus nodes consisteixen en servidors amb 12*8 Tb SATA + 2*2 Tb SSD. Emmagatzematge en fred a SATA, SSD només per a la memòria cau calenta (emmagatzematge en calent).
7+9 servidors, (7 + 9) * 12 * 8 = 1536 Tb.
Part de l'espai està reservat, reservat per a la redundància, etc.
Els registres d'unes 90 aplicacions s'envien a Elasticsearch, inclosos tots els serveis d'informes de Kontur, Elba, etc.
Característiques de desenvolupament en Serverless
El següent és un informe de Ruslan Serkin de DataArt sobre Serverless.
Ruslan va parlar sobre què és el desenvolupament amb l'enfocament Serverless en general i quines són les seves característiques.
Sense servidor és un enfocament del desenvolupament en el qual els desenvolupadors no toquen la infraestructura de cap manera. Exemple: AWS Lambda Serverless, Kubeless.io (Sense servidor dins de Kubernetes), Google Cloud Functions.
Una aplicació sense servidor ideal és simplement una funció que envia una sol·licitud a un proveïdor sense servidor mitjançant una passarel·la API especial. Un microservei ideal, mentre que AWS Lambda també admet un gran nombre de llenguatges de programació moderns. El cost de manteniment i desplegament de la infraestructura esdevé zero en el cas dels proveïdors de núvol, el suport d'aplicacions petites també serà molt barat (AWS Lambda - 0.2 $ / 1 milió de sol·licituds simples).
L'escalabilitat d'aquest sistema és gairebé ideal: el proveïdor de núvol s'encarrega d'això mateix, Kubeless escala automàticament dins del clúster de Kubernetes.
Hi ha desavantatges:
- el desenvolupament d'aplicacions grans és cada cop més difícil
- hi ha dificultats amb les aplicacions de perfils (només tens accés als registres, però no la creació de perfils en el sentit habitual)
- sense versions
Per ser sincer, vaig sentir parlar de Serverless fa uns anys, però durant tots aquests anys no em va quedar clar com utilitzar-lo correctament. Després de l'informe de Ruslan, va aparèixer l'entesa, i després de l'informe de Nikolai Sverchkov (Evil Martians) de la secció Backend, es va consolidar. No va ser en va que vaig anar a la conferència :)
CI és per als pobres, o val la pena escriure el vostre propi CI per a un estudi web?
Mikhail Radionov, cap de l'estudi web Flag de Iekaterinburg, va parlar sobre CI/CD autoescrita.
El seu estudi ha passat de "CI/CD manual" (iniciar sessió al servidor mitjançant SSH, fer un git pull, repetir 100 vegades al dia) a Jenkins i a una eina d'escritura pròpia que us permet supervisar el codi i realitzar llançaments anomenats Pullkins. .
Per què Jenkins no va treballar? No proporcionava prou flexibilitat per defecte i era massa difícil de personalitzar.
"Flag" es desenvolupa a Laravel (marc PHP). Quan van desenvolupar un servidor CI/CD, Mikhail i els seus col·legues van utilitzar els mecanismes integrats de Laravel anomenats Telescope and Envoy. El resultat és un servidor en PHP (si us plau, tingueu en compte) que processa les sol·licituds de webhook entrants, pot crear la interfície i el backend, desplegar-se a diferents servidors i informar a Slack.
Aleshores, per poder realitzar un desplegament blau/verd i tenir una configuració uniforme en entorns de producció en fase de desenvolupament, van canviar a Docker. Els avantatges van continuar sent els mateixos, es van afegir les possibilitats d'homogeneïtzar l'entorn i un desplegament perfecte i es va afegir la necessitat d'aprendre Docker a treballar-hi correctament.
Com hem reduït un 99% el nombre de reversions de llançaments del servidor
L'últim informe de la secció Devops va ser de Viktor Eremchenko, enginyer principal de devops a Miro.com (abans RealTimeBoard).
RealTimeBoard, el producte estrella de l'equip Miro, es basa en una aplicació monolítica de Java. Recollir-lo, provar-lo i desplegar-lo sense temps d'inactivitat és una tasca difícil. En aquest cas, és important desplegar aquesta versió del codi perquè no s'hagi de revertir (és un monòlit pesat).
En el camí de construir un sistema que permeti fer-ho, Miro va passar per un camí que incloïa treballar l'arquitectura, les eines utilitzades (Atlassian Bamboo, Ansible, etc.) i treballar l'estructura dels equips (ara tenen un equip Devops dedicat + molts equips Scrum separats de desenvolupadors de perfils diferents).
El camí va resultar difícil i espinós, i Víctor va compartir el dolor i l'optimisme acumulats que no van acabar aquí.
Va guanyar un llibre per fer preguntes
Secció de backend
Vaig aconseguir assistir a 2 informes: de Nikolay Sverchkov (Evil Martians), també sobre Serverless, i de Grigory Koshelev (empresa Kontur) sobre telemetria.
Sense servidor per a simples mortals
Si Ruslan Sirkin va parlar del que és Serverless, Nikolay va mostrar aplicacions senzilles amb Serverless i va parlar dels detalls que afecten el cost i la velocitat de les aplicacions a AWS Lambda.
Un detall interessant: l'element mínim de pagament és de 128 Mb de memòria i 100 ms de CPU, costa 0,000000208 $. A més, 1 milió de sol·licituds d'aquest tipus al mes són gratuïtes.
Algunes de les funcions de Nikolai sovint superaven el límit de 100 ms (l'aplicació principal estava escrita en Ruby), de manera que reescriure-les a Go va proporcionar un estalvi excel·lent.
Vostok Hercules: torneu a fer que la telemetria sigui fantàstica!
L'últim informe de la secció Backend de Grigory Koshelev (empresa Kontur) sobre telemetria. Telemetria significa registres, mètriques, rastres d'aplicacions.
Per a aquest propòsit, Contour utilitza eines escrites per si mateix publicades a Github. Eina de l'informe - Hèrcules, , s'utilitza per lliurar dades de telemetria.
L'informe de Vladimir Lila a la secció Devops va parlar de l'emmagatzematge i processament de registres a Elasticsearch, però encara hi ha la tasca de lliurar registres de molts milers de dispositius i aplicacions, i eines com Vostok Hercules els resolen.
El circuit va seguir un camí conegut per molts: des de RabbitMQ fins a Apache Kafka, però no tot és tan senzill)) Van haver d'afegir Zookeeper, Cassandra i Graphite al circuit. No revelaré completament la informació d'aquest informe (no el meu perfil), si esteu interessats, podeu esperar les diapositives i els vídeos al web de la conferència.
Com es compara amb altres conferències?
No puc comparar-ho amb les conferències de Moscou i Sant Petersburg, el puc comparar amb altres esdeveniments als Urals i amb el 404fest de Samara.
DAMP es celebra en 8 seccions, això és un rècord per a les conferències Ural. Seccions de Ciència i Gestió molt grans, això també és inusual. El públic a Ekaterinburg està força estructurat: la ciutat té grans departaments de desenvolupament per a Yandex, Kontur, Tinkoff, i això deixa la seva empremta als informes.
Un altre punt interessant és que moltes empreses tenen 3-4 ponents a la conferència alhora (és el cas de Kontur, Evil Martians, Tinkoff). Molts d'ells eren patrocinadors, però els reportatges estan força a l'alçada d'altres, no són reportatges publicitaris.
Anar o no anar? Si vius als Urals o a prop, tens l'oportunitat i t'interessen els temes, sí, és clar. Si esteu pensant en un viatge llarg, miraria els temes de reportatges i reportatges en vídeo d'anys anteriors i va prendre una decisió.
Un altre avantatge de les conferències a les regions, per regla general, és que és fàcil comunicar-se amb el ponent després dels informes; simplement hi ha menys sol·licitants per a aquesta comunicació.
Gràcies a Dump i Ekaterinburg! )
Font: www.habr.com