はじめに
Linuxで docker や podman などのコマンドを使っていると、こんな言葉に出会ったことはありませんか？
- デーモン（daemon）
- ソケットユニット（
.socket） - ソケットファイル（
.sock）
「なんとなく聞いたことはあるけど、どれが何の役割だったか曖昧…」
そんな方に向けて、この記事では Docker を例に、これらの 関係性と役割 をやさしく整理してみました。
目指すのは、systemdや各種デーモンを安全に・自信を持って扱うための“第一歩” です！
本記事は、systemdやDockerに関して自分自身が勉強した内容を
初学者の視点で整理・図解した備忘録的なメモです。
正確性には配慮していますが、内容に誤りや認識違いがありましたら、コメントで教えていただけると嬉しいです。
登場人物の紹介
🧞 デーモン
Linux でバックグラウンドに常駐するプログラム。
Docker では dockerd がこれに該当します。
なお、systemd はデーモンたちを統括する司令塔的存在（後述）。
👤「実際の仕事は私が処理しますが、起こされるまでは寝てます」
🚪 ソケットファイル（.sock）
UNIXドメインソケットと呼ばれる通信の入口。
CLIや外部アプリはこれを通じてデーモンに話しかけます。
例：/run/docker.sock
🧑💻「ここを叩けばデーモンに用件が届く」
🛎️ ソケットユニット（.socket）
systemd が持つ、デーモンを起こすための代行者。
.sock を先に作って、誰かがアクセスしてきたら .service を起動するという便利な存在です。
👤「デーモンが寝てたら、私が起こしてきます」
systemdとは？── OSの司令塔
systemd は、Linux 起動時に最初に立ち上がる「init システム」（＝システム起動時に最初に立ち上がるプロセス）。
システム全体のサービス・マウント・タイマーなどをユニット単位で統一的に管理しています。
たとえば：
| ユニット種別 | 説明 |
|---|---|
.service |
デーモンなどの常駐プロセス |
.socket |
ソケット待ち受け（UNIX/TCP 両対応） |
.mount |
マウントポイント管理 |
.timer |
タイマー処理（cron の代替のような役割） |
.target |
複数ユニットのグルーピング |
つまり、systemd は単なるデーモン管理ツール にとどまらず、OS 上のリソース・プロセス・起動順序を制御する司令塔 のような偉い存在です。
systemd と Docker の関係を流れで理解する
docker コマンドなどを実行すると、Linux の裏側では何が起きているのか──
ここでは .sock を叩いたときの 具体的な処理の流れを、順を追って説明します。
✅ デーモンが起きているとき
- CLI が
/run/docker.sockを叩くと、デーモン本人が即座に処理します。 -
docker.socketユニットは反応せず、ぼーっとしてるだけ（仕事なし）。
💤 デーモンが寝ているとき
- CLI が
/run/docker.sockを叩くと、docker.socketユニットが待ち構えて反応します。 - systemd が
.serviceを起動 → デーモンが目を覚ます -
docker.sockファイルはdocker.socketが systemd を通じて自動で作ってくれます。 - デーモンが起きた後は、以降の通信を引き継いで処理を開始！
流れを図で確認する
docker.socket を有効にしておけば、docker compose up -d したときに
"Cannot connect to the Docker daemon" エラーを回避しやすくなります。
docker.socket を有効にする = 管理の「主導権」を systemd に渡すこと
たとえば docker.socket を有効にするとは、こういうことです：
-
.sockの作成・bind（listen）は systemd が担当 -
.sockにアクセスが来たとき、systemd が.serviceを起動 - Docker デーモンは、自分では
.sockを作らない
このとき、「Docker のサービスは systemd の管理下にある」と言えます。
補足：「socketを有効にする」は、具体的に何してる？
-
systemctl enable docker.socket
→/etc/systemd/system/sockets.target.wants/にシンボリックリンクが張られる -
systemctl start docker.socket
→ systemd が.sockを bind して listen 状態に入る -
.socketユニットには[Socket] ListenStream=/run/docker.sockのような記述があり、ここでファイルパスやプロトコル種別が定義されている
さらに詳しく知りたい方は、こちらの記事がとても勉強になります！
よくある疑問
❓ CLI が失敗して「docker.sock がない」と言われるのはなぜ？
-
docker.socketが無効になっている、もしくはデーモンが起きていない可能性があります。
❓ .sock ファイルって消えるもの？
- はい、揮発性の
/runにあるため OS再起動で消えます。 - ただし
.socketユニットが有効なら、再起動時に自動で再生成されます。
❓ .socket は、デーモン起こしたら消える？
- 消えません。ずっとそこにいます。
- ただし、デーモンが起きている間は特に仕事をしません（次の出番を待っているだけ）。
用語まとめ
| 用語 | 意味 | 誰が作る？ | 状態による挙動 |
|---|---|---|---|
| デーモン | 常駐プロセス | systemd または手動で起動 | 寝てるときは .socket によって起こされる |
.sock |
通信の入り口（UNIXソケット） | systemd（.socket） またはデーモン |
CLIがここを叩くと通信が始まる |
.socket |
呼び鈴ユニット（systemd） | systemd |
.sock の作成と、デーモン起動を担当 |
おわりに：systemd と仲良くなる第一歩として
ここまでの内容で、.sock・.socket・デーモンの関係と systemd の仕組みについて基本的なところをお伝えできたと思います。
そして……ちょっと余談ですが、Docker を扱ううえで知っておいてほしい“強さの話” があります👇
🧠 付録：Dockerが「強すぎる」理由と現実的な向き合い方
Docker は、開発者が「簡単に」「何でも」できるように設計された便利ツールです。
しかしその便利さの裏には、「Docker デーモンが root 権限で動いている」という “強すぎる仕組み” が存在します。
つまり docker コマンドを使える人は、事実上ホストの管理者になれてしまう ということ。
⚠️ docker.socket を有効にしているときの注意点
-
docker.socketユニットが有効だと、systemd が.sockファイルを作って常に待ち受けます - デーモンが停止中でも
.sockが存在し続けるため、プロセスやユーザーがいつでも接続を試みることができる状態になります - 特に
dockerdは root 権限で動作するケースが多く、.sockを通じて制御を奪われると ホスト全体が乗っ取られる危険すら あります
💡 「じゃあ、Dockerを弱くすればいいのでは？」
その発想もアリです。たとえば：
- Docker を rootless モード で運用する
- Podman など、rootless を前提とした代替コンテナエンジンを使う
ただし、これらの方法は：
- ネットワーク設定やパーミッション周りで制限がある
- 既存の Docker エコシステム（ComposeやCIなど）と完全に互換性がない
といった 運用上のハードルが高く、すぐには採用できない現場も多いです。
※ 実際に某プロダクトでは Podman を使っているが、rootless ではなく rootful モードで運用する判断になったという事例もあります。
現実的な対策は？
Docker の強さは受け入れる。けれど、それを誰でも扱える状態にはしない。
そんな運用が、現実的で安全性と利便性のバランスが取れています。
具体的には：
-
docker.sockにアクセスできるユーザーやグループを 限定する -
dockerコマンドを実行できる人に、明確な運用ルールやアクセス制御を設ける
このようにすることで、Docker の強力な能力を生かしつつ、安全に利用することができます。
✅ まとめ（付録）
- Docker は便利さと引き換えに「強すぎる力」を持っている
-
docker.socketによって、常に.sockが開かれる＝セキュリティリスクにもなる - rootless や Podman などの手段もあるが、現実にはハードルがある
- 使える人を限定するなどのアクセス制御と運用ルールこそが、実践的なセキュリティ対策！
ここまで読んでいただき、ありがとうございました！
🔗 関連記事：セキュリティまわりに興味が湧いたら…
.sock や systemd まわりの仕組みを知ると、次は「じゃあどこに脆弱性が生まれるの？」という話が気になりますよね。
セキュリティ系の記事も書いていますので、興味があればぜひこちらもどうぞ！
👉 DDoS攻撃をちゃんと理解したい人のための入門と設計整理メモ