Реальная самоорганизующаяся сервисная инфраструктура, или как использовать на практике Docker

Rate this post

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

Этап №1 – анализ сложившейся ситуации

Перед построением самоорганизующейся инфраструктуры следует реально оценить ситуацию, в которой оказалась компания. Например:

наша компания входит в двадцатку топ интернет-магазинов страны;
группа разработчиков, в которой насчитывается 25 сотрудников, занимается in-house внутри;
единственный админ занимается организацией продакшна (сюда относится и Ansible);
используется Amazon, на AWS, на EC

В финале – кризис, Amazon дорожает (поэтому с него приходиться съехать), безответственный админ увольняется, а интернет-магазин продолжает функционировать.

Этап №2 – постановка целей и определение путей их достижения

Чтобы выйти из создавшейся кризисной ситуации, нашей компании понадобиться определиться с задачами, ведущими к построению самоорганизующейся сервисной инфраструктуры. Хочется получить:

SOA архитектуру;
организованные небольшие отдельные продуктовые команды (сервисы) в одной большой команде;
DevOps (без админа);
автоматизацию.

К тому же не помешает уменьшить накладные расходы на эксплуатацию.

Этап №3 – решение

Остается сделать несколько шагов, и поставленные цели будут достигнуты! Первый шаг — Docker. С его помощью можно для имеющихся контейнеров обустроить внутреннюю сеть относительно дешево. Разъясняем: делая сеть внутри с помощью Docker, поднимая все контейнеры с сетевыми интерфейсами локалки, собираем их в один сетевой мост. При этом появляется возможность самостоятельно указывать:

необходимый мост (на ваш выбор);
подсеть для выдачи контейнерам IP-адреса.

Второй шаг – арендовать железо (например, 10 серверов) и свести в локалку – единую сеть. При этом IP разлаживается вручную на действующих машинах с выделенной подсетью.

Третий шаг – выбрать оптимальный вариант софта в качестве хранилища данных. Можно остановиться на Consul, так как мы самостоятельно занимаемся подъемом контейнеров, также опускаем их, при чем с разными IP. «Плюсы»: выбранный софт отвечает по DNS — Service Discovery, и имеет инструмент Health Checks.

Четвертый шаг – выполнить запуск не на одной машине, а сразу на всех. Можно воспользоваться Swarm, чтобы отследить в кластере необходимое число контейнеров.

Итог

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

хост,
Docker с контейнерами, видящими друг друга;
отдельный Consul с режимом сервера, который функционирует на машинах нашего хоста;
запущен агент для регистрации сервиса (Service Discovery+Health Checks).

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

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