OpenStack est un ensemble modulaire intégrant divers produits Open Source, simplifiant et normalisant la mise en œuvre de “Clouds”. OpenStack se classe dans les IAAS – Infrastructure As A Service.
Il existe plusieurs façons de déployer un cluster OpenStack. Nous nous pencherons aujourd’hui sur TripleO (OpenStack On OpenStack), celui-ci automatisant le déploiement d’un cloud OpenStack à partir d’un second cloud, minimaliste.
La lecture de cet article vous permettra de déployer un OpenStack de test sur un environnement virtualisé à des fins de POC ou de validation de template.
Architecture
OpenStack pourra s’intégrer avec divers composants pouvant être existants dans l’infrastructure sur laquelle s’appuiera notre cluster.
Nous limiterons notre exemple à l’un des cas les plus simple. Nous utiliserons des machines virtuelles de type KVM, et l’isolation réseau à base de VLANs.
La particularité de TripleO étant que nous déploierons dans un premier temps une installation minimaliste d’OpenStack, l’undercloud, depuis laquelle nous personnaliserons et orchestrerons le déploiement d’un second cluster : l’overcloud.
Préparatifs
Avant de pouvoir déployer OpenStack, il nous faudra préparer les couches inférieures : routeurs, switches et hyperviseurs.
L’instance qui servira d’undercloud devra disposer de deux interfaces réseau, l’une d’elles dédiée au provisionning des nœuds devant constituer le cluster overcloud, l’autre servira aux communications des environnements virtualisés et services constituant le cluster overcloud. Cette seconde interface n’est pas strictement indispensable, mais le déploiement de l’undercloud semble reconfigurer l’interface de provisioning, et ce sans conserver les potentielles routes que nous aurions préalablement définies. Dans ce cas, nous devrons rétablir cette route tandis que l’undercloud s’installe, afin de conserver l’accès aux dépôts et autres sources externes dont dépendront ce déploiement. Ou au plus simple, ne pas utiliser de routes sur l’interface de déploiement.
Les nœuds composants l’overcloud devront pouvoir démarrer en PXE, en interrogeant les serveurs DHCP et TFTP qui seront déployés sur l’undercloud, lors de son installation.
Par ailleurs, les nœuds de l’overcloud devront pouvoir accéder aux différents VLANs que nous définirons pour isoler ses réseaux. L’overcloud comportant plusieurs types de nœuds, selon leur fonction, ceux-ci n’auront pas besoin d’accéder à tous ces réseaux.
Enfin, nous déploierons un serveur FreeIPA, qui fera office de serveur DNS et NTP, voire potentiellement de base d’utilisateurs, ou d’autorité de certification.
Réseau
Nous reprendrons l’exemple de configuration définissant et isolant différents réseaux composant un cluster OpenStack, avec pour seul ajustement la correction du plan d’adressage d’un VLAN, pour s’intégrer avec un réseau existant.
Nous y ajouterons un VLAN de provisioning, et un VLAN de services :
VLAN
ID Network Gateway Usage
10 10.42.46.0/24 10.42.46.1 OpenStack External VLAN
20 172.16.2.0/24 OpenStack Internal API
30 172.16.1.0/24 OpenStack Storage VLAN
40 172.16.3.0/24 OpenStack Storage Management
50 172.16.2.0/24 OpenStack Tenant VLAN
60 10.0.1.0/24 OpenStack Management VLAN
100 10.42.44.0/24 10.42.44.1 Common Services
200 10.42.242.0/24 10.42.242.1 OpenStack Provisioning Network
Hyperviseurs
À ce stade, nous ré-utiliserons plusieurs serveurs Debian Buster comme hyperviseurs KVM, qui devront héberger les différents nœuds de notre déploiement OpenStack.
Nous avons identifié 5 machines physiques. Une première devant héberger l’instance d’undercloud, et le contrôleur du cluster d’overcloud. Les quatre autres hébergeront un noeud compute chacune. L’une d’elles accueillant également le serveur FreeIPA.
Pour chaque machine virtuelle, nous allons créer un volume logique qui servira de support au disque virtuel :
# lvcreate -n osp-undercloud -L70G data
Pour les instances d’overcloud, nous pourrons laisser ce volume vierge, le déploiement de l’overcloud se faisant en PXE. Pour l’undercloud et le serveur FreeIPA, nous voudrons initialiser ces volumes depuis un template de guest CentOS 7 – image d’une installation minimale :
# zcat centos-7.6.img.gz | pv | \
dd of=/dev/data/osp-undercloud
# fdisk /dev/data/osp-undercloud
[ delete partition from template ]
[ create new partition ]
[ make sure start offset matches previous partition ]
[ make sure stop offset inclues the whole disk ]
[ make sure partition is bootable ]
[ write and exit ]
Du point de vue du réseau, pour les machines de l’overcloud, nous utiliserons une unique interface, par la quelle pourrons joindre les DHCP et PXE du VLAN de provisioning, ainsi que les différents VLANs du cluster. Pour l’undercloud, nous configurerons deux interfaces réseau : l’une dans le VLAN de Services, l’autre dans le VLAN de provisioning.
Sur nos hyperviseurs hébergeant les instances d’overcloud, nous devrons donc configurer un bridge qui donnera l’accès au réseau de déploiement (VLAN natif), et aux VLANs OpenStack (via tagging).
Notons que le processus de déploiement, en l’absence de DRAC ou ILO, impliquera la connexion, depuis l’undercloud, vers les hyperviseurs accueillant les instances d’overcloud. À ce titre, nous attribuerons à nos hyperviseurs une IP dans le réseau de provisioning, sur ce bridge :
# cat </etc/network/interfaces
auto eth0.200
iface eth0.200 inet manual
vlan-raw-device eth0
auto br200
iface br200 inet static
address 10.42.242.101
netmask 255.255.255.0
bridge_ports eth0.200
bridge_stp off
bridge_fd 0
bridge_maxwait 0
EOF
# ifup br200
Sur les hyperviseurs qui vont accueillir les instances undercloud et FreeIPA, il nous faudra un second bridge, accédant directement au VLAN de service. Ici, l’hyperviseur n’a pas besoin d’IP :
# cat </etc/network/interfaces
auto eth0.100
iface eth0.100 inet manual
vlan-raw-device eth0
auto br100
iface br100 inet manual
bridge_ports eth0.100
bridge_stp off
bridge_fd 0
bridge_maxwait 0
EOF
# ifup br100
Une fois que nous aurons déclaré nos réseaux et disques du point de vue de nos hyperviseurs, nous pourrons alors créer les machines virtuelles pour FreeIPA, l’Undercloud et l’Overcloud OpenStack, observant le dimensionnement suivant :
Node Disk CPU Memory Network
FreeIPA 8G+ 1+ 8192M eth0 access VLAN 200
undercloud 20G+ 1+ 14336M+ eth0 access VLAN 200
eth1 access VLAN 100
overcloud-controller 30G+ 1+ 8192M+ eth0 access VLAN 200
trunk all VLANs
overcloud-compute 30G+ 1+ 2048M+ eth0 access VLAN 200
trunk all VLANs
Enfin, pour chacune des machines virtuelles de l’overcloud, nous utiliserons VBMC, ce dernier permettant de démarrer ou éteindre une instance KVM à distance.
# apt-get install python-libvirt python3-libvirt \
python-dev python-pip gcc libvirt-dev
# pip install --upgrade setuptools
# pip install prettytable unicodecsv pyyaml stevedore
# pip install virtualbmc
# vbmc add os-controller --username bmcadmin \
--password bmcsecret --port 623
# vbmc start os-controller
# vbmc list
Répéter pour chaque instance qui composera le cluster d’overcloud. Si un hyperviseur devait accueillir plusieurs machines virtuelles, il faudrait utiliser différents ports.
FreeIPA
À ce stade, nous disposons d’une paire de machines virtuelles CentOS 7. Nous pourrons démarrer la première, pour déployer FreeIPA.
Nous pourrons alors étendre le système de fichiers racine, configurer le réseau et le FQDN de cette machine. En profiter pour mettre à jour le système et redémarrer :
# resize2fs /dev/vda1
# nmtui
# yum -y update
# reboot
Nous nommerons ce serveur “ipa.openstack.local“. Nous utiliserons l’IP 10.42.44.200/24, gateway 10.42.44.1, et un DNS publique quelconque (1.1.1.1, 8.8.8.8, …).
Nous pourrons enchaîner avec le déploiement de FreeIPA, et la configuration des différentes zones DNS que nous manipulerons dans OpenStack :
# yum -y install ipa-server ipa-server-dns
# ipa-server-install -U -r OPENSTACK.LOCAL \
-p mysecret42 -a mysecret42 \
--hostname ipa.openstack.local \
--ip-address=10.42.44.200 \
--setup-dns --auto-forwarders --auto-reverse
# kinit admin
# ipa dnszone-mod openstack.local. \
--dynamic-update=TRUE --allow-sync-ptr=TRUE
# for rev in 0.16.172 1.0.10 1.16.172 2.16.172 \
242.42.10 3.16.172 44.42.10 46.42.10
do
ipa dnszone-add $rev.in-addr.arpa. \
--dynamic-update=TRUE --allow-sync-ptr=TRUE
done
Déploiement OpenStack
Undercloud
Nous pouvons maintenant finaliser la configuration de notre seconde machine virtuelle CentOS 7, qui hébergera l’Undercloud.
Préparatifs
À nouveau, commencer par retailler le système de fichiers racine. Nous nommerons ce serveur “undercloud.openstack.local“. Nous utiliserons l’IP 10.42.44.201/24, gateway 10.42.44.1, et 10.42.44.200 (FreeIPA) comme serveur DNS. Sur la seconde interface, nous configurerons l’IP 10.42.242.60/24.
# resize2fs /dev/vda1
# nmtui
# yum -y update
# reboot
Nous pourrons poursuivre en préparant le déploiement de l’undercloud :
# yum -y update
# echo net.ipv4.ip_forward=1 \
>>/etc/sysctl.d/99-sysctl.conf
# useradd stack
# passwd stack
# echo "stack ALL=(root) NOPASSWD:ALL" \
| tee -a /etc/sudoers.d/stack
# chmod 0440 /etc/sudoers.d/stack
# yum -y install \
https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
# yum -y install \
https://trunk.rdoproject.org/centos7/current/python2-tripleo-repos-0.0.1-0.20190724014728.1cf6e0b.el7.noarch.rpm
# tripleo-repos -b queens current ceph
# yum -y install python-tripleoclient ceph-ansible \
python-novajoin ansible git ipmitool strace tcpdump
# ssh-keygen -t rsa
# cat /root/.ssh/id_rsa.pub >>/root/.ssh/authorized_keys
# cp -rp /root/.ssh /home/stack/
# ln -sf /usr/share/zoneinfo/Europe/Paris /etc/localtime
# chown -R stack:stack /home/stack
Nous ne nous attarderons pas sur ce sujet, mais notons qu’il sera possible d’intégrer les machines de l’overcloud à FreeIPA. Pour ce faire, nous devrons générer un token, avec la commande suivante :
# /usr/libexec/novajoin-ipa-setup --principal admin \
--password mysecret42 --server ipa.openstack.local \
--realm OPENSTACK.LOCAL --domain openstack.local \
--hostname undercloud.openstack.local --precreate
Auquel cas, conservez ce token, nous le ré-utiliserons dans un instant.
Il est par ailleurs possible, mais pas indispensable, d’enregistrer la machine undercloud dans FreeIPA :
# ipa-client-install --force-ntpd \
--ip-address=10.42.242.60
# kinit admin
Si l’on voulait procéder sans enregistrer l’undercloud à FreeIPA, ni novajoin, alors il faudra déclarer l’enregistrement DNS pointant vers l’undercloud dans FreeIPA.
Configuration
La suite des opérations sera à réaliser depuis le compute utilisateur “stack” que nous venons de créer :
# su - stack
Nous devrons alors configurer le déploiement de notre undercloud. Nous pourrons reprendre et adapter l’exemple fourni dans “/usr/share/python-tripleoclient/undercloud.conf.sample“.
$ cat \
/usr/share/python-tripleoclient/undercloud.conf.sample \
>~/undercloud.conf
$ vi ~/undercloud.conf
Dans notre cas, après définition des interfaces, plans d’addressage et autres spécifiques à notre déploiement, nous en arrivons à la copie suivante :
[DEFAULT]
local_ip = 10.42.242.60/24
local_interface = eth0
local_mtu = 1500
masquerade_network = 10.42.242.0/24
network_cidr = 10.42.242.0/24
network_gateway = 10.42.242.1
overcloud_domain_name = openstack.local
undercloud_admin_host = undercloud.openstack.local
undercloud_debug = true
undercloud_hostname = undercloud.openstack.local
undercloud_nameservers = 10.42.44.200
undercloud_ntp_servers = 10.42.44.200
undercloud_public_host = undercloud.openstack.local
undercloud_update_packages = true
certificate_generation_ca = local
service_principal =
# assuming IPA CA, use instead:
# certificate_generation_ca = IPA
# service_principal = haproxy/undercloud.openstack.local/OPENSTACK.LOCAL
# hieradata_override = /home/stack/undercloud-timeout.yaml
generate_service_certificate = true
generate_service_certificates = true
undercloud_service_certificate =
# IDM integration:
# enable_novajoin = true
# ipa_otp = <secret-from-novajoin>
enabled_drivers = pxe_drac,pxe_ilo,pxe_ipmitool
enabled_hardware_types = idrac,ipmi,redfish,ilo
dhcp_start = 10.42.242.211
dhcp_end = 10.42.242.220
discovery_iprange = 10.42.242.221,10.42.242.230
ipxe_enabled = true
inspection_interface = eth0
inspection_iprange = 10.42.242.221,10.42.242.230
scheduler_max_attempts = 30
[ctlplane-subnet]
cidr = 10.42.242.0/24
gateway = 10.42.242.1
dhcp_start = 10.42.242.211
dhcp_end = 10.42.242.220
inspection_interface = eth0
inspection_iprange = 10.42.242.221,10.42.242.230
masquerade = true
Déploiement
Une fois que nous aurons fixé les détails du déploiement de l’undercloud, nous pourrons lancer son installation :
$ openstack undercloud install
Cette étape pourra prendre de 10 à 30 minutes, suivant les ressources matérielles du serveur d’undercloud. Notons qu’en deça de 14G de mémoire, ou 12G d’espace disque libre, il est peu probable que cette étape aboutisse.
En fin d’installation, nous retrouverons un fichier /home/stack/stackrc, que nous voudrons modifier en suivant. Par ailleurs, nous incluerons ce fichier depuis la configuration bash de notre utilisateur :
$ echo "export
DIB_YUM_REPO_CONF=\"/etc/yum.repos.d/delorean*\"" \
>>~/stackrc
$ ( echo 'if test -s $HOME/stackrc; then'; \
echo ' . $HOME/stackrc'; echo 'fi'; \
) >>~/.bashrc
$ exec bash
Ne pas oublier de relancer bash, les variables en question étant indispensable à la suite des opérations.
Notons que le déploiement de l’undercloud implique l’installation et la configuration d’HAproxy. Celui-ci se charge, entre autres, d’exposer les différents services de l’undercloud en HTTPS / WSS. Cependant, une majorité des relais configurés vont écouter sur la loopback du noeud, rendant ces services injoignables par les nœuds de l’overcloud lors de leur déploiement. Nous voudrons prendre le temps de reprendre le fichier /etc/haproxy/haproxy.cfg, s’assurant que nos services soient bien joignables depuis le réseau de provisionning :
$ cat ~/haproxy.cfg.patch
--- /etc/haproxy/haproxy.cfg 2019-08-22 09:35:32.509005248 +0200
+++ /etc/haproxy/haproxy.cfg 2019-08-22 10:12:01.624682174 +0200
@@ -24,6 +24,7 @@
timeout check 10s
listen aodh
+ bind 10.42.242.60:13042 transparent ssl crt /etc/pki/tls/certs/undercloud-undercloud.openstack.local.pem
bind undercloud.openstack.local:13042 transparent ssl crt /etc/pki/tls/certs/undercloud-undercloud.openstack.local.pem
bind undercloud.openstack.local:8042 transparent
mode http
@@ -36,6 +39,9 @@
server 10.42.242.60 10.42.242.60:8042 check fall 5 inter 2000 rise 2
[...]
$ sudo su
# cd /etc/haproxy
# patch -p0 <~stack/haproxy.cfg
# systemctl restart haproxy
# exit
Overcloud
Le déploiement de l’overcloud est un processus bien plus long et complexe que celui de l’undercloud. À ce stade, il peut être préférable de prendre un snapshot de vos machines virtuelles, si l’on voulait pouvoir répeter les prochaines étapes sans perdre de temps au re-déploiement des briques sous-jacentes.
Différentes classes Puppet et roles Ansible vont rentrer en jeu, sur l’undercloud, et l’overcloud. Nous pourrons personnaliser leur fonctionnement en incorporant nos propres YAML.
Intégration Réseau
Dans un premier temps, nous pourrons nous intéresser au fichier “/usr/share/openstack-tripleo-heat-templates/network_data.yaml“, celui-ci inventoriant les VLANs constituant de l’overcloud. Dans notre cas, nous voudrons modifier le plan d’addressage du VLAN External. Ce que nous pourrons faire comme suit :
$ sed -e 's|10.0.0.0|10.42.46.0|' \
-e 's|10.0.0.4|10.42.46.10|' \
-e 's|10.0.0.250|10.42.46.250|' \
/usr/share/openstack-tripleo-heat-templates/network_data.yaml \
| grep -v ipv6 >~/network_data.yaml
En suivant, nous pourrons générer les YAML représentant la configuration par défaut qu’utilisera le processus de déploiement :
$ cd /usr/share/openstack-tripleo-heat-templates/
$ ./tools/process-templates.py -n ~/network_data.yaml \
-o ~/openstack-tripleo-heat-templates-rendered/
$ cd
Nous disposons à présent d’un visuel sur les différents paramètres contrôlant le déploiement de l’overcloud, dans “~/openstack-tripleo-heat-templates-rendered“.
Nous pourrions alors poursuivre en modifiant le mode de configuration des interfaces réseau sur les nœuds du cluster. Les défaults sont se trouvant dans l’un des dossiers que nous avons généré : “/home/stack/openstack-tripleo-heat-templates-rendered/network/config/single-nic-vlans/“.
Notons la présence d’exemples alternatifs, configurant trunk LACP ou utilisant des interfaces physiques indépendante pour chaque VLAN, dans le dossier parent. Notre installation se contentera de la configuration par défaut, mutualisant une unique interface physique pour le provisioning et les VLANs d’OpenStack.
Pour personnaliser la configuration de nos interfaces, nous partirons d’une copie des défauts générés précédemment :
$ mkdir ~/templates
$ cp -rp \
~/openstack-tripleo-heat-templates-rendered/network/config/single-nic-vlans/ \
~/templates/custom-nics
Dans ce cas, nous voudrons corriger le chemin d’inclusion d’un script :
$ sed -i \
's|../../scripts/run-os-net-config.sh|/home/stack/openstack-tripleo-heat-templates-rendered/network/scripts/run-os-net-config.sh|' \
~/templates/custom-nics/*yaml
Après quoi, nous pourrons éditer le contenu des fichiers dans “/home/stack/templates/custom-nics“. Notons que ce dossier doit comporter un fichier YAML par type de noeud constituant le cluster d’overcloud.
Nous voudrons ensuite corriger certaines IPs et plans d’adressage :
$ sed -e 's|192.168.24.254|10.42.242.1|' \
-e 's|192.168.24.1|10.42.242.60|' \
-e 's|8.8.8.8","8.8.4.4|10.42.44.200|' \
~/openstack-tripleo-heat-templates-rendered/environments/network-environment.yaml \
>~/templates/custom-network-environment.yaml
Si nous avons personnalisé la configuration de nos interfaces, il faudra alors inclure ces fichiers depuis un YAML décrivant l’environnement réseau du cluster d’overcloud :
$ sed -i \
's|../network/config/single-nic-vlans|/home/stack/templates/custom-nics|' \
~/templates/custom-network-environment.yaml
Une autre option que nous pouvons définir ici serait la timezone des machines de l’overcloud :
$ echo ' TimeZone: Europe/Paris' \
>>~/templates/custom-network-environment.yaml
Enfin, nous voudrons que nos machines, et toutes FQDN en général, se trouvent dans le domaine “openstack.local” :
$ sed 's|localdomain|openstack.local|' \
~/openstack-tripleo-heat-templates-rendered/environments/predictable-placement/custom-domain.yaml \
>~/templates/custom-domain.yaml
Préparation des Images
Tandis que l’on met au point les différents fichiers de configurations qui nous assisterons dans le déploiement d’OpenStack, nous voudrons assembler les premières images qui serviront de source au déploiement des nœuds composant l’overcloud.
Dans notre cas, nous nous en tiendrons aux défauts, et mettrons ces images à disposition des autres nœuds :
$ openstack overcloud image build
$ openstack overcloud image upload
Il semblerait que des paquets existent, livrant une version pré-compilée de ces images, au moins pour RedHat. N’ayant pas retrouvé l’équivalent CentOS, compter de 20 à 30 minutes pour les générer vous même.
Inventaire
Pour procéder au déploiement de notre overcloud, il nous faudra transmettre à l’undercloud un inventaire de nos machines.
Celui-ci doit à minima fournir une liste associant le nom d’un noeud, aux addresse MAC et infos de connexion BMC (ou IPMI, DRAC, …), afin que l’undercloud puisse orchestrer les redémarrages et le provisionnement PXE de chaque instance.
$ cat <<EOF >~/instackenv.json
{ "nodes": [
{
"name": "controller",
"mac": [ "52:54:00:9d:9b:2f" ],
"pm_password": "bmcsecret",
"pm_type": "ipmi",
"pm_user": "bmcadmin",
"pm_addr": "10.42.242.101",
"pm_port": "623",
"cpu": "1",
"memory": "1024",
"disk": "20",
"arch": "x86_64",
"capabilities": "profile:control,boot_option:local"
}, {
"name": "compute1",
"mac": [ "52:54:00:34:a2:7c" ],
"pm_password": "bmcsecret",
"pm_type": "ipmi",
"pm_user": "bmcadmin",
"pm_addr": "10.42.242.100",
"pm_port": "623",
"cpu": "1",
"memory": "1024",
"disk": "20",
"arch": "x86_64",
"capabilities": "profile:compute,boot_option:local"
}, {
"name": "compute2",
"mac": [ "52:54:00:c5:d5:b4" ],
"pm_password": "bmcsecret",
"pm_type": "ipmi",
"pm_user": "bmcadmin",
"pm_addr": "10.42.242.23",
"pm_port": "623",
"cpu": "1",
"memory": "1024",
"disk": "20",
"arch": "x86_64",
"capabilities": "profile:compute,boot_option:local"
}, {
"name": "compute3",
"mac": [ "52:54:00:5f:54:17" ],
"pm_password": "bmcsecret",
"pm_type": "ipmi",
"pm_user": "bmcadmin",
"pm_addr": "10.42.242.22",
"pm_port": "623",
"cpu": "1",
"memory": "1024",
"disk": "20",
"arch": "x86_64",
"capabilities": "profile:compute,boot_option:local"
}, {
"name": "compute4",
"mac": [ "52:54:00:57:a6:26" ],
"pm_password": "bmcsecret",
"pm_type": "ipmi",
"pm_user": "bmcadmin",
"pm_addr": "10.42.242.19",
"pm_port": "623",
"cpu": "1",
"memory": "1024",
"disk": "20",
"arch": "x86_64",
"capabilities": "profile:compute,boot_option:local"
} ]
}
EOF
Les infos telles que CPU, mémoire ou disque sont purement déclaratives, et ne reflètent pas la réalité. Seules les addresses MAC et infos relatives au power management sont critiques à ce stade.
Une étape ultérieure se chargera de corriger le reste.
Configuration Undercloud
Avant de lancer le déploiement de l’overcloud, nous pourrons procéder à quelques derniers ajustements. Par exemple, nous pouvons définir le serveur DNS du réseau de déploiement :
$ openstack subnet set ctlplane-subnet \
--dns-nameserver 10.42.44.200
Considérant que les machines virtuelles constituant notre overcloud ne disposent pas des prérequis matériel, nous voudrons définir quelques “flavors“, se substituant aux défauts, trop gourmands pour un simple test. L’unique différence avec les défauts se trouvant dans la taille minimale du disque, que nous diminuons de 40 à 12 Go :
$ openstack flavor create --id auto --ram 1024 \
--disk 12 --vcpus 1 testcompute
$ openstack flavor set \
--property capabilities:boot_option=local \
--property capabilities:profile=compute \
--property resources:CUSTOM_BAREMETAL=1 \
--property resources:DISK_GB=0 \
--property resources:MEMORY_MB=0 \
--property resources:VCPU=0 testcompute
$ openstack flavor create --id auto --ram 1024 \
--disk 12 --vcpus 1 testcontrol
$ openstack flavor set \
--property capabilities:boot_option=local \
--property capabilities:profile=control \
--property resources:CUSTOM_BAREMETAL=1 \
--property resources:DISK_GB=0 \
--property resources:MEMORY_MB=0 \
--property resources:VCPU=0 testcontrol
$ openstack flavor create --id auto --ram 1024 \
--disk 12 --vcpus 1 testceph
$ openstack flavor set \
--property capabilities:boot_option=local \
--property capabilities:profile=ceph-storage \
--property resources:CUSTOM_BAREMETAL=1 \
--property resources:DISK_GB=0 \
--property resources:MEMORY_MB=0 \
--property resources:VCPU=0 testceph
Ayant défini nos propres flavors, il faudra nous assurer que celles-ci soient utilisées lors du déploiement. De plus, nous voudrons fixer le nombre de noeuds à provisionner par flavor. Ce que nous pourrons faire en créant le fichier suivant :
$ ( echo parameter_defaults:; \
echo " OvercloudControllerFlavor: testcontrol"; \
echo " OvercloudCephStorageFlavor: testceph"; \
echo " OvercloudComputeFlavor: testcompute"; \
echo " ControllerCount: 1"; \
echo " ComputeCount: 4"; \
) >~/templates/counts-and-flavors.yaml
À ce stade, nous voudrons reconfigurer le service Dnsmasq d’Ironic, afin que celui-ci écoute sur l’interface de déploiement – sans quoi, le DHCP ne renvoit pas les options 66 & 67 (next-server et filename, décrivant comment démarrer depuis le PXE) :
$ echo interface=br-ctlplane | \
sudo tee -a /etc/ironic-inspector/dnsmasq.conf
$ sudo systemctl restart \
openstack-ironic-inspector-dnsmasq
Nous pourrons enfin valider l’inventaire de notre overcloud :
$ openstack overcloud node import \
--validate-only instackenv.json
Et l’importer :
$ openstack overcloud node import instackenv.json
Nous pouvons alors interroger l’API de l’undercloud, et confirmer que nos machines ont correctement été importées :
$ openstack baremetal node list
+--------------------------------------+------------+-----------------+-------------+--------------------+-------------+
| UUID | Name | Instance UUID | Power State | Provisioning State | Maintenance |
+--------------------------------------+------------+-----------------+-------------+--------------------+-------------+
| 29a51f91-65a7-4f42-b5fe-bc81e8cb6418 | controller | | power off | manageable | False |
| 7927c564-0fb9-49a7-a106-a072941070c1 | compute1 | | power off | manageable | False |
| ee1ef30c-06aa-46af-b172-034dbb29c944 | compute2 | | power off | manageable | False |
| 0d355d21-b572-425e-a0d0-7a095998bedb | compute3 | | power off | manageable | False |
| 3a0ca022-307e-4754-bc31-7a4ef8e82ed2 | compute4 | | power off | manageable | False |
+--------------------------------------+------------+-----------------+-------------+--------------------+-------------+
A ce stade, nous pourrons lancer l’introspection des nœuds, finalisant les préparatifs du déploiement :
$ openstack baremetal introspection start --wait \
--all-manageables --provide
$ openstack baremetal node list
+--------------------------------------+------------+-----------------+-------------+--------------------+-------------+
| UUID | Name | Instance UUID | Power State | Provisioning State | Maintenance |
+--------------------------------------+------------+-----------------+-------------+--------------------+-------------+
| 29a51f91-65a7-4f42-b5fe-bc81e8cb6418 | controller | | power off | available | False |
| 7927c564-0fb9-49a7-a106-a072941070c1 | compute1 | | power off | available | False |
| ee1ef30c-06aa-46af-b172-034dbb29c944 | compute2 | | power off | available | False |
| 0d355d21-b572-425e-a0d0-7a095998bedb | compute3 | | power off | available | False |
| 3a0ca022-307e-4754-bc31-7a4ef8e82ed2 | compute4 | | power off | available | False |
+--------------------------------------+------------+-----------------+-------------+--------------------+-------------+
Une fois que nos instances ont toutes pour status “available”, nous pourrons procéder au déploiement de l’overcloud.
Déploiement
Ayant fixé les détails intégrant OpenStack à notre infrastructure, préparé nos images, importé l’inventaire de l’overcloud, … nous pourrons lancer le déploiement d’OpenStack.
Ici, une seule commande suffit. Il faudra prendre soin d’y inclure tous les fichiers YAML re-définissant des variables que nous aurions personnalisées :
$ openstack overcloud deploy \
--ntp-server 10.42.44.200 \
--templates \
/home/stack/openstack-tripleo-heat-templates-rendered \
-n /home/stack/network_data.yaml \
-e /home/stack/templates/counts-and-flavors.yaml \
-e \
/home/stack/templates/custom-network-environment.yaml \
-e /home/stack/openstack-tripleo-heat-templates-rendered/environments/low-memory-usage.yaml \
-e /home/stack/openstack-tripleo-heat-templates-rendered/environments/network-isolation.yaml \
-e /home/stack/templates/custom-domain.yaml
Notons qu’en plus des variables que nous avons renseigné dans “/home/stack/templates“, notre commande de déploiement appelle un fichier “low-memory-usage“, et un “network-isolation“. Ceux ci n’étant pas inclus par défaut, mais définissant des options utiles dans notre contexte (faible ressources matérielles, et isolation des réseaux métiers).
Dans le cas d’un déploiement tirant partie de l’intégration FreeIPA (DNS, identification utilisateurs, PKI), nous pourrions ajouter les options “-e ~/openstack-tripleo-heat-templates-rendered/environments/services/haproxy-public-tls-certmonger.yaml“, “-e ~/openstack-tripleo-heat-templates-rendered/environments/ssl/tls-everywhere-endpoints-dns.yaml” et “-e ~/openstack-tripleo-heat-templates-rendered/environments/ssl/enable-internal-tls.yaml“.
Compter au moins une heure pour déployer l’overcloud avec un minimum d’options et d’intégrations.
$ openstack baremetal node list
+--------------------------------------+------------+--------------------------------------+-------------+--------------------+-------------+
| UUID | Name | Instance UUID | Power State | Provisioning State | Maintenance |
+--------------------------------------+------------+--------------------------------------+-------------+--------------------+-------------+
| 29a51f91-65a7-4f42-b5fe-bc81e8cb6418 | controller | dd310ff3-b0c1-4154-b32d-1510ff26c8a3 | power on | active | False |
| 7927c564-0fb9-49a7-a106-a072941070c1 | compute1 | ee22ecf4-6dd7-47f7-a6fd-67ede8ec4e2e | power on | active | False |
| ee1ef30c-06aa-46af-b172-034dbb29c944 | compute2 | 1f517053-986d-48a6-9a5f-fb5ea1d9b29e | power on | active | False |
| 0d355d21-b572-425e-a0d0-7a095998bedb | compute3 | 6954fc84-175b-40fc-b312-35f60fc16b31 | power on | active | False |
| 3a0ca022-307e-4754-bc31-7a4ef8e82ed2 | compute4 | a93034b9-0449-40c5-8688-292ac682679d | power on | active | False |
+--------------------------------------+------------+--------------------------------------+-------------+--------------------+-------------+
Enfin, nous pourrons nous connecter à la console d’administration de l’overcloud. L’URL est fournie en fin d’installation – en principe, il s’agit de la première IP disponible dans le VLAN External. Dans notre cas, http://10.42.46.10. Nom d’utilisateur : admin. Le mot de passe se trouve dans “/home/stack/overcloudrc“, variable “OS_PASSWORD“.
Depuis l’instance d’undercloud, nous pourrons nous connecter aux différents noeuds de l’overcloud :
$ openstack server list
+--------------------------------------+-------------------------+--------+------------------------+----------------+--------------+
| ID | Name | Status | Networks | Image | Flavor |
+--------------------------------------+-------------------------+--------+------------------------+----------------+--------------+
| 1f517053-986d-48a6-9a5f-fb5ea1d9b29e | overcloud-novacompute-0 | ACTIVE | ctlplane=10.42.242.213 | overcloud-full | testcompute |
| dd310ff3-b0c1-4154-b32d-1510ff26c8a3 | overcloud-controller-0 | ACTIVE | ctlplane=10.42.242.218 | overcloud-full | testcontrol |
| 6954fc84-175b-40fc-b312-35f60fc16b31 | overcloud-novacompute-2 | ACTIVE | ctlplane=10.42.242.216 | overcloud-full | testcompute |
| a93034b9-0449-40c5-8688-292ac682679d | overcloud-novacompute-1 | ACTIVE | ctlplane=10.42.242.217 | overcloud-full | testcompute |
| ee22ecf4-6dd7-47f7-a6fd-67ede8ec4e2e | overcloud-novacompute-3 | ACTIVE | ctlplane=10.42.242.215 | overcloud-full | testcompute |
+--------------------------------------+-------------------------+--------+------------------------+----------------+--------------+
$ ssh heat-admin@10.42.242.218
La clé SSH que nous avons généré sur l’undercloud lors de son déploiement a été intallée sur tous les noeuds d’overcloud. Nous pourrons nous y connecter, avec le compte utilisateur “heat-admin”.
Conclusion
Ce type de déploiement n’est que pour se familiariser avec le concept de déploiement d’OpenStack via TripleO, une fois ce déploiement réalisé, il est possible d’activer de nouvelles fonctionnalités ou de différencier de nouveaux rôles (Compute Hyperconvergeant, Compute avec Numa etc..)
