Skip to main content

Image de base

Chaque template part d’un environnement source. Le SDK prend en charge plusieurs points d’entrée selon le niveau de contrôle dont vous avez besoin.
  • fromPythonImage(...) / from_python_image(...) pour un runtime Python standard
  • fromUbuntuImage(...) / from_ubuntu_image(...) ou fromDebianImage(...) / from_debian_image(...) pour une base Linux standard
  • fromNodeImage(...) / from_node_image(...) et fromBunImage(...) / from_bun_image(...) pour des bases propres à un langage
  • fromImage(...) / from_image(...) pour une image de conteneur arbitraire
  • fromDockerfile(...) / from_dockerfile(...) lorsque votre Dockerfile est déjà la source de vérité
  • fromBaseImage() / from_base_image() pour partir de la base par défaut de la plateforme
  • fromTemplate(...) / from_template(...) pour ajouter une couche au-dessus d’un autre template
fromPythonImage("3.12") et from_python_image("3.12") équivalent à partir de :
Dockerfile

Registres privés

Si votre image de base se trouve dans un registre privé, transmettez les identifiants lors de la définition de la source du template. Les SDK JS et Python prennent en charge :
  • les identifiants de registre génériques avec nom d’utilisateur et mot de passe
  • les identifiants de registre AWS
  • les identifiants de registre GCP
  • les identifiants de registre Huawei Cloud
Exemple de registre privé générique :

Définition du template

L’API du builder vous permet de composer l’environnement final directement dans le code. Les étapes de définition courantes incluent :
  • runCmd(...) / run_cmd(...) pour installer des packages ou exécuter des commandes de provisionnement
  • copy(...) pour inclure des fichiers locaux
  • makeDir(...), remove(...), rename(...), et makeSymlink(...) pour structurer le système de fichiers
  • setEnvs(...) / set_envs(...) pour les variables d’environnement
  • pipInstall(...), npmInstall(...), bunInstall(...), et aptInstall(...) pour la configuration des packages
  • gitClone(...) / git_clone(...) pour intégrer du code dans l’image
Exemple :

Commandes de démarrage et de disponibilité

Utilisez une commande de démarrage lorsque le template doit lancer un service longue durée dans le résultat du build, et utilisez une commande de disponibilité pour définir à quel moment ce service est considéré comme sain. C’est utile pour les applications web, les serveurs d’API, les workers en arrière-plan et tout template qui doit déjà être initialisé au démarrage d’une sandbox.
Vous pouvez également configurer la disponibilité séparément avec setReadyCmd(...) / set_ready_cmd(...).
Dernière modification le 10 août 2026