【Ansible講座 第1回】構成管理の革命児！エージェントレスで始める自動化入門＆環境構築完全ガイド

「手順書」を見ながらの作業は、もう終わりにしませんか？

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
これまで、Webサーバーの構築やログ管理（logrotate）など、黒い画面（ターミナル）でコマンドを叩く日々を送ってきましたね。

しかし、想像してみてください。
「明日までに、同じ設定のWebサーバーを100台用意してください」と言われたら。

1台ずつSSHでログインして、dnf install httpd を叩いて、設定ファイルを vi で編集して、systemctl start して…それを100回繰り返しますか？
それは苦行でしかありませんし、人間は必ずミスをします。
50台目で設定ファイルの書き間違いをするかもしれませんし、コマンドを打ち忘れるかもしれません。

本連載では、AlmaLinux 9 (RHEL 9) をベースに、Ansibleの基礎から実践的なLAMP環境の自動構築までをステップバイステップで解説します。

---

第1章：Ansibleとは何か？なぜ選ばれるのか？

Ansibleは、Red Hat社が開発を主導しているオープンソースの「構成管理ツール（Configuration Management Tool）」です。
「Infrastructure as Code (IaC)」を実現するツールの一つですが、競合製品（Chef, Puppet, Terraformなど）と比較して圧倒的な人気を誇ります。

1. 最大の特徴：エージェントレス

他の多くの構成管理ツール（ChefやPuppetなど）は、管理される側のサーバー（ターゲットノード）に専用のソフトウェア（エージェント）をインストールし、常駐させておく必要があります。
しかし、これは「エージェントのバージョン管理」や「エージェントがメモリを消費する」といった別の問題を引き起こします。

対して、Ansibleは「エージェントレス」です。

• 必要なもの: SSH接続 (OpenSSH) と Python だけ。
• 仕組み: 管理用PC（コントロールノード）からSSHで接続し、一時的にPythonコード（モジュール）を送り込んで実行し、終わったら消去します。

「SSHさえ繋がれば、今日からすぐに管理できる」という導入の手軽さが、Ansibleが爆発的に普及した最大の理由です。

2. 冪等性（べきとうせい）の魔法

自動化を学ぶ上で、絶対に覚えておかなければならない概念が「冪等性（Idempotency）」です。
これは、「ある操作を1回行っても、複数回行っても、結果が変わらない（システムの状態が同じになる）性質」のことです。

シェルスクリプトの場合（冪等性なし）

mkdir /var/www/html

このコマンドを2回実行すると、2回目はmkdir: cannot create directory ‘/var/www/html’: File existsというエラーで止まってしまいます。
これを防ぐには、「もしディレクトリがなかったら作る」というif文を書く必要があり、スクリプトが複雑化します。

Ansibleの場合（冪等性あり）

Ansibleでは「ディレクトリを作成する」ではなく、「ディレクトリが存在する状態にする（State=directory）」と定義します。

• ディレクトリがない場合 → 作成する（Changed）
• ディレクトリが既にある場合 → 何もしない（Ok）

Ansibleが自動的に現状を確認し、必要な場合のみ変更を加えます。
この性質のおかげで、何度でも安心して実行ボタンを押すことができるのです。

---

第2章：環境構築（コントロールノードの準備）

それでは、実際にAnsibleを動かす環境を作りましょう。
Ansibleは「操作する側（コントロールノード）」と「操作される側（ターゲットノード）」に分かれます。

今回は、コントロールノードとして **AlmaLinux 9 (または RHEL 9 / Rocky Linux 9)** を使用します。
※ターゲットノードも同じくAlmaLinux 9を想定していますが、Ubuntuなど他のOSでも操作可能です。

前提条件

• OS: AlmaLinux 9
• 権限: root権限 (sudo)
• Python: バージョン3.9以上（AlmaLinux 9標準）

1. EPELリポジトリの追加

AnsibleはRHEL系の標準リポジトリには含まれていません。
Fedoraプロジェクトが提供する「EPEL (Extra Packages for Enterprise Linux)」リポジトリを追加する必要があります。

sudo dnf install epel-release -y

2. Ansibleのインストール

Ansibleパッケージをインストールします。

sudo dnf install ansible -y

※補足：最小限の構成である ansible-core だけを入れる場合もありますが、学習用には多数のモジュールが含まれた ansible パッケージを入れるのが簡単です。

3. インストールの確認

以下のコマンドを実行し、バージョンが表示されれば成功です。

ansible --version

出力例:

ansible [core 2.14.2]
  config file = /etc/ansible/ansible.cfg
  configured module search path = ...
  python version = 3.9.16 ...

Python 3.9系で動作していることがわかります。

---

第3章：SSH鍵認証の設定（パスワードレス化）

AnsibleはSSHを使ってサーバーを操作します。
実行のたびにパスワードを入力するのは自動化の妨げになるため、「公開鍵認証」を設定してパスワードなしでログインできるようにするのが鉄則です。

1. 鍵ペアの作成（コントロールノード側）

まだ鍵を作っていない場合は、コントロールノードで作成します。
※Ansibleを実行するユーザー（例: admin）で行ってください。

# 鍵の作成（アルゴリズムはed25519推奨）
ssh-keygen -t ed25519 -C "ansible-control-node"

# パスフレーズは「なし（Enter連打）」にします
# ※自動実行時にパスフレーズ入力で止まらないようにするためです。

2. 公開鍵の転送

操作対象のサーバー（ターゲットノード）へ公開鍵を送ります。
ここではターゲットのIPを 192.168.1.50、ユーザーを admin とします。

ssh-copy-id admin@192.168.1.50

ここで一度だけ相手のパスワードを入力します。
成功すると、ターゲット側の ~/.ssh/authorized_keys に公開鍵が登録されます。

3. 接続確認

パスワードを聞かれずにログインできれば準備完了です。

ssh admin@192.168.1.50
# ログインできたら exit で戻ってくる

---

第4章：インベントリファイル（Inventory）の作成

Ansibleに対して「どのサーバーを操作するのか」を教える台帳を「インベントリ（Inventory）」と呼びます。
デフォルトでは /etc/ansible/hosts ですが、システム全体のファイルを使うのは管理しづらいため、プロジェクトごとにディレクトリを作って管理するのが一般的です。

1. 作業用ディレクトリの作成

ホームディレクトリ配下に作業場所を作ります。

mkdir ~/ansible-demo
cd ~/ansible-demo

2. hostsファイルの作成

hosts という名前でファイルを作成し、ターゲットサーバーのIPを記述します。

nano hosts

記述内容:

[webservers]
192.168.1.50

• [webservers]: グループ名です。後で「webserversグループに対してApacheを入れる」といった指定ができます。
• 192.168.1.50: ターゲットのIPアドレスまたはホスト名です。

---

第5章：Hello World! 最初のコマンド実行

準備が整いました。Ansibleを使って、ターゲットサーバーと疎通確認（Ping）を行ってみましょう。
Playbook（ファイル）を書かずに、コマンドラインで単発実行することを「Ad-Hoc（アドホック）コマンド」と呼びます。

Pingモジュールの実行

以下のコマンドを実行します。

ansible all -i hosts -m ping -u admin

コマンドの解説

• all: インベントリ内の「全てのサーバー」を対象にする。
• -i hosts: 作成したインベントリファイルを指定。
• -m ping: pingモジュールを使用する。
  （※ICMPのpingではなく、AnsibleがSSH接続してPythonを実行できるかを確認する専用モジュールです）
• -u admin: SSH接続するユーザー名を指定。

実行結果の読み解き方

以下のような緑色の文字が表示されれば大成功です！

192.168.1.50 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3"
    },
    "changed": false,
    "ping": "pong"
}

• SUCCESS: 接続と実行に成功したこと。
• “ping”: “pong”: pingモジュールからの返事。Pythonコードが正常に動いた証拠です。
• “changed”: false: サーバーの状態を「変更していない」こと。（単なる確認なので）

---

第6章：構成管理の威力を体感する

せっかくなので、もう一つコマンドを実行してみましょう。
「ターゲットサーバーの稼働時間（uptime）」を確認してみます。

ansible webservers -i hosts -a "uptime" -u admin

• webservers: グループ名を指定。
• -a "uptime": commandモジュール（デフォルト）の引数としてLinuxコマンドを渡す。

実行結果:

192.168.1.50 | CHANGED | rc=0 >>
 10:00:00 up 10 days,  2:30,  1 user,  load average: 0.00, 0.01, 0.05

SSHでログインしなくても、手元のPCから遠隔サーバーの状態を確認できました。
もしインベントリにIPアドレスが100個書いてあれば、この1行のコマンドだけで100台分のuptimeが一気に返ってきます。

これこそが、自動化の第一歩です。

---

まとめ：自動化への扉は開かれた

お疲れ様でした！
まずはAnsibleの環境構築と、最初の疎通確認まで完了しました。

今回の重要ポイント：

• Ansibleはエージェントレス。SSHとPythonがあれば動く。
• 「冪等性」により、何度実行しても安全な構成管理ができる。
• EPELリポジトリから簡単にインストール可能。
• まずは ping モジュールで “pong” を返すのが儀式。

しかし、毎回コマンドラインで -u admin や -i hosts と打つのは面倒ですし、パスワードを入力したくない場合にどうするかなど、まだ課題は残っています。
また、本番環境では「Webサーバー用」「DBサーバー用」など、もっと複雑なインベントリ管理が必要になります。

次回、第2回は「ターゲットを支配せよ。インベントリの書き方とansible.cfgの最適解」です。
今回簡易的に作った hosts ファイルのより高度な書き方（変数やグループ化）や、接続ユーザー・鍵設定を固定化してコマンドを短くする ansible.cfg の設定方法など、実践的な運用に向けた足場固めを行います。
もうオプションを毎回打つ必要はなくなります。お楽しみに！