codespace でのコンテナーのリビルド

開発コンテナーのリビルドについて

codespace で作業する場合、開発環境は仮想マシン上で実行される Docker コンテナーです。 codespace 内から開発コンテナー構成に変更を加え、それらの変更を現在の codespace に適用する場合は、コンテナーをリビルドする必要があります。

既定では、開発コンテナーをリビルドすると、GitHub Codespaces によって、コンテナーの以前のビルドからキャッシュされたイメージを再利用することでビルドプロセスが高速化されます。これは通常、次の理由により、開発コンテナー構成に対する変更を実装する最も簡単な方法です。

GitHub Codespaces では、コンテナーレジストリから再度プルするのではなく、キャッシュ内のイメージを再利用できます。
開発コンテナーの機能や Dockerfile 命令など、コンテナーの構築方法を定義する開発コンテナー構成の一部が、キャッシュ内のイメージレイヤーに既に実装されている可能性があるため、これらのプロセスが再度実行されるのを待つ必要はありません。 (ただし、onCreateCommand など、コンテナーの構築後に実行される構成内のコマンドは、再度実行されます。)

場合によっては、コンテナーの完全なリビルドを実行することが必要になる場合があります。完全なリビルドにより、GitHub Codespaces はキャッシュからすべての Docker コンテナー、イメージ、ボリュームをクリーンアップし、新しくプルされたイメージを使用してコンテナーを再構築します。構成で定義されているすべてのセットアップが再度実行され、新しいイメージレイヤーが生成されます。次のような状況で、キャッシュされたイメージを使用してコンテナーを何度もリビルドした後、完全なリビルドを実行できます。

構成で定義されているセットアップがキャッシュされたイメージに依存しないようにし、構成に基づいて新しい codespace が作成されるときに必要に応じて実行されるようにしたい。たとえば、依存関係が最後に codespace にプルされてから、基本イメージから削除されている可能性があります。
たとえば、ディスク領域が不足している場合や、ストレージ料金を最小限に抑える場合など、キャッシュで使用されるディスク領域を解放したい。基本イメージを複数回変更した場合、構成に対して多数の反復的な変更を行った場合、または Docker Compose を使って複数のコンテナーを実行している場合は、イメージキャッシュで大量のディスク領域が使用されている可能性があります。

コンテナーのリビルド

コンテナーは VS Code の Web クライアントまたはデスクトップアプリケーションの codespace 内でリビルドできます。GitHub CLI を使用することもできます。

VS Code Web クライアントまたはデスクトップアプリケーションで開発コンテナーをリビルドする

Shift+Command+P (Mac) または Ctrl+Shift+P (Windows/Linux) を使用して、VS Code Command Palette にアクセスします。
「Rebuild」と入力し、[Codespaces: コンテナーのリビルド] を選択します。
開いた確認ダイアログで [リビルド] または [完全なリビルド] を選択します。
開発コンテナー構成を変更してコンテナーエラーが発生した場合、codespace は回復モードで動作し、エラーメッセージが表示されます。
- 作成ログを確認してエラーを診断するには、 View creation log をクリックします。
- ログで識別されたエラーを修正するには、devcontainer.json ファイルを更新します。
- 変更を適用するには、コンテナーをリビルドします。

GitHub CLI を使用して開発コンテナーをリビルドする

VS Code の外部 (たとえば、GitHub や JetBrains IDE など) で開発コンテナーの構成を変更した場合は、GitHub CLI を使って既存の codespace の開発コンテナーをリビルドできます。

ターミナルで、次のコマンドを入力します。
```
gh codespace rebuild
```
codespace が一覧表示されます。
キーボードの方向キーを使って必要な codespace を強調表示してから、Enter キーを押します。

GitHub CLI を使用して完全なリビルドを実行するには、gh codespace rebuild --full コマンドを使用します。

リビルドでのデータの保持

codespace を作成すると、リポジトリが codespace 内の /workspaces ディレクトリに複製されます。これは、コンテナーにマウントされる永続的なディレクトリです。ファイルの編集、追加、削除など、このディレクトリ内で行った変更は、codespace を停止して開始するとき、および codespace 内のコンテナーをリビルドするときに保持されます。

/workspaces ディレクトリの外部では、codespace のビルドに使用される開発コンテナーイメージによって異なる Linux ディレクトリ構造が codespace に含まれています。 /workspaces ディレクトリ外部で、ファイルを追加したりファイルに変更を加えたりすることができます。たとえば、新しいプログラムをインストールしたり、~/.bashrc のようなファイルにシェル構成を設定したりすることができます。ルート以外のユーザーは、特定のディレクトリへの書き込みアクセス権を自動的に持っていない場合がありますが、ほとんどのイメージでは、これらのディレクトリへの sudo コマンドを使ったルートアクセスが許可されます。

/workspaces の外部では、/tmp ディレクトリを除き、codespace 内のディレクトリはコンテナーのライフサイクルに関連付けられます。つまり、codespace を停止して開始した場合、加えた変更は保持されますが、コンテナーをリビルドした場合は保持されません。

リビルドで /workspaces ディレクトリの外部にファイルを保持する場合は、コンテナー内の目的の場所に、持続させるディレクトリへのシンボリックリンクを作成できます。たとえば、/workspaces/.devcontainer ディレクトリ内に、再構築先でも持続される config ディレクトリを作成できます。その後、config ディレクトリとその内容を devcontainer.json ファイルの postCreateCommand としてシンボリックリンクすることができます。

{
    "image": "mcr.microsoft.com/devcontainers/base:alpine",
    "postCreateCommand": "chmod +x .devcontainer/postCreate.sh && .devcontainer/postCreate.sh"
}

以下の例の postCreate.sh ファイルでは、config ディレクトリの内容がホームディレクトリにシンボリックリンクされています。

#!/bin/bash
ln -sf $PWD/.devcontainer/config $HOME/config && set +x

参考資料

「開発コンテナーの概要」