Infrastructure as Code
Infrastructure as Code（IaC） はコンピューティング・インフラ（プロセス、ベアメタルサーバー、仮想サーバーなど）の構成管理・機械処理可能な定義ファイルの設定・プロビジョニングを自動化するプロセスである。定義されたファイルはバージョン管理システムで保持することもある。従来、手動のプロセスではなくスクリプトや宣言的な定義によって行われていたが、IaCの開発は今では、宣言的なアプローチに焦点が当てられている[1]。
概要
編集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つの方法がある。主な違いは、サーバーの設定方法である。プルの方法では、構成するサーバーは制御サーバーから構成を引き出す。プッシュの方法では、制御サーバーは宛先システム・サーバーに構成を重ね書きする。
モジュール化
編集インフラストラクチャーをコード化する思想に基づき、プログラミング言語におけるモジュールと同様のモジュールがインフラストラクチャーにも導入できる。1つのインフラストラクチャーをいくつかのまとまりに分割し、各まとまりに対する設定ファイルを用意する。設定ファイル間の読み込みシステムすなわちモジュールimportの仕組みが存在すれば、モジュールの粒度でインフラストラクチャーを管理し、それを組み合わせてインフラストラクチャー全体を構成できる。例えばAWS CloudFormationではstackをモジュール単位としてモジュールを読み込む仕組み（Nested Stacks）が整備されている[4]。
自動生成
編集インフラストラクチャーをコード化する思想に基づき、プログラミングにおけるコード自動生成と同様の自動生成がインフラストラクチャーにも導入できる。IaCによってインフラストラクチャーのプロビジョニングはコードにより実行される。ゆえにこのプロビジョニングコード自体を自動生成できれば、ある種のインフラ設計を自動化できる。
API開発ではschemaからフロントエンドコード、サーバースタブを自動生成する技術（c.f. スキーマ駆動開発）が存在する。通常サーバー自体は手動で立ち上げられるかIaC技術を用いてプロビジョニングコードにより自動構成される。しかしスキーマを基にプロビジョニングコードを自動生成できれば、そのまま生成されたコードによってインフラの自動プロビジョニングまでおこなうことが可能である。例えばAmazon Web Services AmplifyではGraphQL schemaを定義することで、schemaにあわせたGraphQL API・バックエンドデータベースのプロビジョニングコード（AWS CloudFormation Templates）を自動生成し、そのままAWS上へデプロイすることが可能である[5]。上記のフロントエンドコード生成も可能であり、これを用いればSchemaを設計し1コマンドでバックエンドサーバー（APIエンドポイント、データベース）とフロントエンドライブラリが利用可能な状態にできる。
この自動生成は、IaC思想に基づいた「プロビジョニングコード」が存在するからこそ可能になった技術である。このようにインフラストラクチャーをコードとして扱うことで様々なソフトウェア開発手法をインフラストラクチャー開発に導入できる。
ツール
編集インフラストラクチャの自動化機能を提供し、IaCを利用するツールが多い。大まかに言えば、プログラム的アプローチに基づいてインフラストラクチャを宣言型・命令型で変更・設定するフレームワーク・ツールはすべてIaCと考えることができる。従来は、サーバー（ライフサイクル）の自動化と構成管理ツールを使用してIaCを実現したが、現在、企業はマイクロソフトのPowerShell DSC などのContinuous Configuration Automation – CCA のツール・スタンドアローンIaCフレームワークを利用している[6]。
Continuous Configuration Automation
編集全てのCCAツールは従来のIaCフレームワークの拡張機能と考えられる：IaCを活用し、インフラストラクチャを変更、構成、自動化することができるが、インフラストラクチャの管理の可視性、効率性、柔軟性も提供する。この追加の機能は、企業レベルのセキュリティとコンプライアンスを提供するため、このようなツールに対して企業は関心を持っているようだ。
コミュニティ・コンテンツ
編集CCAツールがオープンソースの場合、コミュニティコンテンツとしての重要な側面を持つ。ガートナーがCCAツールの価値は、「オートメーションツールの商業的成熟度とパフォーマンスと同じように、ユーザーコミュニティが提供するコンテンツとサポートに依存している」と述べている。 PuppetやChefのような比較的長期間にわたるベンダーは、独自のコミュニティを作った―ChefはChef Community Repositoryで、PuppetはPuppetForgeである。他のベンダーは、隣接するコミュニティに依存し、PowerShell DSC等の他のIaCフレームワークを活用している。コンテンツ駆動型ではなく、モデル駆動型の新しいベンダーが登場している。このような視覚指向とオブジェクト指向システムは開発者には有用である。さらに、生産指向のDevOpsとコンテンツのスクリプト対モデルを評価する運用担当者の構成要素にとって特に有用となる。IaCツールがモデル駆動型で、オブジェクト指向のものでなければ、市場の発展と変化に伴い、コミュニティ・コンテンツはIaCツールの活用方法にとって重要となる。
CCAのツールの一覧
編集| ツール | 会社 | 方法 | 宣言型 | 制御ファイル | 構成ファイル書式 | アーキテクチャ | サーバ側待ち受けポート |
|---|---|---|---|---|---|---|---|
| Ansible / Ansible Tower | Ansible (RedHat) | プッシュ | 宣言型と命令型 | プレイブック | YAML形式 | エージェントレス | |
| Terraform | HashiCorp | プッシュ | 宣言型 | コンフィグレーション | HCL形式、HCL2形式 | エージェントレス | |
| Puppet | Puppet | プル | 宣言型 | マニフェスト | 独自形式 | エージェント | TCP8140番 |
| Chef | Chef | プル | 命令型 | レシピ、ランリスト | Ruby言語 | エージェント | TCP10002番 |
| CFEngine | CFEngine | プル | 宣言型 | ||||
| Otter | Inedo | プッシュ | 宣言型と命令型 | ||||
| SaltStack | SaltStack | プッシュとプル | 宣言型と命令型 |
DevOpsとの関係
編集IaCはDevOpsのベスト・プラクティスを実現する重要な要素だろう。開発者はもっと構成の定義に参加するようになり、運用チームは、開発プロセスの初期段階で入ってくるようになる。IaCを活用するツールはサーバーの状態・構成を視覚化し、企業内のユーザーに視覚性を提供し、最終的に努力を最大限にするために、チームを結集することを目指している。 一般的に、自動化は、手作業のプロセスの混乱とエラーの起こりやすい部分を取り除き、より効率的かつ生産的にすることを目指している。手動構成の効率を低下させる複雑さを軽減することも目的としてる。柔軟性が高く、ダウンタイムが少なく、全体的に費用効果が高いソフトウェアとアプリケーションを作成できる。 自動化と共同作業は、DevOpsの中心的なポイントであるため、多くの場合、インフラストラクチャ自動化ツールはDevOpsツールチェーンのコンポーネントとして含まれている[7]。
関連項目
編集脚注
編集- ^ Wittig, Andreas; Wittig, Michael (2016). Amazon Web Services in Action. Manning Press. p. 93. ISBN 978-1-61729-288-0
- ^ Riley, Chris (2015年11月12日). “Version Your Infrastructure”. DevOps.com. Template:Cite webの呼び出しエラー：引数 accessdate は必須です。[リンク切れ]
- ^ Loschwitz, Martin (14 November 2014). “Choosing between the leading open source configuration managers”. Admin Network & Security (Lawrence, KS USA: Linux New Media USA LLC).
- ^ AWS User Guide
- ^ GraphQL Transform. Amplify JavaScript. "With the GraphQL Transform, you define your application’s data model using the GraphQL Schema Definition Language (SDL) and the library handles converting your SDL definition into a set of fully descriptive AWS CloudFormation templates that implement your data model."
- ^ Chaganti, Ravikanth (5 January 2016). “DevOps, Infrastructure as Code, and PowerShell DSC: The Introduction”. PowerShell Magazine (PowerShell Magazine) 11 January 2016閲覧。.
- ^ Wurster, Laurie F.; Colville, Ronni J.; Height, Cameron; Tripathi, Somendra; Rastogi, Aditi. Emerging Technology Analysis: DevOps a Culture Shift, Not a Technology (Report). Gartner.