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

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 プロファイルを変更することもできます。

事前構成済みの Secure 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）を変更します。これらのキーワードの詳細については、AddressFamily と X11Forwarding に関する OpenBSD のウェブページをご覧ください。

必要な修正を行う 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

Cloud Workstations 用 Code OSS を別のコンテナ イメージにコピーする

マルチステージ ビルドでは、Dockerfile で複数の FROM ステートメントを使用できます。各 FROM 命令は、異なるベースを使用でき、ビルドステージ間でアーティファクトをコピーできます。Cloud Workstations 用 Code OSS を別のコンテナ イメージに追加するには、マルチステージ ビルドを使用して、アプリケーション フォルダ /opt/code-oss をイメージにコピーします。コンテナの起動時に Code OSS for Cloud Workstations を起動する場合は、スクリプト /etc/workstation-startup.d/110_start-code-oss.sh をコンテナにコピーします。

以下に、Code OSS を JetBrains IntelliJ Ultimate イメージにコピーする Dockerfile のサンプルを示します。どちらの IDE も操作できます。

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"]

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 拡張機能については、Open VSX Registry をご覧ください。.vsix ファイルの URL は、拡張機能の [ダウンロード] リンクから 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 環境変数を更新することもできます。

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

• 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 について詳細を確認する。