開発環境

新しい言語を触ってみようとするたびに、パソコンに何かが積み上がっていく。Python の版をもう一つ、Node.js をもう一つ、ついでにデータベースのクライアントも。数か月たつと、どれが何のために入れたものか分からなくなり、消してよいのかどうかも判断できなくなる。私の作業用パソコンも、しばらくそういう状態が続いていた。 VS Code の Dev Containers は、この積み上げを手元のパソコンではなく Docker のコンテナの中で起こすための仕組みだ。言語の処理系やコマンドはコンテナに入れ、エディターの見た目や操作はいつもの VS Code のまま使う。要らなくなったらコンテナごと捨てればよく、パソコン本体には何も残らない。設定は devcontainer.json という1枚のファイルに書かれるので、別のパソコンでも同じ環境を作り直せる。 この記事では、Dev Containers が何をどこに置く仕組みなのかを確かめたうえで、最小の4行の設定ファイルから動かし、道具を少しずつ書き足していく順番を追っていく。最後に、Windows で使うときにつまずきやすい点もまとめておく。 Dev Containersは、エディターの中身だけをコンテナへ移す 画面に見えているのはいつもの VS Code だが、Dev Containers では言語の処理系や拡張機能の多くがコンテナの側で動くPhoto: Pota12 / CC BY-SA 4.0 最初に押さえておきたいのは、VS Code が二つに分かれて動くという点だ。ウィンドウやメニュー、配色のテーマといった画面まわりは手元のパソコンで動く。一方、コンテナの中には「VS Code Server」と呼ばれる小さな本体が自動で入り、ファイルの読み書き、ターミナル、言語の補完やデバッガーといった拡張機能は、そちらの側で動く。最初にコンテナへつないだとき、この VS Code Server が手元からコンテナに送り込まれる。 この分け方のおかげで、拡張機能はコンテナに入っている処理系やコマンドをそのまま使える。Python の拡張機能はコンテナの中の Python を見に行き、ターミナルを開けばコンテナの中のシェルが立ち上がる。手元のパソコンに Python が入っていなくても、補完もデバッグも普段どおりに動く。ただし、配色のテーマやキー割り当てのように画面にしか関わらない拡張機能は、手元の側で動く。 作業中のファイルそのものは、標準では手元のフォルダーがコンテナの中に「バインドマウント」という形で見えるようになっている。コンテナの中では /workspaces/フォルダー名 という場所に現れ、そこで編集した内容は手元のフォルダーにそのまま反映される。つまり、コードは手元に残り、それを動かす道具だけがコンテナに入る。コンテナを消してもソースコードは消えない、というのがこの仕組みの安心できるところだと思う。 用意するのはDockerと拡張機能が1つずつ コンテナを動かす土台として、Docker が必要になる。Windows と macOS では Docker Desktop を入れるのがいちばん手早く、Windows では WSL2 を使う設定にしておくのが基本だ。Linux なら Docker Engine をそのまま使える。Docker Desktop は個人での利用や学習、従業員250人未満かつ年間売上1,000万ドル未満の小規模な事業であれば無料で使える。それを超える会社で使う場合は有料の契約が必要になるので、職場のパソコンで試すときは一度確かめておきたい。Docker Desktop の代わりに Podman や Rancher Desktop を土台にする方法もある。 ...