Résurrection du blog

Blabla

C’est à la date du 20/06/2020 à 02h07 que mon VPS (hébergeant entre autres ce site Web) a décidé de rendre l’âme.

À 02h32, le service de monitoring VPS m’envoie un e-mail m’avertissant de la situation.
Le matin, je tente donc un redémarrage du serveur : sans succès. À partir de là, impossible d’effectuer d’autres actions : reboot, réinstallation…
J’ouvre donc un ticket au support. Mais comme nous sommes le Week-End et que je suis sur le support standard, je pense que je peux rêver pour une réponse rapide…

J’en parle à des connaissances qui sont aussi surprises de moi que cela arrive sur un VPS. Car oui, le problème semble venir de mon VPS seul car il n’y a pas d’incident sur la page des travaux d’OVH.

Si cela est de ma faute, je n’ai clairement pas d’explication. Je maintiens à jour les paquets de la distribution afin d’éviter les problèmes. Étant donné que je ne peux rien faire sur l’interface d’administration d’OVH, je suis tenté de dire que le problème ne vient pas de moi. À l’heure ou j’écris cet article, toujours pas de nouvelle du support…

En vue du titre de l’article, vous comprenez bien que j’ai trouvé une solution. Ben j’ai pris un serveur dédié ! J’ai pris le serveur KS-3 de chez Kimsufi.
Pour ~2,5 fois plus chère, j’ai un vrai serveur avec le double de RAM et de cœurs ainsi que 100 fois plus de stockage. Je pourrais alors m’en servir pour des backups des données critiques de chez moi.
On ne va pas se mentir, pour le prix, tous n’est pas roses. En effet le CPU est un Intel Atom N2800, mais suffisant pour mon utilisation.

J’ai donc tous redéployé dessus, mais avec Traefik cette fois. De ce fait, je conteneurise tout ! De plus, afin de me compliquer la tâche (et donc me la simplifier plus tard), j’effectue toutes les actions par l’intermédiaire d’un playbook Ansible.

Vous trouverez donc ici une application de mes connaissances sur le déploiement (sans aucune vantardise, plutôt l’inverse) d’un nouveau serveur.
Je mettrais donc des fragments de mon playbook. Pour comprendre cela dans son ensemble, je vous invite à lire mon tuto sur le sujet

Pre-Ansible

Avant d’utiliser Ansible, j’ai changé la passphrase du compte, importé mes clés SSH et verrouillé SSH. Bien que, appart changer la passphrase, le reste était faisable avec Ansible, j’ai fait de cette manière car je ne savais pas encore que j’allais utiliser d’orchestrateur.

A oui, j’ai aussi fait une MAJ système car le serveur a été installé avec l’image 16.04 LTS d’Ubuntu. La 20.04 n’est pas encore disponible en MAJ donc je me traine encore le castor bionique.

Configuration de base

Installation d’applications

Il y a des outils que j’utilise qui ne sont pas forcément disponible de base dans la distribution comme vim, git ou encore tree.

Pour mettre à jour le cache et installer des packages :

1
2
3

- name: Install basic packages
  apt: name={{ item }} update_cache=yes
  loop: ['git', 'vim','tree', 'htop']

Bannière (MOTD)

J’aime bien avoir une bannière avec le nom du serveur en ASCII Art. Du coup, je fais un script en utilisant un générateur en ligne.

Je stocke le contenu du script sur mon PC (./configuration/files/05-banner) :

1
2
3
4
5
6
7
8
9

#!/bin/sh
echo ''
echo '  _   _                      '
echo ' | \ | |                     '
echo ' |  \| | __ _ _ __ ___   ___ '
echo ' | . ` |/ _` | '_ ` _ \ / _ \'
echo ' | |\  | (_| | | | | | |  __/'
echo ' |_| \_|\__,_|_| |_| |_|\___|'
echo ''

Pour la copier sur le serveur et lui attribuer les bons droits :

1
2
3
4
5

- name: Copy MOTD banner
  copy:
    src: ./configuration/files/05-banner
    dest: /etc/update-motd.d/05-banner
    mode: '0755'

Supervision

J’utilise Nagios via SSH pour superviser mes équipements. Pour appliquer les actions sur l’hôte visible sur mon article sur le sujet, je lance les tâches suivantes :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

- name: Add user "nagios"
  user:
    name: nagios
    shell: /bin/bash
    append: yes
    comment: "Nagios User"
    state: present
  become: true
- name: Add Nagios SSH Key
  authorized_key:
    user: "nagios"
    key: "ssh-ed25519 BHIwxeOQq6nTGgEJ0+7s5VHbubL29xPFij+rlxdgHBU= nagios@kaishin"
    state: present
- name: Install Nagios plugins
  apt: name=nagios-plugins

Installation de Docker

On fait ici le nécessaire pour installer Docker ainsi que Docker Compose.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

- name: Install required system packages
  apt: name={{ item }} state=latest
  loop: ['apt-transport-https', 'ca-certificates', 'curl', 'software-properties-common', 'gnupg-agent']

- name: Add Docker GPG apt Key
  apt_key:
    url: https://download.docker.com/linux/ubuntu/gpg
    state: present
- name: Verify that we have the key with the fingerprint
  apt_key:
    id: 0EBFCD88
    state: present

- name: Add Docker Repository
  apt_repository:
    repo: deb https://download.docker.com/linux/ubuntu bionic stable
    state: present

- name: Install Docker
  apt: update_cache=yes name={{ item }} state=latest
  loop: ['docker-ce', 'docker-ce-cli', 'containerd.io']

- name: Install docker-compose
  get_url: 
    url : https://github.com/docker/compose/releases/latest/download/docker-compose-Linux-x86_64
    dest: /usr/local/bin/docker-compose
    mode: 'u+x,g+x'

Services Docker

À partir de là, on a tous les éléments nécessaires à la mise en place de services via Docker. Pour rendre le déploiement réexploitable, l’ensemble des fichiers de configuration vont être créés sur le PC et copier sur le serveur avec Ansible. On a déjà vu un cas de ce type avec la bannière.

Organisation

J’ai décidé de stocker les compositions dans le dossier /srv du serveur car je trouve que la description va bien avec le type de données.

Données pour les services hébergés sur le système. Habituellement le contenu web statique ou les fichiers d’un serveur FTP, une base de données…
Wikipédia

Les fichiers dits de “configuration” vont être mis dans le dossier /etc et les données dans /var/lib.

J’ai donc créé l’arborescence suivante pour mes services (on y voit Gotify et mes sites Web) :

Déploiement des fichiers

En voyant la manière dont je monte les volumes pour Traefik :

1
2
3
4
5
6
7

# Extrait du docker-compose.yml de Traefik
env_file:
  - /etc/traefik/.ovh-api.env
volumes:
  - /etc/traefik/traefik.yml:/etc/traefik/traefik.yml:ro
  - /etc/traefik/dynamic/:/etc/dyn_config/
  - /etc/traefik/acme.json:/acme.json

J’effectue la copie des fichiers ainsi :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

- name: Copy Docker Compose config directory
  copy:
    src: ./configuration/dockers
    dest: /srv
    # Create backup files if modified
    backup: yes

- name: Copy Traefik config directories
  copy:
    src: ./configuration/traefik
    dest: /etc
    # Override modified files
    backup: no
- name: Create Traefik config directories
  file:
    path: /etc/traefik/dynamic
    state: directory
    recurse: yes
- name: Does Traefik acme.json exist ?
  copy:
    content: ""
    dest: /etc/traefik/acme.json
    mode: '0600'
    force: no

Pour les fichiers Docker Compose, j’ai mis la directive backup à yes. De cette manière, si je modifie un fichier dans le dossier et que je relance le playbook, l’ancienne version (sur le serveur) va alors être suffixée avec la date du lancement du playbook et la version du PC (celle à jour) va venir la remplacer. De cette manière, je peux récupérer la version qui était sur le serveur en cas d’erreur.
La dernière tâche créera le fichier que s’il n’existe pas et donne seulement les droits rw au propriétaire (nécessaire).

Pour plus de détail sur la configuration de Traefik : ici et ici

J’ai réappliqué les mêmes principes pour préparer les autres services.

Déploiement des services

Au risque de vous décevoir, je ne gère pas les conteneurs avec Ansible. Je pense que j’ai besoin de plus de compétence pour le faire correctement. Voyez ici un exemple de playbook déployant une stack Docker que j’ai déjà utilisé. Impressionnant non ?

Que pensé de tout ça ?

Je ne peux cacher mon énervement face à ce problème de VPS (vous l’aurez compris vu qu’il n’y a pas d’émoji dans cet article…). Je ne peux même pas réinstaller le VPS !

Mais bon, voyons plutôt le bon côté des choses. Cela m’a permis de passé sur un serveur plus puissant pour pas beaucoup plus (et c’est un dédié !). Je vais tous de même cumuler le coût deux serveurs jusqu’à la fin de l’engagement du VPS. Si je retrouve mon VPS, je pourrais m’en servir pour faire des tests.

Cette aventure en plus d’avoir occupé mon Week-End, m’a permis d’avoir une application plus complète d’Ansible. Du coup, si j’ai un problème sur ce serveur, je pourrais redéployer les services en moins de 15 minutes (après un interminable do-release-upgrade).

Pour rester dans cette optique, le travail que j’effectuerais sur ce serveur se fera exclusivement via Ansible.