===== Hébergement LXC =====

[[wiki:hebergement:hebergement_lxc:tldr| L'infra en 1 page]]

Les membres sur le projet:
**manwefm**, **no_pseudo**, **gerox**

{{ :wiki:hebergement:25_rapport.pdf |Notre rapport cassiopee }}

{{ :wiki:hebergement:25_poster.pdf | Notre poster }}

Schéma représentant le fonctionnement des infra logique et physique :

{{:wiki:hebergement:hosting2.png?800|}}

{{:wiki:hebergement:diagramme_infra.png?800|}}

Un utilisateur peut accéder à sa LXC :
  * via l'interface web où il peut start/stop/restart/ajouter et supprimer une redirection de port/ajouter une clé ssh
  * via le revproxy qui redirige l'entrée de son nom de domaine vers son LXC sur le port 80
  *via ssh sur un port entre 40000 et 50000

==== L'infra physique ====

Il y a 3 serveurs :
  * margherita : Héberge les services (revproxy, passerelle, base de données, dns, site web etc.) sur des KVM avec Libvirt
  * hypnotika : Héberge les LXC des utilisateurs
  * extravaganzza : Le SAN relié en ISCSI over Infiniband à hypnotyka

==== Fonctionnement général ====

Les boutons sur lesquels l'utilisateur clique sur l'interface web écrivent dans des tables temporaires. Des crons écritent en python, sur la VM ansible, récupérent ses données et effectuent l'action demandée.

==== Choix techniques ====

=== Pourquoi LXC ===

Nous n'avions pas les ressources serveurs nécessaires pour proposer des KVM à des dizaines de personnes. C'est pourquoi nous sommes partis sur la conteneurisation.

Plusieurs techno s'offraients à nous : LXC, LXC, Docker et OpenVZ.

{{:wiki:hebergement:choix_lxc.png?400|}}

Pour résumer le tableau :
  * OpenVZ était vieux, non libre, nécessitait un noyau patché, n'était pas dans les dépôt Debian et Ansible n'avait pas de module Ansible pour OpenVZ.
  * Docker était plutôt pour une infra Saas et ne proposait pas des conteneurs non privilégiés
  * LXD n'était pas encore dans les dépôts Debian et son API était galère pour scripter

=== Pourquoi SAN/ISCI/LVM et pas NAS/NFS/ZFS ===

ZFS était encore trop récent sur Debian et OpenIndiana sur un serveur custom bien capricieux...

De plus NFS ne gérait pas simplement les quotas. ISCSI permet à hypnotika de voir les 24 disques d'extravaganzza comme 2 disques de  ~4To et de facilement les découper avec des volumes logiques lvm.

=== Pourquoi Ansible ===
On n'a pas vraiment étudié les différentes possibilités, Ansible possédait tout ce dont on avait besoin.

=== Pourquoi postgresql ===
Pour faire plaisir à M.Guerson (super cool) qui était notre tuteur de Cassiopée pour ce projet. Il devait nous aider à sécuriser correctement la bdd mais on n'a pas eu le temps...

=== Pourquoi Django ===
ADH6 était entrain d'être dev la même année avec django et on préferrait python à php

=== Pourquoi pas d'ipv6 ===
On n'a pas eu le temps mais c'est un petit projet sympa.

==== Et maintenant ? ====
L'infra n'est pas finie, voici quelques idées d'amélioration en vrac :
  * script pour mettre à jour les CT si pas maj tous les 15 jours
  * logrotate propre pour backup la bdd
  * utiliser un certificat wildcard letsencrypt
  * passer sur LXC 2.1 ou +
  * monitorer l'infra
  * verifier ce qu'il se passe après 1 an
  * maj noms de domaine bannis
  * checker ce qu'apport django 2.0 niveau sécu
  * template openvpn et docker
  * écrire plus de test pour les cron et django
  * passer de iptables à nftables
  * développer un outil d'administration en ligne de commande pour remplacer l'application web django si elle tombe
  * développer l'interface d'administration django pour gérer les adhérents et les LXC en clic-clic et pour éviter de toucher directement à la bdd
  * compléter le wiki django encore plus parce que les adhérents...
  * compléter le wiki minet encore plus parce que nous ...
  * backuper les vms quelquepart
  * backuper les LXC quelquepart
  * proposer une/plusieurs ipv6 par LXC

==== TODO ====

  * script pour mettre à jour les CT si pas maj tous les 15 jours, commence par le faire sur ton ct => => => =>  <color #ed1c24>crontab ajoutée sur les CT ?</color> 
  * sauvegarde propre du dump postgresql sur la vm database (faut dump les databases django et django_test, celle de test bougera pas mais faut la backup) => => => <color #ed1c24>check nettoyage.sh dans /root</color>
  * upgrade de jessie vers stretch sur 
      * passerelle => => <color #ed1c24>EN COURS / FAIT</color>
      * revproxy => => <color #ed1c24>EN COURS / FAIT</color>
      * dhcp => => <color #ed1c24>probleme depot.minet.net et accès aux depots debian</color>
      * ansible => => <color #ed1c24>probleme depot.minet.net et accès aux depots debian</color>
      * database => => <color #ed1c24>C'est la vm qui héberge la bdd utilisée par django et les cron pythons</color>
      * nsh1 => => <color #ed1c24>FAIT</color>
      * website => => <color #ed1c24>déjà fait</color>
      * on fera les serveurs physiques après => =>
  * monitoring => =>

==== TODO manwefm ====

  * revoir le stockage et sa doc
  * monitoring log ansible