コンテナ イメージをカスタマイズする

Cloud Workstations によって提供される事前構成されたベースイメージには、IDE、基本的な Linux ターミナル、言語ツール、sshd サーバーを備えた最小限の環境のみが含まれています。特定の開発ユースケースの環境設定を迅速に進めるには、カスタム イメージ コンテナ イメージを作成して、これらのベースイメージを拡張してツールや依存関係をプリインストールし、自動化スクリプトを実行します。

カスタム コンテナ イメージの場合は、Cloud Workstations のベースイメージが更新されたときに、これらのイメージを自動的に再ビルドするパイプラインを設定するだけでなく、Artifact Analysisのようなコンテナ スキャンツールを実行して追加した依存関係を検査することをおすすめします。カスタム イメージに追加されたカスタム パッケージと依存関係の保守と更新は、お客様の責任で行っていただく必要があります。

準備

1. Docker などのコンテナ イメージをビルドし、Google Cloud CLI を使用してイメージを Artifact Registry（または Container Registry）に push するツールを備えたマシンが必要です。これらの手順を実行するには、このツールがプリインストールされている Cloud Workstations または Cloud Shell エディタを使用できます。

   注: Container Registry は非推奨で、提供終了となります。2024 年 1 月 8 日より前に Container Registry を使用していない組織では、デフォルトで Artifact Registry に新しい gcr.io リポジトリがホストされます。2024 年 5 月 15 日以降、以前に Container Registry を使用していない Google Cloud プロジェクトでは、Artifact Registry で gcr.io ドメインのイメージのホスティングと管理のみがサポートされます。

   Container Registry は 2025 年 3 月 18 日に提供終了となる予定です。サポート終了の詳細については、Container Registry のサポート終了をご覧ください。

2. サポート対象のベースイメージのリスト（us-central1-docker.pkg.dev/cloud-workstations-images/predefined/code-oss:latest など）から、使用するベースイメージを選択します。

   また、独自のコンテナ イメージを使用する手順に沿って、独自のコンテナ イメージを使用することも、外部コンテナ イメージを使用することもできます。

3. 以下の例に示すように、このフォルダ内に CUSTOM_IMAGE_FOLDER などのフォルダと選択したベースイメージを拡張する Dockerfile を作成します。

Cloud Workstations のベースイメージの構造

Cloud Workstations のベースイメージは、次の定義済み構造を共有します。

• ベースイメージのエントリポイント ファイルは /google/scripts/entrypoint.sh に設定されます。

• 起動時に、ベースイメージは辞書順に /etc/workstation-startup.d/* でファイルを実行し、ワークステーション環境を初期化します。

  ファイルとその動作は次のとおりです。

  • 000_configure-docker.sh: ワークステーション内で Docker を構成して実行します。

  • 010_add-user.sh: Cloud Workstations にデフォルト ユーザーを作成します。

    永続ディスクはコンテナに動的にアタッチされるため、Dockerfile 内 ではなく、ワークステーションの起動時にユーザーを追加する必要があります。

  • 020_start-sshd.sh: コンテナ内で sshd サービスを開始します。

  • 110_start-$IDE.sh: イメージの IDE を起動します。

• Cloud Workstations は、Docker イメージを /home/.docker_data のホーム ディレクトリに保存するため、イメージはセッション間で保持されます。

ワークステーションの起動時に機能を追加するには、/etc/workstation-startup.d/ ディレクトリにスクリプトを追加します。

• このディレクトリ内のスクリプトはデフォルトで root として実行されます。スクリプトを別のユーザーとして実行するには、runuser コマンドを使用します。

• スクリプトは辞書順に実行されるため、スクリプトの先頭に 200 より大きい 3 桁の数字を付けることをおすすめします。

ホーム ディレクトリの変更

ワークステーション構成で永続的なホーム ディレクトリが指定されている場合（デフォルトの動作）、ホーム ディレクトリをサポートする永続ディスクが実行時にコンテナに動的に接続されます。このプロセスにより、コンテナ イメージのビルド時に /home ディレクトリに加えられた変更が上書きされます。

更新を維持するには、コンテナ ランタイムに /home ディレクトリを変更します。そのためには、/etc/workstation-startup.d ディレクトリにスクリプトを追加するか、/etc/profile.d ディレクトリにユーザーごとの構成を追加します。このプロセスを高速化するには、コンテナの起動をブロックしないように、セットアップ スクリプトをバックグラウンド プロセスとして実行（コマンドの最後にアンパサンド & を追加）することを検討してください。

コンテナ ランタイムに移行する必要があるビルド時間構成の例:

• ユーザーごとの git 構成
• git リポジトリがホーム ディレクトリにクローンされる
• ユーザー ディレクトリの直接構成（$HOME/.config ディレクトリへのファイルの配置など）
• ユーザーの作成

ユーザーの作成と変更

Persistent Disk はランタイムにコンテナに動的にアタッチされるため、Dockerfile 内ではなく、ワークステーションの起動時にユーザーを追加する必要があります。ユーザーを変更または追加するために、/etc/workstation-startup.d/010_add-user.sh を更新するか、起動時に実行する独自のスクリプトを作成することをおすすめします。

また、/etc/profile.d 内のファイルを更新して、ユーザーのデフォルトの bash プロファイルを変更することもできます。

事前構成済みのセキュア APT キーを更新する

Cloud Workstations のベースイメージには、Secure APT を使用してさまざまなサードパーティ リポジトリから取得した多数のツールがプリインストールされています。インストール プロセスの一環として、リポジトリ オーナーによって提供される公開鍵は gpg を使用してインポートされ、/usr/share/keyrings/ の下の個々のファイルに配置されます。これらのファイルは、/etc/apt/sources.list.d/ 内の対応する list ファイルから参照されます。これにより、apt は特定のリポジトリを操作するときに、そのリポジトリの整合性を検証できます。

サードパーティ リポジトリのオーナーが、リポジトリの整合性検証に使用する公開鍵を変更することがあります。これにより、操作時にエラーが apt で表示される可能性があります。この潜在的な問題を解決するには、/google/scripts/refresh-preinstalled-apt-keys.sh を使用します。これは、プリインストールされた公開鍵の最新バージョンを取得して再インポートします。

インストール済み IDE のバージョンを一覧表示する

いくつかの Cloud Workstations ベースイメージには、IDE がプリインストールされています。利便性のためには、含まれている　/google/scripts/preinstalled-ide-versions.sh スクリプトを参照してください。これは、イメージにインストールされた IDE の名前とバージョン情報を一覧表示します。

sudo root 権限をオフにする

デフォルトのワークステーション ユーザーには、これらのコンテナに対する sudo root アクセス権限があります。Docker コンテナへのルートアクセスをオフにするには、ワークステーション構成の作成時に CLOUD_WORKSTATIONS_CONFIG_DISABLE_SUDO 環境変数を true に設定します。

ワークステーション構成の作成時に Google Cloud コンソールでこの環境変数を設定するには、次の手順を行います。

1. ワークステーション構成の作成時に、基本情報の構成とマシン構成を完了します。
2. [環境のカスタマイズ] ダイアログで、[コンテナの詳細オプション] セクションを展開し、[環境変数] を選択します。
3. [変数を追加] をクリックします。
4. 値として「CLOUD_WORKSTATIONS_CONFIG_DISABLE_SUDO」と「true」を入力します。

注: ユーザーが Docker コンテナから移動できる場合、基盤となる VM に対する root 権限を取得できる場合があります。

独自のコンテナ イメージを使用する

また、独自のコンテナ イメージを使用することも、コンテナベースの起動時に Linux ベースのコンテナである外部コンテナ イメージを使用することもできます。

Dockerfile を設定する場合、ENTRYPOINT 命令は、コンテナをすぐに終了するのではなく、実行を継続するように、sleep infinity などのブロック プロセスを実行する必要があります。また、ワークステーション構成で、config.container.args フィールドを設定してブロッキング プロセスを指定することもできます。

独自のコンテナ イメージを使用する場合は、次の点に注意してください。

• Cloud Workstations では、Cloud Workstations のベースイメージから追加のスクリプトは必要ありません。

  ただし、Cloud Workstations のベースイメージを実行しているコンテナ内の /etc/workstation-startup.d/ ディレクトリ内のスクリプトを確認できます。ファイル名は各スクリプトの実行内容を表します。

• コンテナ内で SSH サーバーを実行することをおすすめします。Cloud Workstations のデフォルトの設定については、デフォルトのベースイメージの /etc/workstation-startup.d/020_start-sshd.sh をご覧ください。

• デフォルトの IDE またはウェブサーバーをポート 80 で実行することをおすすめします。

Cloud Workstations ベースイメージの拡張

Cloud Workstations のベースイメージを拡張してワークステーション環境用のカスタム イメージを作成する場合、次の 3 つの方法を使用できます。

1. Dockerfile を更新して、追加する静的アセットを含めます。
2. /etc/workstation-startup.d/ の下に実行可能ファイルを追加して、実行中のコンテナをカスタマイズします。このディレクトリの下のファイルは、コンテナ起動時に辞書順に自動的に実行されるため、ワークステーションの起動時にファイル名を必要に応じて実行することもできます。
3. Dockerfile 内の ENTRYPOINT をオーバーライドして、コンテナの起動を完全にカスタマイズします。

注: ユーザーの変更は、Dockerfile ではなくコンテナ ランタイムで実行する必要があります。これは、起動時に /home がコンテナに動的にマウントされるためです。

カスタム Dockerfile のサンプル

このセクションでは、独自の Dockerfile を作成するためのシナリオと手順の例を示します。

emacs がプリインストールされたコンテナ イメージ

emacs がプリインストールされたコンテナ イメージを作成するには、次のコマンドを実行します。

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

RUN sudo apt update
RUN sudo apt install -y emacs

ユーザー カスタマイズを含むコンテナ イメージ

次の手順に沿って、コンテナ イメージをカスタマイズします。

1. 010_add-user.sh の後に実行される /etc/workstation-startup.d/* にスクリプトを作成します（例: 011_customize-user.sh）。

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

   $GROUP を新しいグループ名に、$USERNAME をユーザーのユーザー名に置き換えます。

2. スクリプトに 011_customize-user.sh という名前を付けた場合、Dockerfile でイメージに以下を追加して実行可能にします。

   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
   

SSH セッションでコンテナ環境変数を設定するコンテナ イメージ

ワークステーション構成またはワークステーション レベルで設定された環境変数は、entrypoint コマンドを使用して直接サブプロセスに渡されます。これには、事前構成されたベースイメージの IDE が含まれます。ただし、SSH セッションはエントリポイントの子プロセスではなく、これらのカスタム環境変数は設定されていません。

これらの環境変数を SSH セッションで設定するには、これらの環境変数をコンテナのエントリポイント コマンドから /etc/environment ファイルにリレーするカスタム コンテナ イメージを設定します。

これを行う手順は次のとおりです。

1. 010_add-user.sh の後に実行される /etc/workstation-startup.d/* にスクリプトを作成します（例: 011_add-ssh-env-variables.sh）。

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

   CUSTOM_ENV_VAR は、目的の環境変数名に置き換えます。

2. スクリプトに 011_add-ssh-env-variables.sh という名前を付けた場合、Dockerfile でイメージに以下を追加して実行可能にします。

   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
   

SSH セッションの X11 転送を有効にするコンテナ イメージ

X11 転送を使用すると、リモート アプリケーションを起動してアプリケーション表示をローカルマシンに転送できます。

X11 転送を有効にするコンテナ イメージを作成するには、（X11 転送を許可する）X11Forwarding yes と（IPv4 のみが使用されるようにする）AddressFamily inet を追加して、Cloud Workstations ベースイメージで提供されている OpenSSH デーモン構成ファイル（/etc/ssh/sshd_config）を変更します。これらのキーワードの詳細については、OpenBSD の AddressFamily と X11Forwarding のウェブページをご覧ください。

必要な修正を行う Dockerfile の例を次に示します。

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

Java 開発用の Cloud Workstations 用 Code OSS に IDE 拡張機能をプリインストールするコンテナ イメージ

ビルド時に Java 開発用の Cloud Workstations 用 Code OSS に IDE 拡張機能をプリインストールするコンテナ イメージを作成するには、次のコマンドを実行します。

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

拡張機能をプリインストールすると、組み込みの拡張機能と見なされます。これらの拡張機能は更新できず、 拡張機能 Marketplace のインストール済みセクションに表示されない場合があります。ただし、組み込みの拡張機能は @builtin で検索して見つけることができます。

起動時に拡張機能をインストールする別の方法として、起動スクリプトを実行する方法もあります。たとえば、/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

この方法を使用すると、拡張機能は 拡張機能 Marketplace に表示され、そこから更新できます。

注: ビルド時に VSIX ファイルを事前にダウンロードし、実行時に使用して、保護を追加し、起動パフォーマンスを向上させることもできます。

JetBrains IDE とプラグインをベースイメージにインストールする

ワークステーション構成用に Docker イメージをカスタマイズする場合は、Cloud Code for IntelliJ などの JetBrains IDE とプラグインをベースイメージにインストールできます。JetBrains プロダクトの Cloud Workstations ベースイメージには、次のスクリプトが含まれています。

• jetbrains-installer.sh: JetBrains IDE をインストールする
• plugin-installer.sh: Cloud Code for IntelliJ などのプラグインをインストールする

これらのスクリプトは、必要に応じてベースイメージのカスタマイズ、起動スクリプトによる呼び出し、ワークステーション起動後の実行に使用します。

インストーラのスクリプト

jetbrains-installer.sh スクリプトと plugin-installer.sh スクリプトのソースファイルを表示するには、JetBrains の事前定義されたイメージの 1 つを使用するワークステーション構成を使用してワークステーションを起動して接続し（JetBrains Gateway か SSH 経由）、ルート ディレクトリの installer-scripts ディレクトリにあるスクリプト ファイルを参照します。

このスクリプトはコンテナのビルド時に実行することをおすすめします。すでに開始されているワークステーションで実行しないでください。

プラグイン インストーラ スクリプトを使用する

plugin-installer.sh スクリプトの構文は次のとおりです。

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

次のように置き換えます。

• VERSION: インストールするプラグインのバージョン番号（省略可）。
• DESTINATION-DIRECTORY: プラグインをインストールするオプションのディレクトリ。指定しない場合、作業ディレクトリが使用されます。
• CHECKSUM: リクエストされたプラグインのオプションの SHA-256 チェックサム。
• -f: 指定すると、既存のプラグインが上書きされます。
• PLUGIN_ID: JetBrains マーケットプレイスの必須の数値プラグイン ID。たとえば、Dart を追加するには、PLUGIN_ID として 6351 を使用します。Cloud Code for IntelliJ を追加するには、PLUGIN_ID として 8079 を使用します。

たとえば、最新バージョンの Dart プラグインを IntelliJ にインストールするには、次のコマンドを実行します。

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

JetBrains インストーラ スクリプトを使用する

JetBrains IDE 用の事前構成されたベースイメージを拡張するときは、JetBrains インストーラ スクリプトを使用することをおすすめします。

jetbrains-installer.sh スクリプトの構文は次のとおりです。

jetbrains-installer.sh IDE [ pinned|latest ]

次のように置き換えます。

• IDE: インストールする JetBrains IDE。次のいずれかの IDE の略語を使用する必要があります。

  IDE	プロダクトがインストールされました
  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: 省略可 - 固定または最新バージョンの IDE を使用します。デフォルトは latest です。

たとえば、Clion の最新バージョンをインストールするには、次のコマンドを実行します。

jetbrains-installer.sh clion

JetBrains IDE 構成ファイルをカスタマイズする

ワークステーションの構成で永続的なホーム ディレクトリが指定されている場合、JetBrains IDE を使用する Cloud Workstations のベースイメージは、$IDE.vmoptions 構成ファイルと $IDE.properties 構成ファイルを自動的に保持します。これらのファイルのデフォルトの場所をオーバーライドするには、CLOUD_WORKSTATIONS_JETBRAINS_PERISTED_CONFIG_DIR 環境変数を指定します。

詳細については、任意の JetBrains ベースイメージの /etc/workstation-startup.d/120_persist-jetbrains-configs.sh を参照して、Cloud Workstations がこれをデフォルトでどのように設定するかを確認してください。

Cloud Code for IntelliJ で Docker のベースイメージを拡張する

次の Dockerfile スニペットは、必要なプラグイン ID として 8079 を含めることで、Cloud Code for IntelliJ で Docker のベースイメージを拡張します。この例では、バージョン番号として version 22.9.3-222、宛先ディレクトリとして /opt/ideaIU/plugins/、チェックサムとして 89628279ed9042c526a81facc09bf53f8fb8b83b4595b0d329d94c1611e0c379 を指定することもできます。

...
# 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
...

追加の IDE 拡張機能を Cloud Workstations 用 Code OSS にインストールする

その他の IDE の拡張機能については、VSX Registry を開くをご覧ください。また、拡張機能の [ダウンロード] リンクから URL をコピーして、.vsix ファイルの URL を確認することもできます。

ワークステーションから 拡張機能 Marketplace を開くと、[ダウンロード] の代わりに [インストール] ボタンが表示されます。

Cloud Workstations 用 Code OSS のデフォルト設定

Cloud Workstations 用 Code OSS の設定の保存の詳細については、設定をカスタマイズするをご覧ください。

ワークステーション構成で永続的なホーム ディレクトリを指定する場合は、設定を $HOME/.codeoss-cloudworkstations/data/Machine/settings.json に書き込む起動スクリプトを追加することで、Cloud Workstations 用 Code OSS のデフォルト設定を構成できます。

たとえば、デフォルトのカラーテーマをダークに設定する場合は、ベースエディタ画像を拡張して /etc/workstation-startup.d/150_default-ide-color-theme.sh に次のスクリプトを追加します。

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

カスタム コンテナ イメージをビルドする

Docker コマンドの詳細については、Docker リファレンスをご覧ください。 次のコマンドを入力して、コンテナをビルドします。

docker build CUSTOM_IMAGE_FOLDER -t TARGET_IMAGE

編集 編集アイコンの前のテキストを置き換えると、このページの他の例が更新されますのでご注意ください。

次のように置き換えます。

• CUSTOM_IMAGE_FOLDER: カスタム イメージを保存するために作成したフォルダのパス。

• TARGET_IMAGE: Artifact Registry（または Container Registry）のイメージへのパス。

  たとえば、TARGET_IMAGE は次のいずれかのパスのようなターゲット イメージのパスを指します。

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

  * は、必要に応じてリージョン名と追加の識別子に置き換えます。

  注: Container Registry は非推奨で、提供終了となります。2024 年 1 月 8 日より前に Container Registry を使用していない組織では、デフォルトで Artifact Registry に新しい gcr.io リポジトリがホストされます。2024 年 5 月 15 日以降、以前に Container Registry を使用していない Google Cloud プロジェクトでは、Artifact Registry で gcr.io ドメインのイメージのホスティングと管理のみがサポートされます。

  Container Registry は 2025 年 3 月 18 日に提供終了となる予定です。サポート終了の詳細については、Container Registry のサポート終了をご覧ください。

リポジトリを指すように CLOUD_WORKSTATIONS_CUSTOM_IMAGE 環境変数を更新することもできます。

Docker イメージを Artifact Registry に保存する方法の詳細については、次のセクションをご覧ください。

• Artifact Registry で Docker リポジトリを作成する方法。
• リポジトリとイメージの名前の命名規則。

カスタム コンテナ イメージをホストする

カスタム コンテナ イメージをホストするために、Google では Artifact Registry を推奨し、サポートしています。GitHub や他のパブリック リポジトリ、プライベート リポジトリを使用すると、Cloud Workstations が想定どおりに動作しない可能性があります。詳細については、カスタム コンテナ イメージを使用するの重要な注意事項をご覧ください。

カスタム コンテナ イメージをテストする

コンテナのビルドが完了したら、次のコマンドを使用してテストできます。

docker run --privileged -p LOCAL_PORT:CONTAINER_PORT TARGET_IMAGE

以下を置き換えます。

• LOCAL_PORT: ローカルポート番号
• CONTAINER_PORT: コンテナのポート番号

たとえば、LOCAL_PORT:CONTAINER_PORT を 8080:80 に置き換えて、ローカルで使用するポート 8080 と、コンテナで使用する 80 を割り当てます。

Cloud Workstations のベースエディタ イメージを拡張する場合は、docker コマンドを実行してから、ローカル ブラウザからワークステーションに接続するか、ssh を実行してコンテナに接続してワークステーション イメージをテストします。

• ブラウザ経由で接続している場合は、-p 8080:80 を docker run コマンドに渡してから、localhost:8080 を開きます。
• SSH 経由で接続する場合は、必ず -p 2222:22 を docker run コマンドに渡してから、ssh user@localhost -p 2222 を実行してください。

カスタム コンテナ イメージを使用する

ローカルでビルドしてテストした後にカスタム コンテナ イメージを使用するには、次のコマンドを使用してコンテナを Artifact Registry（または Container Registry）に push します。

docker push TARGET_IMAGE

これで、作成して push したコンテナ イメージを使用してワークステーション構成を作成できるようになりました。

重要: イメージがプライベート リポジトリでホストされている場合は、ワークステーション構成でリポジトリに対する pull 権限を持つサービス アカウントも指定してください。

詳細については、Artifact Registry で Docker リポジトリを作成するをご覧ください。

問題のデバッグ

コンテナ イメージの実行に関する問題を見つけてデバッグするには、実行中のワークステーションのコンテナ出力ログを確認します。

推奨: イメージ パイプラインの保護を支援する

カスタム イメージに追加されたカスタム パッケージと依存関係の保守と更新は、お客様の責任で行っていただく必要があります。

カスタム イメージを作成する場合は、次のことをおすすめします。

• Cloud Workstations のベースイメージが更新されたときに、これらのイメージを自動的に再構築することで、イメージ パイプラインを保護します。

• Artifact Analysis などのコンテナ スキャンツールを実行して、追加した依存関係を検査する。

• イメージを毎週再ビルドするようにビルドをスケジュールするか、コンテナ イメージの再ビルドを自動化する方法を確認します。

次のステップ

• Cloud Build と Cloud Scheduler を使用してベースイメージの更新を同期するため、コンテナ イメージの再ビルドを自動化する。
• セキュリティのベスト プラクティスを設定する。
• Artifact Analysis の詳細を確認する。