Vous le savez surement mais j’aime beaucoup ansible par sa simplicité. Mais pas seulement, il y a aussi sa communauté qui lui permet de partager un grande nombre de rôles notamment via galaxy. On ne va pas en profiter aujourd’hui mais souvent c’est un bon moyen de voir comment on installe et configure une technologie. Voir de se rendre compte de la complexité ou non de la chose et même si à la fin on ne veut pas forcément le faire avec ansible cela reste une sorte de doc à suivre.

Le monitoring est un point indispensable de notre métier. Il a nettement évolué au cours de la dernière décennie, notamment avec la montée en force de la conteneurisation et du cloud. Ainsi le monitoring a dû se mettre à la page pour adapter une configuration dynamique. On ne peut plus se permettre de rentrer les machines à monitorer une à une.

Je vous propose de joindre l’utile à l’agréable et vous allez prendre, j’espère, un peu de plaisir à faire du ansible tout en découvrant la stack prometheus, grafana et les exporter. Bonne formation ansible à toutes et à tous !!

Vous pouvez retrouver la formation prometheus/grafana and Co ici :

La structure de nos rôles

Alors avec ansible, c’est un exercice assez intéressant pour débuter. Nous allons principalement avoir 3 rôles : node exporter, prometheus et grafana. Ce découpage est intéressant car node exporter doit être installé sur toutes les machines pour remonter les métriques et les deux autres sur une seule machine, le noyau central.

Pourquoi découper en deux prometheus et grafana dans 2 rôles différents ? Généralement plus les briques sont fines et plus on peut faire de choses avec ses legos et bien là c’est le même principe. On se donne le choix d’un jour pouvoir installer juste un prometheus ou juste un grafana ou encore mieux de partager dans la communauté vos rôles.

Pour l’inventaire on va partir sur 3 machines pour avoir quelque chose de simple.

all:
  vars:
    ansible_python_interpreter: /usr/bin/python3
  hosts:
    172.17.0.3:
    172.17.0.4:
  children:
    monito:
      hosts:
        172.17.0.2:

On y retrouve un groupe ALL composé de 3 serveurs dont un fait partie d’un sous groupe MONITO. Eventuellement on précise que l’on va utiliser python 3 sur toutes les machines mais cela n’est plus vraiment nécessaire actuellement.

Et notre playbook ?

La encore on va faire simple, une partie dédiée à node-exporter et l’autre à la stack de monitoring. Le premier va installer node-exporter sur le groupe ALL et le second prometheus/grafana sur la machine du groupe monito.

- name: install node exporter
  hosts: all
  become: yes
  roles:
  - node_exporter

- name: install prometheus/grafana
  hosts: monito
  become: yes
  roles:
  - prometheus
  - grafana

Au passage on passe un become à YES pour jouer l’installation complète avec une élévation de privilège via sudo.

Création du rôle node exporter

Pour la création de nos rôles on commence systématiquement par utiliser la commande galaxy qui permet de créer la structure de base. Cela évite d’avoir des trucs sui ne respecteraient pas les standards de ce côté.

ansible-galaxy init roles/node-exporter

ET donc comme tous les rôles le point d’entrée se fait par le répertoire tasks et son main.yml. Il va comprendre les tasks suivantes (et des variables que l’on va définir après) :

1. Vérification de l’existence ou non du binaire node exporter

- name: check if node exporter exist
  stat:
    path: "{{ node_exporter_bin }}"
  register: __check_node_exporter_present

2. Si il existe on va récupérer sa version en la reprenant via le contenu du fichier systemd de node-exporter (ce n’est pas forcément optimum mais ça marche bien… on aurait pu passer par le –version en redirigeant le stderr vers stdout etc).

- name: if node exporter exist get version
  shell: "cat /etc/systemd/system/node_exporter.service | grep Version | sed s/'.*Version '//g"
  register: __get_node_exporter_version
  when: __check_node_exporter_present.stat.exists == true
  changed_when: false

La variable __get_node_exporter_version permet de stocker la version. Et pour éviter une tâche qui sera toujours avec un changed on passe un changed_when à false. C’est l’inconvénient du module shell.

3. Création d’un utilisateur pour lancer node-exporter.

- name: create node exporter user
  user:
    name: "{{ node_exporter_user }}"
    append: true
    shell: /usr/sbin/nologin
    system: true
    create_home: false
    home: /

Pour la sécurité, cet utilisateur est nologin, sans home et de type system pour son uid.

4. Création d’un répertoire de configuration dans /etc/.

J’ai tendance à le faire pour tous les binaires que l’on l’utilise ou non. Au moins on en a un à notre disposition au cas où.

- name: create node exporter config dir
  file:
    path: "{{ node_exporter_dir_conf }}"
    state: directory
    owner: "{{ node_exporter_user }}"
    group: "{{ node_exporter_group }}"

5. Téléchargement du binaire pour node-exporter

Deux cas de figures se présentent à nous. Soit node exporter n’existe pas, soit il existe mais n’est pas dans la bonne version, donc on s’attache à traiter ces deux cas. Le module unarchive permet à la fois le téléchargement et également le dezip de l’archive.

- name: download and unzip node exporter if not exist
  unarchive:
    src: "https://github.com/prometheus/node_exporter/releases/download/v{{ node_exporter_version }}/node_exporter-{{ node_exporter_version }}.linux-amd64.tar.gz"
    dest: /tmp/
    remote_src: yes
    validate_certs: false
  when: __check_node_exporter_present.stat.exists == false or not __get_node_exporter_version.stdout == node_exporter_version

6. Déplacement du binaire dans le PATH

C’est une habitude et c’est pratique on ajoute le binaire dans un répertoire du PATH commun.

- name: move the binary to the final destination
  copy:
    src: "/tmp/node_exporter-{{ node_exporter_version }}.linux-amd64/node_exporter"
    dest: "{{ node_exporter_bin }}"
    owner: "{{ node_exporter_user }}"
    group: "{{ node_exporter_group }}"
    mode: 0755
    remote_src: yes
  when: __check_node_exporter_present.stat.exists == false or not __get_node_exporter_version.stdout == node_exporter_version

Là encore on couvre les deux cas de figure pour être en accord avec la tâche précédente (soit changement de version, soit première installation de node-exporter).

7. Suppression des traces lol

Pour éviter de laisser un /tmp de cochon on clean ce que l’on vient de faire car on a plus besoin de garder l’archive.

- name: clean
  file:
    path: /tmp/node_exporter-{{ node_exporter_version }}.linux-amd64/
    state: absent

8. Installation du service systemd

Avec le module template on va utiliser un template (que l’on va voir juste après) pour créer le fichier du service systemd de node-exporter.

- name: install service
  template:
    src: node_exporter.service.j2
    dest: /etc/systemd/system/node_exporter.service
    owner: root
    group: root
    mode: 0755
  notify: reload_daemon_and_restart_node_exporter

On n’oublie pas de placer un petit notify qui va permetre de pratiquer un systemctl daemon-reload et un restart pour prendre en compte les modifications en cas de changements.

9. Flush du handler

J’aime bien forcer ansible à jouer les handlers au moment où je le souhaite ou définir le moment le plus tardif où je le fais. Donc on flush le handler.

- meta: flush_handlers

10. Démarrage de node exporter dans tous les cas

Et à la fin on veut une chose quoiqu’il arrive : un service node-exporter qui tourne et qui est enable pour prendre en compte un reboot de notre serveur.

- name: service always started
  systemd:
    name: node_exporter
    state: started
    enabled: yes

11. Les différentes variables par défaut

J’adore utiliser le répertoire des variables par défaut de notre rôle. Alors voici les variables que je vais défnir (à actualiser si besoin).

node_exporter_version: "1.0.1"
node_exporter_bin: /usr/local/bin/node_exporter
node_exporter_user: node-exporter
node_exporter_group: "{{ node_exporter_user }}"
node_exporter_dir_conf: /etc/node_exporter

12. Le contenu du main de notre répertoire handlers

- name: reload_daemon_and_restart_node_exporter
  systemd:
    name: node_exporter
    state: restarted
    daemon_reload: yes
    enabled: yes

13. Le template du service systemd

Rien de fou et le stricte minimum on peut y ajouter éventuellement un restart.

[Unit]
Description=Node Exporter Version {{ node_exporter_version }}
After=network-online.target

[Service]
User={{ node_exporter_user }}
Group={{ node_exporter_group }}
Type=simple
ExecStart={{ node_exporter_bin }}
Restart=on-failure
RestartSec=5s

[Install]
WantedBy=multi-user.target

Voilà pour node exporter. On a un truc à peu près propre et on peut éventuellement le faire évoluer (multi-system…).

Installation et configuration de prometheus

Je vous passe la création du rôle dans le répertoire de rôles. On le fait avec la même méthode que pour node-exporter.

Et on déroule de nouveau les tâches pour installer notre prometheus dans les tasks main.yml

1. Installation de prometheus

Alors on peut améliorer cette tâche en définissant une version fixe c’est toujours un peu mieux et avec sa variable.

- name: update and install prometheus
  apt:
    name: prometheus
    state: latest
    update_cache: yes
    cache_valid_time: 3600

2. Ajout des arguments à la CLI de prometheus

Pour définir les arguments à passer à notre CLI de prometheus on va utiliser /etc/default/prometheus. Pour créer ce fichier, nous allons le gérer à partir d’un template pour y ajouter des variables. Et on oublie pas le notify pour disposer d’un handler qui permettra le restart de prometheus en cas de changement.

- name: prometheus args
  template:
    src: prometheus.j2
    dest: /etc/default/prometheus
    mode: 0644
    owner: root
    group: root
  notify: restart_prometheus

3. Edition de la configuration de prometheus

Nouveau template pour la création de la configuration de prometheus que nous allons voir juste après.

- name: prometheus configuration file
  template:
    src: prometheus.yml.j2
    dest: "{{ prometheus_dir_configuration }}/prometheus.yml"           
    mode: 0755
    owner: prometheus
    group: prometheus
  notify: reload_prometheus

En cas de changement on joue un reload de prometheus (plutôt qu’un restart).

4. Flush du handler

Comme prometheus est normalement toujours démarré à ce stade on peu flusher les handlers (restart ou reload).

- meta: flush_handlers

5. Prometheus doit toujours être up

Comme pour node-exporter on veut à la fin un prometheus up et enable pour prévoir le reboot de la machine.

- name: start prometheus
  systemd:
    name: prometheus
    state: started
    enabled: yes

6. Les variables par défaut

Définissons les variables par défaut. On va également définir dedans l’entête de notre fichier de configuration dans la variables prometheus_var_config, c’est assez pratique pour faire des modifications.

prometheus_dir_configuration: "/etc/prometheus"
prometheus_retention_time: "365d"
prometheus_scrape_interval: "30s"
prometheus_node_exporter_group: "all"
prometheus_env: "production"
prometheus_var_config:
  global:
    scrape_interval: "{{ prometheus_scrape_interval }}"
    evaluation_interval: 5s
    external_labels:
      env: '{{ prometheus_env }}'
  scrape_configs:
    - job_name: prometheus
      scrape_interval: 15s
      static_configs:
        - targets: ['{{ inventory_hostname }}:9090']

7. Le template du fichier de configuration prometheus.yml

Voici notre fichier du template de la configuration. Pour traiter strictement notre yaml on y ajoute une entête lstrip_blocks.

On utilise un filtre to_nice_yaml pour aajouter notre variable contenant l’entête du point précédent.

Et on conditionne un bloc dédié à node-exporter sur activation de la variable prometheus_node_exporter_group.

Grâce aux groupes de ansible ou va lister et boucler sur toutes les machines du groupe défini dans la variable prometheus_node_exporter_group (cela permet de définir un autre nom de groupe que dans notre cas ALL).

#jinja2: lstrip_blocks: "True"
{{ prometheus_var_config | to_nice_yaml(indent=2) }}
{% if prometheus_node_exporter_group %}
- job_name: node_exporter
  scrape_interval: 15s
  static_configs:
  - targets:
{% for server in groups[prometheus_node_exporter_group] %}
    - {{ server }}:9100
{% endfor %}
{% endif %}

Et enfin le dernier template que l’on oublie pas, celui des arguments de prometheus (notamment la durée de rétention des métriques dans notre TSDB).

# Set the command-line arguments to pass to the server.
ARGS="--web.enable-lifecycle --storage.tsdb.retention.time={{ prometheus_retention_time }} --web.console.templates=/etc/prometheus/consoles --web.console.libraries=/etc/prometheus/console_libraries

Et enfin le rôle Grafana !!!

On en arrive à la visualisation de nos données, principalement les métriques collectées dans notre prometheus. Alors go on y va. Après avoir crée notre structure de rôles avec la CLI de ansible-galaxy on édite nos tasks.

1. Installation du repository et installation de grafana

On va regrouper les tâches d’installation.

- name: install gpg
  apt:
    name: gnupg,software-properties-common
    state: present
    update_cache: yes
    cache_valid_time: 3600

- name: add gpg hey
  apt_key:
    url: "https://packages.grafana.com/gpg.key"
    validate_certs: no

- name: add repository
  apt_repository:
    repo: "deb https://packages.grafana.com/oss/deb stable main"
    state: present
    validate_certs: no

- name: install grafana
  apt:
    name: grafana
    state: latest
    update_cache: yes
    cache_valid_time: 3600

Rien de compliqué donc on passe rapidement.

2. Changement du user d’admin

Grafana utilise le user admin et le password par défaut admin, c’est plutôt bien de le changer le plus rapidement possible. On fait cela en passant par son fichier de configuration même si on pouvait le faire par la CLI grafana-cli (mais c’est l’occasion de faire un peu de lineinfile pour le découvrir).

- name: change admin user
  lineinfile:
    path: /etc/grafana/grafana.ini
    regexp: "{{ item.before }}"
    line: "{{ item.after }}"
  with_items:
  - { before: "^;admin_user = admin", after: "admin_user = {{ grafana_admin_user }}"}
  - { before: "^;admin_password = admin", after: "admin_password = {{ grafana_admin_password }}"}

3. Stat et enable de grafana

Sans commentaire

- name: start service grafana-server
  systemd:
    name: grafana-server
    state: started
    enabled: yes

Et on peut attendre que Grafana soit up

4. Attente d’une réponse positive de l’interface Grafana

Un petit truc sympa mais pas toujours nécessaire, on va attendre une réponse 200 de la page d’accueil de Grafana. On utilisera un délai d’attente assez large de 2min.

- name: wait for service up
  uri:
    url: "http://127.0.0.1:3000"
    status_code: 200
  register: __result
  until: __result.status == 200
  retries: 120
  delay: 1

5. Ajout de notre prometheus comme première datasource

On sait que l’on a un prometheus juste à côté qui demande à être raccordé à notre grafana, c’est le moment de le faire.

- name: add prometheus datasource
  grafana_datasource:
    name: "prometheus-local"
    grafana_url: "http://127.0.0.1:3000"
    grafana_user: "{{ grafana_admin_user }}"
    grafana_password: "{{ grafana_admin_password }}"
    org_id: "1"
    ds_type: "prometheus"
    ds_url: "http://127.0.0.1:9090"
  changed_when: false

Rien de très particulier si ce n’est que nous utilisons le module grafana qui est bien fonctionnel sur ansible.

6. Téléchargement du dashboard node-exporter

Ensuite on va procéder en deux temps. On télécharge le dashboard dédié à node-exporter.

- name: install node exporter dashboard
  get_url:
    url: https://raw.githubusercontent.com/rfrail3/grafana-dashboards/master/prometheus/node-exporter-full.json
    dest: /var/lib/grafana/node-exporter.json
    mode: '0755'

7. Activation du dashboard

Ensuite pour activer ce dashboard, nous avons besoin de créer un fichier dans le répertoire de configuration de grafana dans /etc/.

- name: activate dashboard for node exporter
  template:
    src: dashboard-node-exporter.yml.j2
    dest: /etc/grafana/provisioning/dashboards/dashboard-node-exporter.yml
    mode: 0755
  notify: restart_grafana

Et pour l’ajouter nous avons besoin de restart en passant par un handler c’est plutôt mieux.

8. Le handler

- name: restart_grafana
  systemd:
    name: grafana-server
    state: restarted
    enabled: yes
    daemon_reload: yes

9. Les variables pour notre rôle grafana

Bien sûr à personnaliser.

grafana_admin_user: "xavki"
grafana_admin_password: "password"

Conclusion

Voilà on a fini nos petits rôles qui ne demande qu’à être personnalisés et adaptés à vos besoins. Tout cela est perfectible car simplifié pour faciliter la pédagogie et l’apprentissage. Néanmoins je pense que c’est une bonne base pour commencer avec cette stack ou encore avac ansible.

Faites vous plaisir, partagez et rejoignez la chaine Xavki !!

L’article Comment installer la stack de monitoring prometheus/grafana avec ansible ? est apparu en premier sur Xavki.

Revenons à ansible un peu dans ce nouvel article avec deux nouvelles utilisations simples et très utiles :

• la possibilité de créer une clef SSH et de la pousser sur les machines cibles
• l’ajout d’une tâche de reboot (après upgrade par exemple) et la reprise des tâches où on en était resté

Donc des tâches simples mais courantes d’un administrateur système sous linux.

Créer une clef SSH et la déployer sur votre parc avec Ansible

Pour faire cela, nous allons réaliser deux tâches différentes avec deux modules disctincts :

• openssh_keypair : pour créer une clef SSH avec différents paramètres
• authorized_key : pour déployer la clef publique dans le fichier authorized_keys de vos utilisateurs

Créer une clef c’est bien mais en créer une différente sur chaque machine ne sera pas forcément une grande idée. Certes, niveau sécurité vous auriez une infrastructure un peu plus robuste, mais la gestion des clefs risque vite de déborder et devenir insoutenable.

Ainsi, si vous souhaitez passer par ansible pour créer le jeu de clefs SSH (privée et publique), je vous invite à faire tourner cette tâche sur le serveur ansible en local.

Ainsi, nous allons jouer une partie de playbook de la manière suivante :

- name: mon premier playbook
  hosts: all
  remote_user: vagrant
  tasks:
  - name: generate SSH key"
    openssh_keypair:
      path: /tmp/xavki
      type: rsa
      size: 4096
      state: present
      force: no
    run_once: yes
    delegate_to: localhost

J’ai pris des options de base qui peuvent être renforcées (notammen ajouter une passphrase est indispensable).

Nous utilisons donc le module openssh_keypair en lui demandant de créer un jeu de clefs “xavki” de type rsa et de longueur 4096. Et pour faire cela sur le serveur ansible nous lui ajoutons le paramètre delegate_to en mentionnant localhost (run local). Bien sûr ansible souhaite par défaut faire tourner cette tâche pour toutes les machines du groupe all tel que mentionné dans “hosts”. C’est pourquoi avec un run_once à yes, nous allons limiter ce run à une seule itération c’est à dire pour la première machine du groupe all.

Pour le déploiement de la clef publique dans le authorized_key, là encore ansible fournit une module bien pratique.

  - name: Deploy SSH Key
    authorized_key: 
      user: devops
      key: "{{ lookup('file', '/tmp/xavki.pub') }}"
      state: present
    become: yes

On ajoute un become yes pour que notre user puisse avoir suffisament de droit pour aller dans les homes de tous les utilisateurs. Ensuite on va rechercher le contenu de notre clef publique localement (serveur ansible) avec un lookup de type file et on indique pour cible le user nommé “devops”.

Et le tour est joué !!!

Comment organiser un reboot après un upgrade avec ansible ?

Le module reboot de ansible est très utile. Il permet de lancer un reboot intercalé entre différentes taches et de reprendre celles-ci où elles en étaient arrivées avant de lancer le reboot. C’est bon ça, non ?

Alors comment lancer un reboot après une mise à jour du noyau par exemple ou lorsqu’un reboot est requis ?

 - name: update cache
      apt:
        update_cache: yes
        force_apt_get: yes
        cache_valid_time: 3600

    - name: upgrade général
      apt:
        upgrade: dist
        force_apt_get: yes

    - name: vérification à partir du fichier reboot_required
      register: __reboot_required_file
      stat:
        path: /var/run/reboot-required

    - name: lancement du reboot avec reboot
      reboot:
        msg: "Reboot via ansible"
        connect_timeout: 5
        reboot_timeout: 300
        pre_reboot_delay: 0
        post_reboot_delay: 30
        test_command: uptime
      when: __reboot_required_file.stat.exists

Dans la première tâche, on lance une mise à jour du cache apt puis dans la seconde on réalise un dist-upgrade (dans notre exemple).

Sur debian, lorsque qu’un reboot est nécessaire, un fichier temporaire est créé dans /var/run/reboot-required. Donc réalisons un stat sur ce fichier pour tester sa présence.

Donc en dernière tâche, on se base sur __reboot_required et sa clef stat.exists pour vérifier la présence de ce fichier. Si celui-ci est là on lance un reboot.

Pour le reboot, on lance aux utilisateurs connectés un message, et on lance un reboot sans attendre avec pre_reboot_delay. On laisse 5min à la machine pour rebooter, puis 30s d’après reboot et 5 secondes pour se connecter ensuite en SSH dessus. Dans le cas contraire la tâche plantera. Et pour valider cette tâche de reboot on lance enfin un uptime.

Et voilà le tour est joué. Rien de complexe pour deux tâche rudimentaires.

Oubliez pas de venir visiter la chaine Xavki et de vous abonner pour découvrir les plus de 1100 tutoriels.

L’article Ansible, comment générer des clefs SSH et les pousser, organiser un reboot ? est apparu en premier sur Xavki.

Continuons notre formation ansible en apprenant petit à petit les rudiments de ce formidable outil. Bien sûr nous avons encore quelques fondamentaux à découvrir avant de nous lancer dans notre premier TP utile. Celui-ci sera orienté monitoring avec l’installation d’une stack prometheus/grafana et de node-exporter pour aller avec. Simple, pratique et vous le verrez pas besoin d’y passer des heures à coder pour avoir un résultat sympathique.

Mais avant cela, il faut procéder de manière un peu itérative avec les principaux modules ansible. Là encore pas besoin de savoir faire des choses complexes mais un minimum.

Aujourd’hui, penchons-nous sur le module apt (le manager de paquets sous debian, il existe bien sûr la même chose sous Redhat/Centos avec yum). Si votre infrastructure est basée sur cette OS, je vous conseille de bien le retenir et de se familiariser avec ses principales options/paramètres.

Justement débutons avec les principaux paramètres de ce module ansible.

Les paramètres du module APT

Voici une liste assez exhaustive de ses paramètres. Nous verrons leur principales utilisation juste après.

• allow_unauthenticated : autoriser l’installation de paquets non authentifiés
• autoclean : effacement des anciennes versions des paquets
• cache_valid_time : durée durant laquelle ne pas remettre à jour le cache apt
• deb : lien vers une source de paquet .deb
• default_release : version par défaut
• dpkg_options : option d’installation dpkg
• force : équivaut à –force-yes, désactive la signature et certificats de paquets
• force_apt_get : force l’utilisation de apt-get
• install_recommends : activer ou désactiver les paquets recommandés (dépend des OS)
• name : nom du paquet
• only_upgrade : met à jour uniquement les paquets installés
• policy_rc_d : règle de déclenchement automatique à l’installation d’un paquet
• purge : purge les fichiers de configurations (–purge)
• state : present / absent / latest / fixed / build-dep
• update_cache : réaliser un update avant l’installation
• update_cache_retries : nombre de tentatives de l’update
• update_cache_retry_max_delay : délai de chaque retry
• upgrade : yes / no / safe / dist / full

Voilà, la liste n’est finalement pas si longue que cela. Mais voyons un peu son utilisation avec quelques exemples pour la mise en pratique.

Utilisation du module APT ansible

A savoir que l’on peut combiner certains paramètres alors que dans la pratique il s’agit de lignes de commandes APT distinctes.

Par exemple, si nous voulons simplement mettre à jour le cache APT local, voici ce que nous pouvons utiliser :

  - name:
    apt:
      update_cache: yes
      cache_valid_time: 3600

Dans ce cas de figure, nous mettons à jour le cache et nous lui donnons une durée de vie de 3600 secondes. Cela évite tout simplement de remettre à jour le cache après chaque passage.

Mais nous pouvons combiner la mise à jour du cache et l’installation d’un paquet (par exemple HaProxy)

  - name:
    apt:
      name: haproxy
      default_release: stretch-backports
      update_cache: yes
      cache_valid_time: 60

Là nous précisons éventuellement la release utilisée pour l’installation.

Par défaut et sans précision, le paramètre state est à “present”. Nous souhaitons donc que le paquet soit installé. Mais nous pouvons préciser un state à latest. L’impact ? En cas de run ansible et de la présence d’une nouvelle version du paquet, l’applicatif sera mis à jour. Pas forcément une bonne idée pour la stabilité des versions et de votre infrastructure.

Par exemple :

  - name:
    apt:
      name: haproxy,nginx
      update_cache: yes
      cache_valid_time: 60
      state: latest

Bien sûr vous l’avez deviné, pour supprimer un paquet, on va utiliser un state absent.

  - name:
    apt:
      name: haproxy
      state: absent

Ou encore pour une suppression totale des anciennes versions avec autoremove et –purge pour les fichiés liés :

  - name:
    apt:
      name: haproxy
      state: absent
      purge: yes
      autoremove: yes

Nous pouvons aussi réaliser un dist-upgrade pour monter de version notre distribution (par exemple passer de stretch à buster). Attention sous réserve de mise à jour des fichiers de configurations des dépôts au préalable.

  - name:
    apt:
      upgrade: dist

Voilà finalement un module utile et simple, tout ce que l’on aime. Nous verrons aussi que l’on peut associer à ce module, le module de gestion des reboots, très pratique pour les mises à jour.

L’article Le module APT de ansible, un indispensable est apparu en premier sur Xavki.

Continuons sur notre formation ansible. Alors que j’ai tourné la 123ème d’un cours qui sera assez complet sur ansible, je vous propose de continuer progressivement après notre article sur stat et register. Pour les personnes qui souhaitent accéder à ces vidéos sans attendre, elles sont déjà disponibles pour les membres VIP de la chaine xavki qui la soutiennent.

En matière de formation, je pense qu’il faut être progressif et patient. C’est pour cela que je préfère aborder quelques notions au début mais sans brûler les étapes.

Aujourd’hui nous allons nous former à l’utilisation des boucles dans ansible. Les principales sont faciles à retenir car elles commencent par : with_*. La plus répandu étant with_items.

Avant de commencer, il me semble nécessaire de préciser que ansible est en cours d’évolutions dans ce domaine. L’objectif est de basculer à loop et remplacer potentiellement les with_*. Pour le moment nous n’en sommes pas là et les with_* sont plus faciles à aborder et retenir pour commencer. La documentation précise bien que cette migration ne se fait pas rapidement et que with_* possède encore de beaux jours devant lui, on est loin de le voir déprécier.

Les différentes boucles possible avec with

Si loop ne remplace pas encore les with, c’est essentiellement car il en existe de nombreux et que chacun dispose de boucler sur une fonctionnalité particulière :

• with_items : sur une liste de dictionnaire (ensemble de clefs/valeurs)
• with_nested : sur une liste de listes
• with_dict : parcourir un dictionnaire
• with_fileglob : sur une liste de fichiers de répertoire avec ou sans pattern mais non récursif
• with_filetree : sur une liste de fichier d’une arborescence (recursif) et avec pattern
• with_together : permet de croiser 2 listes
• with_sequence : pour parcourir un range (interval)
• with_random_choice : tirage aléatoire dans une liste
• with_first_found : sur le premier élément trouvé d’une liste
• with_lines : pour parcourir chaque ligne d’un programme (exemple : shell)
• with_ini : pour parcourir un fichier au format ini
• with_inventory_hostnames : pour récupérer et parcourir des éléments d’un inventaire

On a donc du choix, mes préférés étant with_items et with_fileglob principalement.

Comment utiliser with_* avec ansible ?

C’est très simple. Les éléments d’entrées sont définis dans le with_* et en sortie sont utilisable par une variable “item”. En cas d’éléments si disposant de plusieurs clefs ont les utilisera avec “item.clef1”, “item.clef2″…

Dans le cas le plus simple nous pouvons commencer par parcourir une simple lite d’éléments :

  - name: boucle création de répertoire
    file:
      path: /tmp/xavki/{{ item }}
      state: directory
      recurse: yes
    with_items:
    - xavki1
    - xavki2
    - xavki3
    - xavki4

Ou encore, dans un playbook, nous pouvons faire un test avec une liste de dictionnaires :

  - name: création de fichiers
    file:
      path: /tmp/xavki/{{ item.dir }}/{{ item.file }}
      state: touch
    with_items:
    - { dir: "xavki1", file: "fichierA"}
    - { dir: "xavki2", file: "fichierB"}
    - { dir: "xavki3", file: "fichierC"}
    - { dir: "xavki4", file: "fichierD"}

Nos clefs sont “dir” et “file” et donc nous allons les utiliser avec item.dir et item.file. Ansible fait le reste pour parcourir la boucle. C’est assez facile pour débuter !!! ou encore en passant par une variable.

  vars:
    fichiers:
    - { dir: "xavki1", file: "fichierA"}
    - { dir: "xavki2", file: "fichierB"}
    - { dir: "xavki3", file: "fichierC"}
    - { dir: "xavki4", file: "fichierD"}
  tasks:
  - name: création de fichiers
    file:
      path: /tmp/xavki/{{ item.dir }}/{{ item.file }}
      state: touch
    with_items:
    - "{{ fichiers }}"

Alors maintenant imaginons que nous souhaitions parcourir les machines composant un groupe de notre inventaire. Le premier réflexe en méconnaissant les boucles serait de faire la chose suivante :

 with_items:
    - "{{ groups['all'] }}"

C’est fonctionnel car on pourra bien récupérer la liste des machines avec la variable “item” de notre with_items. Mais nous l’avons vu , il existe un with dédié à cette tâche with_inventory_hostnames. Ainsi nous pouvons le faire de cette manière :

  - name: création de fichiers
    file:
      path: /tmp/{{ item }}
      state: touch
    with_inventory_hostnames:
    - all

Les boucles un outil indispensable

Clairement nous ne verrons pas d’exemples dans cet article. L’idéal pour manipuler les boucles c’est la pratique d’exemples réels. Cela fera l’objet des TP.

Ainsi les boucles vont nous permettre de définir des variables de types dictionnaires de manière à être en mode descriptif et avoir des blocs qui représentent notre infrastructure. Le with_fileglob nécessite un peu plus de pratique et de recul sur la manière d’organiser un code d’infra as code. Ainsi, nous allons pouvoir nous en servir pour sépcifier un répertoire contenant des usitsateurs : clefs ssh, login… Et une fois cela réalisé il ne restera qu’à récupérer les variables contenues dans ces fichiers. Ce point est l’un de mes préférés sur ansible donc nous n’y couperons pas.

Si vous souhaitez ne pas manquer les prochaines vidéos, vous pouvez vous abonner. Et pour m’aider encore plus vous pouvez éventuellement liker les vidéos.

L’article Les boucles with avec ansible est apparu en premier sur Xavki.

La dernière vidéo publiée s’adresse plutôt aux débutants avec 2 éléments utiles au quotidien dans vos développements ansible : le register et le module stat. J’ai trouvé cela intéressant de les associer car on le fait cela souvent dans la pratique.

Le module stat de ansible

Idéal pour commencer, ce module ansible permet de vérifier notamment l’existence ou non de fichiers ou de répertoires. Mais pas seulement, le module stat s’apparente aux données accessibles via la commande stat sous linux.

Ainsi une commande stat fournie les principales informations fournies par les inodes. On pourrait résumer cela aux metadatas de votre filesystem.

oki@doki ~/playground/centreserver $ ▶ stat deploy.sh
File: deploy.sh
Size: 3710 Blocks: 8 IO Block: 4096 regular file
Device: fd01h/64769d Inode: 11274196 Links: 1
Access: (0755/-rwxr-xr-x) Uid: (1001/ oki) Gid: (1001)
Access: 2021-03-09 15:49:37.803546224 +0100
Modify: 2021-02-09 18:29:07.371956532 +0100
Change: 2021-02-09 18:29:07.371956532 +0100
Birth: -

Je vous propose donc de créer un fichier avec ansible et lancer dessus le mode stat en deuxième task.

  - name: création d'un fichier
    file:
      path: /tmp/xavki.txt
      state: touch
      owner: xavki

puis lançons le module stat :

  - name: check avec stat
    stat:
      path: /tmp/xavki.txt

Les paramètres de ce module ansible sont :

• path : chemin du fichier ou répertoire
• follow : suivre les liens symboliques
• get_checksum : récupérer la checksum
• checksum_algorithm : type de checksum (md5, etc)
• get_mime: récupération du type de données

Mais une fois que l’on a fait cela on ne dispose pas encore des données collectées par le module. Pour cela nous avons besoin d’utiliser le register.

Le register, un ami pour vos modules

Si on devait résumer le register, on pourrait dire qu’il s’agit d’un créateur de variables. Il permet de récupérer les outputs/sorties des modules. En effet de nombreux modules permettent de récupérer des informations lorsqu’ils sont exécutés. Par exemple, le module ec2 de aws va permettre de récupérer toutes les métadatas de l’instance créée.

Pour le module stat de ansible, il va récupérer les informations du fichier ou du répertoire en question.

Pour l’utiliser c’est très simple, il suffit de rajouter register et le nom de la variable créée qui contiendra le contenu de la sortie. Attention à l’indentation avec ansible, il s’agit de mettre le register au même niveau que le nom du module.

Ainsi nous pourrions avoir une succession de tâches suivantes :

  tasks:
  - name: création d'un fichier
    file:
      path: /tmp/xavki.txt
      state: touch
      owner: root
    when: xavki_file is defined
  - name: check avec stat
    stat:
      path: /tmp/xavki.txt
    register: __fichier_xavki
  - name: debug
    debug:
      var: __fichier_xavki

La première pour la création du fichier.

La seconde pour passer un stat sur le fichier xavki.txt avec le register (création de la variable __fichier_xavki).

Et enfin pour visualiser le contenu de la variable obtenue, nous utilisons le module debug.

Bonne pratique : j’ai pour habitude de préfixer ce type de variables par un double underscore. Cela me permet d’une part de les identifier plus rapidement et d’autres part d’utiliser plus rapidement l’autocomplétion (par exemple dans vscode).

Dans le cas de stat, vous pouvez ensuite parcourir le contenu de cette variable ansible. Ainsi pour utiliser la valeur de stat et de la clef “exists” voici comment faire :

__fichier_xavki.stat.exists

Maintenant nous sommes donc en mesure de vérifier l’existence d’un fichier ou d’un répertoire et de conditionner la tache suivante à cela.

  - name: création répertoire xavki
    file:
      path: /tmp/xavki
      state: directory
    when: __fichier_xavki.stat.exists and xavki_file is defined

Mais je vous invite à vérifier le contenu de l’output en totalité et vous verrez que nous disposons des mêmes éléments que si nous avions lancé la commande linux.

Retrouvez les tutoriels ansible ici et abonnez-vous si vous souhaitez ne pas manquer les prochains articles ou vidéos.

L’article Stat et Register, indispensables pour commencer avec ansible est apparu en premier sur Xavki.

Ansible est de plus en plus au coeur des orchestrations dans un esprit de devops. Il permet à partir de choses simples et descriptives de configurer et déployer des infrastructures mais aussi des applicatifs.

Dans cet article dédié à la formation à ansible, je vous propose de découvrir le module user. C’est un peu une base car il permet comme son nom l’indique de créer des users… et l’installation de serveurs ne se fait pas sans créer d’utilisateurs.

Ce module se base principalement sur les commandes : useradd, userdel, usermod…

Comme je le rappelle dans cette page, il prend de nombreux paramètres. Vous povuez aussi vous rapprocher de la documentation en anglais et plus complète du site de ansible.

Débutons par la mise en place et le premier run du module user

Le cas le plus simple pour commencer est de se créer un utiliseurs de démo. Pour cela il vous faut quelques serveurs (je vous invite à regarder mon article précédent pour vous créer des conteneurs docker similaires à des VM).

Ensuite bien sûr vous devez disposer aussi d’un inventaire et d’un playbook mais maintenant vous commencez à connaître.

Pour créer un user sans droits ni contraintes particulières, nous pouvons commencer par cette tâche.

- name: création de xavki
  user:
    name: xavki
    state: present
    password: "{{ 'password' | password_hash('sha512') }}"  

Nous utilisons bien “user” et lui passons 3 paramètres :

• le nom : celui de l’utilisateur que nous voulons créer
• le statut : est-ce que l’on souhaite qu’il soit créé ou supprimé (present/absent en anglais pour ansible)
• le password : petite particularité c’est que celui-ci ne peut pas être complètement en clair (en théorie il ne doit pas l’être du tout mais nous n’avons pas encore vu dans cette formation ansible-vault). Donc nous utilisons le filtre jinja password_hash et lui précisons que nous voulons un hash de type sha512.

Et bien sûr nous lançons notre playbook :

ansible-playbook -i 00_inventory.yml playbook.yml

Ajoutons quelques paramètres pour mieux configurer notre utilisateur

Bien c’est un premier pas et vous pouvez vérifier cela en vous connectant sur une machine distante avec une simple commande comme :

id xavki

Mais admettons que nous souhaitions ajouter ce user à un groupe existant. On parle bien ici de l’ajouter et non pas d’écraser son groupe. Dans notre exemple, ajoutons-le au groupe sudo pour plus de liberté ;).

- name: création de xavki
  user:
    name: xavki
    state: present
    groups: sudo
    append: yes
    password: "{{ 'password' | password_hash('sha512') }}"  

On ajoute donc le paramètre group et le paramètre append à yes. Ce dernier assure que nous ajoutions bien le groupe au user et pas l’écrasement de son appartenance aux autres groupes.

Cependant, nous aimons associer une clef ssh à un utilisteur. Pour cela ansible permet différentes situations. Ici nous allons l’ajouter et voir le retour de la tâche de création user grâce à un debug.

  - name: création du user xavki
    user:
      name: xavki
      state: present
      generate_ssh_key: yes
      uid: 1200
      groups: sudo
      append: yes
      password: "{{ 'password' | password_hash('sha512') }}"
    register: mavar
  - name: debug
    debug:
      msg: "{{ mavar }}"

Et vous pouvez constater dans la sortie que l’on peut récupérer les éléments relatifs à la clef SSH.

Et nous pouvons bien lui ajouter un shell on retrouve les options de useradd en ligne de commande.

  - name: création du user xavki
    user:
      name: xavki
      state: present
      shell: /sbin/nologin
      generate_ssh_key: yes
      uid: 1200
      groups: sudo
      append: yes
      password: "{{ 'password' | password_hash('sha512') }}"
      password_lock: yes

Remarquez que là nous ajoutons un password_lock. Cela permet de conserver l’utilisateur tout en l’empêchant de se connecter.

Et enfin, vous l’avez deviné, nous allons supprimer cet utilisateur en passant simplement le nom et le status “absent”.

  - name: création du user xavki
    user:
      name: xavki
      state: absent

Et voilà nous venons de nous former à l’utilisation du module user de ansible.

L’article Formation Ansible : créer un utilisateur avec le module user est apparu en premier sur Xavki.

Il m’est très utilise pour mes formations ansible.

Lorsque j’ai créé ce script, j’avais besoin de tester régulièrement les rôles que je développais. J’utilisais déjà un peu vagrant et je trouvais que lancer une machine virtuelle demandais du temps. Et comme pour bien développer du ansible, il me semble très important de tout casser pour tout refaire, je me suis réorienté vers des conteneurs docker. Après coup, LXD/LXC serait encore plus optimal, ces conteneurs étant des conteneurs systèmes.

Bref, à l’époque j’ai creusé et cherchais comment avoir des conteneurs avec SSH et systemD. Finalement cela n’est pas très compliqué après avoir installé systemd, il suffit de supprimer quelques répertoires et de monter ceux de la machine en dessous.

Cependant attention, cela signifie aussi de lancer ces conteneurs en privileged. Donc tout cela cumulé, rend ce concept très défaillant d’un point de vue sécurité et non sécurisable. Il faut donc l’utiliser et supprimer les conteneurs après utilisation. En tout cas c’est ce que je recommande fortement.

Le Dockerfile d’une Debian avec SSH et SystemD

Je vous propose donc le Dockerfile suivant :

FROM debian:10

ENV container docker
ENV LC_ALL C
ENV DEBIAN_FRONTEND noninteractive

RUN echo 'deb http://deb.debian.org/debian stretch-backports main' >> /etc/apt/sources.list

RUN apt-get update \
    && apt-get install -y --no-install-recommends systemd python3 sudo bash net-tools openssh-server openssh-client vim git\
    && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*
RUN sed -i 's/PermitRootLogin prohibit-password/PermitRootLogin yes/' /etc/ssh/sshd_config
RUN sed -i 's/#PermitRootLogin/PermitRootLogin/' /etc/ssh/sshd_config
RUN rm -f /lib/systemd/system/multi-user.target.wants/* \
    /etc/systemd/system/*.wants/* \
    /lib/systemd/system/local-fs.target.wants/* \
    /lib/systemd/system/sockets.target.wants/*udev* \
    /lib/systemd/system/sockets.target.wants/*initctl* \
    /lib/systemd/system/sysinit.target.wants/systemd-tmpfiles-setup* \
    /lib/systemd/system/systemd-update-utmp*

RUN ln -s /lib/systemd/system /sbin/init
RUN systemctl set-default multi-user.target
RUN sed -i 's#root:\*#root:sa3tHJ3/KuYvI#' /etc/shadow
ENV init /lib/systemd/systemd
VOLUME [ "/sys/fs/cgroup" ]

ENTRYPOINT ["/lib/systemd/systemd"]

Plusieurs remarques donc :

• on installe ssh et systemd
• on permet le root login avec ssh
• on supprime de nombreux liens systemd car notre conteneur ne dispose pas de son propre matériel
• on définit un passsowr pour root (“password” par défaut)
• on prévoit de monter /sysS
• on lance en entrypoint : systemd (donc ssh n’est pas lancé en l’état)

Lancer un conteneur avec SSH/SystemD

Voici comment lancer avec un simple docker run un conteneur avec cette image

Là encore rien de très compliqué :

docker run -d --cap-add NET_ADMIN --cap-add SYS_ADMIN --publish-all=true -v /srv/data:/srv/html -v /sys/fs/cgroup:/sys/fs/cgroup:ro --name <nom_contneeur> -h <nom_conteneur> priximmo/debian_systemd:v1.0

On permet une élévation de privilège de notre conteneur sur notre hosts sur les capabilities NET_ADMIN et SYS_ADMIN.

On publie tous les ports pour pouvoir utiliser les applicatifs sur l’ip du conteneur sans se poser de question.

On monte un répertoire d’échange entre le host et le conteneur pour /srv/data.

On monte en lecture seul /sys/fs/cgroup.

Maintenant on automatise le lancement des conteneurs avec un script bash

L’enjeu est tout de même de pouvoir créer à la volée des conteneurs. Et d’essayer de gagner du temps dans le développement ansible. Au passage, bien sûr, ce script est utilisable dans d’autres cas d’utilisation (testing, dev…).

Voici le script que je vous propose et que vous pourrez personnaliser et compléter à votre goût.

#!/bin/bash

############################################################
#
#  Description : déploiement à la volée de conteneur docker
#
#  Auteur : Xavier
#
#  Date : 28/12/2018 - V2.0
#
###########################################################


# Functions #########################################################

help(){
echo "

Options :
		- --create : lancer des conteneurs

		- --drop : supprimer les conteneurs créer par le deploy.sh
	
		- --infos : caractéristiques des conteneurs (ip, nom, user...)

		- --start : redémarrage des conteneurs

		- --ansible : déploiement arborescence ansible

"

}

createNodes() {
	# définition du nombre de conteneur
	nb_machine=1
	[ "$1" != "" ] && nb_machine=$1
	# setting min/max
	min=1
	max=0

	# récupération de idmax
	idmax=`docker ps -a --format '{{ .Names}}' | awk -F "-" -v user="$USER" '$0 ~ user"-debian" {print $3}' | sort -r |head -1`
	# redéfinition de min et max
	min=$(($idmax + 1))
	max=$(($idmax + $nb_machine))

	# lancement des conteneurs
	for i in $(seq $min $max);do
		docker run -tid --privileged --publish-all=true -v /srv/data:/srv/html -v /sys/fs/cgroup:/sys/fs/cgroup:ro --name $USER-debian-$i -h $USER-debian-$i priximmo/buster-systemd-ssh
		docker exec -ti $USER-debian-$i /bin/sh -c "useradd -m -p sa3tHJ3/KuYvI $USER"
		docker exec -ti $USER-debian-$i /bin/sh -c "mkdir  ${HOME}/.ssh && chmod 700 ${HOME}/.ssh && chown $USER:$USER $HOME/.ssh"
	docker cp $HOME/.ssh/id_rsa.pub $USER-debian-$i:$HOME/.ssh/authorized_keys
	docker exec -ti $USER-debian-$i /bin/sh -c "chmod 600 ${HOME}/.ssh/authorized_keys && chown $USER:$USER $HOME/.ssh/authorized_keys"
		docker exec -ti $USER-debian-$i /bin/sh -c "echo '$USER   ALL=(ALL) NOPASSWD: ALL'>>/etc/sudoers"
		docker exec -ti $USER-debian-$i /bin/sh -c "service ssh start"
		echo "Conteneur $USER-debian-$i créé"
	done
	infosNodes	

}

dropNodes(){
	echo "Suppression des conteneurs..."
	docker rm -f $(docker ps -a | grep $USER-debian | awk '{print $1}')
	echo "Fin de la suppression"
}

startNodes(){
	echo ""
	docker start $(docker ps -a | grep $USER-debian | awk '{print $1}')
  for conteneur in $(docker ps -a | grep $USER-debian | awk '{print $1}');do
		docker exec -ti $conteneur /bin/sh -c "service ssh start"
  done
	echo ""
}


createAnsible(){
	echo ""
  	ANSIBLE_DIR="ansible_dir"
  	mkdir -p $ANSIBLE_DIR
  	echo "all:" > $ANSIBLE_DIR/00_inventory.yml
	echo "  vars:" >> $ANSIBLE_DIR/00_inventory.yml
    echo "    ansible_python_interpreter: /usr/bin/python3" >> $ANSIBLE_DIR/00_inventory.yml
  echo "  hosts:" >> $ANSIBLE_DIR/00_inventory.yml
  for conteneur in $(docker ps -a | grep $USER-debian | awk '{print $1}');do      
    docker inspect -f '    {{.NetworkSettings.IPAddress }}:' $conteneur >> $ANSIBLE_DIR/00_inventory.yml
  done
  mkdir -p $ANSIBLE_DIR/host_vars
  mkdir -p $ANSIBLE_DIR/group_vars
	echo ""
}

infosNodes(){
	echo ""
	echo "Informations des conteneurs : "
	echo ""
	for conteneur in $(docker ps -a | grep $USER-debian | awk '{print $1}');do      
		docker inspect -f '   => {{.Name}} - {{.NetworkSettings.IPAddress }}' $conteneur
	done
	echo ""
}



# Let's Go !!! ###################################################################""

#si option --create
if [ "$1" == "--create" ];then
	createNodes $2

# si option --drop
elif [ "$1" == "--drop" ];then
	dropNodes

# si option --start
elif [ "$1" == "--start" ];then
	startNodes

# si option --ansible
elif [ "$1" == "--ansible" ];then
	createAnsible

# si option --infos
elif [ "$1" == "--infos" ];then
	infosNodes

# si aucune option affichage de l'aide
else
	help

fi

Plusieurs options sont prévues :

• –create : la création de conteneurs en ajoutant à cette option un nombre pour indiquer le nombre de docker souhaités
• –drop : pour supprimer les conteneurs lancés avec ce script
• –start : en cas d’arrêt et de relance de votre machine, les conteneurs seront stoppés, cette options permet de les relancer à la volée
• –ansilbe : créé un répertoire dédié aux développements ansible avec notamment un inventory déjà rempli et complété par les ip de chacun des conteneurs
• –infos : pour lister les ip des conteneurs créés

Bien sûr on organise tout cela avec des fonctions bash. La plus fournie étant la fonction de création qui notamment :

• créé un user du même nom du user qui lance le script
• lui définit un password par défaut à “password”
• lui copie votre clef publique dans le authorized_keys
• lance ssh (cf dans notre dockerfile on ne lançait que systemd et pas sshd)

Voilà, j’ai déjà eu pas mal de retour positifs ou de gens qui ont customisé ce script. Certains ont ajouté d’autres OS également. A vous de voir et de vous faire plaisir en personnalisant tout cela et en l’adaptant au mieux à votre cas d’utilisation.

Tout le code source est ici.

L’article Un script bash et docker pour vous aider à développer des rôles ansible est apparu en premier sur Xavki.

Alors depuis quelques vidéos nous avons posé les bases avec :

• l’inventaire
• les groupes
• les hosts
• l’installation
• la CLI

Nous allons continuer sur ce chemin pour débuter petit à petit avec cet orchestrateur.

Depuis le temps il est peut être venu le moment de faire quelques actions sur nos serveurs.

A quoi sert le playbook ??

C’est assez simple, dans les définitions et concepts, nous avons vu qu’il y a deux bulles. Avec d’un côté l’inventaire et de l’autre les tasks qui sont des actions individuels que l’on peut rassembler dans des rôles.

Mais comment savoir quelles tâches sont jouées sur quelles machines cibles ?

C’est là qu’intervient le playbook. Il permet de coordonner les deux bulles l’inventaire et les rôles/tasks.

Il s’ait donc ni plus ni moins d’un fichier qui va dire quels groupes ou machines reçoivent quelles actions ? et bien sûr tout cela en format yaml comme la plupart des fichiers dans ansible.

Le playbook minimum resemble à ceci en terme de contenu :

- name: Mon Playbook !!
  hosts: all
  tasks:
  - name: je debug
    debug:
      msg: "{{ var1 }}"

Découvrons un peu plus ce que l’on a écrit :

• le nom du playbook “mon premier playbook”
• son périmètre ou ses serveurs cibles, donc notre cas le groupe all (c’est à dire toutes les machines)
• un bloc permettant de décrire les tasks
• le nom de la première tâche “je debug”
• l’appel à un module, en l’occurence “debug”
• les paramètres passés à ce module “msg” (pour indiquer un message composé d’une variable au format jinja).

On est pas mal pour débuter avec notre playbook.

A côté il ne faut pas oublier d’avoir un inventaire, comme par exemple :

all:
  hosts:
    172.17.0.2:

Comprendre la ligne de commande ansible-playbook ?

Comment lancer le playbook ? Comprendre est peut être un bien grand mot mais au moins savoir un peu ce que l’on fait et ce que l’on peut faire avec ansible et ses playbooks.

Dans ce qui est dessous nous allons parler du binaire ansible-playbook.

Voyons déjà une ligne de commande minimaliste pour lancer ce fichier :

ansible-playbook -i inventory.yml playbook.yml

Très simple non ? bon généralement il y aura souvent un peu plus d’options que cela dans votre terminal.

Voici donc quelques options plus ou moins connues (mais même les moins connues sont intéressantes… le diable se cache dans les détails).

	* -l : réduire le run à certaines machines ou certains groupes de votre inventaire
	* -u : spécifier un user particulier utilisé sur la où les machines distantes
	* -b : become est équivalent à taper sudo devant vos commandes pour élever vos privilèges
	* -k : pour recevoir la demande de saisie du mot de passe pour la connexion ssh
	* -K : le password pour l'élévation de privilège liée au sudo (become)
	* -C : check c'est le dry run... très utile quand on ne connait pas la fréquence des runs ansible
	* -D : diff c'est très utile pour avoir les différences et les modifications de ce que va faire ansible
	* --ask-vault : permet de saisir un password pour déchiffrer les secrets que vous aurez chiffré avec vault
	* --syntax-check : vérfier la syntax
	* --vault-password-file : passer le vault password par un fichier
	* -e : surcharger n'importe quelle variable
	* -f : forks, nombre de parallélisation
	* -t : filtrer sur les tags (--skip-tags)
	* --flush-cache : éviter l'utilisation du cache
	* --step : une tâche à la fois (confirmation via prompt)
	* --start-at-task : commencer à une tâche spécifiquement
	* --list-tags : lister tous les tags rencontrés
	* --list-tasks : liste les tâches qui vont être exécutées

Là on y voit plus clair.

Et maintenant commençons à jouer avec les fichiers grâce au module file.

Débuter avec le module FILE

Créer un fichier, un répertoire, leur affecter des droits, des propriétaires… ce sont des commandes courrantes en linux et généralement on apprend cela en débutant : mkdir, touch, chown, chmod, ln…. Et bien pour ansible c’est un peu pareil.

Le module file peut prendre différents paramètres :

* attribute : définitions des paramètres particuliers d'un fichier : immutabilité etc... cf https://fr.wikipedia.org/wiki/Chattr
* force : pour les liens symboliques (créer même si le fichier source existe pas, la destination existe)
* group/owner : le propriétaire et le groupe du fichier ou du répertoire
* mode : les permissions sous les deux formats : "0755" ou "u=rwx,g=rx,o=rx"
* path : la localisation du fichier ou des répertoires
* recurse : création du chemin intermédiaire si n'existe pas (yes/no), attention cela est valable uniquement pour les répertoires
* src : pour les liens (hard ou symbolique)
* state : le type absent / directory / file / hard / link / touch
		touch > créé le fichier vide
		file > vérifie l'existence et les caractéristiques

Et donc nous voici prêt à écrire notre première task. Par exemple pour créer un répertoire :

- name: créer un répertoire
  file:
    path: /tmp/xavki/
    state: directory
    owner: root

Ici ansible va créer le répertoire xavki dans /tmp car le state est de type directory. Et le propriétaire de ce répertoire sera l’utilistaur root.

Avec l’utilisation du mode récursif :

  - name: création du répertoire /tmp/xavki
    file:
      path: /tmp/xavki/1/2/3/4
      recurse: yes
      state: directory
      owner: root
      group: root
      mode: 0755

Ou encore simplement créer un fichier vide avec touch :

  - name: création du répertoire /tmp/xavki
    file:
      path: /tmp/xavki/1/2/3/4/fichier.txt
      state: touch
      owner: root
      group: root
      mode: 0755

Ou encore sous forme de lien :

  - name: création du répertoire /tmp/xavki
    file:
      src: /tmp/xavki/1/2/3/4/
      dest: /tmp/symlink
      state: link  #hard
      owner: root
      group: root
      mode: 0755

Et enfin pour supprimer des fichiers ou des répertoires, il suffit d’utiliser le state absent très courrant dans les modules ansible.

  - name: dir sans idempotence
    file:
      path: /tmp/xavki.txt
      state: absent

Voilà j’espère que cette prise en main de ansible et que vous pouvez débuter en toute tranquilité à votre rythme. Je vous rappelle que vous pouvez venir découvrir plus de 900 vidéos sur la chaine xavki avec de nombreuses autres thématiques autour du devops bien sûr. Et retrouvez tous les fichiers de ces présentations sur le dépôt dédié à ansible.

L’article Faire son premier playbook avec ansible est apparu en premier sur Xavki.

Il existe pas mal de bonnes pratiques pour ne pas se louper et toujours garder le cap. Après quelques années d’expériences, je pense que dans le domaine de l’infra as code, il faut toujours avoir des règles, des principes, des nomenclatures pour garder l’objectif de toujours s’y retrouver et éviter les dérives. Et systématiquement, il y a des dérives et il faudra revenir vers vos règles pour ramener les choses dans l’ordre.

Mais bon, quand on ne connait pas ou même lorsque l’on connait juste un peu, ce n’est pas évident de trouver son cap. Et surtout il faut éviter d’inventer des choses qui existent déjà.

Rester dans les fondamentaux a aussi un gros avantage. Si vous intégrez de nouvelles personnes dans vos équipes et qu’elles connaissent déjà les bonnes pratiques, ce sera encore plus facile pour eux d’être intégré technologiquement parlant. Et cela est très important en matière d’IaC car celle-ci décrit votre infrastructure et l’installation d’élements importants.

Bref l’inventaire ou inventory est un élément essentiel dans ansible et dans votre infrastructure. Pour débuter avec ansible, il faut donc bien organiser celui-ci.

Inventory ou fichier d’inventaire, c’est votre infrastructure

L’inventory n’est pas juste ce fichier mais celui-ci est central. Nous verrons dans le point suivant que l’inventaire est aussi composé de ses variables que nous nommons… variables d’inventaire.

L’inventaire comprend la liste de vos machines, il peut être de 3 types de formats : json, yaml, ini. Personnellement, je préfère le format yaml. Pourquoi ? tout simplement car :

• tous les autres fichiers ansible sont en format yaml, donc par souci d’homogénéité
• également car grâce à son indentation il permet de bien visualiser la hiérarchie des groupes et hosts (même si nous ne sommes pas toujours fan du format yaml).

Une machine est appelée host assez logiquement. Un ou plusieurs hosts peuvent consituer un groupe (group). Les hosts peuvent être décrit par des éléments permettant de les joindre : ip, dns principalement.

Et si vous avez des nomenclatures de serveurs adaptées, vous pourrez même gagner du temps en utilisant des patterns, par exemple : srv-bdd-[1-5].

Mettons maintenant tout cela en musique :

all:
  children:
    parent1:
      hosts:
        srv4:
      children:
        enfant1:
          hosts:
            srv1:
            srv2:
        enfant2:
          hosts:
            srv3:
          children
            enfant3:
              hosts:
                srv5:

Cela pour le format yaml, on a :

• le groupe parent de tous qui se nomme toujours ALL (non modifiable)
• le sous-groupe de ALL qui se nomme parent1 (à vous de choisir le nom)
• parent1 est composé d’un host srv4 et de deux sous-groupes : enfant1 et enfant2
• enfant1 est composé de srv1 et srv2
• enfant2 est composé de srv3 et un autre sous-groupe enfant3
• etc

Et maintenant pour le format ini.

[parent1]
srv4
[enfant1]
srv1
srv2
[enfant2]
srv3
[enfant3]
srv5
[parent1:children]
groupe1
groupe2
[enfant2:children]
enfant3

Et voilà l’essentiel. On peut également passer des variables directement dans ce fichier pour les associer à des groupes ou encore à des hosts. Mais je ne recommande pas de faire cela ou surtout il faut le limiter au maximum pour éviter que votre fichier d’inventaire ansible ne soit imbuvable.

Les variables d’inventaires ansible

Pour apprendre ansible, nous le reverrons mais il est important d’avoir un peu en tête la hiérarchie des variables ou précédence des variables… 22 types de variables au final dont certaines sont plus prioritaires que d’autres. Rassurez-vous vous n’avez pas besoin de toutes les connaître et surtout il faut éviter autant que possible de toutes les utiliser pour faciliter la maintenance de votre code.

Les formations ansible passent souvent assez rapidement sur les variables d’inventaires. C’est assez logique car sans mise en pratique c’est toujours délicat à aborder. Néanmoins il faut y passer quelques minutes pour bien débuter.

Notre fichier inventory est donc composé de hosts et de groupes. Nous allons donc pouvoir définir des variables de groupes et d’autres spécifiquement pour des hosts. Une fois que l’on a dit cela, il se dégage logiquement une hiérarchie ou précédence, les variables de hosts s’imposent aux variables de groupes. Ainsi, si vous avez un groupe de webserver avec une variable port = 80, si vous avez une exception dans ce groupe vous pourrez surcharger la variable de groupe par la variable du host en question port = 8080, par exemple.

Comment cela s’organise ?

Assez simplement au même niveau que notre inventory (le fichier), on va retrouver deux répertoires :

• group_vars
• host_vars

Une fois dans ces répertoires nous allons pouvoir créer soit :

• des répertoires par groupe avec le nom du groupe ou par nom de host, vous pourrez ainsi créer plusieurs fichiers car vous avez beaucoup de variables et donc un besoin d’organiser un maximum
• des fichiers yaml par nom de groupe ou nom de host car vous avez peu de variables.

├── 00_inventory.yml
├── group_vars
│   ├── all.yml
│   ├── dbserver.yml
│   └── webserver
│       ├── vault.yml
│       └── webserver.yml
└── host_vars
    ├── srv1
    │   └── srv1.yml
    └── srv2.yml

On retrouve bien :

• notre fichier d’inventaire 00_inventory.yml
• nos deux répertoires principaux toujours nommés group_vars et host_vars
• et des sous-répertoires ou fichiers

Et si vous avez différents environnements vous pouvez tendre vers cette organisation assez connue :

├── dev
│   ├── 00_inventory.yml
│   ├── group_vars
│   │   ├── all.yml
│   │   ├── dbserver.yml
│   │   └── webserver
│   │       ├── vault.yml
│   │       └── webserver.yml
│   └── host_vars
│       ├── srv1
│       │   └── srv1.yml
│       └── srv2.yml
├── prod
│   ├── 00_inventory.yml
│   ├── group_vars
│   │   ├── all.yml
│   │   ├── dbserver.yml
│   │   └── webserver
│   │       ├── vault.yml
│   │       └── webserver.yml
│   └── host_vars
│       ├── srv1
│       │   └── srv1.yml
│       └── srv2.yml
└── stage
    ├── 00_inventory.yml
    ├── group_vars
    │   ├── all.yml
    │   ├── dbserver.yml
    │   └── webserver
    │       ├── vault.yml
    │       └── webserver.yml
    └── host_vars
        ├── srv1
        │   └── srv1.yml
        └── srv2.yml

Prenez bien votre temps pour bien comprendre et retenir ce type d’organisation car vous la retrouverez souvent ou elle pourra repondre à votre besoin. Pour débuter avec l’inventaire ansible c’est déjà un très bon début.

Voici une petite démonstration qui va permettre de rendre parlant tout cela avec une variable que l’on va surcharger à différents endroits.

Mon dépôt de formation ansible ici.

Retrouvez également la documentation officielle concernant l’inventory ici.

English version : if you want to learn and start with ansible

L’article Ansible, son inventaire… et son organisation est apparu en premier sur Xavki.

• principes de base
• installations possibles
• premières commandes

Nous n’allons pas encore nous jeter dans le grand bain des rôles et playbooks. Pour un débutant, il est important de comprendre le fonctionnement de base d’un outil. En guise de formation et pour faire un premier pas avec la ligne de commande, je vous propose de pratiquer quelques commandes.

Retrouvez mon dépôt ici.

Et la vidéo associée :

La plus basique : le ping ansible

Pour savoir si ansible fonctionne de votre serveur/laptop source vers votre machine cible, nous pouvons utiliser le module ping. Attention, il ne s’agit pas là de faire un ping réseau ou icmp mais un ping au sens de ansible. En gros, ansible peut-il faire une connexion ssh vers la machine cible d’où vous le lancer.

Cela induit donc plusieurs paramètres : le serveur et le user. Il est important de ne pas oublier ce dernier car c’est avec lui que sera associé la clef ssh ou le password. L’utilisateur de départ qui initie la connexion est celui qui lance la commande ansible et l’utilisateur final peut être précisé par l’option -u.

Regardons la ligne ci-dessous :

ansible -i "node2," all -u vagrant -m ping

On a :

• -i : qui précise le serveur target/cible, cela peut être un nom dns ou une ip. Important,vous devez rajouter une virgule après ce n’est pas une erreur de frappe. Suivi de “all” qui définit le groupe qui par défaut est all, nous reverrons cela plus tard avec l’inventaire.
• -u : précise l’utilsiateur de la machine cible. Si vous utilisez une clef ssh c’est dans la conf ssh de ce user que vous devez avoir ajouté votre clef publique (dans le fichier authorized_keys).
• -k : si vous n’avez pas de clef publique ou que vous souhaitez utiliser une connexion ssh via un passowrd vous pouvez le faire avec cette option. Ansible proposera alors de le saisir après avoir lancé la commande.

Vous pouvez forcer l’utilisation du password ssh de cette manière :

ansible -i "node2," all -u vagrant -k --ssh-extra-args="-o 'PreferredAuthentications=password'" -m ping

Pour afficher le résultat sur une ligne :

ansible -i "node2," all -u vagrant -m ping --one-line

Pour utiliser à distance une commande sur le shell distant :

ansible -i "node2," all -u vagrant -m command -a uptime

Et voilà vous avez lancé un uptime à distance et récupéré son résultat.

Poussons plus loin dans l’utilisation de la CLI

Bien sûr on peut même aller plus loin avec la simple ligne de commande ansible. Je vous propose pour vous former quelques exemples qui vous permettront de vous aguerrir par la pratique et sans faire de code pour le moment.

Par exemple, par la ligne de commande nous pouvons définir une variable et afficher son résultat comme si nous étions sur le serveur distant.

ansible -i "node2," all -e "var1=xavki" -m debug -a 'msg={{ var1 }}'

Ainsi nous passons quelques nouvelles options :

• -e : pour définir une variable “var1” avec sa valeur “xavki”
• -m : pour préciser le module à utiliser, en l’occurence “debug”
• -a : pour définir un paramètre de ce module, nous définissons “msg” avec la valeur de var1. Remarquez le double accolade qui est un format jinja, ansible reposant sur python.

Maintenant lançons un shell un peu plus élaboré avec quelques pipe dans ansible :

ansible -i "node2," all -u vagrant -m shell -a "ps aux | grep vagrant | wc -l" --one-line

On retrouve toujours nos options et nous avons simplement changé de module en utilisant “shell”. Et on profite du oneline pour l’output.

Comment installer à distance un serveur nginx :

ansible -i "node2," all -b -m apt -a 'name=nginx state=latest'

Là encore changement de module pour “apt” et définition de deux paramètres de ce module avec -a.

De même pour arrêter ou redémarer le service systemd :

ansible -i "node2," all -b -m service -a 'name=nginx state=stopped'

Et encore un peu plus…

Et on peut pousser encore plus loin avec d’autres onelines très facile à comprendre et utiliser.

Comment faire l’équivalent d’un scp avec ansible en une ligne ?

ansible -i "node2," all -m copy -a 'src=toto.txt dest=/tmp/titi.txt'

On y définit le fichier source et la destination. Mieux qu’un scp, ansible va faire jouer son idempotence et ne réalisera cette action que si nécessaire. C’est à dire si le fichier n’existe pas ou si il est différent du fichier source.

Pour faire l’inverse et récupérer un fichier d’une machine distante ?

ansible -i "node2," all -m fetch -a 'src=/tmp/titi.txt dest=xavki.txt flat=yes'

Cette fois-ci on utilisera le module “fetch”, là encore en une ligne pour débuter tranquillement et apprendre à notre rythme.

Mais savez vous que à chaque run, ansible récupère ce que l’on appelle des facts, ce sont des variables génériques soit nécessaire pour son fonctionnement soit souvent utiles.

Eh bien regardons les facts disponibles pour une machine donnée :

ansible -i "node2," all -m setup -a "filter=ansible_distribution*"

Vous voyez que dans cette exemple, nous filtrons ceux-ci pour ne récupérer que les facts relatifs à la distribution.

Forez vous avec des tutorials ansible sur la chaine Xavki

L’article Commencer avec la CLI de ansible et quelques astuces est apparu en premier sur Xavki.

Ansible en quelques principes ?

Les principes d’ansible en font de lui un des plus faciles à adopter du marché. Totalement gratuit, il se base sur le langage python qui a fortement progressé ces dernières années agrandissant sensiblement son périmètre au fur et à mesure des années (IA, big data, statistiques, développement, CMS, framework…).

En outre, pour faciliter les choses, il se base sur une méthode de type push. A savoir que ansible ne nécessite pas d’agent. Mieux, une simple connexion ssh et python vous permettront de faire l’essentiel des tâches que vous aurez à réaliser. Un bon point pour les sysadmins qui restent fidèles à leurs scripts bash avec des boucles pour lancer un peu de ssh. Ou encore aux développeurs python qui utilisent paramiko avec une gestion délicate de l’idempotence… Ansible peut satisfaire vraiment beaucoup de monde.

Certains apprécieront moins son langage descriptif à base de yaml. Néanmoins, il permet de glisser sur la tendance et permet d’organiser clairement le code sous réserve de respecter les bonnes indentations. Un bon IDE vous y aidera d’autant plus.

Quelques éléments centraux :

• le fichier d’inventaire (inventory file) : facile à deviner, il permet de regrouper la liste des machines, des groupes de machines ou même des patterns de serveurs
• les variables d’inventaire : il s’agit des variables spécifiques à des hosts/serveurs ou à des groupes de machines. Elles sont stockées soit dans le fichier d’inventaire mais plutôt dans des répertoires host_vars et group_vars, respectivement pour les serveurs et les groupes de serveurs.
• le rôle : regroupe un ensemble de tâches ou d’actions cohérentes pour installer, configurer etc (par exemple installer un serveur web). Un rôle est constitué notamment d’actions que l’on appelle tasks.
• les tasks : ce sont des tâches individuelles qui utilise un module suivant des paramètres adaptés à la finalité de l’action
• le playbook : fichier permettant de faire la jointure entre l’inventaire et les rôles. Il a une fonction centrale qui permet de dire quel groupe ou quel serveur va avoir tels et tels rôles de joués.

Respecter ces principes est PRIMORDIAL pour la faciliter de l’organisation du code dans son ensemble. S’agissant de bonnes pratiques, n’importe quelle personne ayant suivie une formation ansible pourra s’y retrouver relativement facilement et pouvoir découvrir votre infra en lisant comme dans un livre (on l’oubli trop souvent).

Installer le binaire

Potentiellement il y a 3 choix pour installer ansible :

• via le gestionnaire de module python comme pip (pip3)
• via le téléchargement de la source
• via le gestionnaire de paquets de votre distribution préférée

Personnellement je préfère de loin cette dernière solution. Mais le contexte peut vous en faire décider autrement.

Sur debian on va simplement faire

sudo apt update

sudo apt install ansible

Et voilà le tour est joué. Vous pourrez très bien le faire sur redhat/centos/fedora car le projet ansible est porté par Redhat.

Pour configurer ansible, il est nécessaire de retenir un nom de fichier : ansible.cfg.

Vous pourrez le retrouver dans /etc/ansible/ ou encore dans votre home ou enfin à la racine de votre code (localisation du playbook).

Je vous invite à en découvrir plus sur la playlist de tutos ansible.

Premières commandes en CLI

Si vous avez installé ansible, vous êtes prêts à faire feu !!! Sauf si vous n’avez pas créé votre clef ssh. Dans ce cas, je vous propose une petite piqure de rappel ici.

Bref comment débuter et faire vos premières commandes ?

Pour pinguer les machines cibles.

ansible -i "node2," all -u vagrant -m ping

Attention, on parle d’un ping au sens ansible à savoir réussir une connexion ssh globalement.

-i : permet de préciser le fichier d’inventaire mais comme nous ne l’avons pas encore vu et que notre cible est une seule et unique machine on va simplement préciser cette machine entre double quote MAIS n’oubliez pas la virgule et le all (pour indiquer que cette machine fait partie du groupe all.

-u : permet de préciser l’utilisateur distant pour notre ssh ( <user>@<server>)

-m : permet de préciser l’utilisation d’un module, en l’occurence le module ping.

Dans notre cas nous avons une clef ssh mais on peut également faire la même chose par un password ssh :

ansible -i "node2," all -u vagrant -k -m ping

et si vous voulez forcer le fonctionnement par password pour une raison précise :

ansible -i "node2," all -u vagrant -k --ssh-extra-args="-o 'PreferredAuthentications=password'" -m ping

L’article Se former et apprendre Ansible et mettre un pied dans l’automatisation est apparu en premier sur Xavki.

Création de nos users

Pour cela nous allons industrialiser tout cela avec Ansible. Pour appel, nous avions nos mots de passe stockés sous les varaiables de group_vars/all/all.yml avec ceci :

users_password_xavki: "{{ vault_users_password_xavki }}"
users_password_xavier: "{{ vault_users_password_xavier }}"

Et ces variables faisaient appel à un fichier vault situé au même endroit dans group_vars/all/vault.yml mais chiffré par un mot de passe :

$ANSIBLE_VAULT;1.1;AES256
613362633865666266653364373533323263663137623536316431313933653331336239623437613232343965386434353761386436333663303533653862350a333939363463653663656563643966653035353666623165323434613434616334313163616663643763396635313636323666356437393665366339636561650a623032376634633634353132343539613962306132373230343232306234346664336231343866326532363930303566313262376264383231306664386462303461646432646433386535333432643337613138653365396132386261373362366463646564373830656265613239366334636361336462313039323064666432646161326463666635366663313539303136313965623430386435303466386634663161393438363134376138393137373033323565353065383465356638

Maintenant créons un répertoire dédié au stockage de nos clefs publiques (PUBLIQUES j’insiste) : files. Il s’agit des clefs que nous allons diffuser et installer dans la home de nos users. S’agissant de clefs publiques, un chiffrement n’est pas nécessaire, seule la clef privée est d’une importance capitale.

Maintenant modifions notre playbook de création des users :

- name: deploy users
  hosts: all
  become: yes
  vars:
    users_admin:
    - { name: "xavki", password: "{{ vault_users_password_xavki }}" }
    users_no_admin:
    - { name: "xavier", password: "{{ vault_users_password_xavier }}" }
  tasks:
  - name: create group admin
    group:
      name: "admin"
      state: present

  - name: create admin user accounts
    user:
      name: "{{ item.name }}"
      password: "{{ item.password | password_hash('sha512')}}"
      groups: "admin"
    with_items:
    - "{{ users_admin }}"
    no_log: true
 
  - name: create standard user accounts
    user:
      name: "{{ item.name }}"
      password: "{{ item.password | password_hash('sha512')}}"
    with_items:
    - "{{ users_no_admin }}"
    no_log: true

  - name: add authorized keys
    authorized_key:
      user: "{{ item.name }}"
      key: "{{ lookup('file', 'files/'+ item.name + '.key.pub') }}"
    with_items: 
    - "{{ users_admin }}"
    - "{{ users_no_admin }}"
 
  - name: "Allow admin users to sudo without a password"
    lineinfile:
      dest: "/etc/sudoers"
      state: "present"
      regexp: "^%sudo"
      line: "%admin ALL=(ALL) NOPASSWD: ALL"

La tâche “add authorized keys” nous permet donc de récupérer ces clefs et de les placer par défaut dans la hoem de chaque users et selon la bonne pratique avec un répertoire “.ssh”.

Voici donc pour le déploiement de nos clefs correspondantes pour chaque utilisateurs.

Retrouvez les fichiers ici.

Suppression du user PI

Pour supprimer un utilisateur, la démarche est très simple, il suffit d’ajouter la tâches suivante :

- name: remove pi user
  user:
    name: "pi"
    state: absent

Profitons-en pour faire un peu d’organisation et de bonnes pratiques ansible. Pour cela nous allons utliser le principe de rôle. Un rôle est une sorte de module/librairie/fonction qui peut être appelé autant que nécessaire.

Pour cela nous allon créer un répertoire “roles” à la racine de notre ansible et taper la commande :

mkdir roles && cd roles
ansible-galaxy init users

Cette commande créée toute la structure nécessaire pour créer le contenu d’un rôle. A l’heure actuelle ce qui nous intéresse c’est uniquement le répertoire task et son fichier main.yml. C’ets la première chose qui est appelé quand on lance un rôle. Donc dans ce fichier nous recopions le conteneur de notre users.yml.

Ensuite il nous faut modifier notre playbook pour appeler le rôle et non plus les tâches une à une :

- name: deploy users
  become: yes
  hosts: all
  roles:
  - users

Et voilà le tour est joué. il ne reste plus qu’à jouer le playbook :

ansible-playbook -i list_servers.yml -u xavki users.yml

Retrouvez les fichiers ici.

L’article Raspberry et Ansible : gestion des clefs SSH et suppression du user par défaut est apparu en premier sur Xavki.

Pour apprendre à l’utiliser, je vous propose d’installer une stack très utile :

• haproxy : reverse-proxy et load-balancer très réputé
• consul : la registry de service dont je vous ai déjà parlé sur le blog et la chaine youtube
• consul-template : un binaire qui va permettre de modifier automatiquement la conf de haproxy en cas de modification dans la composition et l’état des services de consul

En 9 courtes vidéos, vous allez pouvoir faire coup double :

1. Installation de haproxy : rôle, apt
2. Installation de consul : unarchive, wget
3. Création du user consul : user, group
4. Structurer ses tâches : include task
5. Gestion des configurations : templates
6. Création d’une application de test
7. Mise en place d’un service système D
8. Installation du binaire consul-template
9. Finalisation de consul-template : utilisation de blockinfile, du jinja dans du jinja

Grâce à ces vidéos, vous allez pouvoir rendre dynamique votre configuration haproxy et réaliser un haproxy reload si nécessaire.

L’article Ansible – Comment installer la stack haproxy, consul et consult template de manière orchestrée ? est apparu en premier sur Xavki.

Ansible regorge d’astuces qu’il faut engranger pour pouvoir aller plus loin et ne pas simplement installer des paquets sur des machines distantes. Par exemple, nous allons voir aujourd’hui une valorisation des gather_facts de ansible. Sur puppet, je crois que la même chose est réalisable avec facter.

Gather_facts c’est la possibilité d’utiliser des variables d’environnement ansible. Ce sont principalement des caractéristiques de la machine (interface, os…). Ces données vous vous en doutez seraient bien utiles dans une cmdb (centralisation d’informations de votre parc de machine).

Pour commencer cette démos nous allons commencer par créer quelques machines à l’aide de mon script maison (vous pouvez aussi le découvrir en vidéo désormais). Dans mon cas, j’ai 2 vm debian qui fonctionnent avec du ssh (merci docker).

└─ $ ▶ ./deploy-centre-sans-proxy-v2.sh --infos
#### Récap des conteneurs de tests ####
=> /oki-deb-vmparc3 - 172.17.0.3 - Utilisteur : oki / mdp:password
=> /oki-deb-vmparc2 - 172.17.0.2 - Utilisteur : oki / mdp:password

Maintenant nous allons configurer notre inventory hosts.yml très simplement :

all:  hosts:    172.17.0.2:    172.17.0.3:

Objectif ?

Notre souhait c’est d’utiliser les gather_facts et faire en sorte que ansible centralise tout cela sous forme de fichiers.html. Ainsi nous pourrons faire de la datavisualisation avec un apache installé localement (attention c’est pour la démo, c’est très moyen d’installer un serveur web sur une machine qui a la main sur tout votre parc).

Enfin, grâce à notre apache on pourra afficher dans un navigateur web. Et vous verrez ce qui compte c’est le principe car derrière c’est assez facile d’avoir des idées pour compléter tout cela pour avoir un bon début de cmdb.

Comment lister les gather_facts à notre dispostion ?

Les gather_facts sont accessibles via le module setup de ansible. Donc pour consulter toutes ces variables voici la commande à réaliser :

ansible all - i hosts.yml -u oki -m "setup"

La liste est assez longue et c’est plutôt une bonne nouvelle.

Faisons nos courses et retenons les variables :

• inventory_hostname
• ansible_default_ipv4.alias
• ansible_architecture
• ansible_distribution
• ansible_distribution_version

Et on met tout cela en forme dans un template jinja2 pour générer à terme un fichier html :

<h1>Machine : {{ inventory_hostname }}</h1>
<ul>
<li>Interfaces : {{ ansible_default_ipv4.alias }}</li>
<li>Architecture : {{ ansible_architecture }}</li>
<li>OS : {{ ansible_distribution }}</li>
<li>Version : {{ ansible_distribution_version }}</li>
</ul>

Maintenant le playbook !

Voici le contenu de notre répertoire :

.
├── hosts.yml
├── playbook-cmdb.yml
└── templates
└── listing_ipv4.html.j2

Editons donc le playbook-cmdb.yml de la manière suivante :

---
- name: "[IP v4 listing]"
  hosts: all
  gather_facts: yes
  tasks:
    - name: "[IP v4 listing] - generate html"
      template:
        src: listing_ipv4.html.j2
        dest: "/var/www/html/{{ inventory_hostname }}.html"
      connection: local

Première chose on spécifie l’utilisation des gather_acts. Ensuite on utilise le module template pour faire appel au fichier jinja2. Puis on indique comme destination le répertoire de notre apache /var/www/html/ (de la machine master host). C’est aussi pour cela que nous spécifions connection : local.

Maintenant lançons la commande ansible-playbook :

ansible-playbook -i hosts.yml -u oki playbook-cmdb.yml

Et bingo :

PLAY [[IP v4 listing]] *******************************

TASK [Gathering Facts] *******************************
ok: [172.17.0.3]
ok: [172.17.0.2]

TASK [[IP v4 listing] - generate html] ***************
changed: [172.17.0.3]
changed: [172.17.0.2]

PLAY RECAP *******************************************
172.17.0.2 : ok=2 changed=1 unreachable=0 failed=0 
172.17.0.3 : ok=2 changed=1 unreachable=0 failed=0

Supprimons l’index de notre apache local : rm -f /var/www/html/index.html

Remarque : j’ai confié les droits de ce réprtoire à oki pour cet exercice

Et voici le résultat, une fiche par machine :

Puis la fiche de la machine :

C’est bon tout ça non ? On comprend mieux l’intérêt des facts avec ce genre d’outils d’orchestration. Et ne vous inquiétez pas vous pouvez aisément pousser les fichier vers une autre machine qui portera un service apache de manière isolée.

L’article [Ansible] – comment utiliser les gather_facts et tenir à jour un début de cmdb ? est apparu en premier sur Xavki.

Poursuivons notre découverte de ansible avec l’installation d’un applicatif en l’occurence wordpress. Chaque applicatif possède toutefois des manières différentes de s’installer, il s’agit juste là de prendre un exemple pour se faire la main.

Vous pouvez retrouver cet article en vidéo :

La première chose à faire dans notre rôle est de vérifier si wordpress existe déjà :

- name: "[WORDPRESS] - check if exist"
  stat: 
    path: "/var/www/html/wordpress/"
  register: check_wordpress

Avec stat, nous vérifions si le répertoire wordpress est déjà là et nous alimentons l’état de ce répertoire dans une variable avec register. Notre variable s’appelle donc check_wordpress.

Utilisons maintenant cette variable pour conditonner à celle-ci le téléchargement de l’archive tar.gz.

- name: "[WORDPRESS] - download tar.gz"
  unarchive:
    src: "{{ wordpress_source }}"
    dest: "/var/www/html/"
    remote_src: yes
  when: check_wordpress.stat.exists == False

Avec unarchive, nous procédons au téléchargement en ligne car la variable wordpress_source est une url de téléchargement. Par ailleurs pour pouvoir télécharger une url on utilise remote_src. Et enfin notre condition avec le when.

Après nous procédons à la suppression de index.html que notre apache à installer par défaut.

- name: "[WORDPRESS] - index.html"
  file: 
    path: "/var/www/html/index.html"
    state: absent

Pour cela nous utilisons le module file avec un state à absent.

A la première installation, le fichier wp-config.php se nomme wp-config-sample.php. Nous vérifions donc si nous sommes dans ce cas.

- name: "[WORDPRESS] - exist wp-config-sample.php"
  stat:
    path: "/var/www/html/wordpress/wp-config-sample.php"
  register: check_sample

Nous procédons comme pour le répertoire wordpress en vérifiant la présence de wp-config-sample.php.

Si c’est le cas nous le renommons.

- name: "[WORDPRESS] - rename wp-config-sample.php"
  command: mv /var/www/html/wordpress/wp-config-sample.php /var/www/html/wordpress/wp-config.php 
  when: check_sample.stat.exists == True

Enfin nous procédons à  la modification de plusieurs ligne dans ce même fichier pour configurer celui-ci en fonction de notre serveur base de données.

- name: "[WORDPRESS] - config wp-config.php"
  lineinfile:
    dest: "/var/www/html/wordpress/wp-config.php"
    regexp: "{{ item.search }}"
    line: "{{ item.new }}"
    backrefs: yes
  with_items:
    - {'search': '^(.*)database_name_here(.*)$', 'new': '\1{{ mysql_db }}\2'}
    - {'search': '^(.*)username_here(.*)$', 'new': '\1{{ mysql_user }}\2'}
    - {'search': '^(.*)password_here(.*)$', 'new': '\1{{ mysql_password }}\2'}

Pour chaque ligne définie dans le with_items, nous recherchons un élément (ex : database_name_here) et compturons les éléments présents avant et après. Ensuite nous remplaçons cette ligne par une nouvelle ligne contenant le premier élément capturé puis notre variable puis le deuxième élément capturé.

Et voilà pour notre installation de wordpress. Vous pouvez retrouver tout le code sur mon github.

L’article Ansible – installer un applicatif (ex. WordPress) est apparu en premier sur Xavki.