※本記事にはプロモーションを含む場合があります。

  • Ansibleはエージェントレスで動作し、SSH接続のみで管理対象サーバーへの構成適用が可能
  • YAML形式のプレイブックは学習コストが低く、未経験者でも1週間ほどで基本操作を習得できるとされています
  • 公式モジュールは2,000種類以上あり、パッケージ管理・ユーザー管理・サービス管理まで幅広くカバー
  • Chef・Puppet・SaltStackと比較すると導入コストや学習期間の面で優位性があるといわれています
  • Ansible Vaultを使えばパスワードやAPIキーなどの機密情報を暗号化した状態でGit管理に載せられる

Ansibleとは何か？

Ansibleは、Red Hat社が開発を主導するオープンソースの構成管理ツールです。2015年にRed Hatが買収して以降、企業のITインフラ自動化ツールとして採用が拡大し、公式サイトの情報では世界10,000社以上で利用されているとされています。もっとも大きな特徴は「エージェントレス」で動作する点です。ChefやPuppetのように管理対象サーバー側に専用のエージェントソフトをインストールする必要がなく、SSH接続とPythonがあれば構成管理を始められます。この仕組みにより、導入時のサーバー側作業がほぼゼロになり、既存環境への影響を抑えながら自動化を進められます。

もう一つの強みは「冪等性（Idempotency）」です。同じプレイブックを何度実行しても、既に望んだ状態になっているタスクはスキップされ、状態が変化する場合のみ処理が実行されます。これにより、手順書を毎回目視で確認しながら手作業するオペレーションと比べて、ヒューマンエラーの発生率を大幅に下げられるといわれています。加えて、YAML形式のプレイブックは自然言語に近い書き方ができるため、インフラエンジニアだけでなく開発者やSRE担当者でも読み書きしやすい構造になっています。

Ansibleの主な特徴を整理すると以下のとおりです。

  • エージェントレス：管理対象サーバーに専用ソフトのインストールが不要
  • シンプルな構文：YAML形式で記述でき、学習コストが低い
  • 冪等性：同じ設定を何度実行しても同じ結果を得られる
  • 豊富なモジュール：2,000種類以上の公式モジュールが提供されている
  • 拡張性：独自モジュールやプラグインを自作できる

ChefやPuppetは宣言的な独自DSL、またはRubyベースの記述が必要になる場面が多く、学習に1〜2ヶ月ほどかかるケースも見られます。一方Ansibleは、YAMLの基本構文さえ理解すれば、数日〜1週間程度で最初のプレイブックを書けるようになったという声も少なくありません。この学習コストの低さが、中小規模のインフラチームからも選ばれる理由のひとつになっています。

環境構築の手順

Ansibleを使い始めるには、まず制御ノード（Ansibleを実行する端末）に環境を用意します。AnsibleはPython上で動作するため、Python 3.9以上がインストールされていれば主要なOSで動作します。ここでは、Linux・macOS・Windowsそれぞれのインストール手順と、初期設定ファイル（ansible.cfg）の基本項目を解説します。

  1. 制御ノードのOSを確認する（Ubuntu/Debian、CentOS/RHEL、macOS、Windows+WSLのいずれか）
  2. OSに応じたパッケージマネージャー（apt・yum・Homebrew）でAnsibleをインストールする
  3. ansible --versionでインストールされたバージョンを確認する
  4. プロジェクト用ディレクトリを作成し、ansible.cfgとinventoryファイルを配置する
  5. ansible all -m pingで管理対象サーバーへの疎通確認を行う

Linux（Ubuntu/Debian）の場合

# パッケージリストの更新
sudo apt update

# 必要なパッケージのインストール
sudo apt install -y software-properties-common

# AnsibleのPPAリポジトリを追加
sudo add-apt-repository --yes --update ppa:ansible/ansible

# Ansibleのインストール
sudo apt install -y ansible

# バージョン確認
ansible --version

Linux（CentOS/RHEL）の場合

# EPELリポジトリの有効化
sudo yum install -y epel-release

# Ansibleのインストール
sudo yum install -y ansible

macOSの場合

# Homebrewの更新
brew update

# Ansibleのインストール
brew install ansible

Windowsの場合

公式にはWindowsを制御ノードとしてサポートしていないため、Windows Subsystem for Linux（WSL）上にLinux環境を構築する方法が一般的です。PowerShellでwsl --installを実行し、Ubuntuなどのディストリビューションを導入したうえで、WSL内のターミナルから前述のLinux手順に従ってインストールします。この方法であれば、追加費用0円で既存のWindows PCをAnsible実行環境に転用できます。

インストール後は、ansible.cfgで動作をカスタマイズします。以下は基本的な設定例です。

[defaults]
inventory = ./inventory
remote_user = ansible
private_key_file = ~/.ssh/id_rsa
host_key_checking = False
retry_files_enabled = False

host_key_checkingをFalseにすると初回SSH接続時のホストキー確認が省略され、検証環境での作業時間を数分単位で短縮できます。ただし、本番環境ではセキュリティ上のリスクがあるため、運用フェーズではTrueに戻す運用ルールを設けておくと安心です。

基本概念を理解する

Ansibleを使いこなすうえで欠かせないのが「インベントリ」「プレイブック」「モジュール」という3つの概念です。ここを押さえておくと、公式ドキュメントを読み進める際の理解速度が大きく変わります。

インベントリファイルは、管理対象サーバーの一覧を定義するファイルで、INI形式とYAML形式のどちらでも記述できます。以下はINI形式の例です。

[webservers]
web1.example.com
web2.example.com

[dbservers]
db1.example.com
db2.example.com

[all:vars]
ansible_user=ansible
ansible_ssh_private_key_file=~/.ssh/id_rsa

同じ内容をYAML形式で書くと以下のようになります。

all:
  hosts:
    web1.example.com:
      ansible_user: ansible
    web2.example.com:
      ansible_user: ansible
  children:
    webservers:
      hosts:
        web1.example.com:
        web2.example.com:
    dbservers:
      hosts:
        db1.example.com:
        db2.example.com:

作成後はansible all -m pingで疎通確認を行います。成功すると各ホストから”pong”というレスポンスが返り、SSH接続と認証情報が正しく設定されていることが確認できます。

プレイブックは、実行するタスクを順番に記述するYAMLファイルです。以下はApache HTTP Serverをインストールし起動する例です。

---
- name: Apache HTTP Serverのインストールと起動
  hosts: webservers
  become: yes
  tasks:
    - name: Apache HTTP Serverのインストール
      apt:
        name: apache2
        state: present
      when: ansible_os_family == 'Debian'

    - name: Apache HTTP Serverの起動
      service:
        name: apache2
        state: started
        enabled: yes
      when: ansible_os_family == 'Debian'

実行コマンドはansible-playbook playbook.ymlの1行のみです。数十台規模のサーバーであっても、同じ1コマンドで一括適用できる点が手作業運用との大きな違いです。

モジュールは個々のタスクを実行する機能単位で、公式だけで2,000種類以上が提供されています。代表的なものは以下のとおりです。

  • apt / yum：パッケージ管理（インストール・更新・削除）
  • copy：ローカルファイルをリモートサーバーへ配置
  • template：Jinja2テンプレートを展開して設定ファイルを生成
  • service：サービスの起動・停止・再起動・自動起動設定
  • command / shell：任意のコマンド実行（shellはパイプ・リダイレクトに対応）
# nginxのインストール（Debian系）
- name: nginxのインストール
  apt:
    name: nginx
    state: present
    update_cache: yes

# 設定ファイルのコピー
- name: 設定ファイルをコピー
  copy:
    src: /path/to/local/file.conf
    dest: /etc/nginx/conf.d/file.conf
    owner: root
    group: root
    mode: '0644'

実践的な活用例

基本を押さえたら、実務で頻出するユースケースに落とし込んでいきます。ここではパッケージ管理・ユーザー管理・サービス管理という3つの自動化例を紹介します。いずれも数台〜数百台規模のサーバーに対して、同一のプレイブックで一括適用できる点が実務上のメリットです。

パッケージ管理の自動化

---
- name: 複数のパッケージをインストール
  hosts: all
  become: yes
  tasks:
    - name: 必要なパッケージをインストール
      apt:
        name:
          - nginx
          - mysql-server
          - php
          - php-mysql
        state: present
        update_cache: yes
      when: ansible_os_family == 'Debian'

when条件を使うことで、OSの種類ごとに異なるパッケージ管理コマンド（apt/yum）を1つのプレイブック内で出し分けられます。手動でサーバーごとにコマンドを打ち分ける作業と比べると、10台規模の環境でも作業時間を数十分から数分程度まで短縮できたという事例も見られます。

ユーザー管理の自動化

---
- name: ユーザーの作成とSSHキーの設定
  hosts: all
  become: yes
  vars:
    new_user: deploy
    ssh_public_key: "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQ..."
  tasks:
    - name: ユーザーを作成
      user:
        name: "{{ new_user }}"
        groups: sudo
        shell: /bin/bash
        state: present

    - name: SSHディレクトリを作成
      file:
        path: "/home/{{ new_user }}/.ssh"
        state: directory
        owner: "{{ new_user }}"
        mode: '0700'

    - name: SSH公開鍵を配置
      copy:
        content: "{{ ssh_public_key }}"
        dest: "/home/{{ new_user }}/.ssh/authorized_keys"
        owner: "{{ new_user }}"
        mode: '0600'

varsセクションで変数化しておくことで、対象ユーザー名や公開鍵だけを差し替えれば、新入社員のアカウント発行やアクセス権限の棚卸しといった定型作業も横展開できます。

サービス管理の自動化

---
- name: Nginxサービスの管理
  hosts: webservers
  become: yes
  tasks:
    - name: Nginxサービスを起動
      service:
        name: nginx
        state: started
        enabled: yes

stateをstarted・stopped・restartedのいずれかに変更するだけで、起動・停止・再起動を切り替えられます。深夜メンテナンスなどで数十台のサービスを一括再起動する場面では、手作業に比べて対応時間を80%ほど圧縮できたという運用報告もあります。

応用技術を使う

基本操作に慣れてきたら、ロール・Jinja2テンプレート・Ansible Vaultという3つの応用技術を取り入れることで、プレイブックの保守性とセキュリティを底上げできます。

ロールによる再利用可能な構成管理

ロールは構成管理を再利用可能な単位に分割する仕組みで、defaults・tasks・handlers・templates・files・varsといったディレクトリで構成されます。

roles/
└── nginx/
    ├── defaults/
    │   └── main.yml
    ├── tasks/
    │   └── main.yml
    ├── handlers/
    │   └── main.yml
    ├── templates/
    │   └── nginx.conf.j2
    └── vars/
        └── main.yml

プレイブック側では以下のようにロールを呼び出すだけで済みます。

---
- name: Nginxを設定
  hosts: webservers
  become: yes
  roles:
    - nginx

複数プロジェクトで同じNginx設定ロールを使い回せるため、新規プロジェクト立ち上げ時の初期構築工数を数日単位で削減できたという声もあります。

Jinja2テンプレートによる動的設定

user {{ nginx_user }};
worker_processes {{ ansible_processor_vcpus }};

events {
    worker_connections {{ nginx_worker_connections }};
}

http {
    server {
        listen {{ nginx_port }};
        server_name {{ nginx_server_name }};
    }
}

変数をプレイブックやインベントリ側で定義しておけば、開発・検証・本番の3環境で設定値だけを切り替え、同一テンプレートを使い回せます。環境差分による設定ミスの発生率を下げる効果が期待できるとされています。

Ansible Vaultによる機密情報の暗号化

# 暗号化ファイルの新規作成
ansible-vault create secrets.yml

# 暗号化ファイルの編集
ansible-vault edit secrets.yml

# 実行時にパスワードを入力
ansible-playbook playbook.yml --ask-vault-pass

db_passwordやapi_keyといった機密情報を平文のままGitリポジトリに置くと漏えいリスクが高まりますが、Vaultで暗号化しておけばリポジトリ上は暗号文字列として保存されます。CI/CDパイプラインで自動化する場合は、Vaultパスワード自体を環境変数やHashiCorp Vaultなど外部の秘密管理サービスと連携させる運用がすすめられています。

他ツールとの比較

構成管理ツールにはAnsible以外にもChef・Puppet・SaltStackなどの選択肢があります。導入前にそれぞれの特徴を比較しておくと、自社の環境に合ったツール選定がしやすくなります。

ツールエージェント記述言語学習コストの目安主な利用シーン
Ansible不要（エージェントレス）YAML1週間程度中小〜大規模のインフラ自動化全般
Chef必要Ruby DSL1〜2ヶ月程度細かいカスタマイズが必要な大規模環境
Puppet必要独自DSL1ヶ月程度宣言的な状態管理を重視する現場
SaltStack任意（エージェントレスも可）YAML+Python2〜3週間程度大規模かつ高速な並列実行が必要な環境

ライセンス費用の面では、いずれのツールもコア機能はオープンソースで0円から利用を開始できますが、エンタープライズ向けサポートやGUI管理コンソール（Ansible Automation Platform、Chef Automate、Puppet Enterpriseなど）を導入する場合は、サーバー台数やノード数に応じて年間数十万円〜数百万円規模の費用がかかるケースがあるとされています。小規模チームであれば、まずオープンソース版のAnsibleで運用を始め、管理対象が100台を超えるタイミングで有償プラットフォームへの移行を検討する進め方が一般的です。

トラブル対処法

Ansibleの運用では、SSH接続まわりや変数展開に関するトラブルが起きやすい傾向があります。代表的な事象と対処法を以下にまとめます。

トラブル主な原因対処法
SSH接続エラー鍵の設定ミス、ホストキー不一致、ファイアウォール制限SSH接続を単体でテストし、host_key_checkingをFalseに設定して再確認する
モジュールが見つからないAnsibleのバージョンが古い、モジュール未インストールAnsibleを最新版へアップデートし、必要モジュールをpipで追加する
タスクが失敗するwhen条件の誤り、権限不足条件式を見直し、become: yesでroot権限を付与する
変数が展開されない変数名のタイプミス、スコープの誤りvars_filesやgroup_vars、host_varsで定義箇所を確認する
実行速度が遅いforksの並列数不足、SSHタイムアウトforksパラメータを増やし、SSH接続のタイムアウト値を延長する

forksのデフォルト値は5に設定されているため、対象サーバーが50台を超える環境では、forksを20〜30程度まで引き上げることで実行時間を数分単位で短縮できるケースがあります。ただし、値を上げすぎると管理対象サーバー側のSSHデーモンに負荷がかかるため、段階的に調整するやり方が無難です。

本番環境へ適用する前には、以下のチェックリストで最終確認をしておくと事故を防ぎやすくなります。

  • □ ステージング環境でプレイブックの動作確認を済ませたか
  • □ –check オプションによるドライラン（差分確認）を実施したか
  • □ ansible-lintでYAML構文とベストプラクティス違反をチェックしたか
  • □ Ansible Vaultで機密情報を暗号化しているか
  • □ 実行対象のインベントリ範囲（hosts指定）に誤りがないか
  • □ ロールバック手順（バックアップ・スナップショット）を用意しているか

特にhosts: allのまま検証環境で試したプレイブックを本番用インベントリに誤って流用してしまうミスは起こりやすく、実行前の–checkオプション確認だけで防げるトラブルの割合は高いといわれています。プレイブックのモジュール化（ロール化）、group_vars・host_varsによる変数管理、全タスクの冪等性確保という3点は、運用が長期化するほど効果を実感しやすいポイントです。

よくある質問

Q1. Ansibleは無料で使えますか？
コア機能はオープンソースとして0円で利用できます。企業向けのGUI管理基盤であるAnsible Automation Platformなど有償版は、ノード数に応じた年間契約となるケースがあるとされています。

Q2. Ansibleを学ぶのにどれくらいの期間が必要ですか？
YAMLの基本文法さえ理解していれば、簡単なプレイブックの作成までは数日〜1週間程度で到達できたという声が多く見られます。ロールやVaultまで含めた実務レベルの習得には、1〜2ヶ月ほど継続して触る時間が目安になるといわれています。

Q3. WindowsサーバーもAnsibleで管理できますか？
管理対象としてのWindowsサーバーはWinRMを使った専用モジュールで管理できます。ただし、Ansibleを実行する制御ノード自体はLinux/macOSが前提のため、Windows端末から実行する場合はWSLの利用がすすめられています。

Q4. ChefやPuppetからAnsibleへの移行は難しいですか？
既存のレシピやマニフェストをそのまま流用することはできませんが、YAML形式で書き直す作業自体は、既存の構成情報が整理されていれば数週間程度で移行できたという事例があります。段階的に一部のサーバー群からAnsible化していく進め方が現実的です。

Q5. Ansibleの実行速度を上げるにはどうすればいいですか？
forksパラメータの引き上げ、SSH接続のパイプライン化（pipelining = True）、不要なfacts収集の無効化（gather_facts: no）といった設定変更で、実行時間を体感で20〜30%程度短縮できたという報告があります。

Q6. 機密情報はどこで管理するのが安全ですか？
Ansible Vaultで暗号化してリポジトリに含める方法に加え、CI/CD環境ではHashiCorp Vaultなど外部の秘密管理サービスと連携させる構成もよく採用されています。Vaultパスワード自体を平文でリポジトリに置かない運用ルールを徹底しておくことがポイントです。

【編集・制作ポリシー】
本記事はInfra Academy編集部が各ベンダー公式ドキュメント・エンジニア監修をもとに作成しています。インフラ・クラウド構築は環境により異なります。本番環境への適用前に必ずテストを実施してください。情報の正確性には万全を期していますが、最新情報は各公式ドキュメントをご確認ください。 編集ポリシーはこちら

おすすめ: Amazon技術書｜インフラ・クラウド・ネットワーク

ABOUT ME
たから
フリーランスIT講師/エンジニア。 ◆経験：IT講師/インフラエンジニア/PM/マネジメント/採用/運用・保守・構築・設計 ◆取得資格：CCNA/CCNP/LPIC-1/AZ-900//サーティファイC言語/情報処理技術者 ◆サイドビジネス：アパレル事業/複数のWEBメディアを運営