Nous allons utiliser le cloud public Amazon Web Services (AWS) pour déployer une petite infrastructure virtuelle nous permettant de tester OpenStack. Vous devez disposer d’un compte AWS et cela vous coûtera moins d’un dollar (l’unique VM que nous allons déployer coûte ~0.2 USD de l’heure dans la région Paris).
À noter que vous pouvez également faire cela sur d’autres Cloud providers, ou même sur une machine virtuelle en local sur votre ordinateur avec Vagrant par exemple (prévoyez au minimum 4 vCPUs et 16 GB de RAM).
Nous allons utiliser Terraform, un outil d’Infrastructure as Code, qui permet de définir son infrastructure sous forme de code et de faire les appels API au cloud provider à votre place pour la déployer.
Vous devez d’abord installer Terraform et configurer une clé d’API AWS pour votre compte.
Pour déployer cette infrastructure, il vous suffit de cloner le dépôt Git associé à cet article et de lancer le déploiement avec Terraform.
Les commandes à exécuter pour effectuer le déploiement sont décrites dans le README du dépôt.
Le déploiement devrait prendre quelques minutes. Une fois celui-ci terminé, notez l’adresse IP affichée dans le tableau openstack_public_ips à la fin de la commande terraform apply : il s’agit de l’adresse IP publique de votre VM.
Connectez-vous à votre machine virtuelle nouvellement créée en SSH :
ssh -i <PRIVATE_KEY_PATH> ubuntu@<PUBLIC_IP>Félicitations, vous êtes désormais connecté à votre machine ! Nous allons maintenant procéder au déploiement d’OpenStack à l’aide de DevStack.
⚠️ À la fin de l’article, une fois votre évaluation d’OpenStack terminée, n’oubliez pas de détruire l’infrastructure déployée sur AWS, sinon elle continuera de vous être facturée ! 💸 Pour cela exécutez la commande terraform destroy et confirmez avec yes.
À partir de maintenant, vous devez exécuter toutes les commandes sur la machine distante. Nous allons exécuter DevStack, le script qui va déployer OpenStack sur la machine.
L’installation devrait prendre une vingtaine de minutes, soyez patients !
# On clone le repo officiel de DevStack
git clone https://opendev.org/openstack/devstack
cd devstack
# On crée un fichier de configuration basique pour DevStack
cat <<EOF > local.conf
[[local|localrc]]
ADMIN_PASSWORD=password
DATABASE_PASSWORD=password
RABBIT_PASSWORD=password
SERVICE_PASSWORD=password
enable_service s-proxy s-object s-container s-account s3api
SWIFT_HASH=66a3d6b56c1f479c8b4e70ab5c2000f5
EOF
# On lance le script d'installation.
# À présent, vous devez patienter une vingtaine de minutes...
./stack.shOpenStack est désormais installé sur votre machine virtuelle ! Pour confirmer votre installation vous pouvez tester rapidement une commande avec la CLI openstack :
# Chargez dans votre environnement les credentials de votre OpenStack
source openrc
# Cette commande liste les images d'OS installées sur votre OpenStack,
# vous devriez en voir une : CirrOS.
openstack image listSi tout fonctionne, félicitations ! Vous disposez de votre propre cloud privé open source avec OpenStack !
Nous pouvons désormais utiliser les fonctionnalités basiques d’IaaS (Infrastructure as a Service) d’OpenStack. En l’occurrence nous allons créer une machine virtuelle tournant sur Ubuntu 22.04 LTS, ce qui est un cas fréquent d’utilisation de votre Cloud privé.
C’est d’ailleurs ce que vous avez fait pour créer votre première VM sur un Cloud public plus tôt dans cet article.
Les commandes suivantes s’exécutent toujours sur votre machine virtuelle. Nous allons d’abord télécharger une image d’Ubuntu 22.04 spécifiquement conçue pour un contexte Cloud-native. D’autres distributions Linux sont également disponibles pour OpenStack.
# Chargez dans votre environnement les credentials de votre OpenStack
source openrc
# Cette commande liste les images d'OS installées sur votre OpenStack,
# vous devriez en voir une : CirrOS.
openstack image listLa prochaine étape consiste à configurer le réseau virtuel déjà créé dans OpenStack pour que notre image Ubuntu fonctionne correctement :
# Nous ajoutons des serveurs DNS publics (ici Cloudflare) au réseau déjà créé
# dans OpenStack
openstack subnet set --dns-nameserver 1.1.1.1 --dns-nameserver 1.0.0.1 private-subnetLe concept de groupe de sécurité sur OpenStack est identique à celui que vous pouvez trouver sur AWS et d’autres cloud providers. Il s’agit d’un firewall virtuel qui est attaché à une ou plusieurs VM.
Nous allons rajouter au groupe de sécurité par défaut des règles pour autoriser les connexions SSH et ICMP (ping) entrantes :
# Nous ouvrons le port 22 (SSH) et autorisons les ping (ICMP)
openstack security group rule create --proto icmp --dst-port 0 default
openstack security group rule create --proto tcp --dst-port 22 defaultEnfin la dernière étape avant de créer notre première VM est d’ajouter une clé SSH pour pouvoir s’y connecter. Nous générons ici une nouvelle clé SSH (toujours sur notre VM AWS OpenStack) et nous la chargeons sur OpenStack :
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519 -N ""
openstack keypair create --public-key ~/.ssh/id_ed25519.pub my_key_pair
Maintenant, toutes les conditions sont réunies pour que nous puissions créer notre première VM et s’y connecter en SSH ! Voici la commande pour créer la VM :
openstack server create \
--flavor=m1.medium \
--image=ubuntu22 \
--key-name=my_key_pair \
--network=private \
--security-group=default \
my_first_vmLe paramètre --flavor spécifie le gabarit de la VM que nous créons (son nombre de VCPUs, sa mémoire RAM et la taille de son disque racine). Ici le gabarit m1.medium (déjà présent par défaut sur OpenStack) correspond à 2 VCPUs, 4096 MB de RAM et 40 GB de stockage !
Il nous reste maintenant à nous connecter à notre machine, et pour cela il faut lui allouer une adresse IP flottante. Elle fait partie d’un réseau connecté vers l’extérieur d’OpenStack !
Le réseau private dans lequel est connecté notre VM n’est qu’interne à OpenStack, il n’est pas accessible depuis l’extérieur, ni même depuis la machine sur laquelle est installée votre cloud privé.
En créant une adresse IP flottante et en l’associant à notre machine, nous lui permettons d’avoir également une adresse IP qui est dans un réseau accessible depuis l’extérieur d’OpenStack (DevStack a créé ce réseau pour nous et a déjà branché notre machine AWS dessus, grâce à une gateway).
Voici un petit schéma pour y voir plus clair (tout se passe à l’intérieur de la VM sur AWS) :
# Notez l'output de cette commande !
openstack floating ip create -f value -c name public
# Utilisez l'IP sortie affichée par la commande précédente
openstack server add floating ip my_first_vm <FLOATING_IP> # ex: 172.16.213.57Il peut être nécessaire de patienter un peu jusqu’à la création de la VM, la virtualisation imbriquée (notre VM OpenStack tourne dans notre VM AWS) peut être lente ! Vous saurez quand votre VM est prête quand un ping ou une connexion SSH réussira :
# Testez la connectivité
ping <FLOATING_IP> # ex: ping 172.16.213.57
ssh ubuntu@<FLOATING_IP> # ex: ssh ubuntu@172.16.213.57Une fois connecté à la machine en SSH, vous pouvez exécuter n’importe quelle commande que vous désirez dans votre VM OpenStack ! Vous pouvez constater par exemple que la virtualisation fonctionne bien, le kernel de cette VM est différent du kernel de votre VM “mère” sur AWS.
# Exécutez n'importe quelle commande dans cette VM
uname -a # Le kernel est différent de celui de la VM AWS
# ex: Linux my-first-vm 5.15.0-67-genericVous pouvez maintenant profiter de votre VM OpenStack, mais vous remarquerez sûrement rapidement quelques limites, la virtualisation imbriquée a un coût !
OpenStack dispose d’Horizon, sa propre interface web qui permet de visualiser, créer, supprimer ou modifier des ressources tout comme vous pourriez le faire sur les cloud providers publics avec leurs consoles web respectives.
Pour y accéder depuis un navigateur Web, vous devez d’abord faire un tunnel SSH entre votre ordinateur et votre machine virtuelle AWS. Un tunnel SSH permet d’accéder au réseau de la machine cible depuis sa machine locale, en liant un port de sa machine à un port d’une autre machine sur ce réseau, le tout en passant seulement par la connexion SSH entre vous et votre machine distante !
Nous créons donc un tunnel SSH qui permet de lier notre port 8080 au port 80 (là où est accessible l’interface web d’OpenStack) de l’IP 172.16.10.10 (l’IP par défaut si vous avez déployé cette infrastructure avec Terraform sur AWS). Le résultat est simple : si vous allez sur http://localhost:8080/dashboard sur votre machine, vous accédez à Horizon, l’interface d’OpenStack.
# Tunnel SSH
ssh -N -L 8080:172.16.10.10:80 ubuntu@<AWS_INSTANCE_PUBLIC_IP>Sur l’interface vous pouvez vous connecter avec le login demo et le mot de passe password. Sélectionnez le projet demo dans le coin supérieur gauche, et vous voilà sur l’interface d’OpenStack ! Vous pouvez observer votre machine virtuelle créée plus tôt, n’hésitez pas à faire un tour dans l’interface !
Dans les sections précédentes, nous avons créé des ressources sur OpenStack à l’aide de son outil en ligne de commande openstack. Cette méthode est la même que si vous utilisiez la CLI aws sur AWS ou la CLI gcloud sur GCP.
Mais tout comme sur ces cloud providers publics, vous pouvez également utiliser des outils d’Infrastructure as Code comme Terraform sur votre cloud privé ! OpenStack dispose d’un provider Terraform maintenu par la communauté pour déployer la plupart de ses ressources, n’hésitez pas à y jeter un œil !
Si vous voulez supprimer les ressources que vous avez créées sur OpenStack, voici les commandes à exécuter :
# Nettoyage
openstack server delete my_first_vm
openstack floating ip delete <FLOATING_IP>
openstack keypair delete my_key_pair
Je vous propose de tester quelques autres services d’OpenStack qui vont plus loin que la simple création de machine virtuelle : le stockage objet avec Swift, et le stockage bloc avec Cinder ! Ce sont des briques de base que l’on trouve sur les cloud providers publics, il est normal de les retrouver sur un cloud privé !
Swift est un projet OpenStack visant à fournir un système de stockage objet distribué et hautement disponible. Il est en ce sens similaire à des solutions comme Amazon S3, Google Cloud Storage ou Azure Blog Storage. Avec Swift, vous pouvez créer des conteneurs, dans lesquels vous pouvez stocker autant d’objets (fichiers) que vous le désirez.
Voici quelques commandes que vous pouvez utiliser pour tester la solution Swift :
# Création d'un conteneur (aussi appelé Bucket)
openstack container create my-bucket
# Création d'un objet (fichier) et upload
echo "Hello world" > my-object.txt
openstack object create my-bucket my-object.txt
# En listant les objets vous devriez voir celui créé à l'instant !
openstack object list my-bucket
# Supprimez-le de votre machine en local
rm my-object.txt
# Vous pouvez à nouveau le télécharger depuis votre conteneur Swift
openstack object save my-bucket my-object.txt
cat my-object.txt
#Hello worldUne des forces de Swift est de proposer une API compatible avec Amazon S3 ! Vous pouvez donc vous appuyez sur les nombreux SDKs disponibles dans la nature ainsi que la CLI officielle d’AWS, en voici un exemple :
# Installation de la CLI AWS
sudo apt-get install -y awscli
# Nous devons créer une paire de clé sur OpenStack compatible avec l'API AWS
# Notez bien les valeurs 'access' et 'secret'
openstack ec2 credentials create
# Chargez les clés OpenStack dans l'environnement
export AWS_ACCESS_KEY_ID=XXXXXXXXXXXX # mettez la valeur 'access'
export AWS_SECRET_ACCESS_KEY=XXXXXXXXXXXX # mettez la valeur 'secret'
# Vous pouvez désormais utiliser la CLI AWS
# Lister les buckets (conteneurs Swift)
aws --endpoint-url=http://172.16.10.10:8080 s3 ls
# Lister les objets dans votre bucket
aws --endpoint-url=http://172.16.10.10:8080 s3 ls s3://my-bucketSi vous voulez ne pas préciser le paramètre --endpoint-url dans les commandes aws , vous pouvez installer un plugin permettant de l’ajouter à votre configuration globale.
Cinder est un service de stockage de blocs pour les instances de machines virtuelles sur OpenStack. Avec Cinder, vous pouvez créer des volumes, des disques durs virtuels qui peuvent être attachés et détachés de vos instances de machines virtuelles.
Vous pouvez utiliser les volumes comme vous utiliseriez un disque dur sur une machine : le formatter, le partitioner, le monter… Chez AWS le service similaire est Amazon EBS.
Voici quelques commandes que vous pouvez utiliser pour tester Cinder :
# Création d'un volume de 20 Go
openstack volume create --size=20 -f value -c id
# Notez l'ID affiché en sortie de cette commande !
# En coulisse, ce n'est qu'un volume LVM...
sudo lvs
# ... mais en production Cinder utilise idéalement un système distribué comme Ceph ou des disques durs dédiés
# Vous pouvez attacher (brancher) un volume à une VM comme ceci
openstack server add volume my_first_vm <VOLUME_UUID>
# if you run `sudo fdisk -l` in your VM it should appear, you can format it and use it as you want
# Si vous exécutez `sudo fdisk -l` dans la VM à laquelle vous avez attaché
# le volume, il devrait apparaître. Vous pouvez le formatter, le monter, etc.
# Vous pouvez faire des snapshots (quand le volume n'est pas attaché)
openstack server remove volume my_first_vm <VOLUME_UUID>
openstack volume snapshot create --volume <VOLUME_UUID> snapshot-1
# Enfin vous pouvez supprimer votre volume et/ou ses snapshots
openstack volume snapshot delete snapshot-1
openstack volume delete <VOLUME_UUID>
OpenStack propose de nombreux autres services, et son architecture très modulaire vous permet d’installer uniquement ceux qui répondent à vos besoins. Ils sont tous listés dans la documentation d’OpenStack, mais je vous propose de passer sur ceux qui répondent à la grande majorité des besoins.
Au cours de cet article nous avons déployé OpenStack avec DevStack sur une machine virtuelle AWS. Cette configuration est essentiellement destinée à évaluer les fonctionnalités de la solution et est peu coûteuse.
Cependant, pour de la production, il est préférable d’avoir de la redondance et plus de ressources pour notre cloud privé OpenStack. Se servir d’AWS pour déployer son OpenStack n’est pas une solution viable et performante. À grande échelle cela devient coûteux, et surtout, AWS est déjà un cloud provider très complet. Déployer OpenStack par-dessus n’offre donc aucun intérêt.
Pour déployer OpenStack en production, on privilégie donc une infrastructure bare metal, chez soi ou chez un hébergeur. On utilise également des outils plus robustes comme Kolla Ansible (déploiement des composants OpenStack dans des conteneurs Docker, à l’aide d’Ansible) ou OpenStack Charms (déploiement sur des conteneurs LXD, un peu moins automatisé). Quoi qu’il en soit, pour un déploiement en production DevStack n’est pas la solution.
Mais déployer en production avec ces outils requiert une équipe technique compétente et une infrastructure importante. La configuration par défaut de Kolla Ansible n’est pas tout à fait prête pour de la production.
Il faut donc l’adapter car on veut pouvoir : relier notre installation OpenStack à des plages d’adresses IP publiques, mettre en place du SSO pour la gestion des utilisateurs, exposer de manière sécurisée les différents services, activer des modules supplémentaires d’OpenStack (comme Swift, Octavia ou Cinder)…
Pour conclure, OpenStack propose plusieurs avantages :
Cependant OpenStack n’est pas exempt de défauts, certaines limites sont à prendre en compte lorsque l’on réfléchit à déployer OpenStack pour son organisation :
Les services managés sur OpenStack sont peu développés (le IaaS basique reste le cœur d'OpenStack) et il n’existe pas de solution native pour faire du serverless (il existe cependant des solutions qui s’intègrent à OpenStack via Kubernetes, comme OpenWhisk)
La maintenance en production d’une installation OpenStack demande une équipe compétente, réactive aux incidents et nécessite de se tenir au rythme des mises à jour majeures tous les 6 mois.
Et peut-être un des points les plus rédhibitoires : en fonction des composants OpenStack, la quantité et la qualité de la documentation peuvent être très variables, ce qui rend également difficilement accessible l’acquisition de compétences autour d’OpenStack
Dans cet article, nous avons déployé ensemble une installation d’OpenStack avec DevStack, votre propre cloud privé ! N’oubliez pas de détruire l’infrastructure déployée avec terraform destroy (voir partie 1).
Nous n’avons fait qu’effleurer la surface de ce qu’il est possible de faire avec OpenStack. J’espère que cet article vous aura donné le goût d’aller voir plus loin et d’envisager de déployer OpenStack pour votre organisation ou pour votre usage personnel ! N’hésitez pas à nous partager vos découvertes ou poser vos questions sur Twitter ou LinkedIn !