Ansible on Zwindler's Reflection

Rudder - astuces en vrac

Thu, 20 Apr 2023 18:00:00 +0200

Cet article fait partie d’une suite d’articles sur Rudder. La version qui est testée ici sera la version open source (car je n’ai pas les moyens de me payer une licence pour mon infra perso 😛) :

Note : une fois de plus, je tiens à préciser qu’il ne s’agit PAS d’un article sponsorisé. J’ai eu des contacts (techniques) avec la team Rudder, mais je n’ai été influencé d’aucune manière, en particulier dans la rédaction de cet article.

But de l’article

Dans les deux articles précédents, j’ai parlé des concepts de Rudder, de l’installation du serveur et des agents. Je suis allé un poil plus loin avec mon installation perso mais avec ce que j’ai déjà écrit, on est déjà en capacité de jouer avec Rudder et je pense pas qu’on ait besoin d’aller beaucoup plus loin.

Cependant, au cours de mes péripéties avec Rudder, je suis tombé sur quelques petits “os”. Rien de bien poussé, qui ne justifierait un article seul. Je vais donc tout regrouper ici, en vrac ;-P.

Tuning pour les petits CPUs et les petites RAMs

On l’a dit dans le premier article, Rudder est assez doux en termes de prérequis matériels. Quelques Mo de mémoire suffisent pour l’agent, et grosso modo pas besoin de machine de guerre pour le CPU.

Cependant, comme je suis extrêmement économe (aka radin) dans la gestion de mon infra perso, je suis quasiment un anti pattern dans le cas de Rudder. J’ai un cluster Proxmox monté sur des machines louées à 6€/mois à base d’un antédiluvien Atom C2350 (des duals core de 2013 !).

C’est d’ailleurs pour essayer de grappiller quelques % de CPU que j’avais publié les articles Optimisation de PFsense dans Proxmox VE et Proxmox - Tips and tricks.

Ces machines ne supportant même pas les instructions VT-x, je ne fais donc pas de machines virtuelles mais uniquement des machines à bases de containers LXC. Je me retrouve donc à installer une dizaine d’agents (oui, je suis vraiment bourrin) sur un même Atom.

Rudder a beau être économe, multiplier les agents sur une machine aussi faible avait un coût difficilement soutenable sur ma machine, comme en témoigne le graphique CPU ci-dessous (mon serveur ne fait quasiment rien, c’est donc quasiment exclusivement de la charge Rudder).

Il est très peu probable que vous ayez vous une charge perceptible sur vos infras. Dans le cas de machines aussi peu puissantes, il est probable que la team Rudder recommanderait de ne pas installer d’agent sur mes containers LXC. Mais dans le cas de machines très très peu puissantes et/ou très très densifiées en termes de nombre de VMs, sachez qu’il est quand même possible de tuner le scheduling des runs de Rudder et ainsi limiter la casse.

Dans le menu Administration / Settings, il existe une section Agent run schedule. Par défaut, l’ordonnancement est prévu de la façon suivante : Rudder lance les vérifications / corrections sur sa liste d’agent sur une plage de 5 minutes, le premier tiré au hasard commençant à 0 minutes (directement donc) et le dernier jusqu’à 4 minutes (1 minute avant la fin de la fenêtre de tir).

Note : au-delà de mon cas particulier, c’est quand même intéressant à savoir, car en fonction de ce qu’on lancera (scripts très longs par exemple, upgrades apt, …), il peut être intéressant de tuner ce dernier paramètre (Maximum delay) pour être certain que 2 jobs ne se chevauchent pas.

En modifiant le scheduling pour que les runs se lancent non pas sur 5 minutes mais sur 30, avec un dernier lancement à la 29 ème minute, j’ai pu retrouver une charge relativement acceptable sur mon infra.

Deuxième astuce, si vous êtes limité en RAM, que vous avez moins de 50 machines et que vous n’utilisez pas beaucoup les plugins, il est possible de diminuer la taille de la JVM de rudder (par défaut à 1 Go) et ainsi un peu mieux respirer sur une machine à 2 Go (prérequis Rudder, un peu justes).

sed -i 's/JAVA_XMX=1024/JAVA_XMX=512/' /etc/default/rudder-jetty
systemctl restart rudder-server.service

Merci Nicolas pour l’astuce :)

Changer le nom des machines du point de vue de Rudder

Autre problème, je n’ai pas toujours la main sur le FQDN des machines que je loue. En particulier, le retour de la commande hostname -f renvoit parfois le nom de la machine telle que l’appelle l’hébergeur.

Je me retrouve avec un inventaire rudder plein de machines avec des noms du type int.nua.ge et randomid.dedibox.fr…

Dans certains cas, je peux le modifier moi-même et/ou feinter Rudder (en modifiant le fichier /etc/hosts par exemple) mais plutôt que de faire ça, j’ai préféré utiliser une technique détaillée dans la documentation officielle de Rudder appelée override node fqdn

La méthode pour le faire à la main est la suivante. En tant que root, je crée un script qui renvoie un JSON contenant une variable avec le nom que je souhaite pour mon hôte :

# mkdir -p /var/rudder/hooks.d/
# vi /var/rudder/hooks.d/override-hostname.sh
echo '{"rudder_override_hostname": "myhost.example.org"}'
# chmod +x /var/rudder/hooks.d/override-hostname.sh
# rudder agent inventory
Rudder agent 7.2.4
Node uuid: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

C’est relativement simple, mais j’étais pas satisfait car ça nécessite une action manuelle et je suis super fainéant. Comme les noms courts de mes machines sont eux toujours bons, quel que soit le provider et que je connais le domaine par avance (zwindler.fr), j’ai créé unedirective Rudder pour le faire à ma place !

A partir d’une technique de type Distribution files / File content, j’ai mis les valeurs suivantes :

Et voilà le résultat, 5 minutes pour tard :)

Agent qui ne démarre pas après une désinstallation / réinstallation

Au début, quand je commençais à jouer avec Rudder, je me suis un peu mélangé les pinceaux au point qu’il était plus simple de tout désinstaller et recommencer proprement.

En théorie, quand on veut debug et/ou réinstaller un agent qui marche mal, on peut utiliser les commandes suivantes :

rudder agent factory-reset
rudder agent inventory
rudder agent check

Sauf que dans mon cas, j’avais désinstallé puis réinstallé l’agent. Et à chaque fois, tout avait l’air OK, mais rudder ne faisait rien et voici le message d’erreur que j’avais :

rudder agent check
INFO: No disable file detected and no agent executor process either. Restarting agent service... Done
WARNING: The file /var/rudder/cfengine-community/last_successful_inputs_update is older than twice 10 minutes, the agent is probably stuck. Purging the CFEngine lock database... Done
FINISH: Rudder agent check ran properly, please look at messages above to see if there has been any error.

Pour essayer de comprendre pourquoi Rudder ne se lançait jamais alors que la communication avec le serveur semblait OK, je suis allé voir ce que faisait le service systemd rudder-agent.service.

cat /lib/systemd/system/rudder-agent.service
[Unit]
Description=Rudder agent umbrella service
Documentation=man:rudder(8)
Documentation=https://docs.rudder.io
After=syslog.target
# Dependencies register themselves with a WantedBy/RequiredBy
# currently they are rudder-cf-serverd and rudder-cf-execd
[Service]
Type=oneshot
RemainAfterExit=yes
# This is required for the service to be able to
# pass these commands to its dependencies
ExecStart=/bin/true
ExecReload=/bin/true
[Install]
WantedBy=multi-user.target

Et là, c’était tout de suite plus clair. Le service rudder-agent est en réalité un simple service “chapeau”, dont dépendent 2 sous services rudder-cf-serverd et rudder-cf-execd.

Or, par défaut, quand vous désinstallez rudder-agent (à minima sur Debian/Ubuntu), les services rudder-cf-serverd.service et rudder-cf-execd.service sont “disabled” mais pas re-“enabled” à la réinstallation.

root@node01:/# systemctl status rudder-cf-serverd
● rudder-cf-serverd.service - CFEngine file server
Loaded: loaded (/lib/systemd/system/rudder-cf-serverd.service; disabled; vendor preset: enabled)
Active: inactive (dead)

Rudder ne faisait rien, tout simplement parce qu’il n’était juste pas activé :D. On règle ça en 4 commandes :-P

root@node01:/# systemctl enable rudder-cf-serverd
Created symlink /etc/systemd/system/multi-user.target.wants/rudder-cf-serverd.service → /lib/systemd/system/rudder-cf-serverd.service.
Created symlink /etc/systemd/system/rudder-agent.service.wants/rudder-cf-serverd.service → /lib/systemd/system/rudder-cf-serverd.service.
root@node01:/# systemctl start rudder-cf-serverd
root@node01:/# systemctl enable rudder-cf-execd
Created symlink /etc/systemd/system/multi-user.target.wants/rudder-cf-execd.service → /lib/systemd/system/rudder-cf-execd.service.
Created symlink /etc/systemd/system/rudder-agent.service.requires/rudder-cf-execd.service → /lib/systemd/system/rudder-cf-execd.service.
root@node01:/# systemctl start rudder-cf-serverd

Note : je ne suis pas convaincu que ce soit un comportement voulu, j’ai remonté le point à la team Rudder, je vous tiendrais au courant.

Conclusion

Voilà les quelques petits trucs rigolos que j’ai eu avec Rudder pour l’instant.

Je ne sais pas quand je ferai le prochain article sur Rudder. La version 8 approche doucement, ça sera peut-être à cette occasion (il y a une fonctionnalité que j’attends dedans).

On a pas non plus parlé des plugins. Ca pourrait valoir le coup (il en existe certains uniquement utilisables avec la version entreprise que je n’ai pas, mais aussi des gratuits).

A voir. En attendant, have fun !

Premiers pas avec Rudder - concepts et configuration

Fri, 24 Mar 2023 06:30:00 +0200

On reprend où on en était

Dans l’article précédent, je m’étais arrêté après l’installation du serveur Rudder sur une machine Ubuntu, ainsi que d’un agent.

Dans cet article, je pars du principe qu’on est un peu plus loin dans le temps. On a installé des agents à droite à gauche.

Dans mon cas, j’ai une dizaine de machines Debian et Ubuntu, provenant de VMs (chez nua.ge) et d’hyperviseurs/containers LXC (Proxmox VE).

Pour le “fun”, j’aurais pu faire l’effort d’installer des machines Windows mais je n’ai pas eu le courage. Peut-être une autre fois.

Node Inventory

C’est cool d’avoir une flotte de machines dans notre Rudder, mais qu’est-ce qu’on peut faire avec ?

La première chose qu’on peut faire, c’est d’aller voir ce que l’agent remonte comme info au serveur. Un peu comme les “facts” d’Ansible. Ca nous sera utile par la suite.

On va donc choisir un de nos “nodes” dans la liste et regarder l’onglet Inventory pour voir ce qu’on peut faire avec.

Je n’ai pas creusé en détail pour savoir s’il y avait plus d’infos collectées que ce qui est affiché dans ce menu, mais on a déjà de quoi faire, en parcourant toutes les catégories.

Grosso modo on va utiliser ces infos-là pour définir des groupes, puis l’état souhaité de nos machines.

Groups

Dans la terminologie Rudder, les serveurs sont des “nodes”, on en a déjà parlé. On va ensuite regrouper nos nodes par “groups” (avec une relation n-to-n).

Il y a plusieurs catégories de groupes. On peut soit regrouper les nodes par groupes statiques (pas super efficace quand on passe à l’échelle), soit tirer parti des informations trouvées dans l’inventaire (cf section précédente) pour créer des groupes dynamiques.

Enfin, il existe une dernière catégorie de groupes, dits “system” qui des groupes spéciaux gérés par Rudder.

On retrouve ça dans l’interface de Rudder dans la partie Node management / Groups.

Créer un groupe pour tous les serveurs Ubuntu

Comme j’ai beaucoup de serveurs Ubuntu, la première idée qui m’est venue à l’esprit a été de créer un groupe pour les regrouper.

Dans ce menu, il existe 2 choses qu’on peut créer. Des Categories et des Groups.

Je fais un mini aparté sur les Categories, concept qu’on pourra retrouver ailleurs dans l’interface. Il s’agit de subdivisions logiques (des “dossiers”, en gros) qui permettent de faciliter le rangement de nos bidules.

Comme j’aime bien que les choses soient bien rangées, j’ai commencé donc par créer une catégorie “By OS” pour regrouper tous mes groupes.

Une fois que c’est fait, on peut rentrer dans le dur et créer un groupe dynamique pour nos serveurs Ubuntu.

Quand on clique sur create, on peut ensuite ajouter les conditions pour déterminer si un hôte est dans le groupe ou pas.

Jusque-là, rien de bien foufou, on demande à Rudder de se baser sur les infos de l’inventaire et de matcher ou pas avec une regex.

Je note la petite feature de preview, qui permet de voir d’un coup d’œil si ça matche bien les bons hosts. C’est très sympa :)

Autre remarque, le menu déroulant est assez pratique à utiliser et assez fourni (c’est les infos de l’inventaire, donc assez riche).

Un exemple de ce qu’on peut faire juste avec la partie “node summary” :

Pour l’instant, rien de bien compliqué/original.

Un peu de théorie

C’est là où ça se corse (un peu, pas beaucoup). Avant d’aller plus loin, il va falloir comprendre quelques concepts propres à Rudder.

Je pompe honteusement le schéma de la doc officielle pour faire un support visuel, puis j’explique ensuite :

On a déjà parlé de notre relation n-to-n avec nos nodes et nos groups. Si on se concentre sur la partie gauche, on découvre 3 nouveaux concepts :

les techniques
les directives
les rules

Les techniques, c’est les fonctionnalités que rudder va appliquer ou vérifier sur nos nodes. Les techniques sont configurables et c’est pour ça qu’on va créer des directives à partir de ces techniques (relation 1-to-n).

Et pour finir, les rules sont ce qui va relier un certain nombre de groupes à un certain nombre de directives.

Premier exemple de directive

Quand j’ai commencé à tester Rudder, une CVE (de plus) venait de sortir sur sudo. Je voulais voir si Rudder était capable de vérifier si mes binaires sur mes ubuntu étaient patchés ou pas.

Je suis donc allé dans le menu Directives, cliqué dans la liste sur la technique Packages et j’ai créé ma directive à partie de cette technique.

Cette directive est relativement triviale, on fera des exemples plus complexes dans l’article suivant. Mais ça vous donne une idée du concept.

Première rule

Une fois la directive sauvegardée, on va créer une rule qui va regrouper nos groups et notre directive.

Comme vous pouvez le voir, c’est relativement trivial. Une fois que c’est validé, rudder passe sur tous nos nodes pour appliquer la nouvelle configuration.

On peut retrouver sur le Dashboard principal pour voir ce qu’il se passe de manière globale

Ou aller sur un node en détail et aller lire l’historique

Et si je ne veux pas appliquer ?

Par défaut, le “Policy mode” est positionné sur “Enforce”, ce qui veut dire que Rudder va auditer nos systèmes, puis les corriger s’ils ne sont pas conformes.

Si on veut faire ça, il suffit de positionner la directive sur “Audit”, et utiliser l’option “This specific version” plutôt que “Latest available version”.

Voici le résultat sur un node qui n’était pas à jour :

Conclusion

Voilà pour une très brève introduction sur le système de configuration des nodes et des politiques de conformité avec Rudder.

J’ai pris un exemple très très basique, mais il permet de se faire une idée rapide de la facilité d’utilisation de Rudder.

Premiers pas avec Rudder - Installation

Sun, 19 Mar 2023 14:30:00 +0200

Mais d’abord, c’est quoi Rudder ?

Rudder est un logiciel open-source de gestion de configuration et d’automatisation des systèmes, qui permet aux administrateurs système de contrôler et de gérer leurs infrastructures de manière industrialisée. Il est en grande majorité édité par la société Normation, qui vend du support et des fonctionnalités complémentaires (plugins).

Pendant longtemps, j’ai un peu mis de côté Rudder, pensant que ce n’était pas pour moi, surtout que j’avais investi beaucoup de temps dans Ansible (vous trouverez mes nombreux articles sur le sujet ici).

Cependant, ce qui fait à la fois la force et la faiblesse d’Ansible, c’est le fait qu’il soit agentless. On peut lancer nos playbooks depuis n’importe quelle machine, mais ça veut aussi dire qu’il n’y a pas a priori de machine privilégiée pour garder notre infra conforme dans la durée.

Alors oui, je sais qu’on va me rétorquer qu’il existe Tower/AWX, mais je n’ai pas du tout apprécié l’expérience le peu que je l’ai testé, au point de ne pas vouloir l’utiliser ni au travail, ni en perso. En particulier en perso, je trouve l’outil lourd et pas adapté pour mon objectif : garantir la conformité de mes quelques machines.

Parallèlement à ça, Rudder fonctionne avec un agent, et il y a un serveur centralisé qui contrôle les serveurs enregistrés. On peut consulter le tout dans une interface web et on voit en un clin d’oeil si les serveurs sont conformes ou pas.

Sans juger de l’expérience avec des centaines voire des milliers de serveurs, ça me parait adapté pour mon besoin perso (gérer une flotte de quelques machines voire dizaines de machines).

Installation du serveur

Je vais essayer de ne pas passer trop de temps sur cette partie. Elle a déjà été détaillée récemment par Stéphane Robert sur son blog et par Nidouille en stream la semaine dernière.

Grosso modo, j’ai popé une VM chez nua.ge en Ubuntu 22.04 avec 2 CPU et 2 Go de RAM, suivi la documentation officielle d’installation et basta.

sudo apt update
sudo apt upgrade
sudo wget --quiet -O /etc/apt/trusted.gpg.d/rudder_apt_key.gpg "https://repository.rudder.io/apt/rudder_apt_key.gpg"
echo "deb http://repository.rudder.io/apt/7.2/ $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/rudder.list
(output) deb http://repository.rudder.io/apt/7.2/ jammy main
sudo apt update

Note : j’étais assez content de voir dans la doc officielle que pour quelques nodes, 2 CPU / 2 Go de RAM suffisent (surtout qu’il y a une JVM, donc la conso RAM aurait pu être bien plus importante).

On nous conseille évidemment de vérifier que la clé correspond à celle indiquée dans la documentation officielle, puis on l’ajoute (affichée au moment de l’apt update) et on installe le package contenant le serveur.

apt install rudder-server

Une fois installé, la première chose à faire est de créer un utilisateur admin, puis on peut se connecter sur l’IP du serveur en HTTPS/443 (certificat autosigné par contre, faudra que je regarde comment ajouter du let’s encrypt).

ubuntu@rudder:~$ sudo rudder server create-user -u toto
New password:
Re-type new password:
User 'toto' added, restarting the Rudder server

Côté sécurité réseau, il va falloir ouvrir les ports 443 (obviously) mais aussi le 5309 pour que ça marche bien ( pour la partie “Fetch policy”, je vous laisse aller lire la doc).

Installation des agents

Même topo pour les agents, j’ai suivi la doc.

On peut donc installer simplement un agent sur nos serveurs en ajoutant la clé + le repo de rudder, puis en lançant la commande

sudo wget --quiet -O /etc/apt/trusted.gpg.d/rudder_apt_key.gpg "https://repository.rudder.io/apt/rudder_apt_key.gpg"
echo "deb http://repository.rudder.io/apt/7.2/ $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/rudder.list
sudo apt update && sudo apt install rudder-agent

A partir de là, l’agent ne sait pas où il doit s’enregistrer. On ajoute l’agent au serveur Rudder :

sudo rudder agent policy-server <IP.Du.Rudder.Server>

Petite subtilité, je n’ai pas eu besoin de faire cette étape dans un premier temps, car il se trouve que par défaut, les agents cherchent sur le LAN une machine s’appelant “rudder”. J’étais donc un poil surpris de ne pas voir cette info dans la doc (il faut que je fasse une PR pour corriger ça).

On vérifie ensuite que tout fonctionne :

sudo rudder agent inventory
Rudder agent 7.2.4
Node uuid: 72577f55-46b0-47e2-acd0-2eeb45353122
M| State Technique Component Key Message
E| compliant Common Compute inventory splay Scheduling rudder_run_inventory was correct
E| compliant Inventory Inventory The inventory has been successfully sent
info Rudder agent was run on a subset of policies - not all policies were checked
## Summary #####################################################################
2 components verified in 3 directives
=> 2 components in Enforce mode
-> 2 compliant
Execution time: 10.67s
################################################################################

Note : On prendra évidemment garde à ne pas ouvrir les ports des serveur/agents Rudder sur Internet et à utiliser des IPs locales et/ou des firewalls pour filtrer proprement tout ça. On pourra aussi utiliser un VPN, mais il ne faudra pas oublier d’autoriser les IPs des machines distantes dans Rudder (on en reparlera).

Accepter les machines dans notre inventaire

Un point qui n’était pas super clair pour moi dans la doc de Quickstart d’installation des agents, est qu’une fois que les agents étaient installés, il faut les autoriser côté serveur. C’est logique (on ne veut pas autoriser n’importe qui) mais la doc méritera une petite suggestion de ma part je pense.

Ce point est détaillé dans une autre partie de la documentation Node management / Accept new nodes, mais même cette partie de la documentation ne semble pas à jour, car je n’ai pas vu de menu “Navigate to Node Management → Accept new Nodes.”

On a en revanche un menu “Pending nodes” où on retrouve une liste de tous les agents fraichement installés en attente.

La suite ?

A partir de là, on a installé tout ce qu’on avait besoin d’installer pour commencer à jouer avec Rudder.

Cependant, on est déjà à 8000 signes et entamer la partie configuration dans cet article me parait lourd.

Je vais arrêter ici pour aujourd’hui et publier dans un prochain article (semaine prochaine surement) comment créer des groupes, ce que sont les rules et les directives en un seul et même bloc (ça sera plus cohérent).

En attendant, have fun !

Ansible : subtilités avec « defined » et « skipped »

Mon, 07 Feb 2022 07:00:00 +0000

Ansible des fois c’est pénible

Je vous parle souvent d’Ansible car c’est vraiment un outil qui a changé ma vie d’Ops. Pour autant, des fois c’est up peu pénible à comprendre…

Dans cet article je vais vous parler d’un de ces moments où j’ai vraiment pesté contre les Devs (c’est pas la première fois…). L’erreur initiale était mienne (a priori) mais les workarounds que j’ai testés me paraissaient légitimes…

Et cet article va me permettre de vous illustrer 2 concepts utiles pour vos tâches et variables Ansible qui sont skipped et defined.

C’est l’histoire de deux tâches

Pour remettre les choses dans le contexte : j’ai certaines actions que j’effectue ou non selon les cas sur un groupe d’hôtes donnés. Et c’était typiquement le cas ici…

Note: le code Ansible en lui-même n’est pas impeccable, on peut (et d’ailleurs, on va) faire beaucoup plus propre ; ce n’est pas ce que je veux montrer ici.

Voilà les tâches incriminés :

- name: "Get some content from a command"
 command: "command outputting something"
 changed_when: false
 register: command_output
 when: not_in_test_env

- name: "Write command_output to file"
 copy:
 dest: "{{ command_output_file_path }}"
 content: "{{ command_output.stdout }}"

Le contenu des deux tâches importe peu, car c’est plus des limitations d’Ansible que je vais vous présenter ensuite qui importe. On pourra retrouver cette limitation dans d’autres cas plus pertinents.

Ce qu’il faut retenir, c’est que :

la première tâche génère un output texte et enregistre le contenu dans une variable command_output
la seconde tâche copie le contenu de cette variable dans un fichier texte

Cela pourrait donc être n’importe quelle variable qu’on collecte de n’importe quelle autre façon… On peut donc légitimement appliquer ce genre d’opération dans d’autres contextes, avec certains nodes où on souhaite exécuter ces deux actions et certains autres, non.

Et là, c’est le drame.

Lors du moment où j’ai eu mon erreur, j’étais persuadé d’avoir bien mis un when: not_in_test_env pour skip la 2ème tâche aussi si la première l’est. Visiblement ce n’est pas le cas puisque je n’ai pas pu reproduire…

Dans le premier cas qui nous intéresse donc, si not_in_test_env est positionné à true, pas de problème.

En revanche, si je saute la première partie grâce à la variable not_in_test_env positionnée à false dans les fichiers de configuration de l’inventaire, vu qu’a priori j’ai fait une erreur et n’ai pas correctement écrit mon when dans la 2ème tâche, la première tâche est bien « Skipped » lors de l’exécution du playbook, mais la tâche suivante « Fail » misérablement.

Et pour cause… Ansible essaye à tout prix de résoudre la variable command_output.stdout alors même que la tâche va être « Skipped ». Sur le moment, je n’arrivais pas à comprendre POURQUOI ça n’étais pas skip et j’ai donc essayer de trouver des parades.

Pile, tu gagnes, …

Ma première idée a été de tenter de feinter l’erreur en initialisant la variable dans le cas où elle n’est pas renseignée car la tâche est « Skipped ».

- name: "Write command_output to file"
 copy:
 dest: "{{ command_output_file_path }}"
 content: "{{ command_output.stdout | default('') }}"

Manque de bol pour moi… je suis encore sur une vieille version d’Ansible, le | default( ») ne fonctionne pas sur les sous-variables (ici .stdout).

Beginning in version 2.8, attempting to access an attribute of an Undefined value in Jinja will return another Undefined value, rather than throwing an error immediately. This means that you can now simply use a default with a value in a nested data structure (in other words, {{ foo.bar.baz | default('DEFAULT') }}) when you do not know if the intermediate values are defined.

https://docs.ansible.com/ansible/latest/user_guide/playbooks_filters.html

| default ou pas, Ansible essaye donc de résoudre command_output.stdout ; la tâche continue donc de « Fail »…

… Face, je perd

En passant en mode « debug », j’ai remarqué quelque chose que je ne savais pas. Quand on « Skip » une tâche avec un register:, la variable pas enregistrée (car skip) n’est pas vide. Mon problème est que command_output.stdout n’existe effectivement pas, mais command_output si.

Plus précisément, Ansible injecte une sous entrée command_output.skipped positionnée à « true ».

Je me suis donc dit : banco ! Je vais modifier ma condition pour qu’elle empêche l’exécution de la tâche si command_output.skipped existe (car ça veut dire que command_output.stdout n’existe pas).

Ça donne quelque chose comme ça :

- name: "Get some content from a command"
 command: "command outputting something"
 changed_when: false
 register: command_output
 when: not_in_test_env

- name: "Write command_output to file"
 copy:
 dest: "{{ command_output_file_path }}"
 content: "{{ command_output.stdout }}"
 when: not command_output.skipped

Et là, dans le cas où not_in_test_env est false, ça ne fail plus.

Victoire ? Non bien sûr… car command_output.skipped n’existe pas (pas de skipped = false) quand la tâche est exécutée (c’est à dire « pas skipped »). Retour à la case départ : maintenant ça « Fail » dans le cas où on ne « Skip » plus…

Sur la tranche, je perds aussi

Dernière idée, on peut se dire que le plus simple / propre, c’est tout simplement de tester le fait qu’une variable (que ce soit command_output.stdout ou command_output.skipped) soit « defined » pour décider si on exécute ou pas la tâche.

- name: "Write command_output to file"
 copy:
 dest: "{{ command_output_file_path }}"
 content: "{{ command_output.stdout }}"
 when: command_output.stdout is defined

Mais évidemment, pour que la blague soit complète, ce qu’il faut savoir c’est qu’une solution à base de command_output.skipped is defined, ne peut pas marcher…

En fait, il n’est pas possible avec Ansible d’utiliser is defined pour vérifier l’existence (ou non) d’un sous élément.

Solutions

La solution la plus simple, que je croyais dur comme fer avoir implémenté (mais mes tests additionnels me prouvent que non) c’est simplement d’ajouter un when: not_in_test_env à la 2ème tâche…

Dans la même veine, et qui permet en plus d’éviter d’initialiser pour rien command_output.skipped, il aurait pu être malin de simplement utiliser un block: avec le when, englobant les deux tâches :

- block:
 - name: "Get some content from a command"
 command: "command outputting something"
 changed_when: false
 register: command_output

 - name: "Write command_output to file"
 copy:
 dest: "{{ command_output_file_path }}"
 content: "{{ command_output.stdout }}"
 when: not_in_test_env

Et la vraie solution si jamais vous voulez absolument vérifier si la tâche précédente a été skipped ou pas, est d’utiliser la syntaxe suivante :

- name: "Write command_output to file"
 copy:
 dest: "{{ command_output_file_path }}"
 content: "{{ command_output.stdout }}"
 when: 'skipped' not in command_output

Cette syntaxe n’est pas hyper évidente de prime abord, mais c’est la seule qui fonctionne dans Ansible pour faire ça…

Bonus

Un lecteur (‘Jof) m’a fait remarquer qu’il y a une autre solution qui marche dans tous les cas :

- when command_output|skipped

Merci à lui !

Conclusion

Le vrai problème ici est quand même que j’avais vraiment besoin de vacances pour ne pas avoir été capable de trouver l’erreur aussi basique ;-).

La seconde est que j’utilise une version antédiluvienne d’Ansible et que ça irait beaucoup mieux avec des versions plus récentes (pour le | default notamment).

La dernière chose à retenir est que quand on veut vérifier la présence ou non d’un sous élément dans une variable, le mieux reste d’utiliser in ou not in plutôt que is defined qui ne fonctionne pas dans tous les cas.

Sources additionnelles

Ma plateforme de travail collaboratif Nextcloud en 5 minutes

Mon, 27 Apr 2020 06:45:00 +0000

C’est quoi Nextcloud ?

Par où commencer ? Nextcloud, c’est tellement de choses ;-)

Historiquement, Nextcloud est un fork du projet Owncloud, qui visait à fournir un service en ligne de stockage de fichier via une interface web. Un peu comme Dropbox, mais hébergé par vous, chez vous, et donc respectueux de votre vie privée !

Mais aujourd’hui, Nextcloud c’est bien plus que ça. C’est une véritable plateforme de travail collaboratif avec certes un service de gestion, de partage et de synchronisation de fichiers entre plusieurs devices/utilisateurs, mais aussi un serveur libreoffice/collabora de l’édition de fichiers collaboratifs (Office 365/Google Docs), un serveur Talk (visioconférence), calendrier, gestion de notes et bien plus encore.

La solution s’est même nettement étoffée depuis la version 18 qui vient de sortir, avec de très nombreuses extensions.

Pourquoi attendre si longtemps pour en parler ?

La première fois que j’ai testé Owncloud, c’était en 2014 lorsque j’ai créé (sans succès) une entreprise d’infogérence spécialisée dans les outils open source. Le but était de fournir, entre autre, un service autohébergé pour justement remplacer Dropbox. Cette annecdote fera peut être sourire certains de mes lecteurs, très impliqués dans Nextcloud :-p.

A l’époque, je n’avais pas du tout aimé Owncloud, que j’avais trouvé moyen en terme d’ergonomie, très lent, etc.

Récemment cependant, Nextcloud a gagné beaucoup de traction et c’est tant mieux, car ça m’a forcé à rester l’outil, qui a vraiment évolué pour le mieux.

Et comment on va faire pour le déployer si vite ?

Ahah ! En voilà une bonne question… Grosse surprise, on va déployer tout ça avec un playbook, bien sûr !

Pour ceux qui ne savent pas, à chaque fois que j’installe un soft, j’automatise ça avec ansible, car j’automatise TOUT avec ansible.

Je vous met à disposition sur Github cet ensemble de playbooks qui vous permettront d’installer un serveur Nextcloud de A à Z en partant d’un serveur Ubuntu 18.04 sur lequel vous avez un accès SSH.

Et pour ceux qui n’ont pas de serveur à disposition, je vous ai également mis un playbook permettant de déployer une machine sur le cloud provider français Scaleway.

Pourquoi Scaleway ? Pas parce que j’ai le moindre partenariat avec eux (pas pour l’instant en tout cas), mais parce :

ils sont français
ils ont une super API et des modules Ansible qui marchent très très bien (j’ai même fais un live coding avec) avec l’inventaire ansible dynamique (ce que d’autres n’ont pas forcément)
ils proposent des instances à moins de 4€ par mois, payable à l’heure, ce qui est parfait pour des petits tests

Mais n’importe quelle autre machine sous Ubuntu 18.04 fera l’affaire !

Créer une VM sur Scaleway

Je ne détaillerai pas l’instanciation de la VM sur Scaleway si vous choisissez cette option, car tout est expliqué en détail sur le README.md du dépôt Github. J’ai également abondamment parlé de ce sujet à l’occasion d’autres articles

Préparer l’installation de Nextcloud

Avant de pouvoir installer Nextcloud sur notre nouveau serveur Ubuntu 18.04 tout neuf, il est important de choisir un nom de domaine pour notre futur service Nextcloud. Ajoutez un CNAME permettant de mapper ce nom de domaine sur l’adresse IP de votre machine virtuelle Ubuntu.

Maintenant que le serveur Ubuntu 18.04 est disponible et que le futur service est résolvable, on dispose de 2 méthodes pour installer Nextcloud. Soit on lance le playbook ansible en local sur la machine Nextcloud, soit on l’installe à distance via ansible.

Si on le lance en local

Récupérer le repository zwindler/ansible-nextcloud directement sur le serveur via un git clone. Nous utiliserons le paramètre “-i hosts_local” quand on exécutera ansible-playbook.

Si on a généré une VM avec Scaleway

Dans ce cas, on profitera de la fonctionnalité d’inventaire dynamique fournie par Scaleway. Nous utiliserons le paramètre “-i dynamic_inventory.yml” quand on exécutera ansible-playbook.

Si vous voulez installer à distance

Il sera nécessaire de pouvoir se connecter en SSH à la machine distante mais aussi de générer un inventaire pour qu’ansible sache sur quel machine il doit se connecter. Pour le faire on créera un fichier texte avec l’IP du serveur distant, et nous utiliserons “-i hosts_distant” quand on exécutera ansible-playbook.

echo "IP_of_the_server" > hosts_distant

Installer Nextcloud

En partant du principe que vous avez utilisé la méthode Scaleway avec l’inventaire dynamique, voilà ce que vous devrez faire :

ansible-playbook -i dynamic_inventory.yml -u root nextcloud_install.yml

Le playbook vous promptera pour renseigner un certain nombre de variables qui correspondent à votre installation :

MariaDB root password: awesome_mariadb_password
Nextcloud MariaDB password: awesome_mariadb_user_password
Your domain: example.org
Nextcloud HTTPS port [8443]: 443
Nextcloud instance name (URL will be https://thisvalue.example.org) [nextcloud]: nextcloudscw

A l’issue du playbook, vous devriez pouvoir vous connecter sur votre instance pour finaliser l’installation. Lorsque vous vous connecterez pour la première fois, vous tomberez sur un écran qui vous demandera une partie des informations rentrées préalablement

Et la sécurité ?

Et oui, la sécurité pour un outil aussi sensible que vos documents, c’est important.

Heureusement, Nextcloud est un outil bien packagé et un projet pour lequel la sécurité est au cœur du développement.

Nextcloud met à disposition un scan de sécurité (scan.nextcloud.com) qui vous permettra de vous tester contre un certain nombre d’attaques connues.

Comme vous pouvez le voir, ça se passe plutôt bien ;-)

De même, la configuration nginx (le frontal de notre serveur) coté TLS est elle aussi sécurisée. Par défaut, je désactive TLS 1.0 et 1.1, ce qui peut poser des soucis pour les plus vieux appareil mais permet d’obtenir un joli A+ chez SSL Labs

Dans le cas où vous souhaiteriez les réactiver, c’est possible (il y a un flag dans le playbook) mais dans ce cas là la note sera rétrogradée à B.

Et c’est fini ! Have fun !

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 !!!

Migration mongoDB à chaud depuis une 3.4 vers une 4.0 (replicaSet)

Tue, 05 Feb 2019 11:45:02 +0000

MongoDB

Depuis peu, j’administre des bases de données MongoDB !

Pour le fun (et ceux qui ne connaissent pas), la définition qu’en donne Wikipedia :

MongoDB (de l’anglais humongous qui peut être traduit par « énorme ») est un système de gestion de base de données orientée documents, répartissable sur un nombre quelconque d’ordinateurs et ne nécessitant pas de schéma prédéfini des données. Il est écrit en C++. Le serveur et les outils sont distribués sous licence AGPL{.new}, les pilotes sous licence Apache et la documentation sous licence Creative Commons. Il fait partie de la mouvance NoSQL.

Comme dans la vie de tout projets, on installe un logiciel, et sur le moment ça nous suffit, on est contents.

Mais arrive le jour fatidique où le logiciel est obsolète et il faut mettre à jour la base. Sans aucun créneau de maintenance pour le faire bien entendu car elles sont évidemment utilisées en production ;-).

Prérequis

Bon point pour moi, je n’ai pas fais l’erreur d’avoir une base de données mongoDB « standalone ». Je dispose de cluster de bases de données MongoDB (replicaSet, dans la terminologie mongo), que je vais donc pouvoir mettre à jour à chaud. Ça sera juste un peu plus long ;-).

3.4 => 4.0 = pas possible

Bon quand même, fallait bien que je tombe dans le piège.

La version majeure 3.4 (la dernière en date est la .19) ne peut pas directement être mise à jour vers une 4.0. Comme c’est une majeure, il faut passer d’abord par la majeure suivante, la 3.6 (c’est classique comme limitation).

On passe en 3.6 alors

Pour me simplifier la vie, j’ai un mini playbook Ansible qui me permet d’ajouter les dépôts en fonction de la version que je veux.

- name: Prepare mongodb upgrade
hosts: all
vars:
#mongo_repo : "deb [ arch=amd64,arm64 ] http://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 multiverse"
mongo_repo: "deb [ arch=amd64,arm64 ] https://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.6 multiverse"
#mongo_repo: "deb [ arch=amd64,arm64 ] https://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/4.0 multiverse"
tasks:
- name: "Add mongodb repository key"
apt_key:
keyserver: keyserver.ubuntu.com
id: "{{item}}"
state: present
loop:
- 0C49F3730359A14518585931BC711F9BA15703C6
- 2930ADAE8CAF5059EE73BB4B58712A2291FA4AD5
- 9DA31620334BD75D9DCB49F368818C72E52529D4
- name: "Add mongodb repository"
apt_repository:
repo: "{{ mongo_repo }}"
state: present
update_cache: yes

Clairement, on peut faire plus propre. Ici, c’est du oneshot sur quelques machines Ubuntu, donc je n’ai pas automatisé plus que ça. Mais si vous avez plus de machines à faire que moi, je vous invite à le raffiner un peu, par exemple en ajoutant le repo et la clé en fonction de la version donnée en paramètre.

ansible-playbook -i inventory/prod/mongo-prod prepare_mongo_upgrade.yml -b

Mise à jour des binaires vers la 3.6

Maintenant qu’on a bien les dépôts pour la version 3.6, on peut mettre à jour nos serveurs. Idéalement si on avait de nombreux clusters à migrer, il faudrait le faire avec un playbook Ansible (ou autre) qui passe sur les serveurs, uns par uns, les mets à jour et les redémarre.

Cependant, pour simplifier l’explication, je vais laisser la procédure telle quelle et tout faire à la main.

Sur les SECONDARY, uns par uns, mettre à jour manuellement le serveur, puis le redémarrer :

apt-get update
apt-get upgrade mongodb-org-server mongodb-org-shell
[...]
Unpacking mongodb-org-server (3.6.10) over (3.4.19) ...
[...]
systemctl restart mongod

Vérifier que tout fonctionne à nouveau après redémarrage

mongo
MongoDB shell version v3.6.10
connecting to: mongodb://127.0.0.1:27017/?gssapiServiceName=mongodb
Implicit session: session { "id" : UUID("17272d4e-ecd0-49c2-a672-8804227ab0e4") }
MongoDB server version: 3.6.10
rs:SECONDARY>

Puis, se connecter sur le PRIMARY, et lui passer la commande suivante (qui va avoir pour effet de le rétrograder proprement et temporairement en tant que SECONDARY) :

$> mongo
rs:PRIMARY> use admin
switched to db admin
rs:PRIMARY> db.auth('myadmin', 'myawesomepassword')
1
rs:PRIMARY> rs.stepDown(180)
[...]
2019-01-25T15:23:02.520+0000 I NETWORK [thread1] trying reconnect to 127.0.0.1:27017 (127.0.0.1) failed
2019-01-25T15:23:02.548+0000 I NETWORK [thread1] reconnect 127.0.0.1:27017 (127.0.0.1) ok
rs:SECONDARY>

Et enfin, mettre à jour manuellement le serveur de la même manière que les autres :

apt-get update
apt-get upgrade mongodb-org-server mongodb-org-shell
systemctl restart mongod

Compatibilité 3.6

Ici, je viens de faire la migration de 3.4 vers 3.6. En réalité, ce n’est pas complètement terminé. L’ensemble des binaires ont beau être en version 3.6, la base elle, reste en « compatibilité » 3.4.

Pour s’en assurer, une connexion sur n’importe quel serveur permet de le vérifier :

$> mongo
rs:SECONDARY> db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )
{ "featureCompatibilityVersion" : { "version" : "3.4" }, "ok" : 1 }

On va donc aller sur le nœud PRIMARY pour passer la base en compatibilité 3.6 (le seul prérequis est qu’une majorité de serveurs aient leurs binaires mis à jour en 3.6 et redémarrés) :

$> mongo
MongoDB shell version v3.6.10
connecting to: mongodb://127.0.0.1:27017/?gssapiServiceName=mongodb
Implicit session: session { "id" : UUID("aaa-aaa-aaa-aaa-aaa") }
MongoDB server version: 3.6.10
rs:PRIMARY> db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )
{ "featureCompatibilityVersion" : { "version" : "3.4" }, "ok" : 1 }
rs:PRIMARY> use admin
switched to db admin
rs:PRIMARY> db.auth('myadmin', 'myawesomepassword')
1
rs:PRIMARY> db.adminCommand( { setFeatureCompatibilityVersion: "3.6" } )
{ "ok" : 1 }
rs:PRIMARY> db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )
{ "featureCompatibilityVersion" : { "version" : "3.6" }, "ok" : 1 }

OK ! on a fait la moitié du chemin…

Mettre à jour le ReplicaSet dans la version 1

Différence notable entre la version 3.4 et la version 3.6, c’est la façon dont sont gérés les replicaSets. La version 3.6 introduit la version 1 du protocol des replicaSet, et empêche les précédents clusters déclarés de fonctionner.
Il est donc nécessaire de mettre à jour le protocole avant de mettre à jour en 4.0.

Ouvrir un shell mongo sur le PRIMARY, et modifier la configuration du replicaset (rs) :

cfg = rs.conf();
cfg.protocolVersion=1;
rs.reconfig(cfg);

Mise à jour des binaires vers la 4.0

Bon, je ne vais pas vous refaire l’affront de vous copier coller la procédure de mise à jour : maintenant qu’on a mis à jour la version du replicaSet, c’est la même.

Pour rappel :

Relancer le playbook pour ajouter le dépôt de la version 4.0 (décommenter la ligne 4.0)
Mise à jour des serveurs SECONDARY puis redémarrage du serveur
Step down du PRIMARY
Mise à jour du PRIMARY devenu SECONDARY après le stepdown, puis redémarrage du serveur
Mise à niveau de la compatibilité de la base en 4.0

rs:PRIMARY> db.adminCommand( { setFeatureCompatibilityVersion: "4.0" } )
{
"ok" : 1,
[...]
}
rs:PRIMARY> db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )
{
"featureCompatibilityVersion" : {
"version" : "4.0"
},
[...]
}

Et voilà, votre cluster est « up-to-date », après 2 upgrades de versions majeures et sans aucune interruption de service. Alors, comme on dit chez moi :

Encore une victoire de Canard !

source : player.ina.fr/player/embed/PUB417943064/1/1b0bd203fbcd702f9bc9b10ac3d0fc21

Sources

Récupérer les informations sur la distribution avec les facts Ansible

Wed, 21 Nov 2018 12:45:40 +0000

Les facts d’Ansible

Si vous suivez le blog, vous savez que j’utilise énormément Ansible. J’ai même été faire un talk sur le sujet à BDX I/O 2018, à l’ENSEIRB.

Aujourd’hui, plutôt que de vous donner un playbook tout fait pour installer sans effort une des multiples applications dont j’ai automatisé le déploiement avec Ansible, je vous propose d’explorer une des features les plus importantes et utiles d’Ansible, les facts, par le biais d’un petit exemple.

C’est quoi les facts dans Ansible

Si vous avez déjà lancé un playbook, vous avez sûrement remarqué lors de son exécution, que la première tâche qui est réalisée n’est pas une tâche que vous avez demandée explicitement.

ansible-playbook -i inventory/prod/blop -u blop --private-key=blop.key configure-blop.yml
[...]]
TASK [Gathering Facts] *********************************************************
ok: [blop-vm1]

Cette tâche [Gathering Facts], qui ne fait à première vue rien, correspond en fait à la connexion à la ou les machines sur lesquelles seront exécutées les playbooks. Si la connexion échoue, le playbook échouera sur cette cible, et continuera éventuellement sur les autres (s’il en reste). Si l’hôte répond, alors Ansible en profite pour récupérer moult informations en rapport avec cette machines et les stockent dans une variable ansible_facts.

A quoi ça ressemble ?

Comme je ne disais, à première vue, cette commande de fait rien. Si on ne sait pas qu’elle stocke des informations dans une variables, on ne peut rien en faire.

Un bon moyen d’avoir un premier aperçu de ce qu’on peut en faire est de les afficher. On peut faire ça avec le module « setup », qui est en réalité le même module qui est appelé lors de l’étape [Gathering facts].

Le retour se fera au format JSON, ce qui est certes peu digeste, mais facilitera grandement les manipulations de type « filtre » (via le flag filter intégré ou via l’utilitaire jq par exemple).

ansible blop-vm1 i inventory/prod/blop -m setup
blop-vm1 | SUCCESS => {
"ansible_facts": {
"ansible_all_ipv4_addresses": [
"10.1.1.10"
],
"ansible_apparmor": {
"status": "enabled"
},
[...]

Je ne vous copie-colle pas tout, rien que pour cette machine, j’ai 719 lignes… La quantité d’informations disponible est impressionnante, et on peut même en venir à se demander à quoi ça va bien pouvoir nous servir.

Ok, on en fait quoi ?

Du coup je profite de cet article pour faire un tuto tout simple et qui peut être utile dans de nombreux cas, réaliser des opérations différentes en fonction de la distribution de la machine concernée.

L’information qui va nous intéresser ici concerne donc les remontées en tant que « nom » ou « version » d’une distribution. Je vais vous économiser la lecture de nos 700+ lignes, et vous indiquer que vous pouvez trouver ces informations en filtrant sur les mots clés « ansible_distribution… » et « ansible_os… »

Voilà ce qu’on pourrait obtenir sur une machine CentOS :

ansible blop-vm1 -m setup -a 'filter=ansible_distribution*'
blop-vm1 | SUCCESS => {
"ansible_facts": {
"ansible_distribution": "CentOS",
"ansible_distribution_major_version": "7",
"ansible_distribution_release": "Core",
"ansible_distribution_version": "7.2.1511"
},
"changed": false
}
ansible blop-vm1 -m setup -a 'filter=ansible_os_family'
blop-vm1 | SUCCESS => {
"ansible_facts": {
"ansible_os_family": "RedHat"
},
"changed": false
}

Et sur une machine Ubuntu :

ansible blop-vm2 -m setup -a 'filter=ansible_distribution*'
ansible blop-vm2 | SUCCESS => {
"ansible_facts": {
"ansible_distribution": "Ubuntu",
"ansible_distribution_file_parsed": true,
"ansible_distribution_file_path": "/etc/os-release",
"ansible_distribution_file_variety": "Debian",
"ansible_distribution_major_version": "16",
"ansible_distribution_release": "xenial",
"ansible_distribution_version": "16.04"
},
"changed": false
}
ansible blop-vm2 -m setup -a 'filter=ansible_os*'
blop-vm2 | SUCCESS => {
"ansible_facts": {
"ansible_os_family": "Debian"
},
"changed": false
}

Utiliser les facts dans un playbook

Pour continuer dans l’exemple, on va faire une chose qu’il ne faut jamais faire : désactiver le firewall et SELinux.

Imaginons que vous souhaitiez quand même le faire. Si vous lancez ce playbook sur tout votre parc et qu’il n’est pas homogène, vous allez tomber sur des groupes de machines Ubuntu, CentOS 5, 6, 7…

Un moyen de gérer les cas particuliers pourrait être de les classer tous vos hosts dans des groupes, et de créer un playbook pour chaque OS/version, restreint à un groupe de machines uniquement.

---
- hosts: rhelcentos6only
tasks:
[…]

Ce n’est d’ailleurs pas une mauvaise idée, surtout pour gérer les distrib aussi différentes que RHEL et Ubuntu par exemple.

En revanche, dans le cas de RHEL, on a des différences qui apparaissent à partir de la RHEL 7, notamment la gestion du Firewall qui passe de IPtables à firewalld.

On va donc faire appel à la clause when: de ansible, qui conditionne l’exécution d’une tâche (ou d’un rôle ou d’un block) à une validation. Et ça donnerait quelque chose comme ça :

---
- hosts: rhelcentos6only
tasks:
- name: "shutdown and disable IPtables for RHEL <= 6"
service:
name=iptables
state=stopped
enabled=no
when: (ansible_distribution == "CentOS" or ansible_distribution == "RedHat") and
(ansible_distribution_major_version <= "6")
- name: "shutdown and disable firewalld for RHEL >= 7"
service:
name=firewalld
state=stopped
enabled=no
when: (ansible_distribution == "CentOS" or ansible_distribution == "RedHat") and
(ansible_distribution_major_version >= "7")
- name: "disable selinux"
selinux:
state=disabled

Dans cet exemple, lors de l’exécution du playbook, on aura donc, pour chaque VM CentOS ou RHEL, une tâche qui sera exécutée, et l’autre qui sera marquée « skipping » (en bleu clair) et le playbook marchera pour toutes les RHEL, quelque soit leur version.

Aller plus loin

Il existe une page spécifique sur la documentation d’Ansible pour parler des conditions dans les playbooks, accessible à l’adresse suivante : https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_conditionals.html

Vous pouvez aussi utiliser les facts dans les options des tasks, et dans les templates, en encadrant le nom de la variable souhaitée avec des « doubles curly braces » : {{ xxx }}

- command: "echo {{ ma_super_variable }}"