Здесь переводится видео в статью Дмитрия Чумак из ITSumma "От репозитория до CICD-инфраструктуры в продакшне за неделю"
Ссылка на видеодоклад https://www.youtube.com/watch?v=upHLuHD8xtQ
Текст сделан из субтитров. Буду очень благодарен в форматировании текста, его вычитки. Для этого достаточно знать русский язык. Присылайте свои pull request или присылайте текст на почту patsev.anton[собака]gmail.com
меня зовут ким ок дмитрий я работаю в компании эти суммы начальником отдела администрирования системы некоторые из вас наверное уже слышали раньше про нашу компанию слышали кто слышал про нашу компанию поднимите руки но видимо не все для всех остальных наверно все таки стоит пояснить немножко мы работаем на рынке высокотехнологичных услуг с 2008 года и основным видом нашей деятельности является поддержка интернет-проектов разного уровня от небольших интернет магазинов и заканчивая такими проектами как kupivip хабрахабр постнаука наше радио и многие другие тут лишь некоторые перечисленные на слои в целом что именно обычно люди подразумевают под термином техническая поддержка чего вообще люди ждут обычно представляется что это ну в первую очередь мониторинге это реакция на allure ты на то что там что-то сломалось и нужно починить это взаимодействие с хостерами то там не знаю замена жестких дисков починка рейдов и всякие такие вот повседневные вещи но на самом деле это только первый самый базовый уровень контроля стабильности работы любого интернет проекта ведь на самом деле вы наверняка часто видели конечно вот такие сообщения например hetzner и ребята вы простите у нас тут все . немного лежит вы потерпите все будет хорошо но наверное ничуть не реже вы видели от коллег вот такие сообщения вы знаете я тут нажал git pull и все пропало пожалуйста помогите что мне делать зачем нужен вообще все и сиди представьте вот есть у вас небольшой проект там вы пишите какой нибудь новостной ресурс блог про музыку еще что-нибудь у вас есть один сервер там крутится веб-сервер база скрипты какие-то может быть поисковый движок небольшой вот и разработчики выкатывают новую версию они идут на сервер а там делают git pull обновляют каши еще какие такие повседневные операции но со временем ваш проект растет прошло там полгода год у вас значительно выросло количество посетителей их там будет миллион в месяц у вас уже несколько выделенных серверов по 2 поддельные сервера под базу под реплики б д под резервы под бэкапы отдельный сервер под статику какую-нибудь вот вместо одного сервера вас уже получается ну 20-30 как с этим жить как выкатывать новые релизы то есть это постоянно продолжать вот так вот руками все это делать ну если у вас есть выделенная команда админов то рано или поздно она достигнет какого-то потолка своих собственных физических возможностей и команду вам придется расширять если же у вас нет отдельной команды админов то как бы вам вообще не с руки этим всем заниматься потому что разработчикам нужно фиксит баги им нужно выкатывать новые версии вообще заниматься разработкой а как жить в такой ситуации ну можно конечно расширять штат а можно просто перестать быть админской ремесленной мастерской и начать уже наконец то выстраивать нормальные производственные цепочки что такое сей сиди вообще это идея это методологии это вот все в головах в первую очередь эта идея о том что у вас должно быть изолирована и prada кружение изолированный дев не должно быть возможности тарам парам пам пам вот не должна быть возможность и пушить ой папулей сразу что-то там на мастере как только вы разработали новую фичу продукт должен проходить несколько стадий жизненных циклов перед выходом в прод это должно быть какое-то тестирование базовые вещи и все эти вещи должны быть максимально автоматизированный чтобы избавиться от рисков человеческого фактора когда человек идет на проданный сервер что-то там пули то потом вдруг оказывается что он спорил не ту ветку неистовой репозиторий и в общине тот проект я вот нажала на все пропало этого максимально нужно избежать вообще об инструментах которые облегчают внедрение таких методологий обычно принято говорить больше в таком теоретическом ключе вот допустим есть докер классные ребята его написали можно любой слов запихивать контейнер есть предсказуемо и окружение его можно запускать в любом месте и вы всегда будете знать как он будет работать можно там арно обновлять эти контейнеры работать с каким-то софтом как с минимальной такой единицей можно обновлять можно сразу несколько версий этого софта держать на сервере очень удобно и круто а вот есть другие ребята из google они написали удобную панельку для докера она называется кубер ниц вот там можно нажимать кнопочки оно там будет как-то делать авто скиллинг как-то вам заменять контейнеры и всякое такое прочее вот вам ссылка на документацию вот три строчки из конфига развлекаетесь и ну подумайте придумайте как именно вам это реализовать у себя я же хотел поговорить о об этом больше в таком практическом ключе на примере наших хороших товарищей из проекта эдвин что такой проект эдвин это репетитор английского языка в виде чат-бота что-то вроде наверное можно было бы сказать похоже на lingualeo например но не в виде отдельного сайта или сервиса просто виде чат-бота прямо внутри вашего facebook messenger они пришли к нам этой зимой уже в общем-то готовым к публикации проектом и хотели от нас разработки архитектуры проекта будущего prada хотели чтобы мы помогли им разработать все производственные цепочки вот и чтобы впоследствии можно было легко и быстро расширять архитектуру целом изначально проект разрабатывался в таком микро сервисном стиле поэтому единицей базовое естественно были выбраны докер контейнеры но как сделать так чтобы сервисы эти внутри контейнеров всегда могли знать друг о друге всегда могли найти друг друга и собственно взаимодействовать обмениваться данными и прочее даже если конфигурации сети как-то значительно поменяется и чтобы при этом админа мне приходилось залезать в конфиге залезать в контейнеры и что-то править руками для этого человечество придумало очень интересный такой вид программном обеспечении он называется сервис discovery в целом наверно технически конечно это некорректно так называть но можно для упрощения обозвать таким dns для бизнес-логики вот как готовить ну мы уже поняли примерно как мы представляем себе общую архитектуру а как готовить новые сервера быстро и надежно ведь на самом деле там каждый сервер под контейнеры нужно правильно установить нужно корректной разбивкой дисков нужны правильные настройки сети те же параметры ядра на самом деле зачастую достаточно далеки от того что хотелось бы вообще видеть продакшене для этого мы использовали анти был с несколькими рецептами на земле вот когда мы понимаем о том как нам работать с общей инфраструктурой собственно пора задуматься на тем как именно мы будем реализовывать континент kreation в целом самым популярным сейчас ну по крайне мере он больше всех на слуху инструментом по жонглированию докер контейнерами является убирается от google но нам он показался достаточно тяжеловесным и плохо контролируемым изнутри сложно мониторить взаимодействие во внутренних узлов и поэтому мы решили поискать какой нибудь боли и легковесное решение либо же попробовать сконструировать собственные из меньших функциональных блоков по итогу мы остановились на дисплей панели гусь иди в связке с консулом и небольшой скриптовой обвязкой для базовых операций там типа копирования контейнеров между серверами и вот всякое такое в целом на самом деле все это может звучать не очень сложно но тут вмешивается такой фактор что пока велось обсуждение подключения проекта обсуждение всяких договоров и бюрократических всех вещей до назначенного заранее релиза осталась неделя и собственно вот нужно было как-то быстро придумать на чем именно все это реализовать и внедрить ну и собственно как это происходило в реальном времени в первый день мы получаем ты же получаем доступ к площадке разработчик sky смотрим что там установлена как она друг с другом взаимодействуют мониторим это все чтобы понять где могут быть какие-то узкие момент узкие места где системы может тормозить на основе полученных данных мы пишем on тепловые рецепты чтобы в дальнейшем быстро теплеет новые сервера заводим в амазоне отдельный лифт он проявит клауд под продакшен и под стоишь и устанавливаем там сервера со контейнеры со всеми нужными сервисами из основного это б д подгрести л графова я бы дэниэл for джей сервис очередей рыбе темпе и собственно контейнеры с самим кодом проекта во второй день мы на отдельном сервере устанавливаем deploy панель гоу сиди устанавливаем сервис discovery концу пишем первые pipeline и для сервисов это сборка кода сборка контейнеров и катка контейнеров на стейдж тестирование выкатка контейнеров на продакшен отдельный pipeline по откату на выбранную предыдущую версию потому что ну мало ли что может вдруг произойти вот в третий день в среду мы занимаемся тестированием всего того что мы успели наворотить проверяем что она все между собой правильно за и взаимодействуют что при нажатии кнопки диплом в панели забирается нужный код из нужного репозитории из нужной ветки из этого кода собирается правильный контейнер он заливается на нужный сервер он заявляет о себе консулу и сервисы вокруг него могут его видеть с ним взаимодействовать и собственно что вся система сама работает к вечеру мы создаем в соседние зоне доступности амазона сервера повода реплики и резервы баз данных с разработчиками заливаем рабочие собственно данные в базы и уходим домой в четверг мы передаем все данные по системе разработчикам и уже они со своей стороны проверяют что все работает так как нужно все те же самые сборки те же самые выкатки откаты и прочее и тут на самом деле стоит сказать о том что в целом система вот сей сиена уже готова сейчас идет только проверка тестирование что все корректно работает и тут оказывается что при обсуждении технического задания мы в целом забыли обсудить такую важную вещь как сборка логов всех системных логов от разных сервисов в целом не очень долго думая мы решаем использовать икебану в общем довольно популярный инструмент для таких дел как бы и мы неоднократно сталкивались с ней на проектах наших клиентов мы в некоторых местах используемые у себя внутри для сбора разных данных от мониторингов анализ alert of например вот и остаток дня собственно мы настраиваем лог стрижки баны мы строим сборщики лагов и все на пятый день собственно проект готов к запуску в пятницу разработчики уже пользуясь новой на стройной системой выпускают у себя внутри первые новые версии нас 3g тестируют проверяют как это все работает мы же остаемся на подхвате мы следим за тем что как работает в общем то ну решаем конечно всякие возникающие проблемы типа вот у нас тут вот где залипает а вот здесь вот рыбе thank you почему-то медленно обрабатывает сообщение и такого рода вещи но это вещи такие простые админские они собственно все и сиди и отношения не имеют что мы получили по итогу мы по итогу получили удобную модульную систему разработки можно так сказать удобный последовательный процесс жизни каждого релиза когда он от выката выкатки с дев ветки проходит стадии тестирования prep рода где он проверяется на то что он корректно работает в окружении идентичным продал ему и как он скатывается потом в пруд или откатываться обратно если вдруг что-то пошло не так также у нас есть три полностью изолирован их окружения а не изолированы друг от друга сразу на двух уровнях во первых они находятся в разных virtual правят клауд амазона а во-вторых в контуре заведены отдельные это центры и сервисы внутри них общаются между собой изолирована то есть даже при очень большом желании сломать продакшен какими-то действиями на 9 довольно сложно какие проблемы нам встретились в целом организационно проблем нам почти не встретилось софт довольно простой и конкретных каких-то особых проблем встретили но вот amazon веб-сервисе снам подкинул пару задач занятных в первую очередь стоит конечно помнить что дефолтные amazon новые образы из которых собираются инстанциями linux это конечно когда-то была centos redhat но он значительно так изменен под нужды амазона и первое с чем мы столкнулись это при настройке консула amazon нам ломал dns резольвер и внутри серверов то есть при перезагрузке он вы потешные данные заливает снова в резул веры и взаимодействие между серверами через консул теряется целом там есть возможность через панель добавить кастомные правило но нам к сожалению пока не удалось окончательно победить эту беду консул все равно ломается по итогу мы просто отобрали у системы права на редактирование гетце рисовку и живем так по 2 интересная беде она в общем не беда но так интересный момент апликэйшен балансир амазона в апликэйшен балансир требует чтобы папины находились в разных зонах доступности это в целом нормально это правильно это логично вопрос с другом когда у вас есть уже готовый установленный virtual пройдет клауда в одной зоне у вас нет возможности докинуть еще сетей из соседней зоной доступности и докинуть брендов оттуда все эти вещи они определяются на момент инициализации virtual правят кладу и добавить существующий их нет возможности об этом стоит помнить заранее предусмотреть иначе придется как бы переделать с нуля ну и на этом на самом деле практически все что хотелось бы сказать в общем у такого не стоит бояться расти не стоит боятся менять свои рабочие процессы рабочие привычки если того требует момент если того требует стадии развития вашего проекта на самом деле всё не так сложно как может показаться на первый взгляд главное с умом подходить к выбору технологий не гнаться за какой то эфемерные мода и там вот смотрите вот тут новая классная штука давайте срочное язык выкатим в продакшен нужно думать на тему чего именно вам действительно не хватает разумно подходить к выбору инструментов и в целом как бы этот процесс можно осилить очень малыми силами какие есть дальнейшие планы по развитию конкретного проекта первую очередь конечно после того как сейчас уже прошло месяца наверно 4 месяца уже после релиза аудитория значительно растет вместе с аудитории растет парк вычислительных мощностей amazon в общем не славятся демократическими ценами конечно поэтому в первую очередь думаем о том что нужно вводить авто скиллинг чтобы в не пиковые часы можно было лишнее мощности выключать и на этом экономить уже довольно значительные суммы из плюшек для разработчиков хотелось бы подключить ко всей этой системе bug tracker на основе дыры чтобы когда разработчики выкатывают новый релиз можно было ну чтобы система сама ходила в git смотрела какие баги и фичи были сделаны в этом релизе потом с нужными номерами заявок ходила в дыру привязывала к новому релизу в жире все заявки выпускала релиз и отдавала красивый или знать из в целом проект растет проект развивается дальше больше ждем новых интересных задач но на этом пока все с вами был дмитрий чумак компания эти сумма и в целом все кому близок и интересен highload и поддержка интернет-проектов разных я вас приглашаю наше сообщество аптайм комьюнити у нас есть телеграм чатик у нас есть сообщество фейсбуке где мы общаемся на все такие животрепещущие админские вопросы всем спасибо вопросу [музыка] спасибо за доклад вопрос такой а можно подетальнее пояснить вот у вас для каждого окружения консул кластер он отдельный или он один на все три окружения между собой связаны консул один общий внутри него есть такая такой как сказать термин как дата-центр вот оао они сами между собой не сообщаются да а сам по себе instance консула вон один ну то есть если еще раз еще раз в каждом окружении один instance кластера консул так или нет 1 кластер одно ну давай кластер или а смысле про это нет в кластере несколько 3 5 но давай в отдельном окружения да да да да да сейчас наш мир вам несколько именно но и они разделены между собой эти то есть у вас 3 классе обучаются отдельных нет консул 111 бастер один кластер размазана все 3 января ты знаешь между ними есть связь ну в целом нет настраивается подключение именно в рамках одного конкретного дата центра ведь каждый каждая но да каждый кластер в окружении знает о другом data center ну пойди да значит есть связь [смех] я понял в общем словно в этом был вопрос как организован кластер то есть либо это у вас отдельные разделенные ворами это абсолютно разделены друг от друга отдела получается несвязно консул один они связаны в частности скунс спасибо за доклад у меня вопрос ну вы не озвучиваю наверняка сталкивались с этой темой то есть в нашей компании огромная боль это то что тех люди тратят огромное количество времени на review кода и то есть есть же возможности в рамках я как-то автоматизировать процесс то есть проверить сборку ну в частности босха лавандин да то есть есть такие возможности вы сталкивались с этой проблемой как вы ее решили мы пока нет мы больше и занимаемся именно а организационным вопросам то есть мы настраиваем систему а какие именно дальше деталь единственно конкретные инструменты этой системы будут будут пользовать разработчики мы как бы не указываем то есть если там нужно какой-то интерны этапе включать то в целом мы можем помочь но на данный момент на сколько я знаю нет не проводятся такие проверки хорошо спасибо запомните здравствуйте расти спасибо за доклад могли бы вы более подробно рассказать как осуществлялись и процедуры на том или иной стадии прохождения проекта по цепочке сидим в общем-то вручную с админской стороны вручную то есть мы запускаем первый этап идем и смотрим что она правильно заде плелась что она увидела друг друга все вручную до автоматизировать и пока у нас это несколько сложно потому что как бы клиенты всегда разные там разные окружения и выработать какой-то один универсальный инструмент для таких вещей пока представляется довольно сложной затей но интересный безусловно здравствуй спасибо за доклад у меня на самом деле два вопроса первый касается отслеживание изменений и понимание того кто внес конкретное изменение на каком этапе допустим как вы понимаете что предположим там вася пупкин внес изменения в дев стенд который там затронула там такие такие вещи и потом там на прот допустим это запушил там petrol все окружение они разворачиваются анти блам и и все эти скрипты они лежат в репе и как бы доступ в репе крепи идет по естественно по отдельным аккаунтом по ключам ну и второй такой вопрос который я думаю тут многих волнует с учетом того что вы хотите интеграции с дыры там мы с прочими вещами а где дженкинс вместо дженкинса гусь егэ ну то есть они на самом деле очень близки в общем то они делают одно и то же мы на самом деле сталкивались своей практике и из тем и с другим и по совокупности опыта это практически субъективное мнение гусь едином показался более дружелюбным более удобным в целом там есть из коробки довольно приятные плюшки типа шаблонов для задачи шаблонов для pipeline of которых джин кинсей из коробки нет там вроде как есть возможность как-то этот через плагин и реализовать там потанцевать приходится но раз есть готовая зачем 9 потом вот там поднял опустил но на первый вопрос на самом деле в самом начале уже ответили как тоже хотел спрашивать про консул посколько больная довольно тема и видно что дата-центр одним не значит у них есть связи со слайда сразу видно второй собственно по поводу амазона сказали что вроде бы используете их балансировщик встроенный да собственно что для контейнеров используются вот об этом и сейас амазонский или что-то свое и а почему собственно не то из г если уже как бы и так все предпосылки для этого ей и c&c со на этапе разработки ребята из эдвина использовали но по итогу решили делать 6 это решение потому что и dcs как любая такая облачная штука он привык к определенным парадигмам использования и там отступление плюс-минус как бы не особо поощряется в лице си например нельзя взять один и тот же контент просто вот один контейнер и прокинув ему разные параметры окружения запустить в разных ролях например там есть сервис конкретизированный для лакирования бизнесовая логике там он от самого самого приложения получать действия пользователей всякое такое вот в целом контейнер он один его нет никакой необходимости как-то менять хотелось бы просто ему прокидывать разные переменные и чтобы он в разные места складывал эти лаги в рамках и cs а для этого приходится делить несколько разных контейнеров а это ну несколько усложняет все-таки поддержку поэтому тогда понятно почему собственно изгонит у вопросы а вот товарищи оранжевым или в красном посмели оранжевый до цвет скажите инстансы у вас с амазоне reserved а скорее всего да я так вот честно на память и не вспомню а enhance натур кинг используется тарам парам парам пам парам и не помню можем можно посмотреть мои чуть позже свяжемся при дупло и в amazon нового кластер а были ли у вас проблемы с тем что перформанс degradation дую какого-то во времени промежутка там есть фишка в том что в зависимости от типа инстанса они дают очень разную сеть ну это это да там допустим на микре там что-то мегабит 5 что лего час точно не помню мы специально замеряли несколько разных типов прогоняли вот и если более менее мощный instance там как бы таких проблем не возникало ну и у нас нет не было таких мне turk перформанс degradation и опыт игра дышим и по мониторингу вот это всего добра просто мы сталкивались с тем что amazon может если не pro-vision tabs инженер лаптях не отлажен начать резать может сейчас используется pro-vision ты ли не pro-vision ты почему я не скажу сейчас на память а но как бы такой явные проблемы не возникало скорее всего проверено да а вы считаете да как-то заранее прикидываем да потому что правая проводятся тесты над деве нагрузочные как бы чтобы понимать примерно чего ожидать еще вопроса вопросов нет большое спасибо большое спасибо вам