Automatiser son infra Linux : crons, scripts et alertes

L'infrastructure self-hosted n'est vraiment efficace que si elle tourne toute seule. Dans cet article, je vous montre comment j'automatise l'infrastructure BOTUM : backups nocturnes, rotation des logs, alertes Telegram, et mises à jour Docker — le tout avec des crons et scripts bash.

Crontab — La base de l'automatisation Linux

Cron est le planificateur de tâches natif de Linux. Il permet d'exécuter n'importe quelle commande ou script à une heure précise, de façon répétitive. La syntaxe comprend 5 champs :

# Syntaxe crontab :
# min  heure  jour-du-mois  mois  jour-de-semaine  commande
# *    *      *             *     *                commande

# Exemples :
# 0 3 * * *     = Tous les jours à 3h00
# 0 */6 * * *   = Toutes les 6 heures
# 30 8 * * 1    = Tous les lundis à 8h30
# 0 0 1 * *     = Le 1er de chaque mois à minuit
# */5 * * * *   = Toutes les 5 minutes
# 0 4 * * 0,6   = Sam et dim à 4h00

# Éditer votre crontab :
crontab -e

# Lister les tâches cron actives :
crontab -l

# Crontab système (s'exécute en root) :
sudo nano /etc/crontab
# ou créer un fichier dans /etc/cron.d/

Script de backup Docker — Automatiser les sauvegardes

Ce script sauvegarde tous les volumes Docker importants et envoie une alerte Telegram avec le résultat :

#!/bin/bash
# /usr/local/bin/docker-backup.sh
# Sauvegarde quotidienne des volumes Docker critiques

set -euo pipefail

BACKUP_DIR="/backup/docker/$(date +%Y-%m-%d)"
LOG_FILE="/var/log/docker-backup.log"
TELEGRAM_TOKEN="VOTRE_TOKEN_BOT"
TELEGRAM_CHAT="VOTRE_CHAT_ID"
RETENTION_DAYS=7

# Créer le dossier de backup
mkdir -p "$BACKUP_DIR"

send_telegram() {
    local msg="$1"
    curl -s -X POST "https://api.telegram.org/bot${TELEGRAM_TOKEN}/sendMessage"         -d chat_id="${TELEGRAM_CHAT}"         -d text="${msg}"         -d parse_mode="HTML" > /dev/null
}

echo "$(date): Démarrage backup" | tee -a "$LOG_FILE"

# Sauvegarder Ghost Blog
echo "Backup Ghost Blog..." | tee -a "$LOG_FILE"
tar czf "${BACKUP_DIR}/ghost-data.tar.gz"     /mnt/docker-data/ghost-blog/content/data/ &&     echo "OK: Ghost Blog" | tee -a "$LOG_FILE"

# Sauvegarder Vaultwarden
echo "Backup Vaultwarden..." | tee -a "$LOG_FILE"
docker stop vaultwarden 2>/dev/null || true
cp ~/docker/vaultwarden/data/db.sqlite3     "${BACKUP_DIR}/vaultwarden.db" &&     echo "OK: Vaultwarden" | tee -a "$LOG_FILE"
docker start vaultwarden 2>/dev/null || true

# Calculer la taille totale
TOTAL_SIZE=$(du -sh "$BACKUP_DIR" | cut -f1)

# Nettoyer les anciens backups
find /backup/docker -maxdepth 1 -type d -mtime +${RETENTION_DAYS} -exec rm -rf {} + 2>/dev/null

# Notification Telegram
send_telegram "Backup OK $(date +%Y-%m-%d) — Taille: ${TOTAL_SIZE} — Retention: ${RETENTION_DAYS}j"
echo "$(date): Backup terminé" | tee -a "$LOG_FILE" 

# Rendre le script exécutable et l'ajouter au cron
chmod +x /usr/local/bin/docker-backup.sh

# Ajouter au crontab (backup à 3h00 chaque nuit)
(crontab -l 2>/dev/null; echo "0 3 * * * /usr/local/bin/docker-backup.sh") | crontab -

# Tester le script manuellement
/usr/local/bin/docker-backup.sh

Script d'alerte Telegram — Monitoring depuis bash

Une fonction bash réutilisable pour envoyer des alertes depuis n'importe quel script :

#!/bin/bash
# /usr/local/bin/notify.sh — Envoi d'alertes Telegram

TELEGRAM_TOKEN="${TELEGRAM_BOT_TOKEN:-VOTRE_TOKEN_ICI}"
TELEGRAM_CHAT="${TELEGRAM_CHAT_ID:-VOTRE_CHAT_ICI}"

notify() {
    local level="$1"   # INFO, WARNING, ERROR
    local message="$2"
    local hostname=$(hostname)
    local timestamp=$(date '+%Y-%m-%d %H:%M:%S')
    
    local icon="ℹ️"
    [[ "$level" == "WARNING" ]] && icon="⚠️"
    [[ "$level" == "ERROR" ]] && icon="🔴"
    [[ "$level" == "OK" ]] && icon="✅"
    
    local text="${icon} <b>[${hostname}]</b> ${level}
${timestamp}
${message}"
    
    curl -s -X POST "https://api.telegram.org/bot${TELEGRAM_TOKEN}/sendMessage"         -d "chat_id=${TELEGRAM_CHAT}"         -d "text=${text}"         -d "parse_mode=HTML" > /dev/null 2>&1
}

# Utilisation depuis d'autres scripts :
# source /usr/local/bin/notify.sh
# notify "OK" "Backup terminé avec succès"
# notify "ERROR" "Service ghost-blog inaccessible"
# notify "WARNING" "Disque à 85% de capacité"

# Export de la fonction pour les scripts enfants
export -f notify

Script de mise à jour Docker automatique

#!/bin/bash
# /usr/local/bin/docker-update.sh
# Mise à jour hebdomadaire des conteneurs Docker

source /usr/local/bin/notify.sh

COMPOSE_DIRS=(
    "$HOME/docker/zoraxy"
    "$HOME/docker/vaultwarden"
    "$HOME/docker/uptime-kuma"
    "/mnt/docker-data/ghost-blog"
)

UPDATED=0
ERRORS=0

for dir in "${COMPOSE_DIRS[@]}"; do
    if [[ -f "$dir/docker-compose.yml" ]]; then
        echo "Mise à jour : $dir"
        cd "$dir"
        
        # Pull nouvelles images
        if docker compose pull 2>&1 | grep -q "Pull complete\|Downloaded newer image"; then
            # Redéployer si nouvelles images
            docker compose up -d
            UPDATED=$((UPDATED+1))
            echo "Mis à jour : $(basename $dir)"
        fi
    fi
done

# Nettoyer les images obsolètes
docker image prune -f

notify "OK" "Docker update: ${UPDATED} service(s) mis a jour, ${ERRORS} erreur(s)"
echo "Terminé" 

Rotation des logs avec logrotate

Les logs Docker et système peuvent rapidement occuper des dizaines de Go. Logrotate automatise leur rotation et compression :

# Configurer logrotate pour les logs Docker
sudo nano /etc/logrotate.d/docker-logs

# Contenu du fichier :
/var/lib/docker/containers/*/*.log {
    daily
    rotate 7
    compress
    missingok
    notifempty
    delaycompress
    copytruncate
}

# Configurer les logs Docker pour limiter la taille dès le départ
# Dans /etc/docker/daemon.json :
{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

# Appliquer la configuration Docker
sudo systemctl restart docker

# Tester logrotate manuellement
sudo logrotate -f /etc/logrotate.d/docker-logs

Systemd Timers — Alternative moderne aux crons

Les systemd timers sont l'alternative moderne aux crons. Ils offrent une meilleure gestion des logs et la possibilité de rattraper les tâches manquées après un redémarrage :

# Créer le service systemd (ce qui est exécuté)
sudo nano /etc/systemd/system/docker-backup.service
# Contenu :
# [Unit]
# Description=Docker Backup quotidien
# After=network.target
#
# [Service]
# Type=oneshot
# User=ubuntu
# ExecStart=/usr/local/bin/docker-backup.sh

# Créer le timer (quand c'est exécuté)
sudo nano /etc/systemd/system/docker-backup.timer
# Contenu :
# [Unit]
# Description=Timer backup Docker quotidien
#
# [Timer]
# OnCalendar=*-*-* 03:00:00
# Persistent=true
#
# [Install]
# WantedBy=timers.target

# Activer et démarrer le timer
sudo systemctl daemon-reload
sudo systemctl enable docker-backup.timer
sudo systemctl start docker-backup.timer

# Vérifier les timers actifs
systemctl list-timers

Script de surveillance disque

#!/bin/bash
# /usr/local/bin/check-disk.sh
# Alerte si le disque dépasse un seuil

source /usr/local/bin/notify.sh
THRESHOLD=85  # Alerte à 85%

while IFS= read -r line; do
    usage=$(echo "$line" | awk '{print $5}' | tr -d '%')
    mount=$(echo "$line" | awk '{print $6}')
    
    if (( usage >= THRESHOLD )); then
        notify "WARNING" "Disque ${mount}: ${usage}% utilisé — Action requise !"
    fi
done < <(df -h | grep -E '^/dev' | grep -v tmpfs)

# Ajouter tous les scripts au crontab :
crontab -e

# Backup quotidien à 3h00
0 3 * * * /usr/local/bin/docker-backup.sh >> /var/log/docker-backup.log 2>&1

# Mise à jour Docker chaque dimanche à 4h00
0 4 * * 0 /usr/local/bin/docker-update.sh >> /var/log/docker-update.log 2>&1

# Vérification disque toutes les heures
0 * * * * /usr/local/bin/check-disk.sh

# Nettoyer les logs anciens chaque lundi
0 5 * * 1 find /var/log -name "*.log.gz" -mtime +30 -delete

Conclusion et prochaines étapes

Votre infrastructure est maintenant automatisée : backups nocturnes, alertes proactives, mises à jour planifiées. Dans le dernier article de la série, nous couvrons la haute disponibilité et les stratégies de reprise après sinistre — le niveau ultime pour une infrastructure self-hosted robuste.