Dev Container メモ
コンテナを開発環境として使うオープン仕様
ホストOSの環境と切り離して、統一された環境を用意できる。
プロジェクトのディレクトリに .devcontainer ディレクトリとその中に devcontainer.json があることで動作する。
VSCode の場合はこれで正しいが、以下のバリエーションが規定されている。
.devcontainer.json
.devcontainer/**/devcontainer.json
Dockerfile と Docker Compose に対応している。
既存のイメージをそのまま使う場合
devcontainer.json の image で URL を指定する。
Dockerfile を使う場合
devcontainer.json の dockerFile で devcontainer.json からの相対パスで Dockerfile を指定する。(大文字小文字に注意)
Docker Compose を使う場合
devcontainer.json の dockerComposeFile で devcontainer.json からの相対パスで docker-compose.yml を指定する。配列で複数指定でき、後勝ちになる。
Dockerfile よりは docker-compose.yml を書く方が良い
Dockerfile はコンテナの中身のことしか書けない。
docker-compose.yml はコンテナと外との関係を書くことができる。
VSCode ではワークスペースをコンテナ内に取り込む必要がある。
Dev Container 内から Docker を使う方法
features に docker-in-docker, docker-from-docker が用意されている。
認識できるのは VSCode だけかも?
少なくとも GitHub Codespaces では問題なく認識された。
以下 VSCode での話
VSCode では、昔は Remote Container と呼ばれていた。
VSCode の場合、Docker と連係して動作する。このため Docker がインストールされていないとコケる。
Windows の場合は Docker Desktop でなければならない。
Dev Container 用のイメージが用意されている。
VSCode 本体と指定する環境との両方が使えるように調整されている。
とにかくVSCodeで devcontainer を使いたい場合
Ctrl+Shift+P でコマンドパレットを起動
Dev Containers: New Dev Container... を選択すると、使えるイメージの一覧が表示される。
全部入りを選ぶなら、Default Linux Universal (注:糞重い)
"image": "mcr.microsoft.com/devcontainers/universal:2-linux" (2024-06-09 時点)
GitHub codespace のデフォルトコンテナと同じものが入っているらしい。
この場合、Dev Container のコンテナの中にすべて閉じてしまう。
これはとても使い勝手が良くないので、ここで作られた devcontainer.json の定義をコピーして(Windows であれば WSL 上)で作り直すのが良い。
例えば、devcontainer.json の定義が壊れている時に直すことができない。
ファイルをコンテナ外から見ることができない。(ボリュームをマウントすれば見られるが、マウントするにはまた別のコンテナが必要)
Windows で単に設定すると、Windows 側の gpg と接続される。
ファイルはコンテナの別ボリュームの中に作られる。
Default Linux Universal の場合、universalというボリュームが作られる。
VSCode が動作する Dev Container イメージの作り方は以下にあり(古い?)
デフォルトでコンテナのユーザーは vscode になっている。このため、vscode がコンテナのユーザーに含まれていないとコケる。
このユーザーは devcontainer.json の remoteUser で設定できる。
Windows の場合、可能な限り WSL 上で Dev Container を作ること。
Windows のフォルダで作るとWSLとの変換のため(?)I/Oが途轍もなく遅くなる。
Windows のフォルダで作るとコンテナとユーザー権限が食い違うため git, gpg が通らなくなる。
WSL であれば、git がそのまま使える。
uid, gid が 1000 で共通になるため。
Windows のディレクトリでそのまま使うと、ユーザー権限が食い違うため、妙なことになるので注意。
WSL であれば、gpg-agent により自動的に gpg が接続される。
WSL 上の gpg に鍵をインポートするとよい。
WSL の方で、pinentry-gtk2 をインストールしておけば、GUIでパスフレーズの問い合わせをしてくれる。
完全に独立した Dev Container (コンテナしかない方式)だとこれができないので使い勝手が良くない。
コンテナ側で git を初期化する。
https://gyazo.com/45220f489672251df0b3ed97d024cb4a
The git repositories in the current folder are potentially unsafe as the folders are owned by someone other than the current user.
root ユーザーでパーミッションが 777(rwxrwxrwx)になっているためと思われる。
https://gyazo.com/8c7a2562fa10a9f99bed05095a8a075a
とりあえず、今のところは Manage Unsafe Repository としておく。
ホスト側ファイルシステムにファイルを配置して bind する方式と、コンテナのボリューム内にファイルを配置する方法の2つがある。
Windows の場合、Windows のファイルシステム上に置くのと、WSL のファイルシステム上に置くのとの2通りができてしまう。
コンテナのボリューム内にファイルを配置する方法
そちらの方がパフォーマンスが良い。
Dev Container でコマンドを実行するタイミング
table:command
Property
initializeCommand
onCreateCommand
updateContentCommand
postCreateCommand
postStartCommand
postAttachCommand
関連