ansible.md

Ansible

Nous voilà enfin sur la dernière partie de cet atelier, premièrement merci à celles et ceux qui sont restés jusqu'ici. Pour cette dernière étape nous allons découvrir ansible.

Ansible est une plateforme open-source de gestion de configuration et d'automatisation des déploiements. Grâce à sa simplicité et à son approche basée sur YAML, Ansible permet de provisionner, de configurer et de déployer des infrastructures informatiques de manière efficace et reproductible, facilitant ainsi la gestion des environnements informatique à grande échelle. Pendant cet atelier nous allons voir comment utiliser cet outil pour automatiser l'installation de notre environnement de travail.

Pré-requis

Pour commencer cet atelier, il faut avoir copier le dossier AtelierDP :

cd /
cd sgroinfre/cassie
cp -R sgoinfre/cassie/AtelierDP ~/sgoinfre/

Ansible

Pour installer ansible la doc

Sur un dotfile quelque part dans l'internet, avec seulement cette commande quelqu'un peut installer son environnement de travail.

ansible-playbook --ask-become-pass bootstrap.yml

Qu'est-ce que bootstrap.yml ? En voici un exemple :

- name: Bootstrap development environment
  hosts: localhost

  tasks:
  - name: Install packages with apt
    become: yes
    ansible.builtin.apt:
      name:
        - git
        - tmux
      state: present

Playbook

En terminologie Ansible le fichier bootstrap.yml est appelé playbook. Les playbooks sont écrits en YAML.

Un playbook peut contenir plusieurs play / pièces et dans une pièce / play plusieurs tasks / tâches. Dans l'exemple ci-dessus le playbook possède une play avec une task : "Install packages with apt"

Host & Inventory

Ansible peut exécuter des tâches / tasks en remote ou en local. Pendant cet atelier on va se focus sur la partie local.

- name: Bootstrap development environment
  hosts: localhost

Par défaut ansible définit host en local, il ne sera pas nécessaire pour cet atelier.

Tasks

On va se focus sur les différentes parties des tasks.

  tasks:
  - name: Install packages with apt
    become: yes
    ansible.builtin.apt:
      name:
        - git
        - tmux
      state: present

Become

Permet de become un autre utilisateur pendant que l'on fait cette task. L'utilsateur par défaut étant root. Cela revient à utiliser sudo pour cette task. Et enfin c'est pour cela que dans la commande ci-dessus on utilise l'option --ask-become-pass (ou -K).

Modules

ansible.builtin.apt est un module de Ansible, ansible possède plusieurs modules built-ini (liste). Il existe des modules pour la majorité des gestionnaires de packets des différentes distro linux. Aussi il y a des modules communautaires par exemple pour Homebrew pour macos.

Un module Ansible a besoin d'arguments pour accomplir sa task. Par exemple dans le cas ci-dessous on peut donner une liste de packets dans name et le state desire.

  tasks:
  - name: Install packages with apt
    become: yes
    ansible.builtin.apt:
      name:
        - git
        - tmux
      state: present # peut être aussi 'latest' or 'absent'

Idempotence

Les playbooks de Ansible sont faits pour être idempotent, qu'importe le nombre de fois où vous les lancez, la machine finira dans le même état.

Facts and conditionals

Imaginons maintenant que j'utilise macOS et Ubuntu. On ne peut pas utiliser pour des deux apt.. On peut donc utiliser des conditions à nos tasks.

  tasks:
  - name: Install packages with apt
    become: yes
    ansible.builtin.apt:
      name:
        - git
        - tmux
      state: present
    when: ansible_distribution == "Ubuntu"

  tasks:
  - name: Install packages with brew
    become: yes
    community.general.homebew:
      name:
        - git
        - tmux
      state: present
    when: ansible_distribution == "MacOSX"

La task ne sera effectuée que si la condition when est true.

Ansible Galaxy

Ci-dessus le module community.general.homebrew n'est pas built-in. Pour l'installer vous devez utiliser Ansible Galaxy

$ ansible-galaxy collection install community.general

Rôles

Les rôles dans Ansible sont une manière d'organiser vos tasks. C'est aussi le format utilisé par les tasks d'autres personnes.

Exemple :

ansible-galaxy role install gantsign.visual-studio-code

Il est possible de customizer des rôles.

    - role: gantsign.visual-studio-code
      users:
        - username: something
          visual_studio_code_extensions:
            - "eamodio.gitlens"
            - "kahole.magit"
            - "PhilHindle.errorlens"
            - "sleistner.vscode-fileutils"
            - "vscodevim.vim"

L'objectif principal des rôles est d'organiser des tasks. Par exemple, on créé le rôle nvim, avec cette structure :

$ tree roles/nvim
roles/nvim
└── tasks
    ├── fedora.yml
    ├── macos.yml
    ├── main.yml
    └── ubuntu.yml

1 directory, 4 files

Le fichier main.yml import les tasks d'autres fichiers.

- name: Build nvim from source in Ubuntu
  import_tasks: ubuntu.yml
  when: ansible_distribution == "Ubuntu"

- name: Build nvim from source in Fedora
  include_tasks: fedora.yml
  when: ansible_distribution == "Fedora"

- name: Install nvim with Homebrew in macOS
  import_tasks: macos.yml
  when: ansible_distribution == "MacOSX"

La doc sur les rôles ici

Et un exemple de dotfile qui utilise Ansible.

Atelier

Durant cet atelier en utilisant la vm que vous avez recupéré hier et votre dotfile, vous devrez commencé à automatiser votre dotfile. Utilisez les infos ci-dessus, les docs de ansible et regarder des exemples de dotfile.

Github Awesome dotfile. Plein d'infos et ressources sur les dotfiles.

Sources

Pour cette partie j'ai majoritairement traduit ce tutoriel Que je vous conseille de lire si ça vous intéresse.