【連載01】201.AnsibleでCentOS7サーバ群に接続し、サーバの状態をコミットするまで

<b><font color="#ff6633">当記事はケーススタディの連載となっています。目次は[【こちら】](http://qiita.com/CsFactoryitter/items/6b8308b96afafd61ce5f
)です。</font></b>
<b><font color="#ff6633">最新のソースコードは[【GitHub】](https://github.com/csfactorygihubblog001/blogansible)で公開中です。</font></b>

前回までの連載記事（[01.Vagrant-Ansible-Serverspecによるサーバ構築とサーバテスティング](http://qiita.com/CsFactoryitter/items/35977a5d18aa121bb24c#_reference-805b89062e55ee1f1024)～[08.最小構成CentOS7からAnsibleに制御されるCentOS7を構築する (On Vagrant)](http://qiita.com/CsFactoryitter/items/23fde5761f1243bcead6)）でVagarantを使用してAnsible管理端末、各種サーバ群(apserv01,dbserv01,adminserv01)の構築をしました。
 
今回の連載ではAnsible管理端末から以下のサーバの設定をします。
・apserv01(WEB/Applicationサーバ)
・dbserv01(Maridadb(Mysql))
・adminserv01(SVNやJenkins等)

これらサーバ群の責務は以下の通りです。

![Vagrant-Ansible-Serverspec_1.png](https://qiita-image-store.s3.amazonaws.com/0/98085/8730b7ac-2ee3-954b-e354-2f77bb6973c9.png)

途中Vagrantのプラグインを使用してサーバのコミット/ロールバックも行います。
サーバ設定ソフトウェア(サーバープロビジョニングツール）は設定するとサーバ設定が確定してしまい、データベースやプログラミング等と違い、戻す(ロールバック)ことや確定(コミット)などが出来ない為です。

実際にAnsibleを使用してしてサーバ設定する前にサーバ構成について復習。
![Vagrant-Ansible-Serverspec_3.png](https://qiita-image-store.s3.amazonaws.com/0/98085/a91631fa-f45b-07b6-d238-9d18f702efc5.png)

詳細は、
「[Vagrant-Ansible-Serverspecによるサーバ構築とサーバテスティング](http://qiita.com/CsFactoryitter/items/35977a5d18aa121bb24c)」
Windowsのフォルダ構成は、
「[VirtualBox LinuxイメージをVagrantBoxファイルに変換する](http://qiita.com/CsFactoryitter/items/60b65ae685a3ea4ee16f)」
を参照ください。

##Windowsでの操作
![image](https://qiita-image-store.s3.amazonaws.com/0/98085/9cb7a797-8dfc-082a-c06e-b0a39cbac6de.png)

###1.Ansible管理端末(manageterm)を起動する

####1-1.Vagrantのルートに移動

```ps1:
cd D:\_BLOG\BG001\vagrant_box
```

####1-2.管理端末の起動

```ps1:
vagrant up manageterm
```

実行イメージ：
![image](https://qiita-image-store.s3.amazonaws.com/0/98085/f0c2fc58-6674-3186-8a41-046f2cdd715c.png)

実行結果コンソール：

```ps1:
PS D:\_BLOG\BG001\vagrant_box> vagrant up manageterm
Bringing machine 'manageterm' up with 'virtualbox' provider...
==> manageterm: Clearing any previously set network interfaces...
==> manageterm: Preparing network interfaces based on configuration...
    manageterm: Adapter 1: nat
    manageterm: Adapter 2: hostonly
    manageterm: Adapter 3: bridged
==> manageterm: Forwarding ports...
    manageterm: 22 => 2222 (adapter 1)
==> manageterm: Running 'pre-boot' VM customizations...
==> manageterm: Booting VM...
==> manageterm: Waiting for machine to boot. This may take a few minutes...
    manageterm: SSH address: 127.0.0.1:2222
    manageterm: SSH username: vagrant
    manageterm: SSH auth method: private key
    manageterm: Warning: Connection timeout. Retrying...
    manageterm: Warning: Remote connection disconnect. Retrying...
==> manageterm: Machine booted and ready!
==> manageterm: Checking for guest additions in VM...
==> manageterm: Setting hostname...
==> manageterm: Configuring and enabling network interfaces...
==> manageterm: Mounting shared folders...
    manageterm: /vagrant => D:/_BLOG/BG001/vagrant_box
==> manageterm: Machine already provisioned. Run `vagrant provision` or use the `--provision`
==> manageterm: flag to force provisioning. Provisioners marked to run always will still run.
```

##manageterm(Linux)での操作(Ansible管理仮想端末)

![image](https://qiita-image-store.s3.amazonaws.com/0/98085/ddc25596-4c62-ba9d-cbab-99252623d781.png)

###1.SELINUXの無効化

####1-1.selinuxファイルをコピーしてバックアップ

```bash:
cp /etc/sysconfig/selinux /etc/sysconfig/selinux.org
vi /etc/sysconfig/selinux
```

####1-2.selinuxの編集
<b>SELINUX=enforcing</b> => <b>SELINUX=disabled</b> に変更

```bash:selinux
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
# ******* SELINUX=enforcingをSELINUX=disabledに変更する***************
#SELINUX=enforcing
SELINUX=disabled
```

####1-3.変更箇所の確認
diffコマンドで変更後と変更前のファイルを比較する。

```bash:
diff /etc/sysconfig/selinux /etc/sysconfig/selinux.org
7,8c7
< #SELINUX=enforcing
< SELINUX=disabled
---
> SELINUX=enforcing
```

####1-4.reboot
rebootしてSELINUXを適用する。

```bash:
reboot
```

※後で再起動を行う場合は、とりあえず下記コマンドを実行。

```bash:
setenforce permissive
```

###2.Ansibleルートディレクトリの確認

```bash:
cd /etc/ansible/
ls -la
```

実行イメージ：
![image](https://qiita-image-store.s3.amazonaws.com/0/98085/54ca5ad7-61ff-4849-9a0a-b3388217c9bc.png)


実行結果コンソール：

```bash:
[root@manageterm ansible]# cd /etc/ansible/
[root@manageterm ansible]# ls -la
合計 28
drwxr-xr-x.  3 root root   48 12月 26 01:01 .
drwxr-xr-x. 76 root root 8192 12月 26 01:07 ..
-rw-r--r--.  1 root root 8625 10月 11 03:36 ansible.cfg
-rw-r--r--.  1 root root  965 10月 11 03:36 hosts
drwxr-xr-x.  2 root root    6 10月 11 03:36 roles
[root@manageterm ansible]#
```

###3.Ansibleのhostsファイル(/etc/ansible/hosts)の設定

```bash:
vi /etc/ansible/hosts
```

以下を記述

```bash:hosts
#管理するサーバの一覧
apserv01
dbserv01
adminserv01
 
#WEB/APサーバ用のグループを設定
#ここでは一台だがWEB/APサーバ群に一括して設定したい場合の為
[apservers]
apserv01
 
 
#DBサーバ用のグループを設定
[dbservers]
dbserv01
 
 
#adminserv01サーバ用のグループを設定
[adminservs]
adminserv01
 
#apserv01とadminserv01をグループ化
[ap_admin]
apserv01
adminserv01
 
 
#dbserv01とadminserv01をグループ化
[db_admin]
dbserv01
adminserv01
```

###4.OSのhostsファイルの設定

以下を追記

```bash:hosts
#サーバの一覧
192.168.102.195 manageterm
192.168.102.196 apserv01
192.168.102.197 dbserv01
192.168.102.198 adminserv01
```

具体的なIPアドレスは
「[最小構成CentOS7からAnsibleに制御されるCentOS7を構築する(On Vagrant)](http://qiita.com/CsFactoryitter/items/23fde5761f1243bcead6)」に設定したpublic_networkのURLを指定する。

###5.Ansible用ユーザーの作成

```bash:
useradd ansible
passwd ansible
```

※任意のパスワードを設定する。

###6.Ansibleルート(/etc/ansible)の所有者と権限の変更 

```bash:
#rootユーザとansibleグループに77権限を与える
chown -R root:ansible/etc/ansible

#rootとansibleに77権限を与える
chmod -R 775 /etc/ansible

# /etc/ansible/hostsのみ-xする
chmod -x /etc/ansible/hosts
```

###7.公開鍵作成

```bash:
ssh-keygen -t rsa -N ""
```

実行結果コンソール：

```bash:
[root@manageterm ~]# ssh-keygen -t rsa -N ""
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Created directory '/root/.ssh'.
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
74:f5:b8:c9:63:a5:3a:44:96:b9:1f:84:22:13:f3:13 root@manageterm
The key's randomart image is:
+--[ RSA 2048]----+
|      o E   .    |
|       + . = o   |
|      o = B o o  |
|       + * + =   |
|        S o O    |
|         . + o   |
|          o .    |
|           .     |
|                 |
+-----------------+
```

###8.作成された鍵情報の確認

```bash:
ls -la /root/.ssh
```

以下の２ファイルが作成されている

```bash:
/root/.ssh/id_rsa
/root/.ssh/id_rsa.pub
```

KEY情報をSSH-Agentプロセスに保存する。
毎回パスフレーズを入力せずに他のSSHサーバに対して接続するようにする。
AnsibleはSSHを使用して自動で他のサーバの設定を行う為、SSH公開鍵パスフレーズをssh-agentプロセスに保存しておく。
<b>※eval \`ssh-agent`を実行すると「Agent pid XXXX」と表示される。XXXXを psで確認してみるとssh-agentが起動しているのがわかる
</b>

```bash:
eval `ssh-agent`

ssh-add
```

##Windowsでの操作
apserv01、dbserv01、adminserv01(Ansible管理端末(manageterm)により操作されるサーバの起動)

managetermの準備が完了した為、操作されるサーバをVagrantより起動する。

###1.Vagrantのルートに移動

```ps1:
cd D:\_BLOG\BG001\vagrant_box
```

###2.サーバ群(apserv01、adminsev01、dbserv01)の起動

```ps1:
vagrant up apserv01 dbserv01 adminserv01
```

実行結果コンソール：

```ps1:
Bringing machine 'apserv01' up with 'virtualbox' provider...
Bringing machine 'dbserv01' up with 'virtualbox' provider...
Bringing machine 'adminserv01' up with 'virtualbox' provider...
==> apserv01: Fixed port collision for 22 => 2222. Now on port 2201.
==> apserv01: Clearing any previously set network interfaces...
==> apserv01: Preparing network interfaces based on configuration...
    apserv01: Adapter 1: nat
    apserv01: Adapter 2: hostonly
    apserv01: Adapter 3: bridged
==> apserv01: Forwarding ports...
    apserv01: 22 => 2201 (adapter 1)
==> apserv01: Booting VM...
==> apserv01: Waiting for machine to boot. This may take a few minutes...
    apserv01: SSH address: 127.0.0.1:2201
    apserv01: SSH username: vagrant
    apserv01: SSH auth method: private key
    apserv01: Warning: Connection timeout. Retrying...
    apserv01: Warning: Remote connection disconnect. Retrying...
==> apserv01: Machine booted and ready!
==> apserv01: Checking for guest additions in VM...
==> apserv01: Setting hostname...
==> apserv01: Configuring and enabling network interfaces...
==> apserv01: Mounting shared folders...
    apserv01: /vagrant => D:/_BLOG/BG001/vagrant_box
==> apserv01: Machine already provisioned. Run `vagrant provision` or use the `--provision`
==> apserv01: flag to force provisioning. Provisioners marked to run always will still run.
==> dbserv01: Clearing any previously set forwarded ports...
==> dbserv01: Fixed port collision for 22 => 2222. Now on port 2202.
==> dbserv01: Clearing any previously set network interfaces...
==> dbserv01: Preparing network interfaces based on configuration...
    dbserv01: Adapter 1: nat
    dbserv01: Adapter 2: hostonly
    dbserv01: Adapter 3: bridged
==> dbserv01: Forwarding ports...
    dbserv01: 22 => 2202 (adapter 1)
==> dbserv01: Booting VM...
==> dbserv01: Waiting for machine to boot. This may take a few minutes...
    dbserv01: SSH address: 127.0.0.1:2202
    dbserv01: SSH username: vagrant
    dbserv01: SSH auth method: private key
    dbserv01: Warning: Connection timeout. Retrying...
    dbserv01: Warning: Remote connection disconnect. Retrying...
==> dbserv01: Machine booted and ready!
==> dbserv01: Checking for guest additions in VM...
==> dbserv01: Setting hostname...
==> dbserv01: Configuring and enabling network interfaces...
==> dbserv01: Mounting shared folders...
    dbserv01: /vagrant => D:/_BLOG/BG001/vagrant_box
==> dbserv01: Machine already provisioned. Run `vagrant provision` or use the `--provision`
==> dbserv01: flag to force provisioning. Provisioners marked to run always will still run.
==> adminserv01: Clearing any previously set forwarded ports...
==> adminserv01: Fixed port collision for 22 => 2222. Now on port 2200.
==> adminserv01: Clearing any previously set network interfaces...
==> adminserv01: Preparing network interfaces based on configuration...
    adminserv01: Adapter 1: nat
    adminserv01: Adapter 2: hostonly
    adminserv01: Adapter 3: bridged
==> adminserv01: Forwarding ports...
    adminserv01: 22 => 2200 (adapter 1)
==> adminserv01: Booting VM...
==> adminserv01: Waiting for machine to boot. This may take a few minutes...
    adminserv01: SSH address: 127.0.0.1:2200
    adminserv01: SSH username: vagrant
    adminserv01: SSH auth method: private key
    adminserv01: Warning: Connection timeout. Retrying...
    adminserv01: Warning: Remote connection disconnect. Retrying...
==> adminserv01: Machine booted and ready!
==> adminserv01: Checking for guest additions in VM...
==> adminserv01: Setting hostname...
==> adminserv01: Configuring and enabling network interfaces...
==> adminserv01: Mounting shared folders...
    adminserv01: /vagrant => D:/_BLOG/BG001/vagrant_box
==> adminserv01: Machine already provisioned. Run `vagrant provision` or use the `--provision`
==> adminserv01: flag to force provisioning. Provisioners marked to run always will still run.
PS D:\_BLOG\BG001\vagrant_box>
```

###3.起動確認

```ps1:
vagrant status
```

以下が出力されていればOK。

```ps1:
PS D:\_BLOG\BG001\vagrant_box>   vagrant status
Current machine states:
 
apserv01                  running (virtualbox)
dbserv01                  running (virtualbox)
adminserv01               running (virtualbox)
manageterm                running (virtualbox)
```

##manageterm(Linux)での操作(Ansible管理仮想端末)

![image](https://qiita-image-store.s3.amazonaws.com/0/98085/3a757341-a874-e5e3-e18f-3e05201948e3.png)

###1.鍵のあるディレクトリに移動

```bash:
cd /root/.ssh
```

###2.manageterm(Ansible)からサーバ群へ公開鍵を配布
それぞれ2回パスワードを求められる。
以降は公開鍵暗号方式による接続となりパスワードを求められる事がなくなる。

- apserv01への配布

```bash:
#SSHで対象のサーバに接続して.sshフォルダを作成する。すでにある場合は何もしない
ssh root@apserv01  "mkdir ~/.ssh > /dev/null 2>&1;touch ~/.ssh/authorized_keys;exit"
#SSHで対象のサーバに接続してansible実行端末の公開キーを信頼するサーバ群として登録する
cat /root/.ssh/id_rsa.pub | ssh root@dev_apserv01 "cat > .ssh/authorized_keys && chmod 600 .ssh/authorized_keys"
```

- dbserv01への配布

```bash:
#SSHで対象のサーバに接続して.sshフォルダを作成する。すでにある場合は何もしない
ssh root@dbserv01 "mkdir ~/.ssh > /dev/null 2>&1;touch ~/.ssh/authorized_keys;exit"
#SSHで対象のサーバに接続してansible実行端末の公開キーを信頼するサーバ群として登録する
cat /root/.ssh/id_rsa.pub | ssh root@dbserv01 "cat > ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"
```

- adminserv01への配布

```bash:
#SSHで対象のサーバに接続して.sshフォルダを作成する。すでにある場合は何もしない
ssh root@adminserv01 "mkdir ~/.ssh > /dev/null 2>&1;touch ~/.ssh/authorized_keys;exit"
#SSHで対象のサーバに接続してansible実行端末の公開キーを信頼するサーバ群として登録する
cat /root/.ssh/id_rsa.pub | ssh root@adminserv01 "cat > ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"
```

これでAnsibleに接続するすべてのサーバへ公開鍵の配布が完了。
apserv01、dbserv01、adminserv01に接続確認を行う。

```bash:
ansible all -m ping
```

実行イメージ：
![image](https://qiita-image-store.s3.amazonaws.com/0/98085/5cdf88d5-5783-7018-852a-02544dba6d79.png)

実行結果コンソール：

```bash:
apserv01 | success >> {
    "changed": false,
    "ping": "pong"
}

dbserv01 | success >> {
    "changed": false,
    "ping": "pong"
}
 
adminserv01 | success >> {
    "changed": false,
    "ping": "pong"
}
```

##Windowsでの操作

![image](https://qiita-image-store.s3.amazonaws.com/0/98085/34cb3d21-9daa-39b6-2b65-7b3091a5114f.png)

###Ansible管理端末(manageterm)/サーバ群(adminserv01、apserv01、dbserv01)のコミット

以上でAnsible管理端末の接続設定は完了。
折角なのでVagrantにてサーバ状態をコミットしておく。

####1.Vagrantのルートに移動

```ps1:
cd D:\_BLOG\BG001\vagrant_box
```

####2.Vagrant saharaプラグインのインストール

書式：
>vagrant plugin install sahara

例：

```ps1:
vagrant plugin install sahara
```

実行結果コンソール：

```ps1:
PS D:\_BLOG\BG001\vagrant_box> vagrant plugin install sahara
Installing the 'sahara' plugin. This can take a few minutes...
Installed the plugin 'sahara (0.0.17)'!
``` 

####3.プラグインの確認

書式：
>vagrant plugin list

例：

```ps1:
vagrant plugin list
```

実行イメージ：

```ps1:
PS D:\_BLOG\BG001\vagrant_box> vagrant plugin list
sahara (0.0.17)
vagrant-share (1.1.5, system)
```

####4.Vagrant sahara sandboxモードの有効化
saharaはVirtualBoxのスナップショットモードを利用することによりコミットとロールバックを行う。

まずsaharaのsandboxモードを有効化する。

書式：

>vagrant sandbox on

例：

```ps1:
vagrant sandbox on
```

実行イメージ：

```ps1:
PS D:\_BLOG\BG001\vagrant_box> vagrant sandbox on
[manageterm] Starting sandbox mode...
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
[adminserv01] Starting sandbox mode...
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
[dbserv01] Starting sandbox mode...
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
[apserv01] Starting sandbox mode...
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
```

####5.サーバの一括コミット(VirtualBoxスナップショット作成)

書式：

>vagrant sandbox commit

例：

```ps1: 
vagrant sandbox commit 
```

実行イメージ：

```ps1:
PS D:\_BLOG\BG001\vagrant_box> vagrant sandbox commit
[manageterm] Committing the virtual machine...
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
[adminserv01] Committing the virtual machine...
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
[dbserv01] Committing the virtual machine...
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
[apserv01] Committing the virtual machine...
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
```

エクスプローラの状態

![image](https://qiita-image-store.s3.amazonaws.com/0/98085/e4c53d65-0986-30c6-5381-44834ab5f668.png)

- サーバを指定してコミットしたい場合
書式：

>vagrant sandbox commit ${仮想サーバ名}

例：

```ps1:
vagrant sandbox commit  adminserv01
```

- 一括ロールバックしたい場合

書式：

>vagrant sandbox rollback

例：

```ps1:
vagrant sandbox rollback
```

- サーバを指定してロールバックしたい場合

書式：

>vagrant sandbox rollback ${仮想サーバ名}

例：

```ps1:
vagrant sandbox rollback adminserv01
```

※Vagrant saharaでは、残念ながらGITのようなソース管理ツールで使用できる過去の複数の世代コミット/ロールバックができない。
イメージとしてはデータベースのコミット/ロールバック(直近のトランザクションの確定または破棄）と同じと思ってもらったらわかりやすいです。

GITのように複数の世代を持ちたい場合は（少々面倒ですが）サーバ設定がある程度完了した段階でboxファイルを作成しておくのがおすすめ。

書式：

>vagrant package \${名前} --output ${出力パス}

例：

```ps1:
vagrant package adminserv01 --output ..\vagrant_boxfiles\adminserv01_XXXXX.box
```

上記でboxファイルを作成した断面に戻りたい場合は、「vagrant sandbox rollback」ではもどれないので以下の手順をたどる。

(1)完成形をBOXファイルへパッケージ化

```ps1:
vagrant package adminserv01 --output ..\vagrant_boxfiles\adminserv01_XXXXX.box
```

(2)BOXから対象仮想マシン情報を削除

```ps1:
vagrant box remove adminserv01
```
 
(3)仮想マシン自体を削除

```ps1:
vagrant destroy adminserv01
```
 
(4)BOXの仮想マシンを追加(情報のみ)　※ここで(1)で作成したboxファイルを指定して再構築

```ps1:
vagrant box add adminserv01 ..\vagrant_boxfiles\adminserv01_XXXXX.box
```
 
(5)BOX起動(仮想サーバは初回にアンパックされて作られる)

```ps1:
vagrant up adminserv01
```
 
(6)SandboxをONにする

```ps1:
vagrant sandbox on
```

次回は「[Ansible実行端末からのCentOSサーバ群を構築する（Ansible準備編）](http://qiita.com/CsFactoryitter/items/3112c6d504d3b5a58011)」について。

<b><font color="#ff6633">連載の目次は[【こちら】](http://qiita.com/CsFactoryitter/items/6b8308b96afafd61ce5f
)です。</font></b>