(Я не могу найти аналогичный вопрос, на который уже был дан ответ, но, возможно, я не использую хорошие слова, так как я французский студент;))
Ближайший ответ на то, что я ищу: Передовой опыт топологии оборудования масштабируемых веб-приложений но он не отвечает на все
Я создал небольшое частное облако (Openstack), на котором я запускаю виртуальные машины KVM, большую часть времени по одной виртуальной машине на домен / веб-сайт, для десятков моих веб-сайтов и некоторых клиентов.
Я планирую проверить, смогу ли я развиться до «гибридного облака», имея некоторые вещи, работающие внутри моего облака, а некоторые другие на EC2, поэтому я хочу выяснить, подходит ли мой «способ работы» для меня лучше всего.
На этих виртуальных машинах работает CoreOS, а затем запускаются разные службы Docker (один контейнер для Nginx, один контейнер для pgsql и т. Д.). Если одна служба становится слишком "короткой" для чего-то, я либо создаю более крупную виртуальную машину, копирую старую виртуальную машину на большую виртуальную машину и удаляю старую, либо создаю выделенную виртуальную машину для нужной службы (например, вторая виртуальная машина, выделенная для Nginx, чтобы обрабатывать больше соединений).
Однако мне интересно, не делаю ли я что-то неправильно.
Я выбрал эту «модель», потому что хочу сильный изоляция между различными доменами / клиентами, потому что я хотел вернуться в те дни, чтобы поиграть и больше привыкнуть к Docker, и потому что я считаю Docker одним из наиболее эффективных способов быстрого развертывания сервисов.
Я должен скорее использовать только виртуальные машины (так что без контейнеров) с одной виртуальной машиной на службу (а не одной виртуальной машиной на домен)?
Или следует ли использовать вместо них только контейнеры разделить разные службы и запустить их все вместе на моих узлах? Мол, десятки и десятки контейнеров разных сервисов и разных клиентов? Тогда как я могу эффективно изолировать разные домены / клиентов? И как тогда масштабировать эти услуги? Просто добавляете больше узлов?
Или мне следует создать кластер из больших виртуальных машин или машин без операционной системы, а затем использовать их для создать большой кластер CoreOS который должен иметь возможность расти с добавлением к нему большего количества голых металлических узлов? Тогда тот же вопрос, что и для контейнеров.
Извините, если мой вопрос кажется слишком глупым, новичком или неподходящим, но я предпочитаю задавать его сейчас, а не тогда, когда будет слишком поздно делать шаг назад;)
Любые предложения приветствуются :)
Y
Совершенно нормально использовать обе виртуальные машины и контейнеры, особенно в таком сценарии.
Виртуальные машины обеспечивают безопасный уровень изоляции, который является одновременно дешевым и дорогим: - он дешев в труде, потому что вам не нужно очень много работать, чтобы добиться хорошей безопасности с виртуальными машинами; - это дорого в ресурсах, потому что накладные расходы виртуальных машин могут быть значительными, особенно для небольших сервисов, требующих скромных объемов оперативной памяти.
(«Налог на виртуализацию» можно рассматривать как небольшую константу; для больших сервисов эта константа незначительна, но для небольших сервисов она становится значительной частью общей площади.)
С другой стороны, контейнеры обеспечивают дешевую и эффективную изоляция программного обеспечения и метод развертывания (в том смысле, что вы можете развернуть несколько контейнеров бок о бок, не беспокоясь о конфликтующих версиях).
Более того, если вы хотите реализовать гибридное облако (т. Е. Переход от частного облака к общедоступному), контейнеры - это очень простой способ связать обе среды, абстрагируя их различия.
Моя личная стратегия (при условии, что я правильно понимаю ваши потребности) заключалась в том, чтобы изолировать клиентов с виртуальными машинами и полагаться на простое частное облако (OpenStack или другое), развертывать их в контейнерах и перемещать эти контейнеры между вашим частным облаком и общедоступным. облако по мере необходимости. Конечно, вы можете изменить размер своих виртуальных машин (в любом облаке), чтобы учесть колебания требований к ресурсам.