【Docker】Dockerfile実行時の「docker endpoint for "default" not found」について
概要
docker compose up --build -dコマンドでDockerfileをビルド後にバックグラウンドで起動させようとしたら、「docker endpoint for "default" not found」というメッセージが発生した。イメージから取得するコンテナでは問題なく起動していたのになぜかDockerfileをビルドしようとすると起動しない。この問題を共有します。
| 実行環境 |
|---|
| Windows Subsystem for Linux 2 |
| Ubuntu 22.04.5 LTS |
| Docker Desktop 4.43.1 |
| Docker 28.3.0 |
| Compose v2.38.1-desktop.1 |
Python環境のコンテナを構築したかったので、Dockerfileに以下のように定義した。
# Dockerfile
FROM python:3.10
WORKDIR /app
# 依存関係ファイルをコピー
COPY requirements.txt ./
RUN pip install --upgrade pip && pip install -r requirements.txt
# アプリ本体をコピー
COPY . .
# 実行コマンド
CMD ["python", "app.py"]
そしてcompose.ymlには以下のように定義した。
services:
app:
build: .
container_name: app
ports:
- "8000:8000"
volumes:
- .:/app
prometheus:
image: prom/prometheus:v3.4.0
container_name: prometheus
...
node:
image: quay.io/prometheus/node-exporter:v1.9.1
container_name: node
...
そう、Pythonのコンテナの他に「Prometheus」と「Node Exporter」というコンテナも起動する設定でした。
問題のPython環境のビルドを定義する前は何も引っかからずに起動していた。
以下が問題の部分
services:
app:
build: .
container_name: app
ports:
- "8000:8000"
volumes:
- .:/app
...
この問題をAIに質問したところ、ビルドに必要な「context」が壊れている可能性があると指摘された。
Dockerのエンドポイントは[「contexts/meta」となっているらしく、docker context lsと実行するとcontextが壊れている場合は以下のように表示されます。
$ docker context ls
open /home/user/.docker/contexts/meta: not a directory
本来であれば「contexts/meta」はディレクトリでないといけないが、実際確認してみると「contexts」はディレクトリではなく空のファイルとなっていました。
なので以下のように一応「contexts」ファイルはバックアップをとって「contexts/meta」となるディレクトリを作成します。
# バックアップ
$ mv ~/.docker/contexts ~/.docker/contexts.bak
# /contexts/metaディレクトリの作成
$ mkdir -p ~/.docker/contexts/meta
そして、Python環境のDockerfileを実行します。
$ docker compose up --build -d
[+] Building 12.1s (12/12) FINISHED
=> [internal] load local bake definitions 0.0s
=> => reading from stdin 372B 0.0s
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 288B 0.0s
=> [internal] load metadata for docker.io/library/python:3.10 0.8s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 2B 0.0s
=> [1/5] FROM docker.io/library/python:3.10@sha256:f0a7c36689afe3af9a210ff45502e6252a329b71827193e2ed2bf78eb879b2ee 0.1s
=> => resolve docker.io/library/python:3.10@sha256:f0a7c36689afe3af9a210ff45502e6252a329b71827193e2ed2bf78eb879b2ee 0.1s
=> [internal] load build context 0.1s
=> => transferring context: 571B 0.0s
=> CACHED [2/5] WORKDIR /app 0.0s
=> [3/5] COPY requirements.txt ./ 0.1s
=> [4/5] RUN pip install --upgrade pip && pip install -r requirements.txt 8.5s
=> [5/5] COPY . . 0.1s
=> exporting to image 1.8s
=> => exporting layers 1.0s
=> => exporting manifest sha256:e72a0feb83273de80b5aa885cad3dc8350aef27d176a8646f13d688e4edcec20 0.0s
=> => exporting config sha256:649c337052433f5eb84f53f9a87b610fc9f8d761c40b5a74b9b311d40ee955e5 0.0s
=> => exporting attestation manifest sha256:1a7f6fbf325976ecc81722f1ac30d0bf88f0e8d53b1664c5799ff71e5e68be28 0.0s
=> => exporting manifest list sha256:c6c8c148de8c2e88b6a5b3160fa89e2c6a56873612558574eb2b20e43a448be0 0.0s
=> => naming to docker.io/library/prometheus-app:latest 0.0s
=> => unpacking to docker.io/library/prometheus-app:latest 0.6s
=> resolving provenance for metadata file 0.0s
[+] Running 3/3
無事にビルドが実行されコンテナが起動されました。
$ docker compose ps
NAME IMAGE COMMAND SERVICE CREATED STATUS PORTS
app prometheus-app "python app.py" app 58 minutes ago Up 58 minutes 0.0.0.0:8000->8000/tcp, [::]:8000->8000/tcp
node quay.io/prometheus/node-exporter:v1.9.1 "/bin/node_exporter …" node 58 minutes ago Up 58 minutes 9100/tcp
prometheus prom/prometheus:v3.4.0 "/bin/prometheus --c…" prometheus 58 minutes ago Up 58 minutes 0.0.0.0:9090->9090/tcp, [::]:9090->9090/tcp
contextのリストを取得してみると、エンドポイントが作成されています。
$ docker context ls
NAME DESCRIPTION DOCKER ENDPOINT ERROR
default * Current DOCKER_HOST based configuration unix:///var/run/docker.sock
どうやら、Dockerfileをビルドする際にDockerはどこでビルドをするかを「context」から判断するようです。
/home/user/.docker/contexts/meta
イメージを使ってコンテナを構築する場合はDocker Hubなどから取得してくるだけなので、「context」情報を参照せずに済みます。
ちなみに、これまでずっとイメージからコンテナを構築していたので、現在の環境でDockerfileを使うのは初めてでした。
なので「context」が壊れているのに気が付かずにいたわけです。
他の記事を参照すると、contexts/metaディレクトリ内のmeta.jsonを削除したり内容を追記したりと様々な方法で問題解決しているのが見受けられました。
また、深堀でき次第共有していきます。
最後までご覧いただきありがとうございました。