Archives de catégorie : Ansible

Ansible – Comment créer un user et une base mysql ?

Cela fait quelques temps que je n’ai pas posté d’article ansible. La chaîne youtube prend pas mal de temps mais j’aime beaucoup le blog. Le mode écrit est tout de même bien sympa.

Mon orchestrateur préféré est une vraie mine d’or pour ce qui est de gérer les petites actions du quotidien et c’est aussi le cas en matière de base de données. De nombreuses actions sont natives sur ansible (moyennant d’avoir installé le module python qui va bien pour pouvoir le faire).

Si vous souhaitez la version vidéo de cette article, la voici :

Sinon pour la version écrite. Commençons par définir quelques variables dans notre rôle mysql.

Commençons par définir quelques variables dans notre répertoire defaults de notre rôle mysql.

mysql_packages:
  - mysql-server
  - python-mysqldb
mysql_db: "wordpress"
mysql_user: "user1"
mysql_password: "password"

On y retrouve la liste des paquets à installer à savoir mysql-server et python-mysqldb. C’est ce dernier qui permet à ansible d’interagir avec le moteur mysql.

Ensuite éditons notre fichier main.yml dans le répertoire tasks.

- name: "[MYSQL] - update cache"
  apt:
    update_cache: yes

- name: "[MYSQL] - install"
  apt:
    name: "{{ mysql_packages }}"
    state: latest

- name: "[MYSQL] - start mysql"
  service:
    name: "mysqld"
    state: started
    enabled: yes



Jusque là rien de neuf si ce n’est que la dernière version de ansible nous demande de ne plus utiliser le with_items. En effet, nous pouvons désormais passer directement un tableau. On installe les paquets et active le démarrage de mysql au lancement de notre machine.

Ensuite rentrons dans l’administration mysql.

- name: "[MYSQL] - create database"
  mysql_db:
    name: "{{ mysql_db}}"
  become: yes

Là on vient de créer la base de données dont le nom a été défini dans nos variables par défauts (et donc que l’on peut écraser facilement par les variables d’inventory).

- name: "[MYSQL] - create user"
  mysql_user:
    name: "{{ mysql_user }}"
    password: "{{ mysql_password }}"
    priv: "*.*:ALL"
    host: "127.0.0.1"
  become: yes

Là on vient de créer un user et de lui donner tous les droits sur les bases de notre moteur (nous aurions pu limiter tout ceci bien sûr).

Voici donc pour la découverte du module mysql de ansible. Mais sachez qu’il existe la même chose pour :

  • influxdb
  • mongodb
  • postgres
  • proxysql

En savoir plus sur la documentation officielle de ansible à ce sujet.

Ansible – installer un serveur LAMP automatiquement

Hello la team ! j’espère que vous allez bien. A priori, c’est kool vous êtes nombreux à revenir sur le blog vu les statistiques.

La chaîne youtube marche bien aussi et là encore c’est grâce à vous.

Aujourd’hui, je vous propose de revenir sur ansible avec une vidéo qui vous fait découvrir assez simplement comment installer un serveur LAMP de manière orchestrée. Cela est assez simple et tient sur quelques lignes.

Voici la vidéo :

[youtube https://www.youtube.com/watch?v=xthwCR-uHyo&w=700&h=500]

N’oubliez pas que vous pouvez vous abonner à la chaine ou aussi mettre des petits pouces bleus pour m’encourager.

Qu’est-ce que l’on fait dans cette vidéo ?

1- Création du squelette d’un rôle ansible

A la racine, c’est à dire là on l’on trouve notre playbook et notre fichier d’inventory, on créé un répertoire rôles. Comme son nom l’indique c’est ici que nous stockerons les rôles développés ou récupérés de Galaxy. Pour créer la structure d’un rôle lançons :

ansible-galaxy init wordpress

Il ne nous reste plus qu’à éditer nos fichiers et en particulier le fichier mai.yml situé dans le répertoire tasks. C’est la clef d’entrée dans notre rôle.

2- Edition de main.yml dans tasks

La première chose à faire c’est de commencer par mettre à jour le cache de apt. C’est la moindre des choses avant d’installer des paquets.

- name: "[WORDPRESS] - update cache"
  apt:
    update_cache: yes
  become: yes

Le become à yes permet de réaliser une élévation de privilèges comme pour faire un sudo. Et nous utilisons le module apt.

- name: "[WORDPRESS] - install LAMP"
  apt:
   name: "{{ item }}"
   state: latest
  become: yes
  with_items: 
    - apache2
    - mysql-server
    - php7.0-common
    - php7.0-mysql
    - libapache2-mod-php7.0
    - python-mysqldb
    - wget

Vous pouvez le voir nous allons plus loin qu’un simple LAMP. Cela nous permettra d’aller plus loin par la suite dans notre installation de notre wordpress.

Puis lançons le démarrage de nos services :

- name: "[WORDPRESS] - start apache2 mysql"
  service:
    name: "{{ item }}"
    state: started
    enabled: yes
  become: yes
  with_items:
    - apache2
    - mysqld

Ici nous avons utilisé le module service qui nous permet d’intervenir sur systemd.

Vous pouvez aller plus loin en consultant les articles et vidéos spécifiques à ansible sur cette page.

 

 

 

Ansible – les différents niveaux de variables

Ansible est un orchestrateur simple d’utilisation dès lors que l’on en retient les concepts de base. Parmi ces concepts, la hiérarchie des variables fait partie des essentiels.

Je vous propose d’y revenir en vidéo.

[youtube https://www.youtube.com/watch?v=_8Az2egUKwY&w=700&h=500]

D’ailleurs n’hésitez pas à vous abonner à la chaine xavki.

Au total, Ansible possède plus de 20 manières pour définir des variables. On peut les classer par ordre hiérarchique en fonction de s’imposer les unes aux autres. Je ne reviendrais pas sur l’ensemble des 20 variables mais sur les plus courantes. Néanmoins voici la liste de ces variables ordonnée hierarchiquement :

ansible-v2-and-beyond-ansible-nyc-meetup-19-638

Les principales qui me semblent importantes à retenir sont :

  • 1. extra vars : passable à partir de la command line
  • 2. task vars : variable de tâche (dans le playbook)
  • 3. block vars : la variable de block
  • 4. role vars : dans le répertoire /vars d’un rôle
  • 5. set_facts : définie dans les set_facts
  • 6. playbook vars : dans le fichier playbook
  • 7. host_vars : précisée dans les fichiers individuels des machines de l’inventaire
  • 8. inventory vars : dans l’inventaire (par exemple hosts.yml)
  • 9. group_vars : dans les fichiers de groupes de l’inventaire
  • 10. role defaults vars : la variable par défaut

Un rôle bien rédigé doit être très largement paramétrable : OS, paquets, version, user, passwords… Ainsi un bon rôle possède souvent un fichiers de variables par défaut (répertoire defaults du rôle) très fourni. Cela vous permet de personnaliser très largement l’application de ce rôle.

En outre, un bon rôle doit aussi avoir l’intégratilité de ses variables définies dans son README, en tout cas au moins toutes les variables par défaut. Elles doivent alors être documentées sur la manière de les définir (liste, string, booléens…).

Par ailleurs, vous pouvez utiliser le module debug pour afficher le contenu des variables à n’importe quel moment de votre playbook.

- name: "affichage contenu de var1"
  debug:
    msg: "Voici le contenur de var1 => {{ var1 }}"

Il faut aussi savoir que ansible n’aime pas traiter les variables vides.

Enfin ansible possède des variables particulières propres à son fonctionnement, on parle de facts (version OS, etc…). Celles-ci sont utilisables à tout moment. Pour les connaître utilisez le module setup :

 ansible all -m setup

Vous pouvez également créer vos propres facts.

Ansible – prise en main de checksum, set_facts, register et block

Ansible c’est un peu le fil rouge du moment. Certains l’ont bien vu avec le lancement de la chaine youtube xavki. L’idée c’est de vous montrer comment j’ai appris à utiliser et développer avec ansible.

La vidéo ci-dessous présente ce que nous allons découvrir dans l’article.

[youtube https://www.youtube.com/watch?v=YqKAXnmAetY&w=700&h=300]

L’objectif du jour, c’est de charger un fichier avec l’aide d’ansible, de le modifier et surtout faire en sorte qu’une fois ces opérations réalisées nous gérions la réentrance (ou idempotence). C’est à dire que si nous relançons aussitôt le playbook ansible aucun opération ne soit réalisée.

Or sans vérification du contenu du fichier, le fichier est systématiquement rechargé. Pourquoi ?

Tout simplement car ansible va contrôler l’état du fichier présent sur la cible avec celui présent sur la source. Et malheureusement ansible ne sait pas prendre en compte les diverses opérations qu’il aura réalisé sur le fichier après son chargement. Donc il est systématiquement différent du fichier source.

Comment vérifier l’état du fichier ? de cette manière peut être (si vous avez mieux je suis preneur.

---
- name: "[XAVKI]"
  hosts: all
  vars:
    - check5: "2789ebeb61ab3b1985e9f6df9256d8a1" 
  tasks:

      - name: "[XAVKI] - check md5"
        stat:
          path: /tmp/xavki.txt
          get_checksum: yes
          checksum_algorithm: md5
        register: sum5

      - set_fact:
          data: "0"
        when: sum5.stat.checksum is not defined

      - set_fact:
          data: "{{ sum5.stat.checksum }}"
        when: sum5.stat.checksum is defined

      - name: "[XAVKI] - Bloc"
        block:
        - name: "[XAVKI] - copie du fichier" 
          copy:
            src: ./monfichier.txt
            dest: /tmp/xavki.txt

        - name: "[XAVKI] - add line"
          lineinfile:
            path: /tmp/xavki.txt
            line: "ajout d'une ligne" 

        when: data != check5

Voici le cheminement :

  • tout d’abord on calcul et on place dans une variable le md5 du fichier dans l’état final souhaité (check5 en l’occurence), c’est notre référence
  • à l’aide du module stat on place avec register la valeur du fichier déjà présent dans une variable (sum5)
  • nous devons traiter alors 2 cas de figures : la variable est définie car le fichier existe ou il n’existe pas et la variable n’est pas définie
  • si la variable existe on attribue à la variable data la valeur du sum5 sinon on lui donne la valeur « 0 »
  • enfin on encapsule dans un bloc avec le module block les actions de chargement de fichier et de modification si data ne vaut pas la valeur finale souhaitée (avec when)