Ci-dessous, les différences entre deux révisions de la page.
wiki:hebergement:hebergement_lxc [2018/04/05 14:17] zteeed |
wiki:hebergement:hebergement_lxc [2020/06/27 18:16] |
||
---|---|---|---|
Ligne 1: | Ligne 1: | ||
- | ===== Hébergement LXC ===== | ||
- | |||
- | [[wiki: | ||
- | |||
- | Les membres sur le projet: | ||
- | **manwefm**, | ||
- | |||
- | {{ : | ||
- | |||
- | {{ : | ||
- | |||
- | Schéma représentant le fonctionnement des infra logique et physique : | ||
- | |||
- | {{: | ||
- | |||
- | {{: | ||
- | |||
- | Un utilisateur peut accéder à sa LXC : | ||
- | * via l' | ||
- | * via le revproxy qui redirige l' | ||
- | *via ssh sur un port entre 40000 et 50000 | ||
- | |||
- | ==== L' | ||
- | |||
- | 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 | ||
- | * hyponitika : Héberge les LXC des utilisateurs | ||
- | * extravaganzza : Le SAN relié en ISCSI over Infiniband à hypnotyka | ||
- | |||
- | ==== Fonctionnement général ==== | ||
- | |||
- | Les boutons sur lesquels l' | ||
- | |||
- | ==== Choix techniques ==== | ||
- | |||
- | === Pourquoi LXC === | ||
- | |||
- | Nous n' | ||
- | |||
- | Plusieurs techno s' | ||
- | |||
- | {{: | ||
- | |||
- | Pour résumer le tableau : | ||
- | * OpenVZ était vieux, non libre, nécessitait un noyau patché, n' | ||
- | * Docker était plutôt pour une infra Saas et ne proposait pas des conteneurs non privilégiés | ||
- | * LXD n' | ||
- | |||
- | === Pourquoi SAN/ | ||
- | |||
- | 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' | ||
- | |||
- | === Pourquoi Ansible === | ||
- | On n'a pas vraiment étudié les différentes possibilités, | ||
- | |||
- | === 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' | ||
- | |||
- | === Pourquoi pas d'ipv6 === | ||
- | On n'a pas eu le temps mais c'est un petit projet sympa. | ||
- | |||
- | ==== Et maintenant ? ==== | ||
- | L' | ||
- | * 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' | ||
- | * verifier ce qu'il se passe après 1 an | ||
- | * maj noms de domaine bannis | ||
- | * checker ce qu' | ||
- | * template openvpn et docker | ||
- | * écrire plus de test pour les cron et django | ||
- | * passer de iptables à nftables | ||
- | * développer un outil d' | ||
- | * développer l' | ||
- | * 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/ | ||
- | |||
- | ==== TODO zteeed ==== | ||
- | |||
- | * certificat letsencrypt wildcard sur revproxy200 | ||
- | * script pour mettre à jour les CT si pas maj tous les 15 jours, commence par le faire sur ton ct => => => => <color # | ||
- | * sauvegarde propre du dump postgresql sur la vm database (faut dump les databases django et django_test, | ||
- | * upgrade de jessie vers stretch sur | ||
- | * passerelle => => <color # | ||
- | * revproxy => => <color # | ||
- | * dhcp => => <color # | ||
- | * ansible => => <color # | ||
- | * database => => <color # | ||
- | * nsh1 => => <color # | ||
- | * website => => <color # | ||
- | * on fera les serveurs physiques après => => | ||
- | * monitoring => => | ||
- | |||
- | ==== TODO manwefm ==== | ||
- | |||
- | * revoir le stockage et sa doc | ||
- | * résoudre pb réseau | ||
- | * écrire tests pour cron et ansible | ||
- | * monitoring | ||
- | * intégrer les tests à jenkins | ||