WikiMiNET

La documentation technique et administrative

Outils pour utilisateurs

Outils du site


wiki:hebergement:hebergement_lxc

Hébergement LXC

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

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.

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 zteeed

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

TODO manwefm

  • revoir le stockage et sa doc
  • monitoring log ansible
wiki/hebergement/hebergement_lxc.txt · Dernière modification: 2018/09/01 01:14 (modification externe)