コンテナーから Docker や Kubernetes を使用する

開発用コンテナー (dev container) 内でアプリケーションのビルド、デプロイ、およびデバッグを行うことができますが、本番環境に近い一連のコンテナー内で実行してテストする必要が生じる場合もあります。幸い、必要な Docker または Kubernetes CLI をインストールし、ローカルの Docker ソケットをマウントすることで、dev コンテナーの内側からアプリのコンテナーイメージをビルドおよびデプロイできます。

必要な CLI が配置されたら、Container Tools 拡張機能または Kubernetes 拡張機能を使用して、適切なコンテナー クラスターを操作することもできます。

特定のシナリオに関する詳細情報については、以下の開発用コンテナー テンプレートの例を参照してください。これらをプロジェクトに追加するには、VS Code で作業するフォルダーを開き、コマンド パレット (F1) で Dev Containers: Add Dev Container Configuration Files... コマンドを実行します。

フォルダーの内容に基づいて並べ替えられたフィルター可能なリストから、ファーストパーティおよびコミュニティのインデックスにある定義済みコンテナー構成を選択するよう求められます。VS Code UI から、以下のセクションで説明するテンプレートのいずれかを選択できます。

開発用コンテナーでの Docker または Minikube の実行

  • Docker-in-Docker - コンテナー内だけで Docker (または Moby) を実行する方法を示します。開発用コンテナー内のすべてのフォルダーのバインド マウントをサポートしますが、ローカル マシンのキャッシュを再利用することはできません。

  • Kubernetes - Minikube-in-Docker - Docker-in-Docker と同様の利点と制限を持ちながら、コンテナー内だけで Minikube を実行する方法を示します。

コンテナーから既存の Docker または Minikube インスタンスへのアクセス

  • Docker outside of Docker - Docker Unix ソケットをバインド マウントしてホストの Docker デーモンに接続するために、開発用コンテナー内の Docker (または Moby) CLI をどのように使用できるかを示します。オーバーヘッドが少なく、マシンのキャッシュを再利用できますが、バインド マウントの制限があります。

  • Docker outside of Docker Compose - 単一の Dockerfile の代わりに Docker Compose を使用している状況向けの、Docker outside of Docker のバリエーションです。

  • Kubernetes - ローカル構成 - Docker outside of Docker モデルに kubectl と Helm を追加し、ローカルの Minikube または Docker が提供する Kubernetes クラスターにアクセスする方法を示します。

また、上記のサンプルから参照され、再利用できる Docker-in-DockerDocker outside of Docker、および Kubernetes のインストール スクリプトに関するドキュメントもあります。

コンテナー内から Docker を使用したホスト ボリュームのマウント

Docker-in-Docker モデルに従う場合、開発用コンテナーの内側から Docker CLI を使用すると、同じ場所で実行されている Docker デーモンと対話することになります。つまり、開発用コンテナー内の任意のものを、作成した「内側の」コンテナーに「バインド」マウントできます。

たとえば、これは「そのまま動作します」

docker run -v /workspace/examplefile.txt:/incontainer/path debian

ただし、利用可能なホスト フォルダーをこの内側のコンテナーにバインド マウントする場合は、まずそれを開発用コンテナーにマウントする必要があります。

Docker outside of Docker では、デフォルトで機能するバインド マウントの種類が逆になります。ここでは、コンテナー内の Docker CLI が代わりにホストの Docker デーモンと対話します。コンテナー内のパスがホスト上のディレクトリのパスと一致しない可能性があるため、これはコンテナー内からのディレクトリのマウントに影響します。

コンテナーの外側にあるホスト上のパスが /workspace/... ではないため、上記の例と同じ例は失敗します。さらに、一部のフォルダーはコンテナー内にしか存在しないため、単にマウントできません。これを行う必要がある場合は、Docker-in-Docker モデルの方がニーズに適していることがわかるでしょう。

コンテナー内でフォルダーを開いている場合は、ホスト ディレクトリを環境変数としてコンテナーに渡し、ワークスペース フォルダーをマウントできるようにすることができます。(ただし、ボリュームを使用した場合はこれは機能しません。その場合は Docker-in-Docker が最適な選択肢です。)これを行うには、devcontainer.json に以下を追加します。

  "remoteEnv": {
    // Pass in the host directory for Docker mount commands from inside the container
    "HOST_PROJECT_PATH": "${localWorkspaceFolder}"
  }

以下の例は makefile のものであり、開発用コンテナーから起動する新しい Docker コンテナーへ KUBECONFIG ファイルをマウントします。

docker run -p 8089:8089 -p 9090:9090 -v $(shell echo ${KUBECONFIG} | sed s#/workspace#${HOST_PROJECT_PATH}#):/kubeconfig.json -e KUBECONFIG=/kubeconfig.json ${IMG} -f behaviours/run_submit_locust.py
© . This website operates independently and is not affiliated with or endorsed by Microsoft. All brand names, logos, and trademarks are the property of their respective owners.