Le Blog Utux

HTTP 200 GET /

Configuration et déploiement avec Ansible

Rédigé par uTux 5 commentaires

Ansible est un logiciel d'automatisation et de déploiement, il permet de créer des listes de tâches qui peuvent ensuite être jouées sur un ou plusieurs serveurs.

Attention cet article n'est pas un tutoriel (pour cela je vous renvoie vers la documentation officielle), mon but est de faire un petit retour d'expérience et montrer un exemple de projet Ansible.

Pourquoi Ansible ?

Il existe de nombreuses solutions de ce type mais il y a selon moi deux points qui distinguent Ansible : il est simple à prendre en main (excellente documentation et syntaxe yaml humainement lisible) et il ne nécessite pas d'agent pour fonctionner. En effet sur vos cibles, vous avez uniquement besoin de Python et SSH, présents en standard sur quasiment toutes les distributions Linux. Ansible marche aussi avec Windows et FreeBSD.

Pourquoi pas un script Bash / Perl / Python ?

Ben oui, il y a beaucoup de gens qui se sont fait leur propre script afin de configurer rapidement leur serveur. Mais en vrai les scripts c'est pas idéal :

  • C'est long à développer et ce n'est pas forcément votre métier.
  • Plus le script est complexe moins il sera lisible.
  • Le script doit être copié et exécuté à la main sur chaque serveur.
  • Il se contente d'exécuter une série de commandes sans se soucier du résultat.
  • Bon courage pour gérer un inventaire centralisé et des variables dynamiques.
  • Même en documentant votre script, vous serez le seul à comprendre réellement comment il marche.
  • Qui n'a jamais eu à déboguer un script obscur vieux de 10 ans ?

Ansible est beaucoup plus propre car depuis une unique machine vous gérez votre inventaire de serveurs et vos playbooks dans un même projet. Vous ne vous souciez que du résultat, vous ne demandez pas à ansible de faire un apt-get install curl, vous lui dites juste que le paquet curl doit être présent, à lui de faire en sorte de l'installer si besoin .Et c'est important non seulement car Ansible sait ce qu'il fait, mais il sait aussi le faire plusieurs fois, c'est ce qu'on appelle l'idempotence (sous réserve de ne pas faire n'importe quoi avec les playbooks, bien entendu). Enfin, il y a une énorme communauté d'utilisateurs et beaucoup de modules tiers, on trouve donc toujours des solutions aux problèmes

Exemple d'utilisation

Avertissement : Il y a plusieurs moyens de structurer un projet Ansible, consultez la page Best Practises. L'organisation que j'ai choisi n'engage que moi, vous êtes libre de faire autrement si ça colle mieux à vos besoins !

Voici un exemple de projet Ansible qui utilise un inventaire, des playbooks et des roles. Il sera utilisé pour configurer les nouveaux serveurs fraîchement installés. Objectifs :

  • Installer une liste de paquets de base
  • Configurer le /etc/hostname avec le nom du serveur
  • Configurer la locale fr_FR.UTF-8.
  • Configurer la timezone Europe/Paris.
  • Installer Nginx et Php-fpm sur les serveurs web
  • Tout en étant compatible Debian 8 & Ubuntu 16.04 (les paquets php n'ont pas le même nom !)

Arborescence du projet :

├── deploy-newserver.yml
├── group_vars
│   └── all
├── host_vars
│   ├── server01.example.org
│   └── web01.example.org
├── production.ini
└── roles
    ├── configure-newserver
    │   └── tasks
    │       └── main.yml
    │   └── templates
    │       └── hostname.j2
    ├── install-nginx
    |   └── tasks
    |       └── main.yml
    └── install-php-fpm
        └── tasks
            └── main.yml

Détail des fichiers :

---
# deploy-newserver.yml

- hosts: all
  roles:
    - configure-newserver

- hosts: webservers
  roles:
    - install-nginx
    - install-php-fpm
---
# group_vars/all
ansible_user: root
---
# host_vars/server01.example.org

ansible_host: 172.16.42.190
---
# host_vars/web01.example.org

ansible_host: 172.16.42.180
# production.ini
server01.example.org

[webservers]
web01.example.org
---
# roles/configure-newserver/tasks/main.yml

  - name: set hostname (volatile)
    hostname:
      name: '{{ inventory_hostname }}'

  - name: set hostname (permanent)
    template:
      src: hostname.j2
      dest: /etc/hostname
      force: yes

  - name: generate locales
    locale_gen:
      name: '{{ locale }}'
      state: present
    with_items:
      - en_EN.UTF-8
      - fr_FR.UTF-8

  - name: set default locale
    lineinfile:
      dest: /etc/default/locale
      regexp: '^LANG=.*$'
      line: 'LANG=fr_FR.UTF-8'
      create: yes
      state: present

  - name: set timezone
    file:
      src: /usr/share/zoneinfo/Europe/Paris
      dest: /etc/localtime
      force: yes
      state: link

  - name: common packages
    apt:
      name: "{{ item }}"
      state: present
    with_items:
      - apt-transport-https
      - bsd-mailx
      - ca-certificates
      - htop
      - manpages
      - net-tools
      - openssl
      - pciutils
      - postfix
      - ntp
      - ntpdate
      - rsync
      - tree
      - tzdata
      - ufw
      - unzip
      - vim
# roles/configure-newserver/templates/hostname.j2
{{ inventory_hostname }}
---
# roles/install-nginx/tasks/main.yml

  - name: install
    apt:
      name: nginx
      state: present
---
# roles/install-php-fpm/tasks/main.yml

  - name: php5-fpm if Debian <= 8
    apt:
      name: '{{ item }}'
      state: present
    with_items:
      - php5-fpm
      - php5-gd
    when:
      - ansible_distribution == "Debian" and ansible_distribution_major_version <= '8'

  - name: php7.0-fpm if Ubuntu => 16
    apt:
      name: '{{ item }}'
      state: present
    with_items:
      - php7.0-fpm
      - php7.0-xml
      - php7.0-gd
    when:
      - ansible_distribution == "Ubuntu" and ansible_distribution_major_version >= '16'

Lancer en dry-run (ne modifie rien) :

$ ansible-playbook -i production.ini deploy-newserver.yml --check

Lancer le déploiement :

$ ansible-playbook -i production.ini deploy-newserver.yml

Lancer le déploiement sur web01.example.org uniquement :

$ ansible-playbook -i production.ini deploy-newserver.yml --limit web01.example.org

Et voilà.

Exécution du playbook.

Ansible et moi

J'utilise régulièrement Ansible et maintient des playbooks pour des projets persos et pro, et j'en suis très satisfait. La documentation m'a permis d'être autonome et à l'aise assez vite et m'a même poussé à automatiser plus de choses que nécessaire, comme le déploiement de sites web alors que je pensais me limiter à la stack nginx / php-fpm / letsencrypt.

Même si je suis pleinement convaincu et satisfait par Ansible, je rencontre quand même certaines limitations. Par exemple l'inventaire n'est pas idéal quand on a beaucoup de serveurs et de groupes, ça peut rapidement devenir illisible. Il y a aussi certains modules tels que authorized_key pour lesquels j'aimerai plus de fonctionnalités, en l’occurrence pouvoir utiliser le paramètre 'exclusive' avec plusieurs clés.

Petits conseils en vrac

  • Ansible évolue vite, utilisez une version récente, disponible dans les backports debian ou via pip.
  • Le state: present est souvent implicite, vous n'avez donc pas besoin de le mettre, cependant c'est mieux de le faire, pour rendre le playbook plus évident à comprendre.
  • Pensez à utiliser les variables, pour les URLs ou les numéros de version.
  • Ne mettez pas de mot de passe ou de credential dans les playbooks, utilisez des variables passées au moment de l'exécution, ou dans un fichier que vous prendrez soin d'exclure si vous utilisez un repo public.
  • Faites un dry-run pour tester vos playbooks, on ne sait jamais.
  • Attention au module file et plus particulièrement aux permissions, surtout quand vous travaillez sur des fichiers existants (tels que le resolv.conf).
  • La commande ansible hostname -m setup vous permet de récupérer tous les 'facts' (OS, version, ip...) d'une cible, ils peuvent être utilisés dans les playbooks.
  • Testez vos playbooks jusqu'au bout : redémarrez le serveur pour vérifier que les modifications ne sont pas volatiles.
  • Faites des choses propres et simples. Si vos besoins sont trop variés ou spécifiques, n'utilisez pas Ansible, ou limitez vous au minimum.
  • La machine sur laquelle vous exécutez Ansible est critique, car en général vous aurez l'accès root without-password à tous vos serveurs, c'est donc un point d'entrée que vous devez sécuriser au maximum.

Conclusion

Si vous souhaitez unifier, accélérer et automatiser vos déploiements ou tout simplement vous initier au devops, Ansible est un outil que je recommande fortement, l'essayer c'est l'adopter.

systemd, c'est bien.

Rédigé par uTux 22 commentaires

Systemd est un système d'init "moderne" qui remplace le vieillissant sysvinit. L'init c'est le premier process qui démarre après le boot et qui va "orchestrer" le lancement des services : réseau, logs, ssh ... Mais wikipedia explique cela mieux que moi.

Dire que systemd a provoqué de nombreuses polémiques et levées de boucliers de la part des utilisateurs est un euphémisme, c'est un beau bazar dans lequel des troll s'affrontent au lance-flammes. On lui reproche de nombreuses choses : réinventer l'eau chaude alors que sysvinit marche bien, être monolithique et donc contraire à la philosophie UNIX, être le cheval de troie de Red Hat pour à terme remplacer de plus en plus de composants dans Linux, ne pas être portable sur les autres OS, etc. Je pense que la plupart des critiques sont vraies et que dans quelques années nos distributions ne seront plus GNU/Linux mais SystemD/Linux. Néanmoins il est intéressant d'observer qu'après 6 ans d'existence, systemd s'est imposé partout à l'exception de Gentoo (+et Slackware) et ce n'est pas par hasard.

Je ne vais pas énumérer point par point les fonctionnalités de systemd, je vais me contenter d'en présenter deux aspects que je trouve intéressants : création d'un service et d'un containers (nspawn).

Création d'un service

Avez-vous déjà écrit des scripts d'init pour un logiciel sur Linux ? Moi oui. Et entre sysvinit et systemd, c'est le jour et la nuit. Prenons pour exemple Nginx :

C'est quand même beaucoup plus simple avec systemd puisqu'une grosse partie du boulot est faite nativement, par exemple la gestion du pid et des logs. Pour sysvinit par contre c'est au développeur du script de prévoir tous les cas, de coder la vérification du pid, des logs, bref c'est long et pas forcément utile puisque même sur Windows on ne fait plus ça depuis 20 ans.

Création d'un container

Systemd est très lié à Linux et aux cgroups, il est possible d'isoler des processus dans leur propre contexte, de là à créer des containers avec une application ou un système entier il n'y a donc qu'un pas qui a été franchit. Pour l'exemple on va créer un container ubuntu-server-16.04 à partir d'une image cloud (pour nous épargner les étapes debootstrap qui n'ont pas vraiment d'intérêt dans cet article) :

root@localhost:~# wget https://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64-root.tar.gz
root@localhost:~# mkdir /srv/containers/xenial01
root@localhost:~# tar -xf xenial-server-cloudimg-amd64-root.tar.gz -C /srv/containers/xenial01

Note : sur les versions plus récentes de systemd (non disponible sur Debian Jessie), l'utilitaire machinectl permet de télécharger et déployer une image automatiquement. Voir la section Examples de la documentation machinectl.

Puis démarrer un shell dans le container afin de pouvoir créer un mot de passe root :

root@localhost:~# systemd-nspawn -D /srv/containers/xenial01/
Spawning container xenial01 on /srv/containers/xenial01.
Press ^] three times within 1s to kill container.
/etc/localtime is not a symlink, not updating container timezone.
root@xenial01:~# passwd
Enter new UNIX password: 
Retype new UNIX password: 
passwd: password updated successfully
root@xenial01:~# exit

Maintenant on peut - si on veut - démarrer complètement le container :

root@localhost:~# systemd-nspawn -bD /srv/containers/xenial01/
Spawning container xenial01 on /srv/containers/xenial01.
Press ^] three times within 1s to kill container.
/etc/localtime is not a symlink, not updating container timezone.
systemd 229 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR
+SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ 
-LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN)
Detected virtualization systemd-nspawn.
Detected architecture x86-64.

Welcome to Ubuntu 16.04 LTS!

Ensuite la séquence de démarrage s'affiche et il est possible de se loguer, puis d'arrêter le container avec la commande poweroff :

Ubuntu 16.04 LTS ubuntu console

ubuntu login: root
Password: 
Last login: Mon May 23 09:12:29 UTC 2016 on console
run-parts: /etc/update-motd.d/98-fsck-at-reboot exited with return code 1
root@ubuntu:~# poweroff

Si on ne spécifie aucune option au niveau du réseau, le container utilisera l'interface de l'hôte. Attention donc aux services qui écoutent sur les mêmes ports, typiquement SSH, le mieux est encore d'utiliser une interface réseau virtuelle. Je ne rentre volontairement pas dans les détails afin de ne pas faire un article indigeste, mais il est possible d'aller plus loin notamment au niveau des interfaces réseau (bridge, macvlan, veth), des limitations du système (mémoire, cpus...) ou encore de l'intégration avec SELinux. On peut aussi utiliser debootstrap, dnf ou pacstrap pour créer un container (pas besoin d'une image cloud). Pour cela voir la documentation systemd-nspawn et systemd.resource-control (elles ne sont pas si indigestes que ça).

Systemd-nspawn est une alternative intéressante à LXC permettant de gérer des containers thin (on lance uniquement une application) ou thick (on lance tous les services) sans avoir à installer quoi que ce soit.

BONUS : sous debian, ça ne change rien pour les utilisateurs

Si je peux comprendre que beaucoup de gens n'aiment pas systemd et ne souhaitent pas l'utiliser, en revanche je ne comprends pas pourquoi cette grogne est focalisée chez les utilisateurs de debian au point de créer le fork devuan. Parce que si vous êtes utilisateur de debian, systemd ne change rien pour vous. Tout d'abord le boulot est fait par les mainteneurs des paquets, vous n'avez jamais touché à un système d'init de votre vie, et avec systemd vous n'y toucherez pas non plus. Ensuite, si vous faites un peu de sysadmin, là encore rien ne change pour la majorité des opérations.

Voici pour comparer la manière dont on démarre apache :

root@localhost:~# service apache2 start # avec sysvinit
root@localhost:~# service apache2 start # avec systemd

C'est pareil, parce que debian est une distribution pour fainéants (comme moi) très bien foutue. Même chose pour le réseau, ça se gère toujours dans /etc/network/interfaces rien ne change.

Sous Archlinux par contre tout change par exemple le fichier /etc/rc.conf a disparu au profil de fichiers éclatés pris en charge par systemd. Ce n'est pas méchant mais il a fallu réapprendre certaines choses. Malgré une grogne passagère la chose semble avoir bien été acceptée par les utilisateurs, en tous cas ils ne sont pas partis forker leur distribution.

Conclusion

Au final, après avoir lu tant de troll, tant de FUD sur systemd, je trouve que c'est plutôt bien. C'est simple à utiliser et c'est puissant puisqu'on peut imaginer un jour remplacer LXC et cela ouvre plein de possibilités au niveau des serveurs, par exemple avoir des instances apache et nginx isolées dans les containers thin, ou encore des applications portables à la manière de Snap ou xdg-app. Pour 99% des utilisateurs de Linux la transition est transparente puisque prise en charge en amont par les mainteneurs.

Je prends donc le risque d'invoquer une armée de troll dans les commentaires mais moi j'approuve systemd.

HTML5 : la propriété <figure> c'est super !

Rédigé par uTux 2 commentaires

J'ai fait beaucoup de CSS de 2008 à 2010, j'étais capable de coder un thème dotclear ou pluxml de A à Z avec un simple éditeur de texte. Mais les choses ont beaucoup changé aujourd'hui, HTML5 est arrivé ainsi que le responsive design et javascript qui prennent une place de plus en plus importante. Donc je suis non seulement rouillé mais en plus totalement à la ramasse par rapport au code moderne.

C'est la raison pour laquelle je me suis contenté de légèrement modifier le thème de base Pluxml au lieu d'en refaire un entier. Rien de bien fracassant puisque je me suis contenté d'ajouter un fichier "local.css" invoqué dans le header afin de modifier certains éléments notamment les couleurs et les polices.

En cherchant comment gérer une image + sa légende dans un article j'ai découvert <figure>. Cette propriété HTML5 évite de devoir créer inutilement des <div> et se révèle plus élégante :

<figure>
    <img src="https://utux.fr/data/medias/0005/orage.jpg" alt="" />
    <figcaption>Orage à Nantes (août 2015)</figcaption>.
</figure>

Lisible non ? Plus d'infos chez alsacréations. ou w3schools. Je ne détaille pas la partie CSS car ce serait un peu lourd, mais si ça vous intéresse vous pouvez jeter un œil dans le local.css. En attendant voici le résultat :

Orage à Nantes (août 2015)

Image extraite d'une vidéo prise avec un Lumia 735 il y a quelques temps. La tour que l'on voit entre les grues à gauche et l'éclair est bien sûr la Tour Bretagne.

Fil RSS des articles de cette catégorie