DevOpsについて～Ansibleができること～

お疲れ様です。伊藤です。

引き続き社内研修用の緩めの内容が続きますがご了承ください。
前回DevOpsにおける問題点について書きました（DevOpsについて～現場で起こっている問題～ - ときどきAnsible日記）今回は、じゃあそれをどうやって解決するの？というところについて書いていきたいと思います。

前回記述した問題点ではシステム開発者が本番環境の環境保守をできないところに問題がある、という内容の記述をしたと思います。ではなぜそれができないかを考えてみましょう。

そもそも前回も記述しましたが、テスト環境については開発者が環境を変更する事は多々あります。ではなぜ本番環境は無理なのか？というところです。経験則から下記のような部分が問題になると考えています。

• 規模が大きい
• ドキュメント修正負荷が大きい
• 構成が複雑

これらの問題により作業工数が増えてしまい、ただでさえシステム開発で忙しいのにこんなことできないよ！というのが問題かと。

詳細に見てみます。

• 規模が大きい
  • 本番環境の場合はテスト環境の数倍から数十倍の規模の可能性があります。テスト環境では1台に変更すれば良かったものが本番環境になると数台に、また他の環境にも合わせるとなると数十台～数百台に同じ設定変更をする必要が発生してきます。それに合わせて後述の影響調査も増えていくことになります。

• ドキュメント修正負荷が大きい
  • これはインフラにかかわったことがある人であれば誰しもが経験したことがあると思います。本番環境は当然ながら簡単には設定変更はできません。さまざまなドキュメントを変更しつつ、さらには大量のレビューの嵐をくぐり抜け、時には昔の修正漏れにぶつかり、とにかく時間をとられます。ドキュメント修正が大変だから値を変えないでおこう、なんてことが普通に繰り広げられることもあります。

• 構成が複雑
  • テスト環境は基本的に（システムにもよりますが）現在作成しているプログラムが動けばいい、という環境になっています。ということで他のシステムへの影響や整合性は基本は考えられていません。なので個別に環境変更してもあまり影響がありませんが、本番環境の場合はちょっとした環境変更が他システムへも影響してしまい、大きな問題になることがあります。そのためインフラ技術者は常に他のシステムへの影響を確認して本当にこの値を変更してよいのか？というのを確認します。

また、開発者とインフラ技術者が分かれていることで、本番環境に反映する際に、やっぱりこの設定変更はダメよ、ということが判明する場合（よくケンカになるやつ）もあります。その時にはプログラムの再修正やテストのやり直しなど非常に大きなロスが発生する場合があります。そうならないためにも事前に環境の変更についてはシステム開発者とインフラ技術者で意識を合わせる必要があるのです。

ではここでAnsibleを使った場合にどのようなメリットがあるかを考えます。Ansible自体にどのような機能があるかはこちら（そもそもAnsibleって何？ - ときどきAnsible日記）をご参照ください。
それぞれの問題に対して下記のメリットがあると考えられます。

• 大規模システムへの対応
  • 言わずもがなAnsibleは環境変更を自動的に行うことができるアプリケーションですので、直接的に効果を発揮できます。
• ドキュメントによる管理からの脱却
  • AnsibleではPlaybookというプログラムをもって設定変更を行います。こちらのPlaybookをドキュメント（詳細設計書）の代わりとすることで常に実機と設計書の整合性は保てます。
• 環境別への対応
  • AnsibleではInventoryファイルという環境別の設定ファイルがあります。基本的な構成は本番環境とテスト環境で全く同じものとし、IPやホスト名などの部分はInventoryファイルで対応する事が可能です。

少々強引ではありますが、Ansibleであればこれらの問題を解決することが可能です。（まあそれまでにはドキュメント方針を決めたり、本番環境とテスト環境を見直したり色々な苦労が必要がですが）
もし、一から環境を作る必要があった場合、今後はAnsibleなどの構成管理ツールを前提に考えることで後のシステム運用に対応し、DevOps体制を作ることが出来る（かもしれません）

今回はここまでです。
お疲れ様でした。

DevOpsについて～現場で起こっている問題～

お疲れ様です。伊藤です。

この度グループ会社内で、Ansible関連の説明会を行うことになりました。で、うちのグループなんですが基本的にシステム開発者メインで、インフラ技術者があまりいらっしゃいませんのでシステム開発者にも興味のある内容を、ということでDevOpsに絡めて説明を行います。

というわけでこちらでもちょっとDevOpsについてまとめておこうと思います。
そもそもDevOpsとは？というところからですが、ウィキペディアによると以下の通りになります。

DevOps（デブオプス）は、ソフトウェア開発手法の一つ。開発 (Development) と運用 (Operations) を組み合わせたかばん語であり、開発担当者と運用担当者が連携して協力する（さらに両担当者の境目もあいまいにする）開発手法をさす。厳密な定義は存在しておらず、抽象的な概念に留まっている。ソフトウェアのビルド、テスト、そしてリリースの文化と環境を以前よりも迅速に、頻繁に、確実に発生する確立を目指している。 また、DevOpsにビジネス部門を追加したBizDevOpsというワードも広がりつつある。

あまり明確な定義はなさそうですが、「システム開発者とインフラ技術者の垣根をなくす」という意味だと認識しております。もうちょっと具体的に言うと、開発者がシステムの設定変更（ユーザ追加したり、環境変数変えたり）なんかも行う、という感じかと思います。
（インフラ技術者は環境の構築やその後の保守運用を行いますが、Operationとは保守運用部分のことを言っています）

今までのシステム開発の現場によくある構図は下記のような形だと思います。まあいろいろな理由があって大体仲が悪いです（笑）

DevOpsだとこうなる！

ではなぜそんなことが謡われているか、というところになるかと思います。そのあたりを私の主観満載で今までの経験をもとに感じたことをまとめておきます。

基本的にシステムの開発環境はテスト環境、本番環境に分かれます。まあ、現場によってはステージング環境とか検証環境とか色々ありますが、通常の現場で行くとテストと本番は必ず分かれてるかなと。
で、これも現場によって違うのですが、大体はテスト環境はインフラ技術者が初期構築を行った後は、開発者側で設定変更を行うことが多いです。なぜなら開発の段階で追加の環境変数が必要だったり、テストを行うためにユーザを増やしたり、ということをいちいちインフラチームにお願いしていたら開発も遅れるし、双方の手間になるので。

ところが本番環境の構築時には設定変更は大体が、インフラ技術者が行うことになります。そうするとテスト環境で行った設定変更が漏れる、ということが発生します。

こういった問題(もちろんこれだけではないですが)をなくすために、システム開発者が本番環境の設定変更やその後の環境管理も行う、というのがDevOpsが求められている理由だと思っています。それを実現するためにAnsibleやDockerの技術が利用できますが、そちらについてはまた別の記事で記述したいと思います。

それではお疲れ様でした。