Запуск нескольких приложений в одном контейнере докеров
Этот вопрос является частью моего продолжающегося исследования Docker и в некотором роде следует за одним из моих более ранних вопросов. Теперь я понял, как можно получить полный стек приложений (фактически мини-VPS), работая, связывая вместе кучу контейнеров Docker. Например, можно создать стек, который обеспечивает Apache + PHP5 с помощью связки расширений + Redis + MemCached + MySQL, все запущенные поверх Ubuntu с или без дополнительного контейнера данных, чтобы упростить сериализацию пользовательских данных.
Все очень красиво и элегантно. Однако я не могу не задуматься.... 5 контейнеров для запуска этого небольшого VPS (я считаю 5 не 6, так как Apache + PHP5 входит в один контейнер). Итак, предположим, что у меня есть 100 таких VPS? Это означает, что у меня есть 500 контейнеров! Я понимаю здесь аргументы - легко создавать новые стеки приложений, обновлять один компонент стека и т.д. Но нет ли лишних накладных расходов для работы таким образом?
Предположим, что я сделал это
В моем файле Docker у меня есть
ADD start.sh /usr/local/bin/start.sh
RUN chmod +x /usr/local/bin/start.sh
....
ENTRYPOINT ["/bin/bash"]
CMD ["/usr/local/bin/start.sh"]
Затем я запускаю этот контейнер и запускаю
docker run -d -p 8080:80 -v /var/droidos/site:/var/www/html -v /var/droidos/logs:/var/log/apache2 droidos/minivps
и я занимаюсь бизнесом. Теперь, когда я хочу программно закрыть этот контейнер, я могу сделать это, выполнив одну команду docker.
Есть много вопросов подобного характера, которые можно найти, когда один Google для них. Помимо аргументов, которые я воспроизвел выше, одна из наиболее распространенных причин, заданных для подхода "один-на-контейнер", - "это то, как Docker предназначен для работы". Что я хотел бы знать
- Каковы недостатки запуска x100 экземпляров N связанных контейнеров - компромиссы по скорости, использованию памяти и т.д. на хосте?
- Что не так с тем, что я здесь сделал?
Ответы
Ответ 1
Контейнер - это в основном процесс. Нет технической проблемы с запуском 500 процессов на Linux-системе с приличным размером, хотя им придется совместно использовать CPU и память.
Стоимость контейнера над процессом - это дополнительные ресурсы ядра для управления пространствами имен, файловыми системами и группами управления и некоторыми структурами управления внутри демона Docker, особенно для обработки stdout
и stderr
.
Пространства имен вводятся для обеспечения изоляции, так что один контейнер не мешает другим. Если ваши группы из 5 контейнеров образуют единицу, которая не нуждается в этой изоляции, вы можете использовать сетевое пространство имен, используя --net=container
. В настоящее время нет возможности делиться группами, AFAIK.
Что не так с тем, что вы предлагаете:
- это не "путь докеров". Это может быть не важно для вас.
- вам нужно поддерживать сценарии, чтобы заставить его работать, беспокоиться о перезапуске процесса и т.д., в отличие от использования оркестра, предназначенного для этой задачи.
- вам придется управлять конфликтами в файловой системе, например. двум процессам нужны разные версии библиотеки, либо они оба записывают в один и тот же выходной файл
-
stdout
и stderr
будут перемешаны для пяти процессов
Ответ 2
@Ответ Bryan является твердым, особенно в отношении накладных расходов контейнера, который просто запускает один процесс, низкий.
Тем не менее, вы должны, по крайней мере, прочитать аргументы в https://phusion.github.io/baseimage-docker/, что делает случай наличия контейнеров с несколькими процессами. Без них докер легко освещает:
- контроль процесса
- задания cron
- Syslog
baseimage-docker запускает процесс init, который запускает несколько процессов, кроме основного в контейнере.
Для некоторых целей это хорошая идея, но также помните, что, например, наличие демона cron и демона syslog на контейнер добавляет немного больше служебных данных. Я ожидаю, что по мере созревания экосистемы докеров мы увидим лучшие решения, которые этого не потребуют.