📚 連載：Ansibleが理解できない理由はLinuxにあった
Linuxの仕組みからAnsibleを理解するシリーズです。
0️⃣ Ansibleの仕組み
1️⃣ Linuxの構造（Kernel / Shell / Filesystem）
2️⃣ command not foundの原因：PATH
3️⃣ SSH接続できない理由：鍵認証とポート
4️⃣ Permission deniedの原因：ユーザーと権限
5️⃣ サービスが起動しない理由：systemd
6️⃣ cronが動かない理由：PATH問題
7️⃣ ディスク満杯になる理由
8️⃣ サーバーが遅くなる理由
🗺️ 初めての方・シリーズの全体像を知りたい方はこちら
本記事は、OSの仕組みからAnsible設計までを繋ぐ連載シリーズの一部です。
「どこから読み始めればいいか」あるいは、「OS/Shell/Ansible編の関係性」 について把握されたい場合は、以下の統合ガイドで整理しています。
📑 【OS編】全体のまとめはこちら
→ Ansibleが理解できない理由はLinuxにあった【OS編】まとめ
📑 連載の移動
前の記事：【OS編】第0回 ｜ 次の記事：【OS編】第2回
シリーズ全体構造（学習 × 問題解決）
本シリーズは
「理解（各記事）」と「問題解決（逆引き辞典）」を組み合わせて
スキルを身につける構成になっています。
この図は、どこから学び、どこに進めばよいかを示した“ロードマップ”です。
📍 現在の位置
現在はこの図の「OS編 第1回」になります
前回の振り返り（第0回）
第0回では、Ansibleが内部で手動運用と同じ技術スタック（Ansible → SSH → Shell → Linux）を順に実行していること、そして自動化を真に理解するには接続先である「Linuxの仕組み」の把握が不可欠であることを解説しました。
本記事（第1回）では、その土台となるLinux OSの全体像を4つの基本構造に分解し、実務で遭遇するエラーとの関係性を整理します。
📋 目次
- なぜAnsibleのエラー解決にLinuxの構造が必要なのか
- Linuxを構成する4つの基本構造
- 各要素の役割とAnsibleエラーの関連性
- まとめ：エラーを「構造のレイヤー」で捉える
- 次回予告
- 連載一覧：Ansibleが理解できない理由はLinuxにあった
1. なぜAnsibleのエラー解決にLinuxの構造が必要なのか
Ansibleの実務で遭遇するエラーは、一見するとそれぞれ独立した問題のように見えます。
-
command not found -
Permission denied -
サービス起動失敗（
Job for xxx.service failed）
しかし、これらのエラーの真因を特定するためには、Ansibleが操作している対象であるLinux OSの基本構造を理解しておく必要があります。
Ansibleは何か特別な仕組みでサーバーを構築しているわけではなく、手動運用と同じ以下のスタックを自動で実効しているに過ぎません。
Ansible（制御ノード）
↓
SSH（通信経路）
↓
Shell（コマンド評価）
↓
Linux（カーネル・OS処理）
つまり、Ansibleのエラーメッセージを読み解くということは、「この技術スタックのどの層でトラブルが起きているか」 を特定することと同義です。
知識が断片化してトラブルシューティングで迷子にならないよう、本記事ではLinux OSの全体像を4つの要素に整理して解説します。
2. Linuxを構成する4つの基本構造
Linux OSは多くの機能を持っていますが、インフラ運用のトラブルシューティングにおいては、以下の4つの要素で全体像（OSの地図）を捉えることができます。
| 要素 | 役割 |
|---|---|
| Kernel | CPU、メモリ、ディスクなどのハードウェア資源を管理する |
| Shell | ユーザー（またはAnsible）の命令を受け取り、プログラムへと橋渡しする |
| Process | WebサーバーやSSHなど、現在システム上で実行されているプログラムの単位 |
| Filesystem | 設定ファイルやデータを保持・管理する仕組み（Linuxでは「すべてはファイル」） |
3. 各要素の役割とAnsibleエラーの関連性
① Shell（シェル）
Shellは、ユーザーやAnsibleからのコマンド入力を解釈し、対応するプログラムを起動するインターフェースです。
- Ansibleとの繋がり: Ansibleがリモートサーバーでタスクを実行する際、多くの場合はこのShellを介してコマンドが実行されます。
-
対応するエラー例:
command not found(第2回 で解説）。これはShellがコマンドの実行場所（PATH）を解決できなかった際に出力される、典型的なShellレイヤーのエラーです。
② Process（プロセス）
プロセスとは、メモリやCPUを割り当てられて実行されている「プログラムの本体」です。nginx や sshd、cron などもすべてプロセスとして動作しています。
-
Ansibleとの繋がり: インフラ運用の多くは、これらプロセスの「起動」「停止」「状態監視」です。Ansibleの
serviceモジュールやsystemdモジュールも、裏側ではこのプロセス制御を行っています。 -
対応するエラー例:
Job for xxx.service failed（第5回 で解説）。サービスが正常に起動しない原因を追うには、プロセスを管理する systemd の仕組みを知る必要があります。
③ Filesystem（ファイルシステム）
Linuxには「すべてはファイルとして扱う」という強力な設計思想があります。設定ファイル（/etc/以下）だけでなく、デバイスやプロセス情報すらもファイルという形で表現されます。
-
Ansibleとの繋がり: Ansibleの主要なモジュール（
copy,template,file,lineinfileなど）の多くは、このファイルシステムに対する変更操作を行います。 -
対応するエラー例:
No space left on device（第7回 で解説）。ディスク容量の枯渇やログの滞留は、ファイルシステムの仕組みと調査方法を理解していれば即座に対応可能です。
④ Kernel（カーネル）
KernelはOSの中枢であり、Shellやプロセスからの要求を受けて、実際のハードウェア（CPU、メモリ、ディスク）を制御・管理します。プログラムはKernelに処理を依頼しなければ、ハードウェアに触れることはできません。
-
Ansibleとの繋がり: 特権が必要な操作（パッケージのインストールやポートの開放など）を行う際、Ansibleでは
become: yes（sudo）を使って権限を昇格させます。この権限制御の最終的な番人がKernelです。 -
対応するエラー例:
Permission denied（第4回 で解説）。これはKernelの権限制御によって処理が拒絶された状態を指します。
4. まとめ：エラーを「構造のレイヤー」で捉える
実務における正しい考え方は、エラーを個別に暗記することではなく、「このエラーはどの層で起きているか」を構造から逆算することです。
ユーザー / Ansible
↓
SSH（通信・認証のエラー）
↓
Shell（PATHや環境変数のエラー）
↓
プロセス（systemdやサービス起動のエラー）
↓
Kernel（権限やリソース、ハードウェアのエラー）
このOSの階層構造が頭に入っていれば、Ansibleがエラーを吐いたときに「どこを調査すべきか」の初動に迷わなくなります。
次回から、この構造に沿って実務の泥臭いエラーの真因を1つずつ紐解いていきましょう。
5. 次回予告
次回（第2回）は、運用現場やAnsible実行時に頻出するエラーである「command not found」を解説します。
手動では動くコマンドが、なぜAnsibleを通した途端に見失われてしまうのか。その原因である「環境変数」と「PATH」の仕組みについて解説します。
第2回：【Ansibleでハマる】command not foundの原因はPATHだった（環境変数の正体）
📑 連載の移動
前の記事：【OS編】第0回 ｜ 次の記事：【OS編】第2回
📑 【OS編】全体のまとめはこちら
→ Ansibleが理解できない理由はLinuxにあった【OS編】まとめ
🗺️ 初めての方・シリーズの全体像を知りたい方はこちら
本記事は、OSの仕組みからAnsible設計までを繋ぐ連載シリーズの一部です。
「どこから読み始めればいいか」あるいは、「OS/Shell/Ansible編の関係性」 について把握されたい場合は、以下の統合ガイドで整理しています。
6. 連載一覧：Ansibleが理解できない理由はLinuxにあった
| 回数とタイトル | 内容（概要） |
|---|---|
| Ansibleが理解できない理由はLinuxにあった【OS編】：【保存版】Ansibleトラブル逆引き辞典（Linux / SSH / Shellエラー対応 | Ansibleで発生するエラー（UNREACHABLE / Permission denied / command not found など）を「エラーから逆引き」で調べられる実務向け記事。各回の内容と対応しており、トラブル時の入口として使える。 |
| 第0回：【なぜAnsibleは理解できないのか】仕組みを分解してみる | Ansibleは「Linux操作の自動化」ツール。Ansible → SSH → Shell → Linux の構造を理解し、シリーズ全体の土台を作る。 |
| 第1回：【なぜLinuxが分からないと詰むのか】Kernel / Shell / Filesystemの全体像 | Linuxの基本構造を理解することで、Ansibleが内部で何をしているのか（Shell実行・プロセス・ファイル操作）を把握できるようになる。 |
| 第2回：【Ansibleでハマる】command not foundの原因はPATHだった（環境変数の正体） | Ansible実行時に発生する「command not found」の原因はPATHにある。環境変数の仕組みを理解しないとエラーを解決できない。 |
| 第3回：AnsibleのSSH接続が失敗すると UNREACHABLE エラーになる。（Connection refused / Permission denied / Timeout など） | AnsibleのSSH接続が失敗すると UNREACHABLE エラーになる。SSH（鍵認証・ポート・Firewall）を理解することで原因を特定できる。 |
| 第4回：【Permission deniedの正体】Linuxユーザーと権限の仕組み | Ansibleのbecome（sudo）で発生する Permission denied の原因はLinux権限にある。ユーザー・グループ・権限の仕組みを理解する。 |
| 第5回：【サービスが起動しない理由】systemdの仕組みを理解する | Ansibleのservice / systemdタスクが失敗する原因はLinux側にある。systemdの仕組みを理解することで原因を特定できる。 |
| 第6回：【cronが動かない理由】手動では動くのに失敗する原因 | Ansibleで設定したcronが動かない原因は環境差分（PATHなど）にある。cron特有の実行環境を理解することで解決できる。 |
| 第7回：【No space left on device】ディスク容量不足の原因と調査方法（df / du / log） | Ansible実行時のディスク不足エラーはLinuxのログ肥大化や容量管理が原因。df / duを使った調査方法を解説する。 |
| 第8回：【サーバーが遅い】原因の見つけ方（CPU / メモリ / プロセス） | Ansible実行が遅い・失敗する原因はサーバー負荷の可能性がある。CPU・メモリ・プロセスの見方を理解して原因を特定する。 |