Я экспериментирую с использованием Juju (16.6) для развертывания сервисов в нашем частном облаке Openstack и обнаружил пару проблем.
При начальной загрузке новой среды Джуджу, очевидно, хочет искать в метаданных изображения эту среду. Я создал «публичное» ведро, используя Swift для хранилища объектов, и заполнил его метаданными изображения в путях объекта «streams / v1 / *» - однако при начальной загрузке juju происходит сбой, если метаданные не находятся в частное ведро среды. Это нормально? И есть ли обходной путь в конфигурации среды, чтобы решить эту проблему?
Моя среда выглядит следующим образом (за исключением ключей ssh):
access-key: ""
admin-secret: ""
agent-version: 1.16.6
api-port: 17070
auth-mode: userpass
auth-url: http://173.23.181.5:5000/v2.0
authorized-keys: 'ssh-rsa `...
...
ca-private-key: ""
control-bucket: juju-bucket
default-image-id: ""
default-instance-type: ""
default-series: precise
development: false
firewall-mode: instance
image-metadata-url: ""
logging-config: <root>=INFO
name: openstack-ws
password: xxxxxxxxxx
public-bucket: juju-dist
public-bucket-url: ""
region: regionOne
secret-key: ""
ssl-hostname-verification: true
state-port: 37017
tenant-name: WebServices
tools-url: ""
type: openstack
use-floating-ip: true
username: xxxxx
Как только я запускаю среду для начальной загрузки, я в следующий раз пытаюсь вызвать службу. В моем случае я использую брелок Hadoop. Когда я внедряю master-устройство hadoop (juju deploy hadoop hadoop-master
), экземпляр не может инициализироваться с помощью «hostname: name или service not unknown error». Я подозреваю, что это происходит из-за сбоя обратного поиска DNS на экземплярах "публичного" IP-адреса. Это звучит правильно? В чем проблема?
Обе настройки public-bucket
и public-bucket-url
устарели некоторое время назад и игнорируются. Используется только control-bucket
, если указано, иначе оно генерируется случайным образом. Закрытое хранилище - теперь единственный способ переопределить выбор инструментов juju с указанной версией из данных simplestreams.
Например, запустив juju bootstrap --upload-tools
, убедившись, что вы запустили эквивалент:
# cd $GOPATH/src/launchpad.net/juju-core/cmd/juju
# go install .
# cd ../jujud
# go install .
упаковывает двоичные файлы juju (juju и jujud) из $ PATH в tar-архив выпуска и загружает его в control-bucket
. Затем скрипт cloud-init запускается при загрузке машины начальной загрузки, загружая и устанавливая самые последние текущие инструменты (что - всегда обеспечивает upload-tools). Так что juju bootstrap --upload-tools
, если он взломан, безусловно, полезно проверить изменения в исходном ядре juju в реальном развертывании.
Кроме того, вы можете запустить:
juju sync-tools --all --public --source=~/.juju/local/storage/tools/release/
сразу после выполнения juju bootstrap -e local --upload-tools
(при условии, что вы выполнили 2 go install
команды, упомянутые ранее, при сборке из исходного кода). Таким образом, вам нужно будет запустить juju bootstrap -e local
и наблюдать за ходом работы / проверять журналы.