Использование Juju с частным развертыванием Openstack в облаке?
Я вижу ряд проблем при попытке использовать Juju с нашим развернутым облаком Openstack. Большая часть этого, по-видимому, связана с разрешением узла DNS, а также с необходимостью иметь дело с внутренними HTTP-прокси нашей компании.
Наше развертывание Openstack основано на не маршрутизируемом блоке адресов 172.16.0.0/12 для распределения VLAN каждому проекту (арендатору), размещенному в нашем внутреннем облаке. У пользователей есть возможность назначать один или несколько плавающих адресов экземплярам, выделенным из блока маршрутизируемых адресов в локальной сети наших внутренних компаний.
В настоящее время Openstack не регистрирует имена экземпляров ни с чем, кроме службы DNSMASQ, работающей на облачном контроллере. Таким образом, нет способа разрешить этот адрес через нашу внутреннюю иерархию DNS (эта проблема уже была зарегистрирована как ошибка № 945505). Таким образом, даже несмотря на то, что я могу загрузить свой серверный узел Juju, я не могу подключиться к нему с помощью клиента Juju, поскольку он не может разрешить имя локальной (частной) сети. Я могу подключиться к узлу по ssh, как только я назначил ему внутренний маршрутизируемый (т.е. плавающий) адрес. Что приводит к следующему вопросу.
Далее, для установки программного обеспечения на экземпляр, работающий в нашем облаке, необходимо определить наш внутренний прокси-адрес - либо в файле apt.conf, либо через переменные среды. К сожалению, при начальной загрузке серверного узла нет никакой возможности передать эту информацию в экземпляр через файл JuJu environment.yaml (если это даже лучший способ справиться с этой проблемой). В результате узел начальной загрузки не может установить необходимые пакеты.
Я предполагаю (опасно, я знаю), что способ развертывания Openstack в нашей внутренней среде, вероятно, не уникален. Кто-нибудь еще сталкивался с этими проблемами? И что более важно, доступны ли обходные пути?
1 ответ
После развертывания / начальной загрузки Juju попытается подключиться к среде через публичный адрес экземпляров. AFAIK, он получает этот адрес прямо из вызова description_instance API EC2. В вашей среде появляются новые экземпляры с внутренним / частным адресом и без связанного публичного (плавающего) IP-адреса. Результатом является частный адрес как в полях личного, так и публичного адресов файла description_instances. После привязки плавающего IP к экземпляру в поле публичного адреса теперь должен отображаться вновь связанный адрес.
После подключения Juju сможет нормально подключаться через SSH (так же, как вы можете). Таким образом, вы должны иметь возможность «juju bootstrap», связать IP с узлом начальной загрузки, «juju status». Вам также необходимо связать плавающие IP-адреса со всеми другими развернутыми машинами. Одним из вариантов является добавление «--auto_assign_floating_ip» в nova.conf, так что сопоставление плавающего IP происходит автоматически при появлении экземпляра.
Что касается вопроса «прокси-сервер», было бы здорово, если бы Juju позволил пользователям настраивать облачный конфиг, который передается на новые узлы, для начальной загрузки агентов Juju. Если это было возможно, вы можете настроить свои apt прокси вместе с облачным конфигурацией, специфичной для juju. Поскольку это в настоящее время не поддерживается, одним из вариантов будет публикация настроенного облачного образа в Glance, который содержит apt.conf для вашей среды, и для этого параметра default-image-id в environment.yaml указан этот идентификатор AMI.