» » » CICD: бесшовный деплой на распределенные кластерные системы без даунтаймов

 

CICD: бесшовный деплой на распределенные кластерные системы без даунтаймов

Автор: admin от 9-10-2018, 13:45, посмотрело: 81

Выкладываю второй доклад с нашего первого митапа, который провели в сентябре. В прошлый раз можно было почитать (и посмотреть) про использование Consul для масштабирования stateful-сервисов от Ивана Бубнова из BIT.GAMES, а сегодня поговорим про CICD. Точнее расскажет об этом наш системный администратор Егор Панов, который отвечает за доступность инфраструктуры и сервисов в Pixonic. Под катом — расшифровка выступления.





как мы выбирали Graylog и как устанавливали. В любом случае он помогает отдебажить, если какая-то проблема все-таки случилась.



CICD: бесшовный деплой на распределенные кластерные системы без даунтаймов
Вот на этой базе уже можно переходить к деплою.



CICD: бесшовный деплой на распределенные кластерные системы без даунтаймов
Но про деплой я уже рассказал во втором пункте, поэтому не буду сильно останавливаться на этом. Скажу один лайфках: если вы используете Ansible, обязательно добавьте вот этот serial, который на слайде. Не раз бывало, что ты запускаешь что-то, а потом понимаешь, а я не то запустил, или не туда, или не то и не туда, а потом видишь, что это всего лишь один сервер. А мы потерять один сервер легко можем и ты просто его заново перезаливаешь, никто и не заметил.



Плюс установили хранилище артефактов на Nexus — он является единой точкой входа абсолютно для всех, не только для CI.



CICD: бесшовный деплой на распределенные кластерные системы без даунтаймов
И это очень помогает нам обеспечить повторяемость. Ну и так как нексусы могут работать как прокси-сервисы в разных регионах, то они ускоряют деплой, установку rpm-пакетов, докер-образов, чего угодно.



Когда закладываешь новый проект, желательно выбирать компоненты, которые легко поддаются автоматизации. Например с Photon-сервером нам это не удалось. В любом случае, это было лучшее решение по другим параметрам. А вот Cassandra, например, очень удобно обновляется и автоматизируется.



CICD: бесшовный деплой на распределенные кластерные системы без даунтаймов
Вот пример одного из наших проектов. Клиент приходи на APP-сервер, где у него лежит профиль в БД Cassandra, а потом идет на мастер-сервер, который при помощи матчмейкинга дает ему уже гейм-сервер с какой-то комнатой. Все остальные сервисы сделаны в виде «приложения — БД» и обновляется точно таким же образом.



Второй момент — нужно обеспечить простую малосвязанную архитектуру для деплоя. Нам это удалось.



CICD: бесшовный деплой на распределенные кластерные системы без даунтаймов
Смотрите, обновляем например app-сервер. У нас есть выделенные сервисы дискавери, которые реконфигурируют балансировщик, поэтому мы просто приходим к app-сервер, тушим его, он вылетает из балансировки, обновляем и все. И так с каждым по отдельности.



Мастер-сервера обновляются почти идентично. Клиент пингует каждый мастер-сервер в регионе и идет на тот, на котором пинг лучше. Соответственно, если мы обновляем мастер-сервер, то может быть игра чуть-чуть помедленнее будет идти, но обновляется это легко и просто.



Гейм-сервера обновляются немного по-другому, потому что там все-таки идет игра. Мы идем в матчмейкинг, просим его выкинуть определенный сервер с балансировки, приходим на гейм-сервер, ждем, пока игр не станет ровно ноль, и обновляем. Потом возвращаем обратно в балансировку.



CICD: бесшовный деплой на распределенные кластерные системы без даунтаймов
Ключевой момент здесь, это ендпоинты, которые есть у каждого из компонентов, и с которыми легко и просто общаться. Если вам нужен пример, то есть Elasticsearch-кластер. При помощи обычных http-запросов в JSON можно легко с ним общаться. И он сразу в этом же JSON отдает всякие разные метрики и высокоуровневую информацию о кластере: зеленый, желтый, красный.



Проделав эти 12 шагов, мы увеличили количество окружений, стали больше тестировать, деплой у нас ускорился, люди начали получать быструю обратную связь.



CICD: бесшовный деплой на распределенные кластерные системы без даунтаймов
Что очень важно, мы получили простоту и скорость экспериментов. А это очень важно, ведь когда много экспериментов, мы легко можем отсеять ошибочные идеи и остановится на верных. И не на основе каких-то субъективных оценок, а на основе объективных показателей.



На самом деле я уже и не слежу, когда у нас там деплой происходит, когда релиз. Нет этого ощущения «о, релиз!», всё собрались и мурашки по коже. Сейчас это такая рутинная операция, я в чатике периодически вижу, что что-то зарелизилось, ну и ладно. Это реально круто. Ваши сисадмины будут реветь от радости, когда вы так сделаете.



Но мир не стоит на месте, он иногда подпрыгивает. Нам есть, что улучшать. Например, логи билда хотелось бы тоже засунуть в Graylog. Это потребует еще доработать логирование, чтобы была не какая-то отдельная история, а четко: вот так билд собирался, так тестировался, так деплоился и так он ведет себя на проде. И continuous monitoring — с этим история посложнее.



CICD: бесшовный деплой на распределенные кластерные системы без даунтаймов
Мы используем Zabbix, а он вообще не готов к таким подходам. Скоро выйдет 4-я версия, узнаем что там и если все плохо, то придумаем другое решение. Как это у нас получится — расскажу на следующем митапе.



Вопросы из зала



А что происходит, когда вы задеплоили какой-то мусор в продакшн? Например, вы что-то по перформансу не рассчитали и на интегрейшене все ок, а в продакшене смотрите — у вас серваки начинают падать. Как вы откатываетесь обратно? Есть какая-то кнопка «спаси меня»?



Мы пробовали сделать автоматизацию обратной откатки. Можно потом на докладах рассказывать, как она классно работает, как все это замечательно. Но во-первых, мы разрабатываем так, чтобы версии были обратносовместимы и тестируем это. И когда мы сделали эту полностью автоматическую штуку, которая что-то там проверяет и обратно откатывает, а потом начали с этим жить, то поняли, что мы сил в нее вкладываем гораздо больше, чем если просто возьмем и той же самой педалью запустим старые версии.



По поводу автоматического обновления деплоя: почему вы вносите изменения на текущий сервер, а не добавляете новый и просто добавляете его в таргетгруп или балансер?



Так быстрее.



Например, если вам нужно обновить версию Java, вы меняете стейт инстенса на Амазоне, обновляя версию Java или еще что-то, то как вы откатываетесь в таком случае? Вы делаете изменения на рабочем сервере?



Да, каждый компонент работает прекрасно с новой версией и старой. Да, может быть придется перезалить сервер.



Бывают изменения стейтов, когда возможны большие проблемы…



Тогда взорвемся.



Просто мне кажется добавить новый сервер и просто поместить его за балансер в таргетгруп — небольшая по сложности задача и довольно хорошая практика.



Мы хостимся на железе, не в облаках. Нам добавить сервер — это можно, но немного дольше, чем просто в облаке накликать. Поэтому мы берем наш текущий сервер (у нас не такая загрузка, чтобы мы не могли вывести часть машин) — выводим часть машин, их обновляем, пускаем туда продашкн-трафик, смотрим, как это работает, если все окей, то докатываем дальше на все остальные машины.



Вы говорите, если каждый коммит собирается и если все плохо — разработчик сразу все правит. Как вы понимаете, что все плохо? Какие процедуры с коммитом проделываются?



Естественно, первое время это какое-то ручное тестирование, обратная связь медленная. Потом уже какими-то автотестами на Appium все это покрывается, работает и дает какую-то обратную связь о том, упали тесты или не упали.



Т.е. сначала каждый коммит выкатывается и тестеры его смотрят?



Ну не каждый, это практика. Мы одну практику из этих 12 пунктов сделали — ускорились. На самом деле это долгая и упорная работа, может быть в течении года. Но в идеале потом приходишь к этому и все работает. Да, нужны какие-то автотесты, хотя бы минимальный набор, о том что у тебя это все работает.



И вопрос поменьше: там на картинке App-сервер и так далее, вот что там мне интересно? Вы сказали, что Докера у вас вроде бы нет, что же такое сервер? Голая Java или что?



Где-то это Photon на винде (гейм-сервер), App-сервер — это Java-приложение на Томкате.



Т.е. никаких виртуалок, никаких контейнеров, ничего?



Ну Java это, можно сказать, контейнер.



И Ансиблом все это раскатывается?



Да. Т.е. в определенный момент мы просто не стали вкладываться в оркестракцию, потому что зачем? Если в любом случае винду надо будет точно так же менеджить отдельно, а тут одним инструментом покрывается абсолютно все.



А базу данных как деплоите? Зависимость к компоненту или к сервису?



В самом сервисе есть схема, которая задеплоит, когда он появился и нужно разрабатывать так, чтобы ничего не удаляли, а просто что-то добавлялось и было это обратно совместимо.



А база у вас тоже железная или база где-то в облаке в Амазоне?



Самая большая база железная, но есть и другие. Есть маленькие, RDS — это уже не железная, виртуальная. Те маленькие сервисы, которые я показывал: чаты, лиги, общение с фейсбуками, кланы, что-то из этого — RDS.



Мастер-сервер — что он из себя представляет?



Это, по сути, такой же гейм-сервер, только с признаком мастер и он является балансировщиком. Т.е. клиент пингует все мастера, потом получает тот, до которого пинг меньше, а уже мастер-сервер при помощи матчмейкинга собирает комнаты на гейм-серверах и отправляет игрока.



Я правильно понимаю, что на каждую выкатку вы пишите (если появились какие-то фичи) миграцию на обновление данных? Вы сказали, что берете старые артефакты и заливаете — а что с данными происходит при этом? Вы пишите миграцию на откат базы?



Это очень редкая операция с откатом. Да, пишешь ручками миграцию, а что делать.



Как обновление сервера синхронизируется с обновлениями клиента? Т.е. нужно вам новую версию игры выпустить — вы сначала обновите все сервера, потом обновятся клиенты? А сервер поддерживает и старую и новую версию?



Да, мы разрабатываем c feature toggling и feature dimming. Т.е. это специальная ручка, рычаг, который позволяет какую-то фичу включить потом. Можно абсолютно спокойно обновиться, увидеть то, что у тебя все работает, но фичу эту не включать. А когда ты уже клиента разогнал, тогда можешь фичидиммингом на 10% подкрутить, посмотреть, что все окей, а потом на полную.



Вы говорите, у вас отдельно хранятся части проекта в разных репозиториях, т.е. у вас есть какой-то процесс для разработки? Если вы меняете сам проект, то у вас тесты должны упасть, потому что вы поменяли проект. Значит тесты, которые лежат отдельно нужно, как можно быстрее поправить.



Я говорил вам про кита «плотное взаимодействие с тестировщиками». Эта схема с разными репозиториями очень хорошо работает, только если есть какое-то очень плотное общение. Для нас это не проблема, все друг с другом легко общаются, есть хорошая коммуникация.



Т.е. в вашей команде репозиторий с тестами поддерживают тестировщики? А автотесты отдельно лежат?



Да. Ты сделал какую-то фичу и можешь из репозитория тестировщиков набрать именно те автотесты, которые тебе нужны, а все остальное не проверять.



Такой подход, когда все быстро накатывается — вы можете себе позволить по каждому коммиту сразу идти в прод. Вы такой тактики и придерживаетесь или вы компонуете какие-то релизы? Т.е. раз в неделю, не по пятницам, не на выходных, какие-то у вас тактики релизные есть или фича готова, можно выпускать? Потому что, если вы делаете маленький релиз из маленьких фич, то у вас меньше шансов, что все сломается, а если что-то сломается, то вы точно знаете что.



Заставлять пользователей клиента каждые пять минут или каждый день новую версию скачивать — не айс идея. В любом случае ты будешь привязан к клиенту. Классно, когда у тебя web-проект, в котором ты можешь хоть каждый день обновляться и ничего не нужно делать. С клиентом история посложнее, у нас есть какая-то релизная тактика и мы ее придерживаемся.



Ты рассказал про автоматизацию выкатки на продуктовые сервера, а (я так понимаю) есть еще автоматизация выкатки на тест — а что с dev-средами? Есть ли какая-то автоматизация, разворачиваемая разработчиками?



Почти то же самое. Единственное, это уже не железные сервера, а в виртуалке, но суть примерно такая же. При этом на том же самом Ansible мы написали (у нас Ovirt) создание этой виртуалки и накатку на нее.



У вас вся история хранится в одном проекте вместе с продовыми и тестовыми конфигами Ansible или оно отдельно живет и развивается?



Можно сказать, что это отдельные проекты. Dev (devbox мы это называем) — это история, когда все в одном паке, а на проде — это распределенная история.



CICD: бесшовный деплой на распределенные кластерные системы без даунтаймов

Источник: Хабр / Интересные публикации

Категория: Системное администрирование, Веб-разработка

Уважаемый посетитель, Вы зашли на сайт как незарегистрированный пользователь.
Мы рекомендуем Вам зарегистрироваться либо войти на сайт под своим именем.

Добавление комментария

Имя:*
E-Mail:
Комментарий:
Полужирный Наклонный текст Подчеркнутый текст Зачеркнутый текст | Выравнивание по левому краю По центру Выравнивание по правому краю | Вставка смайликов Выбор цвета | Скрытый текст Вставка цитаты Преобразовать выбранный текст из транслитерации в кириллицу Вставка спойлера
Введите два слова, показанных на изображении: *