Infrastructure as Code

出典: フリー百科事典『ウィキペディア(Wikipedia)』
Jump to navigation Jump to search

Infrastructure as Code(IaC) というのは、物理的なハードウェア構成やインタラクティブな設定ツールの使用ではない。コンピューティング・インフラ(プロセス、ベアメタルサーバー、仮想サーバー、など)の構成を管理したり、機械処理可能な定義ファイルを設定したり、プロビジョニングを自動化するプロセスである。なお、定義されたファイルはバージョン管理システムで保持することもある。従来、手動のプロセスではなくスクリプトや宣言的な定義によって行われていたが、IaCの開発は今では、宣言的なアプローチに焦点が当てられている。[1]

クラウドコンピューティングの採用とともに、IaCアプローチは 広く普及している。しばしばInfrastructure as a Service (「サービスとしてのインフラストラクチャー(IaaS)) として間違って販売されていることがあるが、IaCはIaaSをサポートはしているが、その2つを混同すべきではない。

概要[編集]

IaCは、2つの破壊的な技術(ユーティリティコンピューティングと第2世代のWebフレームワーク)の難点に対処することで成長した。以前は、このようなスケーラビリティーの問題は巨大企業でしか見つかっていなかったが、今では多くの企業で広がっている。具体的には、2006年に新しい課題が最前線にもたらされて、技術産業を揺るがした:Amazon Web ServicesのElastic Compute Cloudと、数ヶ月前のRuby on Rails 1.0版の発売。この新しい分野を処理するツールが登場するにつれて、IaCが生まれてきた。ソフトウェア開発者とITインフラ管理者は、現在のソフトウェアのベスト・プラクティスを使用して、コードを使ってインフラストラクチャを再編成し、アプリのインフラを設計、実装、展開できることに興味を示している。インフラをコードのように扱い、他のソフトウェア・プロジェクトと同じツールを使用することで、開発者はアプリを迅速に展開できる. [2]


付加価値と利点[編集]

IaCの価値は、測定可能な3つのカテゴリに分類できる:コスト(削減)、スピード(実行の高速化)、リスク(エラーとセキュリティ違反の除去)。コスト削減は財務面だけではなく、労力の面でも企業のメリットとなる。手動コンポーネントを削除することで、従業員は他の作業に集中できる。インフラを自動化することで、インフラを構成したり、高速な実行が可能になる。そして、他のチームが迅速かつ効率的に作業できるための可視性を提供する。手動設定ミスのような人的ミスのリスクを排除することで、ダウンタイムが減少し、信頼性が向上する。このような結果と属性は企業がDevOps文化を実装するのに役立つ。

アプローチの種類[編集]

宣言型プログラミング(機能的)、命令型プログラミング(手続き的)、とインテリジェント(環境認識)の3つのIaCアプローチがある。それらの違いは「何」「どのように」と「なぜ」の違いと同じである。[3]

宣言型プログラミング(機能的)は「何」[編集]

  • 最終的なターゲット設定が何であるべきかに焦点を当てている。
  • 目的の様子(所望の状態?)を定義すると、システムはその様子を達成するために必要な何かを実行する。

命令型プログラミング(手続き的)は「どのように」[編集]

  • 最終的なターゲット設定を満たすために、インフラがどのように変化すべきかに焦点を当てている。
  • 目的の様子で終了するために、適切な順序で実行する必要があるコマンドを定義する。

インテリジェント(環境認識)は「なぜ」[編集]

  • 同じインフラストラクチャで実行されている複数のアプリケーションの全ての相互関係と依存性を考慮し、最終的なターゲット設定が、特定の方法による理由に焦点を当てている。
  • 相互依存(共依存)アプリケーションに影響を与えないように、システムは起こる必要がある何かを処理する前に、目的の状態を決定する。

環境を意識した状態がIaCの次世代である。

方法[編集]

IaCには、「プッシュ」と「プル」の2つの方法がある。主な違いは、サーバーの設定方法である。プルの方法では、構成するサーバーは制御サーバーから構成を引き出す。プッシュの方法では、制御サーバーは宛先システム・サーバーに構成を重ね書きする。

ツール[編集]

インフラストラクチャの自動化機能を提供し、IaCを利用するツールが多い。大まかに言えば、プログラム的アプローチに基づいてインフラストラクチャを宣言型・命令型で変更・設定するフレームワーク・ツールはすべてIaCと考えることができる。従来は、サーバー(ライフサイクル)の自動化と構成管理ツールを使用してIaCを実現したが、現在、企業はマイクロソフトのPowerShell DSC などのContinuous Configuration Automation – CCA のツール・スタンドアローンIaCフレームワークを利用している[4]

Continuous Configuration Automation[編集]

全てのCCAツールは従来のIaCフレームワークの拡張機能と考えられる;IaCを活用し、インフラストラクチャを変更、構成、自動化することができるが、インフラストラクチャの管理の可視性、効率性、柔軟性も提供する。この追加の機能は、企業レベルのセキュリティとコンプライアンスを提供するため、このようなツールに対して企業は関心を持っているようだ。

コミュニティ・コンテンツ[編集]

CCAツールがオープンソースの場合、コミュニティコンテンツとしての重要な側面を持つ。ガートナーがCCAツールの価値は、「オートメーションツールの商業的成熟度とパフォーマンスと同じように、ユーザーコミュニティが提供するコンテンツとサポートに依存している」と述べている。 PuppetやChefのような比較的長期間にわたるベンダーは、独自のコミュニティを作った;ChefはChef Community Repositoryで、PuppetはPuppetForgeである。他のベンダーは、隣接するコミュニティに依存し、PowerShell DSC等の他のIaCフレームワークを活用している。コンテンツ駆動型ではなく、モデル駆動型の新しいベンダーが登場している。このような視覚指向とオブジェクト指向システムは開発者には有用である。さらに、生産指向のDevOpsとコンテンツのスクリプト対モデルを評価する運用担当者の構成要素にとって特に有用となる。IaCツールがモデル駆動型で、オブジェクト指向のものでなければ、市場の発展と変化に伴い、コミュニティ・コンテンツはIaCツールの活用方法にとって重要となる。

CCAのツールには[編集]

ツール 会社 方法 宣言型
Ansible Tower Ansible (RedHat) プッシュ 宣言型と命令型
CFEngine CFEngine プル 宣言型


Chef Chef プル 命令型


Otter Inedo プッシュ 宣言型と命令型
Puppet Puppet プル 宣言型
SaltStack SaltStack プッシュとプル 宣言型と命令型

DevOpsとの関係[編集]

IaCはDevOpsのベスト・プラクティスを実現する重要な要素だろう。開発者はもっと構成の定義に参加するようになり、運用チームは、開発プロセスの初期段階で入ってくるようになる。IaCを活用するツールはサーバーの状態・構成を視覚化し、企業内のユーザーに視覚性を提供し、最終的に努力を最大限にするために、チームを結集することを目指している。 一般的に、自動化は、手作業のプロセスの混乱とエラーの起こりやすい部分を取り除き、より効率的かつ生産的にすることを目指している。手動構成の効率を低下させる複雑さを軽減することも目的としてる。柔軟性が高く、ダウンタイムが少なく、全体的に費用効果が高いソフトウェアとアプリケーションを作成できる。 自動化と共同作業は、DevOpsの中心的なポイントであるため、多くの場合、インフラストラクチャ自動化ツールはDevOpsツールチェーンのコンポーネントとして含まれている。[5]

脚注[編集]

  1. ^ Wittig, Andreas; Wittig, Michael (2016). Amazon Web Services in Action. Manning Press. p. 93. ISBN 978-1-61729-288-0. 
  2. ^ Riley, Chris (12 November 2015). “Version Your Infrastructure”. DevOps.com. http://devops.com/2015/11/12/version-your-infrastructure/. 
  3. ^ Loschwitz, Martin (14 November 2014). “Choosing between the leading open source configuration managers”. Admin Network & Security (Lawrence, KS USA: Linux New Media USA LLC). http://www.admin-magazine.com/Archive/2014/23/Choosing-between-the-leading-open-source-configuration-managers. 
  4. ^ Chaganti, Ravikanth (5 January 2016). “DevOps, Infrastructure as Code, and PowerShell DSC: The Introduction”. PowerShell Magazine (PowerShell Magazine). http://www.powershellmagazine.com/2016/01/05/devops-infrastructure-as-code-and-powershell-dsc-the-introduction/ 2016年1月11日閲覧。. 
  5. ^ Wurster, Laurie F.; Colville, Ronni J.; Height, Cameron; Tripathi, Somendra; Rastogi, Aditi. Emerging Technology Analysis: DevOps a Culture Shift, Not a Technology (Report). Gartner.