Ansibleでバージョンアップ作業を自動化する

デベロッパーのkyosimotoです。

Ansibleをバージョンアップ作業の自動化ツールとして導入するための手順、おすすめ構成などについて紹介させていただきます。

目次

• 目次
• なぜAnsible
• どんな感じ？
• Ansibleの基本
• • 実行方法
  • 実行イメージ
  • マシン要件
  • ファイル構成
  • • ディレクトリ構成（サンプル）
    • playbook（サンプル）
    • • ファイル構成のポイント
• 検証環境の準備
• • 検証環境の説明
  • 検証用仮想マシンの構築手順
  • 仮想サーバにSSH接続する
• Ansible実行環境の構築
• • Ansibleのインストール
  • SSH接続設定
  • 検証用仮想マシンのミドルウェアセットアップ
  • • WEBサーバの構築 (Apache2.2 + PHP7.1)
    • DBサーバの構築(PostgreSQL9.6)
    • WEB／DBサーバの連携チェック
  • プロジェクトディレクトリ作成
  • • バージョンアッププロジェクト用のディレクトリ作成
    • Inventoryの作成
    • • Inventoryの作成（補足）
  • Playbookの作成
  • ansible.cfgの作成
  • Roleの作成
  • • ミドルウェアの起動
    • • （補足）ミドルウェアの起動
    • ミドルウェアの停止
    • ミドルウェアのバージョンアップ
  • playbookの実行
• 最後に

なぜAnsible

私は担当サービスのバージョンアップ作業を自動化するため、シェルベースのスクリプトを開発・運用してきました。 スクリプト導入により、ほとんどの作業は自動化され、運用コストは大幅に削減されました。

半面、バージョンアップスクリプトの属人化が課題となっており、リリース時のトラブルが起きた場合に、作業担当者による 原因調査と復旧作業が難しい状態となっています。

シェルスクリプトで作成したバージョンアップスクリプトには、フレームワークのような拘束力が無く、長い運用の中でイレギュラーケースに対応したコードやフラグが追加され、複雑化の道をすすみ続ける可能性があります。

さらには、今のところこの複雑化したスクリプトをポジティブに学習したいという人はいません。問題が起きたとしても、開発担当者に聞けばすぐに解決できるからです。

私は属人化を解消するためには、シェルスクリプトによる実装をやめ、学習コストが低く複雑なコードを生まない自動化ツールの導入が必要と考えており、この要件にマッチしたAnsibleを導入提案することになりました。

どんな感じ？

今のところメリットと感じているのは下記３点です。

• 学習コストが低い
  設定ファイルはYAMLという形式で記述します。設定ファイルがシンプルで、初めての人でも内容をすぐに理解できると思います。
  運用作業用のモジュールが充実していますので、プログラミング書くことも読むこともほとんどありません。
• 導入コストが低い
  管理対象サーバには余計なツールやデーモンをインストールする必要がありません。
  SSHとPythonさえ使えれば、Ansibleからの操作が可能ですので、運用チームへも提案しやすいと思います。
• 運用コストが低い
  少しの工夫で設定ファイルをそのまま手順書として扱うことができます。

Ansibleの基本

実行方法

Ansibleの実行コマンドは以下の通りです。

Inventoryには、サーバ名やIPアドレスなどの管理対象ノードの情報、Playbookには管理対象ノードで実行するタスクを記述します。

実行イメージ

Ansibleは、上記コマンドを実行するとPlaybookの内容をPythonのプログラムに変換します。
変換されたプログラムファイルは、Inventory（インベントリ）に記述された管理対象ノードに転送後に実行されます。

マシン要件

ファイル構成

私のお勧めするファイル構成サンプルを紹介します。

ディレクトリ構成（サンプル）

playbook（サンプル）

以下、playbookファイルの内容です。
- myapp_verup/versionup.yml

ファイル構成のポイント

ファイル構成を考える上で、お勧めするポイントは下記２点です。

• playbookを日本語で記述する playbookのタスクを日本語化することで、設定ファイルの可読性が上がる、playbookがそのまま手順書／ドキュメントになるという点でメリットが大きいと考えています。
• バージョンアップ作業に集中する。
  バージョンアップ作業以外のタスクを含めないようにします。
  例えば、サーバ構成管理や冪等性のための実装を行うと、Ansibleの設定は複雑化します。 複雑化は属人化を進行させますし、（Serverspecなど）ツールを使ったテストなども検討する必要がでてくるでしょう。

検証環境の準備

ここからは、Ansibleの検証用環境の構築手順について記載します。

検証環境の説明

仮想マシンの構築に Vagrant + Virtualbox を利用します。 検証用に構築するサーバは以下の通りです。

ホスト名IPアドレスOSMW/Toolcontrol192.168.33.100CentOS 6.9Ansibleweb192.168.33.101CentOS 6.9Apache2.2 + PHP7.1db192.168.33.102CentOS 6.9PostgreSQL9.6

別のディストリビューションで検証したい場合は、Vagrant Cloudよりboxイメージを検索し、後述する「vagrantinit」コマンドの引数に指定してください。

検証用仮想マシンの構築手順

仮想サーバにSSH接続する

Windowsの場合は、ターミナルソフトで接続します。

Ansible実行環境の構築

AnsibleのインストールとSSH設定の手順について記載します。

Ansibleのインストール

SSH接続設定

接続先サーバへのSSH接続を簡単にするためSSH設定を記述します。

検証用仮想マシンのミドルウェアセットアップ

バージョンアップ手順の検証用に、予めミドルウェアをセットアップします。

WEBサーバの構築 (Apache2.2 + PHP7.1)

DBサーバの構築(PostgreSQL9.6)

WEB／DBサーバの連携チェック

プロジェクトディレクトリ作成

ファイル構成の項目で紹介したAnsibleプロジェクトを作成していきましょう。

バージョンアッププロジェクト用のディレクトリ作成

Inventoryの作成

Inventoryでは、管理対象ノードのホスト名、またはIPアドレスとグループの定義を行います。 ファイルはINIファイル形式で記述します。

• myapp_verup/development.ini

Inventoryの作成（補足）

Inventoryを本番環境用、ステージング環境用、開発環境用に分けて管理することで バージョンアップ対象の切り替えできるようにします。

以下サンプルです。

• myapp_verup/product.ini (本番環境用）

・myapp_verup/staging.ini (ステージング環境用）

Playbookの作成

Playbookには、バージョンアップ手順を記述します。
（どのサーバでどんなタスクをどのような順番で実行するかを記述します）

• myapp_verup/versionup.yml

ファイルはYAML形式となりますので、拡張子は「yml」、１行目は「---」としてください。

2行目以降にバージョンアップ手順を記述します。書き方のルールは以下の通りです。

ansible.cfgの作成

Ansibleの動作設定を記述するファイルで、INI形式で記述します。
- myapp_verup/ansible.cfg

Roleの作成

Playbookのrolesディレクティブに記述したタスクの実態をrolesディレクトリの配下作成します。 例えば、「Cronを起動する」というタスクは、roles/Cronを起動する/tasks/main.yml に、処理内容を記述します。

ミドルウェアの起動

service コマンドが準備されているミドルウェア（デーモン）であれば、「service」モジュールを使って以下のように記述します。

• myapp_verup/roles/cronを起動する/tasks/main.yml

・myapp_verup/roles/apacheを起動する/tasks/main.yml

・　myapp_verup/roles/postgresqlを起動する/tasks/main.yml

（補足）ミドルウェアの起動

service コマンドが提供されていないミドルウェアの場合は、「shell」モジュールと「wait_for」モジュールで実装することもできます。

shell モジュールは終了ステータスコードが0以外は、すべてエラーとして処理を中断しますので注意が必要です。 ステータスコードが0以外でも処理を継続する場合には、下記サンプルを参考にしてください。

ミドルウェアの停止

service コマンドが準備されているミドルウェア（デーモン）であれば、「service」モジュールを使って以下のように記述します。

• myapp_verup/roles/cronを停止する/tasks/main.yml

myapp_verup/roles/apacheを停止する/tasks/main.yml

myapp_verup/roles/postgresqlを停止する/tasks/main.yml

ミドルウェアのバージョンアップ

RPMがyumコマンドでバージョンアップできる場合は、「yum」モジュールを利用して「latest」の状態に更新します。

• myapp_verup/roles/apacheをバージョンアップする/tasks/main.yml

myapp_verup/roles/phpをバージョンアップする/tasks/main.yml

myapp_verup/roles/postgresqlをバージョンアップする/tasks/main.yml

リポジトリ管理されていない（カスタムRPMをつかっている）場合は、以下設定を参考にしてください。

※ディレクトリ構成については公式ページのBest Practices の「Directory Layout」を参考にしています。

• myapp_verup/roles/Apacheをバージョンアップする/tasks/main.yml

・myapp_verup/roles/Apacheをバージョンアップする/templates/httpd.conf.j2

※ 上記変数部分は、例えばInventoryファイルに記述した変数の値に自動で 置き換えることができます。

・myapp_verup/roles/Apacheをバージョンアップする/vars/main.yml

playbookの実行

実行結果は以下の通りです。
日本語で書いたタスクがそのままターミナル上のログに出力されていることが確認できます。
（/tmp/ansible.log にも出力されます。)

最後に

本記事は、運用チーム向けにAnsibleを使ったバージョンアップ自動化提案後に書いた記事です。
本番運用が開始されれば、いろいろと課題はでてくると思いますので、知見がたまりましたら
改めて情報を共有させていただこうと思います。

以上、ありがとうございました。