Перейти к содержанию

Infra

Набор сервисов, создающих инфраструктурный слой для запуска контейнеров приложений.

Представляет собой кластер Docker Swarm с сервисами и утилитами для упрощения разработки и развёртывания.

Функции

  • Создаёт Docker Swarm кластер
  • Предоставляет Docker Registry
  • Управляет кластером с помощью Portainer
  • Выводит сервисы на поддомены вида service.subdomain.domain.com с помощью Traefik
  • Собирает логи с помощью loki + promtail
  • Собирает метрики с помощью graphite
  • Выводит метрики и позволяет искать по логам с помощью Grafana

Начало работы

Для локальной разработки и отладки необходимы:

  • Окружение с поддержкой Unix-команд (Unix shell, для Windows возможно через WSL)
  • GNU Make
  • Docker
  • Golang 1.18 или выше

Проект настраивается с помощью переменных окружения.

Перед началом нужно скопировать файл .env:

cp .env.example .env
И заменить значения переменных на нужные.

Для начала работы с сервисом можно выполнить команду в терминале:

make init

Список доступных команд:

make help

Запускаются основные внутренние сервисы с помощью команды:

make up

К основным внутренним сервисам не относится postgres, поэтому, если он нужен, то его запустит команда:

./deploy postgres

Отключается postgres через:

./undeploy postgres

Аналогичным образом с помощью ./deploy и ./undeploy можно запустить или выключить другие сервисы, представленные каталогами относительного текущего.

Соответственно, с автодополнением команды может помочь TAB:

./deploy pos[+ TAB]
->
./deploy postgres

Использование

Проект infra подойдёт, если:

  • Нужно быстро запустить несколько сервисов;
  • Нужно использовать как можно меньше ресурсов;
  • Нужно автоматически перезапускать упавшие сервисы;
  • Нужно бесшовно развёртывать новые версии сервисов;
  • Вертикальное масштабирование предпочтительнее горизонтального (проще докинуть ресурсов на текущий сервер, чем подключить новый сервер к кластеру);

Проект infra не подойдёт, если:

  • Есть серьёзные требования к отказоустойчивости;
  • На сервисы ожидается высокая нагрузка;
  • Нет необходимости экономить на ресурсах;
  • Нужно распределять трафик, привязывая пользователя к конкретной реплике (sticky session);
  • Нужно канареечное развёртывание сервиса (canary deploy, изменения процента трафика на новый сервис);
  • Нужны иные возможности Kubernetes или аналогичных оркестраторов.

Источники