почему порядок действий имеет значение при установке плавающего ip на горизонте openstack?

Я хотел бы использовать openstack для установки экземпляров ubuntu / bionic. Перед автоматизацией создания экземпляра виртуальной машины с помощью ansible / openstack API я провел несколько тестов через веб-интерфейс openstack horizon. В основном я выполняю следующие шаги:

  1. создать сеть: my-network

    shared: False

subnet:
    address: 192.168.66.0/24
    IP version: IPv4
    gateway: 192.168.66.254
    allocation pool: 192.168.66.100,192.168.66.200
dns: my-dns-ips

  2. создать маршрутизатор: my-router

    external provider: provider
interface:
     subnet: my-network
     ip: 192.168.66.254

  3. создать экземпляр: мой-экземпляр

    network: my-network    
security group: default + ssh + icmp
keypair: generated via ssh-keygen and imported to horizon

  4. добавить плавающий IP-адрес в мой экземпляр

    ip: 192.168.13.209
port to be associated: my-instance:192.168.66.123

при выполнении этих шагов в следующем порядке: 1. 3. 2. 4., я могу ping и ssh на мою машину через плавающий IP-адрес, как и ожидалось. Однако, выполняя эти шаги в порядке 1. 2. 3. 4., я могу пинговать, но не могу ssh с ошибкой permission denied (publickey).

В идеале порядок 1. 2. 3. 4. был бы лучшим для моих будущих потребностей в ansible, поскольку они позволили бы четкое (и чистое) разделение между настройкой сети и распределением экземпляров.

Не могли бы вы сказать мне, почему этот заказ вызывает ошибку ssh, а другой работает отлично?

Это нормальное поведение, и если да, не могли бы вы мне объяснить, почему?

[EDIT] копаясь дальше в журнале успешных и неудачных экземпляров, я заметил, что сбойный не может найти ключ ssh. Это, очевидно, объясняет сбой ssh, но я до сих пор не понимаю, почему в этом случае пара ключей не вводится в экземпляр.


openstack openstack-horizon
person Eurydice    schedule 11.09.2019    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Это потому, что при первой попытке экземпляр может получить метаданные из DHCP-agent. Но во втором порядке сеть имеет gw на маршрутизаторе, и с тем, что показано на картинке, metadata-agent вступает в игру. Я не могу определить проблему с помощью такого количества информации, но предлагаю проверить metadata_proxy_shared_secret в конфигурационных файлах нейтронов и nova. Если это не ваш случай, не могли бы вы опубликовать файлы конфигурации нейтронных служб и объяснить, какая служба и где установлена?

person Siavash Sardari    schedule 17.09.2019
comment
Спасибо за объяснение. Это действительно имеет смысл. Я, наконец, смог сделать это без четкого понимания, установив для параметра os_server::config_drive значение True. - person Eurydice; 18.09.2019
comment
милости прошу, советую найти проблему в нейтрон-метаданных и l3 агентах. пока ваше решение работает, оно не позволит вам добавлять пользовательские данные в облачный init. metadata-agent - лучший способ внедрить метаданные в экземпляры. - person Siavash Sardari; 19.09.2019