Использование 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 в нашей внутренней среде, вероятно, не уникален. Кто-нибудь еще сталкивался с этими проблемами? И что более важно, доступны ли обходные пути?
7 ответов
После развертывания / начальной загрузки 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-адресов происходило автоматически при порождении экземпляра.
Что касается проблемы с proxy-to-apt, было бы здорово, если бы Juju позволил пользователям настраивать облачный конфиг, который передается новым узлам для начальной загрузки агентов Juju. Если это было возможно, вы можете настроить свои apt прокси вместе с облачным конфигурацией, специфичной для juju. Поскольку это в настоящее время не поддерживается, одним из вариантов будет публикация настраиваемого облачного образа в Glance, который содержит apt.conf для вашей среды, и установите default-image-id в environment.yaml для этого идентификатора AMI.
После развертывания / начальной загрузки 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-адресов происходило автоматически при порождении экземпляра.
Что касается проблемы с proxy-to-apt, было бы здорово, если бы Juju позволил пользователям настраивать облачный конфиг, который передается новым узлам для начальной загрузки агентов Juju. Если это было возможно, вы можете настроить свои apt прокси вместе с облачным конфигурацией, специфичной для juju. Поскольку это в настоящее время не поддерживается, одним из вариантов будет публикация настраиваемого облачного образа в Glance, который содержит apt.conf для вашей среды, и установите default-image-id в environment.yaml для этого идентификатора AMI.
После развертывания / начальной загрузки 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-адресов происходило автоматически при порождении экземпляра.
Что касается проблемы с proxy-to-apt, было бы здорово, если бы Juju позволил пользователям настраивать облачный конфиг, который передается новым узлам для начальной загрузки агентов Juju. Если это было возможно, вы можете настроить свои apt прокси вместе с облачным конфигурацией, специфичной для juju. Поскольку это в настоящее время не поддерживается, одним из вариантов будет публикация настраиваемого облачного образа в Glance, который содержит apt.conf для вашей среды, и установите default-image-id в environment.yaml для этого идентификатора AMI.
После развертывания / начальной загрузки 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-адресов происходило автоматически при порождении экземпляра.
Что касается проблемы с proxy-to-apt, было бы здорово, если бы Juju позволил пользователям настраивать облачный конфиг, который передается новым узлам для начальной загрузки агентов Juju. Если это было возможно, вы можете настроить свои apt прокси вместе с облачным конфигурацией, специфичной для juju. Поскольку это в настоящее время не поддерживается, одним из вариантов будет публикация настраиваемого облачного образа в Glance, который содержит apt.conf для вашей среды, и установите default-image-id в environment.yaml для этого идентификатора AMI.
После развертывания / начальной загрузки 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-адресов происходило автоматически при порождении экземпляра.
Что касается проблемы с proxy-to-apt, было бы здорово, если бы Juju позволил пользователям настраивать облачный конфиг, который передается новым узлам для начальной загрузки агентов Juju. Если это было возможно, вы можете настроить свои apt прокси вместе с облачным конфигурацией, специфичной для juju. Поскольку это в настоящее время не поддерживается, одним из вариантов будет публикация настраиваемого облачного образа в Glance, который содержит apt.conf для вашей среды, и установите default-image-id в environment.yaml для этого идентификатора AMI.
После развертывания / начальной загрузки 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-адресов происходило автоматически при порождении экземпляра.
Что касается проблемы с proxy-to-apt, было бы здорово, если бы Juju позволил пользователям настраивать облачный конфиг, который передается новым узлам для начальной загрузки агентов Juju. Если это было возможно, вы можете настроить свои apt прокси вместе с облачным конфигурацией, специфичной для juju. Поскольку это в настоящее время не поддерживается, одним из вариантов будет публикация настраиваемого облачного образа в Glance, который содержит apt.conf для вашей среды, и установите default-image-id в environment.yaml для этого идентификатора AMI.
После развертывания / начальной загрузки 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-адресов происходило автоматически при порождении экземпляра.
Что касается проблемы с proxy-to-apt, было бы здорово, если бы Juju позволил пользователям настраивать облачный конфиг, который передается новым узлам для начальной загрузки агентов Juju. Если это было возможно, вы можете настроить свои apt прокси вместе с облачным конфигурацией, специфичной для juju. Поскольку это в настоящее время не поддерживается, одним из вариантов будет публикация настраиваемого облачного образа в Glance, который содержит apt.conf для вашей среды, и установите default-image-id в environment.yaml для этого идентификатора AMI.
-
1Прошло довольно много времени с тех пор, как вы опубликовали это, но в настоящее время я сталкиваюсь с точно такой же проблемой (DNS, плавающий ip и прокси). Это может быть довольно распространенным явлением для любого частного облака в корпоративной среде. Вы нашли какое-нибудь решение для прокси? – gdupont 25 July 2017 в 19:41