OSSのサーバ構築自動化ツール、4製品徹底検証 2016年版：実際に検証済み！OSS徹底比較（3）サーバ構築自動化【前編】（1/9 ページ）

今回は、サーバ構築・運用自動化ソフトの中でも特に利用者の多い、「Chef」「Ansible」「Puppet」「Itamae」の4製品をピックアップ。「各ソフトの実行環境の構築手順」「OSSのブログ／CMS基盤であるWordPressの構築」を通じて、その違いを探る。

[森元敏雄,TIS]

増え続けるサーバと比例して増大する運用コスト

　パーソナルコンピュータに加えて、スマートフォンなどのモバイルデバイスの普及により、インターネットを経由したシステムの利用規模や利用時間の拡大が続いている。B2B、B2C分野でもシステムを利用することが当たり前になっており、ビジネスにおいてコンピュータは不可欠なものとなっている。

　そのビジネスを支えるシステムで利用されるサーバの台数も、増加の一途をたどっている。特に成長著しいクラウドサービスでは、金額ベースで年20％以上の成長が見込まれるとの調査結果も公表されている。

参考リンク：国内クラウド市場は2019年度に2兆円へ成長（MM総研）

　クラウドの利用により、サーバのハードウェアを保守する負荷は軽減されているが、システムを構築、運用するためのコストは増加傾向となっている。IDCの調査でも運用コストが増加した企業が、減少した企業を上回っている現状がうかがえるだろう。システムコストの平均30％以上が運用のコストであり、この削減はIT投資の効率化のためには不可欠となっている。

参考リンク：システム運用管理コストは増加傾向に（ITmediaエンタープライズ）

　その課題に対応すべく、「OpenStack」や「Docker」など、IaaS／PaaS基盤の構築・運用を効率化する製品に注目が集まっている。さらに、プラットフォーム上のサーバで稼働するシステムの構築・維持の自動化を実現する「サーバ構築・運用自動化ソフト」にも高い関心が寄せられており、数々の製品がリリースされ、本番環境でも有効に活用されている。

　サーバ構築・運用自動化ソフトは、今までインフラエンジニアが手作業で行っていた「アプリケーションやプロダクトのインストール・設定」や「日々のアップデートの適用」などを、システムで自動的に適用できるようにする製品である。実際に行う手順やチェックの処理をインフラ構築用ソースコードに定義することで実現するため、この技術はInfrastructure as Codeと呼ばれている。

　今回は、サーバ構築・運用自動化ソフトの中でも特に利用者の多い、「Chef」「Ansible」「Puppet」「Itamae」の4製品を用い、各ソフトの実行環境の構築手順と、OSSのブログ／CMS基盤であるWordPressの構築を実際に行って結果をまとめている。基本的に同一のインストール手順で自動構築を行うことで、各製品間の違いを表現できればと考えている。

　製品は2016年4月時点の最新安定バージョンを用いて実施している。基本的な使い方を記述しているため、初めて製品を使う方の参考になれば幸いである。ただ、筆者の知識不足で、各製品で推奨されている“ベストプラクティス”に準拠できていない点も存在することをご容赦いただきたい。

対象製品

　今回、評価を行った4製品の製品名と特徴は以下の通りだ。なお、リスト中の製品名をクリックすると該当ページに飛ぶので、知りたい製品から読むこともできる。前編となる本稿ではChefとAnsibleを紹介。PuppetとItamaeを紹介する後編は明日、2016年6月24日に公開する。

	製品名	ベンダー／コミュニティ	特徴
1	Chef	Chef Software, Inc.	使用言語はRuby。サーバnode内で設定を行うChefと管理サーバからChefを実行するknifeと集中管理を行うChef Serverが提供されている
2	Ansible	Red Hat Inc.	使用言語はPython。エージェントレスでssh接続で設定可能であれば、サーバ以外(Network Switch等)でも設定が可能
3	Puppet	Puppet Labs	使用言語はRuby。2005年から開発されている最古参の製品。他の3製品とは異なり、node側から処理が実行されるpull型となっている
4	Itamae	itamae-kitchen	使用言語はRuby。Chefの軽量化、簡素化を目的にcookpadの荒井氏が開発した。機能もrecipeの書式もChefを踏襲しているが、Ansible同様にエージェントレスのため、sshで接続して処理を実行する

検証環境

　今回の検証は以下の環境で実施している。

図1　今回の検証環境

1. VMware ESXi上でCentOS 7.2のサーバを2台構築
2. Manager→nodeへのssh接続をパスワードなしの鍵認証で行える状態にしている
3. インストールや設定は管理者権限が必要なため、ログイン後のsudoやsuコマンドをパスワードなしで実行できるようにしている
4. サーバの名前解決ができるように双方の/etc/hostsにホスト名とIPアドレスを登録している
5. 各製品を同一環境で検証するために、この状態で双方のサーバのスナップショットを取得している

インストールの手順を確認してみよう〜もはや手作業では“増え続けるサーバ”に対応できない〜

　まず、各ツールを利用する前に、インストール手順の確認の意味も含めて、旧来用いられているシェルスクリプトで実現してみたものが以下となる。

#!/bin/bash
# Parameter settings
HOSTNAME="`hostname`"
IP_ADDR="`hostname -i`"
MYSQL_ROOT_PASS="FM11AD2+"
WP_OS_USER="root"
WP_OS_GROUP="root"
WP_DB_NAME="WordPress"
WP_DB_USER="wp_admin"
WP_DB_PASS="HB-F1XDJ"
WP_UNIQUE_PHRASE="FX702PFX801PPB100FX860PPB700PB500PB750PAI1000"
#WP_LATEST="http://wordpress.org/latest.tar.gz"
WP_LATEST="https://ja.wordpress.org/latest-ja.tar.gz"
# update packages
yum update -y
# install packages
yum install -y mariadb-server httpd php php-mysql
# start/enable mariadb
systemctl start mariadb
systemctl enable mariadb
# set mariadb root password
mysql <<EOT
update mysql.user set password=password("${MYSQL_ROOT_PASS}") where user = 'root';
flush privileges;
EOT
# create /root/.my.cnf
cat <<EOT > /root/.my.cnf
[client]
user = root
password = "${MYSQL_ROOT_PASS}"
[mysqladmin]
user = root
password = "${MYSQL_ROOT_PASS}"
EOT
chmod 600 /root/.my.cnf
# restart mariadb
systemctl restart mariadb
# mariadb logrotate setting
sed -i.bak -e '23,$ s/^#//' /etc/logrotate.d/mariadb
# create wordpress db/user
mysql -u root -p${MYSQL_ROOT_PASS} -vvv <<EOT
create user "${WP_DB_USER}"@"localhost" identified by "${WP_DB_PASS}";
create database ${WP_DB_NAME};
grant all privileges on ${WP_DB_NAME}.* to "${WP_DB_USER}"@"localhost";
flush privileges;
EOT
# install wordpress
curl ${WP_LATEST} | tar zx -C /var/www
# create wordpress config
sed -e "s/\(define.*'\)database_name_here\('.*\)/\1${WP_DB_NAME}\2/" \
    -e "s/\(define.*'\)username_here\('.*\)/\1${WP_DB_USER}\2/" \
    -e "s/\(define.*'\)password_here\('.*\)/\1${WP_DB_PASS}\2/" \
    -e "s/\(define.*'\)put your unique phrase here\('.*\)/\1${WP_UNIQUE_PHRASE}\2/" \
    /var/www/wordpress/wp-config-sample.php  > /var/www/wordpress/wp-config.php
# chown wordpress files
chown -R ${WP_OS_USER}:${WP_OS_GROUP} /var/www/wordpress
# create wordpres httpd config
cat <<EOT > /etc/httpd/conf.d/wordpress.conf
<VirtualHost *:80>
  ServerName ${HOSTNAME};
  DocumentRoot /var/www/wordpress
  <Directory "/var/www/wordpress">
    AllowOverride All
    Options -Indexes
  </Directory>
  <Files wp-config.php>
    order allow,deny
    deny from all
  </Files>
</VirtualHost>
EOT
# modify httpd config
sed -i.bak -e "s/ServerName www.example.com:80/ServerName ${HOSTNAME}/" /etc/httpd/conf/httpd.conf
# start/enable httpd
systemctl start httpd
systemctl enable httpd
# open httpd port in firewall
firewall-cmd --add-service=http --zone=public --permanent
firewall-cmd --reload
# Complete message
echo ""
echo "========================================"
echo "Complete WordPress install"
echo "http://${IP_ADDR}/wp-admin/install.php"
echo "========================================"

　各nodeにログインして、このスクリプトをroot権限で実行するとインストールと設定が行え、取りあえずは問題なく動作する。ただ、実行するコマンドを羅列しているだけなので、全てのコマンドが正常に動作しているかの判断には、プロセス、サービス、ファイルの状態を手で確認する必要がある。何らかの原因でスクリプト実行時にエラーが発生し、再実行した場合も、実行済みの処理が再実行されてしまうため、コマンドがエラーになるだけではなく、設定不備の原因にもなりかねない。

　これが1台のサーバの設定であれば問題はないが、設定する複数のサーバ1台1台にログインして実行するのも煩雑である。この点をサーバ構築・運用自動化ツールがどのような形で解決できるのかを、実際に動かして検証してみたい。