Ответ 1
Примечание. Вопрос очень широк и может заполнить целую книгу, но я пролью некоторый свет.
Преимущества контейнеров
Интересная часть о контейнерах - это не их использование на одном хосте, а их использование на узлах, подключенных к большому кластеру. Не смотрите на свои компьютеры как на независимые хосты докеров, а на пул ресурсов для размещения ваших контейнеров.
Контейнеры сами по себе не являются новаторскими (т.е. Docker CTO, заявляя на последнем DockerCon, что "никто не заботится о контейнерах" ), но в сочетании с современными планировщиками и структурами оркестровки контейнеров они становятся очень мощной абстракцией для обработки производственное программное обеспечение.
Что касается аргумента, что он также применим к виртуальным машинам, да, но это делает, но контейнеры имеют некоторые технические преимущества (см. Как Docker отличается от обычной виртуальной машины) над виртуальными машинами, что делает их удобными для использования.
На одном хосте
На одном хосте преимущества, которые вы можете получить из контейнеров, (среди многих других):
- Использовать в качестве среды разработки, имитирующей поведение на реальном кластере производства.
- Воспроизводимые сборки независимо от хоста (удобно для совместного использования)
- Тестирование нового программного обеспечения без раздувания вашей машины с помощью пакетов, которые вы не будете использовать ежедневно.
Расширение от одного узла до пула машин (кластера)
Когда приходит время управлять производственным кластером, существуют два подхода:
- Создайте пару хостов докеров и запустите/соедините контейнеры вместе "вручную" с помощью скриптов или используя такие решения, как docker-compose. Мониторинг срока службы ваших услуг/контейнеров - это ваша ответственность, и вы должны быть готовы к простою обслуживания.
- Позвольте контейнерному оркестру разбираться со всем и контролировать срок службы ваших услуг, чтобы лучше справляться с ошибками.
Есть много контейнеров-оркестров: Кубернетес, Рой, Мезос, Номад, Облачный литейный завод и, возможно, многие другие. Они управляют многими крупными компаниями и инфраструктурами, такими как Ebay, поэтому они, несомненно, нашли преимущество в их использовании.
Выберите правильную стратегию репликации
Контейнер лучше использовать как ресурс, который означает, что вы можете остановить и перезапустить БД самостоятельно, и он не должен влиять на бэкэнд (кроме того, что он выдает ошибку, поскольку БД не работает). Таким образом, вы должны иметь возможность обрабатывать любой сетевой раздел, если ваши службы правильно реплицируются на нескольких хостах.
Вам нужно выбрать правильную стратегию репликации, чтобы убедиться, что ваш сервис работает и работает. Вы можете, например, реплицировать свою БД через облачные зоны доступности облачного провайдера, чтобы, когда вся зона опускается, ваши данные остаются доступными.
Используя Kubernetes, например, вы можете поместить каждый из ваших контейнеров (1 FE, 1 BE и 1 DB) в контейнер. Kubernetes будет заниматься тиражированием этого модуля на многих хостах и следить за тем, что эти контейнеры всегда работают и работают, если не будет создан новый модуль для устранения сбоя.
Если вы хотите смягчить влияние сетевых разделов, укажите node аффинности, указав планировщику на размещение контейнеров на одном и том же подмножестве машин и реплицируя соответствующее количество хостов. p >
Сколько контейнеров на хост?
Это действительно зависит от количества используемых вами машин и ресурсов, которые у них есть.
Правило заключается в том, что вы не должны налетать на хост с слишком большим количеством контейнеров, если вы не укажете ограничения ресурсов (с точки зрения процессора или памяти). В противном случае вы рискуете подвергнуть риску хозяина и исчерпать его ресурсы, что, в свою очередь, повлияет на все другие услуги на машине. Хорошая стратегия репликации важна не только на одном уровне обслуживания, но и для обеспечения хорошего здоровья для пула служб, которые совместно используют хост.
Ограничение ресурсов должно решаться в зависимости от типа вашей рабочей нагрузки: БД, вероятно, будет использовать больше ресурсов, чем ваш контейнер Front-end, поэтому вы должны соответствующим образом изменить размер.
В качестве примера, используя Swarm, вы можете явно указать количество процессоров или памяти, которые вам нужны для данной услуги (см. документация по обслуживанию докеров). Хотя есть много возможностей, и вы также можете дать верхнюю границу/нижнюю границу с точки зрения использования процессора или памяти. В зависимости от выбранных значений планировщик привяжет службу к правильной машине с доступными ресурсами.
Kubernetes работает практически так же, и вы можете указать лимиты для своих модулей (см. документация).
Mesos имеет более мелкозернистые политики управления ресурсами с помощью фреймворков (для конкретных рабочих нагрузок, таких как Hadoop, Spark и многие другие) и с возможностями over-commiting. Mesos особенно удобен для рабочих нагрузок Big Data.
Как разделять службы?
Это действительно зависит от решения оркестровки:
- В Docker Swarm вы должны создать сервис для каждого компонента (FE, BE, DB) и установить желаемый номер репликации для каждой службы.
- В Kubernetes вы можете создать модуль, охватывающий все приложение (FE, BE, DB и том, подключенный к БД) или создать отдельные модули для FE, BE, DB + volume.
Как правило: используйте один сервис для типа контейнера. Что касается групп контейнеров, оцените, удобнее ли масштабировать всю группу контейнера (как атомную единицу, т.е. Блок), чем управлять ими отдельно.
Сумма
Контейнеры лучше использовать с каркасом/платформой оркестровки. Существует множество доступных решений для планирования контейнеров и управления ресурсами. Выберите тот, который может соответствовать вашему варианту использования, и узнайте, как его использовать. Всегда выбирайте подходящую стратегию репликации, имея в виду возможные режимы отказа. Укажите ограничения ресурсов для ваших контейнеров/служб, когда это возможно, чтобы избежать исчерпания ресурсов, которые потенциально могут привести к тому, что узел будет удален.