Сколько контейнеров должно существовать на каждом хосте в производстве? Как следует разделять службы?

Я пытаюсь лучше понять преимущества Docker, и я не понимаю, как это будет работать в производстве.

Скажем, у меня есть веб-интерфейс, резервная копия api и db. Это делает 3 контейнера.

Скажем, что я хочу 3 переднего конца, 5 из бэкэнд и 7 из db. (Незначительный вопрос: имеет ли смысл иметь меньше dbs, чем серверные серверы?)

Теперь, учитывая описанный выше сценарий, если я упакую их все на один и тот же хост, я получаю выгоду от эффективного использования ресурсов хоста, но тогда я DOA, когда эта машина терпит неудачу или имеет сетевой раздел.

Если я разделяю их на 1 полное приложение (то есть 1 FE, 1 BE и 1 DB) на хост и кладу дополнительные контейнеры на свой собственный хост, я получаю некоторые преимущества эффективного использования ресурсов, но мне кажется, что я по-прежнему теряют значимость, когда у меня есть сетевой раздел, так как он будет использовать несколько сервисов.

Следовательно, я почти склоняюсь к выводу, что я должен помещать 1 контейнер на хост, но тогда это означает, что я использую свои ресурсы довольно неэффективно, а затем каковы преимущества контейнеров в производстве? Я имею в виду, что ОС может быть дополнительным количеством парных гигабайтов на одну машину в размере памяти, но большинство поставщиков облачных вычислений дают вам минимум 10 гигабайт. И позвольте ему взглянуть на это, остальная часть api backend или веб-интерфейс не собираются даже приблизиться к 10 концертам... даже включая ОС.

Итак, после всего этого, я пытаюсь выяснить, не хватает ли я точки контейнеров? Являются ли преимущества сохранения всех контейнеров приложения на 1 хосте, в основном связанных с преимуществами тестирования и разработки?

Я знаю, что есть преимущества в перемещении контейнеров между разными поставщиками/машинами, но по большей части я не вижу в этом огромного выигрыша, поскольку это можно было сделать с изображениями...

Есть ли другие преимущества для контейнеров в производстве, которые мне не хватает? Или основные преимущества тестирования и разработки? (Я думаю о том, что контейнеры в производстве ошибочны)?

Ответ 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.

Как правило: используйте один сервис для типа контейнера. Что касается групп контейнеров, оцените, удобнее ли масштабировать всю группу контейнера (как атомную единицу, т.е. Блок), чем управлять ими отдельно.

Сумма

Контейнеры лучше использовать с каркасом/платформой оркестровки. Существует множество доступных решений для планирования контейнеров и управления ресурсами. Выберите тот, который может соответствовать вашему варианту использования, и узнайте, как его использовать. Всегда выбирайте подходящую стратегию репликации, имея в виду возможные режимы отказа. Укажите ограничения ресурсов для ваших контейнеров/служб, когда это возможно, чтобы избежать исчерпания ресурсов, которые потенциально могут привести к тому, что узел будет удален.

Ответ 2

Это зависит от типа приложения, которое вы запускаете в своих контейнерах. С головы до ног я могу представить пару различных способов взглянуть на это:

Ваше дисковое пространство приложения тяжелое?
Вам нужно, чтобы сбой приложения не выполнялся на нескольких машинах?
Можно ли запускать несколько разных экземпляров разных приложений на одном и том же хосте без снижения их производительности?
Вы используете программное обеспечение, например kubernetes или swarm для обработки ваших машин?

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

Ответ 3

Незначительный вопрос: имеет ли смысл когда-нибудь иметь меньше баз данных, чем серверы бэкэнда?

Да.

Рассмотрим случаи, когда вы нажимаете обычные (без большого количества объединений) операторы SQL select для получения данных из базы данных, но ваша бизнес-логика требует слишком больших вычислений. В этих случаях вы можете подумать о том, чтобы поддерживать высокий уровень вашего Back-End Service и низкий уровень Service Database.

Все зависит от варианта использования, который решается.