Le Blog Utux

HTTP 200 GET /

Ansible bonnes pratiques - Ep2

Rédigé par uTux Aucun commentaire

Dans l'article Configuration et déploiement avec Ansible je livrais déjà quelques conseils issus de mon expérience. J'ai eu la chance de continuer à travailler sur cette technologie en entreprise et je livre donc les compléments suivants:

  • L'idempotence est importante, c'est à dire la capacité à rejouer le même rôle une seconde fois. Si votre playbook doit créer un utilisateur (Unix ou mysql), pensez à ce qui peut se passer au bout de 6 mois. Imaginez qu'entre temps un collègue a changé le mot de passe root de Mysql et ne l'a pas mis à jour dans Ansible. Si vous rejouez le rôle, il sera écrasé et votre prod pourra potentiellement tomber. Pour cela restez à l'affut des options des modules, par exemple pour mysql_user on a update_password: on_create (on ne change le mot de passe que lors de la création du user, on y touche pas s'il existe déjà). C'est pareil avec le module user, si vous mettez le groupe "sudo", l'utilisateur sera mis dans ce groupe et retiré des autres! A moins d'utiliser l'option append: yes. Idempotence et anticipation!
  • La documentation et le guide des bonnes pratiques de Ansible recommandent de faire des playbook webservers.yml, dbservers.yml, etc. Mais en pratique il est parfois plus approprié d'avoir 1 playbook par serveur (srv-web-01.yml, srv-web-02.yml, etc). Car dans la réalité de la production on a pas toujours la même chose sur les serveurs.
  • Évitez d'éparpiller vos variables partout. Mettez-les dans le .yml du serveur si possible, puis dans le group_vars/groupe et c'est tout. Évitez les host_vars ou encore les roles/truc/vars car cela peut rapidement devenir un enfer de retrouver où sont définies les variables. Parfois il vaut mieux faire moins optimisé mais plus lisible.
  • Ne faites pas trop de groupes, car l'inventaire de base (constitué d'un fichier) peut rapidement devenir impossible à maintenir. On peut être tenté de faire des groupes par location géographique, par type d'environnement, par type d'applicatif, mais il sera alors chargé et illisible ce qui entrainera des erreurs dans les playbook (oubli de certains serveurs).
  • Soyez verbeux, utilisez le module debug pour afficher des informations. Pour les opérations sensibles utilisez le module pause permettant de valider l'exécution d'une opération, exemple: "Installation de Gluster 3.5.2-4 sur Debian Jessie, infra Paris. Enter pour valider ou CTRL+C pour annuler" (un cluster constitué de différentes versions de Gluster peut crasher, d'où l'intérêt de bien vérifier les versions).
  • Documentez clairement, faites des README dans chaque rôle expliquant leur utilité.
  • Faites des templates pour que vos collègues/successeurs aient des exemples de playbook utilisant vos rôles.

A l'année prochaine pour l'Ep3...

Ansible vault

Rédigé par uTux Aucun commentaire

Ansible vault permet de stocker de manière chiffrée certaines informations, par exemple des variables utilisables dans vos playbooks.

Exemple d'information sensible lisible dans un playbook (sans vault):

---
- hosts: localhost
  remote_user: root
  tasks:
    - name: ensure 'utux' user exists
      user:
        name: utux
        append: yes
        groups: sudo
        shell: /bin/bash
        password: "{{ utux_passwd }}"
        generate_ssh_key: yes
        state: present
  vars:
    utux_passwd: "{{ 'secret' | password_hash('sha256') }}"

C'est lisible mais le mot de passe ('secret') se promène en clair, ce qui n'est pas top surtout si vous stockez votre projet sur un dépôt. La solution est d'utiliser ansible vault pour stocker dans un fichier sécurisé le mot de passe.

Création d'un vault:

$ mkdir -p group_vars/all
$ ansible-vault --ask-vault-pass create group_vars/all/vault

On y met une variable contenant notre mot de passe:

vault_utux_passwd: "{{ 'secret' | password_hash('sha256') }}"

Comme on peut le voir, notre fichier est bien chiffré:

$ cat group_vars/all/vault 
$ANSIBLE_VAULT;1.1;AES256
66623865616561613766343831613161343936636563373530643933323037333363363139666235
6135616635313332626637636466666236346365373037620a356436363133343161636239313133
36343539626564316431323135626533366462306631323761633330623231386434613734653934
3263383130386164620a663561363238303035336631326437643337646430653139643939363039
62663533626261373863323137316562643038613737333139303536623162633931

Et si on veut l'éditer:

$ ansible-vault --ask-vault-pass edit group_vars/all/vault

On adapte notre playbook:

---
- hosts: localhost
  remote_user: root
  tasks:
    - name: ensure 'utux' user exists
      user:
        name: utux
        append: yes
        groups: sudo
        shell: /bin/bash
        password: "{{ utux_passwd }}"
        generate_ssh_key: yes
        state: present
  vars:
    utux_passwd: "{{ vault_utux_passwd }}"

On exécute notre playbook:

ansible-playbook myuser.yml --ask-vault-pass

Ça marche, mais c'est un peu lourd car il faut taper le mot de passe vault à chaque exécution du playbook. Heureusement on peut le définir dans un fichier. On prendra soin de faire un gitignore pour ce fichier, voire même le placer dans un autre dossier:

$ echo "motdepassevault" > vault_passwd
$ echo "vault_passwd" >> .gitignore

On doit ensuite spécifier à Ansible où trouver ce fichier. Vous pouvez le définir au niveau du /etc/ansible/ansible.cfg ou dans le ansible.cfg local du projet (ce que je préfère faire, ainsi il est commité dans le dépôt et tout le monde a la bonne version):

# ansible.cfg
[defaults]
vault_password_file = vault_passwd

Vous devriez maintenant pouvoir exécuter votre playbook sans le --ask-vault-pass.

Le blog sous Docker (le retour)

Rédigé par uTux 6 commentaires

Juste un petit billet pour indiquer que le blog tourne à nouveau sous Docker. Cette fois-ci je n'utilise plus un unique container apache, mais 3 containers orchestrés par docker-compose :

Et il y a toujours un nginx "en dur" en frontal qui fait reverse proxy et centralise les logs.

logo docker

Le serveur est désormais un Scaleway VC1S aux pays-bas sur lequel tourne une distribution Debian Stretch. Pour les containers j'ai choisi d'utiliser au maximum des images alpine en raison de leur légèreté et de la simplicité du système. Et pour le moment, ça marche plutôt bien.

J'ai essayé d'utiliser un serveur ARM Scaleway, mais outre le fait qu'il est compliqué d'installer Docker (il faut utiliser Ubuntu-server ou alors compiler) les images du Dockerhub ne semblent pas disponibles pour cette architecture. Je me suis donc rabattu sur un VC1S qui n'est rien d'autre qu'une machine virtuelle x86_64.

NixOS : la distribution déclarative

Rédigé par uTux Aucun commentaire

Si vous êtes familier avec l'écosystème des distributions Linux, vous avez probablement levé un sourcil (comme Teal'c) en lisant ce titre car vous les connaissez toutes, vous avez touché à tous les gestionnaires de paquet, vous avez utilisé debian et gentoo, en bref vous avez fait le tour et plus rien ne nous surprend.

Et pourtant, bien que NixOS soit une distribution assez ancienne (2003) elle dispose de nombreux atouts inédits passés plutôt inaperçus jusqu'à présent.

NixOS logo

La configuration déclarative centralisée

Ce que je trouve le plus intéressant dans NixOS, c'est la configuration centralisée dans un unique fichier. En effet si vous avez déjà travaillé sur des routeurs ou diverses appliances, vous avez remarqué que l'on peut souvent importer et exporter la configuration sous forme de texte assez facilement, cela rend la maintenance très facile. Sous NixOS c'est le même principe, mais en plus puissant puisqu'on peut rollback voire booter sur une ancienne configuration depuis grub. Exemple de configuration d'un serveur MariaDB :

/etc/nixos/configuration.nix

{ config, pkgs, ... }:

{
  imports =
    [ # Include the results of the hardware scan.
      ./hardware-configuration.nix
    ];

  # Use the systemd-boot EFI boot loader.
  boot.loader.systemd-boot.enable = true;
  boot.loader.efi.canTouchEfiVariables = true;

  networking = {
    hostName = "mariadb";
    nameservers = [ "192.168.0.31" ];
    defaultGateway = "192.168.0.254";
    interfaces.enp0s3.ip4 = [
      {
        address = "192.168.0.41";
        prefixLength = 24;
      }
    ];
  };

  # Select internationalisation properties.
  i18n = {
    consoleFont = "Lat2-Terminus16";
    consoleKeyMap = "fr";
    defaultLocale = "fr_FR.UTF-8";
  };

  # Set your time zone.
  time.timeZone = "Europe/Paris";

  # List packages installed in system profile. To search by name, run:
  # $ nix-env -qaP | grep wget
  environment.systemPackages = with pkgs; [
    git
    htop
    sudo
    tree
    vim
  ];

  # Services
  services = {
    openssh = {
      enable = true;
      permitRootLogin = "yes";
    };
    mysql = {
      enable = true;
      package = pkgs.mysql;
      extraOptions = ''bind-address=0.0.0.0'';
    };
  };

  # Open ports in the firewall.
  networking.firewall.allowedTCPPorts = [ 22 3306 ];
  # networking.firewall.allowedUDPPorts = [ ... ];

  # Define a user account. Don't forget to set a password with ‘passwd’.
  users.extraUsers = {
    utux = {
      isNormalUser = true;
      extraGroups = [ "wheel" ];
    };
  };

  # The NixOS release to be compatible with for stateful data such as databases.
  system.stateVersion = "17.03";

}

/etc/nixos/hardware-configuration.nix

# Do not modify this file!  It was generated by ‘nixos-generate-config’
# and may be overwritten by future invocations.  Please make changes
# to /etc/nixos/configuration.nix instead.
{ config, lib, pkgs, ... }:

{
  imports = [ ];

  boot.initrd.availableKernelModules = [ "virtio_pci" "ahci" "xhci_pci" "sr_mod" "virtio_blk" ];
  boot.kernelModules = [ ];
  boot.extraModulePackages = [ ];

  fileSystems."/" =
    { device = "/dev/disk/by-uuid/78634ba0-11d1-4f91-85ae-ac2ee247c387";
      fsType = "xfs";
    };

  fileSystems."/boot" =
    { device = "/dev/disk/by-uuid/019A-1A05";
      fsType = "vfat";
    };

  swapDevices =
    [ { device = "/dev/disk/by-uuid/075a27eb-5656-4b57-b186-73a6d86e5e5c"; }
    ];

  nix.maxJobs = lib.mkDefault 1;
}

Comme vous le voyez, le fichier configuration.nix contient toute la configuration, incluant les services tiers tels que mariadb dans notre cas. Cela va donc encore plus loin que le /etc/rc.conf sur FreeBSD/NetBSD/OpenBSD qui centralise déjà pas mal de choses. Le fichier hardware-configuration.nix lui est généré automatiquement il n'y a pas besoin d'y toucher et il est plus ou moins unique par serveur.

Pour générer et appliquer la configuration :

nixos-rebuild switch

Pour mettre à jour le système :

nixos-rebuild switch --upgrade

Puis un petit mysql_secure_installation la première fois pour préparer notre SGBD.

Ce qu'il reste à faire en dehors du configuration.nix, c'est la définition des mots de passe, avec passwd et bien sûr la gestion des données persistantes (les bases de données pour mariadb par exemple).

Nix, gestionnaire de paquets fonctionnel

Je vais être un peu plus prudent sur ce point, car étant encore en phase de découverte de NixOS, je ne connais pas encore très bien le gestionnaire de paquets Nix. Cependant, à la différence des gestionnaires classiques tels que apt, yum ou pacman, il ne se contente pas d'aller chercher des paquets pour les décompresser. Chaque version de chaque paquet est installé dans une arborescence /nix/store/{identifiant unique}, du coup plusieurs versions peuvent cohabiter ensemble et les mises à jour n'écrasent rien. Il est possible également pour les utilisateurs d'installer des paquets pour leur environnement (non-root) uniquement.

Mon avis

J'ai mis un serveur NixOS en test et il est trop tôt pour en tirer des conclusions. Mais j'aime l'idée de configuration centralisée déclarative, car la configuration classique des systèmes Linux n'est pas toujours simple à maintenir : Docker, Ansible, NixOS : le savoir (re)faire.

Si je dois citer deux inconvénients à NixOS : elle prend de la place (1,6GB à l'installation avec MariaDB) et elle nécessite au moins 1GB de RAM pour s'installer sous peine de voir oomkiller tuer nixos-install... elle peut cependant tourner avec 256MB par la suite.

NixOS nous montre qu'une distribution Linux ce n'est pas seulement un éinième fork de Ubuntu avec un wallpaper personalisé, ou encore une guerre de gestionnaire de paquets (dnf/apt), il existe encore de l'innovation et rien que pour cela elle mérite le coup d’œil.

Docker-compose et le COMPOSE_PROJECT_NAME

Rédigé par uTux 2 commentaires

Docker-compose est un outil permettant d'utiliser docker à l'aide d'un simple fichier .yml, facilitant ainsi grandement la vie et les interactions entre les containers d'un même service. Mais il n'est pas exempt de bugs ou de défauts de conception.

Le défaut dont je vais parler concerne le nommage des containers. Prenons par exemple deux projets docker : projet1 et projet2 avec l'arborescence suivante :

.
├── projet1
│   └── src
│       └── docker-compose.yml
└── projet2
    └── src
        └── docker-compose.yml

Nos docker-compose.yml sont identiques et commandent le lancement d'un simple container nginx :

# projet1/src/docker-compose.yml
version: '3'
services:

  nginx:
    image:
        nginx:latest

Et :

# projet2/src/docker-compose.yml
version: '3'
services:

  nginx:
    image:
        nginx:latest

Voyons ce qui arrive lorsque je démarre mon projet1 :

utux@docker:~/projet1/src$ docker-compose up -d
Creating src_nginx_1 ... 
Creating src_nginx_1 ... done

On voit que notre container a été nommé src_nginx_1 suivant la logique suivante : $dossier_$service_$numero. Très bien. Démarrons maintenant le projet2 :

utux@docker:~/projet2/src$ docker-compose up -d
src_nginx_1 is up-to-date

docker-compose dit que le container existe déjà alors que non ! En fait il applique le même raisonnement et veut nommer le container src_nginx_1 aussi alors qu'il existe déjà ! C'est un défaut de conception et c'est problématique car en cas de modification sur l'un des projets, docker-compose va recréer les containers, et donc écraser ceux de l'autre...

Pour palier à ce problème, plusieurs solutions sont possibles :

  • Nommer différemment votre dossier de travail. Ce n'est pas toujours possible car on peut avoir un environnement de dev et un environnement de prod avec les mêmes chemins.
  • Utiliser l'attribut container_name mais c'est un peu fastidieux car il faut le faire sur tous les services du docker-compose.yml
  • Utiliser la variable d'environnement COMPOSE_PROJECT_NAME. Malheureusement on ne peut pas la définir dans le docker-compose.yml malgré les demandes répétées des utilisateurs (ici et ) il faut la mettre dans un fichier .env dans votre projet.

Exemple d'utilisation du COMPOSE_PROJECT_NAME :

.
├── projet1
│   └── src
│       ├── docker-compose.yml
│       └── .env
└── projet2
    └── src
        ├── docker-compose.yml
        └── .env

Avec nos fichiers .env :

# projet1/src/.env
COMPOSE_PROJECT_NAME=projet1

Et :

# projet2/src/.env
COMPOSE_PROJECT_NAME=projet2

Démarrons maintenant notre projet1 puis notre projet2 :

utux@docker:~$ cd projet1/src/
utux@docker:~/projet1/src$ docker-compose up -d
Creating network "projet1_default" with the default driver
Creating projet1_nginx_1 ... 
Creating projet1_nginx_1 ... done
utux@docker:~/projet1/src$ cd ../../projet2/src/
utux@docker:~/projet2/src$ docker-compose up -d
Creating network "projet2_default" with the default driver
Creating projet2_nginx_1 ... 
Creating projet2_nginx_1 ... done

Cette fois les deux projets cohabitent bien et ne se marchent plus sur les pieds. La preuve :

utux@docker:~/projet2/src$ docker ps
CONTAINER ID        IMAGE                            COMMAND                  CREATED             STATUS              PORTS                    NAMES
eacabeb7e961        nginx:latest                     "nginx -g 'daemon ..."   4 seconds ago       Up 2 seconds        80/tcp                   projet2_nginx_1
9477b31d2035        nginx:latest                     "nginx -g 'daemon ..."   16 seconds ago      Up 14 seconds       80/tcp                   projet1_nginx_1

En conclusion il ne faut pas avoir une confiance aveugle en docker-compose, qui est un outil bien pratique mais manifestement sujet à des défauts de conception. Imaginez ce genre de confusion de nommage, voire d'écrasement de containers en production. Utilisez COMPOSE_PROJECT_NAME et testez vos projets en pré-production avant de déployer sur la prod.

Fil RSS des articles de cette catégorie