Contribuer / Tester l'environnement de l'AMIPO en local sur son poste de dev

L'environnement de dev repose sur l'utilisation de machine virtuelles (VM). Pour nous simplifier la tache, nous utilisons le logiciel Vagrant, qui nous permet d'automatiser la création de VM.

Il faut donc installer Vagrant. La procédure est décrite dans le README.md du projet ici : https://framagit.org/amipo/amipo-infra.

Ensuite, le déploiement sur tous nos environnements du Developpement, au Staging à la Produciton est automatisé avec le logiciel Ansible.

Nous utilisons Vagrant pour construire l'environnement de Dev. L'environnement de Dev doit est déployable par chaucun sur son propre ordinateur personnel, de façon homogène, standard et automatisée. Pour cela, Vagrant créé et gère des Machines Virtuelles sur lesquels sera déployé l'environnement de Dev.

Liste des VMs :

• Controller (“Tour de controlle” qui permet de lancer les playbooks Ansible)
• Amipo1 (Image du serveur de Production)

1. Création de la VM Controller avec Debian Stretch
2. Ajout de l'IP de la VM Controller dans le fichier /etc/hosts de la machine hote
3. Provisionnement de l'environnement du Controller avec l'environnement Ansible fournit par Vagrant (Ansible provisioner)
4. Création d'un volume disk autonome séparé pour la VM Amipo1 pour la (pas détruit à la destruction de la VM)
5. Création de la VM Amipo1 avec Debian Stretch
6. Ajout de l'IP de la VM Amipo1 dans le fichier /etc/hosts de la machine hote
7. Bootstrap d'Ansible sur Amipo1 pour que la machine soit accessible via Ansible (avec un script, il faudrait voir si il serait pas mieu de faire tourner un provisioner ansible à vide dessus qui pourrait peut etre avoir le meme effet)
8. Provisionnement de l'environnement d'Amipo1 avec l'environnement Ansible du Controller

1. Installation des packages dnsmasq et vim
2. Installation de l'environnement shell
3. Configuration de l'environnement dans le fichier .profile
4. Génération de la clé ssh de provisionnement
5. Création du fichier ~/.ssh/config
6. Génération de la “personnal_root_ac”, clé privé et certificat pour créé une Autorité de Certification propre aà chaque environnement de Dev.

1. Installation de vim et cie …
2. Installation de l'environnement shell
3. Securisation du serveur (firewall, …)
4. Installation de certbot
5. Installation de nginx
6. Configuration de l'architecture web
7. Déploiement de la homepage amipo
8. Installation du serveur prometheus
9. Installation du node-exporter prometheus
10. Installation de grafana

Pour se connecter sur les VM, par défaut Vagrant utilise une clé ssh nommé “insecure private key”. Il y a plusieurs clés ssh à distinguer :

• La clé ssh “insecure private key” qui permet à Vagrant de se connecter sur une VM dans l'environnement de Dev.
• La clé ssh d'un utilisateur qui est autorisé à se connecter sur le serveur.
• La clé ssh “de provisionnement” qui permet à ansible de se connecter à un serveur.

Pour le moment nous utilisons la meme clé pour tous les usages. En dev, seule la clé insecure_private_key de vagrant est utilisée, et dans les autres environnements c'est la clé ssh de l'administrateur qui est utilisée.

• L'env de dev utilise pour le moment la vagrant insecure private key pour les connextions ssh d'ansible.
• Les autres envs stage et prod nécessite des clés ssh personnelles que l'utilisateur devra déposer dans le dossier .privateCredentials
• Le dossier .privateCredentials sera ignoré par git.
• Le fichier .privateCredentials/ssh_credentials.yml contiendra la config des cles ssh de l'utilisateur.

Pour automatiser le déploiement des outils sur tous les environnements, nous allons créer des playbooks ansible. Buts :

• Pouvoir reproduire l'installation d'un service de manière automatisée
• Faciliter le developpement en proposant un moyen d'installer facilement l'environnement sur une machine personelle
• Faciliter la maintenance
• Faciliter la diffusion la sécurisation et l'amélioration des déploiements

Liste des playbooks ansible à réaliser en adéquation avec la cible fin 2018 :

• [x] Installation et configuration du frontal nginx
• [x] Configuration de l'architecture web (nom de domaine, sous domaine, server blocks (virtual hosts), dns, …)
• [x] Génération des certificats ssl / Déploiement de la config ssl
• [x] Déploiement de la homepage
• [x] Harmoniser les playbooks pour qu'il soit réutilisable sur les différents env
• [x] Création d'un playbook / script de provisioning minimal des machines pour pouvoir les contacter avec ansible.
• [x] Sécurisation du serveur
• [x] Environnement du serveur
• [x] Installation de Grafana
• [_] Configuration de Grafana ⇒ Install dashboards ? 1 Dashboard pour la surveillance du serveur, 1 dashboard MQTT
• [x] Installation de Prometheus
• [_] Configuration de Prometheus

Points difficiles :

• Installation et configuration du frontal nginx
• Configuration de l'architecture web
• Déploiement de la homepage
• Génération des certificats ssl
• Sécurisation du serveur
• Transition dev / stagging / prod
• Création d'un playbook / script de provisioning minimal

• La config actuellement externalisée dans un repo git specifique sera réintégré dans l'environnement Ansible.
• Chargement de tous les fichiers de conf dans le repertoire conf.d comme le suggere nginx
• Configuration des logs dans /var/log/nginx
• Configuration de Nginx (timeout, gzip, HTTP headers, …)
• Installation et configuration de logrotate

Le principe est de découpler la configuration de nginx et la configuration relative à l'archi web. Ce playbook ne touche pas aux fichiers de config de nginx, il se contente d'ajouter des fichiers dans conf.d

Idée :

• Le server block www.amipo.fr est décrit dans un seul fichier dans le repertoire conf.d pour faire simple. On doit éviter de faire des inclusions dans ce fichier pour simplifier sa lecture.
• Le playbook contient un mapping lisible de tous les server blocks et locations block.
• On peut désactiver un à un chaque serveur block et location block dans la config du playbook.
• Le playbook construit un fichier complet sans include dans conf.d par server block.
• Il y a une grosse redondance de la configuration, mais chaque server block est facile à lire. L'homogénéité de la configuration est assuré par le playbook.

Idée :

• Installation de certbot en prod et en stagging
• Génération de certificat avec openssl en dev. Comment tester certbot en dev ?
• Maintenance / conservation du certificat racine de l'Amipo

• Génération d'une root AC propre à chaque poste de dev qui sera stoqué dans le repertoire “.dev_root_AC” dans le workspace de travail. Ce repertoire est ignoré par git pour ne pas etre commit. Le but de cette root AC est que l'utilisateur puisse lui faire confiance et cela permettre ainsi à tous les certificats de l'environnement dev signés par cette root AC d'etre valides. (Cela évite le message fastidieux: d'insécurité relatives des certificats auto-signés.)
• Génération des certificats nécéssaires à l'architecture web. Les certificats seront placées aux meme endroits que les auraient déposés certbot, soit dans les repertoire: /etc/openssl/dev/<domain.tld>/ avec la meme norme de nommage, soit: cert.pem, chain.pem, fullchain.pem et privkey.pem Ils seront similaires, avec des wildcard et des Subject Alternatives Names
• Installation de certbot

• les certificats seront déposés par certbot dans le repertoire: /etc/letsencrypt/live/<domain.tld>/

• Cloner le repo git de la homepage
• Executer le script de compilation
• Eventuellement utiliser le playbook de l'archi web pour déclencher une page de maintenance pendant le déploiement, puis activer redéployer la config de l'archi web incluant la homepage.

• Copier le workspace en cours de travail
• Executer le script de compilation

• Installation de fail2ban
• Configuration de iptables

• Installation de python
• Installation de sudo
• Création des admin users (au moins un) avec leur clé publique
• Ajout du sudo nopasswd pour les admin users

Idée:

• Le script prend un admin username, une clé public et une compte ssh root en argument
• Il se connecte en root, créé le compte admin, ajoute la clé public
• Il installe les paquets nécessaires

• 1 dashboard monitoring du serveur en prod : https://www.amipo.fr/grafana/
• 1 dashboard MQTT en staging : https://www.amipo.mby.ovh/grafana/d/l9dEFqAWz/amipo-capteurs?refresh=5s&orgId=1

Je vois 2 implémentations de broker opensource :

• Mosquitto
• VerneMQ

VerneMQ implémente le protocol MQTT v5.0

Le compte sansible sur ansible galaxy propose des roles pour installer Mosquitto, VerneMQ et le mqtt-exporter:

• https://galaxy.ansible.com/sansible/mosquitto
• https://galaxy.ansible.com/sansible/vernemq
• https://galaxy.ansible.com/sansible/prometheus_mqtt_exporter

Le role VerneMQ install vernemq sur debian, mais le fichier service est mauvais et ne permet pas de lancer le serveur VerneMQ. A creuser.

Pour plug MQTT sur InfluxDB, nous allons construire un poller en python. Ce poller sera un daemon qui utilisera la librairie python prometheus_client pour poller les queues MQTT.

Idées :

• On utilisera le topic de la file MQTT pour déterminer le nom de la métrique.
• Un message peut être une simple donnée brut, directement contenir une valeur non typée.
• Un message peut être exprimé au format CayenneLpp, et contenir plusieurs valeurs typées.
• Un message peut être exprimé au format “TTN” JSON avec une payload brut ou au format CayenneLpp.
• Un message peut être exprimé au format JSON lequel ?
• Si plusieurs valeurs dans le messages, il faut pouvoir les différencier et le topic ne suffit plus à identifier completement la métrique.
• Si pas de date fournit dans les méta données ou dans la payload, on prend la date courante pour la time serie.

Idées :

• Un script permet de générer des messages sur la sortie standard
• On pipe la sortie du script dans un mosquitto_pub pour simuler un producteur de données
• Le script prend des paramètres pour génerer des données plus ou moins aléatoire avec des bornes et pour spécifier le format des messages
• Les formats des messages supportés : RAW, CayenneLpp, et “TTN” JSON