Loading article…
Infrastructure as code ( IaC ) は、物理的なハードウェア構成や対話型構成ツールではなく、機械可読な定義ファイルを通じてコンピュータデータセンターの リソースを管理およびプロビジョニングするプロセスです。 [1]このプロセスによって管理される IT インフラストラクチャは、ベアメタルサーバーなどの物理的な機器と仮想マシン、および関連する構成リソースの両方で構成されます 。定義は、手動プロセスを通じてコードを保守するのではなく、バージョン管理システム内に存在する場合があります。定義ファイル内のコードでは、スクリプトまたは宣言型定義のいずれかを使用できますが、IaC では宣言型アプローチが採用されることが多いです。
概要
IaC は、ユーティリティ コンピューティングと第 2 世代の Web フレームワークがもたらす困難への対応として成長しました。2006 年、Amazon Web ServicesのElastic Compute Cloudと、その数か月前にリリースされたRuby on Railsのバージョン 1.0 [2]により、以前は大規模な多国籍企業でしか経験されなかったスケーリングの困難が企業全体に広がりました。[3]この成長を続ける分野に対処するための新しいツールが登場したことで、IaC のアイデアが生まれました。インフラストラクチャをコードでモデル化し、既知のソフトウェアのベスト プラクティスを使用してアプリケーション インフラストラクチャを設計、実装、展開する機能を持つという考えは、ソフトウェア開発者と IT インフラストラクチャ管理者の両方にとって魅力的でした。インフラストラクチャをコードとして扱い、他のソフトウェア プロジェクトと同じツールを使用できると、開発者はアプリケーションを迅速に展開できます。[4]
利点
IaC の価値は、コスト、スピード、リスクという 3 つの測定可能なカテゴリに分類できます。[要出典]コスト削減は、企業に財務面で貢献するだけでなく、人材と労力の面でも貢献することを目指しています。つまり、手動コンポーネントを排除することで、人々は他の企業タスクに力を注ぐことができるようになります。[要出典]インフラストラクチャの自動化は、インフラストラクチャを構成する際の実行を高速化することでスピードアップを実現し、可視性を提供して企業全体の他のチームが迅速かつ効率的に作業できるようにすることを目的としています。自動化により、手動による構成ミスなどの人為的エラーに関連するリスクが排除されます。人為的エラーを排除することで、ダウンタイムが短縮され、信頼性が向上します。これらの結果と属性は、企業が開発と運用を組み合わせたDevOpsの文化の実装に向けて進むのに役立ちます。[5]
アプローチの種類
IaC には一般に、宣言型(機能的) と命令型(手続き的) の2 つのアプローチがあります。宣言型アプローチと命令型アプローチの違いは、本質的に「何」と「どのように」です。宣言的アプローチは、最終的なターゲット構成がどうあるべきかに焦点を当てています。命令型は、これを満たすためにインフラストラクチャをどのように変更するかに焦点を当てています。 [6]宣言型アプローチは、望ましい状態を定義し、システムはその望ましい状態を達成するために必要なことを実行します。命令型は、望ましい結論に至るために適切な順序で実行する必要がある特定のコマンドを定義します。[7]
方法
Infrastructure as Code (IaC) を使用すると、コードを使用してサーバーとその構成を管理できます。これらの構成をサーバーに送信するには、「プッシュ」方式と「プル」方式の 2 つの方法があります。「プッシュ」方式では、構成を制御するシステムがサーバーに直接指示を送信します。「プル」方式では、サーバーは制御システムから独自の指示を取得します。[8]
ツール
インフラストラクチャ自動化機能を実現し、IaCを使用するツールは数多くあります。大まかに言えば、プログラム的アプローチに基づいて宣言的または命令的にインフラストラクチャの変更や構成を実行するフレームワークやツールはすべてIaCと見なすことができます。[9]従来、IaCを実現するために、サーバー（ライフサイクル）自動化および構成管理ツールが使用されていました。現在、企業は継続的な構成自動化ツールや、MicrosoftのPowerShell DSC [10]やAWS CloudFormationなどのスタンドアロンのIaCフレームワークも使用しています。[11]
継続的な構成の自動化
すべての継続的構成自動化(CCA) ツールは、従来の IaC フレームワークの拡張版と考えることができます。これらのツールは、IaC を活用してインフラストラクチャを変更、構成、自動化し、インフラストラクチャの管理方法の可視性、効率性、柔軟性も提供します。[3]これらの追加属性により、エンタープライズ レベルのセキュリティとコンプライアンスが実現します。
コミュニティコンテンツ
コミュニティ コンテンツは、オープン ソース CCA ツールの品質を決定する重要な要素です。ガートナーが述べているように、CCA ツールの価値は「自動化ツールの商業的成熟度とパフォーマンスと同じくらい、ユーザー コミュニティが提供したコンテンツとサポートに依存します」。[3] PuppetやChefなどの定評あるベンダーは、独自のコミュニティを作成しています。Chef にはChef Community Repositoryがあり、Puppet にはPuppetForgeがあります。[12]他のベンダーは、隣接するコミュニティに依存し、 PowerShell DSCなどの他の IaC フレームワークを活用しています。 [10]コンテンツ駆動型ではなく、製品にインテリジェンスを備えたモデル駆動型の新しいベンダーが登場しています。これらの視覚的なオブジェクト指向システムは、開発者にとってうまく機能しますが、特に、コンテンツにスクリプトではなくモデルを重視する、本番指向の DevOps および運用構成員にとって便利です。この分野が発展し、変化し続けるにつれて、モデル駆動型でオブジェクト指向でない限り、コミュニティ ベースのコンテンツは、IaC ツールの使用方法にとってますます重要になります。
注目すべき CCA ツールには次のようなものがあります。
その他のツールには、AWS CloudFormation、cdist、StackStorm、Juju、Step CI などがあります。
人間関係
DevOpsとの関係
IaCは、DevOpsのベストプラクティスを実現するための重要な属性となり得ます。開発者は構成の定義にさらに関与するようになり、運用チームは開発プロセスの早い段階から関与するようになります。[13] IaCを活用するツールは、サーバーの状態と構成を可視化し、最終的には企業内のユーザーに可視化を提供し、チームを結集して最大限の努力をすることを目指します。[14]自動化は一般的に、手動プロセスの混乱やエラーが発生しやすい側面を取り除き、より効率的で生産的なものにすることを目的としています。柔軟性、ダウンタイムの削減、そして会社にとって全体的に費用対効果の高い方法で、より優れたソフトウェアとアプリケーションを作成できるようにします。IaCは、手動構成の効率を低下させる複雑さを軽減することを目的としています。自動化とコラボレーションはDevOpsの中心点と考えられており、インフラストラクチャ自動化ツールは、DevOpsツールチェーンのコンポーネントとして含まれることがよくあります。[15]
セキュリティとの関係
サイバーセキュリティプロバイダーのパロアルトネットワークスの脅威インテリジェンス部門であるUnit 42が発表した2020年クラウド脅威レポートでは、コードテンプレートとしてのインフラストラクチャに約20万件の潜在的な脆弱性が特定されました。[16]
参照
参考文献
- ^ Wittig, Andreas; Wittig, Michael (2016). Amazon Web Services in Action . Manning Press. p. 93. ISBN 978-1-61729-288-0。
- ^ Bower, Joseph L.; Christensen, Clayton M. 「破壊的技術：波に乗る」ハーバード・ビジネス・レビュー。
- ^ abc Fletcher, Colin; Cosgrove, Terrence (2015 年 8 月 26 日)。継続的な構成自動化ツールに関するイノベーションの洞察。Gartner (レポート)。[リンク切れ ]
- ^ Riley, Chris (2015 年 11 月 12 日). 「インフラストラクチャのバージョン管理」. DevOps.com .
- ^ Phillips, Andrew (2015 年 5 月 14 日)。「インフラストラクチャ自動化から真の DevOps への移行」。DevOps.com。
- ^ 「構成管理における宣言型モデルと命令型モデル: どちらが優れているか?」Scriptrock.com。 2015 年 3 月 31 日時点のオリジナルよりアーカイブ。2015 年12 月 14 日閲覧。
- ^ Loschwitz, Martin (2014 年 11 月 14 日)。「主要なオープン ソース構成マネージャーの選択」。Admin Network & Security。ローレンス、カンザス州、米国: Linux New Media USA LLC。
- ^ Venezia, Paul (2013年11月21日). 「Puppet vs. Chef vs. Ansible vs. Salt」. Network World . Network World. 2018年7月18日時点のオリジナルよりアーカイブ。 2015年12月14日閲覧。
- ^ Garner Market Trends: DevOps – 市場ではなく、継続的デリバリーバリューチェーンをサポートするツール中心の哲学 (レポート)。Gartner。2015 年 2 月 18 日。
- ^ ab Chaganti, Ravikanth (2016 年 1 月 5 日)。「DevOps、Infrastructure as Code、PowerShell DSC: 概要」。PowerShell Magazine。PowerShell Magazine。2016年1 月 11 日閲覧。
- ^ 「AWS CloudFormation の紹介」。
- ^ スタージョン、フィル（2012年10月28日）。「人形かシェフか？」。2016年2月1日時点のオリジナルよりアーカイブ。 2016年1月29日閲覧。
- ^ Ramos, Martin (2015 年 11 月 4 日). 「Continuous Integration: Infrastructure as Code in DevOps」. easydynamics.com . 2016 年 2 月 6 日時点のオリジナルよりアーカイブ。 2016 年1 月 29 日閲覧。
- ^ Infrastructure As Code: より高速なアプリケーション配信への推進力 (レポート)。Forrester。2015 年 3 月。
- ^ Wurster, Laurie F.; Colville, Ronni J.; Height, Cameron; Tripathi, Somendra; Rastogi, Aditi. 「新興技術分析: DevOps は技術ではなく文化の変化 (レポート)」。Gartner。
- ^ 「クラウド脅威レポートは一貫したDevSecOpsの必要性を示している」InformationWeek。2020年2月13日。 2020年2月24日閲覧。