Skip to content

ansible

ansible – sysctl module

The first version of my sysctl module for ansible have been merged to the devel tree of the mainstream ansible projet (on github) by mpdehaan.

You can now use easily this sysctl module :

  • by using git pull, if you have installed ansible by a simple git clone
  • by downloading manually sysctl in the library subdirectory of your playbooks :
cd /path/to/my/playbooks
[ -d "library" ] || mkdir -v library
wget https://raw.github.com/ansible/ansible/devel/library/sysctl -O library/sysctl
Ansible Servers Orchestration
Ansible is the easiest way to deploy, manage, and orchestrate computer systems you’ve ever seen. You can get started in minutes

After that, you can now use the sysctl module in your playbooks (extracted from the embedded documentation) :

  • Set vm.swappiness to 5 in /etc/sysctl.conf
    (first, check if /proc/sys/vm/swappiness file exist and is writteable, and after change, call sysctl -p and verify if /proc/sys/vm/swappiness file content is now 5) :
sysctl: name=vm.swappiness value=5 state=present
  • Remove kernel.panic entry from /etc/sysctl.conf
sysctl: name=kernel.panic state=absent sysctl_file=/etc/sysctl.conf
  • Set kernel.panic to 3 in /tmp/test_sysctl.conf, check if the sysctl key seems writable, but do not reload sysctl, and do not check kernel value after (not needed, because it is not the real /etc/sysctl.conf updated) :
sysctl: name=kernel.panic value=3 sysctl_file=/tmp/test_sysctl.conf check=before reload=no

Découverte d’ansible – Orchestration de serveurs

Bonjour !

Je viens de découvrir ansible, et j’ai décidé de tenter de l’utiliser, pendant quelques mois, pour mes besoins personnels et pour certains clients.

Pourquoi ansible au lieu de Opscode Chef  ou Puppet ou CFEngine pour gérer le parc de configuration, le déploiement de logiciels, et autres ?

Sincèrement je n’ai pas de raisons majeures à ce stade, je fais les choses au feeling, je n’ai pas assez d’expérience dans les alternatives citées pour les juger.

Ansible Servers Orchestration powerfull tools
Ansible Servers Orchestration powerfull tools

Par contre, voici les premiers plus qui m’ont attirés et qui m’ont menés là : (sans pour autant sous-entendre que les alternatives ne peuvent pas, dans certains cas, en faire autant)

  • une architecture reposant sur ssh, l’installation d’aucun agent sur chacun des nodes n’est nécessaire.
  • une architecture modulaire, dans laquelle un script bash, python, php, ou encore un binaire peuvent être utilisés de manière transparente.
  • un mode had-hoc, avec lequel je peux – par exemple – déployer en une seule ligne de commande, propager un nouveau réglage pour la conntrack sur un pool de 45 serveurs.
  • un mode playbook, avec lequel je modélise des configurations idempotentes partielles et/ou totales de serveurs que je peux ensuite appliquer sans avoir la nécessité d’être un développeur, le playbook ressemble plus à une documentation rédigé au format yaml plutôt qu’un script en ruby.
  • pas d’abstraction sur le système d’exploitation des nodes et de son gestionnaire de paquets ; et cela volontairement ; pourquoi ? la pluralité des OS fait que certaines distributions Linux par exemple, ont des particularités qui sont valorisables. Reposer sur un outil qui ne retiendrait que le plus petit dénominateur de chaque distribution serait une sorte de gaspillage.

Et donc ?

Le projet ansible est récent (environ 1 an) initié – entre autres – par Michael DeHaan (un développeur ayant un historique dans les outils d’orchestration/industrialisation)

Ansible est disponible sur GitHub, je l’ai forké pour pouvoir contribuer en développant le module sysctl en un premier temps, et pour le module emerge (gestionnaire de paquet de Gentoo) en un second temps.