Opfield 2.12.3

Opfield 2.12.3 est disponible. L'essentiel du travail de cette version a porté sur trois points : empêcher les disques de se remplir, rendre l'accès des agents plus sûr, et corriger les aspérités des builds Git, de Pages et des bases de données gérées. Voici les changements que la plupart des utilisateurs remarqueront. La liste complète se trouve dans le journal des modifications.

Des disques qui ne débordent plus

Un plan de contrôle qui gère des builds, des images et des logs sur de nombreux serveurs peut remplir un disque sans bruit. Dans la 2.12.3, tout ce qui grossit a désormais une limite.

• Le registre interne garde deux builds par conteneur, supprime les builds des sources retirées et refuse les nouveaux builds quand son disque est plein à 90 %.
• Les nœuds Docker suppriment les images que rien n'a utilisées depuis 12 heures. Chaque conteneur garde l'image qu'il exécute et une pour revenir en arrière.
• Les logs des conteneurs sur les nœuds Docker restent bornés, y compris pour les conteneurs créés avant Opfield ou en dehors. Les nœuds nginx limitent la taille des logs de routes et suppriment ceux des routes supprimées.
• Le WAL et les slots de réplication de Postgres ne remplissent plus le disque d'une base.
• Housekeeping garde les données propres d'Opfield bornées même lorsqu'il est désactivé, et se lance immédiatement quand un disque d'Opfield atteint 90 %. Il montre aussi ce qui remplit chaque disque : les plus grosses tables, Redis, les logs des conteneurs et les anciennes images par nœud.

De nouvelles alertes intégrées préviennent à temps : alerte disque à 85 % pour chaque disque de données d'un nœud, disque d'Opfield plein, disques de bases pleins et Housekeeping arrêté.

Un garde-fou pour la console des agents

L'assistant et les clients MCP peuvent exécuter des commandes dans la console d'un nœud. Elles s'exécutent en root, pour qu'un agent puisse vraiment réparer un nœud. Docker, containerd et Podman sont masqués dans cette console : une commande qui utilise Docker est refusée, et la réponse indique l'outil Opfield à utiliser à la place.

C'est un garde-fou contre les erreurs, pas une frontière de sécurité. Il évite qu'un agent modifie par mégarde un conteneur géré dans le dos d'Opfield. Les agents ne peuvent plus non plus exécuter de commandes en SSH sur des hôtes qui sont des nœuds Opfield.

Si un conteneur géré est malgré tout arrêté, modifié ou supprimé à la main, la nouvelle alerte intégrée « Container changed outside Opfield » se déclenche et explique ce que cela implique.

Des règles d'accès dans le bon ordre

Les règles d'une liste d'accès sont évaluées de haut en bas, et la première qui correspond l'emporte. Jusqu'ici, l'ordre ne pouvait pas être modifié : une règle d'autorisation ajoutée après un refus large ne s'appliquait jamais. Les règles peuvent maintenant être réordonnées dans l'interface, par l'API et par MCP, et celles qui ne peuvent jamais s'appliquer sont signalées.

Ordre de bascule des bases et du stockage

Pour Postgres géré, les bases clé-valeur, ClickHouse et le stockage S3 avec disponibilité, vous pouvez désormais définir l'ordre de bascule : quel serveur prend le relais en premier quand le primaire tombe.

Registre dans S3

Le registre interne peut stocker ses données dans S3 plutôt que sur le disque de l'hôte Opfield. Un changement de stockage vérifie chaque image que le registre conserve pour les charges de travail.

Pages et pages d'erreur

Les projets Pages servent leur propre 404.html pour les chemins absents, avec un statut 404.

Toutes les pages que nginx génère lui-même (erreurs, clients refusés, upstreams injoignables, serveur par défaut) sont désormais des pages Opfield. Les pages d'erreur de vos applications passent sans modification.

Sources Git

• Un conteneur avec une source Git peut revenir à son build précédent depuis l'onglet Source, l'API ou MCP.
• Un build en échec affiche l'étape du Dockerfile qui a échoué et son code de sortie, et une source indique pourquoi un build a échoué ou n'a rien déployé.
• Les variables d'environnement, les secrets et les volumes peuvent être définis avant le premier build, et le premier build démarre tout de suite.
• La politique de sécurité des builds peut ne bloquer que les vulnérabilités qui ont un correctif, pour les paquets de l'application ou pour tous les paquets.

Aussi dans cette version

Les routes derrière Cloudflare voient la vraie IP du client dans les listes d'accès, les limites de débit et les logs. Postgres géré tourne sur les images d'Opfield, et PostGIS et pgRouting s'installent à la demande depuis l'onglet Extensions.

À savoir avant de mettre à jour : les archives de conteneurs utilisent maintenant le format Opfield (.ofca). Les archives exportées par les versions précédentes ne peuvent pas être importées.

Les installations auto-hébergées se mettent à jour comme d'habitude. Les installations cloud gérées se mettent à jour pendant leur fenêtre de maintenance.