Mon infrastructure en tant qu’hébergeur web indépendant

1. Présentation de l’infrastructure

Dans cette infrastructure, chaque application tourne sous forme d’un ou plusieurs conteneurs répartis sur un ou plusieurs serveurs selon leurs ressources disponibles.

Les conteneurs permettent d’accélérer et faciliter le déploiement des applications, ils contiennent toutes les dépendances d’une application et sont indépendants vis-à-vis de l’infrastructure hôte. Additionné à un orchestrateur, par exemple Docker Swarm, on dispose d’un système qui exécute, coordonne et gère entièrement le cycle de vie de nos applications.

Aujourd’hui je démarre mon infrastructure avec trois petits serveurs, demain elle pourra évoluer facilement suivant l’augmentation des demandes clients.

Plutôt que de gérer mon infrastructure sous forme de tâches manuelles et répétitives, une grande partie est gérée à l’aide de fichiers de définition que je versionne. Dans mon cas, il s’agit principalement de fichiers YAML.

Si jamais tous mes serveurs venaient à être stoppés ou supprimés inintentionnellement, je peux à priori tout restaurer en moins d’une heure du moment que je dispose des backups.

Une fois l’infrastructure mise en place, il est possible de démarrer une application en seulement une ligne de commande, par exemple :

• Un tchat (ex : rocket.chat)
• Un blog (ex : WordPress, Joomla, Ghost)
• Un site e‑commerce (ex : PrestaShop)
• Un espace de stockage (ex : ownCloud, Nextcloud)
• Un système de facturation (ex : Invoice Ninja)
• Un système de monitoring et d’alerting (ex : Grafana + Prometheus + Alertmanager)

Le tout avec un nom de domaine et un certicat SSL associé automatiquement.

3. Persistence des données

Une application stateful, contrairement à une application stateless, a besoin de persister certaines données comme une base de données (des fichiers de configurations ou de simples fichiers images par exemple). On utilise pour ça les volumes docker. De plus, avec Docker Swarm, les containers sont volatiles et ne restent pas toujours reliés à un unique serveur. Il faut donc utiliser un volume driver.

Un espace de stockage flexible

Afin d’éviter d’éparpiller les données et étendre facilement la taille de notre espace de stockage, j’ai créé une partition LVM qui combine plusieurs volumes de données. Au fur et à mesure que l’infrastructure grandit, il est possible d’ajouter nos volumes de données à cette partition.

Avec Scaleway, il est très simple d’ajouter et de relier des volumes de données à un serveur. Une fois nos volumes reliés, nous pouvons les combiner ensemble pour former un seul point de montage.

L’installation se fait sur notre serveur master :

apt-get install -y lvm2
systemctl start lvm2-lvmetad.socket
pvcreate /dev/{nbd1,nbd2}
vgcreate lvm /dev/nbd1 /dev/nbd2
lvcreate -l 100%FREE -n storage lvm
mkfs -t ext4 /dev/lvm/storage
echo "/dev/mapper/lvm-storage /mnt ext4 rw,relatime 0 0" >> /etc/fstab
mount -a
sed -i -e 's/use_lvmetad = 1/use_lvmetad = 0/g' /etc/lvm/lvm.conf

À l’avenir, si vous souhaitez agrandir votre espace de stockage via d’autres volumes, il suffit simplement d’exécuter les commandes suivantes :

umount /mnt
vgextend lvm /dev/nbd3
lvextend -l +100%Free /dev/lvm/storage
resize2fs /dev/lvm/storage
mount -a

Volume driver

Le volume driver que j’ai choisi s’appelle docker-volume-netshare. Chaque application persistera ses données sur un serveur NFS.

On installe notre serveur NFS sur notre master :

sudo apt-get install -y nfs-kernel-server
sudo mkdir /mnt/data

Puis on autorise tous les serveurs à s’y connecter :

# /etc/exports
/mnt/data 127.0.0.1(rw,sync,no_subtree_check,no_root_squash) worker-01.priv.cloud.scaleway.com(rw,sync,no_subtree_check,no_root_squash) worker-02(rw,sync,no_subtree_check,no_root_squash)

On redémarre notre serveur afin d’appliquer notre configuration :

sudo systemctl restart nfs-kernel-server

Puis on installe sur tous les serveurs le package nfs-common et notre volume driver docker-volume-netshare :

sudo apt-get install -y nfs-common

sudo wget -O /usr/bin/docker-volume-netshare https://github.com/ContainX/docker-volume-netshare/releases/download/v0.35/docker-volume-netshare_0.35_linux_amd64-bin
sudo chmod +x /usr/bin/docker-volume-netshare

On crée un service docker-volume-netshare qui sera lancé à chaque démarrage serveur :

# /etc/systemd/system/docker-volume-netshare.service
[Unit]
Description=Docker NFS, AWS EFS & Samba/CIFS Volume Plugin
Documentation=https://github.com/gondor/docker-volume-netshare
Wants=network-online.target
After=network-online.target
Before=docker.service

[Service]
ExecStart=/usr/bin/docker-volume-netshare nfs
StandardOutput=syslog

[Install]
WantedBy=multi-user.target

systemctl enable docker-volume-netshare.service
systemctl start docker-volume-netshare.service

Pour vérifier si tout fonctionne correctement, vous pouvez créer un volume « test » :

docker volume create --driver nfs --name=test --opt share=127.0.0.1:/mnt/data --opt create=true

Puis créer un fichier « test » depuis un container :

docker run --rm -v test:/mount alpine touch /mount/test

Ce fichier devrait apparaître dans le répertoire /mnt/data de votre serveur master.

5. Reverse-proxy et Let’s Encrypt

Objectif : Configurer un reverse proxy pour accéder à nos applications via un unique point d’entrée.

Personnellement, j’utilise Traefik, qui est compatible avec Docker Swarm.

On crée un network que l’on nomme par exemple traefik-net, il sera utilisé pour relier de manière automatique chaque application à Traefik à l’aide des labels.

docker network create --driver=overlay traefik-net

Puis on déploie Traefik uniquement sur notre serveur master :

# traefik.yml

version: "3.3"
services:
  traefik:
    image: traefik
    command: --docker \
      --docker.swarmMode \
      --docker.watch
    ports:
      - "80:80"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    deploy:
      placement:
        constraints: [node.role==manager]

networks:
  default:
    external:
      name: traefik-net

docker stack deploy -c traefik.yml traefik

Enfin, pour relier une application à notre reverse proxy, on peut créer un service docker avec des labels qui indiqueront à Traefik de diriger le traffic HTTP du domaine blog.ston3o.me sur le(s) bon(s) container(s) :

docker service create --name blog --network traefik-net -l traefik.port=2368 -l traefik.frontend.rule=Host:blog.ston3o.me -l traefik.enable=true ghost

Let’s Encrypt

Pour automatiser la création de certificats SSL des services exposés à l’extérieur de mon cluster, j’ai configuré Traefik avec ce fichier de configuration :

# traefik.toml

debug = true
logLevel = "DEBUG"
defaultEntryPoints = ["https","http"]

[entryPoints]
  [entryPoints.http]
  address = ":80"
    [entryPoints.http.redirect]
    entryPoint = "https"
  [entryPoints.https]
  address = ":443"
    [entryPoints.https.tls]

[acme]
email = "contact@example.com"
storage = "acme.json"
acmeLogging = true
entryPoint = "https"
onHostRule = true

[acme.httpChallenge]
  entryPoint = "http"

7. Monitoring, alerting et logging

Pour monitorer tous mes serveurs, pour être alerté à chaque fois qu’une application ne renvoie pas un code 200 ou qu’un CPU, RAM, Disque dépasse les 95% d’utilisation. Je me suis créé une stack avec grafana, prometheus et alertmanager.

Et d’une commande, je peux tout installer :

DOMAIN_GRAFANA=grafana.mondomaine.fr DOMAIN_PROMETHEUS=prometheus.mondomaine.fr docker stack deploy -c monitoring.yml monitoring

La stack elastic quant à elle, va me servir à logger tout le traffic HTTP entrant sur Traefik et collecter les syslog de chaque serveur.

DOMAIN=kibana.mondomaine.fr docker stack deploy -c elastic.yml elastic