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

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

今回もDevOpsについての続きです。まだ読んでない方は前回・前々回の記事（DevOps カテゴリーの記事一覧 - ときどきAnsible日記）を読んでいただくと理解が早いかと。
さて前回はDevOps体制を作るためにAnsibleがコーユー風に使えるよ、というのを記事にしました。簡単に説明しますと、本番環境の設定変更は大変だから簡単にやるためにAnsibleを使って設定変更をしよう！という内容でした。

で、今回はDockerを使ってDevOps体制を目指そうというパターンです。Dockerの場合はAnsibleの時と少々考え方が変わります。なおDockerって何？という方はこちら（Dockerコンテナの概要 - ときどきAnsible日記)を読んでいただけるとありがたいです。
Ansibleの場合は、設定変更を行うのが大変、という前提でした。が、Dockerの場合は設定変更を大変にさせないためにDockerを導入しよう、という考え方になります。
これだけ読んで「なるほど」となる方は基本的ににこれ以降は読む必要はございません。「はぁ？」となった方に向けてこれ以降の記事を書きます。

そもそも設定変更が必要というのは、元になるサーバがあってその上にアプリケーションを乗せる際に、元のサーバの設定を変える必要がある、ということです。それに対してDockerは「設定を含めたアプリケーションの実行環境」となり、Dockerを使ってアプリをリリースする、ということはテスト環境で動作したアプリが入ったコンテナをそのまま本番環境に持っていくということになります。それにより環境変更漏れはなくなり、実際に動いていたものがそのまま本番環境で動くことになります。

これができるのはDockerが持ち運び可能なコンテナであり、コンテナ内でのアプリケーションの動作はどのサーバ上でも保証される、というポータビリティがあるためです。
この技術を使い、今まで煩雑だった設定変更とアプリのリリースを簡易化することができます。

ただし、この実現についても、アプリケーションをDockerコンテナに作り替える必要がある、本番と試験環境を全く同じにする必要がある（IPなどはコンテナ起動時に変えられますが）などのさまざまな課題が発生します。

とりあえず今回はここまです。
お疲れ様でした。

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

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

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

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

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

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

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

詳細に見てみます。

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

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

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

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

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

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

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

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