第2回 Ansibleを使って構築してみよう(前編)(1/2)

技術特集

第2回 Ansibleを使って構築してみよう(前編)

Ansible

はじめに

Playbookは一度作成してしまえば同じ内容で何度でもすぐに実行することができます。しかし、実案件においてはお客様毎に設定差異等あり、その都度Playbookを書いているととても手間がかかってしまいます。
第2回の前編ではPlaybookの基本的な書き方、第3回の後編では再利用等応用的な使い方に関して紹介します。

前回Ansibleには4種類のラインナップがある事を説明しましたが、今回はCUIツールのAnsibleを用いて実行環境の構築及びPlaybookの書き方、実行方法を簡単に紹介します。

OSS版(Ansible)と商用版(Ansible Engine)

OSS版(Ansible)と商用版(Ansible Engine)はほぼ同じため、本稿においてはOSS版(Ansible)を用います。また、RedHat系のフリーOSであるCentOS7上に導入する手順を紹介します。

Ansible環境の構築

CentOSの場合、Ansibleは標準のリポジトリに含まれており、標準パッケージマネージャのyumを用いてインストールする事が出来ます。SELinuxがインストールされている環境の操作も可能とするため、合わせてlibselinux-pythonもインストールします。

# yum update -y     事前にリポジトリの内容含め最新化しておきます
# yum install ansible libselinux-python
# ansible --version     バージョン情報が表示されればインストールが完了しています

標準リポジトリから入手したバージョンより新しいバージョンのAnsibleを使用したい場合は、標準外であるepelリポジトリから入手する必要があります。
なお、RHELでの導入の際は別途extraのリポジトリを有効化してからインストールを行います。

Ansibleを使用した環境構築

Ansibleを使用した構築を行う際にはPlaybookと呼ばれるファイルを作成する必要があります。
Playbookは環境構築に関する設定情報を定義したファイルであり、YAMLという形式で記載する事が出来ます。

Playbookは大きく、トップレベルのPlaybook(site.ymlという名称になっていることが多い)と Role用のPlaybook(トップレベルのPlaybookから呼び出される役割毎のPlaybook)の2種類で構成されています。
また、インベントリーファイルと呼ばれる、操作対象のサーバや機器を列挙したファイルも必要となります。

Ansibleを使用した環境構築

Playbookは身近な例で例えると演劇(英語でPlay)の台本のような物となります。
この台本は全体を束ねる台本(トップレベルのPlaybook)と役割毎に分けた台本(Role用Playbook)に分けて管理する事ができ、再利用や一部だけの変更が行いやすくなっています。更に、誰がどの役割かを分かるようにした配役表(インベントリーファイル)があるイメージです。

Ansibleのディレクトリ構成

Playbookやインベントリーファイルは適切な場所に配置する必要があります。この配置場所を事前に作成します。

再利用の観点から以下の構成を推奨します。このディレクトリ構成はベストプラクティスと呼ばれています。

Ansibleのディレクトリ構成

今回はApacheを例に、以下のようなディレクトリ、ファイルを作成します。

/data/playbook
   |- site.yml
   |- hosts
   |- roles
       |- apache
           |- tasks
               |- main.yml

このディレクトリ構成における「apache」をトップレベルのPlaybook内に記載し、apacheのRole用Playbookと紐づけます。「apache」ディレクトリと並行して、「tomcat」や「mysql」等様々なRole用Playbookを作成、配置する事が可能です。

トップレベルのPlaybook(図ではsite.yml)やインベントリーファイル(図ではhosts)のファイルの名称は任意ですが、Role用Playbookの「main.yml」は名称が固定となります。
トップレベルのPlaybook及びインベントリーファイルは同一ディレクトリ内に複数作成することが可能であり、他と同一のRole用Playbookを使用することが出来ます。

インベントリーファイルの作成

Playbookに記載した処理をどのサーバ/機器に対して実行するかを定義するファイルです。同一の処理を行う機器のグループ分けや、接続にあたって個別に必要となるユーザやパスワード等の記載を行います。

インベントリーファイルの作成

[]の中に記載した文字がグループに付ける名前です。
今回は例としてWebサーバ、APサーバ、DBサーバを構築する事を想定しましたため、webserver、apserver、dbserverというグループ名を付けています。
グループ名の下にホストのIPや名称(名前解決可能である事)、その他情報を記載します。1つのインベントリーファイル内に複数のグループがあっても問題ありません。

ログイン情報も記載する事は可能ですが、セキュリティ上の理由から、例のようなユーザ名・パスワードの直書きは非推奨となります。今回はサンプルのため直に書いていますが、実案件での利用時には鍵ファイル名の記載を行う等セキュリティリスクとならないよう工夫してください。

前述のApache構築用には以下のようなインベントリーファイルを用意しました。

[webserver]
172.21.11.142 ansible_user=root ansible_ssh_pass=password

webserverというグループを作成し、そのグループに172.21.11.142というホストが所属しています。このホストにはroot / passwordというユーザ/パスワードでログインする旨記載しています。

Playbookの作成

Playbookの記載に使用するYAMLは、インデントを使ってブロック構造(プログラミング言語では()や{}に相当)を表現する記法です。
インデントはスペースのみが使用可能です。開始位置があっていれば良いので特に数の制限はありませんが、スペース2個単位でインデントすることが多いようです。

Ansibleではハイフンから始まるブロック毎に設定情報を記載します。

Playbookの作成

例えば、ApacheをインストールするPlaybookを用意する場合、以下のようなトップレベルのPlaybookとRole用Playbookを作成します。

〇トップレベルのPlaybook:

---
- name: Install Apache
  hosts: webserver
  become: yes
  roles:
    - apache

トップレベルのPlaybookではRole用のPlaybookを呼び出す設定の他、以下のような項目を設定します。

設定項目 概要
Name このブロックにつけた名称を表す物で、実行時にこの名称とともに処理が成功したかどうかが画面に表示されますので、わかりやすい、任意の名称を付けます。
Hosts インベントリーファイル内に記載したグループ名を記載します。ここに記載したグループに対してPlaybookの処理が実行されます。
ここではwebserverという名称のグループを別途インベントリーファイル内で定義していますので、その名称を記載しています。
Become Root権限を使用する場合、或いは特定のユーザを使用する場合は、ここに記載を行います。
Roles 実際の処理を記載したRole用Playbookの読み込みを行います。
後述するディレクトリ構造においてRole用Playbookを「格納したディレクトリ名」を記載します。
ここではapacheというディレクトリ名にしています。

〇Role用Playbook:

---
- name: Install Apache
  yum:
    name: httpd
    state: latest
- name: Start httpd Service
  systemd:
    name: httpd
    state: started

実際の処理を定義するPlaybookです。使用するモジュールとそのモジュールが必要とするパラメータを記載します。例えば、以下のような項目を設定します。

設定項目 概要
Name このブロックにつけた名称を表す物で、実行時にこの名称とともに処理が成功したかどうかが画面に表示されますので、わかりやすい、任意の名称を付けます。
yum、systemd 使用するモジュール名が記載されています。
記載にあたってAnsibleのドキュメントサイト
http://docs.ansible.com/ansible/latest/modules/modules_by_category.html)を見ながら使用したいものを適宜選択します。
配下の、インデントされた状態で記載されている項目はそれぞれのモジュールが必要としているパラメータです。
name: 操作対象のサービス名
state: どうなっていて欲しいかの記載
例)
state: latest 最新がインストールされている状態
state: started 起動されている状態