Mises à jour, sauvegardes et restauration

Les mises à jour et les sauvegardes protègent deux résultats différents : les mises à jour font avancer la plateforme, tandis que les sauvegardes permettent de récupérer l’identité, l’état souhaité, les identifiants de service et les données applicatives après une panne. Le responsable de la plateforme est responsable de la séquence de mise à jour ; le responsable de la sécurité, des clés de reprise ; les responsables des bases de données et des applications, des sauvegardes natives des moteurs et de leur validation.

Définissez l’objectif de point de reprise (la quantité de données qui peut être perdue) et l’objectif de temps de reprise (la durée que peut prendre la restauration) avant de choisir la fréquence des sauvegardes ou les fenêtres de mise à jour. Le succès, c’est une restauration testée, et non l’existence de fichiers d’archive.

Avant une mise à jour d’Opfield, lisez les notes de version, vérifiez les planchers de compatibilité, sauvegardez PostgreSQL et les fichiers persistants, préservez les clés de chiffrement et la clé maîtresse, et consignez les références des images en cours d’exécution. Mettez à jour via l’installateur pris en charge ou la configuration Compose générée.

Les mises à jour des démons sont signées et gérées nœud par nœud. Restez dans la fenêtre de compatibilité documentée pour les versions mixtes et vérifiez la reconnexion, l’inventaire, les liaisons, les journaux et les opérations après la mise à jour de chaque rôle.

Sauvegardez :

PostgreSQL ;
les volumes persistants d’artefacts et de configuration d’Opfield ;
les clés maîtresses de chiffrement et de PKI ;
le volume d’identité de Relay ;
les sauvegardes natives des moteurs de bases de données ;
la configuration externe du DNS, du fournisseur d’identité, de l’e-mail, des registres et du SIEM détenue hors d’Opfield.

Un test de restauration doit prouver la connexion, le déchiffrement, la reconnexion des nœuds, l’autorisation de Relay, les Routes, les certificats, les liaisons de bases de données managées et la continuité de l’audit. Une sauvegarde qui n’a jamais été restaurée n’est pas un plan de reprise.

Les données des bases de données ne font pas partie de ce jeu de reprise. À partir de Personal, les sauvegardes de bases de données créent des sauvegardes natives planifiées des bases PostgreSQL, clé-valeur et ClickHouse managées et externes dans une connexion de stockage ; en Community, ou pour les moteurs qui nécessitent une restauration à un instant donné, utilisez les outils natifs du moteur. Voir Bases de données managées et externes en un coup d’œil.

Processus intégrés

Les connexions de stockage et le stockage objet managé ainsi que la sauvegarde et la restauration des bases de données sont disponibles à partir de Personal. L’export de configuration, qui permet de déplacer Opfield vers un autre hôte, est disponible avec tous les plans.

Export de configuration

Settings > General > Configuration export (scope admin:system) empaquette l’installation dans un fichier unique chiffré avec une phrase secrète d’au moins 12 caractères : la base de données d’Opfield, PKI_MASTER_KEY, les clés de signature des CA et des politiques de relais, les fichiers d’Opfield, le cœur commercial d’une installation payante, l’identifiant de l’installation et, en option, les réglages de .env. Les images du registre interne et les journaux du ClickHouse géré par Opfield sont facultatifs. Opfield continue de fonctionner pendant l’export et ne stocke pas la phrase secrète.

Un export ne se restaure que dans une nouvelle installation de la même version d’Opfield, soit depuis l’assistant de configuration (Restore from an export), soit avec l’option --restore <file> de l’installateur ; mettez ensuite à jour comme d’habitude. La restauration demande l’URL publique et l’adresse gRPC du nouvel hôte, et la nouvelle installation conserve ses propres mots de passe de base de données et de registre. Les sessions de connexion ne sont pas transférées. Les données des bases de données situées sur les nœuds Storage ne font pas partie de l’export : protégez-les avec les sauvegardes de bases de données. Pour faire passer des nœuds à une nouvelle adresse, utilisez Settings > General > Move nodes to a new address sur l’ancienne installation avant de l’arrêter.

Un export de configuration est distinct de l’export d’archives de conteneurs. Le jeu de reprise manuel ci-dessous reste un moyen de conserver vos propres sauvegardes du plan de contrôle ; les sauvegardes de bases de données protègent les données applicatives, et non l’état propre à Opfield.

Constituer le jeu de reprise

Documentez le responsable, l’emplacement, la conservation, la méthode de chiffrement et l’ordre de restauration de chaque composant de sauvegarde. Conservez les clés maîtresses et les identifiants de reprise hors de l’hôte Opfield et hors du domaine de panne de la sauvegarde de la base de données.

PostgreSQL est le magasin faisant autorité pour les identités, l’état souhaité, les relations, les opérations et les métadonnées d’audit. Les volumes persistants contiennent des artefacts et du matériel d’identité de service qui ne peuvent pas être reconstitués à partir de PostgreSQL seul. Les sauvegardes natives des bases de données managées protègent les données applicatives ; une sauvegarde du plan de contrôle ne les remplace pas.

Jeu de reprise Compose manuel

L’installateur manuel utilise des services nommés app, relay, registry, postgres et redis, ainsi que ces volumes persistants :

Volume	Rôle dans la reprise
`postgres_data`	utilisateurs, ressources, état souhaité, tâches et métadonnées d’audit
`app_data`	artefacts téléversés, configuration générée, TLS et état de l’application
`relay_identity`	identité du relais local, partagée par `app` et `relay`
`relay_state`	état d’exécution du relais local
`registry_data`	blobs et manifestes du registre privé
`registry_auth`	matériel de signature des jetons du registre
`redis_data`	état persisté de Redis ; utile pour une reprise complète coordonnée, mais ne remplace pas PostgreSQL

Ce sont les clés de docker-compose.yml. Une nouvelle installation nomme les volumes opfield_app_data, etc. ; une installation déplacée depuis /opt/gateway (voir Mettre à jour vers 2.12.1) conserve les noms qu’elle avait, comme gateway_gateway_data, listés sous name: dans docker-compose.yml. Les commandes ci-dessous utilisent les chemins dans les conteneurs d’une installation mise en place avec 2.12.3 ou ultérieur (/var/lib/opfield, /var/lib/opfield-relay, /var/lib/opfield-registry-auth) ; une installation mise en place plus tôt monte les mêmes données sous /var/lib/gateway, /var/lib/gateway-relay et /var/lib/gateway-registry-auth ; utilisez alors ces chemins.

Lorsque la journalisation structurée locale est activée, sauvegardez aussi le volume du ClickHouse géré par Opfield.

Préservez aussi .env et le docker-compose.yml exact utilisé par l’installation ; l’installateur comme l’installation manuelle le conservent à côté de .env, par défaut dans /opt/opfield pour l’installateur. Le fichier .env contient des secrets sensibles pour la reprise ; chiffrez sa sauvegarde séparément et ne le joignez jamais à un ticket de support.

L’exemple suivant crée une courte fenêtre de cohérence hors ligne. Exécutez-le depuis le répertoire qui contient le fichier Compose manuel :

mkdir -p opfield-recovery/{app_data,relay_identity,relay_state,registry_data,registry_auth,redis_data}
cp .env docker-compose.yml opfield-recovery/
chmod 700 opfield-recovery
chmod 600 opfield-recovery/.env

docker compose -f docker-compose.yml stop app relay registry
docker compose -f docker-compose.yml exec -T postgres \
  pg_dump -U opfield -d opfield -Fc > opfield-recovery/postgres.dump
docker compose -f docker-compose.yml stop redis
docker compose -f docker-compose.yml cp --archive app:/var/lib/opfield/. opfield-recovery/app_data/
docker compose -f docker-compose.yml cp --archive app:/var/lib/opfield-relay/. opfield-recovery/relay_identity/
docker compose -f docker-compose.yml cp --archive relay:/var/lib/opfield-relay/state/. opfield-recovery/relay_state/
docker compose -f docker-compose.yml cp --archive registry:/var/lib/registry/. opfield-recovery/registry_data/
docker compose -f docker-compose.yml cp --archive app:/var/lib/opfield-registry-auth/. opfield-recovery/registry_auth/
docker compose -f docker-compose.yml cp --archive redis:/data/. opfield-recovery/redis_data/
docker compose -f docker-compose.yml start redis registry app relay

La base de données et son rôle s’appellent opfield ; une installation qui n’a pas encore été déplacée depuis /opt/gateway utilise gateway pour les deux.

Copiez opfield-recovery vers un stockage chiffré hors de l’hôte et vérifiez-y sa somme de contrôle. Cet exemple ne sauvegarde pas les bases de données gérées sur les nœuds Storage ; protégez leurs données avec les sauvegardes de bases de données ou les outils natifs du moteur.

Pour restaurer sur un hôte compatible propre, restaurez d’abord .env et le même fichier Compose, puis créez des conteneurs arrêtés, copiez les données persistantes, démarrez PostgreSQL et importez le dump avant de démarrer le reste du plan de contrôle :

docker compose -f docker-compose.yml create

docker compose -f docker-compose.yml cp --archive opfield-recovery/app_data/. app:/var/lib/opfield
docker compose -f docker-compose.yml cp --archive opfield-recovery/relay_identity/. app:/var/lib/opfield-relay
docker compose -f docker-compose.yml cp --archive opfield-recovery/relay_state/. relay:/var/lib/opfield-relay/state
docker compose -f docker-compose.yml cp --archive opfield-recovery/registry_data/. registry:/var/lib/registry
docker compose -f docker-compose.yml cp --archive opfield-recovery/registry_auth/. app:/var/lib/opfield-registry-auth
docker compose -f docker-compose.yml cp --archive opfield-recovery/redis_data/. redis:/data

docker compose -f docker-compose.yml up -d postgres
docker compose -f docker-compose.yml cp opfield-recovery/postgres.dump postgres:/tmp/opfield.dump
docker compose -f docker-compose.yml exec -T postgres \
  pg_restore -U opfield -d opfield --clean --if-exists /tmp/opfield.dump

docker compose -f docker-compose.yml up -d redis registry app relay

Utilisez d’abord la même version. Vérifiez la connexion, le déchiffrement des secrets, l’identité de Relay et de nouvelles reconnexions de nœuds avant toute tentative de mise à niveau. La propriété des fichiers peut différer d’un hôte à l’autre ; si un service signale des erreurs de permissions, comparez la propriété dans les conteneurs d’origine et restaurés plutôt que d’appliquer des permissions d’écriture étendues.

Procédure de mise à jour d’Opfield

Lisez les notes de version et les versions intermédiaires requises.
Confirmez le canal de mise à jour actif et la version cible et, pour une installation qui détient ou a détenu un plan payant, qu’Opfield peut joindre le service de licences ; voir Prérequis de mise à jour en 2.11. Lors d’une mise à jour depuis 2.10, suivez d’abord Mettre à jour depuis 2.10.
Vérifiez la présence de sauvegardes récentes de PostgreSQL et des volumes persistants.
Consignez les versions et les empreintes d’images actuelles d’Opfield, de Relay et des démons.
Confirmez la santé de PostgreSQL, de Redis, de Relay et du disque.
Ne placez les services visibles par les clients en maintenance que si la mise à jour l’exige.
Appliquez la mise à jour prise en charge sans remplacer les volumes persistants ni les clés maîtresses.
Attendez la disponibilité d’Opfield et la fin de la migration du schéma.
Vérifiez Relay, la connexion, l’amorçage du tableau de bord, les reconnexions des nœuds, les Routes et les liaisons de bases de données.
Ne levez la maintenance qu’après une vérification externe.

Ne considérez pas un conteneur en cours d’exécution comme une mise à jour réussie. L’application doit déchiffrer les secrets existants, lire l’état antérieur, réconcilier les services d’arrière-plan et exposer des chemins clients sains.

Prérequis de mise à jour en 2.11

Chaque mise à jour d’Opfield autorise d’abord la version cible auprès du service de licences. Opfield conserve une liste signée des adresses du service et utilise celle qui répond, normalement license.opfield.dev. LICENSE_SERVICE_URL dans .env, par exemple un proxy sortant, est essayé en premier. Cela s’applique aux mises à jour lancées depuis la Console et à la réexécution de l’installateur. Opfield vérifie la version signée avant de modifier l’hôte :

Installations payantes : une installation qui détient ou a détenu une activation payante — y compris expirée, révoquée, transférée ou désactivée — reçoit le cœur commercial de la version cible, afin que ses ressources payantes existantes continuent de fonctionner après la mise à jour. Opfield vérifie la signature, la version, les tailles et les empreintes du cœur, et n’accepte l’autorisation que sous la forme d’un état de licence signé pour cette requête. Une telle installation a besoin du service de licences pendant la mise à jour : si le service est injoignable, refuse la version ou renvoie un état dont la vérification échoue, la mise à jour s’arrête avant toute modification et l’Opfield actuel continue de fonctionner. Opfield ne remplace jamais silencieusement une installation payante par Community ; autorisez donc l’accès sortant au service de licences pendant les fenêtres de mise à jour.
Installations Community : une installation qui n’a jamais détenu de plan payant se met à jour en tant que Community. Lorsqu’elle n’a ni clé de licence, ni plan payant dans son état de licence, ni cœur commercial sur l’hôte, elle se met aussi à jour lorsque le service de licences est injoignable, car elle ne télécharge rien de privé. Un refus ou un état de licence dont la vérification échoue arrête tout de même la mise à jour.
Opérations en cours : après la récupération des images et avant la modification de l’hôte, Opfield attend la fin du travail d’orchestration en cours et en file d’attente — déploiements blue/green et vidage de leurs slots précédents, opérations Compose, actions Workload Availability, migrations et déploiements de builds. L’attente dure jusqu’à 15 minutes par défaut, ou jusqu’à l’échéance la plus longue annoncée par le travail en cours, et au plus 60 minutes. L’écran de mise à jour liste les opérations attendues. Le nouveau travail d’orchestration lancé pendant l’attente est refusé avec OPFIELD_UPDATING. Un administrateur peut mettre fin à l’attente plus tôt avec Update now ; Opfield reprend ou réconcilie alors les opérations interrompues après le redémarrage.
Espace disque libre : avant de remplacer l’application, la mise à jour prend un instantané de la base de données d’Opfield et a besoin pour cela d’espace libre sur le système de fichiers qui contient le répertoire d’Opfield : la taille de la base plus 10 % plus 256 Mio. Avec moins, la mise à jour s’arrête avant toute modification, et les journaux du conteneur de mise à jour indiquent l’espace nécessaire.

L’image et le cœur commercial précédents sont conservés afin qu’une mise à jour en échec puisse revenir en arrière. Voir Cœur commercial pour la façon dont les fonctionnalités payantes sont livrées.

L’attente des opérations en cours, la vérification de l’espace disque et l’instantané de la base de données ci-dessous relèvent de l’outil de mise à jour de la version en cours d’exécution. Ils s’appliquent aux mises à jour lancées à partir de 2.11, et non à la mise à jour depuis 2.10 ; voir Mettre à jour depuis 2.10.

Retour arrière automatique et instantané de la base de données

Juste avant le démarrage de la nouvelle version, la mise à jour écrit un instantané pg_dump au format custom de la base de données d’Opfield dans .opfield-foundation-backups/pre-update-<time>/opfield-db.dump, dans le répertoire d’Opfield, à côté des .env et docker-compose.yml enregistrés. Si la nouvelle version ne devient pas saine en cinq minutes environ, le conteneur de mise à jour revient en arrière : il restaure .env et docker-compose.yml, arrête tous les services Compose sauf postgres, supprime la base de données d’Opfield et la recrée à partir de l’instantané (les mises à jour lancées depuis une version antérieure à 2.12.1 écrivent .gateway-foundation-backups/pre-update-<time>/gateway-db.dump). La version précédente ne s’exécute donc jamais sur un schéma modifié par les migrations de la nouvelle version. Les données écrites après l’instantané sont perdues.

L’instantané est supprimé une fois la mise à jour ou la restauration réussie, et une mise à jour ultérieure supprime tout instantané restant de plus de 7 jours. Si la base migrée ne peut pas être supprimée, la version précédente démarre dessus comme auparavant et l’instantané est conservé. Si la restauration échoue après la suppression, Opfield reste arrêté et l’instantané est conservé : corrigez la cause indiquée dans les journaux du conteneur de mise à jour, puis restaurez depuis le répertoire d’Opfield :

docker compose exec -T postgres psql -U opfield -d postgres -c 'DROP DATABASE IF EXISTS opfield WITH (FORCE)'
docker compose exec -T postgres pg_restore --create --exit-on-error -U opfield -d postgres < .opfield-foundation-backups/pre-update-<time>/opfield-db.dump
docker compose up -d

L’instantané ne protège que la mise à jour elle-même. Conservez aussi les sauvegardes PostgreSQL du jeu de reprise.

Mettre à jour depuis 2.10

La mise à jour depuis 2.10.x est exécutée par l’outil de mise à jour de 2.10.x. Celui-ci n’attend pas les opérations en cours et ne prend pas d’instantané de la base de données d’Opfield ; préparez-la donc vous-même.

Avant la mise à jour

Dans le répertoire d’Opfield (/opt/gateway par défaut), sauvegardez la base de données et conservez une copie de .env, qui contient PKI_MASTER_KEY :
Fenêtre de terminal
```
docker compose exec -T postgres pg_dump -Fc -U gateway gateway > gateway-2.10.dump
cp .env env-2.10.backup
```
Évitez les déploiements, les sauvegardes et les migrations Docker pendant la mise à jour.
Sur une installation payante, assurez-vous que l’hôte Opfield peut joindre le service de licences : la mise à jour télécharge le cœur commercial signé de 2.11 et s’arrête avant le remplacement de l’application s’il n’y parvient pas. Les installations Community qui n’ont jamais détenu de plan payant se mettent à jour sans lui.
En Community, lisez Mettre à niveau une installation Community depuis 2.10 : à partir de 2.11, les bases de données (y compris les connexions externes enregistrées en 2.10), le stockage, l’intégration GitLab ainsi que Plan Mode, les Scenarios et les Sandboxes d’AI Workspace nécessitent Personal ou supérieur. Leurs enregistrements restent dans la base de données et redeviennent utilisables avec une clé Personal ou supérieure.

La mise à jour applique les migrations de base de données de 2.11. Les données existantes que 2.11 n’autorise plus, comme deux charges de travail sur un même port d’hôte d’un nœud, deux Routes activées portant le même nom sur un nœud ou des exécutions de sauvegarde actives en double, sont signalées dans le journal d’audit au lieu de faire échouer la mise à jour ; voir Conflits résolus par la mise à jour 2.11.

Si la mise à jour revient en arrière, 2.10.x redémarre sur la base de données déjà migrée et conserve ses permissions et une licence valide ; une nouvelle mise à jour rétablit tout ce que 2.11 avait. Corrigez la cause indiquée dans les journaux du conteneur de mise à jour et mettez à jour à nouveau. Pour revenir plutôt à l’état antérieur à la mise à jour, remettez en place le .env enregistré, arrêtez tous les services sauf postgres (docker compose stop app relay registry redis), restaurez gateway-2.10.dump avec les commandes DROP DATABASE et pg_restore de Retour arrière automatique et instantané de la base de données, et exécutez docker compose up -d.

Ordre de mise à jour

Mettez à jour Opfield.
Mettez à jour les démons des nœuds avec Nodes > Update Nodes, qui liste chaque nœud Docker, Nginx, Storage et Monitoring disposant d’un démon plus récent et met à jour ensemble ceux qui sont sélectionnés.
Mettez à jour le Relay Pool avec Settings > General > Update Relay Pool.

Ne mettez pas à jour les démons des nœuds ou les relais avant Opfield : le relais 2.11 nécessite Opfield 2.11, et de nombreuses fonctionnalités et corrections de 2.11 nécessitent les versions 2.11 de Docker, Nginx et Relay. Les relais 2.10 conservent le bail de politique Relay de 15 minutes jusqu’à leur mise à jour.

Après les mises à jour des démons et de Relay :

La première application d’un projet Compose, même pour une révision inchangée, recrée ses services une fois, car ils reçoivent les nouveaux paramètres de journalisation et un label portant l’empreinte de leur propre configuration ; les révisions suivantes ne recréent que les services qu’elles modifient ; voir Configuration Compose prise en charge. Les routeurs de Deployments cessent de plafonner les corps de requête lors de leur prochain déploiement, de leur prochaine bascule de slot ou de leur prochain redémarrage.
Les politiques Docker Availability passent d’elles-mêmes en mode bail une fois que chaque nœud Docker, chaque nœud Ingress et chaque relais de la charge de travail a exécuté 2.11 pendant 2 minutes. Chaque nœud Docker a besoin du lease watchdog : l’installateur du nœud Docker l’installe, et un démon Docker 2.11 qui s’exécute en root avec systemd ou OpenRC l’installe lui-même. Sinon, la politique liste le nœud sous Excluded nodes ; réexécutez-y l’installateur du nœud Docker avec sudo et le même --user. En mode bail, chaque nœud de la politique doit joindre chaque relais. Voir Basculement du plan de données.
Les nœuds Storage ont besoin d’un accès HTTPS sortant vers ghcr.io pour récupérer l’exécuteur de sauvegardes. Les autres images d’exécution tierces proviennent en priorité du miroir Opfield sur ghcr.io et se rabattent sur Docker Hub.
Les connexions externes PostgreSQL et clé-valeur avec TLS créées avant 2.11 restent non vérifiées et affichent un avertissement. Lancez la vérification en un clic ou ajoutez la CA privée ; voir Vérification des certificats TLS.
Les modèles Claude Fable 5.1 et Opus 5.5 publiés dans Opfield Inference avant 2.11 ont les outils désactivés ; ouvrez-les et enregistrez-les à nouveau.

Permissions après la mise à jour

Les groupes, utilisateurs, jetons d’API et autorisations OAuth qui détenaient un nom de scope retiré ont reçu son remplaçant, et les noms retirés restent acceptés en entrée pendant deux versions. Les scripts qui relisent les noms de scopes doivent s’attendre aux nouveaux noms. Voir Noms de scopes retirés.
Certains remplacements sont plus larges que l’ancien scope. Examinez les groupes, les permissions des utilisateurs, les jetons d’API et les autorisations OAuth qui détenaient l’un de ceux-ci :
- integrations:gitlab:ci:edit, :variables:edit, :variables:delete, :webhooks:manage et :registry:manage sont devenus integrations:gitlab:repo:write, qui commite aussi des fichiers de dépôt et modifie la configuration CI, les variables CI/CD, les webhooks et les paramètres du registre. Un jeton de CI qui se contentait de nettoyer le registre peut désormais pousser des commits.
- integrations:gitlab:ci:view est devenu integrations:gitlab:repo:read, qui lit aussi les fichiers du dépôt.
- integrations:gitlab:sync, :github:sync et :git:sync sont devenus la permission manage du connecteur : paramètres, jetons, liste d’autorisation, test et suppression.
- nodes:config:edit est devenu nodes:manage, qui installe aussi le Secure Runtime, modifie les adresses de service, et contrôle l’alimentation, le redimensionnement et la restauration d’instantanés des VM hébergées.
- proxy:advanced:bypass et proxy:raw:bypass sont tous deux devenus proxy:unrestricted ; l’un ou l’autre lève donc désormais les deux restrictions.
- proxy:templates:create, :edit et :delete sont devenus proxy:templates:manage, soit toute opération sur les modèles nginx.
- notifications:alerts:create, :edit et :delete sont devenus notifications:alerts:manage, et notifications:webhooks:create, :edit et :delete sont devenus notifications:webhooks:manage, qui révèle aussi les URL, les en-têtes et les charges utiles d’envoi des webhooks.
- docker:containers:folders:manage est devenu docker:folders:manage, qui couvre les dossiers de chaque type de ressource Docker.
integrations:gitlab:variables:view est devenu integrations:gitlab:repo:read et ne lit plus les valeurs des variables CI/CD ; la lecture des valeurs nécessite integrations:gitlab:repo:write.
Chaque permission d’action, sauf la création, implique désormais la permission de consultation de sa famille avec le même qualificatif : un groupe ou un jeton qui ne détenait qu’une permission de suppression, de modification, de gestion ou d’exécution peut désormais aussi lister et consulter ces ressources. Examinez les droits limités à la suppression.
Les groupes intégrés reçoivent automatiquement les nouvelles permissions. Les groupes personnalisés non : accordez diagnostics:view et diagnostics:logs pour les Diagnostics d’Opfield, databases:backups:view, :manage, :run et :restore, nodes:backups:execute, ainsi que storage:view, :create, :edit, :delete, :iam, storage:objects:* et storage:credentials:use là où c’est nécessaire. storage:credentials:reveal implique storage:credentials:use.
Les jetons ne voient jamais plus que le compte qui les a créés, et une permission de création ne compte plus comme consultation lorsque l’accès est délégué : les jetons des utilisateurs dont l’accès a diminué perdent cet accès.
Les sources Git enregistrées après la mise à jour ne construisent automatiquement que tant que le compte qui les a enregistrées conserve use sur le dépôt ; les webhooks et les déploiements automatiques vérifient le compte qui les a configurés.
Déployer ou mettre à jour un Deployment avec une nouvelle image, une nouvelle commande ou un nouvel environnement, et mettre à jour l’image d’un conteneur, nécessitent les permissions d’environnement et de secrets ; rattacher un conteneur à des réseaux nécessite le droit de modifier ces réseaux. Le SQL limité à l’écriture sur un PostgreSQL externe s’exécute une instruction à la fois, et les modifications de schéma ou de rôles nécessitent la permission d’administration.
Les limites du plan Community sont de 25 nœuds gérés, 3 utilisateurs et 1 groupe de permissions personnalisé (100, 10 et 5 en 2.10). Rien d’existant n’est supprimé ; la création au-delà est refusée.

Changements de comportement

TLS pour les noms inconnus. Les nœuds Ingress refusent les poignées de main TLS pour les noms d’hôte qu’aucune Route ne sert. Les clients ou répartiteurs de charge qui se connectent par IP en HTTPS sans SNI, ou qui s’appuient sur un site par défaut, sont refusés. Les nœuds dont le nginx a déjà son propre serveur par défaut sur le port 443 ignorent ce comportement avec un avertissement. Voir Routes.
Restrictions Compose. Les projets Compose ne peuvent ni utiliser le réseau de l’hôte ou les réseaux internes d’Opfield (gateway-secure-links, gateway-db-*, gateway-storage-*), ni définir les labels réservés d’Opfield, ni définir des variables du client Docker comme DOCKER_HOST, DOCKER_CONFIG, BUILDKIT_* et COMPOSE_*. Les projets existants qui enfreignent ces règles continuent de s’exécuter et peuvent être arrêtés et supprimés, mais une nouvelle révision, une application, un démarrage ou un redémarrage sont refusés jusqu’à leur modification, y compris la première application après la mise à jour du démon Docker. Voir Configuration Compose prise en charge.
Contrôles des directives nginx. Le contenu des modèles nginx et la configuration avancée des Additional Routes sont contrôlés comme la configuration des Routes : sans proxy:unrestricted, les directives interdites sont refusées et les journaux nginx ne peuvent être écrits que sous /var/log/nginx. Les modèles enregistrés avant la mise à jour continuent d’être générés tels qu’enregistrés.
Bail de politique Relay. Les relais continuent de fonctionner sans Opfield pendant 72 heures par défaut (Settings > Relay, de 1 heure à 7 jours) ; voir Les relais sans Opfield.
Maintenance. L’historique des opérations — builds terminés avec leurs journaux, opérations Compose, Availability et d’hébergement, et livraisons de webhooks — est conservé 90 jours, et les autorisations OAuth expirées ainsi que les clients OAuth qui n’ont jamais terminé une autorisation sont purgés. Modifiez Settings > Features > Housekeeping avant la première exécution si vous avez besoin d’un historique plus long ; voir Maintenance et rétention.
Renouvellement de la PKI interne. Les certificats de PKI interne liés à des Routes sont réémis automatiquement avant leur expiration lorsqu’Opfield détient la clé privée ; le renouvellement automatique est activé pour les liaisons existantes.
Rotation des jetons GitLab. Les jetons GitLab dotés du scope api ou self_rotate qui expirent dans les 14 jours sont renouvelés par Opfield, qui révoque l’ancien jeton. Donnez à Opfield un jeton qui lui est propre si le même jeton est utilisé ailleurs ; voir Expiration et rotation des jetons.
Paramètres. L’enregistrement des paramètres ne redémarre Opfield que lorsque le HTTPS interne est basculé, ou lorsque la Public URL change alors que le HTTPS interne est activé. Les méthodes de connexion, la MFA, le fournisseur OIDC et le provisionnement des identités ont été déplacés vers Settings > Authentication, la journalisation structurée se trouve dans Settings > Features, et Authentication email (SMTP) s’appelle désormais SMTP configuration.
API. Les lectures de nœuds n’incluent plus le matériel des jetons d’enrôlement, une mise à jour de nœud vide renvoie 400, et un identifiant mal formé renvoie 404. Les modifications d’environnement, de recréation et de révision Compose renvoient 409 tant qu’un déploiement de build détient la cible. Un chemin /api inconnu renvoie un 404 JSON.
Docker Availability n’est plus étiqueté Tech Preview, et les builds ne peuvent plus être épinglés au tableau de bord ni à la barre latérale.

Conflits résolus par la mise à jour 2.11

Opfield 2.11 applique plusieurs règles d’unicité dans sa base de données plutôt que seulement dans le code applicatif ; elles valent donc aussi lorsque plusieurs processus Opfield traitent des requêtes simultanément. La mise à jour n’échoue jamais sur des données existantes qui enfreignent l’une d’elles : la migration 0207 conserve l’enregistrement le plus ancien, signale ou renomme les autres, et consigne chaque cas dans le journal d’audit. Après la mise à jour, recherchez ces actions dans le journal d’audit et résolvez ce qu’elles signalent.

Règle après la mise à jour	Ce que la mise à jour a fait des conflits existants	Action d’audit
Deux Routes activées sur un même nœud Ingress ne peuvent pas servir le même nom (`409 PROXY_HOST_DOMAIN_CONFLICT`)	La Route la plus ancienne conserve le nom. Les suivantes conservent leur configuration et restent signalées jusqu’à ce que leurs noms ou leur nœud changent. Une fois désactivée, une telle Route ne peut pas être réactivée tant qu’une autre Route activée sert le nom. nginx ne sert que l’une d’elles ; retirez donc le nom d’une Route ou désactivez-la	`proxy_host.domain_conflict`
Une politique de sauvegarde a une seule sauvegarde en file d’attente ou en cours (`409 BACKUP_ALREADY_RUNNING`), et une seule restauration vers un nom de nouvelle base donné s’exécute à la fois (`409 BACKUP_RESTORE_ALREADY_RUNNING`)	Une exécution active continue : une exécution en cours plutôt qu’une exécution en file d’attente, sinon la plus récente. Les autres sont marquées en échec avec la phase `superseded`, libèrent leur exécuteur et voient leurs exécuteurs de sauvegarde annulés	`database.backup.superseded`
Les noms des stockages managés sont uniques par nœud Storage (`409 MANAGED_STORAGE_NAME_IN_USE`)	Le cluster le plus ancien conserve le nom. Les suivants, ainsi que leurs connexions de stockage, sont renommés avec le premier suffixe libre `-2`, `-3`, …	`storage.managed.renamed_duplicate`
Un port d’hôte sur un nœud appartient à un seul Deployment, stockage managé ou base de données managée (`409 DEPLOYMENT_HOST_PORT_IN_USE`, `MANAGED_STORAGE_PORT_CONFLICT` ou `MANAGED_DATABASE_PORT_CONFLICT`)	La charge de travail la plus ancienne conserve le port. Les suivantes continuent de s’exécuter et sont signalées ; déplacez l’une d’elles vers un autre port	`node.host_port_conflict`
Un certificat utilisé par une Route ne peut pas être supprimé (`409 CERT_IN_USE`)	Rien à résoudre : la base de données applique désormais la vérification existante	—

Les ports d’hôte que le démon Docker choisit pour une base de données managée évitent les ports réservés par d’autres charges de travail sur ce nœud. Une base de données managée dont le port publié entre encore en conflit avec la réservation d’une autre charge de travail le signale dans managed.hostPortConflicts de sa connexion de base de données, avec le port et la charge de travail qui le détient.

La mise à jour ne supprime ni Routes, ni charges de travail, ni stockages, ni sauvegardes, et n’arrête pas les charges de travail en cours. Vérifiez, pour les clusters renommés, les clients qui renomment des stockages managés ou les recherchent par nom.

Mettre à jour vers 2.11.1

2.11.1 fait passer les liaisons de bases de données et les liens de stockage sur un seul connecteur secure-link partagé par nœud Docker et ajoute les liens entre conteneurs. Mettez d’abord à jour Opfield, puis les démons Docker. Ce qui se passe sur chaque nœud après la mise à jour de son démon Docker :

Chaque charge de travail dotée d’une liaison de base de données est recréée une fois, une à la fois sur chaque nœud, la suivante une fois que la précédente s’exécute sainement. Les Deployments se déploient en blue/green sans interruption ; les Containers autonomes et les services Compose redémarrent une fois ; planifiez donc en conséquence la mise à jour des nœuds qui exécutent de telles charges de travail.
Chaque charge de travail dotée d’un lien de stockage créé avant 2.11.1 est recréée une fois juste après la bascule de son lien. Les liens créés en 2.11.1 ne nécessitent pas de recréation.
Les noms de variables et les identifiants ne changent pas, et rien n’est à faire à la main. Ne supprimez pas vous-même les anciens réseaux ou conteneurs de liens.
Revenir à un démon Docker 2.11.0 rebascule automatiquement ses liens, avec une recréation par charge de travail. Au plus quatre charges de travail par nœud sont recréées simultanément, limite du démon pour les commandes concurrentes ; sur un nœud comportant de nombreux Deployments liés, les derniers se reconnectent donc un peu plus tard.
Les mises à jour ultérieures du connecteur conservent les connexions de liens ouvertes : à partir de 2.11.4, l’ancien connecteur les transmet au nouveau sans reconnexion. Un connecteur antérieur à 2.11.4 les conserve jusqu’à une heure, puis les ferme une fois ; une troisième mise à jour dans cette heure ferme immédiatement les connexions du plus ancien connecteur.

Les nouveaux réseaux de liens utilisent leur propre plage d’adresses, 10.213.x.x (un /16) par défaut. Si elle chevauche un réseau que vos nœuds joignent par leur route par défaut, définissez docker.secure_links.subnet_pool avant de mettre à jour le démon Docker, afin que les liens déplacés utilisent déjà votre plage (les démons antérieurs ignorent cette clé) ; voir Connecteur partagé et réseaux de liens.

Mettre à jour vers 2.12

2.12 ajoute les Apps, les bases de données et le stockage sur plusieurs serveurs, les stockages clé-valeur Valkey, les relais protégés et Opfield Cloud. Une installation 2.11 se voit d’abord proposer 2.11.5, puis 2.12. Mettez d’abord à jour Opfield, puis les démons des nœuds, puis le Relay Pool. À quoi vous attendre :

Adresses des services. Opfield 2.12 lit les versions et les installateurs de nœuds depuis get.opfield.dev et utilise les adresses du service de licences listées dans Prérequis de mise à jour. Autorisez get.opfield.dev et license.opfield.dev dans une liste d’autorisation du trafic sortant avant la mise à jour.
Dépôt d’images. Les images sont publiées dans ghcr.io/opfield/opfield. Pour une mise à jour manuelle, définissez GATEWAY_IMAGE_REF dans .env sur une image de ce dépôt (OPFIELD_IMAGE_REF à partir de 2.12.1).
Barre latérale plus courte. Domains, Ingress Groups, Access Lists et les Templates nginx sont des onglets de Routes ; les certificats SSL, Authorities, PKI Certificates et les Templates de certificats sont des onglets de Certificates ; Profile se trouve dans le menu du compte. Les anciennes adresses de pages ouvrent l’onglet correspondant.
Les stockages clé-valeur conservent Redis. Les stockages clé-valeur managés existants continuent d’exécuter Redis et de fonctionner. Les nouveaux stockages exécutent Valkey. Faites passer un stockage existant avec Move to Valkey quand cela vous convient, puis effectuez une nouvelle sauvegarde : une sauvegarde ne se restaure que dans le moteur dont elle provient.
Démons Docker. Move to Valkey, l’exécution d’une base de données ou d’un stockage sur plusieurs serveurs et l’isolement des conteneurs par le coupe-circuit des apps nécessitent le démon Docker 2.12 sur les nœuds Storage et Docker concernés ; Opfield vous demande de mettre à jour un démon trop ancien.
Relais. Le mode protégé et l’hébergement de témoins de bases de données nécessitent le relais 2.12. Lancez la mise à jour du Relay Pool après celle des démons.
Rien ne bouge de soi-même. Les ressources existantes ne rejoignent pas d’app, et aucune base de données ni aucun stockage ne commence à s’exécuter sur plusieurs serveurs tant que vous ne l’activez pas.

Mettre à jour vers 2.12.1

2.12.1 termine le passage aux noms Opfield. Une fois la mise à jour vers 2.12.1 stabilisée (environ dix minutes après que la nouvelle version est devenue saine, afin que le retour arrière automatique de la version précédente soit terminé), une installation créée avant 2.12.1 se déplace d’elle-même une fois :

le répertoire /opt/gateway devient /opt/opfield ; /opt/gateway reste sous forme de lien vers celui-ci ;
le projet Compose, les conteneurs (opfield-app-1, …) et le réseau (opfield_default) prennent le nouveau nom ;
la base de données et son rôle sont renommés opfield, et les paramètres de .env sont nommés OPFIELD_* ;
le ClickHouse local géré devient opfield-clickhouse avec la base opfield_logs ;
les volumes Docker conservent leurs noms (gateway_gateway_data, gateway_postgres_data, …) : docker-compose.yml les rattache par leur nom ; rien n’est donc copié et aucun espace disque supplémentaire n’est nécessaire.

Pendant le déplacement, Opfield est indisponible pendant environ une minute, et les Secure Links passant par le relais de l’hôte Opfield s’arrêtent une fois pendant quelques dizaines de secondes, le temps que la pile soit recréée. Les opérations d’orchestration en cours se terminent d’abord, comme avant une mise à jour. Lorsque vous mettez à jour avec l’installateur, celui-ci déplace l’installation juste après la mise à jour et affiche le nouveau répertoire.

Le déplacement s’exécute dans le conteneur opfield-host-move et consigne chaque étape dans .opfield-host-move/state.json du répertoire d’installation. Après un plantage ou un redémarrage, Docker le relance et il reprend là où il s’était arrêté. Si une étape échoue de manière répétée, le déplacement annule ce qu’il a fait et Opfield s’exécute depuis /opt/gateway comme avant ; il réessaie au bout de six heures, au plus trois fois. docker logs opfield-host-move affiche chaque étape. Pour réessayer immédiatement :

docker rm opfield-host-move
cd /opt/gateway && curl -fsSL https://get.opfield.dev | bash

Revenir à 2.12.0 après le déplacement n’est pas pris en charge. Les CA système affichent leurs nouveaux noms (Opfield Node CA, Opfield Database CA, Opfield Storage CA) ; leurs certificats sont conservés, de sorte que les nœuds, les relais et vos applications qui leur font confiance continuent de fonctionner. Les scripts d’installation qui définissent des variables GATEWAY_* continuent de fonctionner ; les noms OPFIELD_* l’emportent lorsque les deux sont définis.

Mises à jour des démons et de Relay

Mettez à jour un domaine de panne à la fois. Pour les membres du Relay Pool, videz, mettez à jour, vérifiez et remettez en service chaque membre avant de passer au suivant. Pour les nœuds ordinaires, vérifiez les ressources propres au rôle après la reconnexion. Ne mettez pas à jour simultanément tous les membres Ingress, Storage ou Relay, sauf si l’environnement dispose d’un chemin de reprise testé de façon indépendante.

Nodes > Update Nodes met à jour ensemble les démons de plusieurs nœuds, et Opfield refuse les mises à jour de démons pour les nœuds déconnectés, les nœuds Relay et les nœuds qui exécutent déjà la version ; voir Mises à jour des démons. Après une mise à jour d’Opfield, mettez à jour les démons des nœuds avant le Relay Pool, en particulier en venant de 2.10 : la mise à jour du Relay Pool met aussi à jour le relais local, en le recréant immédiatement tant qu’il exécute une version antérieure à 2.11.1, et les démons actuels s’y reconnectent en une fraction de seconde ; voir Relay et Relay Pool. Les mises à jour des démons et de Relay des nœuds qui participent au basculement du plan de données sont ordonnées par Opfield, un membre de chaque politique Availability à la fois ; une mise à jour peut donc attendre ses pairs de bail.

Procédure de restauration

Provisionnez un environnement Opfield compatible et propre.
Restaurez PostgreSQL et les volumes persistants à partir du même point de reprise.
Restaurez le matériel de chiffrement, de PKI et d’identité de Relay avec ses permissions d’origine.
Démarrez les dépendances internes, Opfield et Relay dans l’ordre documenté.
Vérifiez la connexion et le déchiffrement avant d’autoriser les modifications.
Laissez les nœuds gérés se reconnecter avec leurs identités existantes.
Réconciliez les Routes, les certificats, les charges de travail, les liaisons de bases de données, les notifications et les intégrations.
Restaurez les bases de données applicatives via les procédures natives des moteurs lorsque c’est nécessaire.
Confirmez la continuité de l’audit et consignez l’événement de reprise.

Si seule une partie du jeu de reprise est disponible, arrêtez-vous et évaluez les conséquences. Générer des clés maîtresses ou des identités de remplacement peut rendre définitivement orphelins l’état chiffré ou les nœuds gérés.

Décision de retour arrière

Décidez du déclencheur de retour arrière avant de lancer une mise à jour : migration en échec, impossibilité de déchiffrer les secrets existants, échec de l’autorisation de Relay, état incompatible des démons, Routes clientes cassées ou autre condition mesurable. Conservez les références d’images approuvées précédentes et la sauvegarde correspondante jusqu’à ce que la nouvelle version ait terminé sa fenêtre d’observation.

Le retour arrière applicatif et le retour arrière des données sont distincts. En dehors du retour arrière automatique d’une mise à jour qui n’est jamais devenue saine, revenir à une image d’Opfield antérieure n’annule pas une migration de schéma PostgreSQL terminée, et ramener une charge de travail à un artefact plus ancien n’annule pas les données modifiables des volumes ou des bases de données. Suivez les consignes de compatibilité propres à chaque version et ne restaurez les données qu’à partir d’un point de reprise coordonné lorsque l’intégrité l’exige.

Validation de l’opérateur après la mise à jour

Couche	Preuve requise
Identité	Les utilisateurs existants se connectent ; la MFA, OAuth et le déchiffrement fonctionnent
Plan de contrôle	Les migrations sont terminées ; les planificateurs d’arrière-plan et l’audit continuent
Relay et nœuds	Les versions sont compatibles ; les nœuds se reconnectent avec un inventaire récent
Trafic client	Le DNS externe, TLS, la santé des Routes et la réponse de l’application réussissent
Données	Les bases de données managées sont saines et les liaisons applicatives peuvent interroger
Automatisation	Les builds, les webhooks, les notifications et les connecteurs de sources utilisés par l’installation fonctionnent

Conservez l’enregistrement de la mise à jour avec les heures de début et de fin, les versions, les empreintes des images, les identifiants des sauvegardes, l’opérateur, les exceptions et la vérification finale. La prochaine mise à jour devient ainsi une procédure maîtrisée plutôt qu’une reconstitution à partir de l’historique shell.