Skip to main content

Imagem base

Todo template começa a partir de um ambiente de origem. O SDK oferece suporte a vários pontos de entrada, dependendo de quanto controle você precisa.
  • fromPythonImage(...) / from_python_image(...) para um runtime Python padrão
  • fromUbuntuImage(...) / from_ubuntu_image(...) ou fromDebianImage(...) / from_debian_image(...) para uma base Linux padrão
  • fromNodeImage(...) / from_node_image(...) e fromBunImage(...) / from_bun_image(...) para bases específicas de linguagem
  • fromImage(...) / from_image(...) para uma imagem de contêiner arbitrária
  • fromDockerfile(...) / from_dockerfile(...) quando seu Dockerfile já é a fonte da verdade
  • fromBaseImage() / from_base_image() para começar a partir da base padrão da plataforma
  • fromTemplate(...) / from_template(...) para criar uma camada sobre outro template
fromPythonImage("3.12") e from_python_image("3.12") são equivalentes a começar a partir de:
Dockerfile

Registries privados

Se sua imagem base estiver em um registry privado, passe as credenciais ao definir a origem do template. Os SDKs JS e Python oferecem suporte a:
  • credenciais genéricas de registry com nome de usuário e senha
  • credenciais de registry da AWS
  • credenciais de registry do GCP
  • credenciais de registry do Huawei Cloud
Exemplo de registry privado genérico:

Definindo o template

A API do builder permite compor o ambiente final diretamente no código. Etapas comuns de definição incluem:
  • runCmd(...) / run_cmd(...) para instalar pacotes ou executar comandos de provisionamento
  • copy(...) para incluir arquivos locais
  • makeDir(...), remove(...), rename(...) e makeSymlink(...) para modelagem do sistema de arquivos
  • setEnvs(...) / set_envs(...) para variáveis de ambiente
  • pipInstall(...), npmInstall(...), bunInstall(...) e aptInstall(...) para configuração de pacotes
  • gitClone(...) / git_clone(...) para trazer código para a imagem
Exemplo:

Comandos de inicialização e prontidão

Use um comando de inicialização quando o template deve iniciar um serviço de longa execução durante o resultado da build, e use um comando de prontidão para definir quando esse serviço é considerado saudável. Isso é útil para apps web, servidores de API, workers em segundo plano e qualquer template que já deve estar inicializado quando um sandbox começa.
Você também pode configurar a prontidão separadamente com setReadyCmd(...) / set_ready_cmd(...).
Última modificação em 10 de agosto de 2026