Rôle Ansible : Installe et personnalise ISPConfig 3 sur Ubuntu Bionic

Le rôle inoxio.ispconfig3 vous aidera à installer ISPConfig sur votre machine Ubuntu 18.04. Il suit les instructions du tutoriel de howtoforge.com et permet des personnalisations qui seront expliquées dans les segments suivants. Il utilise également Molecule comme environnement de test et contient quelques conseils si vous souhaitez utiliser Molecule par vous-même.

Exigences

• Machine avec Ubuntu 18.04

Dépendances

• oefenweb.apt

Variables du rôle

Les variables Mail, PHPMyAdmin et Roundcube définissent principalement les mots de passe des administrateurs des applications mentionnées. Mail lui-même aura aussi besoin d'un e-mail pour envoyer des mails.

ISPConfig est ici la partie la plus importante, il contient de nombreuses variables différentes. La plupart d'entre elles peuvent être traduites dans le autoinstall.php d'ISPConfig. Il est également important de noter que le mot de passe du mysql_root_password sera utilisé pour la configuration du module MariaDB.

Variables du Playbook : Les variables suivantes sont requises dans le playbook (sauf les mots de passe, qui seront générés si laissés vides). Il y a des vérifications pour s'assurer que ces variables sont déclarées dans le playbook. Les variables par défaut peuvent être écrasées dans le playbook.

Mail : Cela va définir toutes les variables nécessaires pour configurer une nouvelle liste de diffusion. Cela va automatiquement créer une liste de diffusion avec les paramètres donnés.

• mail_admin_email : Mail qui enverra/recevra des mises à jour de Mailman.

• mail_admin_password : (Optionnel) Mot de passe pour l'administrateur Mailman. Si aucun mot de passe n'est défini, un mot de passe sera généré et imprimé à la fin de l'exécution du rôle.

• mail_base_domain : Domaine de base pour Mailman.

• phpmyadmin_hostname : Domaine de base pour phpmyadmin.

• roundcube_admin_password : (Optionnel) Mot de passe pour la connexion d'administration dans Roundcube. Si aucun mot de passe n'est défini, un mot de passe sera créé et imprimé à la fin de l'exécution du rôle.

ispconfig : Cela contient la plupart des configurations pour votre installation ISPConfig. Veuillez consulter l'exemple fourni par ISPConfig lui-même. Vous pouvez le trouver ici.

• ispconfig_admin_password : (Optionnel) Mot de passe pour la connexion administrateur d'ISPConfig. Si aucun mot de passe n'est défini, un mot de passe sera généré et imprimé à la fin de l'exécution du rôle.

• ispconfig_mysql_root_password : (Optionnel) Mot de passe de l'utilisateur root, merci de choisir un mot de passe sécurisé. Même si votre base de données n'est pas exposée. Si aucun mot de passe n'est défini, un mot de passe sera généré et imprimé à la fin de l'exécution du rôle.

• ispconfig_mysql_ispconfig_password : (Optionnel) Identifiant pour MySQL. Si aucun mot de passe n'est défini, un mot de passe sera généré et imprimé à la fin de l'exécution du rôle.

• ispconfig_mysql_master_root_password : (Optionnel) Mot de passe pour l'utilisateur root de la base de données principale. Si aucun mot de passe n'est défini, un mot de passe sera généré et imprimé à la fin de l'exécution du rôle.

• ispconfig_hostname : Nom de l'hôte ISPConfig.

• roundcube_hostname : Nom de l'hôte roundcube.

• quota_mounts : Liste de tous les répertoires à remonter pour quota. Voir la section "Quota".

Variables par défaut :

• language : Langue au niveau système.

• mailing_list_name : Définit la liste Mailman. Il est recommandé de le définir comme Mailman (voir l'exemple de playbook).

  • Par défaut : Mailman

• ispconfig_install_mode : Définissez le mode que vous souhaitez ; si vous voulez simplement l'installer normalement, il est recommandé d'utiliser le défaut.

  • Par défaut : standard

• ispconfig_hostname : utilisé pour votre FQDN où vous pouvez définir le nom de votre site.

• ispconfig_mysql_hostname : Emplacement où la base de données MySQL s'exécute ; si vous n'utilisez que ce rôle, la valeur par défaut est suffisante.

  • Par défaut : localhost

• ispconfig_mysql_root_user : Nom de l'utilisateur root. Dans la plupart des cas, ce sera juste 'root'. Si vous personnalisez votre ISPConfig, définissez-le comme bon vous semble. Cela définira également le nom de l'utilisateur root dans la configuration de MariaDB.

  • Par défaut : root

• ispconfig_mysql_database : Base de données qui sera initialisée dans la configuration de MariaDB et utilisée par ISPConfig.

  • Par défaut : dbISPConfig

• ispconfig_mysql_ispconfig_user : Utilisateur qui sera créé dans la base de données MySQL.

  • Par défaut : ISPConfig

• ispconfig_mysql_port : Port utilisé par MariaDB, il est également utilisé pour l'initialisation de la base de données.

  • Par défaut : 3306

• ispconfig_mysql_charset : Jeu de caractères de la base de données.

  • Par défaut : utf8

• ispconfig_http_server : Définit le serveur HTTP qui fonctionne derrière le site ISPConfig.

  • Par défaut : apache

• ispconfig_ispconfig_port : Port pour le site web à utiliser.

  • Par défaut : 8080

• ispconfig_ispconfig_use_ssl : Utiliser SSL pour se connecter à ISPConfig.

  • Par défaut : y

• ispconfig_join_multiserver_setup : Rejoindre plusieurs serveurs.

  • Par défaut : n

• ispconfig_mysql_master_hostname : Emplacement de la base de données MySQL principale ; dans la plupart des cas, 'localhost' est suffisant.

  • Par défaut : localhost

• ispconfig_configure_mail : Configuration de Mailman pour ISPConfig.

  • Par défaut : y

• ispconfig_configure_jailkit : Configuration de Jailkit pour ISPConfig.

  • Par défaut : y

• ispconfig_configure_ftp : Configuration de PureFTP pour ISPConfig.

  • Par défaut : y

• ispconfig_configure_dns : Configuration DNS pour ISPConfig.

  • Par défaut : y

• ispconfig_configure_nginx : Configuration de NGINX pour ISPConfig.

  • Par défaut : n

• ispconfig_configure_apache : Configuration d'Apache pour ISPConfig.

  • Par défaut : y

• ispconfig_configure_firewall : Configuration du pare-feu pour ISPConfig.

  • Par défaut : y

• ispconfig_install_ispconfig_web_interface : Configuration de l'interface web pour ISPConfig.

  • Par défaut : y

• ispconfig_do_backup : Configuration de la sauvegarde pour ISPConfig.

  • Par défaut : yes

• ispconfig_mysql_master_database : Base de données contenant les informations pour ISPConfig.

  • Par défaut : dbISPConfig

• ispconfig_reconfigure_permissions_in_master_database : Définit les autorisations nécessaires pour ISPConfig dans la base de données.

  • Par défaut : no

• ispconfig_reconfigure_services : Reconfigure tous les services.

  • Par défaut : yes

• ispconfig_create_new_ispconfig_ssl_cert : Crée un nouveau certificat (ne sera pas nécessaire).

  • Par défaut : no

• ispconfig_reconfigure_crontab : Configure le cronjob.

  • Par défaut : yes

• ispconfig_configure_webserver : Configure le serveur web.

• quota_mounts : Liste des répertoires que le quota surveillera.

  • Par défaut : /

Quota

La liste quota_mounts dans defaults/main.yml contient tous les répertoires qui seront modifiés dans le fichier fstab pour activer le quota dessus. Si la liste est vide, le quota ne sera pas activé. Vous pouvez écraser cette liste en ajoutant la variable quota dans le playbook (voir section "Variables du rôle"). Si le noyau de votre machine ne contient pas les modules de quota, vous devez garder la liste vide. C'est le cas pour les machines AWS qui utilisent le noyau linux-aws.

Versions multiples de PHP

Vous pouvez spécifier plusieurs versions de PHP dans vars/main.yml, qui seront installées.

Exemple de Playbook

Voici un exemple de la façon dont vous pourriez configurer votre playbook.

- role: inoxio.ispconfig3
  mail_admin_email: email@votre-entreprise.com
  mail_base_domain: votre-entreprise.com
  ispconfig_hostname: ispconfig.votre-entreprise.com
  roundcube_hostname: mail.votre-entreprise.de
 

Tout le reste mentionné dans les variables du rôle peut être trouvé dans le defaults/main.yml.
Tous les paramètres pour le rôle ISPConfig sont pris du fichier de configuration pour la configuration d'Apache2. Pour plus d'informations, consultez ce lien. Vous pouvez trouver des paramètres d'exemple sous autoinstall.php pour ISPConfig.

Démarrer comme VM et exécuter des tests avec Molecule

Tout ce qui suit est tiré de https://Molecule.readthedocs.io/en/latest/. C'est pratique d'avoir tout au même endroit.

Cela vous aidera à exécuter des rôles Ansible sur une réelle machine virtuelle sans vous soucier de l'état de la VM.

Pour démarrer le rôle et exécuter l'environnement de test, vous aurez besoin de Molecule. Les étapes suivantes expliqueront comment tout configurer et exécuter les tests.

1. Installer virtualenv
   • Installé virtualenv sudo apt install virtualenv
   • Créer un virtualenv dans votre dossier virtualenv --no-site-packages .venv Cela contiendra tous les paquets installés. C'est la manière la plus propre de prévenir votre système de l'encombrement des paquets.
2. Démarrer virtualenv
   • Vous devrez exécuter cette commande chaque fois que vous redémarrez votre console ou entrez une nouvelle session.
   • source .venv/bin/activate
3. Installer le paquet Molecule
   • pip3 install Molecule ansible
   • Vous devrez installer l'API Python pour votre pilote que vous utiliserez, dans le cas de ce rôle, ce sera Vagrant.
   • Exécutez cette commande si vous voyez (.venv) au début de votre ligne de console.
   • pip install python-vagrant

Voici les exigences que vous devez respecter avant de commencer avec Molecule. Ensuite, il sera expliqué comment vous pouvez configurer des rôles pour le test.

Exécuter le test

Exécuter des tests est assez simple, il suffit d'aller dans votre venv comme vu dans l'étape 2 ci-dessus et de lancer :

Molecule test

Cela configurera automatiquement votre pilote (Docker ou Vagrant dans la plupart des cas) et exécutera différents scénarios de test tels que des tests d'idempotence ou vos propres tests écrits pouvant tester toutes sortes de choses.

Nouveau Rôle

Molecule init role -r nouveau-rôle -d vagrant

Cela initialisera un nouveau rôle Vagrant avec le nom nouveau-rôle et il contiendra la configuration standard pour Vagrant. Comme alternative, vous pouvez définir votre pilote sur Docker ou d'autres méthodes de virtualisation prises en charge.

Mettre à jour Molecule

Remarque : Molecule est relativement nouveau, donc des mises à jour seront effectuées, c'est pourquoi il est recommandé de faire cela de temps en temps.

pip install --upgrade Molecule

Exemple de Molecule et Playbook

Ici, vous allez voir un exemple de la manière dont le Molecule.yml et le Playbook.yml sont structurés pour ce scénario de test.

Molecule.yml

---
dependency:
  name: galaxy
driver:
  name: vagrant
  provider:
    name: virtualbox
lint:
  name: yamllint
platforms:
  - name: instance
    box: ubuntu/bionic64
    instance_raw_config_args:
      - "vm.hostname = 'web.my.net'"
    memory: 4096
provisioner:
  name: ansible
  lint:
    name: ansible-lint
    enabled: false
scenario:
  name: default
  test_sequence:
    # - lint
    - destroy
    # - dependency
    - syntax
    - create
    - prepare
    - converge
    - idempotence
    # - side_effect
    - verify
    - destroy
verifier:
  name: testinfra
  lint:
    name: flake8
    

Vous pouvez voir le Molecule.yml utilisé pour ce projet avec le pilote et ses paramètres, comme la mémoire. Remarque importante : Il était nécessaire pour une tâche dans le rôle de définir le nom d'hôte, donc vous pouvez voir qu'il est défini grâce à instance_raw_config_args. Vous pouvez utiliser différentes machines directement depuis Vagrant ou les charger depuis un lien. Pour ce type de changement, consultez la documentation de Molecule.

Si vous jetez un œil à Playbook.yml, vous verrez qu'il est similaire à l'appel normal de rôle, mais avec un nom différent. Voir l'exemple complet ci-dessous dans l'exemple de playbook.

Playbook.yml

---
- name: Converger
  hosts: all
  roles:
     - role: inoxio.ispconfig3
         ***
         ***

Molecule

Cette section contiendra une conclusion sur Molecule car c'était la première configuration de celui-ci.

Le premier test avec Molecule se faisait avec Docker comme pilote. Avec cette méthode, des obstacles sont rapidement apparus. En raison de la nature de Docker et de la complexité de ce rôle. Cela a commencé avec des services qui ne sont pas chargés dans un conteneur et a continué avec des PID qui sont différents. Nous en sommes donc venus à la conclusion qu'il n'est pas agréable d'adapter votre code à votre cadre de test.

Cela nous a laissés le choix d'utiliser Vagrant comme pilote. Cela nous aidera à résoudre le problème de l'absence d'environnement virtuel complet et d'exécuter tout de manière fluide.

Cette configuration s'est déroulée sans problème majeur et a testé tous les points clés souhaités.

Si vous souhaitez inclure Molecule dans votre rôle, veuillez suivre cette liste simple :

• Assurez-vous de commencer avec une feuille blanche et créez votre rôle dans Molecule pour pouvoir le tester de temps en temps.
• Si vous souhaitez utiliser Docker, assurez-vous que votre rôle n'est pas trop complexe et que vous n'avez pas à adapter votre rôle à Docker.