Archives de catégorie : Hébergement

About – ce site

Juste une petite description de l’architecture de ce site.

Pas de détails, rien de très compliqué non plus.

Ce site est installé comme suit :

  • Nginx avec un cache fastcgi
  • php5-fpm avec plusieurs pool
  • et bien sur WordPress (sans aucune extension d’optimisation)

Sa base de données est :

  • MariaDB

Le tout est sur une petite Dedibox qui fait plein d’autres trucs.

LXC – virtualisation/conteneur

Un petit article pour décrire le fonctionnement de LXC (LinuX Containers) et son utilisation sur une Debian Wheezy.

J’avais commencé ce blog en parlant de Linux Vserver, un système de « virtualisations au niveau du système d’exploitation ».

Ça m’a bien rendu service, mais vserver n’est plus intégré à la Debian Wheezy, il a été remplacé par LXC, hors il fallait bien que je fasse la mise à jour de mes Squeeze.

Je vais faire court car il existe de nombreuses docs sur LXC.

On commence par mettre à jour la Debian (sauf exceptions, il vaut mieux utiliser aptitude que apt-get) :

On installe le paquet LXC :

Je rajoute aussi le paquet bridge-utils, mais il n’est pas obligatoire.

Dans /etc/fstab, on ajoute un point de montage pour gérer les ressources :

Attention, il y a un bug dans le script de création des premières Wheezy (corrigé en 7.4 de mémoire).

Le plus simple est de créer un nouveau fichier de modèle, je me suis librement inspiré de celui proposé ici.

Voici mon template /usr/share/lxc/templates/lxc-debian-wheezy :

Attention à la ligne 65, il faut bien évidemment changer le mot de passe, soit dans le template lui-même, soit dans le conteneur une fois déployé.

Pour le reste, libre à vous d’adapter le script, en particulier les lignes 74 à 85 (paquets installés par défaut) et les lignes 179 à 212 qui contiennent le paramétrage du conteneur, en particulier la configuration réseau :

Le paquet LXC vient avec toute une panoplie d’outils de gestion des conteneurs, entre autre :

  • lxc-create – déployer un conteneur
  • lxc-ls – lister les conteneurs déployés
  • lxc-list – lister le status des conteneurs
  • lxc-start – démarrer un conteneur
  • lxc-stop – arrêter un conteneur
  • lxc-console – « entrer » dans un conteneur
  • lxc-destroy – supprimer un conteneur
  • Par exemple pour créer un conteneur :

  • On peut modifier sa configuration en éditant le fichier :

  • On démarre le conteneur avec :

  • On se connecte à la console avec :

Pour quitter la console il faut faire CTRL+a, q

  • On arrête le conteneur avec :

  • On le supprime avec :

  • Pour qu’un conteneur démarre avec l’hôte, il suffit de créer un lien vers son fichier « config » dans /etc/lxc/auto/ :

Quelques recommandations pour terminer :

  • l’utilisation de LVM est fortement recommandée, ne serait ce que pour faire des sauvegardes à chaud;
  • il vaut mieux laisser les conteneurs dans l’emplacement par défaut (/var/lib/lxc),
  • donc il est recommandé de faire un point de montage sur ce dossier
Sources :

VPS – Serveur dédié virtuel

Comme je ne sais pas par où commencer dans mon rangement, je vais donc noter ici ce sur quoi je travaille en ce moment : vserver

Dans le cadre de mon travail, on m’a demandé d’étudier les différentes solutions d’hébergement « vite fait et pas cher ». L’objectif est d’offrir à certains utilisateurs la possibilité, d’avoir leur propre espace Web perso, accessible de partout et surtout sans que ça nécessite des ressources de support, en gros du clefs en main.

La suite est une petite histoire qui n’intéressera probablement que ceux qui travaillent dans un métier d’administration système ou de support IT.

Quelques points de détails font qu’on ne peut pas décemment leur dire d’aller chez le premier hébergeur venu :

  • ces sites sont à vocation professionnelle
  • ces utilisateurs sont des VIP (tout est relatif…)

Actuellement, quand l’un des ces utilisateurs veut un tel espace, il y a en gros 3 cas de figure, qui s’enchainent (de 1 vers 3 et de 3 vers 1) :

  1. il fait ça dans son coin (sur un hébergement perso la plupart du temps, parfois sur du semi pro)
  2. il demande un espace sur un coin de serveur
  3. il se plaint qu’on ne lui propose pas d’office un tel outil de travail

Dans tous les cas ça nous (service info) pose des problèmes de sécurité et/ou de ressources en support à plus ou moins court terme : l’utilisateur demande une intégration de son site aux sites internes, il souhaite avoir une URL @corp, il n’arrive pas à déménager son site chez un autre hébergeur, on ne peut pas lui laisser toute la latitude qu’il souhaite sur nos serveurs (question de sécurité), nous sommes des incompétents …

J’ai donc fait une étude rapide sur les offres d’hébergement du marché (OVH, 1&1, Online, Amen …).

Sur beaucoup de points ces offres semblaient répondre aux besoins, mais elles avaient toutes le même talon d’Achille, elles nous auraient couté très chez en temps de support (gestion des comptes, création des bases SQL, configuration DNS, sauvegardes, …). Il aurait donc fallut acheter un hébergement par utilisateur (et là c’est le cout administratif qui aurait explosé).

En gros les offres d’hébergement mutualisé c’est bien quand ce n’est pas mutualisé.

J’ai donc regardé la possibilité de le faire en interne. La problématique est la suivante :

  1. pour chaque utilisateur qui en fait la demande, on doit offrir un espace de 1Go (donc avec une gestion des quotas), une base de donnée, un serveur Web, un interpréteur PHP et un accès en FTP
  2. l’adresse doit être du type http://serveur.domaine.tld/LOGIN (domaine étant ici l’un de nos noms de domaines)
  3. le déploiement d’un espace totalement opérationnel et configuré ne doit pas prendre plus de 5min (donc ça doit être scriptable)
  4. le service doit être simple à l’usage pour les utilisateurs (le plus proche possible ce que l’on trouve chez un hébergeur grand public)
  5. l’utilisateur doit pouvoir déployer les outils classiques (wordpress, joomla, drupal, sugar, …) de manière autonome
  6. le système doit être sécurisé, un utilisateur ne doit pas pouvoir accéder aux données d’un autre (pondéré par la sécurité du mot de passe)
  7. la mise en place du système (documentations et backups compris) ne pas pas prendre plus de 2 jours d’ingénierie
  8. le tout sur un seul serveur avec une seule IP et dans une DMZ public dédiée

Indépendamment les uns des autres, ces points sont simples à respecter, mais les mettre tous ensemble relève du casse tête.

Pour le 1, pas de problèmes pour le serveur Web (il suffit de l’installer) ni pour le FTP (on peut facilement chrooter les utilisateurs), mais PHP pose un sérieux problème de sécurité en environnement mutualisé. En quelques lignes, on accède (au moins) à tout ce qui est accessible par le serveur Web, à commencer par les données des autres utilisateurs, ce qui entre en conflit avec le point 6. Si on sécurise d’avantage PHP (open_basedir, disable_functions, …), le point 5 ne peut pas être respecté.

J’ai donc cherché une autre approche, virtualiser tout ça, sur un seul serveur avec un reverse proxy et un peu de SNAT.

Il existe plusieurs types de virtualisation, on dispose d’ailleurs d’une ferme ESX, mais le point 8 en réduit l’utilité.Je suis donc partie sur une solution indépendante, autonome et bien plus efficace en terme de ressource : le VPS.

J’ai évalué 3 techno de VPS :

  • LXC : plein de promesses, mais j’ai eu un bug et mon délai de mise en place de la solution était limité
  • OpenVZ : trop long à configurer, j’aurai passé trop de temps à faire une documentation d’exploitation pour mes collègues
  • Linux-VServer : moins puissant que les deux précédent, mais très simple et très rapide à mettre en place

J’ai donc opté pour Linux-VServer dans l’architecture suivante :

  • une Debian Squeeze avec le noyau vserver
  • nginx en reverse proxy
  • un peu d’iptables pour la sécurité et le SNAT
  • un vserver dédié à MySQL
  • un modèle de vserver avec Apache2 et PHP5 configurés
  • un système de déploiement du modèle

La mise en place de l’architecture (installation, configuration, backup, logs, template, scripts de déploiement, …) peut se faire en 2 heures, plus environ autant pour la documentation d’exploitation.

Il me reste encore à peaufiner quelques points pour l’automatisation totale du déploiement, notamment mettre une interface devant mon script de déploiement et ajouter un petit module de stats propre à chaque utilisateur, mais je pense que c’est une technologie que je vais faire rentrer de plus en plus dans notre DataCenter.

Pour le détail de l’installation, c’est un autre article.