L'infra en 1 page

Les membres sur le projet: manwefm, no_pseudo, gerox

Notre rapport cassiopee

Notre poster

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

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

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

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.

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.

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

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.

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

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…

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

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

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

• script pour mettre à jour les CT si pas maj tous les 15 jours, commence par le faire sur ton ct ⇒ ⇒ ⇒ ⇒ crontab ajoutée sur les CT ?
• 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) ⇒ ⇒ ⇒ check nettoyage.sh dans /root
• upgrade de jessie vers stretch sur
  • passerelle ⇒ ⇒ EN COURS / FAIT
  • revproxy ⇒ ⇒ EN COURS / FAIT
  • dhcp ⇒ ⇒ probleme depot.minet.net et accès aux depots debian
  • ansible ⇒ ⇒ probleme depot.minet.net et accès aux depots debian
  • database ⇒ ⇒ C'est la vm qui héberge la bdd utilisée par django et les cron pythons
  • nsh1 ⇒ ⇒ FAIT
  • website ⇒ ⇒ déjà fait
  • on fera les serveurs physiques après ⇒ ⇒
• monitoring ⇒ ⇒

• revoir le stockage et sa doc
• monitoring log ansible