LINUX.ORG.RU

Насущие вопросы по инфраструктуре на базе docker

 


0

2

Всем привет! Пытаюсь расставить в голове все точки над i, помогите пожалуйста.

1. Есть кучка серверов под web с различными мощностями с чисто установленным софтом nginx, php-fpm, PostgreSQL. Сейчас внедряем 3 новых сервера с docker swarm, где будут контейнеры с микросервисами. Вопрос: На сколько адекватно переинсталлить уже имеющиеся разношерстные сервера под web, натянуть на них docker-engine, запустить текущие сервисы nginx/php-fpm/PostgreSQL в контейнерах и пристегнуть их worker'ами к manager'ам для микросервисов на новой инфраструктуре? Или как тогда всё превратить в docker swarm инфраструктуру?

2. Как лучше обеспечить управление конфигурацией nginx/java........ и т.д. в контейнерах? Собирать каждый раз образ с новым nginx.conf из которого будем запускать контейнер или распространять nginx.conf на хост-машины и подключать volume к контейнеру?

3. Такой же вопрос и в части деплоя приложений. Каких-нибудь php/python-скриптов. Сейчас код хранится в GIT'е и деплой релиза, это просто git checkout на нужную ветку в локальном репозе на web-сервере. Может быть вывести volume на хост-машине для контейнера с web-сервером, где будет локальный репозиторий GIT? Или как-то автоматизировать сборку контейнера внутри которого локальный репозиторий GIT с нужной веткой, мне кажется это очень неудобным.

4. У меня есть несколько условно разделяемых подсистем в рамках моего проекта напр. 3, они раскиданы по 2м ЦОДам, из серии web-сайт, Микросервисы, событийно-ориентированные приложения на Java для внутренних задач. Как лучше сделать, 3 docker swarm инфраструктуры или всё завести в одну инфраструктуру. Мне кажется лучше 3и фермы, т.к. нечётное число ЦОДов и протокол RAFT несовместимы. Тогда встаёт вопрос на сколько адекватно управлять Ansible разными swarm-инфраструктурами? И чем лучше управлять, когда у тебя несколько независимых swarm-инфраструктур?


1.

Вопрос: На сколько адекватно переинсталлить уже имеющиеся разношерстные сервера под web, натянуть на них docker-engine, запустить текущие сервисы nginx/php-fpm/PostgreSQL в контейнерах

Адекватно.

2.

Собирать каждый раз образ с новым nginx.conf из которого будем запускать контейнер или распространять nginx.conf на хост-машины и подключать volume к контейнеру?

Скорее всего первый вариант. Ну разве что если конфиг nginx меняется часто.. Но это маловероятно.

3.

Или как-то автоматизировать сборку контейнера внутри которого локальный репозиторий GIT с нужной веткой, мне кажется это очень неудобным.

Автоматизировать. Настрой какой-нибудь Jenkins. В чём неудобство?

4.

нечётное число ЦОДов и протокол RAFT несовместимы

Несовместимы. В каждом ЦОДе подними отдельный кластер.

P.S. Не надо swarm брать, потрать пару дней на изучение kubernetes.

generator ★★★ ()
Ответ на: комментарий от generator

P.S. Не надо swarm брать, потрать пару дней на изучение kubernetes.

Эххх там ни пару дней, уж с *nix'ом я на ТЫ, но кубернетис боюсь я очень. Тем более признаться честно, есть кучу консалтинговых компаний, банков, правительственных контор, которым выкатывают сервер в виде VMware ESXi тачки и всё что ниже уровня OS никогда не будет в твоём ведении. Философия конечно долгая, но Кубер всё-таки рассчитан на более масштабные задачи и мне кажется такие решения имеет смысл внедрять на уровне, то что называют гипервизором, т.е. вместо VMware ESXi. Берём железо с Linux, которое ещё рассчитано с учётом оркестрации под Кубер и раскатываем инфраструктуру docker. А вот в реальностях с физическими виртуалками на мой взгляд есть смысл строить оркестрацию docker-инфраструктурой менее масштабными инструментами.

Т.е. в целом к docker'у надо ещё относиться как к инструменту реализации CI/CD? Приложение и СУБД в контейнерах должны быть размещены на разных хост-машинах, т.к. база всё так же генерит нагрузку на I/O?

trider ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.