Запускайте команды для 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.