Photo by Dominik Scythe on unsplash

Automatisation des mises à jour Linux

J'ai décidé d'écrire un article sur l'automatisation des mises à jour Linux que j'ai mise en place depuis un moment sur mes serveurs. Les exemples pris tout au long de cet article sont issus de mon infrastructure personnelle. Il n'est pas question ici de donner une vision exhaustive du sujet mais ma vision, ce que j'ai pu mettre en place avec des choix qui sont les miens et que je ne justifierai pas ici.

Avant de rentrer dans le vif du sujet, voici un rapide état de mon infrastructure, aussi communément appelée homelab. Je dispose de machines physiques sur lesquelles est installé ProxmoxVE, un hyperviseur qemu/kvm basé sur Debian. Je dispose ensuite de containers et de machines virtuelles. Ici, nous laissons de côté les premiers pour nous concentrer sur les secondes. En fonction des différents besoins applicatifs, les distributions nécessaires peuvent changer. Je me suis limité à deux sur mon parc virtuel : Ubuntu et CentOS.

Je dispose, à l'heure où je rédige ces lignes, de trois serveurs physiques et une vingtaine de machines virtuelles.

Il serait fastidieux et improductif de tout mettre à jour sans automatiser. De plus, cela devient vite complexe de le faire, manuellement, à intervalle suffisamment régulier dans le but de garantir une sécurité minimale nécessaire pour mes machines.

Pour chacune des distributions Linux majeures données ci-dessus, une solution différente est utilisée :

Mon infrastructure est puppetisée. La configuration de mes machines s'y trouve donc logiquement. Voici un extrait de déclaration de mes noeuds (machines, virtuelles ou physiques) :

node 'lab-v-jump02' {
    include ubuntu_base, unattended_upgrades
}

node 'lab-v-sup02' {
    include centreon_plugins, proxmox_guest, yum_cron
}

node 'pve01', 'pve04', 'pve03' {
    include unattended_upgrades::physical
}

Sur mes machines Ubuntu j'utilise le module unattented_upgrades, sur les machines CentOS le module yum_cron et enfin pour les Debian le sous-module unattended_upgrades::physical. Entre Ubuntu et Debian, la syntaxe de configuration de l'outil diffère légèrement, d'où la distinction en deux modules Puppet distincts. Je ne m'attarde pas plus longuement sur la configuration et la mise en place de l'outil de mise à jour, la documentation qui se trouve sur Internet est assez explicite.

A titre d'exemple, voici le fichier de template qui est poussé sur mes machines Debian :

//
// /!\ Warning ! This file is managed by Puppet /!\
//

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::AutocleanInterval "7";
APT::Periodic::Unattended-Upgrade "1";

// Automatically upgrade packages from these (origin:archive) pairs
Unattended-Upgrade::Origins-Pattern {
    "o=Debian,n=stretch";
    "o=Proxmox,n=stretch";
};

// List of packages to not update (regexp are supported)
Unattended-Upgrade::Package-Blacklist {
//      "vim";
};

// Send email to this address for problems or packages upgrades
// If empty or unset then no email is sent, make sure that you
// have a working mail setup on your system. A package that provides
// 'mailx' must be installed. E.g. "user@example.com"
Unattended-Upgrade::Mail "root";

// Set this value to "true" to get emails only on errors. Default
// is to always send a mail if Unattended-Upgrade::Mail is set
Unattended-Upgrade::MailOnlyOnError "true";

// Do automatic removal of new unused dependencies after the upgrade
// (equivalent to apt-get autoremove)
Unattended-Upgrade::Remove-Unused-Dependencies "true";

// Automatically reboot *WITHOUT CONFIRMATION*
//  if the file /var/run/reboot-required is found after the upgrade
Unattended-Upgrade::Automatic-Reboot "true";

// If automatic reboot is enabled and needed, reboot at the specific
// time instead of immediately
//  Default: "now"
<% Puppet::Parser::Functions.function('fqdn_rand') -%>
<% value = scope.function_fqdn_rand(['59']).to_i -%>
Unattended-Upgrade::Automatic-Reboot-Time "05:<%= value.to_s %>";

Dans l'ordre de l'extrait de configuration ci-dessus :

  1. A quelle fréquence a lieu la mise à jour des listes de paquets, leur téléchargement, leur nettoyage et leur installation (1 = tous les jours, 7 = tous les 7 jours)
  2. La liste des dépôts de paquets à mettre à jour (j'ai ici un dépôt Proxmox, par exemple)
  3. Blacklist des paquets à ne pas mettre à jour automatiquement (ici, je n'en ai pas)
  4. Activation de l'emailing, adresse du destinataire et sous quelle condition l'envoi est-il effectué. Dans mon exemple, je ne reçois un e-mail qu'en cas d'erreur.
  5. Activation du nettoyage automatisé de la machine (suppression des anciens paquets kernel entre autre)
  6. Redémarrage automatique après la mise à jour si nécessaire, avec une petite magouille tout en bas pour que ça redémarre à un moment aléatoire entre 05h00 et 05h59 du matin

Voici comment mes serveurs se mettent à jour automatiquement. Le choix d'un temps aléatoire est mis en place afin de m'assurer que toutes les machines virtuelles ne redémarrent pas au même moment sur l'hyperviseur ProxmoxVE. De plus, cela permet de redémarrer chacune des machines physiques à un moment différent également. Cela limite les interruptions de service, les machines formant un cluster. Enfin, comme indiqué ci-dessus, je ne reçois des e-mails qu'en cas d'erreur, ce qui n'arrive pratiquement jamais !

{{ message }}

{{ 'Comments are closed.' | trans }}