Dockerで作る、壊して戻せる開発環境

Dockerは、自分のPCの中に開発専用の隔離された環境を用意する技術。ホストPCへ直接いろいろなプログラムを入れなくても、必要なツールをコンテナの中にまとめて動かせる。

コンテナは仮想マシンそのものではなく、必要なファイルやライブラリと一緒に隔離して動かすプロセス。仮想マシンはOSやカーネルまで丸ごと持つのに対して、複数のコンテナは基本的にホスト側のカーネルを共有する。そのぶん起動が速く、比較的軽量なのが特徴。なお、macOSやWindowsのDocker Desktopでは、Linuxコンテナを動かすために内部でLinuxの仮想マシンも利用している。

イメージは、コンテナを起動するために必要なファイル、実行環境、ライブラリ、設定をまとめた変更不可のひな型。Dockerfileには、どのベースイメージを使うか、何をインストールするか、どのコマンドで起動するかをコードで書く。このブログではDockerfileを使ってNode.js 22系が動くイメージを作っている。同じ定義から作れば、環境を壊してもイメージからコンテナを作り直せるし、ほかの人も近い環境を再現しやすい。

コンテナを作り直すと、コンテナ内の書き込み可能な層に置いたデータは失われるのが基本。残したいデータにはDocker管理の「ボリューム」を使い、PC上のソースコードをコンテナから直接扱いたいときは「バインドマウント」を使う。このブログのCompose設定では、プロジェクトのフォルダをコンテナ内の`/workspace`へバインドマウントしている。だからPC側で編集した記事やコードが、コンテナ側からも同じファイルとして見える。ただし、コンテナからPC側のファイルを書き換えられる設定でもあるので、便利さと権限の強さはセットで意識したい。

コンテナの中でWebサーバーを起動しても、そのままではPCのブラウザからアクセスできないので、ホスト側とコンテナ側のポートを対応づける。このブログはComposeで`4321:4321`と設定しているから、PCの`localhost:4321`へのアクセスが、コンテナ内の4321番ポートへ届く。さらにDocker Composeを使うと、コンテナのビルド方法、マウント、ポート、環境変数、複数サービスのネットワークなどをYAMLへまとめて、同じ構成を一括で起動できる。

Dockerfile、Composeの設定、パッケージのロックファイルをリポジトリで共有すれば、「自分のPCでは動くのに」という差を減らせる。完全に同じになるとは限らないため、ベースイメージや依存関係のバージョンを固定し、秘密情報をイメージへ含めないことも大切。このブログでは、ローカルはこのDocker環境でチェックと本番ビルドを試し、本番はCloudflareのWorkers Builds専用環境を使っている。GitHubへ変更をプッシュすると、Cloudflare側でビルドコマンドが実行され、成功した成果物がWorkerへデプロイされる。