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