Dockerデーモンのグローバル設定でチーム開発環境を統一する

ローカルでもサーバーでもDockerを使うと、プロジェクトごとに同じ設定を docker-compose.ymlにコピー＆ペーストすることが多くなります。

  • DNSを常に 1.1.1.1, 8.8.8.8 に固定
  • ログドライバを json-file + max-size=10m に固定
  • プロキシ、insecure registry、デフォルトネットワーク帯域など…

これらは コンテナ個別の設定ではなく「ホスト全体のデフォルト値」 として 設定しておくと、管理が格段に楽になります。役割を担うのが Dockerデーモンのグローバル設定（daemon.json） です。

以下では:

  • どのファイルを
  • どこに作るか
  • どのように書くか
  • どんな状況・誰に有用か

を整理します。

1. Dockerデーモン設定の2つの方法

Commandbox 광고

Dockerデーモン（dockerd）は主に2つの方法で設定できます。

  1. JSON設定ファイル（daemon.json）を使用 ← 推奨
  2. dockerd 実行時に CLIフラグ でオプションを渡す

両者を混ぜて使うことは可能ですが、同じオプションを両方で指定するとデーモンが起動しません。例えば --log-driver フラグと daemon.json に同じログドライバを設定すると、Dockerは起動時にエラーを出して停止します。

チーム／サーバー環境を統一するには、通常:

「できるだけ daemon.json にまとめ、フラグは最小限に抑える」

ことを推奨します。

2. daemon.json の場所

OS・インストール方法別に基本パスを表にまとめました。

環境 基本パス 備考
Linux（一般インストール） /etc/docker/daemon.json 最も一般的
Linux（snapでインストール） /var/snap/docker/current/config/daemon.json Ubuntu snapパッケージ
Windows Server / Docker Engine C:\ProgramData\Docker\config\daemon.json 管理者権限が必要な場合あり
Docker Desktop（Mac / Windows） ~/.docker/daemon.json デスクトップ設定の内部パス
  • このファイルは デフォルトで存在しない ことがあるので、無ければ自分で作成して使用します。
  • チーム／サーバー標準を扱う際は、Linuxサーバーの /etc/docker/daemon.json を基準に説明するのが実務に合います。

3. 基本的な使用パターン: 「ファイル作成 → デーモン再起動」

Commandbox 광고

Linuxを例に、最も一般的なワークフローは次の通りです。

  1. daemon.json を作成／編集
{
  "dns": ["1.1.1.1", "8.8.8.8"],
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}
  1. 設定ファイルが有効か 事前検証
sudo dockerd --validate --config-file=/etc/docker/daemon.json
# configuration OK が出れば正常
  1. Dockerデーモン 再起動
sudo systemctl restart docker

これで、新しく起動するコンテナは、設定が無ければこのグローバル設定をデフォルトとして継承します。

4. 例1 – DNSサーバーをグローバルに固定する

4.1 なぜDNSをグローバルに？

コンテナが「外部APIが見つからない」「内部ドメインが解決できない」などの問題を頻繁に起こす場合、ほとんどは ホストのDNS設定／環境に依存 しています。

例:

  • チーム全体で Cloudflare DNS（1.1.1.1）を使いたい
  • 社内DNSサーバー経由でしかアクセスできないエンドポイントがある

このようなケースでは、プロジェクトごとに docker-compose.yml に dns: を入れるより、デーモンレベルで統一したほうがずっと楽です。

4.2 設定例 (daemon.json)

{
  "dns": ["1.1.1.1", "8.8.8.8"]
}

既存の daemon.json がある場合は、ルート { ... } 内に "dns": [...] を追加します（カンマ位置に注意）。

⚠️ 注意: DNS設定はコンテナ内の /etc/resolv.conf に反映されます。既に起動しているコンテナには即座に適用されず、新しく起動するコンテナから 有効になります。

4.3 どんな人に有用か？

  • 社内に プロキシ・内部DNS がある開発者
  • マルチクラウド 環境で特定DNSを強制したいプラットフォームチーム
  • ローカルで複数VPNを切り替えながら開発する個人開発者

5. 例2 – ロギングドライバ＆オプションをグローバルに設定

コンテナログはデフォルトで json-file ドライバを通じて /var/lib/docker/containers/... に蓄積されます。これをグローバルに変更すると、

  • ログフォーマット
  • ログ保存場所
  • ログローテーションポリシー

を コンテナ全体に一括適用 できます。

5.1 基本的な json-file ドライバ + ローテーション

最も一般的なパターンは「json-file を使い、ディスクがいっぱいにならないようローテーション設定」。

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "5"
  }
}

これで、 - コンテナごとのログファイルサイズは最大 10MB、 - 最大 5 ファイルまで保持し、超過分は自動で削除されます。

5.2 中央ログ収集用ドライバ（fluentd, journald など）

プラットフォームチーム／インフラチームでは、すべてのコンテナログを中央ロギングシステムへ送る ことが多いです。

例として Fluentd を使う場合:

{
  "log-driver": "fluentd",
  "log-opts": {
    "fluentd-address": "localhost:24224",
    "tag": "{{.Name}}"
  }
}

この設定により、docker run --log-driver=... を個別に指定せずとも、すべてのコンテナログが自動で Fluentd に送られます。

個人的には journald ドライバ も非常に便利です。systemd ベースの Linux 環境なら、アプリケーションログと Docker コンテナログを同じ journald に集約でき、journalctl だけで検索・フィルタ・保持ポリシーを統一できます。

journald をグローバルログドライバにしたい場合は、次のように設定します:

{
  "log-driver": "journald",
  "log-opts": {
    "tag": "{{.Name}}"
  }
}

ここで tag をコンテナ名にしているので、 - journalctl -f | grep {container_name} でリアルタイムログを素早く確認できる - --since "10m ago" などを組み合わせて 特定時点以降のログだけを見る - journalctl -f -t {container_name} のように -t オプション（タグ/識別子）で 特定コンテナログだけを抽出 可能

もちろん journalctl -u docker.service でユニット単位で見ることもできますが、コンテナ名でフィルタする方が直感的で入力も短く、実務でよく使われます。

5.3 Compose / docker run との関係

  • グローバル log-driver + log-opts は「デフォルト」役割
  • 個別コンテナで logging:（Compose）や --log-driver, --log-opt（CLI）を指定すると そのコンテナだけオーバーライド

戦略としては: - 共通値は daemon.json に - 特殊なサービスだけ個別オーバーライド

という構成を推奨します。

6. 例3 – プロキシ、insecure registry などのグローバルネットワーク設定

グローバル設定で頻繁に使われる他のオプションもあります。

6.1 プロキシ設定

社内プロキシを通じてのみ外部にアクセスできる場合、デーモンレベルでプロキシを設定すると、環境変数を毎回入れる手間が省けます。

{
  "proxies": {
    "http-proxy": "http://proxy.example.com:3128",
    "https-proxy": "http://proxy.example.com:3128",
    "no-proxy": "localhost,127.0.0.1,.corp.example.com"
  }
}

この設定により、Docker デーモンはイメージをプルしたり、ビルド時にネットワークを使用したりするときにこのプロキシ設定を自動で適用します。

6.2 insecure registry

TLS が無いレジストリを必ず使う必要がある場合（内部開発用など）:

{
  "insecure-registries": ["my-registry.local:5000"]
}

セキュリティ上のリスクがあるため、内部テスト環境でのみ 使用するよう注意してください。

7. 例4 – デフォルトブリッジネットワーク帯域、ストレージドライバなど

よりインフラ寄りのオプションです。

7.1 デフォルトブリッジネットワーク帯域のカスタマイズ

VPNや社内ネットワークとIPが重複しないようにしたい場合:

{
  "default-address-pools": [
    {
      "base": "10.20.0.0/16",
      "size": 24
    }
  ]
}

これで Docker が新しいブリッジネットワークを作るときに 10.20.x.0/24 を使用します。

7.2 ストレージドライバの強制

Linux ディストリビューションによってデフォルトストレージドライバが異なる場合があります。チームで overlay2 のみを使うと決めたら:

{
  "storage-driver": "overlay2"
}

実際にサポートされるストレージドライバは OS/カーネルにより異なるため、dockerd ドキュメントとディストリビューションガイドを必ず確認してください。

8. いつ、誰に特に有用か？

8.1 個人開発者

  • 複数サイドプロジェクトで常に同じ Docker オプションを使う人
  • VPN、社内プロキシなどネットワーク環境が頻繁に変わる状況
  • ログ/ディスク管理が面倒なローカル開発マシン

→ daemon.json 1 つで 環境統一 + 繰り返し設定の削除 が可能です。

8.2 小規模／中規模開発チーム

  • チームメンバーごとにローカル Docker 設定が異なり「自分の PC では動くけど？」が頻発
  • CI サーバーと開発者ローカル環境のネットワーク／ログ設定をできるだけ揃えたい
  • 社内標準 DNS・プロキシ・レジストリ使用を強制したい

→ 「チームの Docker 基本値はこれだ」という チーム規約 を daemon.json で定義しておくと便利です（Ansible、Chef、Terraform、Cloud-Init などで配布するとさらにきれい）。

8.3 プラットフォームチーム / DevOps / SRE

  • 数十〜数百コンテナを稼働させるノードで
  • ログ、ストレージ、ネットワークポリシーを一貫して管理したい
  • ログ収集、モニタリング、セキュリティルールを ホスト基準で標準化 したい

→ daemon.json は実質的に 「Docker Node のポリシーファイル」 となります。

9. デバッグヒント

  1. フラグと重複設定 - systemd ユニットファイル（/lib/systemd/system/docker.service など）に既に --log-driver などのフラグがあるか確認 - 同じオプションがフラグと daemon.json に共存するとデーモンが失敗します。
  2. Docker Desktop では GUI が優先 - Desktop では Settings(UI) で変更すると内部的に ~/.docker/daemon.json が更新されます。 - 直接ファイルを編集した後に UI で再度設定すると上書きされるので、どちらか一方に統一すると良いです。

まとめ

  • Docker のグローバルデフォルトは daemon.json で管理します。
  • 位置は主に:
  • Linux: /etc/docker/daemon.json
  • Windows: C:\ProgramData\Docker\config\daemon.json
  • Docker Desktop: ~/.docker/daemon.json
  • 代表的なグローバル設定例:
  • DNS: "dns": ["1.1.1.1", "8.8.8.8"]
  • ログドライバ: "log-driver": "json-file", "log-opts": {...}
  • プロキシ、insecure registry、デフォルトネットワーク帯域、ストレージドライバ…
  • グローバル設定は:
  • 個人開発者にとっては「毎回設定しなくて済む便利さ」
  • チーム／組織にとっては「環境標準化と障害削減」をもたらします。

docker-compose.yml や docker run に同じオプションを繰り返し書いているなら、今こそ daemon.json で統一するタイミング かもしれません。

image of docker daemon json setting