Personalizar imagens de contêiner

As imagens de base pré-configuradas fornecidas pelo Cloud Workstations contêm apenas um ambiente mínimo com IDE, terminal básico do Linux e ferramentas de linguagem e um servidor sshd. Para acelerar a configuração do ambiente de casos de uso de desenvolvimento específicos, crie imagens de contêiner personalizadas que estendam essas imagens de base para pré-instalar ferramentas e dependências e que executem scripts de automação.

Para imagens de contêiner personalizadas, recomendamos configurar um pipeline para recriar automaticamente essas imagens quando a imagem de base do Cloud Workstations for atualizada, além de executar uma ferramenta de verificação de contêineres, como o Artifact Analysis, para inspecionar as dependências adicionais que você adicionou. Você é responsável por manter e atualizar 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 o Docker, e para enviar imagens para o Artifact Registry usando a Google Cloud CLI. Use o Cloud Workstations ou o editor do Cloud Shell para realizar essas etapas, que têm essas ferramentas pré-instaladas.

2. Selecione a imagem de base que você quer usar na nossa 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 usar imagens de contêiner externas seguindo as instruções para Usar sua própria imagem de contêiner.

3. Crie uma pasta como CUSTOM_IMAGE_FOLDER e um Dockerfile dentro dela que estenda a imagem de base selecionada, conforme mostrado 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 lexicográfica para inicializar o ambiente da estação de trabalho.

  Os arquivos e o comportamento deles são os seguintes:

  • 000_configure-docker.sh: configura e executa o Docker dentro da 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.

  • 030_customize-environment.sh: executa /home/user/.workstation/customize_environment como user.

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

• O Cloud Workstations armazena imagens 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 seus scripts no diretório /etc/workstation-startup.d/:

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

• Como os scripts são executados em ordem lexicográfica, recomendamos que você adicione um prefixo de três dígitos maior que 200.

Como alternativa, se você não quiser estender uma imagem de estações de trabalho, crie um script customize_environment no diretório inicial.

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 faz backup do diretório principal é anexado 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, execute o script de configuração como um processo em segundo plano (adicione um e comercial, &, ao final do comando) para evitar o bloqueio da inicialização do contêiner.

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

• Configuração do git por usuário
• Repositórios git 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 é anexado 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 crie seu próprio script que é 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 as chaves pré-configuradas do Secure APT

As imagens de base do Cloud Workstations vêm pré-instaladas com várias ferramentas obtidas de vários repositórios de terceiros usando o Secure APT. Como parte do processo de instalação, as chaves públicas fornecidas pelos proprietários do repositório são importadas usando gpg e colocadas 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 o apt verifique a integridade de um determinado repositório ao interagir com ele.

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

Também é possível executar esse script diretamente no Dockerfile personalizado antes de executar apt-get update:

# Refresh the preinstalled APT keys
RUN /google/scripts/refresh-preinstalled-apt-keys.sh

RUN apt-get update

Listar as 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 facilitar, 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 integrado instalados na imagem.

Desativar os privilégios de raiz de 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 no 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, preencha 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 addAdicionar variável.
4. Insira CLOUD_WORKSTATIONS_CONFIG_DISABLE_SUDO e true como o valor.

Observação: se um usuário conseguir sair do contêiner do Docker, ele poderá obter privilégios de raiz na VM subjacente.

Personalizar sem estender uma imagem

Para maior conveniência, todas as imagens de base do Cloud Workstations verificam a presença de um arquivo executável localizado em /home/user/.workstation/customize_environment e, se ele existir, o executam em segundo plano como user. Isso permite que você execute qualquer script ou binário na inicialização. Ao contrário de .profile ou .bashrc, o script é executado apenas uma vez quando a estação de trabalho é iniciada, em vez de uma vez para cada login do shell.

Como o script customize_environment é executado como user, atualize as permissões conforme necessário ao escrever o script. Por exemplo, se você quiser instalar o Emacs sempre que a estação de trabalho for iniciada, o conteúdo de customize_environment pode ser semelhante ao seguinte:

#!/bin/bash
sudo apt-get update
sudo apt-get install -y emacs

Os registros de execução de customize_environment podem ser encontrados no contêiner em /var/log/customize_environment e também são gravados nos registros de saída do contêiner. Após a execução bem-sucedida de customize_environment, um arquivo é criado em /var/run/customize_environment_done. Como customize_environment é executado em paralelo com a inicialização da estação de trabalho, os pacotes instalados pelo script podem estar disponíveis alguns instantes após a inicialização da estação de trabalho.

Evitar tempos limite de inatividade

Para facilitar, todas as imagens de base do Cloud Workstations incluem um script pré-instalado em /google/scripts/keep_alive.sh. Esse script envia mensagens de atividade regulares, que podem impedir que a estação de trabalho seja encerrada devido a tempos limite de inatividade quando você está executando processos em segundo plano sem interação direta.

Evitar tempos limite de inatividade com agentes de IA

Além disso, as imagens de base do Cloud Workstations incluem scripts de configuração de agente de amostra em /google/samples/agents/keepalive/. Essas configurações de amostra permitem configurar agentes de programação de IA (como o Claude Code e a CLI do Antigravity) dentro da estação de trabalho para mantê-la ativa automaticamente enquanto eles estão trabalhando em tarefas. Quando o agente conclui as tarefas ou pausa para aguardar a entrada do usuário, o script para de enviar mensagens de atividade, permitindo que a estação de trabalho expire devido à inatividade. Essas configurações funcionam melhor quando a configuração da estação de trabalho está definida para usar a suspensão da estação de trabalho (idleAction definido como SUSPEND), permitindo que a estação de trabalho salve o estado da memória e retome sem problemas quando você retornar.

Para mais informações sobre como configurar fluxos de trabalho assistidos por agentes e hooks de keep-alive, consulte Desenvolvimento otimizado para agentes.

Use 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 baseadas em Linux e executem um processo de bloqueio quando o contêiner for iniciado.

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

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

• O Cloud Workstations não exige scripts adicionais da imagem de base do Cloud Workstations.

  No entanto, é possível analisar os scripts no diretório /etc/workstation-startup.d/ em um contêiner que executa a imagem de 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 na imagem de base padrão para saber como o Cloud Workstations configura isso por padrão.

• Recomendamos que você execute o IDE ou o servidor da Web padrão na porta 80.

OGoogle Cloud fornece imagens de base padrão que podem ser usadas para criar uma imagem do contêiner totalmente personalizada.

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 estação de trabalho, você pode adotar três abordagens:

1. Atualize o Dockerfile para incluir outros recursos estáticos que você quer adicionar.
2. Adicione outros arquivos executáveis em /etc/workstation-startup.d/ para personalizar o contêiner em execução. Os arquivos nesse diretório são executados automaticamente em ordem lexicográfica na inicialização do contêiner. Portanto, é possível prefixar o 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 a inicialização do contêiner.

Observação: qualquer modificação do usuário precisa ser feita no ambiente de execução do contêiner, não no Dockerfile. Isso ocorre porque /home é montado dinamicamente no contêiner no momento da inicialização.

Exemplos de Dockerfiles personalizados

Nesta seção, mostramos exemplos de cenários e instruções para criar seus próprios Dockerfiles.

Imagem do contêiner com emacs pré-instalado

Para criar uma imagem de contêiner com o emacs pré-instalado, execute os seguintes 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 de 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 após 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.

2. Supondo que você tenha nomeado o script como 011_customize-user.sh, adicione o seguinte à imagem no Dockerfile e torne-o 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 do contêiner que define variáveis de ambiente de contêiner em sessões SSH

As variáveis de ambiente definidas na configuração ou no nível da estação de trabalho são transmitidas para subprocessos diretos usando o comando de ponto de entrada. Isso inclui o ambiente de desenvolvimento integrado 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 uma imagem de contêiner personalizada que retransmita essas variáveis de ambiente do comando de ponto de entrada do contêiner para o arquivo /etc/environment.

Para fazer isso, siga estas etapas:

1. Crie um script em /etc/workstation-startup.d/* que seja executado após 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 pelo nome da variável de ambiente pretendida.

2. Supondo que você tenha nomeado o script como 011_add-ssh-env-variables.sh, adicione o seguinte à imagem no Dockerfile e torne-o 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 permite o encaminhamento X11 para sessões SSH

O encaminhamento X11 permite iniciar aplicativos remotos e encaminhar a exibição do aplicativo para uma máquina local.

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

Veja 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

Uma versão 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 build. Para adicionar o Code OSS para Cloud Workstations a outra imagem de contêiner, use um build de vários estágios para copiar a pasta do aplicativo /opt/code-oss para a 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 para o contêiner.

Veja um exemplo de Dockerfile que copia o Code OSS para a imagem do JetBrains IntelliJ Ultimate. Em seguida, você pode interagir com qualquer 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 Cloud Workstations para desenvolvimento em Java

Para criar uma imagem de contêiner que pré-instale extensões de ambiente de desenvolvimento integrado no Code OSS para Cloud Workstations para desenvolvimento em 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

RUN chmod a+rwx -R /opt/code-oss/extensions/

Se você pré-instalar extensões, elas serão consideradas integradas. Não será possível atualizar essas extensões, e elas podem não aparecer na seção de instaladas no Marketplace de extensões do . No entanto, é possível encontrar as extensões integradas pesquisando por @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:

sudo -u user /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

Com esse método, a extensão aparece no Marketplace de extensões, e você pode fazer a atualização por lá.

Observação : também é possível fazer o download prévio dos arquivos VSIX no momento do build e usá-los no ambiente de execução para aumentar a proteção e melhorar o desempenho de inicialização.

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

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

• jetbrains-installer.sh: instalar os ambientes de desenvolvimento integrado da JetBrains
• plugin-installer.sh: instale 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 depois de iniciar a estação de trabalho.

Scripts do instalador

Para ver 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 por SSH e navegue pelos arquivos de script no diretório installer-scripts, que está localizado 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 de versão opcional do plug-in a ser instalado.
• DESTINATION-DIRECTORY: diretório opcional em que o plug-in será instalado. Se não for especificado, o diretório de trabalho será usado.
• CHECKSUM: checksum SHA-256 opcional do plug-in solicitado.
• -f: se especificado, qualquer plug-in atual será substituído.
• PLUGIN_ID: o identificador numérico obrigatório do plug-in no marketplace do JetBrains. Por exemplo, para adicionar Dart, use 6351 como PLUGIN_ID. Para adicionar o Cloud Code para IntelliJ, use 8079 como PLUGIN_ID.

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

/installer-scripts/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 estender uma imagem de base pré-configurada para ambientes de desenvolvimento integrado do 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. Use uma das seguintes abreviações de ambiente de desenvolvimento integrado:

  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 a versão fixada ou 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:

/installer-scripts/jetbrains-installer.sh clion

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

Se um diretório inicial permanente for especificado na configuração das estações de trabalho, as imagens de base do Cloud Workstations com ambientes de desenvolvimento integrado 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 o Cloud Workstations configura isso por padrão.

Estender uma imagem Docker base com o Cloud Code para IntelliJ

O snippet do Dockerfile a seguir estende uma imagem Docker base com o Cloud Code para IntelliJ, incluindo 8079 como o identificador de plug-in necessário. O exemplo também especifica 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 outras extensões de ambiente de desenvolvimento integrado no Code OSS para Cloud Workstations

Encontre outras extensões de ambiente de desenvolvimento integrado no Open VSX Registry. Também é possível encontrar o URL do arquivo .vsix copiando o URL do link de download de qualquer extensão.

Se você abrir o Marketplace de extensões em uma estação de trabalho, a opção Instalar vai aparecer em vez de Fazer o download.

Configurações padrão do Code OSS para 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, poderá definir as configurações padrão do Code OSS para Cloud Workstations adicionando um script de inicialização que grava as configurações em $HOME/.codeoss-cloudworkstations/data/Machine/settings.json.

Por exemplo, se você quiser definir o tema de cores padrão como Escuro, estenda a imagem do editor de base para incluir o seguinte script 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. Digite o seguinte comando para criar o contêiner:

docker build CUSTOM_IMAGE_FOLDER -t TARGET_IMAGE

Substituir o texto que precede o ícone editar 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.

  Por exemplo, TARGET_IMAGE pode apontar para um caminho de imagem de destino semelhante ao seguinte:

  *.pkg.dev/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 as seguintes seções:

• Como criar um repositório do Docker com o Artifact Registry.
• Convenções de nomenclatura para nomes de repositórios e imagens.

Hospedar a imagem de contêiner personalizada

Para hospedar imagens de contêiner personalizadas, recomendamos e oferecemos suporte ao 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 seção Usar uma imagem de contêiner personalizada.

Testar a imagem do 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 local.
• CONTAINER_PORT: o número da porta do contêiner.

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

Se você estiver estendendo a imagem do editor de base do Cloud Workstations, 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 comando docker run e abra localhost:8080.
• Se preferir se conectar por SSH, transmita -p 2222:22 para o comando docker run e execute ssh user@localhost -p 2222.

Usar uma imagem do 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 com o seguinte comando:

docker push TARGET_IMAGE

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

Importante: se a imagem estiver hospedada em um repositório particular, verifique se a configuração da estação de trabalho também especifica uma conta de serviço com permissões de extração no repositório.

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

Depurar problemas

Para encontrar e depurar problemas ao executar a imagem do contêiner, analise os registros de saída do contêiner das estações de trabalho em execução.

Recomendado: ajude a proteger seu pipeline de imagens

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

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

• Execute uma ferramenta de verificação de contêineres, como o Artifact Analysis, para inspecionar outras dependências adicionadas.
• Programe builds para recriar imagens semanalmente ou saiba como automatizar as recriações de imagens de contêiner.

A seguir

• Automatize as recriações de imagens de contêiner para sincronizar as atualizações de imagens de base usando o Cloud Build e o Cloud Scheduler.
• Configurar as práticas recomendadas de segurança.
• Saiba mais sobre o Artifact Analysis.