Newer
Older
# ansible-roles-paquerette
*Proposition de rôles ansible **minimaux**, pour mettre en oeuvre et maintenir des applications sur des machines auto hébergées ou dans le cloud.*
Systèmes supportés : **Ubuntu 16.04 LTS**, **Ubuntu 18.04 LTS**
- configuration basée sur deux partitions, 1 système, 1 pour les données et les programmes montée sur **/mnt/vdb** par défaut
- monitoring : **monit**
- backup : **backupninja**, backup externe en mode "master/slave" : un serveur externe se connecte sur la machine pour récupérer les archives mises à sa disposition
- mail, remontée de messages : **postfix configuré en relais SMTP**, possibilité de copie cachée systématique permettant l'envoi de sms par exemple, non détaillé ici
## 0 - Prérequis
- une machine ubuntu avec une adresse ip publique. (**le serveur**)
- une machine à partir de laquelle effectuer le déploiement, avec ansible. (**la machine de déploiement**)
- sur le serveur : en option, mais recommandé une partition de donnée sur la machine montée sur /mnt/vdb par défaut. Si absente, positionner dans les host_vars **data_partition** à "no"
- sur le serveur : **un compte d'administration** permettant l'execution de commande via sudo et sans renseigner de mot de passe, avec sa clé ssh
- sur le serveur : une clé ssh permettant la connexion du compte récupérant les sauvegardes (peut être la même que le compte d'administration, mais non recommandable)
- **une boîte mail** accessible via SMTP pour relayer par défaut l'ensemble des messages.
L'ensemble des variables associées sont dans le fichier base_server, dans les sections PREREQUISITES
C'est la partie qui définit la liste des machines pilotées, la composition de la plateforme de support applicative, la liste des instances applicatives et toutes les variables utiles aux rôles.
***En gras**, les groupes à définir localement, selon les besoins.*
- secret : les variables communes qui doivent rester secrètes (mot de passe etc...)
- - base_server : toutes les variables communes non secrètes
- - - **test** : toutes les variables propres aux machines de test
- - - **prod** : toutes les variables propres aux machines de production
etc...
fichiers dans group_vars
*cf hosts.example*
## 2 - Le serveur
C'est la partie qui définit les base du serveur, elle est la couche basse. Elle met en oeuvre :
- l'organisation des répertoires et fichiers
- la localisation du serveur
- la stratégie de sauvegarde
- la stratégie de monitoring
## 3 - La plateforme de support applicative
C'est la partie qui définit l'ensemble des services ou composants nécessaire au fonctionnement d'une instance applicative. Elle met en oeuvre :
- les serveurs web (nginx, apache,...)
- les serveurs de base de données (mariadb, postgres, mongodb...)
- les languages (php, python, nodejs...)
## 4 - Le déploiement de l'instance applicative, la mise à jour et la désinstallation complète
C'est la partie qui définit la méthode de déploiement et de mise à jour d'une instance applicative. Elle met en oeuvre,
- le téléchargement d'une application
- la création des bases de données et dépendances (certificat letsencrypt...)
- la configuration de base de l'application
- la mise en place des sauvegardes et du monitoring
- le téléchargement de la nouvelle version
- l'arrêt du service
- la sauvegarde complète de la version courante à froid
- la mise à jour du logiciel et de la base de données + ou - automatisée selon l'application
- le redémarrage du service
pour la suppression complète (uninstall):
- l'arrêt du monitoring
- l'arrêt du service
- la suppression de l'application et de la base de données
- la suppression des tâches de sauvegarde et associées (logrotate...)
- la révocation et la suppression du certificat letsencrypt
Les rôles utilisent des parties factorisées dans des rôles réutilisables (création de base de données, de certificats etc...)
La gestion de l'inventaire des instances se fait avec le programme **inventory.py**
L'application des modifications de l'inventaire se fait avec le programme **play.py** qui génère le playbook et le lance avec ansible
par exemple :
./play.py host_example nc_mydomain_eu install
./inventory.py --new-instance
**utilitaire : inventory.py, play.py**
- Obtention de certificats letsencrypt pendant la coupure nocturne : **letsencrypt_nightly_new**
exemple d'utilisation :
./play.py -e 'domain_name=www.peace.org' '-r myhost letsencrypt_nightly_new
## 8 - Cas particuliers
Ce sont des rôles qui permettent de déployer des applications telles collabora d'une façon spécifique.
**rôles :**
**- collabora\_online\_instance**
**- turn\_server**
**- _master_backup_server** qui permet de configurer un serveur récupérant les backups d'autres serveurs
## Notes :
- base server (_python3)
- base platform (apache, nginx, mysql/mariadb, mongodb, nodejs, postgres, php7_fpm )
- _app_backup, _app_logrotate, _app_monit, _create_database, _letsencrypt_certificate
- nextcloud_instance
- collabora online_instance (partner)
- dolibarr_instance
- rocketchat_instance: il est devenu impossible d'installer plusieurs instances sur une même machine, rocket.chat n'est pas prévu pour ça
- _web_app (chrooted sftp only user, git, static, php, python) (wordpress, grav, pelican, yeswiki, adminer ...)
ROLES NOUVEAUX OU EN DÉVELOPPEMENT (qui peuvent subir un refactoring important):
- _app_log_inventory (refactoring)
NOUVEAUX OUTILS
- status.py : utilitaire permettant de faire un check rapide de la production, en cours de développement
- bases de données dans la partition système : déplacer le /var/lib/ postgres.... dans /mnt/vdb/ à l'étude