Un peu plus d'assaisonnement

Magazine
Marque
GNU/Linux Magazine
Numéro
166
|
Mois de parution
décembre 2013
|
Domaines


Résumé
Nous avons précédemment vu comment le système de gestion de configuration Salt nous permettait de contrôler différents aspects d'un parc de machines, par exemple en s'assurant que des fichiers de configuration communs étaient tous synchronisés et que les paquets nécessaires aux services souhaités sur ces serveurs étaient bien installés et à jour. Bien que le nombre de modules fournis par défaut par Salt permette l'orchestration d'un parc relativement standard, pour une infrastructure de grande envergure ou pour des besoins spécifiques, il peut s'avérer indispensable de créer son propre module de contrôle, c'est cet aspect du logiciel que nous allons explorer ici.

Body

1. Vogue, petit module, vogue

Un master Salt sait évidemment communiquer avec ses minions pour les interroger ou leur faire exécuter des actions et dans ce dernier cas, une panoplie de possibilités permet de façonner les minions avec grande souplesse.

Salt est livré muni d'une quantité remarquable de modules, présents dans ${PREFIX}/lib/pythonX.Y/{site,dist}-packages/salt/modules. Mais d'emblée, nous sommes en mesure d'étendre cette liste sans polluer le contenu du répertoire placé sous le contrôle du paquet fourni par votre système. Pour ce faire, il suffit, dans le répertoire défini comme file_roots dans le fichier de configuration de salt-master d'ajouter un répertoire _modules (notez l'underscore devant le nom du répertoire). Une fois le répertoire _modules peuplé de modules maison, ces derniers seront synchronisés sur les minions grâce à la commande :

# salt ‘*’ saltutil.sync_modules

Où, comme vu dans l'article de présentation de la suite Salt, '*' représente l'environnement de base (tous les minions); on aurait pu spécifier un minion en particulier ou une condition relative à une catégorie de minions. Par exemple, pour cibler les minions dont le système d'exploitation est Debian GNU/Linux, on aurait fait :

# salt -G ‘os:Debian’ saltutil.sync_modules

Utilisant ainsi les grains, valeurs statiques chargées au démarrage des minions.

Deux intérêts majeurs à la possibilité de synchroniser ainsi dynamiquement des modules :

- Utiliser des modules spécifiques à votre environnement.

- Tester des modules que vous souhaiteriez publier plus largement et pourquoi pas les soumettre au projet Salt pour inclusion dans le logiciel lui même.

Munis de cette facilité, nous allons pouvoir démarrer l'apprentissage de l'écriture d'un module simple et nous familiariser ainsi avec les multiples possibilités offertes par l'environnement Salt.

2. Hello, Salt

Nous en avons parlé dans l'article d'introduction, Salt est écrit en python, et tout naturellement, les modules sont également proposés dans ce langage, simplifiant grandement leur écriture. Nous allons donc écrire un simple module qui renvoie une chaîne de caractères et constater son fonctionnement sur un sous-ensemble de minions. Exécution :

$ cat ~/salt/_modules/hello.py
def hello():
return ‘Hello, Salt!

On synchronise ce module comme vu précédemment, je choisis ici mes machines NetBSD :

# salt -G ‘os:NetBSD’ saltutil.sync_modules
watto:
- modules.hello
korriban:
- modules.hello
coruscant:
- modules.hello
exar:
- modules.hello
ragnos:
- modules.hello

Le maître nous informe que le module hello a été synchronisé sur nos minions dont le grain “os” vaut NetBSD. Il nous est maintenant possible de faire appel à notre nouveau module de la façon la plus simple qui soit :

$ sudo salt -G ‘os:NetBSD’ hello.hello
exar:
Hello, Salt!
watto:
Hello, Salt!
coruscant:
Hello, Salt!
korriban:
Hello, Salt!
ragnos:
Hello, Salt!

Simple non ?

Le développement de modules, comme tout développement, pouvant s'avérer semé d'embûches, il n'est pas obligatoire de passer systématiquement par la machinerie master - minion. L'utilitaire salt-call permet de réaliser un appel direct :

# salt-call hello.hello
[INFO ] Configuration file path: /usr/pkg/etc/salt/minion
local:
Hello, Salt!

Ce petit exemple ouvre d'ores et déjà un nombre de possibilités assez vaste mais sa portée reste limitée. Héritant des capacités objet de Python, Salt permet, au sein d'un module, de faire appel à toute sa machinerie interne.

Faisons-donc appel, dans notre module trivial, à la notion de grains :

$ cat hello.py
def hello():
if __grains__[‘kernelrelease’] < ‘6.1’:
return ‘VIEUX!’
return ‘JEUNE! {0}’.format(__grains__[‘kernelrelease’])

Après avoir synchronisé cette nouvelle version, nous pouvons constater son bon fonctionnement :

# salt -G ‘os:NetBSD’ hello.hello
watto:
JEUNE! 6.1_RC4
coruscant:
VIEUX!
exar:
VIEUX!
korriban:
VIEUX!
ragnos:
VIEUX!

Pour rappel, on consultera la liste des grains disponibles via la commande :

# salt ‘watto’ grains.items
watto:
cpu_flags: FPU DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA
CMOV PAT PSE36 CFLUSH MMX FXSR SSE SSE2 SSE3 CX16 POPCNT RAZ XD LAHF
cpu_model: Intel 686-class
cpuarch: i386
defaultencoding: ISO8859-15
defaultlanguage: fr_FR
domain: home.imil.net
fqdn: watto.home.imil.net
gpus:
{‘model’: ‘CL-GD5446’, ‘vendor’: ‘Cirrus Logic’}
host: watto
id: watto
ipv4:
127.0.0.1
192.168.1.151
kernel: NetBSD
kernelrelease: 6.1_RC4
localhost: watto.home.imil.net
master: coruscant
mem_total: 511
nodename: watto.home.imil.net
num_cpus: 2
num_gpus: 1
os: NetBSD
os_family: NetBSD
osrelease: 6.1_RC4
path: /usr/bin:/bin:/usr/pkg/bin:/usr/local/bin:/sbin:/usr/sbin:/
usr/pkg/sbin:/usr/X11R7/bin:/home/imil/bin
ps: ps auxwww
pythonpath:
/usr/pkg/bin
/usr/pkg/lib/python27.zip
/usr/pkg/lib/python2.7
/usr/pkg/lib/python2.7/plat-netbsd6
/usr/pkg/lib/python2.7/lib-tk
/usr/pkg/lib/python2.7/lib-old
/usr/pkg/lib/python2.7/lib-dynload
/usr/pkg/lib/python2.7/site-packages
pythonversion: 2.7.3.final.0
saltpath: /usr/pkg/lib/python2.7/site-packages/salt
saltversion: 0.15.1
server_id: 1276300030
shell: /usr/pkg/bin/bash
virtual: kvm

Toutes les clés et valeurs sont disponibles, soit à partir de la ligne de commande à la suite du flag -G, soit directement dans le module à l'aide du dict __grains__.

3. Pass'pass'l'module

Au delà des grains, c'est à l'intégralité des fonctionnalités de Salt auxquelles nous avons accès dans notre module, ceci à travers le dict __salt__. Accédons par exemple aux fonctions d'exécution :

$ cat hello.py
def hello(directory):
return __salt__[‘cmd.run’](‘ls {0}’.format(directory))
$ sudo salt ‘coruscant’ saltutil.sync_modules
$ sudo salt-call hello.hello ‘/usr’
[INFO ] Configuration file path: /usr/pkg/etc/salt/minion
[INFO ] Executing command ‘ls /usr’ in directory ‘/root’
local:
X11R6
X11R7
bin
games
include
lib
libdata
libexec
local
mdec
obj
obj-i386
pkg
pkgsrc
sbin
share
src
tests
tools
tools-i386

Ici, nous exécutons la commande ls suivie d'un paramètre variable (directory) en faisant appel au module cmdmod.py, présent dans l'installation de base de Salt. Ce dernier expose des fonctions d'interfaçage avec l'exécution de commandes sur le minion ciblé. Bien évidemment, notre module hello est également immédiatement disponible pour tous les autres modules chargés. Par exemple, lors de l'écriture de hello2, dans un fichier distinct hello2.py, nous sommes parfaitement autorisés à utiliser les fonctionnalités de hello.py :

$ cat hello2.py
def hello2():
return __salt__[‘hello.hello’](‘/stand’)
$ sudo salt ‘coruscant’ saltutil.sync_modules
coruscant:
- modules.hello2
$ sudo salt-call hello2.hello2
[INFO ] Configuration file path: /usr/pkg/etc/salt/minion
[INFO ] Executing command ‘ls /stand’ in directory ‘/root’
local:
amd64

La fonction hello2 fait appel à la fonction hello précédemment écrite dans hello.py en lui passant en paramètre le répertoire /stand. hello2 retourne à Salt la valeur de retour de la fonction hello que nous avons appelé via le dict __salt__ qui donne un accès direct à cette dernière.

4. Transformation

Dans l'exemple précédent, vous aurez probablement remarqué qu'alors qu'on accède aux fonctions d’exécution via l'appel à cmd.<fonction>, le module se nomme en réalité cmdmod.py. Bien plus qu'un simple renommage, le module utilise ici une puissante fonctionnalité: les modules virtuels.

L'un des intérêts de l'orchestration réside dans la généricité des fonctions appelées, par exemple, il serait fastidieux d'appeler séparément apt.install, pkgin.install ou encore yum.install pour écrire nos recettes d'installation de paquets sur notre parc hétérogène. Au lieu de cela, nous appelons Salt de façon générique :

# salt ‘*’ pkg.install vim

Pourtant, les fonctionnalités d'installation de logiciels tiers sont belles et bien présentes dans plusieurs modules, aux noms distincts. Quelle est cette sorcellerie ? C'est ici la notion de module virtuel qui se charge d'appeler le bon backend pour installer le paquet. Par exemple, dans pkgin.py, j'ai ajouté :

def _check_pkgin():
‘’’
Looks to see if pkgin is present on the system, return full path
‘’’
return salt.utils.which(‘pkgin’)
def __virtual__():
‘’’
Set the virtual pkg module if the os is supported by pkgin
‘’’
supported = [‘NetBSD’, ‘SunOS’, ‘DragonFly’, ‘Minix’, ‘Darwin’]
if __grains__[‘os’] in supported and _check_pkgin():
return ‘pkg’
else:
return False

Ainsi, si le système d'exploitation est supporté par pkgin et que pkgin est accessible dans l'un des $PATH (salt.utils.which), nous informons Salt que ce module sera appelé via son nom virtuel pkg. Autre avantage de cette fonctionnalité, on évitera élégamment les conflits de nommage en créant son module Python avec un nom différent que celui par lequel il est invoqué, exactement comme cela est réalisé pour les fonctions cmd inscrites dans cmdmod.py.

5. Une dernière pincée

Quelques astuces supplémentaires permettront à vos futurs modules de passer la barrière du pull-up request, participation au projet rendue extrêmement simple grâce au site GitHub[1].

5.1 Les fonctions internes

Il n'est pas rare, dans tout type de projet, d'écrire des fonctions qui n'ont qu'une portée interne, dans notre cas, des fonctions qui ne seront pas exposées aux minions. Cela se réalise très simplement en préfixant le nom de la fonction par un underscore, par exemple :

Fonction chargée par le minion :

def foo():
return ‘bar’

Fonction non-chargée par le minion :

def _foo():
return ‘bar’

5.2 Do-cu-men-tez !

La méthode de documentation d'un module Salt n'est pas différente de celle employée pour un code Python classique. En renseignant proprement un docstring dans vos fonctions, ces dernières seront consultables par la commande Salt sys.doc :

def foo():
‘’’
This function returns the number of fooes.
CLI Example::
salt ‘*’ test.foo
‘’’

6. Quoi, vous êtes encore là ?

Accordez-moi que le développement de modules Salt brille par sa simplicité, mais également par sa souplesse et ses concepts inhérents. De plus, l'excellente lisibilité des modules présents dans l'installation de base vous permettra de vous mettre au travail rapidement. Le projet étant développé collaborativement sur GitHub, il est aisé de se faire une idée assez précise des structures et modèles utilisés. Enfin, le canal #salt sur le réseau IRC freenode est peuplé de nombreux développeurs du projet dont la sympathie et l'entrain ne gâchent rien au plaisir de participer à un tel projet.

7. Références

[1] https://github.com/saltstack/salt


Sur le même sujet

Crostini : débridez Chrome OS avec les applications Linux

Magazine
Marque
Linux Pratique
Numéro
120
|
Mois de parution
juillet 2020
|
Domaines
Résumé

Chrome OS est basé sur un système Linux (Gentoo), mais l'approche adoptée par Google est de limiter les possibilités de paramétrage et d'installation d'applications. Pour améliorer la polyvalence de son système sans remettre en cause son modèle sécuritaire, Google a, par la suite, introduit Crostini : une solution basée sur LXC pour que les utilisateurs de Chrome OS puissent travailler avec Linux dans un conteneur.

Analysez, diagnostiquez et dépannez votre système avec Sysdig

Magazine
Marque
Linux Pratique
HS n°
Numéro
47
|
Mois de parution
juillet 2020
|
Domaines
Résumé

Un système ne manque pas d’avoir des problèmes matériels, de plantage système, de performances, au niveau utilisateur ou noyau. Et malheureusement, les systèmes Linux ne sont pas exempts de ces problèmes à dépanner. Mais heureusement, Linux n’est pas en reste d’outils pour vous aider à diagnostiquer les problèmes. Des outils simples comme top pour surveiller l’usage CPU, ou ps pour les processus. Vous voulez tracer un appel système d’un processus : strace est votre ami. tcpdump, ou tshark vous aideront à inspecter le trafic réseau en ligne de commandes. Vous avez donc beaucoup d’outils à disposition, dans l’esprit « un outil précis pour une tâche unique », cher à Linux. Le problème c’est que lorsque l’on dépanne un système, on n’a pas le temps de se souvenir de tous les outils à disposition et taper toutes ces commandes en live. Outils qui ont chacun une philosophie différente, une interface d’entrée et de sortie différentes, ce qui peut poser soucis dans des situations stressantes et créer de la confusion lors d’occasions qui demandent de réagir dans l’urgence. Surtout que la plupart de ces outils ne sont pas pensés et optimisés pour être utilisés dans des conteneurs, plateformes de plus en plus utilisées et répandues.

Mettez en place une gestion efficace de vos journaux système avec Loki

Magazine
Marque
Linux Pratique
HS n°
Numéro
47
|
Mois de parution
juillet 2020
|
Domaines
Résumé

Bien avant les métriques et les graphiques de performances, les journaux système étaient la première source pour dépanner un système ou un service qui posait problème. Et ils le sont toujours : par défaut, sans aucune configuration, n’importe quel système Linux ou service journalise son activité et ses erreurs. Mais tout comme les métriques, si vous commencez à avoir à administrer plusieurs systèmes, la question se pose de centraliser ces journaux pour pouvoir les consulter simplement. Et quel stockage utiliser ? Des solutions, privées comme Splunk, ou libres comme Kibana sont déjà très populaires. Mais leur type de stockage (ElasticSearch pour Kibana), avec un indexage pour la recherche plein texte, prend beaucoup de place à l’utilisation et en sauvegarde, pour un intérêt limité dans la majorité des cas d’utilisation. Dans cet article, nous allons découvrir Loki, une solution toute récente, plus légère, pour gérer vos journaux.

Basez votre supervision sur des logs de qualité avec Rsyslog

Magazine
Marque
Linux Pratique
HS n°
Numéro
47
|
Mois de parution
juillet 2020
|
Domaines
Résumé

Les événements systèmes (aussi nommés logs dans la suite de l’article) sont des éléments déterminants pour la supervision du bon fonctionnement du système d’exploitation. Leur intérêt est souvent sous-coté aussi bien du point de vue maintenance du système que de sa sécurité. Cet article a pour ambition de poser les bases d’une bonne gestion des logs.

Neovim : dépoussiérez votre Vim

Magazine
Marque
Linux Pratique
HS n°
Numéro
47
|
Mois de parution
juillet 2020
|
Domaines
Résumé

Une application historique, puissante, populaire avec une base utilisateurs énorme, une compatibilité multiplateforme ultra-large, un code et une API quasi inmaintenables, dirigée par un Dictateur Bienveillant À Vie comme chef de projet et unique développeur : Vim présente toutes les caractéristiques d’un projet libre à succès. Et donc aussi tous les problèmes qui irritent ses utilisateurs et les contributeurs qui auraient le courage de participer à son développement. Dans cet article, nous allons découvrir Neovim, un fork de Vim né de la frustration d’utilisateurs de l’éditeur.

Par le même auteur

Amazon <3 Linux

Magazine
Marque
GNU/Linux Magazine
Numéro
207
|
Mois de parution
septembre 2017
|
Domaines
Résumé
Qui d'entre vous n'a jamais entendu parler de AWS (Amazon Web Services), LE cloud public qui domine le marché, la panacée du DevOps, le destructeur de toute une industrie, l'hébergeur qui soutient désormais un bon 40% du Web mondial ? Si tu réponds « moi » à cette question, tu devrais visiter autre chose que des sites en HTML v2 et cesser d’éditer tes fichiers de conf à la main.La triple pique d'entrée de jeu c'est gratos, ça me fait plaisir. AWS, c'est le rouleau compresseur, et cette position de leader n'est pas liée à la chance, puisque comme nombre de solutions disruptives, les analystes les plus pointus proféraient à son lancement que « ça marchera jamais » ©®™ ; non, le succès de ce cloud réside en grande partie dans son API, ses outils, le plus souvent libres, et la puissante communauté qui s'est construite autour. Ce que je vous propose dans cet article, c'est de faire connaissance avec ces outils, et en particulier l'AWS cli [1] basée sur boto3[2], tous les deux sous licence Apache 2[3].

Des bits comme s'il en pleuvait : une appliance SAN/NAS sous NetBSD

Magazine
Marque
GNU/Linux Magazine
Numéro
181
|
Mois de parution
avril 2015
|
Domaines
Résumé
À Noël, je suis le désespoir de ma famille. En effet, là où d'autres demandent des Blu-ray, de quoi s'habiller en hiver ou encore une nouvelle poêle à frire, moi je demande des composants. Des disques, des cartes, des trucs super pas excitants pour les personnes qui vous les offrent. Cette année, je voulais plus de place sur mon NAS [1], plein de bits pour y coller des documents à haute teneur multimédia.

NetBSD, le système du futur du subjonctif

Magazine
Marque
GNU/Linux Magazine
HS n°
Numéro
74
|
Mois de parution
septembre 2014
|
Domaines
Résumé
« The Original UNIX », c'est pour cette punchline que j'avais voté lorsque le groupe chargé du marketing chez NetBSD cherchait une approche différente du classique « of course it runs NetBSD » ; néanmoins, s'il est l'héritier le plus direct des travaux du CSRG [1] et l'un des plus grands défenseurs de la portabilité du code, le projet NetBSD n'est certainement pas un système d'exploitation du passé, loin s'en faut. Bénéficiant des avancées standards d'autres OS, NetBSD dispose en outre d'avantages uniques dont l'administrateur système aguerri saura faire usage. Dans cet article, nous allons monter un serveur web articulé autour de briques modernes, et allons dans notre périple découvrir l'ensemble des éléments nécessaires au déploiement d'un système aussi réactif que respectueux des standards.

Préface

Magazine
Marque
GNU/Linux Magazine
HS n°
Numéro
74
|
Mois de parution
septembre 2014
|
Résumé

Huit ans. Huit ans se sont écoulés depuis les deux derniers numéros hors-séries BSD et le mook que vous tenez entre les mains. Il y a huit ans, il est probable qu'une bonne partie d'entre vous n'avait même jamais touché un système UNIX/Linux, et réalisait plutôt son grand œuvre Lego(c)(tm).

Pendant ces huit années, le monde du Libre a proprement explosé, il est partout, omniprésent sur vos mobiles, vos tablettes, votre télé ou votre point d'accès Wi-Fi ; et si des sociétés telles que Google ne se cachent pas d'utiliser le système GNU/Linux comme socle entre l'espace utilisateur et le matériel, d'autres, sans totalement le masquer, ne font pas étalage des technologies libres constituant la pierre angulaire de leurs systèmes. En tête de liste notons particulièrement la société Apple, dont l'espace utilisateur du système d'exploitation Mac OS X est directement issu de FreeBSD.

Les différents BSD

Magazine
Marque
GNU/Linux Magazine
HS n°
Numéro
74
|
Mois de parution
septembre 2014
|
Domaines
Résumé

« Salut, je voudrais installer *BSD, vous me conseillez quoi ? »Cette phrase, lue et relue des centaines, des milliers de fois, est fondamentalement incorrecte. *BSD n'existe pas. Plus important, lorsque l'on souhaite mettre le pied à l'étrier d'un système BSD, un minimum de contexte est nécessaire, car chacun des héritiers de BSD UNIX suit une philosophie bien définie, et si chacun d'entre eux s'avère éminemment versatile, certains seront plus adaptés et faciles d'accès fonction de l'utilisation souhaitée. Nous allons ici faire connaissance avec les trois systèmes BSD les plus connus, NetBSD, FreeBSD et OpenBSD et évoquer leurs forces et faiblesses afin de guider votre choix de façon la plus objective possible.

Jouons un peu (plus) avec nginx

Magazine
Marque
GNU/Linux Magazine
Numéro
172
|
Mois de parution
juin 2014
|
Domaines
Résumé
Il existe pour le serveur web / proxy inverse nginx une foule de modules tierce partie, à ajouter au besoin, pas encore intégrés upstream mais pourtant de très bonne facture. Parmi les auteurs de ces modules, il en est un qui sort du lot par la quantité mais surtout la qualité de ses contributions, il s'agit de Yichun Zhang, plus connu sous son pseudo : agentzh.