seaworld008/centos7-almalinux-upgrade

CentOS 7 → AlmaLinux 10 Mise à niveau sur place

Ce processus est le fruit d'une migration réelle en production (serveur bastion Huawei Cloud, CentOS 7.7 → AlmaLinux 10.2, avec préservation complète de nginx/Docker/xxl-job/MySQL/NetBird/kubectl). L'objectif est que chaque machine puisse être mise à niveau de manière sécurisée, réversible et vérifiable, tout en pouvant être déployée par lots.

Idée directrice : d'abord évaluer → snapshot de sauvegarde → petits pas (pré-vérification → mise à niveau → redémarrage → comparaison des lignes de base → finalisation) → modernisation. La plupart des problèmes proviennent d'éléments « non officiels » (programmes compilés localement, paquets pip, dépôts tiers, openssh auto-compilé, stratégies de redémarrage des conteneurs, chemins d'accès VPN), c'est pourquoi la phase d'audit est la plus importante.

Quand ne pas faire de mise à niveau sur place

Consultez d'abord les BLOCKER du survey.sh. Dans les cas suivants, il est recommandé de créer une nouvelle machine AlmaLinux 10 et de migrer les services, plutôt que de mettre à niveau sur place :

• C'est un nœud Kubernetes (kubelet en cours d'exécution) – à traiter comme un changement au niveau du cluster, en suivant references/kubernetes.md (kubeadm 1.21 + dockershim + flannel/ipvs fonctionne sur EL10, un cluster 3m3w prend environ 6 heures) ; on peut aussi drainer puis remplacer le nœud
• La base de données installée via rpm sur l'hôte doit traverser plusieurs versions majeures (MariaDB 5.5→10.11, PostgreSQL 9.2→16) et les données sont volumineuses
• Architecture non x86_64, btrfs, disque système extrêmement petit et impossible à étendre
• Le processeur ne supporte pas x86-64-v3 (la version standard d'AlmaLinux 10 ne fonctionnera pas ; on peut monter jusqu'à 9, ou utiliser la variante x86_64_v2 d'AlmaLinux 10)
• Les services sont déjà conteneurisés, la configuration est dans compose/k8s – créer une nouvelle machine et redéployer est souvent plus rapide qu'une mise à niveau sur place

En cas de doute, transmettez les critères de décision à l'utilisateur et laissez-le choisir.

Boîte à outils

Sous le répertoire scripts/ du skill (le tout est téléchargé via SSH sur la machine cible dans /root/os-upgrade-kit/) :

Script	Rôle
remote.py	S'exécute localement : récupère les identifiants depuis un fichier d'inventaire (xlsx/csv), exécute des commandes SSH, télécharge/téléverse, attend les redémarrages ; keepalive activé ; n'affiche pas les mots de passe
survey.sh	Audit en lecture seule, affiche les RISK FLAGS classés (BLOCKER/HIGH/MEDIUM/INFO) à la fin
backup.sh	Sauvegarde la configuration + génère la ligne de base baseline.tsv (services/ports/conteneurs/code HTTP de chaque domaine/kubectl)
state.sh / verify.sh	Génère l'état actuel / compare avec la ligne de base, affiche FAIL/WARN
prep-el7.sh	Préparation EL7 : repos (correction des dépôts), update vers 7.9, pipfix, inhibitors
convert-el8.sh	Lorsque le système source est CentOS 8 : prep → run (almalinux-deploy officiel) → post, conversion en AlmaLinux 8
swap-openssh.sh	Remplace openssh auto-compilé par le paquet officiel (avec restauration automatique)
hop.sh	Chaque saut : prep→pre→report/answer→up→reboot→post
nginx-static-build.sh	Recompilation statique de nginx auto-compilé (même version, utilisable pendant la transition)
fleet_summary.py	S'exécute localement : résume les résultats de survey de plusieurs machines → classification A/B/C/D, marquage VPN/EL8, suggestions de canari et de lots (--groups pour que les serveurs actif/backup d'un même service soient dans des lots différents)
finalize.sh	Finalisation EL10 : packaging compose, alignement kubectl avec le cluster, helm, postfix lmdb, dépôt nginx.org, compatibilité cgroup v1, packaging SysV, modules iptables legacy, redis→valkey, services manuels transformés en services systemd
k8s.sh	Nœud K8s : backup (snapshot etcd/configuration/binaires/liste de pods, pin automatique de version), stop, nfs-off/nfs-on, nm, fix, check, pods (comparaison avec avant la mise à niveau), jvm-maxram (OOM sous cgroup v2 pour les anciens JDK)

Lors de l'appel sous Windows Git Bash, remote.py gère automatiquement le problème de MSYS qui transforme /root/... en C:/Program Files/Git/root/....

Utilisation courante :

export FLEET_INVENTORY="/path/to/servers.xlsx"   # Colonnes : name, host, port, username, password (contient le mot de passe, ne pas committer)
S=<répertoire_du_skill>/scripts
python $S/remote.py HOST put $S /root/os-upgrade-kit
python $S/remote.py HOST run "bash /root/os-upgrade-kit/survey.sh > /root/os-upgrade-kit/survey.txt; sed -n '/RISK FLAGS/,\$p' /root/os-upgrade-kit/survey.txt"
python $S/remote.py HOST wait-ssh --timeout 3600

Processus

Phase 0 : À confirmer avec l'utilisateur avant de commencer (indispensable)

Ce sont des décisions de l'utilisateur, ne les prenez pas à sa place :

1. Snapshot cloud/sauvegarde complète de la machine déjà effectuée (disque système + disques de données). C'est le seul moyen de restauration fiable, Claude ne peut pas le faire à l'intérieur de la machine.
2. Fenêtre d'arrêt : chaque saut implique un redémarrage, l'ensemble prend environ 2 à 4 heures (la plupart du temps pour télécharger les paquets, selon la vitesse du miroir) ; le service sera interrompu plusieurs fois.
3. Console hors bande disponible : Alibaba Cloud VNC / Huawei Cloud VNC / AWS EC2 Serial Console (conditions préalables dans references/cloud-providers.md). En cas de blocage dans initramfs, c'est le seul moyen de récupérer.
4. Chemin d'accès : comment êtes-vous (la machine locale) connecté à cette machine ? Si c'est via un VPN/tunnel, exécutez sur cette machine (survey émettra un BLOCKER). Redémarrage et opérations sur les conteneurs doivent être particulièrement prudents – notre incident réel : docker stop de tous les conteneurs a empêché le redémarrage automatique du conteneur de routage NetBird, rendant tout le VPC inaccessible.
5. Qu'est-ce qui est devenu inutile : après l'audit, donnez la liste à l'utilisateur pour qu'il confirme les composants/sites à désactiver (par exemple PHP, vieux sites). Avant de supprimer, expliquez l'impact ("supprimer PHP entraînera une erreur 404 pour le site xxx"), et laissez l'utilisateur trancher.

Phase 1 : Audit + Sauvegarde + Ligne de base

1. Téléchargez la boîte à outils, exécutez survey.sh, examinez chaque RISK FLAG, et avec l'aide de references/app-compat.md, déterminez un plan de traitement pour chacun.
2. Exécutez backup.sh (par défaut sur un disque non système comme /data), notez BACKUP_DIR. baseline.tsv servira de référence pour chaque saut – si un élément (ex. 502) était déjà anormal avant la mise à niveau, signalez-le dans le rapport comme « existait avant la mise à niveau » pour éviter les confusions ultérieures.
3. Communiquez à l'utilisateur les conclusions de l'audit, les plans de traitement et les décisions nécessaires (voir phase 0).

Phase 2 : Préparation EL7

bash prep-el7.sh repos <MIROIR>      # Recommandé pour la Chine : https://mirrors.aliyun.com ; réseau interne Alibaba Cloud : http://mirrors.cloud.aliyuncs.com ; upstream pour l'étranger
bash prep-el7.sh update              # Vers 7.9 ; les paquets en Failed sont généralement des conflits pip
bash prep-el7.sh pipfix
bash prep-el7.sh inhibitors
bash swap-openssh.sh                 # Uniquement si survey signale openssh non officiel ; vérifier avec une **nouvelle connexion** après

Pour les programmes dépendant des bibliothèques EL7 (comme nginx auto-compilé) : utilisez nginx-static-build.sh pour une recompilation statique (ou acceptez l'indisponibilité pendant la transition, puis installez le paquet officiel à la fin). Bases de données sur l'hôte : faites une sauvegarde logique d'abord.

Si le système source est CentOS Linux 8 / CentOS Stream 8 (survey émettra un BLOCKER) : ELevate ne le supporte pas comme source, sautez la préparation EL7 ci-dessus, commencez par la conversion vers la même version, puis passez à la phase 3 (saut 8→9) :

bash convert-el8.sh prep <MIROIR>                    # Correction des dépôts (vault, EPEL8), conflits pip, kernel-devel superflus
bash convert-el8.sh update                           # Montée à 8.5 (almalinux-deploy nécessite ≥8.4)
bash convert-el8.sh run  <MIROIR> <almalinux-deploy.sh>   # almalinux-deploy officiel : -d pour autoriser la rétrogradation, -l pour utiliser le miroir
bash hop.sh reboot && python remote.py HOST wait-ssh   # Redémarrage dans le noyau AlmaLinux
bash convert-el8.sh post                             # Supprimer les noyaux non-AlmaLinux, dnf upgrade

Les serveurs en Chine ont souvent un accès limité au raw de GitHub, téléchargez d'abord almalinux-deploy.sh en local puis téléversez-le.

Phase 3 : Chaque saut (7→8, 8→9, 9→10 à faire chacun)

bash hop.sh prep <MIROIR>     # Installe ELevate pour ce saut, dépôts cibles et miroir pour les dépôts fabricant docker-ce/epel, désactive les sections test/nightly, nettoyage pip, vérification de l'accessibilité
bash hop.sh pre               # Preupgrade en arrière-plan et attend → rapport automatique
bash hop.sh answer            # Répond automatiquement aux problèmes de sécurité connus ; pour les autres blocages, traiter selon les commandes de réparation du rapport, puis relancer pre jusqu'à 0 blocage
bash hop.sh report            # Examinez surtout « paquets qui seront supprimés » et « destination des paquets critiques » – si cela impacte des services, trouvez d'abord une solution
bash hop.sh up                # Téléchargement en arrière-plan + génération de l'environnement de mise à niveau
bash hop.sh reboot [noms de conteneurs supplémentaires à arrêter]   # Arrête uniquement les conteneurs avec état restart=always ; ne touche pas aux conteneurs VPN ni ceux avec unless-stopped ; si le métier dit « ne touche pas », utilisez --no-stop
python remote.py HOST wait-ssh --timeout 3600   # Attente locale ; timeout → console, voir references/recovery.md
bash hop.sh post <MIROIR>     # Vérifie les marqueurs d'échec, nettoie leapp/anciens noyaux/dépôts résiduels, dnf upgrade
bash verify.sh <BACKUP_DIR>   # FAIL doit être traité ; WARN à évaluer si attendu

Réparez les problèmes métier après chaque saut avant de passer au suivant, ne les accumulez pas pour la fin. Les blocages spécifiques à chaque saut et leur traitement sont détaillés dans references/pitfalls.md sous « Par saut ».

Les tâches longues doivent être exécutées en arrière-plan : les scripts utilisent systemd-run pour lancer leapp/dnf, une déconnexion SSH ne les affecte pas ; vous n'avez qu'à interroger. Pour vos propres commandes, suivez la même règle : ne laissez pas une session SSH ouverte pendant des dizaines de minutes.

Phase 4 : Finalisation EL10 et modernisation

Utilisez les sous-commandes de finalize.sh selon les besoins de l'utilisateur, et référez-vous à references/app-compat.md :

• nginx auto-compilé → paquet officiel stable nginx.org (ssl on; devient listen 443 ssl;, TLS 1.2/1.3, certificats dans /etc/nginx/ssl, démarrage automatique via systemd)
• docker-compose v1 → wrapper vers compose v2 ; ajout d'un shim pour les anciennes applications cgroup v1
• kubectl → dépôt pkgs.k8s.io, même version mineure que le cluster ; helm → dernière v3
• postfix hash → lmdb ; les services lancés via rc.local transformés en unités systemd
• dnf -y upgrade mise à jour complète, vérifier que dnf check-update ne retourne rien
• Effectuez un dernier redémarrage pour tester le démarrage automatique, exécutez verify.sh, tous les services doivent démarrer seuls pour considérer la tâche terminée

Phase 5 : Rapport de livraison

Utilisez la structure de assets/report-template.md pour écrire à l'utilisateur : comparaison des versions, tableau de comparaison des services (avant/après), modifications de compatibilité effectuées, éléments restants et actions nécessaires de la part de l'utilisateur (expiration des certificats, plugins cloud non réparés, etc.), emplacement des sauvegardes. En cas de déploiement par lots, mettez à jour le tableau de suivi de la flotte (assets/fleet-tracker.csv).

Phase 6 : Retour d'expérience (alimenter le dépôt du skill)

Ce skill évolue grâce à des exécutions réelles, le projet est ici : https://github.com/seaworld008/centos7-lighthouse . Après chaque exécution réelle (succès, échec ou rollback) :

• Rédigez un rapport de terrain anonymisé (sans IP réelles, noms de domaine, noms d'hôte ou identifiants) en suivant le field-reports/TEMPLATE.md du dépôt.
• Si un nouveau problème survient, ajoutez-le dans references/pitfalls.md ; si détectable automatiquement, ajoutez la détection dans survey.sh ; si traitable automatiquement, améliorez les scripts.
• Si le répertoire de travail actuel est ce dépôt, suivez son AGENTS.md ; sinon, transmettez le rapport à l'utilisateur et suggérez de soumettre une issue ou une PR.

Principes clés (chacun correspond à un incident réel)

• Ne jamais docker stop $(docker ps -q) avant un redémarrage : les conteneurs avec unless-stopped ne redémarreront pas s'ils ont été arrêtés manuellement ; un conteneur VPN arrêté vous rendra injoignable. Utilisez hop.sh reboot.
• Tout ce qui est installé via pip dans les site-packages système doit être déplacé avant chaque saut : en cas de conflit de fichiers avec les rpm, la mise à niveau échouera en cours de route dans initramfs, laissant le système en mode d'urgence et dans un état « semi-mis à jour ».
• Tout ce qui n'est pas officiel ou inconnu doit être traité en premier : openssh auto-compilé, nginx auto-compilé, dépôts tiers, mysql-community-libs remplaçant mariadb-libs… leapp ne s'en occupe pas, et après la mise à niveau, ils seront cassés.
• En Chine, utilisez des miroirs locaux et désactivez les sections test/nightly des dépôts fabricant : mirrorlist/metalink sont souvent lents ou expirés ; le dépôt docker nightly expiré fera échouer leapp directement. Le miroir Huawei Cloud peut limiter le débit (429), Alibaba Cloud est le plus fiable.
• Les motifs de pkill -f / pgrep -f ne doivent pas apparaître dans votre propre ligne de commande, sinon vous tuerez votre propre session SSH (nous l'avons subi deux fois). Utilisez des PID, des fichiers de script ou une expression comme [l]eapp.
• Comparez les lignes de base à chaque saut : un problème métier découvert lors d'un saut doit être réparé immédiatement, par exemple cgroup v2 faisant planter Yearning, ou docker-compose v1 devenant inutilisable.
• Les décisions qui modifient le comportement des services appartiennent à l'utilisateur : suppression de composants, désactivation de sites, désactivation de TLS 1.0/1.1, changement de version majeure de base de données.

Documentation de référence (à consulter selon les besoins)

• references/pitfalls.md — Tous les pièges : symptôme → cause → traitement, classés par saut + généraux. En cas d'erreur, commencez par chercher ici.
• references/app-compat.md — Traitement de compatibilité des applications lors des sauts EL7→EL10 : nginx, Docker/compose/cgroup v2, Java, Python, PHP, bases de données, postfix, réseau, SSH, kubectl/helm, SysV, stratégie de chiffrement TLS.
• references/cloud-providers.md — Différences Alibaba Cloud/Huawei Cloud/AWS : snapshots, conditions préalables pour les consoles hors bande, miroirs, agents cloud, cloud-init.
• references/recovery.md — Que faire en cas de blocage en mode d'urgence initramfs, de perte de connexion au démarrage, d'état semi-mis à jour (avec astuces VNC).
• references/fleet.md — Déploiement par lots de dizaines ou centaines de machines : inventaire, audit parallèle, classification, canari, lots, suivi.
• references/kubernetes.md — Mise à niveau sur place d'un nœud K8s : informations à connaître avant de commencer (chemin d'accès/point d'entrée du contrôleur/etcd/stockage), conclusions de compatibilité, ordre recommandé, pièges rencontrés, liste de vérification pour la remise en service.