はじめに
この記事は、Leveragesアドベントカレンダー10日目の記事になります。
IaCのツール群のうちサーバー構成管理ツール(Ansible)を
自分の担当サービス(看護のお仕事)に導入してみました。
今回は導入理由とAnsibleを採用するに至った経緯を書いてみます。
(余裕があれば導入過程でたどり着いたベストプラクティス等を後日書きます）
※12/12追記 ベストプラクティスも書いてみました Ansible 俺流 Best Practices
Infrastructure as Code(IaC)とは
IaCでは大きく使用するツールを下記の4つに分類できます。
- ダイナミックインフラストラクチャプラットフォーム（AWS,GCP等）
- インフラストラクチャ定義ツール（Terraform等）
- サーバー構成ツール（Ansible,Chef等）
- インフラストラクチャサービス（モニタリング等の環境管理用ツール）
メリット
冪等性により、インフラ設定関連でのバグが減る
冪等性とは「大雑把に言って、ある操作を1回行っても複数回行っても結果が同じであることをいう概念である」
冪等 - Wikipedia
つまりどのサーバーに対してでも、同じ変更を行うことができ、結果が変わらないことを保証できます。
これにより、テスト環境で確認した設定と同じものを本番に反映しやすくなります。
また不必要に二重に変更を行うことがなくなります。
手作業による操作ミスを減らす
IaCが導入されていない場合、マニュアルなどに従って設定を行うことが多くありますが、
マニュアル管理だとマニュアルの更新忘れや設定を忘れたりなどのミスが起こりえます。
コード管理にすることにより、それらの設定内容を確認しやすくなるだけでなく、
仮にインフラ担当者がいない状況でも同様のサーバーの構築が可能となります。
デメリット
サーバー環境の変更に時間がかかる
コードを書いてからサーバーに変更を適用することになるので、
どうしてもサーバー環境の変更をするための時間は増えていきます。
学習コストがかかる
いままの学習コストにプラスしてそれぞれのツールに関しても
基本的な部分は作業担当者は知識を持っている必要があります。
なぜサーバー構成管理ツールから導入したか
導入しようと思い立ったきっかけ
2016年当時の看護のお仕事は応募フォームなど個人情報を扱うページのみSSL化していましたが、
その他のページでも個人情報を扱う必要が出てきたため全ページのSSL化対応をする必要があり、
2016/8に全ページSSL化の対応をしました。
ちなみに当時の環境は下記のようになっていました。
従来の環境
- さくらのVPSにて運用
- インフラの構成や変更作業は担当エンジニアの手作業で行う
- サーバー構成は開発,ステージング,本番で異なる
- 開発やステージングで動作確認した内容が本番で動かないことがある
このような環境だったため、インフラ構成の変更も容易には出来ない環境になっており、
構成変更に伴う確認作業も安心して行えない状況になっていました。
SSL化対応はこの状況で行いましたが、
今後もインフラ関係の作業が発生することを考えると早急に改善策を設ける必要がありました。
サーバー構成管理ツールから導入しようとしたわけ
Infrastructure as Code(IaC)とはでも述べたように
IaCには4つのツール群があります。
このうちダイナミックインフラストラクチャプラットフォームとインフラストラクチャ定義ツールの2つは
下記の理由によりサーバー構成ツール導入後に対応することにしました。
- プラットフォームを変えようにもそもそものサーバー内の構成が把握できていない
- サーバー構成ツールを利用している環境下のほうがより価値を発揮すること
またインフラストラクチャサービスに関しては
今回はインフラの構成把握と管理が目的だったため対応候補から外しました。
これらの判断基準によりまず最初にサーバー構成ツールを導入することに決めました。
サーバー構成ツールとしてAnsibleを採用した理由
技術選定
技術選定段階では主にAnsible,Chef,Itamaeの3つを比較しました。
下記に3つのツールのメリットとデメリットをまとめました。
参考:構成管理ツール比較表(サクラのナレッジより)
Ansible
メリット
- 言語仕様としてYAMLを採用(実装言語はPythonだが、Ansible使用者が触るのはほとんどYAML)
- YAMLのおかげで記述をシンプルかつ可読性高く保てる
- 学習コストが少なくて済む
- 必要なファイル群が少なくて済む
- プロビジョニング先にAnsibleをインストールする必要はなし（実行環境にのみインストールされていればよい)
デメリット
- 繰り返しの実行などがモジュールによっては複雑になる
- プロビジョニング対象が大規模になるとコードが属人化しやすい
- 大規模な構成の場合、きちんとディレクトリ構成を決めて管理する必要がある
Chef
メリット
- Rubyを採用しているため、Ansibleと比べて繰り返し処理を書きやすい
- 大規模な構成でも対応可能なツールが揃っている(Chef-Serverなど)
- Chef-ServerがあればWebUIをつかって確認が可能
デメリット
- 学習コストがすごく高い
- 設定ファイルの記述がRubyそのもの
- Chefの構成要素が多く、変更コストも高い
- プロビジョニング対象にChefを入れておく必要がある(Chef-server,Chef-client)
- 一応スタンドアロンなChef-soloもある
Itamae
メリット
- シンプルなChef
- 必要なファイル群が少ない
- 学習コストがChefほど多くない
- プロビジョニング対象にItamaeはいらない
デメリット
- シンプルとはいえChefの派生
- 設定ファイルの記述がRubyそのもの
- 対象nodeごとにレシピが必要
Ansibleを採用した理由
Ansibleを採用した理由は主に下記の3点です。
- 言語仕様としてYAMLを採用
- 必要なファイル群が少なくて済む
- プロビジョニング先にAnsibleをインストールする必要はなし（実行環境にのみインストールされていればよい)
特に言語仕様としてYAMLを採用していたのは大きかったです。
初めてチームにこういうツールを入れる上では学習コストの少なさと可読性の高さは採用するための大きな要因の一つになりました。
また、プロビジョニングツールとしては対象先に何も入れないままプロビジョニングを開始出来るという点も素晴らしかったです。
まとめ
今回Ansibleを導入してみた結果、下記のような恩恵を大きく受けることが出来ましたので
まだサーバー構成ツールを導入していないチームや導入を検討しているチームは
サーバー構成ツール(特にAnsible）を導入することをおすすめします。
- 構成の変更が容易
- 開発環境を本番環境と同様の設定で構成できる
- 簡単に本番環境の破棄、切り替えが可能
- インフラ担当者が変更してもナレッジをコードさえあれば共有出来る