DevOpsについて～Ansibleができること～
お疲れ様です。伊藤です。
引き続き社内研修用の緩めの内容が続きますがご了承ください。
前回DevOpsにおける問題点について書きました（DevOpsについて～現場で起こっている問題～ - ときどきAnsible日記）今回は、じゃあそれをどうやって解決するの？というところについて書いていきたいと思います。
前回記述した問題点ではシステム開発者が本番環境の環境保守をできないところに問題がある、という内容の記述をしたと思います。ではなぜそれができないかを考えてみましょう。
そもそも前回も記述しましたが、テスト環境については開発者が環境を変更する事は多々あります。ではなぜ本番環境は無理なのか？というところです。経験則から下記のような部分が問題になると考えています。
- 規模が大きい
- ドキュメント修正負荷が大きい
- 構成が複雑
これらの問題により作業工数が増えてしまい、ただでさえシステム開発で忙しいのにこんなことできないよ！というのが問題かと。
詳細に見てみます。
- 規模が大きい
- 本番環境の場合はテスト環境の数倍から数十倍の規模の可能性があります。テスト環境では1台に変更すれば良かったものが本番環境になると数台に、また他の環境にも合わせるとなると数十台～数百台に同じ設定変更をする必要が発生してきます。それに合わせて後述の影響調査も増えていくことになります。
- ドキュメント修正負荷が大きい
- これはインフラにかかわったことがある人であれば誰しもが経験したことがあると思います。本番環境は当然ながら簡単には設定変更はできません。さまざまなドキュメントを変更しつつ、さらには大量のレビューの嵐をくぐり抜け、時には昔の修正漏れにぶつかり、とにかく時間をとられます。ドキュメント修正が大変だから値を変えないでおこう、なんてことが普通に繰り広げられることもあります。
- 構成が複雑
- テスト環境は基本的に（システムにもよりますが）現在作成しているプログラムが動けばいい、という環境になっています。ということで他のシステムへの影響や整合性は基本は考えられていません。なので個別に環境変更してもあまり影響がありませんが、本番環境の場合はちょっとした環境変更が他システムへも影響してしまい、大きな問題になることがあります。そのためインフラ技術者は常に他のシステムへの影響を確認して本当にこの値を変更してよいのか？というのを確認します。
また、開発者とインフラ技術者が分かれていることで、本番環境に反映する際に、やっぱりこの設定変更はダメよ、ということが判明する場合（よくケンカになるやつ）もあります。その時にはプログラムの再修正やテストのやり直しなど非常に大きなロスが発生する場合があります。そうならないためにも事前に環境の変更についてはシステム開発者とインフラ技術者で意識を合わせる必要があるのです。
ではここでAnsibleを使った場合にどのようなメリットがあるかを考えます。Ansible自体にどのような機能があるかはこちら（そもそもAnsibleって何？ - ときどきAnsible日記）をご参照ください。
それぞれの問題に対して下記のメリットがあると考えられます。
- 大規模システムへの対応
- 言わずもがなAnsibleは環境変更を自動的に行うことができるアプリケーションですので、直接的に効果を発揮できます。
- ドキュメントによる管理からの脱却
- AnsibleではPlaybookというプログラムをもって設定変更を行います。こちらのPlaybookをドキュメント（詳細設計書）の代わりとすることで常に実機と設計書の整合性は保てます。
- 環境別への対応
- AnsibleではInventoryファイルという環境別の設定ファイルがあります。基本的な構成は本番環境とテスト環境で全く同じものとし、IPやホスト名などの部分はInventoryファイルで対応する事が可能です。
少々強引ではありますが、Ansibleであればこれらの問題を解決することが可能です。（まあそれまでにはドキュメント方針を決めたり、本番環境とテスト環境を見直したり色々な苦労が必要がですが）
もし、一から環境を作る必要があった場合、今後はAnsibleなどの構成管理ツールを前提に考えることで後のシステム運用に対応し、DevOps体制を作ることが出来る（かもしれません）
今回はここまでです。
お疲れ様でした。
