Dedibox + OpenVZ + vzdump + raspberrypi + crontab + rsync = ❤

Essayez de vous imaginer en train de faire la vaisselle avec des gants de boxe et vous aurez une bonne image de ce à quoi je ressemble lorsque je dois faire de l'administration système.

Entre Heroku, Amazon, les pages Github et j'en passe, bien peu nombreux sont les développeurs qui souhaitent encore gérer leur propre serveur. Pourtant, le serveur dédié est devenu relativement abordable depuis la guerre des prix entre Online et OVH, et reste un must en terme de souplesse et de liberté. Évidemment, il faut mettre les mains dans le cambouis.

Jusqu'à il y a quelques semaines, je louais deux serveurs (!) : un censé être réservé à des projets sensibles (ex : ce blog, plutôt vital pour mon activité) et l'autre réservé aux tests, préproduction des sites en développement, petits projets qui s'accumulent et jamais mis à jour, etc. Au fil des ans, cette configuration est vite devenue fort b**lique, sans compter le coût récurrent.

J'ai donc décidé de tout mettre à plat et de ne plus louer qu'un seul serveur. Évidemment, je me voyais mal héberger côte à côte des sites en production vitaux, des backups de données confidentielles, et des vieux drupals pourris et jamais mis à jour.

Mon architecture est donc tout ce qu'il y a de plus classique, et répond aux problématiques suivantes :

  • me permettre d'héberger tout ce qui me passe par la tête ;
  • assurer un niveau de sécurité correct ;
  • faciliter les backups ;

Attention, si vous êtes admin système pro, ce post vous fera sans doute bien rire. Pour les devs dont ce n'est pas l'activité principale, peut-être que ça vous dépannera.

Des machines virtuelles avec OpenVZ

Dans la mesure ou j'ai une utilisation professionnelle de mon hébergement, je peux me permettre de dépenser 30€ par mois pour de l'hébergement. J'ai donc fait le choix d'une Dedibox classique à 30€ chez Online avec une installation Debian Wheezy, ce qui est plus que largement suffisant pour faire tourner à peu près n'importe quoi.

L'astuce consiste à systématiquement créer des machines virtuelles pour héberger chaque projet (sites, serveur de mail, serveur git, serveur de backup, etc.).

J'ai fait le choix d'OpenVZ (et j'ai été conseillé par des gens très bien). OpenVZ est une techno qui a fait ses preuves, et qui permet de créer sur une machine physique plusieurs instances de systèmes d'exploitation isolés. OpenVZ est un conteneur, ce qui signifie que chaque machine virtuelle utilisera le noyau linux du système hôte, et qu'il n'est pas possible d'installer un windows ou autre. En contrepartie, l'impact sur les performances est très faible. Ça tombe bien, c'est ce qu'on veut : plein de petits serveurs Debian.

L'installation d'OpenVZ sur Debian est assez rapide et bien documentée, je vous laisse donc réaliser ces opérations par vous même.

Commander quelques IP failover

Comme je veux que chaque machine soit indépendante et que je n'ai pas envie de me compliquer la tâche, je loue également quelques ip failover.

Le principe d'une ip failover est simple : il s'agit simplement d'une adresse ip supplémentaire que vous pouvez faire pointer vers votre machine, et affecter à une instance OpenVZ. Vous pouvez alors faire pointer vos DNS vers ces ip supplémentaires plutôt que vers l'ip principale de la machine.

C'est très pratique, parce que le jour ou vous voulez changer de serveur, il suffit de déplacer la machine virtuelle vers la nouvelle machine physique, et de modifier la configuration de l'ip failover. Pas besoin de toucher à la configuration DNS. Et en 5 minutes, c'est fait. Pareil pour basculer d'un serveur principal à un serveur de backup, c'est quasi transparent pour l'utilisateur.

Créer une machine virtuelle

Une fois OpenVZ installé et les ip commandées, créer une nouvelle machine est confondant de simplicité. Ici, 101 représente un identifiant arbitraire.

vzctl create 101 --ostemplate=debian-7.0-x86_64
vzctl set 101 --ipadd xx.xx.xx.xx --save
vzctl start 101
vzctl enter 101

Et hop ! Vous voilà root sur une belle machine toute neuve, avec sa propre ip et sa propre arborescence de fichier. Pour retourner sur la machine principale, il suffit de terminer la console en cours (exit ou ctrl^D). Vous pouvez également vous connecter directement en ssh sur la machine fille.

Sécuriser les connexion ssh

Si vous avez déjà jeté un coup d'œil aux logs de tentatives de connexion, vous connaissez déjà l'importance de bien configurer son serveur ssh. Une solution fort simple et qui marche très bien est de désactiver purement et simplement les connexions par mot de passe pour n'autoriser que les connexions par clé publique.

Comme il existe déjà des bazillions de tutos qui expliquent comment on fait ça, je ne vais pas me répéter ici… Comment ? Si ? Bon, mais c'est vraiment pour vous faire plaisir.

Commencez par générer une clé publique sur votre machine locale (si ce n'a pas encore été fait), et copiez la sur le serveur.

ssh-keygen -t dsa
ssh-copy-id -i ~/.ssh/id_dsa.pub user@xx.xx.xx.xx

Vérifiez que vous vous connectez sans problème sans taper de mot de passe, puis éditez le fichier de conf du serveur ssh (/etc/ssh/sshd_config). Vérifiez la présence des paramètres suivants.

PermitRootLogin yes
PubkeyAuthentication yes
PasswordAuthentication no
UsePAM yes
Match User git
    PasswordAuthentication yes

Puis redémarrez le serveur ssh.

Vous noterez qu'il est possible d'ajouter des exceptions. J'autorise par exemple la connexion à l'utilisateur git avec un mot de passe, parce que ça me simplifie grandement la vie. N'en abusez pas.

N'oubliez pas de sécuriser toutes vos machines virtuelles et la machine hôte.

Héberger un serveur web

Chaque machine virtuelle est un véritable serveur que vous pouvez utiliser comme bon vous semble. Par exemple pour héberger un projet Django. Je ne vous refais pas le topo.

Un serveur de mail privé

Même chose, je me contenterai de vous rediriger vers cet article écrit il y a quelques temps.

Git rural

Il y a les projets qu'on peux héberger sur Github, et puis il y a les autres. Héberger un serveur git privé est simple comme bonjour, il suffit d'avoir un serveur ssh qui tourne et git installé (apt-get install git).

Commencez par créer l'utilisateur système approprié.

adduser git

Même si j'autorise les connexions ssh vers cet utilisateur pour gagner du temps, je peux néanmoins limiter les possibilités pour un éventuel assaillant de pourrir mon système, en limitant le shell de l'utilisateur. Dans /etc/passwd, remplacez le shell de l'utilisateur git par /usr/bin/git-shell/.

git:x:1001:1001:,,,:/home/git:/usr/bin/git-shell

Vous pourrez vérifier que l'utilisateur git ne peux pas accéder à un shell interactif en essayant de vous logguer avec ce compte.

su - git
fatal: Interactive git shell is not enabled.

Pour créer un nouveau dépôt :

cd /home/git/
git init project.git --bare
chown git:git -R project.git

Ensuite, depuis votre machine locale, il vous suffit de cloner le dépôt…

git clone ssh://git@mon.serveur.git/home/git/project.git

…ou de configurer le dépôt distant s'il s'agit d'un dépôt existant.

git remote add origin ssh://git@mon.serveur.git/home/git/project.git
git push origin master

Backup ALL the things

Un des très gros avantages des machines virtuelles, c'est que le backup devient très simple. Plutôt que de se prendre la tête à sauvegarder chaque base de données, chaque répertoire, chaque projet, etc., on sauvegardera toutes les machines d'un coup ; chaque backup pourra être remonté en local en un éclair.

On utilise pour ça l'utilitaire vzdump, à installer sur la machine hôte.

apt-get install vzdump

Le script de backup ira dans la crontab (crontab -e).

SHELL=/bin/bash
HOME=/root/
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# m h  dom mon dow   command
42 2 * * * vzdump --all --suspend --mailto moi@gmail.com --maxfiles 5

Toutes les nuits, une belle archive toute propre sera déposée pour chaque machine dans /var/lib/vz/dump/.

Évidemment, des backups qui restent sur le serveur ne vous serviront pas à grand chose si ce même serveur plante, devient indisponible ou si vous oubliez de le renouveler. L'idéal est donc de les rapatrier quotidiennement chez vous, ou ailleurs.

J'utilise pour ça un raspberryPi branché sur un bête disque usb. Ça peut rester allumer 100% du temps et ça fait un nas pas naze. Sur la crontab du raspberry :

42 3 * * * rsync root@monserveur.com:/var/lib/vz/dump/ /media/hdd/backups/openvz/ -av

C'est tout.

Pour aller plus loin

Il existe tout un tas de super technologies toutes plus in et modernes les unes que les autres et que j'utiliserai peut-être un jour si la Terre sort de son orbite et que les journées commencent à durer plus de 24h. En attendant, je me contenterai de vous lister en vrac quelques noms :