Предоставление Juju и Openstack
Я новичок в Juju и Openstack и в настоящее время развертываю тестовую среду openstack с двумя и тремя узлами, используя провайдер Juju. С первой попытки я попытался развернуть сервисы на моих хостах, используя ключ --to для juju deploy.
Я понял, что что-то идет не так, когда Juju не удалось создать связь между Keystone и MySQL, развернутыми на одном хосте. Для развертывания сервисов я использовал следующий синтаксис:
juju deploy keystone --to 1
juju deploy mysql --to 1
Некоторые поиски в Google дали мне этот вопрос по Askubuntu и это руководство .
Итак, как я понимаю, правильный способ развертывания служб в ручной среде - это использование контейнеров lxc для служб, развертываемых на одном хосте (если эти службы, конечно, могут работать в контейнерах).
Хотя я вижу такие преимущества lxc, как независимость и изоляция сервисов, я все еще не понимаю, почему сервисы, развернутые Juju, ДОЛЖНЫ быть изолированы в контейнерах. Это недостаток дизайна Juju или временное решение?
Есть ли способ развернуть пару сервисов на одном хосте без lxc?
Я думаю, что это можно сделать, указав конфигурационный файл для каждой развертываемой службы, но это устранит почти всю "магию" и простоту Juju ...
1 ответ
Сам амулет не заботится. Именно до очарования Вы развертываетесь для обработки ситуации, или нет. Таким образом, это действительно не рассматривают как проблему вообще; это - просто различие между тем, что поддерживает Амулет, что очарование обычно поддерживает, и принятая лучшая практика.
я не думаю, что этот ответ характерен для ручного поставщика. Это относится ко всем поставщикам.
Большая часть очарования предполагает, что они "владеют" машиной (или контейнер), что они развертываются на, и в прошлом это было единственным способом развернуть их.
Эта изоляция делает очарование легче разработать и протестировать. Это избавляет от необходимости разработчиков очарования волноваться о совместном использовании ресурсов с другим очарованием. Модульное развертывание облегчает управлять сложностью. Путем ограничения взаимодействий между очарованием к отношениям Амулета они могут остаться чистыми и хорошо понятыми. Авторы очарования не должны волноваться о создании "системы" - изменения уровня, которые могли бы неблагоприятно повлиять на другое очарование; это до контейнеризации для обработки этого правильно. Это устраняет целый класс ошибок очарования, где одно очарование оказывает негативное влияние на другого.
Так, на практике, очарование должно быть развернуто на своих собственных контейнерах как минимум, если они не специально предназначены для сотрудничества. Конфликты, которые возникают, когда два очарования развертывается на той же машине, не помещая их в контейнерах, не будут обычно рассматривать как ошибки.
Это не должно влиять на много. LXC легок.
Ни одно из этого не останавливает Вас пишущий Ваше собственное очарование или изменяющий существующее очарование, чтобы разрешить им быть развернутыми на той же машине или контейнере. Амулет разрешит его, но это тогда до очарования, чтобы гарантировать, чтобы они не конфликтовали.
действительно ли это - недостаток дизайна Амулета или временное решение?
Нет - это не действительно вещь Амулета вообще; это - выбранная лучшая практика среди авторов очарования и касается решений, принятых относительно того, какое очарование конфигураций развертывания должно и не должно поддерживать.
существуют некоторые пограничные случаи, где это полезно, и не трудно поддерживать (например, GUI Амулета, работающий на узле начальной загрузки), таким образом, Амулет разрешает его. Я полагаю, что нет никаких планов относительно поддержки Амулета изменению.