Dev container featuresについて調べてみる
Dev container featuresについて調べてみる
devcontainer.json
に以下の様に設定すると、指定したツール(ここではgithub-cli)が導入された状態のコンテナを利用できる仕組みのようだ。
"features": {
"github-cli": "latest"
}
現在(2022年1月9日現在)のpreview段階では、上記のように指定して導入できるツールはscript libraryに記載のあるツールに限られそう。
自身で任意のツール導入について試したいときは、自分でリポジトリを用意して、以下の様に指定する必要がある。リポジトリのテンプレートはgithub.com/microsoft/dev-container-features-templateにある。
"features": {
"your-github-id-or-org/your-repository/feature-name@v0.0.1": "latest"
}
OCIレジストリへの参照以外の方法だと、2022/8現在では、tarballへのHTTPS URLの指定またはローカルファイルへの指定ができるとのこと
"features": {
"https://github.com/user/repo/releases/devcontainer-feature-go.tgz": {
"optionA": "value"
},
"./myGoFeature": {
"optionA": true,
"optionB": "hello",
"version" : "1.0.0"
}
}
2022/8/18現在、自作のfeatureをテンプレートとして使うのには以下が良さそう。
実際にfeatureをつくって動作することは確認できた。
つくったfeatureはAWS CLI v2をインストールするというもの。
テンプレートのGithub ActionsにArtifactを作成する処理があった。
このAritifactをRemote Containersでプロジェクトを開いたときにダウンロード、これに含まれるinstall.shを実行するようなDockerfileが内部的に作成され、Dockerビルドしているようだ。
以下は、Remote Containersでプロジェクトを開いたときの出力ログの抜粋。
=> [internal] load .dockerignore 0.0s
=> => transferring context: 2B 0.0s
=> [internal] load metadata for mcr.microsoft.com/vscode/devcontainers/t 0.0s
=> CACHED [1/4] FROM mcr.microsoft.com/vscode/devcontainers/typescript-n 0.0s
=> [internal] load build context 0.1s
=> => transferring context: 247.09kB 0.0s
=> [2/4] COPY . /tmp/build-features/ 0.0s
=> [3/4] RUN cd /tmp/build-features/local-cache && chmod +x ./install.sh 0.4s
=> [4/4] RUN cd /tmp/build-features/github-nmemoto-dev-container-feature 0.7s
=> => # Activating feature 'awscli'
=> => # Downloading AWS CLI for latest...
[+] Building 1.5s (7/8)
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 421B 0.0s
=> [internal] load .dockerignore 0.0s
[+] Building 1.6s (7/8)
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 421B 0.0s
=> [internal] load .dockerignore 0.0s
[+] Building 1.8s (7/8)
=> [internal] load .dockerignore 0.0s
=> => transferring context: 2B 0.0s
=> [internal] load metadata for mcr.microsoft.com/vscode/devcontainers/typescript-node:0- 0.0s
[+] Building 13.6s (9/9) FINISHED
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 421B 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 2B 0.0s
=> [internal] load metadata for mcr.microsoft.com/vscode/devcontainers/typescript-node:0- 0.0s
=> CACHED [1/4] FROM mcr.microsoft.com/vscode/devcontainers/typescript-node:0-12 0.0s
=> [internal] load build context 0.1s
=> => transferring context: 247.09kB 0.0s
=> [2/4] COPY . /tmp/build-features/ 0.0s
=> [3/4] RUN cd /tmp/build-features/local-cache && chmod +x ./install.sh && ./install.sh 0.4s
=> [4/4] RUN cd /tmp/build-features/github-nmemoto-dev-container-features-aws-cli-latest 8.7s
=> exporting to image 4.3s
=> => exporting layers 4.3s
=> => writing image sha256:e6fc96da0e3431e71613ae9850a6b2764c50808df4fa0c3d56624f3612cb59 0.0s
=> => naming to docker.io/library/vsc-vscode-remote-containers-custom-feature-test-876237 0.0s
上記のDockerビルドはdevcontainer-cliがしているようだ
Dockerイメージのライフサイクルとは別で、導入したいツールの任意バージョンを個別に導入できるのがこの機能の利点だと思う。
より汎用性を高めるなら、ツール導入やその過程でOS標準のパッケージ管理ツールを使わないといけないケースがほとんどのため、alpineやredhat系のOS用の処理も別に作らないといけない。
ただ、github.com/microsoft/vscode-dev-containersで管理されているものはdebianベースのDockerイメージを使っているため、ほとんどのケースであればそれだけ考慮して作ればよいだろう。
以下に書いてあるとおり、CIでイメージをDocker Registryにプッシュさせといて、ローカルはそこからpullしてくるのが一番早そう。Dev Containerはデブコンテナーなのでせめてビルド時間を小さくするこの対応を可能ならするのが良さそう。
Dev container featuresの指定は以下のようになる模様
Development Container Features用の新しいリポジトリが公開されている
新しいDevelopment Container用のDocker Imageが公開された。
README.mdやsrc内の各機能のdevcontainer.jsonを見るに、featuresを含んだイメージとして作成している模様。