Playbook on Zwindler's Reflection

Déployer en 5 minutes un cluster Kubernetes sur ARM avec k3s et Ansible

Thu, 21 Mar 2019 13:00:14 +0000

C’est quoi k3s ?

Il y a quelques jours, vous avez peut être vu passer dans vos fil d’actus k3s, ce nouveau projet open sourcé par Rancher.

Lightweight Kubernetes. 5 less than k8s.

Il s’agit d’une version réduite de Kubernetes, sans pour autant être minimaliste, qui nous vante la possibilité de monter des clusters Kubernetes avec très peu de ressources nécessaires. On parle de moins de 512 Mo de RAM pour un master, encore moins pour un worker, tout dans un binaire de 40 Mo, support de armhf, et arm64, …

Great for Edge, IoT, CI, ARM, and situations where a PhD in k8s clusterology is infeasible

Cerise sur le gâteau, comme tout est regroupé dans un seul et même binaire, l’installation est ultra simple et se résume en :

Récupérer un binaire
Lancer le binaire sur le master
Lancer le binaire sur le worker avec l’URL du master et un token

Mais c’est génial !

Nécessairement, pour arriver à ça, il a fallut faire quelques concessions mais pour l’instant je ne les trouves pas très gênantes. Parmi les modifications notables, on retrouve :

Suppression des features alpha, legacy et non standard
Suppression de tous les add-on des cloud providers
Remplacement de etcd3 par sqlite3 (même si etcd3 peut être toujours être utilisé)

J’en veux un !

Autant dire que pas mal de bidouilleurs du dimanche se sont jetés dessus.

Le premier exemple qui vient à l’esprit est de monter un cluster Kubernetes sur Raspberry pi. Nombre de personnes ont déjà installé Docker sur un raspberry qui traînait dans un tiroir (moi compris), et le nombre d’articles avec Docker Swarm sur plusieurs Raspberry pullule sur le web.

Geekerie du week end : installer Docker sur un Raspberry Pi

Tout ça c’est très bien mais jusqu’à présent, il était difficile d’installer Kubernetes sur ce genre de machines, assez limités en CPU/RAM. Du coup, vous vous en doutez, je ne suis pas le premier à parler de ça.

Vincent RABAT aka itwars (que vous connaissez sûrement si vous écumez les meetups sur Bordeaux) m’a coiffé au poteau en releasant un playbook Ansible pour installer k3s, et notamment sur un Raspberry Pi (mais pas que).

A charge de revanche, Vincent ;-).

Un peu différent

Du coup, pour me démarquer, je vous propose aujourd’hui quelque chose d’un peu différent. N’ayant pas suffisament de raspberry sous la main, j’ai voulu faire un PoC de k3s en me basant sur des machines ARM créées chez un cloud provider.

L’idée étant que si ça marche sur des machines de faible puissance en ARM, ça marchera partout (x64, raspberry, etc).

Ça fait plusieurs fois que j’utilise Scaleway comme hébergeur pour des petits projets, et en particulier pour déployer rapidement des machines car leur API est pas trop mal fichues et surtout ils disposent de modules Ansible très bien fait, notamment avec la feature « inventaire dynamique », ce que beaucoup ne font pas.

Pour ceux que ça intéresse, mon talk sur BDX.IO était basé sur le même principe :

https://www.youtube.com/watch?v=WPRE1_f0pyg

Dans ce tuto, je vais donc vous montrer comment en quelque commande, monter un cluster k3s sur des machines ARM créées à la volée chez Scaleway, le tout avec Ansible (vous l’aurez compris).

Quelques prérequis

La première chose à faire est de cloner sur votre machine les playbooks Ansible que j’ai mis à disposition sur Github à l’adresse suivante : github.com/zwindler/ansible-scaleway-k3s

Pour réaliser ce tuto, je pars du principe que vous avec déjà un compte sur Scaleway, que vous avez un clé SSH qu’on déposera à la racine du projet, appelée admin.pub (c’est original).

Il faudra également installer les package pipy suivant sur la machine locale :

pip install jinja2 PyYAML paramiko cryptography packaging

Ensuite, vous devrez installer Ansible depuis les sources (>= 2.8devel) et éventuellement le binaire jq pour requêter dans les output JSON (ça c’est juste pour se faciliter la vie)

Dans la console Scaleway, vous devrez créer un token sur le site de Scaleway pour les accès distants et le stocker dans un fichier scaleway_token

export SCW_API_KEY='aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa'

Et enfin sourcer le fichier pour avoir la variable dans votre environnement

source scaleway_token

OK, on est prêt

La première étape de cette procédure va être de générer des instances ARM pour héberger le master et le worker Kubernetes. Pour ça, le playbook Ansible create_arm_vms.yaml va :

récupérer l’ID d’organisation du compte Scaleway
récupérer un ID d’image compatible debian Stretch
ajouter si nécessaire la clé SSH de l’admin
créer autant de machines que nécessaire

On lance la commande suivante :

ansible-playbook create_arm_vms_scaleway.yml

ET C’EST TOUT !

Normalement en 2 minutes, vous devriez avoir 2 instances ARM sur le datacenter de Paris (par1).

A noter, il se peut qu’elles ne soient pas accessibles tout de suite en SSH. J’adapterai peut être le playbook pour qu’il ne rende pas la main tant que les machines ne sont pas accessibles, et qu’on enchaîne automatiquement sur l’étape suivante (TODO).

Inventaire automatique

Je le disais plus haut, la grande force de Scaleway avec Ansible est le fait qu’ils ont fait l’effort de coder l’inventaire dynamique. Vous n’avez pas besoin de renseigner à la main les IPs des instances que vous venez de créer dans un fichier ansible/hosts. Grâce à l’API, la découverte se fait automatiquement. On va dont pouvoir enchaîner sur la suite directement.

De base, voici le contenu de mon fichier d’inventaire (inventory.yml) :

plugin: scaleway
regions:
- par1
tags:
- k3smaster
- k3sworker

Maintenant que les machines sont UP, on peut vérifier ce que nous renvoie Scaleway avec la commande ansible-inventory. Ça devrait ressembler à ça :

ansible-inventory --list -i inventory.yml
{
"_meta": {
"hostvars": {
"x.x.x.x": {
"arch": "arm64",
"commercial_type": "ARM64-2GB",
"hostname": "k3smaster1",
[...]
"k3sworker": {
"hosts": [
"x.x.x.x",
"y.y.y.y",
"z.z.z.z"
]
}

SSH fingerprints

Une étape qui est souvent fastidieuse, surtout quand on ajoute beaucoup de serveur, est l’étape de vérification de l’empreinte SSH des nouveaux serveurs lors de la première connexion. Cette authentification est très importante et il n’est pas du tout conseillé (comme je le vois parfois) d’ajouter l’option ANSIBLE_HOST_KEY_CHECKING=False.

Ici, je vous propose de scanner automatiquement la première fois l’empreinte, et l’ajouter dans votre known_hosts. Ainsi, si l’empreinte change en cours de route, vous serez prévenus. Cependant, ce n’est à utiliser que dans le cas de notre bidouille, pas en production.

ansible-inventory --list -i inventory.yml | jq -r '.k3smaster.hosts | .[]' | xargs ssh-keyscan >> ~/.ssh/known_hosts
ansible-inventory --list -i inventory.yml | jq -r '.k3sworker.hosts | .[]' | xargs ssh-keyscan >> ~/.ssh/known_hosts

Vous pouvez maintenant ajouter votre clé SSH dans le ssh-agent, et vérifier qu’on vous pouvez vous connecter à tous les serveurs via Ansible :

eval `ssh-agent`
ssh-add myprivate.key

Préparation du serveur

C’était facile, non ?

Et bien la suite l’est encore plus, à l’exception de cette petite subtilité/piège => Il se trouve que l’image ARM par défaut proposée par Scaleway ne dispose ni de python ni de sudo. Pour faire du Ansible, c’est très très handicapant.

J’ai donc écris un petit playbook, à n’exécuter la première fois, qui installe les prérequis non présents sur l’image de base (python et sudo)

ansible-playbook -i inventory.yml -u root install_prerequisites_scaleway.yml

Si vous n’êtes pas sur ce genre de machines, vous n’aurez pas à faire cette étapes.

Maintenant qu’on a des machines avec python et sudo, on peut installer k3s normalement avec Ansible :

ansible-playbook -i inventory.yml -u root install_k3s_scaleway.yml

Une fois de plus : ET C’EST TOUT !

Le cluster est maintenant opérationnel. Les serveurs ont Kubernetes installé et fonctionnel. Le ou les workers ont rejoint le master et font parti d’un même cluster. Un Ingress controller Treafik est créé, on peut jouer dessus directement :-)

Bonus : accéder au cluster

Bon je vous ai un peu feinté.

Certes, on peut se connecter en SSH sur le master et le piloter avec les commandes kubectl classique (mais il faut rajouter k3s devant car le binaire kubectl est intégré à k3s). Mais c’est quand même plus simple si on peut y accéder à distance, depuis votre machine locale.

Là encore, j’ai donc fais un petit playbook qui va aspirer la configuration kubectl et la coller dans le fichier ~/.kube/config.k3smaster

ansible-playbook -i inventory.yml -u root configure_kubeconfig.yml

A partir de là, vous devriez pouvoir tester votre nouveau cluster depuis votre PC :-)

cd
kubectl --kubeconfig=.kube/config.k3smaster get nodes
NAME STATUS ROLES AGE VERSION
k3smaster1 Ready <none> 2d v1.13.3-k3s.6
k3sworker1 Ready <none> 2d v1.13.3-k3s.6

Enjoy !!!

Installation xwiki 10.6.1 via un playbook Ansible

Wed, 05 Sep 2018 11:45:00 +0000

Ansible + XWiki

Je sais ce que vous vous dites :

Ça fait longtemps que zwindler n’a pas écrit un article sur Ansible ou XWiki !

Non ? Vous ne vous dites pas ça ? Bon tant pis c’est pas grave. Aujourd’hui, je rédige ENFIN l’article pour parler d’un playbook que j’ai déjà rédigé il y a presque un an déjà (et mis à jour et déployé de nombreuses fois). C’est dire si j’ai du retard dans les articles du blog…

Petit rappel des épisodes précédents

J’ai déjà rédigé de manière extensive sur XWiki qui est un belle solution open source de gestion de la connaissance. Parmi les articles les plus susceptibles d’intéresser, il y a déjà :

Il y en a plein d’autre (voir ici).

Et Ansible ?

Et bien oui. Je vous rabâche aussi les oreilles avec Ansible, l’Infrastructure as Code, et l’Idempotence. (Là encore, il y en a plein)

Alors pourquoi pas un playbook Ansible pour automatiser l’installation de XWiki, si vous n’avez pas de cluster Kubernetes sous la main et que vous êtes un Gaulois réfractaire à Docker ?

Ya quoi dans ton playbook ?

Trêve de suspense, les sources sont disponibles sur Github à cette adresse.

Ce playbook a été testé pour des RHEL/CentOS 7, en particulier de la version 7.2 jusqu’à 7.4. Une installation de RHEL/CentOS en mode minimale, même sans environnement graphique, devrait être suffisante. Je l’ai faite tourner en production sur des environnements Desktop dans des VMs, mais aussi en Minimal sur un container LXC dans Proxmox VE sans aucun souci.

L’installation n’utilise pas les serveurs web et de bases de données par « défaut » (MySQL), mais Tomcat 8 et PostgreSQL. Pour la version de Tomcat, c’est une version très particulière qu’il faut utiliser car des bugs ont étés introduits dans une version, puis RE-introduits quelques mois plus tard. Vous pouvez modifier la version par défaut qui est une variables de mon playbook (8.5.32) si elle ne vous convient pas. Les instructions d’installation se basent sur la documentation officielle.

- tomcat_version: 8.5.32

Vous pouvez également modifier la version de XWiki directement dans le playbook (c’est une variable là aussi) :

- xwiki_version: "10.6.1"

A noter, les vielles versions de XWiki n’étaient pas hébergées sur le même dépôt, qui a changé récemment, d’où les deux URLs dans le playbook.

Prérequis

On va utiliser git pour récupérer le playbook et ansible (version de l’OS, rien d’exotique).

yum install ansible git
git clone https://github.com/zwindler/ansible-deploy-xwiki-tomcat-postgresql
cd ansible-deploy-xwiki-tomcat-postgresql

Quand est ce qu’on installe XWiki ?

Maintenant !

Sur un poste qui dispose de git et Ansible :

ansible-playbook -l localhost ansible-deploy-xwiki-tomcat-postgresql.yml

Le playbook devrait vous prompter pour un mot de passe pour l’utilisateur de base de données PostgreSQL, n’hésitez pas à mettre quelque chose de complexe. Vous ne devriez pas en avoir besoin.

Si vous avez une erreur qui vous dit que localhost est ignoré, vous pouvez l’ajouter à votre fichier d’inventaire global : /etc/ansible/hosts

sudo vim /etc/ansible/hosts
[local]
localhost ansible_connection=local

Et Paf ! Vous avez un XWiki installé, disponible à l’adresse http://@IP:8080/. Il n’y a plus qu’à le configurer :)

Votre première VM dans Azure… déployée avec Ansible bien sûr !

Tue, 07 Aug 2018 11:45:22 +0000

Mais tu n’as pas déjà fais un article sur Ansible et des VMs ?

Si vous me suivez depuis quelques temps, vous savez que j’apprécie particulièrement Ansible. J’ai déjà écris plusieurs articles sur le sujet, ainsi que de nombreux playbooks que j’ai mis à votre disposition sur mon compte github.

Un des articles qui intéresse le plus les lecteurs du blogs est un article en deux parties (part1 part2) qui détaille comment déployer des machines virtuelles sur une architecture VMware vSphere avec Ansible. J’en ai d’ailleurs fait une version en anglais également qui attire pas mal de monde aussi ;-).

Du coup, maintenant que je me suis attaqué aux principaux clouds providers (AWS, GCP et Azure), il était grand temps de faire un article sur cette partie également !

Comme d’autres outils d’automatisation, Ansible fait la part belle aux intégrations cloud. Je vous laisse jeter un oeil à la liste des modules Ansible disponibles pour le cloud :

docs.ansible.com/ansible/2.9/modules/list_of_cloud_modules.html

Et c’est particulièrement vrai pour Azure, dont l’équipe dédiée chez Microsoft est assez réactive et ajoute des features de manière très régulière (on aura l’occasion d’y revenir dans un prochain article, #teasing).

Les prérequis

Finalement, déployer un VM dans Azure, c’est presque pareil que comme déployer une VM dans VMware. On a des prérequis, une liste de paramètres à renseigner et pouf, on va poper une VM.

Bon, en vrai, ce n’est pas aussi trivial : si pour VMware, on se contentait d’une API python relativement simple à installer avec pip et d’un mot de passe, sur Azure, il va falloir trimer un poil plus.

Deux ressources nous donnent la marche à suivre pour configurer notre poste :

Installer

Sur une machine mint/debian/ubuntu, récupérer les modules python nécessaires :

apt install python-pip ansible
pip install setuptools wheel
pip install ansible[azure]

Configurer

Pour déployer des VMs sur Azure, il faut… un compte sur Azure !

Thanks, captain obvious.

Bon, si jamais vous voulez essayer, sachez que vous pouvez vous créer un compte gratuit avec 200$ de crédit offert, mais seulement valable 30 jours. C’est hyper radin de leur part, là où un GCP offre 300$ pendant 1 an, ce qui offre largement plus de temps pour tester.

Pour ouvrir le compte, il faut simplement aller à cette URL et renseigner une carte bancaire. Oui je sais, j’ai flippé moi aussi.

Normalement, ils ne vous prélèveront pas sans vous prévenir, c’est simplement pour éviter les bots. Personnellement je n’ai pas eu de problèmes mais je ne peux rien garantir (même si je pense que ça se saurait s’il y avait eu des soucis de ce côté là).

Une fois le compte créé, on va générer les fichiers de configuration pour Azure. Le plus simple pour le faire, c’est d’utiliser la commande « az login » (mais du coup il faut installer az cli en plus).

az login
To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code CCHMTROLL to authenticate.

Vous devriez avoir un dossier .azure dans votre homedir

ll .azure
total 8
drwxrwxrwx 1 zwindler zwindler 512 Aug 4 17:00 ./
drwxr-xr-x 1 zwindler zwindler 512 Aug 4 16:56 ../
-rw------- 1 zwindler zwindler 7124 Aug 4 17:00 accessTokens.json
-rw-rw-rw- 1 zwindler zwindler 5 Aug 4 16:56 az.json
-rw-rw-rw- 1 zwindler zwindler 5 Aug 4 16:56 az.sess
-rw-rw-rw- 1 zwindler zwindler 333 Aug 4 17:00 azureProfile.json
-rw-rw-rw- 1 zwindler zwindler 66 Aug 4 17:00 clouds.config
-rw------- 1 zwindler zwindler 27 Aug 4 16:56 config

Et donc, on la déploie sur Azure, cette VM ?

Maintenant que notre poste est configuré, ça redeviens simple. Ouf !

Le module à invoquer dans notre playbook est azure_rm_virtualmachine, dont la documentation est disponible à l’adresse suivante :

https://docs.ansible.com/ansible/latest/modules/azure_rm_virtualmachine_module.html#azure-rm-virtualmachine-module

Voici un des exemples donnés dans la documentation du module :

- name: Create a VM with managed disk
azure_rm_virtualmachine:
resource_group: Testing
name: testvm001
vm_size: Standard_D4
managed_disk_type: Standard_LRS
admin_username: adminUser
ssh_public_keys:
- path: /home/adminUser/.ssh/authorized_keys
key_data: < insert your ssh public key here... >
image:
offer: CoreOS
publisher: CoreOS
sku: Stable
version: latest

La plupart des options que je vous met plus haut sont obligatoires. Il y en a beaucoup d’autre, mais celles ci sont un minimum. Pour expliquer un peu de quoi il s’agit, voici une petite traduction :

resource_group
Sur Azure, il existe plusieurs entités logiques permettant de segmenter les ressources entre elles. La souscription (plus haut niveau de segmentation, utile au niveau billing) et les resources groups. On peut donc avoir plusieurs resource groups dans une souscription.

name
Le nom de la ressource, telle qu’elle apparaîtra dans votre portail Azure. Pas plus important que ça.

vm_size
Là on rentre dans le vif du sujet ; il s’agit de la taille de la VM (en terme de nombre de CPU et de Go de RAM) que va avoir votre VM. Un guide des tailles (sans le billing) est disponible à l’adresse suivante

managed_disk_type

Pour faire simple, est ce que votre disque sera sur des baies SSD ou sur des baies mixant SSD et HDD classiques. On a assez peu d’information sur la façon dont sont stockées les données, au delà d’un nombre d’IOPS qui sera d’autant plus important que vous aurez réservé d’espace disque. Par exemple, un disque Premium de 128 Go, on aura droit à 500 IOPS et 100Mo/s max. Si vous passez au delà (de 129 à 256), vous aurez droit à 1100 IOPS et 125 Mo/s.

Quelques infos quand même :

Je vois vos petits yeux pétiller de malice.

Vous vous dites « ahah, je vais les feinter, me payer un disque de 129 Go pour avoir les perfs d’un disque de 256 pour à peine plus qu’un disque de 128 Go ».

Et bien non, ils ne sont pas fous, vous payerez pour un disque de 256 même si vous ne demandez que 129 (et même si vous n’utilisez 1 Go dedans).

admin_username & ssh_public_keys

Je ne vais pas vous faire l’affront de détailler ça. Il faut rentrer un utilisateur, un path pour la clé SSH et le contenu de votre clé publique.

image

Sur azure, vous avez accès à un magasin pré configuré d’images de VMs.

Si on veut un Ubuntu 16.04, on mettra :

image:
offer: UbuntuServer
publisher: Canonical
sku: '16.04.0-LTS'
version: latest

Pour un CentOS 7.4 :

image:
offer: CentOS
publisher: OpenLogic
sku: '7.4'
version: latest

Toujours plus

Alors OK, avoir un bout de doc qui explique comment déployer une VM sur Azure, c’est chouette. Mais est ce qu’on pourrait pas faire mieux ?

Et oui, bien sûr ! Car en fait, dans Azure, on ne va pas simplement pouvoir déployer notre VM comme ça et espérer que ça marche.

Je l’ai déjà dis, il existe des ressources groups, dans lequel toutes vos ressources doivent être. On va devoir le créer. Mais il va aussi nous falloir une carte réseau, qui aura une adresse IP qui elle même proviendra d’un réseau virtuel, qui auront leur propres règles de sécurité (genre de firewalling basique). Et bien sûr, tout ça, c’est des objets à créer (à la main :-( … ou pas) !

Mais comme je suis sympa, je vais vous donner un playbook clé en main qui fait tout ça pour vous ;)

---
- name: "Create Azure resources"
connection: local
hosts: all
vars_prompt:
- name: "location"
prompt: "Choose region to deploy VMs"
private: no
default: "westeurope"
- name: "project_prefix"
prompt: "Choose a prefix for all the resources"
private: no
default: "test"
- name: "instances_number"
prompt: "Choose a number of virtual machines to create"
private: no
default: 1
- name: "vm_size"
prompt: "Choose a size for azure virtual machines"
private: no
default: "Standard_B2s"
- name: "managed_disk_type"
prompt: "Choose a type for azure virtual disks"
private: no
default: "Standard_LRS"
- name: "admin_username"
prompt: "Choose an admin username"
private: no
default: "zwindler"
- name: "admin_pub_path"
prompt: "Where can I find the admin public key ?"
private: no
default: "~/.ssh/id_rsa.pub"
- name: "local_ip"
prompt: "your local IP address (skip if you don't want to add 22 port to NSG)"
private: no
default: "skip"
- name: "virtualnetwork_cidr"
prompt: "Give a network CIDR for virtual network (large)"
private: no
default: "172.16.0.0/18"
- name: "subnet_cidr"
prompt: "Give a subnet of that network"
private: no
default: "172.16.1.0/24"
vars:
- resourcegroup_name: "{{project_prefix}}-rg"
- availabilityset_name: "{{project_prefix}}-avset"
- virtualnetwork_name: "{{project_prefix}}-vnet"
- subnet_name: "{{project_prefix}}-subnet"
- securitygroup_name: "{{project_prefix}}-nsg"
- vm_root_name: "{{project_prefix}}-vm"
- public_ip_name: "{{project_prefix}}-ip"
- nic_root_name: "{{project_prefix}}-nic"
tasks:
- name: "Create {{project_prefix}}-rg Resource Group"
azure_rm_resourcegroup:
name: "{{resourcegroup_name}}"
location: "{{location}}"
- name: "Create {{availabilityset_name}} Availability Set"
azure_rm_availabilityset:
name: "{{availabilityset_name}}"
location: "{{location}}"
resource_group: "{{resourcegroup_name}}"
sku: Aligned
- name: "Create {{virtualnetwork_name}} Virtual Network"
azure_rm_virtualnetwork:
name: "{{virtualnetwork_name}}"
resource_group: "{{resourcegroup_name}}"
address_prefixes_cidr:
- "{{virtualnetwork_cidr}}"
- name: "create {{subnet_name}} Subnet in {{virtualnetwork_name}} for VMs"
azure_rm_subnet:
name: "{{subnet_name}}"
virtual_network_name: "{{virtualnetwork_name}}"
resource_group: "{{resourcegroup_name}}"
address_prefix_cidr: "{{subnet_cidr}}"
register: subnet
- name: "Create {{securitygroup_name}} security rules (if local IP address was given)"
azure_rm_securitygroup:
name: "{{securitygroup_name}}"
resource_group: "{{resourcegroup_name}}"
purge_rules: yes
rules:
- name: 'AllowSSHFromYourOwnInternetIP'
protocol: 'Tcp'
source_address_prefix: "{{local_ip}}"
destination_port_range: 22
access: Allow
priority: 1000
direction: Inbound
when: local_ip | ipaddr
- name: "Create a {{nic_root_name}}X network interface for each VM"
azure_rm_networkinterface:
name: "{{nic_root_name}}{{item}}"
resource_group: "{{resourcegroup_name}}"
virtual_network: "{{virtualnetwork_name}}"
subnet_name: "{{subnet_name}}"
security_group: "{{securitygroup_name}}"
ip_configurations:
- name: "ipconfig"
public_ip_address_name: "{{public_ip_name}}"
primary: True
with_sequence: count="{{instances_number}}"
- name: "Create {{vm_root_name}}X VM with existing NIC"
azure_rm_virtualmachine:
resource_group: "{{resourcegroup_name}}"
name: "{{vm_root_name}}{{item}}"
vm_size: "{{vm_size}}"
managed_disk_type: "{{managed_disk_type}}"
admin_username: "{{admin_username}}"
availability_set: "{{availabilityset_name}}"
ssh_password_enabled: false
ssh_public_keys:
- path: "/home/{{admin_username}}/.ssh/authorized_keys"
key_data: "{{lookup('file', '{{admin_pub_path}}') }}"
network_interface_names: "{{nic_root_name}}{{item}}"
image:
offer: UbuntuServer
publisher: Canonical
sku: '16.04.0-LTS'
version: latest
with_sequence: count="{{instances_number}}"

Pour ceux qui veulent d’économiser un copier coller, j’ai mis à disposition ce playbook à l’adresse suivante :

github.com/zwindler/ansible-deploy-azure

Et il ne reste plus qu’à l’exécuter :

pip install --user netaddr
echo localhost > hosts
ansible-playbook -i hosts azure-deploy.yml
[...]
TASK [Create test-vmX VM with existing NIC] *****************************************
changed: [localhost] => (item=1)
PLAY RECAP **************************************************************************
localhost : ok=1 changed=7 unreachable=0 failed=0

Le mot de la fin

Bon, on en est où maintenant ?

Et bien maintenant, vous avez un playbook qui vous permet de déployer des VMs à tour de bras dans Azure certes, mais aussi de les préconfigurer avec votre clé SSH et votre utilisateur administrateur, et seul votre IP (ou celle que vous aurez donné ou un subnet) pourra y accéder en SSH.
Vous avez toutes vos VMs dans un même sous réseau, lui même dans un réseau virtuel.
Vous avez également un AVSET qui vous permet de ne pas avoir toutes vos VMs sur les mêmes hyperviseurs et augmenter la disponibilité de votre application.
Et tout ça, sans rien avoir eu à faire à la main.

Badass non ?

Et encore! J’en ai gardé un peu sous le coude, pour d’autres articles ;-)