Outils pour utilisateurs

Outils du site


amipo

Ceci est une ancienne révision du document !


AMIPO

L'AMIPO est l'Association de Maintien de l'Informatique Paysanne Orléanaise, elle s'inscrit dans la dynamique CHATONS initiée par Framasoft.

Archi cible pour fin 2018

Liste des services que je pense pouvoir faire fonctionner d'ici fin 2018 :

  • Frontal nginx
  • Homepage
  • Grafana
  • Prometheus
  • Vagrant déploiement local
  • Vagrant déploiement à distance

Environnement de Dev

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

  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

Provisionnement de la VM Controller

  1. Installation des packages dnsmasq et vim
  2. Configuration de l'environnement dans le fichier .profile
  3. Génération de la clé ssh de provisionnement
  4. Création de fichier .ssh/config

Provisionnement de la VM Amipo1

  1. Installation de vim
  2. Installation de nginx

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.

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.

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_config.yml contiendra la config du template

A positionner

  • root dev cert
  • ssh keys

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
  • [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

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 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

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
amipo.1544515765.txt.gz · Dernière modification : 2018/12/11 08:09 de bigMax