Нужно ли помещать метаданные изображения в приватное ведро?

Я экспериментирую с использованием 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-адреса. Это звучит правильно? В чем проблема?

2
задан 22 February 2014 в 02:26

1 ответ

Обе настройки 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 и наблюдать за ходом работы / проверять журналы.

0
ответ дан 22 February 2014 в 02:26

Другие вопросы по тегам:

Похожие вопросы: