【Docker】Dockerfile実行時の「docker endpoint for "default" not found」について


投稿日 2025年10月27日 >> 更新日 2025年10月27日

概要

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

Dockerfileをビルドしようとすると「docker endpoint for "default" not found」が発生する問題

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 endpoint for "default" not found」が発生したのか?

どうやら、Dockerfileをビルドする際にDockerはどこでビルドをするかを「context」から判断するようです。

/home/user/.docker/contexts/meta

イメージを使ってコンテナを構築する場合はDocker Hubなどから取得してくるだけなので、「context」情報を参照せずに済みます。

ちなみに、これまでずっとイメージからコンテナを構築していたので、現在の環境でDockerfileを使うのは初めてでした。

なので「context」が壊れているのに気が付かずにいたわけです。

他の記事を参照すると、contexts/metaディレクトリ内のmeta.jsonを削除したり内容を追記したりと様々な方法で問題解決しているのが見受けられました。

また、深堀でき次第共有していきます。

最後までご覧いただきありがとうございました。