Échec de la mise à niveau : version de Docker non prise en charge

Ubuntu 16
Clicé sur la mise à jour Web comme nous l’avons fait plusieurs fois. Échoué, maintenant l’application ne peut pas reconstruire une version de Docker non supportée.

Des idées ? Je pourrais essayer de mettre à jour l’OS, etc., mais ce serait beaucoup de temps que je n’avais pas aujourd’hui.

Y a-t-il un moyen de revenir en arrière ?

J’ai essayé de définir la version sur l’ancien hash, mais je reçois immédiatement la message de version de Docker non supportée lorsque j’essaie de reconstruire.

Vous ne pouvez pas effectuer de mise à niveau.

Je déplacerais vers une nouvelle machine virtuelle (VM) et restaurerais la base de données là-bas. C’est plus facile, avec peu de temps d’arrêt, et si quelque chose ne va pas, vous continuez simplement à utiliser le serveur fonctionnel.

Oh. Désolé. Je n’ai pas lu assez attentivement.

Non. Vous ne pouvez pas revenir en arrière.

Vous pourriez être en mesure de mettre à niveau docker si vous utilisez l’installation de docker.

J’ai effectué la mise à niveau du système d’exploitation, etc., et cela s’est déroulé après la mise à niveau de PostgreSQL 15, mais maintenant lorsque je reconstruis l’application, je reçois

2025-05-18 14:58:28.208 UTC [1455] discourse@discourse ERROR:  la colonne "require_message" n'existe pas à la position 72
2025-05-18 14:58:28.208 UTC [1455] discourse@discourse STATEMENT:  SELECT id, name, name_key, description, notify_type, auto_action_type, require_message, applies_to, position, enabled, score_type FROM "flags" ORDER BY "flags"."position" ASC
** ÉCHEC DU PLUG-IN **

Vous ne pouvez pas démarrer Discourse à cause de cette erreur lors de l'initialisation du plug-in :

PG::UndefinedColumn: ERROR:  la colonne "require_message" n'existe pas
LINE 1: ..._key, description, notify_type, auto_action_type, require_me...
                                                             ^

Après avoir lancé la reconstruction (après la mise à niveau de PostgreSQL)

Mise à niveau en cours
------------------
Analyse de toutes les lignes dans le nouveau cluster                       ok
Gel de toutes les lignes dans le nouveau cluster                        ok
Suppression des fichiers du nouveau pg_xact                             ok
Copie de l'ancien pg_xact vers le nouveau serveur                           ok
Configuration de l'XID le plus ancien pour le nouveau cluster                          ok
Configuration du prochain ID de transaction et de l'époque pour le nouveau cluster       ok
Suppression des fichiers du nouveau pg_multixact/offsets                ok
Copie de l'ancien pg_multixact/offsets vers le nouveau serveur              ok
Suppression des fichiers du nouveau pg_multixact/members                ok
Copie de l'ancien pg_multixact/members vers le nouveau serveur              ok
Configuration du prochain ID multixact et de l'offset pour le nouveau cluster        ok
Réinitialisation des archives WAL                                      ok
Configuration des counters frozenxid et minmxid dans le nouveau cluster       ok
Restauration des objets globaux dans le nouveau cluster                 ok
Restauration des schémas de la base de données dans le nouveau cluster               ok
Copie des fichiers de relation utilisateur                                 ok
Configuration du prochain OID pour le nouveau cluster                            ok
Synchronisation des données sur le disque                                 ok
Création du script pour supprimer l'ancien cluster                       ok
Vérification des mises à jour des extensions                              notice

Votre installation contient des extensions qui devraient être mises à jour
avec la commande ALTER EXTENSION. Le fichier
    update_extensions.sql
lorsqu'il est exécuté par psql avec le superutilisateur de la base de données permettra de mettre à jour
ces extensions.


Mise à niveau terminée
----------------
Les statistiques de l'optimiseur ne sont pas transférées par pg_upgrade.
Une fois que vous démarrez le nouveau serveur, envisagez d'exécuter :
    /usr/lib/postgresql/15/bin/vacuumdb --all --analyze-in-stages

L'exécution de ce script supprimera les fichiers de données de l'ancien cluster :
    ./delete_old_cluster.sh
-------------------------------------------------------------------------------------
MISE À NIVEAU DE POSTGRES TERMINÉE

L'ancienne base de données 13 est stockée à /shared/postgres_data_old

Pour terminer la mise à niveau, reconstruisez à nouveau en utilisant :

./launcher rebuild app

Que puis-je faire ? Je ne suis pas sûr de comment il manque une colonne.

Oui. Il y a des sujets sur des problèmes similaires. Une migration a été annulée, je pense, donc vous êtes laissé dans un état de limbo.

Peut-être ajouter la colonne à la main.

Je ne suis pas sûr de comment faire cela, plus précisément à quelle table, etc. Y a-t-il des informations à ce sujet que je peux trouver ? J’ai trouvé ce post que vous mentionnez, mais il n’y avait pas de détails spécifiques.

Merci beaucoup !

Je ne peux même pas monter la base de données suffisamment pour ajouter la colonne. Je vais essayer de désactiver tous les plugins pour voir si je peux au moins faire démarrer le conteneur.

Voici comment nous avons résolu le problème (ce n’est pas pour les âmes sensibles)

  1. Mettre à niveau Ubuntu vers une version qui prend en charge Docker 20+
    Nous étions sous Ubuntu 16, j’ai dû passer à au moins Ubuntu 20, nous avons donc effectué cette mise à niveau deux fois
RELEASE_UPGRADER_ALLOW_THIRD_PARTY=1 do-release-upgrade
  1. Une fois que nous avons atteint Ubuntu 20, nous avons dû mettre à jour Docker, ce qu’Ubuntu a refusé de faire par lui-même.
sudo apt-get update
sudo apt-get install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

# Ajouter le dépôt aux sources Apt :
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release & echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt-get update
  1. Cela nous a permis d’atteindre Docker 28
  2. Ensuite, exécutez
./launcher rebuild app
  1. Cela mettra à niveau votre PostgreSQL de 13 à 15, voir :
    PostgreSQL 15 update
  2. Une fois la base de données mise à niveau avec succès, exécutez
./launcher rebuild app
  1. Cela a généré une erreur concernant une colonne manquante
2025-05-18 14:58:28.208 UTC [1455] discourse@discourse ERROR:  column "require_message" does not exist at character 72
2025-05-18 14:58:28.208 UTC [1455] discourse@discourse STATEMENT:  SELECT id, name, name_key, description, notify_type, auto_action_type, require_message, applies_to, position, enabled, score_type FROM "flags" ORDER BY "flags"."position" ASC
** PLUGIN FAILURE **

Vous ne pouvez pas démarrer Discourse en raison de cette erreur lors de l'initialisation du plugin :

PG::UndefinedColumn: ERROR:  column "require_message" does not exist
LINE 1: ..._key, description, notify_type, auto_action_type, require_me...
                                                             ^
  1. À ce stade, il n’y a aucun moyen de démarrer le conteneur, j’ai donc modifié app.yml pour désactiver tous les plugins, puis j’ai relancé la reconstruction.
  2. L’application a finalement été reconstruite, puis j’ai pu accéder à la console Rails pour ajouter manuellement la colonne ci-dessus.
./launcher enter app
rails db
ActiveRecord::Base.connection.execute("ALTER TABLE flags ADD COLUMN require_message BOOLEAN DEFAULT FALSE;")
exit
exit
  1. Une fois la colonne présente, je suis retourné dans app.yml, j’ai réactivé tous les plugins et j’ai relancé la reconstruction.
  2. La reconstruction a réussi… et nous sommes en ligne !

Merci @pfaffman pour votre réponse rapide, même un week-end. Nous allons créer un nouveau droplet mis à jour et migrer. Il était censé s’agir d’une mise à niveau rapide sur place depuis l’interface web. Mais je suppose que le script ne teste pas la compatibilité de Docker. Lorsqu’il a mis à jour Docker pour Discourse, il a ensuite généré une erreur de Docker incompatible.

C’était entièrement de notre faute de rester sur une version aussi ancienne d’Ubuntu 16. L’une des bonnes et des mauvaises choses d’un système stable est qu’il a tendance à perdurer.

1 « J'aime »

Contentieux que vous ayez réussi ! C’est assez impressionnant !

Vous n’avez pas droit à des mises à niveau rapides lorsque votre système d’exploitation a dépassé sa durée de vie de 4 ans. :wink:

1 « J'aime »

Oui, Leçon apprise, merci encore !

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.