Почему контейнеры управления не получают IP-адреса при установке с OpenStack-Ansible? - PullRequest
0 голосов
/ 06 ноября 2018

В целях тестирования я хочу установить OpenStack на два экземпляра VirtualBox, используя Ansible. Как сказано в документации , я предварительно настроил локальную сеть с четырьмя VLAN. И создать мостовые интерфейсы. После этого все в порядке.

Я также настраиваю openstack_user_config.yml файл.

---
cidr_networks:
  container: 172.29.236.0/22
  tunnel: 172.29.240.0/22
  storage: 172.29.244.0/22
used_ips:
  - "172.29.236.1,172.29.236.255"
  - "172.29.240.1,172.29.240.255"
  - "172.29.244.1,172.29.244.255"

global_overrides:
  internal_lb_vip_address: 192.168.33.22
  external_lb_vip_address: dev-ows.hive
  tunnel_bridge: "br-vxlan"
  management_bridge: "br-mgmt"
  provider_networks:
    - network:
      container_bridge: "br-mgmt"
      container_type: "veth"
      container_interface: "eth1"
      ip_from_q: "container"
      type: "raw"
      group_binds:
        - all_containers
        - hosts
      is_container_address: true
    - network:
      container_bridge: "br-vxlan"
      container_type: "veth"
      container_interface: "eth10"
      ip_from_q: "tunnel"
      type: "vxlan"
      range: "1:1000"
      net_name: "vxlan"
      group_binds:
        - neutron_linuxbridge_agent
    - network:
      container_bridge: "br-vlan"
      container_type: "veth"
      container_interface: "eth11"
      type: "flat"
      net_name: "flat"
      group_binds:
        - neutron_linuxbridge_agent
    - network:
      container_bridge: "br-storage"
      container_type: "veth"
      container_interface: "eth2"
      ip_from_q: "storage"
      type: "raw"
      group_binds:
        - glance_api
        - cinder_api
        - cinder_volume
        - nova_compute
...

Но я получаю ошибку после запуска playbook:

# openstack-ansible setup-hosts.yml
...
TASK [lxc_container_create : Gather container facts] *********************************************************************************************************************************************************************************************************
fatal: [controller01_horizon_container-6da3ab23]: UNREACHABLE! => {"changed": false, "msg": "SSH Error: data could not be sent to remote host \"controller01_horizon_container-6da3ab23\". Make sure this host can be reached over ssh", "unreachable": true}
fatal: [controller01_utility_container-3d6724b2]: UNREACHABLE! => {"changed": false, "msg": "SSH Error: data could not be sent to remote host \"controller01_utility_container-3d6724b2\". Make sure this host can be reached over ssh", "unreachable": true}
fatal: [controller01_keystone_container-01c915b6]: UNREACHABLE! => {"changed": false, "msg": "SSH Error: data could not be sent to remote host \"controller01_keystone_container-01c915b6\". Make sure this host can be reached over ssh", "unreachable": true}
...

Я выяснил, что контейнеры LXC, созданные в Plays книги Ansible, не имеют интерфейсов и, следовательно, IP-адреса. Вот почему, когда Ansible подключается через ssh к этим контейнерам, я получаю сообщение об ошибке «Host unreachable».

# lxc-ls -f
NAME                                           STATE   AUTOSTART GROUPS            IPV4 IPV6 UNPRIVILEGED
controller01_cinder_api_container-e80b0c98     RUNNING 1         onboot, openstack -    -    false
controller01_galera_container-2f58aec8         RUNNING 1         onboot, openstack -    -    false
controller01_glance_container-a2607024         RUNNING 1         onboot, openstack -    -    false
controller01_heat_api_container-d82fd06a       RUNNING 1         onboot, openstack -    -    false
controller01_horizon_container-6da3ab23        RUNNING 1         onboot, openstack -    -    false
controller01_keystone_container-01c915b6       RUNNING 1         onboot, openstack -    -    false
controller01_memcached_container-352c2b47      RUNNING 1         onboot, openstack -    -    false
controller01_neutron_server_container-60ce9d02 RUNNING 1         onboot, openstack -    -    false
controller01_nova_api_container-af09cbb9       RUNNING 1         onboot, openstack -    -    false
controller01_rabbit_mq_container-154e35fe      RUNNING 1         onboot, openstack -    -    false
controller01_repo_container-bb1ebb24           RUNNING 1         onboot, openstack -    -    false
controller01_rsyslog_container-07902098        RUNNING 1         onboot, openstack -    -    false
controller01_utility_container-3d6724b2        RUNNING 1         onboot, openstack -    -    false

Пожалуйста, дайте мне несколько советов о том, что я делаю неправильно.

1 Ответ

0 голосов
/ 07 ноября 2018

Как вы заметили, контейнеры не получают управление ip.

Убедитесь, что мост br-mgmt на ваших двух виртуальных коробках работает должным образом? Проверьте связь между этими двумя хостами через br-mgmt. Например. ping с IP-адресом br-mgmt между двумя хостами.

Если вы правильно настроили vlan и мосты, вы сможете установить соединение между хостами через определенные мосты.

$ ansible -vi inventory/myos all -m shell -a "ip route" --limit infra,compute
Using /etc/ansible/ansible.cfg as config file
infra2 | SUCCESS | rc=0 >>
default via 10.255.0.1 dev eno1 onlink 
10.0.3.0/24 dev lxcbr0  proto kernel  scope link  src 10.0.3.1 
10.255.0.0/24 dev eno1  proto kernel  scope link  src 10.255.0.12 
172.29.236.0/22 dev br-mgmt  proto kernel  scope link  src 172.29.236.12 
172.29.240.0/22 dev br-vxlan  proto kernel  scope link  src 172.29.240.12 
172.29.244.0/22 dev br-storage  proto kernel  scope link  src 172.29.244.12 

infra1 | SUCCESS | rc=0 >>
default via 10.255.0.1 dev eno1 onlink 
10.0.3.0/24 dev lxcbr0  proto kernel  scope link  src 10.0.3.1 
10.255.0.0/24 dev eno1  proto kernel  scope link  src 10.255.0.11 
172.29.236.0/22 dev br-mgmt  proto kernel  scope link  src 172.29.236.11 
172.29.240.0/22 dev br-vxlan  proto kernel  scope link  src 172.29.240.11 
172.29.244.0/22 dev br-storage  proto kernel  scope link  src 172.29.244.11 

infra3 | SUCCESS | rc=0 >>
default via 10.255.0.1 dev eno1 onlink 
10.0.3.0/24 dev lxcbr0  proto kernel  scope link  src 10.0.3.1 
10.255.0.0/24 dev eno1  proto kernel  scope link  src 10.255.0.13 
172.29.236.0/22 dev br-mgmt  proto kernel  scope link  src 172.29.236.13 
172.29.240.0/22 dev br-vxlan  proto kernel  scope link  src 172.29.240.13 
172.29.244.0/22 dev br-storage  proto kernel  scope link  src 172.29.244.13

compute1 | SUCCESS | rc=0 >>
default via 10.255.0.1 dev eno1 onlink 
10.255.0.0/24 dev eno1  proto kernel  scope link  src 10.255.0.16 
172.29.236.0/22 dev br-mgmt  proto kernel  scope link  src 172.29.236.16 
172.29.240.0/22 dev br-vxlan  proto kernel  scope link  src 172.29.240.16 
172.29.244.0/22 dev br-storage  proto kernel  scope link  src 172.29.244.16 

compute2 | SUCCESS | rc=0 >>
default via 10.255.0.1 dev eno1 onlink 
10.255.0.0/24 dev eno1  proto kernel  scope link  src 10.255.0.17 
172.29.236.0/22 dev br-mgmt  proto kernel  scope link  src 172.29.236.17 
172.29.240.0/22 dev br-vxlan  proto kernel  scope link  src 172.29.240.17 
172.29.244.0/22 dev br-storage  proto kernel  scope link  src 172.29.244.17 

Таким образом, используя IP-адрес br-mgmt (172.29.236.x) с любого из хостов, указанных выше, я смог бы достичь равноправных узлов с той же подсетью br-mgmt.

...