宮崎智広 この記事の監修:宮崎智広(Linux実務・教育歴20年以上・受講者3,100名超)
「またあの作業か……」サーバーが増えるたびに、同じSSH接続と同じコマンド打鍵を繰り返していませんか?
10台ならまだ我慢できます。しかし20台・50台と増えた瞬間、手作業は「管理の限界」にぶつかります。

この記事では、構成管理ツール Ansible(アンシブル)の入門から実践的なPlaybook設計まで、完全初心者でも理解できるように解説します。
「コマンドを1台ずつ打つ」作業から卒業して、インフラ自動化の入口に立ちましょう。

この記事のポイント

・Ansibleはエージェント不要でSSH経由だけでサーバーを自動設定できる
・Inventoryで対象サーバーを定義し、Playbookで手順を宣言的に書く
・べき等性(何度実行しても同じ結果)がAnsibleの最大の強み
・セミナーLP(ansible.linuxmaster.jp)で実機ハンズオンを体験できる


「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
図解60P/登録10秒/解除も3秒 / 詳細はこちら

手作業が壊れる瞬間

サーバーが1~3台の頃は、手作業でも何とかなります。
しかし台数が増えると、次のような問題が次々と起きます。

・作業漏れ(あのサーバーだけ設定が古いまま)
・再現性の喪失(誰がいつ何をしたか分からない)
・ドキュメントの陳腐化(手順書は現実と乖離していく)
・属人化(担当者が休むと誰も触れない)

私がセミナーで受講生に最初に聞く質問があります。「サーバーの現在の設定状態、今すぐ全台分を紙1枚で出せますか?」。多くの方が沈黙します。

これが「管理の限界」のサインです。Ansibleはこの問題に対するシンプルな答えです。

Ansibleとは何か|構成管理の基本概念

Ansibleは、Red Hatが開発しているオープンソースの構成管理ツールです。
「サーバーをどういう状態にするか」をYAMLファイル(Playbook)で宣言しておき、それを自動的に適用します。

Ansibleの特徴を他のツールと比較すると、次の通りです。

特徴 Ansible 他のツール(Chef/Puppet等)
エージェント 不要(エージェントレス) 対象サーバーにエージェント導入が必要
通信経路 SSH(既存インフラそのまま) 専用ポート/プロトコル
記述言語 YAML(読みやすい) 独自DSL(学習コスト高め)
導入コスト 低い(PCにpip installだけ) 高い(サーバー全台にエージェント)
Ansibleが入門ツールとして選ばれるのは、「今日から始められる」シンプルさにあります。

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

グループ([webservers][dbservers])でサーバーを論理的に分類します。
後述の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

YAMLを読めば「このPlaybookは何をするか」が一目でわかります。
これが構成のドキュメント化でもある、というのが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

Ansibleはコントロールノード(自分のPC)にのみインストールします。
対象サーバーには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" }

「pong」が返れば、AnsibleからSSH接続できている証拠です。
この確認を必ず最初に行うことを習慣にしてください。

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

`changed: [192.168.1.101]` は「変更を加えた」、`ok` は「すでに期待通りの状態だったのでスキップ」を意味します。
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'

`{{ 変数名 }}` がJinja2テンプレート記法です。実行時に値が埋め込まれます。

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

設定ファイルが変更なし(ok)のときは、ハンドラーは実行されません。
不要な再起動を防げるのが、手作業との大きな違いです。

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 # デフォルト変数

Roleを使うと「webサーバーのRole」「DBサーバーのRole」を組み合わせてPlaybookを組み立てられます。
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

`ssh-copy-id` で公開鍵を送り直すか、`~/.ssh/authorized_keys` のパーミッション(600)を確認してください。

【エラー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サーバー構築の「型」を体系的に身につけたい方へ、20年以上の運用経験を持つ現役エンジニアが基礎から教えます。
Linux無料マニュアルを受け取る >>

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

登録10秒/合わなければ解除3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広(みやざき ともひろ)

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。


  • この記事の属するカテゴリ:Ansibleへ戻る