Минатата недела отидов на DUMP IT конференцијата (https://dump-ekb.ru/) во Екатеринбург и сакам да ви кажам што се дискутираше во секциите Backend и Devops и дали вреди да се обрне внимание на регионалните ИТ конференции.
Николај Сверчков од Злобните марсовци за безсервер
Што имаше сепак?
Севкупно, конференцијата имаше 8 секции: Backend, Frontend, Mobile, Testing and QA, Devops, Design, Science и Management.
Најголемите сали, инаку, се во Наука и Менаџмент)) За ~ 350 луѓе секоја. Backend и Frontend не се многу помали. Собата Девопс беше најмалата, но активна.
Ги слушав извештаите во секциите Devops и Backend и малку разговарав со звучниците. Би сакал да зборувам за опфатените теми и да ги разгледам овие делови на конференцијата.
Претставници на SKB-Kontur, DataArt, Evil Martians, веб студиото Екатеринбург Flag, Miro (RealTimeBoard) зборуваа во секциите Devops и Backend. Темите опфатени CI/CD, работењето со услуги на редица, логирање на теми без сервер и работа со PostgreSQL во Go беа добро покриени.
Имаше пријави и од Avito, Tinkoff, Yandex, Jetstyle, Megafon, Ak Bars Bank, но немав време физички да присуствувам на нив (видео снимките и слајдовите од извештаите се уште не се достапни, ветуваат дека ќе ги објават на буни- ekb.ru во рок од 2 недели).
Девопс дел
Она што беше изненадувачки е што делот се одржуваше во најмалата сала, околу 50 седишта. Луѓето дури стоеја на патеките :) Ќе ви кажам за извештаите што успеав да ги слушам.
Еластик со тежина од петабајт
Делот започна со извештај на Владимир Лил (SKB-Kontur) за Elasticsearch во Контур. Тие имаат прилично голем и оптоварен Еластик (~ 800 ТБ податоци, ~ 1.3 петабајти земајќи го предвид вишокот). Elasticsearch за сите услуги на Kontur е единечно, се состои од 2 кластери (од 7 и 9 сервери) и е толку важно што Контур има посебен инженер за Elasticsearch (всушност, самиот Владимир).
Владимир, исто така, ги сподели своите размислувања за придобивките од Elasticsearch и проблемите што ги носи.
Корист:
- Сите дневници се на едно место, лесен пристап до нив
- Складирање на трупци една година и лесно нивно анализирање
- Голема брзина на работа со трупци
- Кул визуелизација на податоци надвор од кутијата
Проблеми:
- брокерот за пораки мора да се има (за Контур неговата улога ја игра Кафка)
- карактеристики на работа со Elasticsearch Curator (периодично креирано големо оптоварување од редовните задачи во Curator)
- нема вградено овластување (само за посебни, прилично големи пари или како приклучоци со отворен код со различен степен на подготвеност за производство)
Имаше само позитивни критики за Open Distro за Elasticsearch :) Истото прашање на авторизација е решено и таму.
Од каде потекнува петабајтот?Нивните јазли се состојат од сервери со 12*8 Tb SATA + 2*2 Tb SSD. Ладно складирање на SATA, SSD само за топла кеш (топло складирање).
7+9 сервери, (7 + 9) * 12 * 8 = 1536 Tb.
Дел од просторот е во резерва, одвоен за технолошки вишок итн.
Дневниците од околу 90 апликации се испраќаат до Elasticsearch, вклучувајќи ги сите услуги за известување на Kontur, Elba итн.
Карактеристики на развој на без сервер
Следно е извештајот на Руслан Серкин од DataArt за Serverless.
Руслан зборуваше за тоа каков е развојот со пристапот без сервер воопшто и кои се неговите карактеристики.
Без сервер е пристап кон развојот во кој програмерите не ја допираат инфраструктурата на кој било начин. Пример - AWS Lambda Serverless, Kubeless.io (без сервер во Kubernetes), Google Cloud Functions.
Идеална апликација без сервер е едноставно функција која испраќа барање до провајдер без сервер преку специјален API Gateway. Идеален микросервис, додека AWS Lambda поддржува и голем број современи програмски јазици. Трошоците за одржување и распоредување на инфраструктурата стануваат нула во случај на даватели на облак, поддршката за мали апликации исто така ќе биде многу евтина (AWS Lambda - 0.2 $ / 1 милион едноставни барања).
Приспособливоста на таков систем е речиси идеална - давателот на облак сам се грижи за ова, Kubeless автоматски се скали во рамките на кластерот Kubernetes.
Има недостатоци:
- развојот на големи апликации станува се потешко
- има потешкотии со профилирањето на апликациите (достапни ви се само дневници, но не и профилирање во вообичаена смисла)
- нема верзии
Да бидам искрен, слушнав за Serverless пред неколку години, но сите овие години не ми беше јасно како правилно да го користам. По извештајот на Руслан, се појави разбирање, а по извештајот на Николај Сверчков (Злобни марсовци) од делот Backend, тоа беше консолидирано. Не залудно отидов на конференцијата :)
CI е за сиромашните, или вреди да напишете свој CI за веб студио?
Михаил Радионов, раководител на веб-студиото Flag од Екатеринбург, зборуваше за самонапишаните CI/CD.
Неговото студио премина од „рачно CI/CD“ (најавете се на серверот преку SSH, правете git pull, повторувајте 100 пати на ден) до Џенкинс и во алатка која самостојно пишува што ви овозможува да го следите кодот и да изведувате изданија наречени Pullkins .
Зошто Џенкинс не работеше? Стандардно не обезбеди доволно флексибилност и беше премногу тешко да се приспособи.
„Flag“ се развива во Laravel (PHP рамка). Кога развивале CI/CD сервер, Михаил и неговите колеги ги користеле вградените механизми на Ларавел наречени Телескоп и Пратеник. Резултатот е сервер во PHP (ве молиме забележете) кој ги обработува дојдовните барања за веб-кука, може да ги изгради предниот дел и задниот дел, да се распореди на различни сервери и да поднесе извештај до Slack.
Потоа, за да можат да изведуваат сино/зелено распоредување и да имаат униформни поставки во средини dev-stage-prod, тие се префрлија на Docker. Предностите останаа исти, додадени се можностите за хомогенизација на околината и беспрекорно распоредување, а додадена е и потребата да се научи Docker да работи правилно со него.
Како го намаливме бројот на враќање на серверот за 99%
Последниот извештај во делот Devops беше од Виктор Еремченко, главен инженер за devops на Miro.com (поранешен RealTimeBoard).
RealTimeBoard, водечкиот производ на тимот на Miro, се базира на монолитна Java апликација. Собирањето, тестирањето и распоредувањето без прекини е тешка задача. Во овој случај, важно е да се распореди таква верзија на кодот за да не мора да се враќа назад (тоа е тежок монолит).
На патот кон изградба на систем кој ви овозможува да го направите ова, Миро помина низ патека која вклучуваше работа на архитектурата, користените алатки (Atlassian Bamboo, Ansible, итн.) и работа на структурата на тимовите (тие сега имаат посветен тим на Devops + многу одделни Scrum тимови од развивачи на различни профили).
Патот се покажа тежок и трнлив, а Виктор ја сподели насобраната болка и оптимизам што не заврши тука.
Освои книга за поставување прашања
Заден дел
Успеав да присуствувам на 2 извештаи - од Николај Сверчков (Злобни марсовци), исто така за безсервери и од Григориј Кошелев (компанија Контур) за телеметрија.
Без сервер за обични смртници
Ако Руслан Сиркин зборуваше за тоа што е без сервер, Николај покажа едноставни апликации користејќи „Без сервер“ и зборуваше за деталите што влијаат на цената и брзината на апликациите во AWS Lambda.
Интересен детал: минималниот платен елемент е 128 Mb меморија и 100 ms процесор, чини 0,000000208 долари. Покрај тоа, 1 милион вакви барања месечно се бесплатни.
Некои од функциите на Николај често ја надминуваа границата од 100 ms (главната апликација беше напишана во Ruby), така што нивното препишување во Go обезбеди одлична заштеда.
Восток Херкулес - направи телеметријата повторно одлична!
Најновиот извештај на делот за Backend од Григориј Кошелев (компанија Контур) за телеметријата. Телеметрија значи логови, метрика, траги од апликации.
За таа цел, Contour користи алатки кои сами се пишуваат објавени на Github. Алатка од извештајот - Херкулес, , се користи за доставување телеметриски податоци.
Извештајот на Владимир Лила во делот Devops дискутираше за складирање и обработка на дневници во Elasticsearch, но сè уште постои задача да се доставуваат дневници од многу илјадници уреди и апликации, а алатките како Vostok Hercules ги решаваат.
Колото го следеше патот познат на многумина - од RabbitMQ до Apache Kafka, но не е сè толку едноставно)) Тие мораа да ги додадат Zookeeper, Cassandra и Graphite на колото. Нема целосно да ги обелоденам информациите за овој извештај (не мојот профил), доколку сте заинтересирани, можете да ги почекате слајдовите и видеата на веб-страницата на конференцијата.
Како се споредува со другите конференции?
Не можам да го споредам со конференции во Москва и Санкт Петербург, можам да го споредам со други настани на Урал и со 404фест во Самара.
DAMP се одржува во 8 секции, ова е рекорд за конференциите во Урал. Многу големи секции за наука и менаџмент, ова е исто така необично. Публиката во Екатеринбург е прилично структурирана - градот има големи развојни оддели за Yandex, Kontur, Tinkoff, и тоа остава свој белег на извештаите.
Друга интересна поента е што многу компании имаат 3-4 говорници на конференцијата одеднаш (таков беше случајот со Kontur, Evil Martians, Tinkoff). Многу од нив беа спонзори, но извештаите се сосема на исто ниво со другите, тоа не се рекламни извештаи.
Да се оди или да не се оди? Ако живеете на Урал или во близина, имате можност и ве интересираат темите - да, секако. Ако размислувате за долго патување, би ги разгледал темите на извештаите и видео извештаите од претходните години и донесе одлука.
Друга предност на конференциите во регионите, по правило, е тоа што е лесно да се комуницира со говорникот по извештаите, едноставно има помалку апликанти за таква комуникација.
Благодарение на Дамп и Екатеринбург! )
Извор: www.habr.com
