J’ai un peu modernisé et fiabilisé mon auto-hébergement, en suivant quelques principes :

• Reproductibilité : la configuration de l’OS, l’installation et la configuration des services qui tournent dessus doivent être automatisés
• Sauvegardes automatiques : les données de chaque service doivent être sauvegardées automatiquement, périodiquement
• Failover en mode actif/passif : chaque service doit être installé sur un serveur actif, et sur un ou plusieurs serveurs passifs. Les données sont synchronisées automatiquement sur les passifs, périodiquement
• Indépendance de chaque serveur : chaque machine doit être la plus indépendante possible des autres

L’objectif est de limiter les interruptions de service (lorsqu’une machine est en rade, ou en maintenance), et de simplifier les mises à jour de l’OS sous-jacent (il y a plusieurs images, qui s’améliorent régulièrement) ou les déplacements d’un service d’une machine à une autre.

Bonus : avec une architecture de ce type, le PRA se fait très naturellement, en mettant simplement une autre machine passive à l’extérieur (il est très facile d’avoir plusieurs serveurs passifs).

J’ai mis en œuvre tout ça sur des petits serveurs Olinuxino A64 (pour les serveurs actifs), et avec l’aide des autres machines existantes pour le reste (Olinuxino A20 et Sheevaplug).

C’est évidemment Ansible que j’ai choisi pour l’automatisation des installations/configurations, et aussi pour les sauvegardes/mises à jour périodiques des données.

Playbooks d’installation

J’ai mis en ligne les rôles Ansible que j’ai créés pour ça :

• https://gitlab.com/mossroy/ansible-role-init-a64 me permet d’initialiser un serveur A64 (sous Debian Buster). J’ai mis ce que fait le playbook dans le README (je ferai peut-être un article dédié pour expliquer plus en détail)
• des roles simples pour les stacks LAMP et LAPP : https://gitlab.com/mossroy/ansible-role-apache, https://gitlab.com/mossroy/ansible-role-php, https://gitlab.com/mossroy/ansible-role-mariadb et https://gitlab.com/mossroy/ansible-role-postgresql
• et des roles très basiques pour installer quelques services : https://gitlab.com/mossroy/ansible-role-kanboard, https://gitlab.com/mossroy/ansible-role-nextcloud, https://gitlab.com/mossroy/ansible-role-piwigo, https://gitlab.com/mossroy/ansible-role-ttrss, et https://gitlab.com/mossroy/ansible-role-wordpress

Playbook de sauvegarde et synchronisation actif/passif

Sur une des machines, j’ai installé Jenkins, et y ai configuré un pipeline lancé automatiquement chaque nuit, qui enchaîne :

• La sauvegarde de chacun des services depuis le serveur actif
• La mise à jour des données de chaque service sur les serveurs actifs
• La sauvegarde complète du filesystem de chaque machine

Techniquement, c’est le module synchronize d’Ansible qui est utilisé, qui s’appuie sur rsync pour mettre à jour les données sur le serveur de backup (en incrémental). Pour l’éventuelle base de données, j’exporte un dump (MySQL ou PostgreSQL, en utilisant les modules standards d’Ansible).

Dans un second temps, je mets à jour les serveurs passifs avec les mêmes données (à partir du serveur de backup), et en y important l’éventuel dump de base de données.

J’ai mis en ligne ce role : https://gitlab.com/mossroy/ansible-role-datasync (voir le README pour quelques exemples d’utilisation)

A noter que, compte tenu de la faible puissance des appareils, et s’ils sont tous en réseau local, je recommande de désactiver la compression lors du rsync (en passant la variable datasync_compression à false) : cela permet de gagner pas mal de temps.

Pour lancer la synchronisation de données depuis Jenkins, j’ai créé des Jenkinsfiles comme le suivant :

pipeline {
    options {
        buildDiscarder(logRotator(numToKeepStr: '30', daysToKeepStr: '365'))
    }
    agent { node { label 'ansible'}}
    stages {
        stage('update roles') {
        steps {script{
            sh './update_roles.sh'
        }}
        }
        stage('data sync') {
        steps {script {ansiColor('xterm') {
            ansiblePlaybook(
                playbook: 'sync-donnees-ttrss.yml',
                credentialsId: 'cle-ssh-pour-sauvegardes-serveurs',
                extras: '-e ansible_user=sauvegardes',
                colorized: true)
        }}}
        }
    }
    post {
        always {
          step([$class: 'Mailer',
            notifyEveryUnstableBuild: true,
            recipients: "mossroy@mossroy.fr"])
        }
    }
}

Le script update_roles.sh s’occupant de récupérer les roles Ansible :

ansible-galaxy install -r roles/requirements.yml --roles-path roles --force

En s’appuyant sur le fichier requirements.yml suivant :

- src: git+https://gitlab.com/mossroy/ansible-role-apache.git
  name: apache
- src: git+https://gitlab.com/mossroy/ansible-role-init-a64.git
  name: init-a64
- src: git+https://gitlab.com/mossroy/ansible-role-php.git
  name: php
- src: git+https://gitlab.com/mossroy/ansible-role-mariadb.git
  name: mariadb
- src: git+https://gitlab.com/mossroy/ansible-role-postgresql.git
  name: postgresql
- src: git+https://gitlab.com/mossroy/ansible-role-kanboard.git
  name: kanboard
- src: git+https://gitlab.com/mossroy/ansible-role-nextcloud.git
  name: nextcloud
- src: git+https://gitlab.com/mossroy/ansible-role-piwigo.git
  name: piwigo
- src: git+https://gitlab.com/mossroy/ansible-role-ttrss.git
  name: ttrss
- src: git+https://gitlab.com/mossroy/ansible-role-wordpress.git
  name: wordpress
- src: git+https://gitlab.com/mossroy/ansible-role-datasync.git
  name: datasync