Environnements d'une app

Chaque ressource d’une app appartient à un environnement. La page d’un environnement contient ce que partagent ses ressources : les nœuds qu’elles peuvent utiliser, les variables et secrets que reçoit chaque charge de travail, la maintenance de toutes ses routes et la promotion depuis ou vers un autre environnement. Ouvrez-la depuis l’onglet Overview ou le bloc Environments de l’onglet Settings de l’app.

Nœuds autorisés

Un environnement ne crée des ressources que sur les nœuds qu’il autorise. Un nouvel environnement n’en autorise aucun. Utilisez Allow node sur la page de l’environnement pour ajouter un nœud ; l’onglet Nodes de l’app affiche les nœuds autorisés de chaque environnement.

La règle s’applique partout, pas seulement dans la console : l’API REST, MCP et l’assistant d’IA refusent de créer un conteneur, un déploiement, un projet Compose, une base de données managée, un stockage managé, une route ou un projet Pages de l’environnement sur un nœud qu’il n’autorise pas, tout comme la migration, Workload Availability et la restauration d’une sauvegarde dans une nouvelle base de données. Lorsque l’environnement n’autorise aucun nœud du type requis, la requête est refusée avec « no allowed node » ; lorsqu’elle désigne un nœud non autorisé, avec « node not allowed ».

Retirer un nœud de la liste est possible à tout moment. La confirmation indique combien de ressources de l’environnement s’y exécutent ; elles continuent de s’exécuter, mais de nouvelles ne peuvent plus y être créées.

Variables et secrets

Le bloc Variables définit des valeurs que reçoivent chaque conteneur, chaque déploiement et chaque service Compose de l’environnement. Les Secrets fonctionnent de la même manière, mais en écriture seule : après l’enregistrement, seuls leurs clés et le moment de leur modification sont affichés. Les deux sont chiffrés au repos. Un environnement contient jusqu’à 200 clés, chaque valeur pouvant atteindre 32 Kio, et une clé est soit une variable, soit un secret, pas les deux. Les projets Pages ne reçoivent pas de variables.

Lorsqu’une clé est définie à plusieurs endroits, la valeur la plus spécifique l’emporte, de la plus faible à la plus forte priorité :

1. l’ENV propre à l’image ;
2. les variables de l’environnement ;
3. les secrets de l’environnement ;
4. les variables d’environnement propres à la ressource (ou les variables du projet Compose) ;
5. les secrets propres à la ressource.

L’onglet Environment d’un conteneur signale les clés qui proviennent de l’environnement. Les valeurs de l’environnement ne sont jamais copiées dans les paramètres propres à la ressource ; les modifier plus tard change donc ce que reçoit la ressource. Un service Compose reçoit chaque clé d’environnement qu’il ne définit pas lui-même ; les valeurs ne sont pas écrites dans le fichier Compose.

Save, ou Save and recreate

Les charges de travail en cours ne redémarrent pas lorsque vous modifiez les valeurs de l’environnement. Après Save, l’avis indique combien de charges de travail recevront les nouvelles valeurs lors de leur prochaine recréation ou de leur prochain déploiement.

Pour les appliquer immédiatement, utilisez More → Save and recreate N workloads. Cette action recrée les charges de travail une par une : les conteneurs sont recréés, les déploiements suivent leur déploiement normal et les projets Compose sont appliqués. La boîte de dialogue affiche l’avancement de chaque charge de travail et s’arrête au premier échec, qu’elle nomme ; les charges de travail suivantes ne sont pas touchées.

Une charge de travail qui passe dans un autre environnement reçoit les valeurs du nouvel environnement lors de sa prochaine recréation, et les clés de l’ancien environnement sont retirées. Une charge de travail sortie de l’app perd les clés de l’environnement lors de sa prochaine recréation.

Maintenance

Maintenance sur la page de l’environnement met toutes les routes de l’environnement en maintenance d’un coup : elles renvoient la page de maintenance (HTTP 503) jusqu’à ce que vous la désactiviez. Le paramètre de maintenance propre à chaque route est conservé et s’applique à nouveau ensuite. Le bloc affiche Off, Maintenance, ou le nombre de routes dont la maintenance propre est activée alors que l’interrupteur de l’environnement est désactivé.

Maintenance for the whole app, dans l’onglet Settings de l’app, fait de même pour chaque route de chaque environnement et prévaut sur l’interrupteur de chaque environnement ; la page de l’environnement affiche alors Overridden by the app. La désactiver rétablit l’état propre à chaque environnement.

Seules les routes qui redirigent vers un upstream sont concernées, comme avec l’interrupteur propre à la route. La page d’une route indique d’où provient sa maintenance.

Code d’accès de maintenance

Pour laisser passer une personne pendant que les routes sont en maintenance, ouvrez le menu d’actions de l’environnement (ou de l’app) et choisissez Create Maintenance Access Code. Le code est valable 5 minutes et ouvre une fois chaque route de cet environnement (ou de toute l’app) qui est en maintenance. Ne le partagez qu’avec la personne qui a besoin de l’accès. Les routes doivent s’exécuter sur un nœud ingress qui prend en charge les codes d’accès, et un code ne fonctionne jamais tant que l’app est isolée. Voir Listes d’accès et maintenance pour la façon de saisir un code.

Promouvoir

Le bloc Promote exécute dans un autre environnement exactement ce qui s’exécute dans celui-ci, sans rien reconstruire. C’est ainsi qu’un staging testé passe en production.

1. Sur la page de l’environnement source, choisissez Promote to <environment>. S’il y a plus de deux environnements, sélectionnez d’abord la cible.
2. L’étape 1 liste ce qui s’exécute dans la source et sa comparaison avec la cible : Same, Changed ou Not promotable avec la raison. Désactivez ce qui ne doit pas être promu.
3. L’étape 2 indique ce qui se passera dans la cible pour chaque élément.
4. Confirmez. Les éléments s’exécutent l’un après l’autre ; un échec n’arrête pas les autres. La boîte de dialogue affiche l’avancement de chacun.

Ce qui est promu :

• Conteneurs et déploiements : l’image par son empreinte, de sorte que la cible exécute une image identique octet pour octet. Un déploiement utilise son déploiement normal. Une image construite depuis Git est promue en tant que même artefact de build, sans nouveau build.
• Projets Compose : le fichier Compose de la révision source, l’image de chaque service étant épinglée sur l’empreinte qui s’exécute dans la source. La cible conserve ses propres variables et secrets.
• Projets Pages : le déploiement actif de la source est copié dans le projet cible et y devient actif.

Les bases de données, le stockage, leurs données et leur schéma ne sont jamais promus.

Les ressources sont appariées par nom : le même nom, ou le nom de la source sans suffixe -<environment> final (shop-api-staging dans staging s’apparie avec shop-api dans production). Une ressource source sans paire est listée comme absente de la cible. Une paire de types différents, comme un déploiement et un conteneur, n’est pas promouvable.

L’aperçu est revérifié lors de la confirmation ; si quelque chose a changé entre-temps, Opfield vous demande de le revoir. Chaque promotion est enregistrée dans l’onglet Activity de l’app avec ce qui a changé, et le bloc Promote de l’environnement indique quand une promotion y a été effectuée pour la dernière fois.

Permissions

La gestion des nœuds autorisés, des variables, des secrets, de la maintenance et des codes d’accès nécessite le rôle Developer sur l’environnement (apps:env:manage). La promotion nécessite le rôle Deployer sur l’environnement cible (apps:promote). La maintenance de toute l’app nécessite le rôle Operator sur l’app. La page de l’environnement elle-même nécessite apps:view sur l’environnement ; un utilisateur qui ne voit l’environnement qu’à travers ses ressources est renvoyé vers la page de l’app. Voir Permissions des Apps.