Dans le billet précédent (https://blog.atolcd.com/ansible/) nous avons abordé succinctement ce qu’était Ansible et ses potentielles utilisations. Au sein du pôle ECM d’Atol CD, nous avons fait le choix d’utiliser cet outil pour nous aider au quotidien.
Objectifs
Le pôle ECM d’Atol CD utilise d’ores et déjà des technologies de déploiement automatisé pour la mise en oeuvre de serveurs de démonstration mais aussi pour permettre aux développeurs d’avoir des environnements de développement au plus proche de l’installation en production. Cette automatisation est rendue possible grâce à Puppet (https://puppet.com/). Ce dernier est également utilisé pour l’infogérance de notre cloud.
Le choix d’Ansible au sein du pôle ECM est régi par différents objectifs:
- fournir un moyen de déployer un environnement de développement couplé avec le gestionnaire de machine virtuelle Vagrant (https://www.vagrantup.com/)
- fournir un moyen de déployer les solutions Alfresco chez nos clients qui ne nécessite que très peu de pré-requis, qui soit fiable et facile d’utilisation (déploiement de modules par exemple)
- fournir un moyen de provisionner au sein d’Atol CD les serveurs de démonstration tout en maintenant la cohabitation avec Puppet
- rédiger et ne maintenir qu’un seul code et garder une uniformité dans nos différents déploiements
- dissocier le déploiement Alfresco de l’infogérance assurée par notre service réseaux
Périmètre fonctionnel actuel
Aujourd’hui les travaux sur Ansible permettent d’effectuer les actions suivantes :
- installation des briques nécessaires pour Alfresco Content Services dans les versions 6.0 ou supérieures
- déploiement et redéploiement de modules (compatibles également avec les version 5.X d’Alfresco)
- customisation/paramétrage de l’installation
- possibilité d’éclater les services sur différents noeuds
- recopie d’environnements par exemple de production vers formation. (Attention toutefois aux volumétries trop importantes)
# L’utilisation des playbook dans la pratique
Voyons comment se construit une commande ansible-playbook pour jouer un provisionning
Anatomie de la commande
ansible-playbook -i mon_inventaire.yml playbook.yml –extra-vars ”@variables.yml” –limit serveur_cible
La commande ansible-playbook va jouer un scénario rédigé dans playbook.yml sur le serveur_cible défini dans mon_inventaire.yml. Le fichier variables.yml précisé permet de spécifier des valeurs particulières à appliquer lors de l’installation.
Par exemple, cela peut être une règle de configuration dans le fichier pg_hba.conf de postgresql pour autoriser un serveur externe à consulter la base de données ou les versions des briques à installer comm tomcat, activemq, etc.
Démonstration
Dans cette démonstration nous utilisons Vagrant pour créer deux machines virtuelles Ubuntu 18.04.
L’objectif est de déployer sur ces machines deux environnements Alfresco via Ansible. Nous allons donc créer un inventaire pour Ansible une fois les machines virtuelles opérationnelles.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 |
all: children: db: hosts: acs1: acs2: acs: hosts: acs1: acs2: ass: hosts: acs1: acs2: activemq: hosts: acs1: acs2: reverse_proxy: hosts: acs1: acs2: demonstration: hosts: acs1: ansible_host: 127.0.0.1 ansible_ssh_port: 2200 ansible_user: 'vagrant' ansible_ssh_private_key_file: '/home/XYZ/projets/vagrant/dual/vagrant/.vagrant/machines/acs1/virtualbox/private_key' acs2: ansible_host: 127.0.0.1 ansible_ssh_port: 2222 ansible_user: 'vagrant' ansible_ssh_private_key_file: '/home/XYZ/projets/vagrant/dual/vagrant/.vagrant/machines/acs2/virtualbox/private_key' |
NB : notons qu’il existe un module de provisionning Ansible spécifique à Vagrant (https://www.vagrantup.com/docs/provisioning/ansible.html). Ce dernier est très pratique pour exécuter des playbooks dès l’initialisation de la machine virtuelle. Dans ce cas, c’est Vagrant qui va constituer lui-même son inventaire et faire appel à un playbook en fonction des informations inscrites dans son fichier de configuration Vagrantfile. Son utilisation peut être faite pour rendre le plus transparent possible le provisionning.
Dans le cadre de notre démonstration nous utilisons un fichier de variables qui s’appliquera à chaque instance. Il est évidemment possible d’appliquer des variables différentes par environnement mais cela se ferait dans le fichier d’inventaire. Aujourd’hui plus d’une centaine de variables sont disponibles pour personnaliser les déploiements.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 |
# Postgresql postgresql_version: 11 # Tomcat tomcat_version: 8.5.43 # ACS acs_version: 6.2.0 acs_type: enterprise acs_csrf_enable: true acs_global_properties_custom: - {key: "local.transform.service.enabled", value: "false"} acs_pdf_render_version: 1.1 ## REPO MODULES acs_modules_repository: - { name: 'com.atolcd.alfresco.repository', version: '6.2.0-SNAPSHOT'} ## SHARE MODULE acs_modules_share: - { name: 'com.atolcd.alfresco.share', version : '6.2.0-SNAPSHOT'} # ASS ass_version: '1.4.1' # Apache2 apache2_ServerName: atolcd-alfresco-ansible.atolcd.show apache2_serveraliases: - atolcd-alfresco-ansible.atolcd.show |
Nous allons effectuer l’installation sur le groupe noeuds, ‘demonstration’ (cf inventaire) grâce à la commande suivante et son paramètre –limit :
|
1 |
ansible-playbook -i ansible/inventories/staging/blog.yml ansible/playbooks/acs/playbook.yml --extra-vars "@var_test.yml" --limit demonstration |
Puisque les images valent mieux que des mots, nous vous invitons à vous relaxer durant quelques minutes devant la vidéo ci-dessous, qui résume une installation de deux environnements Alfresco, postgresql sous un environnement Ubuntu.
Ainsi se concluent nos deux billets introductifs sur Ansible !
Laisser un commentaire