Outils pour utilisateurs

Outils du site


amipo

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentesRévision précédente
Prochaine révision
Révision précédente
amipo [2019/05/17 13:45] – [Pousser les messages MQTT dans InfluxDB] bigMaxamipo [2020/02/07 14:05] (Version actuelle) bigMax
Ligne 1: Ligne 1:
-====== L'AMIPO : dégooglisons Internet ======+====== L'AMIPO : déGAFAMisons Internet ======
 L'AMIPO est l'Association de Maintien de l'Informatique Paysanne Orléanaise, elle s'inscrit dans la dynamique [[https://chatons.org|CHATONS]] initiée par Framasoft. L'AMIPO est l'Association de Maintien de l'Informatique Paysanne Orléanaise, elle s'inscrit dans la dynamique [[https://chatons.org|CHATONS]] initiée par Framasoft.
  
Ligne 5: Ligne 5:
 ===== Liste des choses en place ===== ===== Liste des choses en place =====
   * Architecture web   * Architecture web
-  * La Homepage AMIPO+  * La Homepage AMIPO : https://www.amipo.fr
   * Un serveur Prometheus pour héberger des métriques systemes.   * Un serveur Prometheus pour héberger des métriques systemes.
-  * Un serveur Grafana pour construire des visualisation de métriques temporelles +  * Un serveur Grafana pour construire des visualisation de métriques temporelles : https://www.amipo.fr/garafana 
-  * Un environnement de Dev déployable en local+  * Un environnement de Dev déployable en local : [[ amipo_dev ]]
   * Un déploiement automatisé sur les environnements de Stage et de Prod   * Un déploiement automatisé sur les environnements de Stage et de Prod
   * Un serveur InfluxDb pour heberger des métriques temporelles   * Un serveur InfluxDb pour heberger des métriques temporelles
-  * Un serveur VerneMQ pour fournir un broker MQTT+  * Un serveur VerneMQ pour fournir un broker MQTT [[ amipo_mqtt ]] 
 ===== Liste des services à fournir à l'avenir ===== ===== Liste des services à fournir à l'avenir =====
   * Un service d'intégration de métriques temporelles dans Prometheus pour conserver des données de capteurs (LaPerco)   * Un service d'intégration de métriques temporelles dans Prometheus pour conserver des données de capteurs (LaPerco)
Ligne 19: Ligne 20:
   * Serveur nextcloud : un service pour synchroniser et partager ses agenda et ses contacts   * Serveur nextcloud : un service pour synchroniser et partager ses agenda et ses contacts
  
-===== Environnement de Dev ===== +===== Organisation ===== 
- +Nous utilisons [[ https://mxbossard.framaboard.org/?controller=BoardViewController&action=show&project_id=1 | Framaboard ]] pour lister les choses à faire, découper le travail en petites tâches testable et suivre notre avancé.
-==== Vagrant ==== +
-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) +
- +
-=== Synoptique du déploiement === +
-  - Création de la VM Controller avec Debian Stretch +
-  - Ajout de l'IP de la VM Controller dans le fichier /etc/hosts de la machine hote +
-  - Provisionnement de l'environnement du Controller avec l'environnement Ansible fournit par Vagrant (Ansible provisioner) +
-  - Création d'un volume disk autonome séparé pour la VM Amipo1 pour la (pas détruit à la destruction de la VM) +
-  - Création de la VM Amipo1 avec Debian Stretch +
-  - Ajout de l'IP de la VM Amipo1 dans le fichier /etc/hosts de la machine hote +
-  - 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) +
-  - Provisionnement de l'environnement d'Amipo1 avec l'environnement Ansible du Controller +
- +
-=== Provisionnement de la VM Controller === +
-  - Installation des packages dnsmasq et vim +
-  - Installation de l'environnement shell +
-  - Configuration de l'environnement dans le fichier .profile +
-  - Génération de la clé ssh de provisionnement +
-  - Création du fichier ~/.ssh/config +
-  - Génération de la "personnal_root_ac", clé privé et certificat pour créé une Autorité de Certification propre aà chaque environnement de Dev. +
- +
-=== Provisionnement de la VM Amipo1 === +
-  - Installation de vim et cie ... +
-  - Installation de l'environnement shell +
-  - Securisation du serveur (firewall, ...) +
-  - Installation de certbot +
-  - Installation de nginx +
-  - Configuration de l'architecture web +
-  - Déploiement de la homepage amipo +
-  - Installation du serveur prometheus +
-  - Installation du node-exporter prometheus +
-  - Installation de grafana +
- +
-=== Gestion des clés ssh dans l'environnement de Dev === +
-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. +
- +
-<WRAP center round important 60%> +
-Actuellement, pour des raisons de simplicité, la clé ssh de provisionnement sur l'environnement de dev est la clé "insecure private key". Pour corriger cela, il faut ajouter une étape de distribution de la "clé de provisionnement" qui est à réfléchir. +
-</WRAP> +
- +
-=== Gestion des credentials ssh pour les differents environnements === +
-  * 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. +
- +
- +
-===== Playbooks ansible ===== +
-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 ? Dashboard pour la surveillance du serveur, 1 dashboard MQTT +
-  * [xInstallation 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 +
- +
-==== Installation et configuration du frontal nginx ==== +
-  * 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 +
- +
-==== Configuration de l'architecture web ==== +
-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. +
- +
-==== Generation des certificats ssl ==== +
-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 +
- +
-=== En dev avec openssl === +
-  * 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 certbotsoit 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 +
- +
-=== En prod avec certobt === +
-  * les certificats seront déposés par certbot dans le repertoire: /etc/letsencrypt/live/<domain.tld>/ +
- +
-==== Déploiement de la homepage ==== +
-=== Un playbook de déploiment des release === +
-  * 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. +
- +
-=== Un playbook de déploiement du workspace en cours de dev === +
-  * Copier le workspace en cours de travail +
-  * Executer le script de compilation +
- +
-==== Sécurisation du serveur ==== +
-  * Installation de fail2ban +
-  * Configuration de iptables +
- +
-==== Création d'un playbook / script de provisioning minimal ==== +
-  * 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 +
- +
-===== Grafana / Prometheus ===== +
-  * 1 dashboard grafana pour monitorer le serveur +
-  * 1 dasgboard MQTT ? +
- +
-===== MQTT ? ===== +
-Je vois 2 implémentations de broker opensource : +
-  * Mosquitto +
-  * VerneMQ +
- +
-VerneMQ implémente le protocol MQTT v5.0 +
- +
-==== Installation de VerneMQ ==== +
-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. +
- +
-==== Pousser les messages MQTT dans InfluxDB ==== +
-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. +
- +
-=== Formats de données === +
-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. +
-\\ \\ +
- +
-=== Générateurs de messages === +
-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 +
-==== TODO liste "immédiate" ==== +
-  * [x] Stabiliser le déploiement du serveur MQTT (service not working, cf [[ https://github.com/vernemq/vernemq/wiki/Running-VerneMQ-as-a-systemd-service ]]) => maj du role ansible OK +
-  * [x] Construire / Recup un playbook pour déployer InfluxDB (config incluse) +
-  * [x] Réparer le déploiement avec provisioning de Grafana cassé par la maj du role ansible +
-  * [_] Scripter / Recup un daemon pour injecter les messages MQTT dans InfluxDB => imposer un format pour convertir le topic en métrique et convertir les donnée du message en valeur. Piste de format: [[ https://mydevices.com/cayenne/docs/lora/#lora-cayenne-low-power-payload|Cayenne ]] et un format raw plus facile à tester. +
-  * [_] Configurer Grafana pour afficher les metriques provenant de MQTT +
-  * [_] Le role cloudalchemy.prometheus actuel dl prometheus meme si la version actuelle n'est pas à mettre à jour +
-  * [_] Voir si les modifications récentes du role cloudalchemy.grafana corrige les problèmes de livraison des dashboards +
-  * [_] provision_amipo.yml pas completement idempotent nottament sur "Deploy released Amipo homepage" "amipo.devsslcerts" +
-  * [_] Ajouter une nouvelle VM backup pour être en mesure de faire des backups depuis un poste de dev. +
-  * [_] Dev des playbooks pour configurer cette VM backup. +
-  * [x] Provisioning du home dashboard de Grafana +
-  * [x] Installer MQTT +
-  * [x] Installer l'exporter prometheus pour MQTT  +
-  * [x] Scripter un mangeur d'open data pour pousser dans MQTT +
-  * [x] Construire un dashboard grafana pour présenter les open data manger par MQTT +
  
 {{tag>amipo realisations_logicielles système_exploitation}} {{tag>amipo realisations_logicielles système_exploitation}}
amipo.1558100747.txt.gz · Dernière modification : 2019/05/17 13:45 de bigMax