10台ならまだ我慢できます。しかし20台・50台と増えた瞬間、手作業は「管理の限界」にぶつかります。
この記事では、構成管理ツール Ansible(アンシブル)の入門から実践的なPlaybook設計まで、完全初心者でも理解できるように解説します。
「コマンドを1台ずつ打つ」作業から卒業して、インフラ自動化の入口に立ちましょう。
この記事のポイント
・Ansibleはエージェント不要でSSH経由だけでサーバーを自動設定できる
・Inventoryで対象サーバーを定義し、Playbookで手順を宣言的に書く
・べき等性(何度実行しても同じ結果)がAnsibleの最大の強み
・セミナーLP(ansible.linuxmaster.jp)で実機ハンズオンを体験できる
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
手作業が壊れる瞬間
サーバーが1~3台の頃は、手作業でも何とかなります。しかし台数が増えると、次のような問題が次々と起きます。
・作業漏れ(あのサーバーだけ設定が古いまま)
・再現性の喪失(誰がいつ何をしたか分からない)
・ドキュメントの陳腐化(手順書は現実と乖離していく)
・属人化(担当者が休むと誰も触れない)
私がセミナーで受講生に最初に聞く質問があります。「サーバーの現在の設定状態、今すぐ全台分を紙1枚で出せますか?」。多くの方が沈黙します。
これが「管理の限界」のサインです。Ansibleはこの問題に対するシンプルな答えです。
Ansibleとは何か|構成管理の基本概念
Ansibleは、Red Hatが開発しているオープンソースの構成管理ツールです。「サーバーをどういう状態にするか」をYAMLファイル(Playbook)で宣言しておき、それを自動的に適用します。
Ansibleの特徴を他のツールと比較すると、次の通りです。
| 特徴 | Ansible | 他のツール(Chef/Puppet等) |
|---|---|---|
| エージェント | 不要(エージェントレス) | 対象サーバーにエージェント導入が必要 |
| 通信経路 | SSH(既存インフラそのまま) | 専用ポート/プロトコル |
| 記述言語 | YAML(読みやすい) | 独自DSL(学習コスト高め) |
| 導入コスト | 低い(PCにpip installだけ) | 高い(サーバー全台にエージェント) |
1. べき等性(idempotency)とは
Ansibleを理解するうえで最重要の概念がべき等性です。「ユーザーを作成する」という処理を10回実行しても、ユーザーは1つしか作られません。
「Apacheをインストールする」を5回実行しても、インストールは1回だけで、その後は「already installed」とスキップされます。
つまり、Playbookを何度実行しても結果は同じ。これがべき等性です。
手作業で「このサーバー、もうApache入ってるっけ?」と確認する必要が消えます。
2. Push型とPull型
AnsibleはPush型です。自分のPC(コントロールノード)から対象サーバーへSSHで接続し、設定を送り込みます。Chef/Puppetはサーバー側のエージェントが設定サーバーを見に行くPull型。
Push型は「すぐ試せる」のが強みです。対象サーバーに何もインストールしなくていいので、既存の本番環境にも適用しやすい。
Ansibleの主要コンポーネントを理解する
Ansibleは「Inventory」「Playbook」「Module」の3つで動きます。1. Inventory(インベントリ)
「どのサーバーに対して作業するか」を定義するファイルです。# /etc/ansible/hosts または任意の場所に置く # 例: inventory.ini [webservers] web01.example.com web02.example.com 192.168.1.101 [dbservers] db01.example.com 192.168.1.201 [all:vars] ansible_user=ec2-user ansible_ssh_private_key_file=~/.ssh/my_key.pem
後述のPlaybookでグループ名を指定すれば、グループ全台に一括適用できます。
2. Playbook(プレイブック)
「何をするか」を宣言するYAMLファイルです。Playbookは1つ以上の「Play」で構成され、各Playは「対象ホスト」と「タスクのリスト」を持ちます。
# install_apache.yml の例 --- - name: Apacheのインストールと起動 hosts: webservers # Inventoryのグループ名 become: yes # sudo権限を使う tasks: - name: Apacheをインストールする ansible.builtin.dnf: name: httpd state: present # インストール済み状態にせよ - name: Apacheを起動して自動起動を有効にする ansible.builtin.service: name: httpd state: started enabled: yes - name: firewalldでhttpを許可する ansible.builtin.firewalld: service: http permanent: yes state: enabled immediate: yes
これが構成のドキュメント化でもある、というのがAnsibleの設計思想です。
3. Module(モジュール)
各タスクで実際に処理を行う「機能単位」です。上の例では `dnf`(パッケージ管理)・`service`(サービス制御)・`firewalld`(ファイアウォール)がモジュールです。
Ansibleには3,000以上のモジュールが標準搭載されています。
・`ansible.builtin.copy` — ファイルをコピーする
・`ansible.builtin.template` — Jinja2テンプレートを展開する
・`ansible.builtin.user` — ユーザーを作成・削除する
・`ansible.builtin.cron` — crontabに登録する
・`ansible.builtin.git` — Gitリポジトリをクローンする
「やりたいこと」が決まったら、まずモジュールを探す、という流れになります。
実際に動かしてみる|環境構築からPlaybook実行まで
ここからは、実際に手を動かして理解を深めます。自分のPC(Ubuntu/RHEL/AlmaLinux等)をコントロールノードとし、別の検証サーバーへ接続するシナリオです。
1. Ansibleのインストール(コントロールノード側)
# RHEL 9 / AlmaLinux 9 の場合 $ sudo dnf install -y epel-release $ sudo dnf install -y ansible # Ubuntu 22.04 / 24.04 の場合 $ sudo apt update $ sudo apt install -y ansible # バージョン確認 $ ansible --version ansible [core 2.16.x] config file = /etc/ansible/ansible.cfg python version = 3.11.x
対象サーバーにはSSHでログインできること、Pythonがインストールされていること(RHEL 9標準搭載)の2点だけ必要です。
2. SSH鍵認証の準備
Ansibleは内部でSSHを使います。パスワード認証も動きますが、鍵認証を推奨します。# 自分のPCで鍵ペアを生成(すでにある場合はスキップ) $ ssh-keygen -t ed25519 -C "ansible-key" # 対象サーバーへ公開鍵をコピー $ ssh-copy-id -i ~/.ssh/id_ed25519.pub user@192.168.1.101 # 接続確認 $ ssh user@192.168.1.101 "hostname" web01
3. Inventoryの作成とping確認
# inventory.ini を作成 $ cat inventory.ini [webservers] 192.168.1.101 ansible_user=ec2-user [dbservers] 192.168.1.201 ansible_user=ec2-user # Ansibleのpingモジュールで疎通確認 $ ansible -i inventory.ini webservers -m ping 192.168.1.101 | SUCCESS => { "changed": false, "ping": "pong" }
この確認を必ず最初に行うことを習慣にしてください。
4. Playbookの実行
# install_apache.yml を実行 $ ansible-playbook -i inventory.ini install_apache.yml PLAY [Apacheのインストールと起動] ***** TASK [Gathering Facts] **** ok: [192.168.1.101] TASK [Apacheをインストールする] **** changed: [192.168.1.101] TASK [Apacheを起動して自動起動を有効にする] **** changed: [192.168.1.101] TASK [firewalldでhttpを許可する] **** changed: [192.168.1.101] PLAY RECAP ***** 192.168.1.101 : ok=4 changed=3 unreachable=0 failed=0
2回目に同じPlaybookを実行すると、全て `ok` になります。これがべき等性の動作です。
Ansible実機ハンズオンはこちら
「実際に手を動かして覚えたい」方には、Linux Master Pro Seminarのハンズオン講座がおすすめです。
Ansible PlaybookをゼロからRHEL環境で書き、複数サーバーへ自動適用する体験ができます。
>> Ansibleハンズオン講座の詳細を見る
実務で使えるPlaybook設計パターン
基本を覚えたら、実務で使えるパターンを押さえましょう。1. 変数(vars)でPlaybookを汎用化する
ハードコードを避けて変数で柔軟に書くのが実務の鉄則です。--- - name: Webサーバーのセットアップ hosts: webservers become: yes vars: http_port: 80 document_root: /var/www/html app_user: webadmin tasks: - name: アプリユーザーを作成する ansible.builtin.user: name: "{{ app_user }}" state: present - name: ドキュメントルートのディレクトリを作成する ansible.builtin.file: path: "{{ document_root }}" state: directory owner: "{{ app_user }}" mode: '0755'
2. ハンドラー(handler)で条件付き再起動
設定ファイルを変更したときだけApacheをリロードしたい、というケースにハンドラーを使います。tasks: - name: httpd.confを配置する ansible.builtin.template: src: httpd.conf.j2 dest: /etc/httpd/conf/httpd.conf notify: Restart Apache # 変更があった時だけハンドラーを呼ぶ handlers: - name: Restart Apache ansible.builtin.service: name: httpd state: restarted
不要な再起動を防げるのが、手作業との大きな違いです。
3. Roleで再利用可能な構造にする
複数のPlaybookで同じ処理が重複してきたら、Roleでまとめます。# ansible-galaxy コマンドでRoleの雛形を生成 $ ansible-galaxy role init roles/webserver roles/webserver/ ├── tasks/ │ └── main.yml # タスク定義 ├── handlers/ │ └── main.yml # ハンドラー定義 ├── vars/ │ └── main.yml # 変数定義 ├── templates/ │ └── httpd.conf.j2 # Jinja2テンプレート └── defaults/ └── main.yml # デフォルト変数
Ansible Galaxy(https://galaxy.ansible.com/)には公式・コミュニティ製のRoleが公開されており、再利用できます。
トラブルシュート|よくあるエラーと対処法
【エラー1】「Permission denied (publickey)」
SSH鍵認証が通っていない状態です。# 対処: SSHの詳細ログで原因を特定する $ ssh -vvv user@192.168.1.101 # ansible側でも詳細モードで確認 $ ansible -i inventory.ini webservers -m ping -vvv
【エラー2】「sudo: a password is required」
become: yes を使っているが、sudoがパスワードなしで実行できない設定の場合に出ます。# 対処1: 実行時にsudoパスワードを渡す $ ansible-playbook -i inventory.ini playbook.yml --ask-become-pass # 対処2: 対象サーバーのsudoersをパスワードなしに設定(推奨) # /etc/sudoers に以下を追記(visudoで編集) ansible_user ALL=(ALL) NOPASSWD:ALL
【エラー3】「UNREACHABLE! - Failed to connect to the host」
SSHポート・ファイアウォール・ホスト名解決の問題が多いです。# 手動SSH接続で確認する(Ansibleの問題かSSHの問題かを切り分ける) $ ssh -p 22 user@192.168.1.101 # 非標準ポートを使っている場合はInventoryに指定 [webservers] 192.168.1.101 ansible_port=2222 ansible_user=ec2-user
【エラー4】「MODULE FAILURE: No module named 'selinux'」
RHEL系でSELinux関連モジュールを使う際に起きます。# コントロールノードにlibselinuxのPythonバインディングを入れる $ sudo dnf install -y python3-libselinux
Ansible導入の設計指針|どこから始めるか
「いきなりAnsibleで全環境を管理する」は大げさに聞こえるかもしれません。実際には、次のステップで段階的に広げるのが現場での正解です。
・Stage 1 — 定型作業を1つPickUp(例: Apacheのインストール)して最初のPlaybookを書く
・Stage 2 — 検証サーバーで動くことを確認してGit管理を始める
・Stage 3 — 本番環境の作業手順書を順次Playbook化する
・Stage 4 — Role化・CI/CDパイプラインと統合する
「全部Ansible化してから使う」ではなく「使いながら広げる」が継続のコツです。
私のセミナーでも、Ansible未経験の方が1日でPlaybookを書いてRHEL環境に適用するところまで到達します。
重要なのは「完璧な設計」ではなく「最初の1本を動かす体験」です。
本記事のまとめ
Ansibleを使った構成管理の要点を整理します。| 概念 | 役割 |
|---|---|
| Inventory | 「どのサーバーに対して」作業するかを定義する |
| Playbook | 「何をするか」をYAMLで宣言する |
| Module | 各タスクで実行する処理単位(3,000以上搭載) |
| べき等性 | 何度実行しても同じ状態になる性質 |
| Handler | 変更があった時だけ実行する後処理(サービス再起動等) |
| Role | Playbookを再利用可能な構造にまとめる仕組み |
Ansibleが解決するのは「手作業の繰り返し」だけではありません。
インフラの状態をコードとして記録・管理するという考え方そのものです。
「サーバーが今どういう状態か」がPlaybookを読めば分かる。
「この変更を全台に適用する」がコマンド1本で終わる。
これが、Ansibleを導入したチームが実感する最大の変化です。
次のステップとして、実機を使ったハンズオンで定着させることをおすすめします。
Ansibleハンズオン講座(ansible.linuxmaster.jp)では、RHEL 10対応の実践的な内容を少人数で体験できます。
「手を動かして理解した」という確信を持ちたい方は、ぜひ詳細をご覧ください。
Linux無料マニュアルを受け取る >>
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒/合わなければ解除3秒 / 詳細はこちら
- この記事の属するカテゴリ:Ansibleへ戻る

無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます