Самодостаточная система – это система, способная восстанавливаться и адаптироваться.
Восстановление означает, что кластер почти всегда будет находиться в том состоянии, в котором он был спроектирован.
Например, в случае сбоя копии службы системе потребуется ее восстановить.
Адаптация связана с изменением желаемого состояния, чтобы система могла справиться с изменившимися условиями.
Простой пример — увеличение трафика.
В этом случае услуги необходимо будет масштабировать.
Когда восстановление и адаптация автоматизированы, мы получаем самовосстанавливающуюся и самоадаптирующуюся систему.
Такая система самодостаточна и может работать без вмешательства человека.
Как выглядит самодостаточная система? Каковы его основные части? Кто персонажи? В этой статье мы будем обсуждать только сервисы и игнорировать тот факт, что аппаратное обеспечение также очень важно.
Учитывая эти ограничения, мы строим картину высокого уровня, которая описывает (в основном) автономную систему с точки зрения сервисов.
Мы опустим детали и посмотрим на систему с высоты птичьего полета.
Если вы хорошо разбираетесь в теме и хотите сразу во всем разобраться, то система представлена на рисунке ниже.
Система с самовосстанавливающимися и самоадаптирующимся сервисами Понять такую диаграмму сразу может быть сложно.
Если бы я оставил вам такой рисунок, вы могли бы подумать, что сопереживание — не самая яркая черта моего характера.
В этом случае вы не одиноки.
Моя жена думает так же, даже без каких-либо диаграмм.
Но на этот раз я сделаю все возможное, чтобы изменить ваше мнение и начать все с нуля.
Мы можем разделить систему на две основные области — человеческую и машинную.
Рассмотрите себя в Матрица .
Если вы еще не смотрели этот фильм, немедленно отложите эту статью, возьмите немного попкорна и вперед. В «Матрице» мир был порабощен машинами.
Люди там мало что делают, за исключением тех немногих, кто осознал, что происходит. Большинство живут во сне, который отражает прошлые события в истории человечества.
То же самое происходит сейчас и с современными кластерами.
Большинство относятся к ним так, будто сейчас 1999 год. Почти все делается вручную, процессы громоздки, а система выживает только за счет грубой силы и траты энергии.
Некоторые поняли, что уже 2017 год (по крайней мере, на момент написания этой статьи) и что хорошо спроектированная система должна выполнять большую часть работы автономно.
Почти всем должны управлять машины, а не люди.
Но это не значит, что людям не осталось места.
Работа для нас есть, но она больше связана с творческими и неповторяющимися задачами.
Таким образом, если мы сосредоточимся только на кластерных операциях, ответственность человека снизится и уступит место машинам.
Задачи распределяются по ролям.
Как вы увидите ниже, специализация инструмента или человека может быть очень узкой, и в этом случае он будет выполнять только один тип задач, а может отвечать за множество аспектов операций.
Роль разработчика в системе
В обязанности человека входят процессы и инструменты, которыми необходимо управлять вручную.Из этой области мы стараемся удалить все повторяющиеся действия.
Но это не значит, что оно должно исчезнуть полностью.
Наоборот. Избавляясь от повторяющихся задач, мы освобождаем время, которое можно потратить на действительно важные задачи.
Чем меньше времени мы тратим на задачи, которые можно делегировать машине, тем больше времени мы можем потратить на задачи, требующие творчества.
Эта философия находится в одном ряду с сильными и слабыми сторонами каждого актера этой драмы.
Машина хорошо справляется с цифрами.
Они могут выполнять данные операции очень быстро.
В этом вопросе они намного лучше и надежнее нас.
Мы, в свою очередь, способны мыслить критически.
Мы можем мыслить творчески.
Мы можем программировать эти машины.
Мы можем сказать им, что и как делать.
Я назначил разработчика главным героем этой драмы.
Я сознательно отказался от слова «кодер».
Разработчик — это любой человек, работающий над проектом разработки программного обеспечения.
Он может быть программистом, тестировщиком, гуру эксплуатации или scrum-мастером — не имеет значения.
Я поместил всех этих людей в группу под названием «Разработчики».
В результате своей работы они должны разместить некоторый код в репозитории.
Пока его нет, его как будто не существует. Неважно, находится ли оно на вашем компьютере, ноутбуке, столе или на небольшом листке бумаги, прикрепленном к почтовому голубю.
С точки зрения системы этот код не существует, пока не попадет в репозиторий.
Я надеюсь, что это репозиторий Git, но теоретически это может быть любое место, где вы можете что-то хранить и отслеживать версии.
Ответственность за этот репозиторий также лежит на человеке.
Несмотря на то, что это программное обеспечение, оно принадлежит нам.
Мы работаем с ним.
Мы обновляем код, скачиваем его из репозитория, сливаем части вместе и порой ужасаемся количеству конфликтов.
Но нельзя сделать вывод, что автоматизированных операций вообще не существует или что некоторые области ответственности машин не требуют вмешательства человека.
Тем не менее, если данная область в основном выполняется вручную, мы будем считать это человеческой ответственностью.
Репозиторий кода определенно является частью системы, требующей вмешательства человека.
Разработчик отправляет код в репозиторий Давайте посмотрим, что произойдет, когда код будет отправлен в репозиторий.
Роль непрерывного развертывания в системе
Процесс непрерывного развертывания полностью автоматизирован.Без исключений.
Если ваша система не автоматизирована, у вас нет непрерывного развертывания.
Возможно, вам придется выполнить развертывание в рабочей среде вручную.
Если вы вручную нажмете одну-единственную кнопку с надписью «развернуть», выделенной жирным шрифтом, то ваш процесс будет непрерывной доставкой.
Я могу понять, что.
Такая кнопка может потребоваться с точки зрения бизнеса.
Однако уровень автоматизации в этом случае такой же, как и при непрерывном развертывании.
Здесь вы просто принимаете решения.
Если вам приходится делать что-то еще вручную, вы либо выполняете непрерывную интеграцию, либо, что более вероятно, делаете что-то, в названии которого нет слова «непрерывный».
Будь то непрерывное развертывание или доставка, этот процесс должен быть полностью автоматизирован.
Все действия, выполняемые вручную, могут быть оправданы только тем фактом, что у вас есть устаревшая система, которую ваша организация предпочитает не трогать (обычно это приложение COBOL).
Она просто стоит на сервере и что-то делает. Мне очень нравятся правила «никто не знает, что она делает, поэтому не трогай ее».
Это способ проявить максимальное уважение, сохраняя при этом безопасную дистанцию.
Все же я предполагаю, что это не ваш случай.
Ты хочешь что-то с ней сделать, желание буквально разрывает тебя на части.
Если это не так и вам не повезло работать с системой «руки прочь отсюда», то вам не стоит читать эту статью, я удивлен, что вы сами этого не поняли раньше.
Как только репозиторий получает запрос на фиксацию или извлечение, срабатывает веб-перехватчик, который, в свою очередь, отправляет запрос инструменту непрерывного развертывания для запуска процесса непрерывного развертывания.
В нашем случае этим инструментом является Jenkins. Запрос запускает поток всевозможных задач непрерывного развертывания.
Он просматривает код и запускает модульные тесты.
Он создает образ и помещает его в регистр.
Он запускает функциональные, интеграционные, нагрузочные и другие тесты — те, которые требуют работающего сервиса.
В самом конце процесса (не считая тестов) планировщику отправляется запрос на развертывание или обновление сервиса в кластере.
Среди других планировщиков мы выбираем Docker Swarm. 
Развертывание сервиса через Jenkins Параллельно с непрерывным развертыванием работает еще один набор процессов, отслеживающих обновления конфигурации системы.
Роль настройки сервиса в системе
Какой бы элемент кластера ни менялся, некоторые части системы необходимо переконфигурировать.Возможно, потребуется обновить конфигурацию прокси-сервера, сборщику метрик могут потребоваться новые цели, а анализатору журналов может потребоваться обновить свои правила.
Неважно, какие части системы необходимо изменить, главное, чтобы все эти изменения применялись автоматически.
С этим мало кто будет спорить.
Но возникает большой вопрос: где найти те фрагменты информации, которые следует внедрить в систему? Лучшее место – это сам сервис.
Т.
к.
почти все планировщики используют Docker; информацию о сервисе логичнее всего хранить в самом сервисе в виде меток.
Если мы поместим эту информацию в какое-либо другое место, то потеряем единственный источник истины, и выполнять автоматическое обнаружение станет очень сложно.
Тот факт, что информация о сервисе находится внутри него, не означает, что эту же информацию нельзя размещать где-либо еще в кластере.
Должно.
Однако именно сервис должен находиться там, где должна находиться первичная информация, и с этого момента она должна передаваться другим сервисам.
С Docker это очень просто.
У него уже есть API, к которому каждый может подключиться и получить информацию о любом сервисе.
Есть хороший инструмент, который находит информацию о сервисе и распределяет ее по системе — это Прослушиватель Docker Flow Swarm (ДФСЛ).
Вы можете использовать любое другое решение или создать свое.
Конечная цель этого и любого другого подобного инструмента — прослушивать события Docker Swarm. Если у службы есть определенный набор ярлыков, приложение получит информацию, как только вы установите или обновите службу.
После чего оно передаст эту информацию всем заинтересованным лицам.
В данном случае это Docker Flow Proxy (DFP, внутри которого есть HAProxy) и Docker Flow Monitor (DFM, внутри которого есть Prometheus).
В результате оба всегда будут иметь самую последнюю текущую конфигурацию.
У прокси есть путь ко всем публичным сервисам, а у Прометея есть информация об экспортёрах, оповещениях, адресе Alertmanager и прочем.
Реконфигурация системы через Docker Flow Swarm Listener Пока развертывание и реконфигурация продолжаются, пользователи должны иметь возможность доступа к нашим сервисам без простоев.
Роль прокси в системе
Каждый кластер должен иметь прокси-сервер, который будет принимать запросы с одного порта и пересылать их назначенным службам.Единственным исключением из правил будут государственные услуги.
Для такого сервиса под вопросом будет не только необходимость прокси, но и кластера в целом.
Когда запрос поступает на прокси, он оценивается и в зависимости от его пути, домена и некоторых заголовков перенаправляется на один из сервисов.
Благодаря Docker некоторые аспекты прокси уже устарели.
Больше никакой балансировки нагрузки.
Сеть Docker Overlay делает это за нас.
Больше нет необходимости поддерживать IP-узлы, на которых размещаются службы.
Обнаружение служб делает это за нас.
Все, что нужно сделать прокси, — это оценить заголовки и перенаправить запросы туда, куда они должны направиться.
Поскольку Docker Swarm всегда использует чередующиеся обновления при каждом изменении какого-либо аспекта службы, процесс непрерывного развертывания не должен вызывать простоев.
Чтобы это утверждение было верным, необходимо соблюдение нескольких требований.
Должно быть запущено как минимум две реплики сервиса, а лучше даже больше.
В противном случае, если реплика всего одна, простой неизбежен.
На минуту, секунду или миллисекунду — это не имеет значения.
Простой не всегда приводит к катастрофе.
Все зависит от типа услуги.
Когда Prometheus обновляется, простоя не избежать, потому что программа не умеет масштабироваться.
Но эту услугу нельзя назвать публичной, если только у вас не несколько операторов.
Несколько секунд простоя никому не повредят. Совсем другое дело — государственный сервис вроде крупного интернет-магазина с тысячами, а то и миллионами пользователей.
Если такой сервис выйдет из строя, он быстро потеряет свою репутацию.
Мы, потребители, настолько избалованы, что даже один-единственный сбой заставит нас передумать и отправиться искать замену.
Если этот сбой произойдет снова и снова, потеря бизнеса практически гарантирована.
Непрерывное развертывание имеет множество преимуществ, но поскольку оно используется так часто, потенциальных проблем становится все больше, и время простоя — одна из них.
Фактически, нельзя допускать односекундного простоя, если он повторяется несколько раз в день.
Есть и хорошие новости: если объединить чередующиеся обновления и несколько реплик, можно избежать простоев при условии, что прокси всегда будет последней версии.
Если мы объединим повторяющиеся обновления с прокси-сервером, который динамически перенастраивает себя, мы получим ситуацию, когда пользователь может отправить запрос к сервису в любое время и на него не повлияет непрерывное развертывание, сбой или любые другие изменения в состоянии кластер.
Когда пользователь отправляет запрос в домен, запрос проникает в кластер через любой работающий узел и перехватывается сетью Docker Ingress. Сеть, в свою очередь, определяет, что запрос использует порт, на котором слушает прокси, и перенаправляет его туда.
С другой стороны, прокси-сервер оценивает путь, домен и другие аспекты запроса и пересылает его назначенной службе.
Мы используем Docker Flow Proxy (DFP), который добавляет необходимый уровень динамизма поверх HAProxy. 
Запросить путь к назначенному сервису Следующая роль, которую мы обсудим, связана со сбором метрик.
Роль метрик в системе
Данные являются ключевой частью любого кластера, особенно того, который нацелен на самоадаптацию.Вряд ли кто-то будет оспаривать, что необходимы как прошлые, так и текущие метрики.
Если что, без них мы будем бегать, как тот петух по двору, которому повар отрубил голову.
Главный вопрос не в том, нужны ли они, а в том, что с ними делать.
Обычно операторы смотрят в монитор бесконечные часы.
Этот подход далеко не эффективен.
Присмотритесь лучше к Netflix. По крайней мере, они подходят к этому вопросу весело.
Система должна использовать метрики.
Система их генерирует, собирает и принимает решения о том, какие действия предпринять, когда эти метрики достигнут определенных порогов.
Только тогда систему можно назвать самоадаптирующейся.
Только когда они работают без вмешательства человека, они самодостаточны.
Самоадаптивной системе необходимо собирать данные, хранить их и применять к ним различные действия.
Мы не будем обсуждать, что лучше — отправлять данные или собирать их.
Но поскольку мы используем Прометей для хранения и оценки данных, а также для создания оповещений мы будем собирать данные.
Эти данные можно получить у экспортеров.
Они могут быть общими (например, Node Exporter, cAdvisor и т. д.) или специфичными для сервиса.
В последнем случае сервисы должны создавать метрики в простом формате, ожидаемом Prometheus. Независимо от потоков, которые мы описали выше, экспортеры производят разные типы показателей.
Prometheus периодически собирает их и сохраняет в базе данных.
Помимо сбора метрик, Prometheus также постоянно оценивает пороговые значения, установленные оповещениями, и если система достигает любого из них, данные передаются в Менеджер оповещений .
В большинстве случаев эти пределы достигаются при изменении условий (например, при увеличении нагрузки на систему).
Сбор данных и оповещений
Роль оповещений в системе
Оповещения делятся на две основные группы в зависимости от того, кто их получает — система или человек.Когда предупреждение оценивается как системное, запрос обычно отправляется в службу, которая может оценить ситуацию и выполнить задачи по подготовке системы.
В нашем случае это Jenkins, выполняющий одну из предопределённых задач.
Наиболее распространенными задачами, которые выполняет Дженкинс, обычно являются масштабирование (или демасштабирование) службы.
Однако прежде чем он попытается масштабироваться, ему необходимо узнать текущее количество реплик и сравнить их с верхним и нижним пределами, которые мы установили с помощью ярлыков.
Если в результате масштабирования количество реплик выйдет за эти пределы, он отправит уведомление в Slack, чтобы человек мог решить, какие действия необходимо предпринять для решения проблемы.
С другой стороны, когда Дженкинс поддерживает количество реплик в заданных пределах, он отправляет запрос одному из менеджеров Swarm, который, в свою очередь, увеличивает (или уменьшает) количество реплик в сервисе.
Этот процесс называется самоадаптацией, поскольку система адаптируется к изменениям без вмешательства человека.
Системное уведомление для самоадаптации Хотя наша цель — полностью автономная система, в некоторых случаях без человека нам не обойтись.
По сути, это случаи, которые невозможно предусмотреть.
Когда происходит что-то, чего мы ожидали, позвольте системе исправить ошибку.
Звонить человеку следует только тогда, когда происходят неожиданные вещи.
В таких случаях Alertmanager отправляет человеку уведомление.
В нашей версии это уведомление осуществляется через Слабый , но теоретически это может быть любой другой сервис передачи сообщений.
Когда вы начнете проектировать систему самовосстановления, большинство предупреждений попадет в категорию «неожиданных».
Вы не можете предсказать каждую ситуацию.
Единственное, что вы можете сделать в этом случае, — это сделать так, чтобы неожиданное случилось только один раз.
Когда вы получите уведомление, ваша первая задача — адаптировать систему вручную.
Второе — улучшить правила в Alertmanager и Jenkins, чтобы при повторении ситуации система могла справиться с ней автоматически.
Уведомление человека, когда происходит что-то неожиданное Создать самоадаптирующуюся систему сложно, и эта работа бесконечна.
Его постоянно необходимо совершенствовать.
А как насчет самоисцеления? Неужели этого тоже так сложно добиться?
Роль планировщика в системе
В отличие от самоадаптации, самоисцеления достичь относительно легко.Пока доступно достаточно ресурсов, планировщик всегда будет обеспечивать работу определенного количества реплик.
В нашем случае это планировщик Докер Рой .
Реплики могут выйти из строя, их можно уничтожить, и они могут находиться внутри неработоспособного узла.
Это все не так уж и важно, поскольку Swarm следит за тем, чтобы они перезапускались при необходимости и (почти) всегда работали нормально.
Если все наши сервисы масштабируемы и на каждом из них работает хотя бы несколько реплик, простоев никогда не будет. Процессы самовосстановления в Docker сделают процессы самоадаптации легко доступными.
Именно сочетание этих двух элементов делает нашу систему полностью автономной и самодостаточной.
Проблемы начинают накапливаться, когда сервис невозможно масштабировать.
Если мы не можем иметь несколько реплик сервиса, Swarm не может гарантировать отсутствие простоев.
Если реплика выйдет из строя, она будет перезапущена.
Однако если это единственная доступная реплика, период между сбоем и перезапуском превращается в простой.
Точно так же и с людьми.
Мы заболеваем, лежим в постели и через некоторое время возвращаемся на работу.
Если мы единственный сотрудник в этой компании и нас некому заменить, пока нас нет, то это проблема.
То же самое касается и услуг.
Для сервиса, который хочет избежать простоев, необходимо иметь как минимум две реплики.
Docker Swarm гарантирует отсутствие простоев К сожалению, наши услуги не всегда разрабатываются с учетом масштабируемости.
Но даже если он учтен, всегда есть вероятность, что у одного из сторонних сервисов, которыми вы пользуетесь, его нет. Масштабируемость — важное проектное решение, и нам обязательно следует учитывать это требование при выборе любого нового инструмента.
Нам необходимо четко различать сервисы, для которых простой простоя недопустим, и сервисы, которые не подвергнут систему риску, если будут недоступны в течение нескольких секунд. Как только вы научитесь различать их, вы всегда будете знать, какие сервисы масштабируемы.
Масштабируемость является требованием для услуг с нулевым временем простоя.
Роль кластера в системе
В конце концов, все, что мы делаем, содержится в одном или нескольких кластерах.Больше нет отдельных серверов.
Мы не решаем, что и куда.
Планировщики делают это.
С нашей (человеческой) точки зрения самый маленький объект — это кластер, в котором собраны такие ресурсы, как память и процессор.
Все представляет собой кластер
Теги: #Сетевые технологии #ИТ-инфраструктура #Системное администрирование #Администрирование серверов #docker #DevOps #prometheus #jenkins #haproxy #Slack #docker swarm
-
Одежда Для Снаряжения – История
19 Oct, 24 -
Как Настроить Свой Блог Wordpress
19 Oct, 24 -
Orm — Отвратительный Антипаттерн
19 Oct, 24 -
Twitter Тестирует Новые Функции Поиска
19 Oct, 24 -
Кодирование Без Кода
19 Oct, 24
