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.

Ce que vous obtenez

Une installation gérée est un Opfield complet, dans la même version que l'auto-hébergé, à l'adresse <name>.opfield.cloud. Vous l'achetez et la gérez dans le portail client, avec une clé de licence payante (Personal, Business ou Enterprise). Elle n'est pas disponible avec Community.

• Région : Finlande. L'Allemagne est prévue.
• Connexion avec votre compte Opfield. Le propriétaire se connecte à l'installation avec le même compte que sur le portail.
• Sauvegardes quotidiennes. Une sauvegarde est faite chaque jour. Vous pouvez aussi sauvegarder à la demande et restaurer depuis le portail. Après une suppression, la dernière sauvegarde est gardée quelques jours pour pouvoir récupérer l'installation.
• Mises à jour dans votre fenêtre de maintenance. Vous choisissez un jour et une heure (UTC). Opfield fait une sauvegarde, se met à jour et revient sur la nouvelle version. Vous pouvez aussi mettre à jour tout de suite.
• Vos nœuds restent les vôtres. Vous connectez vos propres serveurs avec des jetons à usage unique depuis le portail. Les charges de travail, les bases et le stockage tournent sur eux, pas sur la VM gérée.

Offres

Les prix sont mensuels, en plus de la clé de licence, et se renouvellent avec elle.

Douze mois coûtent le prix de onze. Vous pouvez passer de Standard à Extended à tout moment en payant la différence pour le reste de la période ; Opfield redémarre une fois. Un passage à l'offre inférieure prend effet à la fin de la période payée.

L'e-mail inclus

Opfield envoie des e-mails système : codes de connexion, liens de création et de réinitialisation de mot de passe, invitations. Une installation auto-hébergée a besoin d'un fournisseur SMTP pour cela. Une installation gérée les envoie d'emblée, depuis <name>@mail.opfield.cloud, sur les deux offres et sans supplément.

Les limites suffisent largement pour des e-mails système et préservent la réputation de l'expéditeur partagé :

• Standard : 500 par mois, 50 par jour, 25 par heure.
• Extended : 2 000 par mois, 200 par jour, 50 par heure.

Votre propre domaine

L'installation peut répondre sur votre domaine, par exemple ops.example.com. Ajoutez le domaine sur la page de l'installation, créez l'enregistrement CNAME indiqué, et Opfield obtient un certificat. L'adresse en opfield.cloud continue de fonctionner. Les passkeys sont liées à l'adresse et doivent être ajoutées à nouveau après un changement ; la page vous prévient avant.

L'IA incluse

Opfield intègre un assistant IA et un serveur MCP pour vos propres agents. Les deux ont besoin d'un modèle. Sur une installation gérée, Opfield Cloud AI est déjà connecté :

• Free, avec chaque installation gérée : utilisation des modèles incluse.
• S, 9 $/mois.
• M, 29 $/mois, avec deux fois plus d'utilisation que S.

Deux modèles sont proposés : Opfield Swift pour le travail rapide du quotidien, et Opfield Heavy pour les tâches plus longues et plus difficiles. L'utilisation s'affiche en pourcentage de chaque fenêtre, avec l'heure de sa remise à zéro. Quand une fenêtre est épuisée, l'assistant le dit et reprend après la remise à zéro. Le reste d'Opfield continue de fonctionner.

Pour commencer

Dans le portail client, activez « Host it in our cloud » à l'achat d'une clé, ou choisissez « Add managed cloud » sur la page d'une clé existante. Après le paiement, l'installation est configurée automatiquement et vous recevez un e-mail quand elle est prête. Les offres et les prix sont aussi sur la page des tarifs.

Les mêmes règles que pour une personne

Les agents n'ont pas de modèle de droits à part. Un client MCP se connecte à https://<your-opfield>/api/mcp et s'authentifie en OAuth au nom d'un utilisateur. Sur l'écran de consentement, l'utilisateur choisit les scopes accordés au client, et ceux-ci ne dépassent jamais ses propres droits. Un accès limité à des dossiers, des nœuds ou des ressources précises fonctionne de la même façon : un agent qui a accès au dossier d'une application ne voit que ce dossier. L'agent peut appeler get_my_access pour savoir ce qui lui a été accordé et où il peut créer des ressources.

Les agents peuvent faire presque tout ce qu'une personne fait avec les ressources. Quelques actions restent volontairement réservées au navigateur : l'usurpation d'identité, le consentement OAuth, la création de jetons d'API ou d'autorisations, ainsi que la connexion et les sessions de l'utilisateur lui-même. Un agent ne peut pas s'accorder plus de droits.

Le point d'accès MCP n'accepte que les jetons OAuth émis pour lui ; les jetons de l'API REST n'y fonctionnent pas. L'utilisateur doit aussi disposer du droit MCP : c'est donc un administrateur qui décide qui peut connecter des agents.

Tout est dans le journal d'audit

Chaque action d'un agent passe par les mêmes contrôles qu'un clic dans l'interface et s'inscrit dans le même journal d'audit, avec l'utilisateur et le jeton d'origine. Pour savoir ce qu'un agent a changé pendant la nuit, il suffit d'ouvrir le journal d'audit.

Des garde-fous contre les erreurs

Les droits définissent ce qu'un agent peut faire. Mais certaines erreurs arrivent dans le cadre de ces droits, alors Opfield ajoute des garde-fous :

• Garde-fou de console. Les agents peuvent exécuter des commandes en root dans la console d'un nœud, ce qui leur permet de le réparer. Docker, containerd et Podman y sont masqués, et une commande Docker est refusée avec le nom de l'outil Opfield à utiliser. C'est un garde-fou contre les erreurs, pas une frontière de sécurité : il évite qu'un agent modifie un conteneur géré dans le dos d'Opfield.
• Pas de SSH vers les nœuds. Les agents ne peuvent pas exécuter de commandes en SSH sur des hôtes qui sont des nœuds Opfield. Ils passent par la console du nœud, qui a son garde-fou.
• Les changements hors d'Opfield sont visibles. Si un conteneur géré est malgré tout arrêté, modifié ou supprimé à la main, l'alerte intégrée « Container changed outside Opfield » se déclenche.
• Des nouvelles tentatives sans risque. Les opérations de création acceptent une clé d'idempotence : un agent qui réessaie après un délai dépassé ne crée pas de doublon.

Des outils Docker plutôt qu'un shell

L'essentiel du travail d'un agent sur les charges de travail passe par des outils dédiés plutôt que par des commandes shell : lister les conteneurs de tous les nœuds Docker, lire les logs et les métriques, redémarrer, mettre à jour une image, modifier la configuration, gérer les déploiements avec slots et retour arrière, les projets Compose, les volumes, les réseaux et les sources Git avec leurs builds. Comme ce sont des opérations Opfield, les routes, les Secure Links et la disponibilité restent cohérents après un changement, et chaque étape est auditée.

Les agents peuvent aussi lire la documentation et les skills d'Opfield via MCP avant de modifier quoi que ce soit.

Exemple : un service en panne

Un utilisateur écrit à un agent : « L'API de facturation renvoie des 502 depuis ce matin. Trouve pourquoi et corrige. » Une session type :

1. find_resource trouve la route et le conteneur derrière elle ; get_route montre l'upstream.
2. get_docker_container montre que le conteneur redémarre en boucle et que sa source Git a déployé un nouveau build à 07:40.
3. get_docker_container_logs montre que le processus s'arrête au démarrage : une nouvelle variable d'environnement obligatoire manque.
4. L'agent le signale et propose deux options : revenir au build précédent ou ajouter la variable.
5. L'utilisateur choisit le retour arrière. L'agent appelle manage_docker_source avec rollback, puis vérifie à nouveau les logs et la route : le conteneur tourne et la route répond 200. Le retour arrière figure dans le journal d'audit au nom de l'utilisateur.

Personne n'a eu besoin d'un accès shell au serveur, et l'agent n'a rien fait en dehors des droits de l'utilisateur.

Pour commencer

Ajoutez le serveur MCP dans votre client avec l'adresse de votre Opfield, connectez-vous et choisissez les scopes. Commencez par des scopes en lecture seule, regardez dans le journal d'audit ce que fait l'agent, et élargissez l'accès à mesure que la confiance s'installe. Si vous préférez ne pas configurer de client, l'assistant intégré à Opfield utilise les mêmes outils et les mêmes règles.