Personalizar imagens de contêiner

O imagens de base pré-configuradas fornecidos pelo Cloud Workstations contêm apenas um ambiente mínimo com o ambiente de desenvolvimento integrado, ferramentas básicas de linguagem e terminal do Linux e um servidor sshd; Para acelerar a do ambiente de desenvolvimento para casos de uso específicos, é possível criar imagens de contêiner que estendem essas imagens de base para pré-instalar ferramentas e e que executam scripts de automação.

Para imagens de contêiner personalizadas, recomendamos configurar um pipeline para recriar essas imagens quando a imagem de base do Cloud Workstations for atualizada, além de executar uma ferramenta de verificação de contêineres, Artifact Analysis para inspecionar as dependências adicionais adicionadas. Você é responsável manutenção e atualização de pacotes e dependências personalizados adicionados a imagens personalizadas.

Antes de começar

  1. Você precisa de uma máquina com ferramentas para criar imagens de contêiner, como Docker e para enviar imagens ao Artifact Registry (em inglês) (ou Container Registry) usando o Google Cloud CLI: Use o Cloud Workstations ou o Cloud Shell Editor para realizar que têm essas ferramentas pré-instaladas.

  2. Selecione a imagem de base que você quer usar do nosso lista de imagens de base compatíveis, como us-central1-docker.pkg.dev/cloud-workstations-images/predefined/code-oss:latest

    Como alternativa, é possível usar sua própria imagem de contêiner ou imagens de contêiner seguindo as instruções para Use sua própria imagem de contêiner.

  3. Crie uma pasta como CUSTOM_IMAGE_FOLDER e uma Dockerfile dentro desta pasta estendendo a imagem de base selecionada, conforme mostrado em nos exemplos a seguir.

Estrutura da imagem base do Cloud Workstations

As imagens de base do Cloud Workstations compartilham a seguinte estrutura definida:

  • O arquivo de ponto de entrada da imagem de base está definido como /google/scripts/entrypoint.sh.

  • Na inicialização, as imagens de base executam arquivos em /etc/workstation-startup.d/* em ordem lexicográfica para inicializar o ambiente da estação de trabalho.

    Os arquivos e seus comportamentos são os seguintes:

    • 000_configure-docker.sh: configura e executa o Docker no a estação de trabalho.

    • 010_add-user.sh: cria o usuário padrão no Cloud Workstations.

      Como o disco permanente é anexado dinamicamente ao contêiner, os usuários precisam ser adicionados na inicialização da estação de trabalho, não no Dockerfile.

    • 020_start-sshd.sh: inicia o serviço sshd no contêiner.

    • 110_start-$IDE.sh: inicia o ambiente de desenvolvimento integrado da imagem.

  • O Cloud Workstations armazena imagens do Docker no diretório inicial em /home/.docker_data para que as imagens sejam preservadas entre as sessões.

Para acrescentar funcionalidade durante a inicialização da estação de trabalho, adicione seus scripts em diretório /etc/workstation-startup.d/:

  • Por padrão, os scripts nesse diretório são executados como raiz. Para executar os scripts como com outro usuário, use o comando runuser.

  • Como os scripts são executados em ordem lexicográfica, recomendamos que você prefixe os scripts com um número de três dígitos maior que 200.

Modificações do diretório principal

Quando a configuração da estação de trabalho especifica um diretório principal permanente (que é o comportamento padrão), um disco permanente que apoia o diretório principal é dinamicamente anexado ao contêiner no ambiente de execução. Esse processo substitui modificações feitas no diretório /home no tempo de build da imagem do contêiner.

Para preservar as atualizações, modifique o diretório /home no ambiente de execução do contêiner. adicionando um script no diretório /etc/workstation-startup.d ou adicionando uma configuração por usuário no diretório /etc/profile.d. Para acelerar o processo, execute o script de configuração como segundo plano processo (adicione um E comercial, &, ao final do comando) para evitar bloquear a inicialização do contêiner.

Alguns exemplos de configuração de tempo de build que precisam ser movidos para o contêiner ambiente de execução:

  • Configuração de git por usuário
  • git repositórios clonados no diretório inicial
  • Configuração direta do usuário, como colocar arquivos em um diretório $HOME/.config
  • Criação de usuário

Criação e modificação de usuários

Como o disco permanente se anexa dinamicamente ao contêiner no ambiente de execução, os usuários precisam ser adicionados na inicialização da estação de trabalho, não no Dockerfile. Para modificar ou criar outros usuários, recomendamos que você atualize /etc/workstation-startup.d/010_add-user.sh ou criar seu próprio script para ser executado na inicialização.

Além disso, é possível modificar o perfil bash padrão para os usuários atualizando os arquivos em /etc/profile.d.

Atualizar chaves APT seguras pré-configuradas

As imagens de base do Cloud Workstations vêm pré-instaladas com várias ferramentas disponíveis de vários repositórios de terceiros usando o APT seguro. Como parte da instalação, processo, as chaves públicas fornecidas pelos proprietários do repositório são importadas usando gpg e colocados em arquivos individuais em /usr/share/keyrings/. Esses arquivos são referenciado dos arquivos list correspondentes em /etc/apt/sources.list.d/. Isso permite que o apt verifique a integridade de um determinado repositório quando interagir com ele.

Às vezes, os proprietários de repositórios terceirizados podem decidir alterar a chave pública usada para validar a integridade do repositório, o que faz com que apt exibir um erro ao interagir com ele. Para resolver esse possível problema, é possível usar /google/scripts/refresh-preinstalled-apt-keys.sh, recebe as versões mais recentes das chaves públicas pré-instaladas e as reimporta.

Listar versões instaladas do ambiente de desenvolvimento integrado

Várias imagens de base do Cloud Workstations vêm pré-instaladas com um ambiente de desenvolvimento integrado. Para conveniência, consulte o /google/scripts/preinstalled-ide-versions.sh incluído que lista o nome e a versão dos ambientes de desenvolvimento integrado instalados a imagem.

Desativar privilégios raiz de sudo

O usuário padrão da estação de trabalho tem sudo privilégios de acesso raiz nestas containers. Para desativar o acesso raiz ao contêiner Docker, defina o Variável de ambiente CLOUD_WORKSTATIONS_CONFIG_DISABLE_SUDO como true ao criar a configuração da estação de trabalho.

Para definir essa variável de ambiente usando o console do Google Cloud ao criar a configuração da estação de trabalho, siga estas etapas:

  1. Ao criar a configuração da estação de trabalho, conclua a configuração para ver as informações básicas e a configuração da máquina.
  2. Na caixa de diálogo Personalização do ambiente, expanda a Seção Opções avançadas de contêiner e selecione Variáveis de ambiente.
  3. Clique em AdicionarAdicionar variável.
  4. Insira CLOUD_WORKSTATIONS_CONFIG_DISABLE_SUDO e true como o valor.
.

Usar sua própria imagem de contêiner

Também é possível usar sua própria imagem de contêiner ou imagens de contêiner externas, desde que sejam baseados em Linux e executem um processo de bloqueio quando o contêiner é iniciado.

Ao configurar o Dockerfile, a instrução ENTRYPOINT precisa executar uma processo de bloqueio, como sleep infinity, para que o contêiner continue ser executado, em vez de sair imediatamente. Como alternativa, na estação de trabalho é possível definir o campo config.container.args para especificar o processo de bloqueio.

Ao usar sua própria imagem de contêiner, observe o seguinte:

  • O Cloud Workstations não requer scripts adicionais do Imagem de base do Cloud Workstations.

    No entanto, é possível conferir os scripts na /etc/workstation-startup.d/ em um contêiner que executa a imagem base do Cloud Workstations. Os nomes dos arquivos indicam o que cada script faz.

  • Recomendamos que você execute um servidor SSH no contêiner. Consulte /etc/workstation-startup.d/020_start-sshd.sh no padrão imagem de base para saber como o Cloud Workstations faz essa configuração por padrão.

  • Recomendamos executar o servidor da Web ou o ambiente de desenvolvimento integrado padrão na porta 80.

Estender imagens de base do Cloud Workstations

Ao estender uma imagem de base do Cloud Workstations para criar uma imagem personalizada para seu ambiente de trabalho, é possível adotar três abordagens:

  1. Atualize o Dockerfile para incluir outros recursos estáticos que você que quiser adicionar.
  2. Adicione outros arquivos executáveis em /etc/workstation-startup.d/ ao personalizar o contêiner em execução. Os arquivos neste diretório automaticamente são executadas em ordem lexicográfica na inicialização do contêiner. Assim, você pode nome do arquivo para executá-lo no momento apropriado durante a inicialização da estação de trabalho.
  3. Substitua o ENTRYPOINT no Dockerfile para personalizar totalmente o do contêiner inicial.
.

Exemplos de Dockerfiles personalizados

Esta seção fornece exemplos de cenários e instruções para criar seu próprio cenário ou Dockerfiles.

Imagem de contêiner com emacs pré-instalado

Para criar uma imagem de contêiner com o emacs pré-instalado, execute o seguinte: comandos:

FROM us-central1-docker.pkg.dev/cloud-workstations-images/predefined/code-oss:latest

RUN sudo apt update
RUN sudo apt install -y emacs

Imagem do contêiner com personalização do usuário

Siga estas etapas para personalizar uma imagem de contêiner:

  1. Crie um script em /etc/workstation-startup.d/* que seja executado depois 010_add-user.sh. Por exemplo, 011_customize-user.sh:

    #!/bin/bash
# Create new group
groupadd $GROUP
# Add the user to a new group
usermod -a -G $GROUP $USERNAME

    Substitua $GROUP pelo novo nome do grupo e $USERNAME pelo nome de usuário do usuário.

  2. Supondo que você nomeou seu script, 011_customize-user.sh, adicione o à sua imagem no Dockerfile e torne-a executável:

    FROM us-central1-docker.pkg.dev/cloud-workstations-images/predefined/code-oss:latest

COPY 011_customize-user.sh /etc/workstation-startup.d/

RUN chmod +x /etc/workstation-startup.d/011_customize-user.sh

Imagem de contêiner que define variáveis de ambiente de contêiner em sessões SSH

Variáveis de ambiente definidas no nível da estação de trabalho ou da configuração da estação de trabalho são passados para subprocessos diretos usando o comando entrypoint. Isso inclui IDE nas imagens de base pré-configuradas. Mas as sessões SSH não são filhas processos do ponto de entrada e não tiver esses ambientes personalizados variáveis definidas pelo usuário.

Para definir essas variáveis de ambiente nas sessões SSH, configure um imagem de contêiner que redireciona essas variáveis de ambiente da Ponto de entrada para o arquivo /etc/environment.

Para isso, siga estas etapas:

  1. Crie um script em /etc/workstation-startup.d/* que seja executado depois 010_add-user.sh. Por exemplo, 011_add-ssh-env-variables.sh:

    #!/bin/bash
#
echo "CUSTOM_ENV_VAR=$CUSTOM_ENV_VAR" >> /etc/environment

    Substitua CUSTOM_ENV_VAR pela variável de ambiente pretendida. nome.

  2. Supondo que você nomeou seu script, 011_add-ssh-env-variables.sh, adicione o à sua imagem no Dockerfile e torne-a executável:

    FROM us-central1-docker.pkg.dev/cloud-workstations-images/predefined/code-oss:latest

COPY 011_add-ssh-env-variables.sh /etc/workstation-startup.d/

RUN chmod +x /etc/workstation-startup.d/011_add-ssh-env-variables.sh

Imagem do contêiner que ativa o encaminhamento X11 para sessões SSH

Com o encaminhamento X11, você inicia aplicativos remotos e encaminha o aplicativo em uma máquina local.

Para criar uma imagem de contêiner que permita o encaminhamento X11, modifique o daemon do OpenSSH arquivo de configuração (/etc/ssh/sshd_config) fornecido pelas imagens de base do Cloud Workstations por anexando X11Forwarding yes (para permitir o encaminhamento X11) e AddressFamily inet (para garantir que somente IPv4 seja usado). Para mais informações sobre essas palavras-chave, consulte a página da Web do OpenBSD páginas sobre AddressFamily e X11Forwarding.

Este é um exemplo de Dockerfile, que faz as modificações necessárias:

FROM us-central1-docker.pkg.dev/cloud-workstations-images/predefined/code-oss:latest

# Permit X11 forwarding using only IPv4
RUN cat >> /etc/ssh/sshd_config <<-EOF

AddressFamily inet
X11Forwarding yes
EOF

Copiar o Code OSS do Cloud Workstations para outra imagem de contêiner

Um build de vários estágios permite usar várias instruções FROM. no Dockerfile. Cada instrução FROM pode usar uma base diferente e permite copiar artefatos entre as etapas de criação. Para adicionar o Code OSS do Cloud Workstations ao outra imagem de contêiner usa um build em vários estágios para copiar a pasta do aplicativo /opt/code-oss na imagem. Se você quiser iniciar o Code OSS para Cloud Workstations no momento da inicialização do contêiner, copie também o script /etc/workstation-startup.d/110_start-code-oss.sh. no contêiner.

Este é um exemplo de Dockerfile que copia o Code OSS para o IntelliJ do JetBrains Imagem final. Em seguida, você pode interagir com um dos ambientes de desenvolvimento integrado:

FROM us-central1-docker.pkg.dev/cloud-workstations-images/predefined/code-oss:latest as code-oss-image

FROM us-central1-docker.pkg.dev/cloud-workstations-images/predefined/jetbrains-intellij:latest

# Copy Code OSS for Cloud Workstations and startup scripts into our custom image
COPY --from=code-oss-image /opt/code-oss /opt/code-oss
COPY --from=code-oss-image /etc/workstation-startup.d/110_start-code-oss.sh /etc/workstation-startup.d/110_start-code-oss.sh

# Use the existing entrypoint script which will execute all scripts in /etc/workstation-startup.d/
ENTRYPOINT ["/google/scripts/entrypoint.sh"]

Imagem do contêiner que pré-instala extensões do ambiente de desenvolvimento integrado no Code OSS para Cloud Workstations para desenvolvimento em Java

Para criar uma imagem de contêiner que pré-instala as extensões do ambiente de desenvolvimento integrado Codifique o OSS do Cloud Workstations para desenvolvimento em Java no tempo de build. Execute estes comandos:

FROM us-central1-docker.pkg.dev/cloud-workstations-images/predefined/code-oss:latest

RUN wget https://open-vsx.org/api/vscjava/vscode-java-debug/0.40.1/file/vscjava.vscode-java-debug-0.40.1.vsix && \
unzip vscjava.vscode-java-debug-0.40.1.vsix "extension/*" &&\
mv extension /opt/code-oss/extensions/java-debug

RUN wget https://open-vsx.org/api/vscjava/vscode-java-dependency/0.19.1/file/vscjava.vscode-java-dependency-0.19.1.vsix && \
unzip vscjava.vscode-java-dependency-0.19.1.vsix "extension/*" &&\
mv extension /opt/code-oss/extensions/java-dependency

RUN wget https://open-vsx.org/api/redhat/java/1.6.0/file/redhat.java-1.6.0.vsix && \
unzip redhat.java-1.6.0.vsix "extension/*" &&\
mv extension /opt/code-oss/extensions/redhat-java

RUN wget https://open-vsx.org/api/vscjava/vscode-maven/0.35.2/file/vscjava.vscode-maven-0.35.2.vsix && \
unzip vscjava.vscode-maven-0.35.2.vsix "extension/*" &&\
mv extension /opt/code-oss/extensions/java-maven

RUN wget https://open-vsx.org/api/vscjava/vscode-java-test/0.35.0/file/vscjava.vscode-java-test-0.35.0.vsix && \
unzip vscjava.vscode-java-test-0.35.0.vsix "extension/*" &&\
mv extension /opt/code-oss/extensions/java-test

Se você pré-instalar extensões, elas serão consideradas extensões integradas. Você não poderá atualizar essas extensões, e elas podem não aparecer nos a seção instalada no no Marketplace de extensões. No entanto, você pode encontrar suas extensões integradas pesquisando @builtin:

Outra maneira de instalar extensões na inicialização é executar uma script de inicialização. Por exemplo, inclua o seguinte script de inicialização em /etc/workstation-startup.d/120_install_extensions.sh:

/opt/code-oss/bin/codeoss-cloudworkstations --install-extension vscjava.vscode-java-debug@0.40.1 \
--install-extension vscjava.vscode-java-dependency@0.19.1  \
--install-extension redhat.java@1.6.0 \
--install-extension vscjava.vscode-maven@0.35.2 \
--install-extension vscjava.vscode-java-test@0.35.0

Usando esse método, a extensão aparece no , O Extensions Marketplace e você que podem ser atualizadas a partir daí.

Instalar plug-ins e ambientes de desenvolvimento integrado do JetBrains em imagens de base

Ao personalizar imagens do Docker para configurações de estações de trabalho, é possível instalar IDEs e plug-ins da JetBrains, como Cloud Code para IntelliJ, na imagem de base. As imagens de base do Cloud Workstations para produtos da JetBrains incluem o seguinte: scripts para ajudar você a:

  • jetbrains-installer.sh: instalar os ambientes de desenvolvimento integrado da JetBrains
  • plugin-installer.sh: instalar plug-ins, como o Cloud Code para IntelliJ

Use esses scripts conforme necessário para personalizar a imagem base, para chamá-los com uma script de inicialização ou executá-los após a inicialização da estação de trabalho.

Scripts do instalador

Para conferir os arquivos de origem de jetbrains-installer.sh e Scripts plugin-installer.sh, inicie uma estação de trabalho usando uma estação de trabalho configuração que usa uma das imagens predefinidas do JetBrains, conecte-se ao da estação de trabalho pelo JetBrains Gateway ou por SSH e navegue os arquivos de script no diretório installer-scripts, localizado no diretório diretório raiz.

Recomendamos que você execute esses scripts no tempo de criação do contêiner. Evitar corrida em uma estação de trabalho já iniciada.

Usar o script do instalador do plug-in

O script plugin-installer.sh usa a seguinte sintaxe:

plugin-installer.sh [-v VERSION] [-d DESTINATION-DIRECTORY] [-c CHECKSUM] [-f] PLUGIN_ID

Substitua:

  • VERSION: número da versão opcional do plug-in a ser instalado.
  • DESTINATION-DIRECTORY: diretório opcional em que o plug-in deve ser instalado. Se não for especificado, será usado o diretório de trabalho.
  • CHECKSUM: soma de verificação SHA-256 opcional do plug-in solicitado.
  • -f: se especificado, qualquer plug-in atual será substituído.
  • PLUGIN_ID: o identificador numérico de plug-in obrigatório do mercado da JetBrains. Por exemplo, para adicionar Dart (link em inglês) usar 6351 como o PLUGIN_ID. Para adicionar Cloud Code para IntelliJ usar 8079 como o PLUGIN_ID.

Por exemplo, para instalar a versão mais recente do plug-in Dart no IntelliJ, execute o seguinte comando:

plugin-installer.sh -d /opt/ideaIU/plugins/ 6351

Usar o script do instalador do JetBrains

Recomendamos que você use o script de instalação do JetBrains ao estendendo uma imagem de base pré-configurada para ambientes de desenvolvimento integrado da JetBrains.

O script jetbrains-installer.sh usa a seguinte sintaxe:

jetbrains-installer.sh IDE [ pinned|latest ]

Substitua:

  • IDE: o ambiente de desenvolvimento integrado do JetBrains a ser instalado. Você deve usar uma das seguintes abreviações de IDE:

    Ambiente de desenvolvimento integrado Produto instalado
    cl CLion
    clion CLion
    go GoLand
    goland GoLand
    iiu Intellij Ultimate
    intellij Intellij Ultimate
    pcp Profissional PyCharm
    pycharm Profissional PyCharm
    ps PHPStorm
    phpstorm PHPStorm
    rd Rider
    rider Rider
    rm RubyMine
    rubymine RubyMine
    ws WebStorm
    webstorm WebStorm

  • pinned|latest (opcional): use as colunas fixas ou e a versão mais recente do ambiente de desenvolvimento integrado. O padrão é latest.

Por exemplo, para instalar a versão mais recente do Clion, execute o seguinte comando:

jetbrains-installer.sh clion

Personalizar arquivos de configuração do ambiente de desenvolvimento integrado do JetBrains

Se um diretório principal permanente for especificado nas estações de trabalho do Cloud Workstations com os ambientes de desenvolvimento integrado do JetBrains. manter automaticamente as configurações $IDE.vmoptions e $IDE.properties; . Para substituir o local padrão desses arquivos, especifique a variável de ambiente CLOUD_WORKSTATIONS_JETBRAINS_PERISTED_CONFIG_DIR.

Para mais informações, consulte /etc/workstation-startup.d/120_persist-jetbrains-configs.sh em qualquer Imagem de base da JetBrains (link em inglês) para aprender como o Cloud Workstations faz essa configuração por padrão.

Estender uma imagem Docker de base com o Cloud Code for IntelliJ

O snippet do Dockerfile a seguir estende uma imagem Docker básica com Cloud Code para IntelliJ incluindo 8079 como o identificador de plug-in obrigatório. O exemplo também especifica version 22.9.3-222 como a versão. /opt/ideaIU/plugins/ como diretório de destino e 89628279ed9042c526a81facc09bf53f8fb8b83b4595b0d329d94c1611e0c379 como o checksum:

...
# Install IDE and Plugins
RUN bash /installer-scripts/jetbrains-installer.sh intellij pinned && \
  # Install Cloud Code - https://plugins.jetbrains.com/plugin/8079-cloud-code
  bash /installer-scripts/plugin-installer.sh \
      -v 22.9.3-222 \
      -d /opt/ideaIU/plugins/ \
      -c 89628279ed9042c526a81facc09bf53f8fb8b83b4595b0d329d94c1611e0c379 \
      8079

# Register IDE with JetBrains Gateway
RUN echo 'runuser user -c "/opt/ideaIU/bin/remote-dev-server.sh registerBackendLocationForGateway"' > /etc/workstation-startup.d/110_register-intellij-with-gateway.sh \
    echo 'echo "IntelliJ-Ultimate ready for incoming gateway connection"' >> /etc/workstation-startup.d/110_register-intellij-with-gateway.sh
...

Instalar mais extensões do ambiente de desenvolvimento integrado no Code OSS para Cloud Workstations

Encontre mais extensões do ambiente de desenvolvimento integrado na Abra o VSX Registry. Também é possível encontrar o URL do arquivo .vsix copiando o URL do Link de download de qualquer extensão.

Abra a página do VSX da extensão da linguagem Go que mostra o botão &quot;Download&quot;.

Se você abrir o no Extensions Marketplace de uma estação de trabalho, a opção Instalar é exibida em vez de Fazer download.

Código padrão do OSS para configurações do Cloud Workstations

Para informações detalhadas sobre o armazenamento de configurações no Code OSS para Cloud Workstations, consulte Personalizar configurações.

Se você especificar um diretório principal permanente na configuração das estações de trabalho, é possível definir as configurações padrão do Code OSS para Cloud Workstations adicionando uma script de inicialização que grava configurações $HOME/.codeoss-cloudworkstations/data/Machine/settings.json

Por exemplo, se você quiser definir o tema de cores padrão como Escuro, estenda a base imagem do editor para incluir o script a seguir em /etc/workstation-startup.d/150_default-ide-color-theme.sh

cat <<< $(jq '. += {"workbench.colorTheme": "Default Dark Modern"}' settings.json) > settings.json

Criar uma imagem de contêiner personalizada

Para informações detalhadas sobre os comandos do Docker, consulte a Referência do Docker (link em inglês). Digite o seguinte comando para criar o contêiner:

docker build CUSTOM_IMAGE_FOLDER -t TARGET_IMAGE

A substituição do texto que antecede editar O ícone Editar atualiza os outros exemplos nesta página.

Substitua:

  • CUSTOM_IMAGE_FOLDER: o caminho para o que você criou para armazenar sua imagem personalizada.

  • TARGET_IMAGE: o caminho para a imagem no Artifact Registry. ou Container Registry.

    Por exemplo, TARGET_IMAGE pode apontar para uma imagem de destino semelhante a um dos seguintes caminhos:

    *.pkg.dev/cloud-workstations-external/customimage:latest

*.gcr.io/cloud-workstations-external/customimage:latest

    Substitua * conforme necessário pelo nome da região e e nenhum outro identificador.

Também é possível atualizar a variável de ambiente CLOUD_WORKSTATIONS_CUSTOM_IMAGE para apontar para o repositório.

Para mais informações sobre como armazenar imagens Docker no Artifact Registry, consulte a seções a seguir:

Hospedar a imagem personalizada do contêiner

Para hospedar imagens de contêiner personalizadas, recomendamos e oferecer suporte ao Artifact Registry. Se você usa o GitHub ou qualquer outro repositório público ou privado, o Cloud Workstations pode não funcionar como esperado. Para mais informações, consulte a observação importante na Usar uma imagem de contêiner personalizada nesta seção.

Testar a imagem personalizada do contêiner

Quando o contêiner terminar a criação, você poderá testá-lo com o seguinte comando:

docker run --privileged -p LOCAL_PORT:CONTAINER_PORT TARGET_IMAGE

Substitua:

  • LOCAL_PORT: o número da porta local
  • CONTAINER_PORT: o número da porta do contêiner.

Por exemplo, substituir LOCAL_PORT:CONTAINER_PORT com 8080:80 atribui a porta 8080 para uso local e a porta 80 para uso em o contêiner.

Se você estiver estendendo a imagem do editor de base do Cloud Workstations, execute o docker e, em seguida, teste a imagem da estação de trabalho conectando-se a ela usando seu navegador local ou executando ssh para se conectar ao seu contêiner:

  • Se você se conectar pelo navegador, transmita -p 8080:80 para comando docker run e, em seguida, abra localhost:8080.
  • Se você preferir se conectar por SSH, transmita -p 2222:22. no comando docker run e, em seguida, execute ssh user@localhost -p 2222.

Usar uma imagem de contêiner personalizada

Para usar uma imagem de contêiner personalizada depois de criá-la e testá-la localmente, envie o contêiner para o Artifact Registry (ou Container Registry) com os seguintes comando:

docker push TARGET_IMAGE

Agora é possível criar uma configuração de estação de trabalho usando a imagem do contêiner que você acabou de criar e enviar.

Para mais informações, consulte Crie um repositório do Docker com o Artifact Registry.

Depurar problemas

Para encontrar e depurar problemas na execução da imagem do contêiner, consulte as registros de saída de contêiner das estações de trabalho em execução.

Você é responsável por manter e atualizar os pacotes personalizados, e dependências adicionadas a imagens personalizadas.

Se você estiver criando imagens personalizadas, recomendamos o seguinte:

A seguir