As
imagens de base pré-configuradas
fornecidas pelas estações de trabalho do Cloud contêm apenas um ambiente mínimo com IDE,
ferramentas básicas de terminal e linguagem 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 reconstruir essas imagens automaticamente quando a imagem de base do Cloud Workstations for atualizada, além de executar uma ferramenta de verificação de contêineres, como a Artifact Analysis, para inspecionar todas as dependências adicionais que você adicionou. Você é responsável manutenção e atualização de pacotes e dependências personalizados adicionados a imagens personalizadas.
Antes de começar
Você precisa de uma máquina com ferramentas para criar imagens de contêiner, como o Docker, e enviar imagens para o Artifact Registry (ou Container Registry) usando a CLI do Google Cloud. É possível usar o Cloud Workstations ou o Cloud Shell Editor para realizar essas etapas, que têm essas ferramentas pré-instaladas.
Selecione a imagem de base que você quer usar na 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.
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 de 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 alfabética 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 na 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çosshd
no contêiner.110_start-$IDE.sh
: inicia o ambiente de desenvolvimento integrado para a 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 adicionar mais funcionalidades durante a inicialização da estação de trabalho, adicione os scripts no
diretório /etc/workstation-startup.d/
:
Os scripts nesse diretório são executados como raiz por padrão. Para executar os scripts como um usuário diferente, use o comando
runuser
.Como os scripts são executados em ordem alfabética, recomendamos que você adicione um prefixo de três dígitos maior que 200.
Modificações no 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
é anexada dinamicamente ao contêiner no ambiente de execução. Esse processo substitui
as modificações feitas no diretório /home
no momento da criação 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, considere executar o script de configuração como um processo
em segundo plano (adicione um símbolo &, &
, 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 - Repositórios
git
clonados no diretório principal - Configurações diretas 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 persistente se conecta dinamicamente ao contêiner no momento da 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 atualizar
/etc/workstation-startup.d/010_add-user.sh
ou
criar seu próprio script que 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 das estações de trabalho do Google Cloud vêm pré-instaladas com várias ferramentas obtidas
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
referenciados nos arquivos list
correspondentes em /etc/apt/sources.list.d/
.
Isso permite que a apt
verifique a integridade de um determinado repositório ao
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 problema,
use /google/scripts/refresh-preinstalled-apt-keys.sh
, que
importa novamente as versões mais recentes das chaves públicas pré-instaladas.
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 script /google/scripts/preinstalled-ide-versions.sh
incluído, que lista o nome e as informações de versão dos ambientes de desenvolvimento integrados instalados na
imagem.
Desativar privilégios de raiz do sudo
O usuário padrão da estação de trabalho tem privilégios de acesso raiz sudo
nesses
contêineres. Para desativar o acesso raiz ao contêiner do Docker, defina a
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:
- 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.
- 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.
- Clique em AdicionarAdicionar variável.
- Insira
CLOUD_WORKSTATIONS_CONFIG_DISABLE_SUDO
etrue
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 um
processo de bloqueio, como sleep infinity
, para que o contêiner continue
sendo 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:
- Atualize o
Dockerfile
para incluir outros recursos estáticos que você quer adicionar. - Adicione outros arquivos executáveis em
/etc/workstation-startup.d/
ao personalizar o contêiner em execução. Os arquivos nesse diretório são executados automaticamente em ordem alfabética na inicialização do contêiner. Assim, você pode prefixar o nome do arquivo para executá-lo no momento apropriado durante a inicialização da estação de trabalho. - Substitua o
ENTRYPOINT
no Dockerfile para personalizar totalmente a inicialização do contêiner.
Exemplos de Dockerfiles personalizados
Esta seção fornece exemplos de cenários e instruções para criar seu próprio cenário Dockerfiles.
Imagem do 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:
Crie um script em
/etc/workstation-startup.d/*
que seja executado depois010_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.Supondo que você nomeou seu script,
011_customize-user.sh
, adicione o a seguir à 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 o IDE nas imagens de base pré-configuradas. No entanto, as sessões SSH não são processos filhos do ponto de entrada e não têm essas variáveis de ambiente personalizadas definidas.
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
entrypoint ao arquivo /etc/environment
.
Para isso, siga estas etapas:
Crie um script em
/etc/workstation-startup.d/*
que seja executado após010_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.Supondo que você nomeou seu script,
011_add-ssh-env-variables.sh
, adicione o a seguir à 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
O encaminhamento X11 permite iniciar aplicativos remotos e encaminhar a tela do aplicativo para 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 para Cloud Workstations em 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 estágios de build. Para adicionar o Code OSS para estações de trabalho do Cloud a
outra imagem de contêiner, use um build em vários estágios para copiar a pasta do aplicativo
/opt/code-oss
para a imagem. Se você quiser iniciar o Code OSS para estações de trabalho do Cloud
na inicialização do contêiner, copie o script /etc/workstation-startup.d/110_start-code-oss.sh
para o contêiner.
Confira um exemplo de Dockerfile que copia o Code OSS para a imagem do JetBrains IntelliJ Ultimate. 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 de contêiner que pré-instala extensões de ambiente de desenvolvimento integrado no Code OSS para estações de trabalho do Cloud para desenvolvimento Java
Para criar uma imagem de contêiner que pré-instala extensões de ambiente de desenvolvimento integrado no Code OSS para estações de trabalho do Cloud para desenvolvimento Java no momento da criação, execute os seguintes 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 um
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 ambientes de desenvolvimento integrado e plug-ins 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 ambientes de desenvolvimento integrado da JetBrainsplugin-installer.sh
: instalar plug-ins, como o Cloud Code para IntelliJ
Use esses scripts conforme necessário para personalizar a imagem de base, chamá-los com um 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 dos scripts jetbrains-installer.sh
e
plugin-installer.sh
, inicie uma estação de trabalho usando uma configuração
que use uma das imagens predefinidas do JetBrains, conecte-se à
estação de trabalho pelo JetBrains Gateway ou pelo SSH e navegue
pelos arquivos de script no diretório installer-scripts
, que fica no
diretório raiz.
Recomendamos que você execute esses scripts no momento da criação do contêiner. Evite executá-los 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 do plug-in necessário do mercado de plug-ins da JetBrains. Por exemplo, para adicionar Dart usar6351
como o PLUGIN_ID. Para adicionar Cloud Code para IntelliJ usar8079
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 o uso do script do instalador do JetBrains ao estender uma imagem base pré-configurada para ambientes de desenvolvimento integrados do JetBrains.
O script jetbrains-installer.sh
usa a seguinte sintaxe:
jetbrains-installer.sh IDE [ pinned|latest ]
Substitua:
IDE
: o ambiente de desenvolvimento integrado da JetBrains a ser instalado. Você precisa 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
PyCharm Professional pycharm
PyCharm Professional ps
PHPStorm phpstorm
PHPStorm rd
Rider rider
Rider rm
RubyMine rubymine
RubyMine ws
WebStorm webstorm
WebStorm pinned|latest
(opcional): use as colunas fixas ou 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 de origem persistente for especificado na configuração das estações de trabalho, as imagens de base das estações de trabalho do Cloud com ambientes de desenvolvimento integrados do JetBrains vão manter automaticamente os arquivos de configuração $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 do JetBrains para saber
como as estações de trabalho do Cloud configuram isso por padrão.
Estender uma imagem base do Docker com o Cloud Code para 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 opcionalmente version 22.9.3-222
como o número
da versão, /opt/ideaIU/plugins/
como o 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 outras extensões de IDE no
Open VSX Registry.
Também é possível encontrar o URL do arquivo .vsix
copiando o URL do link
Download de qualquer extensão.
Se você abrir o Extensions Marketplace em uma estação de trabalho, a opção Install vai aparecer em vez de 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 a editar O ícone Editar atualiza os outros exemplos nesta página.
Substitua:
CUSTOM_IMAGE_FOLDER
: o caminho para a pasta que você criou para armazenar a imagem personalizada.TARGET_IMAGE
: o caminho para a imagem no Artifact Registry ou no 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 outros identificadores.
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:
- Como criar um repositório do Docker com o Artifact Registry.
- Convenções de nomenclatura para nomes de repositórios e imagens.
Hospedar sua imagem de contêiner personalizada
Para hospedar imagens de contêineres personalizadas, recomendamos o Artifact Registry. Se você usar 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 de contêiner personalizada
Depois que o contêiner terminar de ser criado, teste-o com o seguinte comando:
docker run --privileged -p LOCAL_PORT:CONTAINER_PORT TARGET_IMAGE
Substitua:
LOCAL_PORT
: o número da porta localCONTAINER_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 das estações de trabalho do Cloud, execute o comando docker
e teste a imagem da estação de trabalho conectando-se a ela
pelo navegador local ou executando ssh
para se conectar ao contêiner:
- Se você se conectar pelo navegador, transmita
-p 8080:80
para o comandodocker run
e abralocalhost:8080
. - Se você preferir se conectar por SSH, transmita
-p 2222:22
ao comandodocker run
e executessh user@localhost -p 2222
.
Usar uma imagem de contêiner personalizada
Para usar a 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 o seguinte comando:
docker push TARGET_IMAGE
Agora você pode 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, analise os registros de saída do contêiner nas estações de trabalho em execução.
Recomendado: ajude a proteger seu pipeline de imagens
Você é responsável por manter e atualizar pacotes personalizados e dependências adicionadas a imagens personalizadas.
Se você estiver criando imagens personalizadas, recomendamos o seguinte:
Ajude a proteger seu pipeline de imagem recriando automaticamente essas imagens quando a imagem de base do Cloud Workstations é atualizado.
Execute uma ferramenta de verificação de contêineres, como o Artifact Analysis, para inspecionar as dependências adicionais que você adicionou.
Programar builds reconstruir imagens semanalmente ou aprender a automatizar recriações de imagens de contêiner.
A seguir
- Automatize a recriação de imagens de contêiner para sincronizar atualizações de imagens de base usando o Cloud Build e o Cloud Scheduler.
- Configurar práticas recomendadas de segurança.
- Saiba mais sobre o Artifact Analysis.