実践!Ansibleベストプラクティス(前編)

ansible_best_practices

今回はAnsibleを本格運用した際のイメージを掴むためにAnsibleのベストプラクティスを参考に実際に試してみたいと思います。

実践のお題はWordPressとします。WordPressのセットアップを通してベストプラクティスのイメージを掴んでいただければと思います。

準備

ローカルマシンに作業ディレクトリを作り、その中でAnsibleのベストプラクティスに則ったプレイブックを作っていきます。MacもしくはLinuxなどで試してみてください。

$ mkdir try-ansible-best-practices
$ cd try-ansible-best-practices

ウェブサーバとDBサーバを別個に立てますので、さくらのクラウドでサーバを二台立てておきます。OSはCentOS 6.6を利用します。サーバ作成時にrootでのsshの接続に必要となる公開鍵も忘れずに登録してください。

ディレクトリレイアウトの確認

手を動かす前にベストプラクティスで推奨されているディレクトリレイアウトをざっと俯瞰してみましょう。

Ansibleのベストプラクティスの内容を引用しつつ見ていきます。

インベントリファイル

まずはインベントリファイルです。本番環境やステージング環境など、環境ごとにサーバのホストとグループをまとめます。

production                # inventory file for production servers
stage                     # inventory file for stage environment

次にグループやホストごとの変数を定義するファイルがあります。

group_vars/
   group1                 # here we assign variables to particular groups
   group2                 # ""
host_vars/
   hostname1              # if systems need specific variables, put them here
   hostname2              # ""

グループやホストはインベントリファイルに記述したものとなります。これらの変数はインベントリファイルに含めることもできますが、ベストプラクティスでは別個のファイルに切り出すようになっています。

トップレベルのプレイブック

マスタープレイブックとしてsite.ymlがあります。

site.yml                  # master playbook

そしてその配下にサーバの役割ごとにロールをまとめたプレイブックを作ります。

webservers.yml            # playbook for webserver tier
dbservers.yml             # playbook for dbserver tier

これらのファイルはロールをインクルードするだけに留め、ここに細かいタスクを書いていくことはしません。

ロール

ロールはプレイブックの一連のタスク、ハンドラ、ファイル、テンプレートなどをまとめたものです。Chefで言うクックブックのようなものでしょうか。

具体的なセットアップのタスクはロールに書いていきます。

roles/
    common/               # this hierarchy represents a "role"
        tasks/            #
            main.yml      #  <-- tasks file can include smaller files if warranted
        handlers/         #
            main.yml      #  <-- handlers file
        templates/        #  <-- files for use with the template resource
            ntp.conf.j2   #  <------- templates end in .j2
        files/            #
            bar.txt       #  <-- files for use with the copy resource
            foo.sh        #  <-- script files for use with the script resource
        vars/             #
            main.yml      #  <-- variables associated with this role
        defaults/         #
            main.yml      #  <-- default lower priority variables for this role
        meta/             #
            main.yml      #  <-- role dependencies

    webtier/              # same kind of structure as "common" was above, done for the webtier role
    monitoring/           # ""
    fooapp/               # ""

適切に切り分けられたロールはプレイブックの再利用性も高めてくれます。Ansibleを本格的に運用していくためには必須の概念と言えるでしょう。

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

さて、ではここからは実際に手を動かしていきましょう。

開発環境のサーバと言うことでインベントリファイル名はproductionでもなくstageでもなくdevelopmentとしてみます。

ベストプラクティスに従ったインベントリファイルでは地域と役割ごとのグループを作って、それを役割ごと地域ごとのグループに束ねます。

複数リージョンにまたがったサーバ構築というのはほとんどのサービスには不要かと思いますが、従っておいてマイナスはないので、倣っておきましょう。

development

IPアドレスは実際に作成したサーバのIPアドレスに置き換えてください。

[ishikari-2-webservers]
xxx.xxx.xxx.xxx

[ishikari-2-dbservers]
yyy.yyy.yyy.yyy

# webservers in all geos
[webservers:children]
ishikari-2-webservers

# dbservers in all geos
[dbservers:children]
ishikari-2-dbservers

# everything in the ishikari-2 geo
[ishikari-2:children]
ishikari-2-webservers
ishikari-2-dbservers

どのリージョンを使っているか分かりやすくなるのがいいですね。

それぞれのグループごとにプレイブックを適用できるので、ウェブサーバのみ、DBサーバのみ、特定リージョンのサーバのみを更新するといったことも簡単にできます。

トップレベルのプレイブックの作成

次にトップレベルのプレイブックを作成していきましょう。

まずはマスタープレイブックのsite.ymlです。

site.yml

---
- include: webservers.yml
- include: dbservers.yml

site.ymlはこのように極めてシンプルに保ちます。

そしてsite.ymlから読み込むグループごとのプレイブックを同じくトップレベルのディレクトリに作成します。

webservers.yml

---
- hosts: webservers
  roles:
    - common

dbservers.yml

---
- hosts: dbservers
  roles:
    - common

これらのファイルも極めてシンプルな内容に保ちます。

事始めとして基本的な設定を行うということでcommonというロールを読み込むようにしました。
今はwebservers.ymlもdbservers.ymlもほぼ同じ内容のファイルになっていますが、追々各グループごとのロールを読み込むようにしていきますので、しばらくお待ちください。

commonロールの作成

全てのサーバに共通する処理ということでcommonというロールを作っていきます。

以下のような基本的なユーザの追加やセキュリティ設定を行うことを目的としたロールです。

  • 管理ユーザーの作成
  • sshdの設定
  • iptablesの設定

ベストプラクティスに従ってrolesディレクトリを作成し、その配下にcommonというロール名でディレクトリを切り、更にその下にディレクトリやファイルを作成していきましょう。

管理ユーザーの追加

まずは管理ユーザの追加です。

運用を開始した後もrootアカウントを日常的に使い続けるのは良くありませんので、sudo可能な管理者アカウントを別に作ります。

roles/common/tasks/main.yml

userモジュールを用いてユーザを作成するタスクを書いていきます。

単にuserモジュールでユーザを作成するだけではなく、少しアレンジを加えて変数を用いることで複数ユーザーの追加を楽に行うことができるようにしてみました。

またユーザーの追加に加えて公開鍵認証のためのauthorized_keysの設定とsudoの設定も行っています。

- name: users exist
  user: name={{item.name}} state=present password={{item.password}} groups={{item.groups}}
  with_items: users
  tags: users

- name: ~/.ssh for users exsit
  file: path="/home/{{item.name}}/.ssh" state=directory owner={{item.name}} group={{item.name}} mode=0700
  with_items: users
  tags: users

- name: authorized keys is deployed
  copy: src="authorized_keys_for_{{item.name}}" dest="/home/{{item.name}}/.ssh/authorized_keys" owner={{item.name}} group={{item.name}} mode=0600
  with_items: users
  tags: users

- name: sudo configured
  copy: src="sudoers" dest="/etc/sudoers" owner=root group=root mode=0440

これらのタスクに必要な変数定義やファイルの作成を続いて行いましょう。

group_vars/all

タスクで使用した変数は全てのサーバに共通のグループ変数として定義します。

そのためにgroup_varsディレクトリを作り、配下にallという名前でファイルを作成し以下の内容とします。

users:
  - { name: moongift,  password: "$1$Id9Bdq7D$B7bNBQO.MaZP.XKXm.Hbl.", groups: "wheel" }

パスワードは以下のようにハッシュ化したものを使います。hogehogeは実際に使うパスワードに置き換えてください。

openssl passwd -1 hogehoge

roles/common/files/sudoers

サーバ上に置くsudoersファイルを準備します。今回は実際のサーバ上から/etc/sudoersをscpでコピーしてきたものを編集します。

105行目のコメントアウトを外してwheelに所属するユーザーがsudoできるようにします。

## Allows people in group wheel to run all commands
%wheel  ALL=(ALL)   ALL

なおlineinfileモジュールでサーバ上の既存のファイルを変更するようにする事もできますが、今回は手元に用意した設定ファイルをアップロードするアプローチをとります。

roles/common/files/authorized_keys_for_moongift

公開鍵認証のための公開鍵を含んだauthorized_keysを準備します。

cat ~/.ssh/id_rsa_for_moongift.pub > roles/common/files/authorized_keys_for_moongift

公開鍵の内容をそのままコピーすればOKです。

適用

これでプレイブックにユーザ追加の機能が備わりました。以下のコマンドで適用してみましょう。

ansible-playbook -i development site.yml -u root --private-key=~/.ssh/id_rsa_for_ansible_bp_root

インベントリファイルとしてdevelopmentを、プレイブックとしてsite.ymlを指定しており、各サーバにはrootで接続し、秘密鍵はサーバ作成時に登録した公開鍵と対になるものを使っています。

うまく適用できましたか?うまくいったら追加したユーザでログインしてsudoができることを確認してみてください。

sshdの設定

ユーザが追加できたら次はsshdの設定です。パスワード認証を無効にして公開鍵認証のみとします。

roles/common/files/sshd_config

配置するsshdの設定ファイルを作成します。sudoの設定の時と同じように実際のサーバ上から/etc/ssh/sshd_configをコピーしてきて編集します。

PasswordAuthentication no

としてください。

roles/common/tasks/main.yml

ユーザ追加のタスクが書かれたtasks/main.ymlに以下を追記します。

- name: sshd is configured
  notify:
    - restart sshd
  copy: src="sshd_config" dest="/etc/ssh/sshd_config" owner=root group=root mode=0600
  tags: sshd

- name: sshd is enabled and started
  service: name=sshd state=running enabled=yes
  tags: sshd

notifyでrestart sshdを呼び出しているのに注意してください。これはハンドラとして定義する必要があります。

ちなみにsshd.ymlのようなファイルを別に作ってmain.ymlからインクルードしてもいいのですが、早期に細分化すると見通しが悪くなるので同じファイルに書いていきます。長くなってきたら、その時に分ければいいでしょう。

roles/common/handlers/main.yml

sshdを再起動するためのハンドラは次のように作成します。

---
- name: restart sshd
  service: name=sshd state=restarted

適用

再度適用です。

ansible-playbook -i development site.yml -u root --private-key=~/.ssh/id_rsa_for_ansible_bp_root

うまくいけばsshdの設定ファイルが更新され、sshdが再起動します。これでパスワード認証は無効になりひとつセキュアになりました。

ちなみにうまくいかない場合はファイルを修正して調整する必要がありますが、動作の確認のために全てのタスクが走るのは少し時間がかかり煩わしいです。そこで役に立つのが、タグを指定してそのタグが付けられたタスクのみを実行するという方法です。

ansible-playbook -i development site.yml -u root --private-key=~/.ssh/id_rsa_for_ansible_bp_root --tag=sshd

これを見越して今までに定義したタスクにもtagsでタグを振ってあります。プレイブックを構築する際には特に便利ですので、是非覚えておいてください。

iptablesの設定

最後にiptablesの設定です。

roles/common/tasks/main.yml

引き続きtasks/main.ymlに追記します。

テンプレートとグループ変数を使って各サーバに必要なポートだけを許可するようにしました。

- name: iptables is enabled and started
  service: name=iptables state=running enabled=yes
  tags: iptables

- name: iptables is configured
  template: src="iptables" dest="/etc/sysconfig/iptables" owner=root group=root mode=0600
  notify:
    - restart iptables
  tags: iptables

sshdの時と同じように、設定ファイルが変更されたらサービスを再起動するよう、notifyでハンドラを指定しています。

roles/common/handlers/main.yml

iptablesを再起動するハンドラです。

restart sshdの下に以下を追加します。

- name: restart iptables
  service: name=iptables state=restarted

roles/common/templates/iptables

iptablesのルールファイルのテンプレートです。

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
{% for rule in iptables.accept_tcp_rules %}
-A INPUT {% if "source" in rule %}-s {{rule.source}}{% endif %} -m state --state NEW -m tcp -p tcp --dport {{ rule.port }} -j ACCEPT
{% endfor %}
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT

テンプレートエンジンはJinja2です。

group_vars/webservers

接続を許可するポートを変数で定義します。

ウェブサーバはsshとhttpのみを許可します。

iptables:
  accept_tcp_rules:
    - { port: 22 }
    - { port: 80 }

group_vars/dbservers

DBサーバはsshとウェブサーバーからのMySQLの接続のみを許可します。

iptables:
  accept_tcp_rules:
    - { port: 22 }
    - { port: 3306, source: xxx.xxx.xxx.xxx }

このように変数をうまく使うと同じプレイブックやテンプレートからグループ個別、ホスト個別の設定を行うことができます。

適用

三度目の適用です。

ansible-playbook -i development site.yml -u root --private-key=~/.ssh/id_rsa_for_ansible_bp_root

各サーバにログインしてiptablesの設定を確認してみてください。意図したとおりの設定になっているでしょうか?

現在のファイル構成

try-ansible-best-practices
├── development
├── site.yml
├── dbservers.yml
├── webservers.yml
├── group_vars
│   ├── all
│   ├── dbservers
│   └── webservers
└── roles
    └── common
        ├── files
        │   ├── authorized_keys_for_moongift
        │   ├── sshd_config
        │   └── sudoers
        ├── handlers
        │   └── main.yml
        ├── tasks
        │   └── main.yml
        └── templates
            └── iptables

次回は

今回は運用ユーザの追加と基本的なセキュリティ設定をしてみました。

次回はウェブサーバとDBサーバそれぞれの設定を行ってWordPressが動作するところまでいきたいと思います。ぜひご覧ください。

Ansibleのベストプラクティス