Как исправить вашу инфраструктуру микросервисов на основе Docker

Запускайте команды для Docker API, чтобы исправить вашу инфраструктуру всякий раз, когда происходит сбой.

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

Затем появились такие инструменты оркестровки, как Docker Swarm, Kubernetes и Nomad. Эти инструменты помогают автоматизировать масштабирование, развертывание и управление контейнерами.

Несмотря на то, что сложность управления микросервисами уменьшается из-за этих достижений, некоторые проблемы остаются, например, плавный и простой мониторинг таких инфраструктур. В предыдущей статье мы представили Logspout и новый адаптер Slack в качестве облегченной альтернативы мониторинга журналов для ваших контейнеров Docker. В этой статье мы представим kontrol, легкую альтернативу встроенной проверке работоспособности контейнеров Docker, которую вы можете настроить и развернуть в мгновение ока.

в двух словах о контроле

kontrol - очень легкое приложение, которое можно запускать как контейнер Docker или как службу Docker Swarm. Он запускает запросы к набору ресурсов (контейнеров или служб), чтобы определить, нормально ли работают эти ресурсы (также как и проверка работоспособности). Каждый раз, когда проверка работоспособности терпит неудачу, она запускает команды для Docker API, чтобы исцелить инфраструктуру. kontrol может как отслеживать, так и исправлять вашу инфраструктуру микросервисов на основе Docker.

kontrol включает уведомления Slack с помощью Incoming Webhook. Просто вставьте URL-адрес веб-перехватчика в свою среду и включите интеграцию со Slack. Каждый раз, когда проверка работоспособности завершается неудачно, канал, который вы указали в Slack, получит сообщение.

Почему контрол?

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

Например, представим, что у вас есть служба A, использующая службу B. Службы A и B можно рассматривать как работоспособные с точки зрения Docker, в то время как служба B по какой-то причине недоступна из службы A (например, сбой сети, тайм-аут и т. Д.) ). В этом случае может быть интересно продемонстрировать конечную точку проверки работоспособности в службе A, предоставляющую статус службы B с точки зрения A. Когда эта проверка работоспособности в службе A дает сбой, вы должны быть уведомлены, и служба B, возможно, должна быть автоматически перезапущена в дополнение к службе A.

Настройка контроля

Большинство вариантов конфигурации происходят от got и dockerode управления питанием. Экспортированный объект в config.js должен иметь такую ​​структуру:

• docker: параметры, используемые для инициализации dockerode.
• jobs: Карта проверок работоспособности и задач по уведомлению / лечению, которые должны выполняться для каждой задачи, определенной ее ключом.
• cron: Шаблон CRON для его планирования.
• delay: Задержка в секундах перед планированием задачи.
• notify: Необязательная функция с объектом error в качестве входных данных, когда проверка работоспособности завершилась неудачно, или отсутствует, когда она возвращается к работоспособности после сбоя (возвращает полезные данные сообщения Slack для отправки для уведомления).
• heal: Необязательная функция с объектом docker (т.е. экземпляром dockerode) и _ (экземпляром lodash) в качестве входных данных. Выполняет команды Docker для восстановления инфраструктуры.
• Все остальные параметры отправляются полученному экземпляру для запроса проверки работоспособности.

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

• CONFIG_FILEPATH: путь к вашему файлу конфигурации config.js
• PORT: порт сервера (по умолчанию 8080)
• SLACK_WEBHOOK_URL: URL-адрес вашего веб-перехватчика Slack

Значение по умолчанию config.js - отличный пример для начала. Он в основном проверяет сам контейнер kontrol и перезапускает его в случае сбоя, как это сделал бы Docker. В тестовом режиме контейнер kontrol случайно выйдет из строя с кодом состояния 500, так что контейнер будет перезапущен, пока вы не убьете его вручную. Чтобы собрать и запустить пример, выполните следующие команды:

git clone https://github.com/kalisio/kontrol.git
SLACK_WEBHOOK_URL=https://hooks.slack.com/services/xxx
docker-compose build
docker-compose up

Контроль микросервисов

Если вы используете Docker Swarm, вот более полный пример файла Docker Compose, чтобы развернуть его в диспетчере для мониторинга и лечения ваших сервисов:

В следующем примере конфигурации мы предполагаем, что приложение использует распределенные сервисы A и B. Даже если сервисы A и B исправны с точки зрения Docker, мы проверяем, доступны ли они с точки зрения приложения, используя выделенную работоспособность. проверьте конечные точки. В случае сбоя произойдет уведомление и целевая служба будет автоматически перезапущена:

Заключение

Я надеюсь, что вы найдете это решение довольно простым и полезным. Если так, не стесняйтесь открывать вопросы или пиары по новому репозиторию контролей.

Если вы заинтересованы в создании платформы на основе микросервисов, вы можете взглянуть на некоторые проекты с открытым исходным кодом, например:

• Kaabah, решение для построения и эксплуатации инфраструктур Docker Swarm.
• Kargo, решение на основе Docker для развертывания сервисов в инфраструктурах Docker Swarm.

То, что я представил в этой статье, теперь является частью встроенного стека мониторинга Kargo.