Связаться по Skype: vkarabedyants
Позвонить Написать
+7 (499) 404-28-83

Блог о системном администрировании серверов и сайтов

Установка, настройка программного обеспечения Linux, Windows операционных систем

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итог

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

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

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

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

Наша команда занимается внедрением docker и построением ит инфраструктуры любой сложности, обращайтесь [email protected]

Оставить комментарий

Лимит времени истёк. Пожалуйста, перезагрузите CAPTCHA.