Aller au contenu

Images de runtime

Les workloads de vos équipes — jobs et espaces de travail — tournent dans des images d’exécution publiées séparément de la plateforme. Elles ne suivent pas le numéro de version du produit : une correction de sécurité sur une image ne doit pas attendre une version de graal.

Image Base Sert à
toolbox Alpine jobs bash et conteneurs d’initialisation (copies, attente, préparation)
python Python 3.11 slim jobs python et lowcode
spark-py Apache Spark 3.5 jobs spark
jupyter scipy-notebook espace de travail Jupyter
code-server code-server espace de travail VS Code

Propriétés communes, vérifiées au build :

  • identité non privilégiée par défaut (uid 10001), sans avoir à forcer l’utilisateur au lancement ;
  • base épinglée par empreinte, pas par étiquette mouvante : deux constructions de la même définition donnent la même image ;
  • testées sous contrainte restreinte simulée (toutes capacités Linux retirées, pas de nouveau privilège), c’est-à-dire dans les conditions réelles d’exécution.

Les images de runtime sont publiques : elles ne contiennent ni code client, ni configuration, ni secret — uniquement des paquets publics. Cela permet un tirage anonyme, sans distribuer d’identifiants de registre aux nœuds qui exécutent les workloads.

La règle qui en découle est stricte : rien de confidentiel, et jamais l’image d’un client, dans ce dépôt-là.

Chaque type de runtime résout son image par une table de configuration. Vous pouvez y pointer votre propre image — par exemple une image Python durcie par votre équipe sécurité, ou dérivée de la nôtre avec vos bibliothèques internes.

Les types spécialisés (docker, dbt, dask, flink, ray) se servent de la même façon : une image par type, désignée dans cette table. Un runtime sans image configurée répond 501 feature_disabled plutôt que de tenter un lancement voué à l’échec.