Задать вопрос
@vitalysokolov

Как грамотно изолировать сервисы на linux-сервере?

Переехал на новый сервер и хочу добиться большей отказоустойчивости и изолированности сервисов друг от друга.
На сервере будет использоваться:
1. Postfix + PostgreSQL
2. Несколько (3-5) проектов с примерно одинаковым стеком технологий (python, NodeJS, PostgreSQL, MongoDB, RabbitMQ)
3. Несколько (3-5) проектов, требующих apache, php, MySQL.
4. Bind
5. ownCloud

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

Отсюда вытекают вопросы:
1. Какую (бесплатную) технологию лучше выбрать для изоляции? Я рассматривал KVM + Qemu, LXC и Docker.

2. Как грамотней распределить мои сервисы по контейнерам?

Думаю над таким распределением:
bind остаётся работать на корневой ОС.
Postfix с PostgreSQL (где хранятся почтовые аккаунты), в отдельном контейнере.
Каждый проект (python, NodeJS, PostgreSQL, MongoDB, RabbitMQ) — в отдельный контейнер
Простые сайты на php + MySQL поместить в один отдельный контейнер
ownCloud тоже изолировать отдельно.

Буду признателен вашим советам.
  • Вопрос задан
  • 659 просмотров
Подписаться 5 Средний Комментировать
Решения вопроса 1
leahch
@leahch Куратор тега Linux
3D специалист. Dолго, Dорого, Dерьмово.
Технологий конечно же есть.
1) Это виртуализация - KVM/Xen
На мой взгляд предпочтительнее KVM, лучше поддержка, не нужно специальное хост-ядро.
Немного, процента на 2-3 проигрывает перед XEN, но в удобстве выигрывает однозначно. XEN - только линукс, и только со специальными патчами в ядре на хосте и клиенте.
Фактически получаете полноценную виртуальную машину, ставите туже все, что душе угодно, хоть линукс, хоть BSD, хоть винду.
Проблема одна - требует жесткого выделения ресурсов. Поэтому только десяток-другой виртуалок (да и то заивисит от нагрузок).
По сравнению с железом, сожрет от 3 до 7-10 процентов производительности.
Тем не менее: мой выбор KVM.
2) Контейнеризация - Docker/LCX/Virtuozzo.
Сразу скажу за virtuozzo - ничего про нее говорить не буду. В принципе - очень похожа на XEN.
Остальные две основаны на CGroups, более того, docker внутри использует LXC.
Docker - очень распространен и популярен, фактически лидер рынка. Заточен на запуск одной задачи в одном контейнере. Контейнеры можно объединять в группы.
LXC/LXD - менее распростанен, но очень удобная технология, если нужно контейнеризировать окружение операционки с кучей процессов.

Мы пользуем и Docker и LXC/LCD. И даже в LXC пускаем Docker.
Все зависит от задачи.
Нужен сервис с кучей процессов и окружением - LXC
Нужен один процесс - docker.
Нужно полноценное окружение с ядром, куртизанками и гусарами - KVM.

По факту - около 10 виртуалок KVM, порядка 10 контейнеров LXC, и порядка 20 контейнеров Docker.
Ответ написан
Пригласить эксперта
Ответы на вопрос 4
Sanes
@Sanes
Лучше разделить по стекам через KVM или другую нормальную виртуализацию.
Например LAMP в одну VM, почту в другую и т.д.
  1. LXC/LXD возможны проблемы из-за кастрированности технологии
  2. Docker вообще не про это

Virtuozzo Containers пока единственная более или менее полноценная среди контейнеров. Если делить на виртуальные машины.
Ответ написан
mayton2019
@mayton2019
Bigdata Engineer
Топик совершенно не так должен звучать. Автор видел уязвимость. Что это было? Почему оно имело эффект в exim (? что такое exim?) и вдруг не будет имет эффекта в виртуальной среде.

Атака может проходить через сетевой порт и нет гарантии что если ты вынес все в докеры то ты "спрятался в домике". Возможно ты виртуализацией решаешь человеческую ошибку? Так это - другое. И может быть не надо виртуализировать. А просто позаводить несколько учетных записей.

Да кто вообще докер сертифицировал на безопасность? Тоже мне крепость.
Ответ написан
@0x131315
ИМХО наиболее актуально - докер.
Банально - прост в настройке, есть уже собранные образы на любой вкус, минимальные накладные расходы (можно позволить себе меньше памяти и дешевле железо), лёгкий мониторинг и управление сервисами. Умеет изолировать сервисы, сети и ресурсы. Умеет поднимать упавшие сервисы. Умеет управлять кластерами. Есть множество удобных веб-морд для управления/мониторинга из любого места, где есть браузер.

По разбиению - рекомендую БД вынести в отдельный общий (глобальный) контейнер, т.к. это будет одна из самых тяжёлых по памяти частей. Несколько БД держать дорого, и имеет смысл, только если проекты несовместимы с общей БД, но такое редкость.
Часть проектов может работать только с mysql - тогда нужно держать два контейнера с БД: mysql и postgres
Понятно, что для каждого проекта нужен отдельный ограниченный пользователь в БД.
Такая организация не только экономит ресурсы, но и позволяет управлять всеми БД через одну веб-морду, а также позволит легко прикрутить бекапы сразу для всех проектов.

Также отдельно стоит вынести nginx, который будет принимать подключения, обеспечивать безопасность и маршрутизацию по контейнерам. Как минимум это нужно, чтобы собрать все общие настройки в одном месте, и для возможности разделять один внешний порт на множество проектов.
nginx из проектов можно заменить глобальным (nginx довольно гибкий, достаточно перенести настройки), а можно и не трогать - nginx довольно дешёвый по памяти.

Также и с FPM, можно держать несколько общих контейнеров с разными версиями - глобальный nginx легко заставить маршрутизировать каждый проект в нужную версию FPM. Но это тоже не особо критично, т.к. FPM тоже дешёвые.
Специфичные настройки FPM под каждый проект нередко можно компенсировать подключением полифилов внутри проекта, чтобы сэкономить память.

Естественно все это нужно собирать под docker compose
И придерживаться правила: всё, что нужно проекту для работы, должно быть в одном docker compose файле (читай - каждый проект в своей папке)

Ну и в хост-системе, понятно, не должно быть нативно того софта, что работает в контейнерах - будут проблемы с настройками, портами, и вообще, софт в хост-системе по факту не нужен, докером намного удобнее управлять, особенно когда есть несколько несовместимых проектов, и нужны две-три версии одного и того же софта. Без докера такое настраивать - ад.
Ответ написан
Комментировать
gohdan
@gohdan
Системный администратор
"Каждый проект / сайт в отдельный контейнер" - в корне неверный подход. Контейнеризация - способ изоляции процессов, а не проектов. Т. е. на проекте у вас будет несколько контейнеров (один для ноды, один для реббита, один для постгреса и т. д.), и в основной системе вы будете видеть сразу всю эту кучу контейнеров со всех проектов. Поэтому, если Вы хотите изолировать друг от друга проекты, Ваш выбор - не контейнеры, а виртуалки на KVM (и вот там уже внутри виртуалок можно будет проект разбивать на контейнеры попроцессно). Так у вас будет нормальная изоляция проектов друг от друга, и проблемы в одном проекте будут по минимуму затрагивать другие.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы