コードとしてのインフラストラクチャ

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

コードとしてのインフラストラクチャIaC )は、物理的なハードウェア構成やインタラクティブな構成ツールではなく、機械可読な定義ファイルを介してコンピューターデータセンターを管理およびプロビジョニングするプロセスです。[1] このプロセスによって管理されるITインフラストラクチャは、ベアメタルサーバーなどの物理機器と仮想マシンの両方および関連する構成リソースで構成されます。定義はバージョン管理システムにある可能性があります。定義ファイル内のコードは、手動プロセスを通じてコードを維持するのではなく、スクリプトまたは宣言型定義のいずれかを使用できますが、IaCはより頻繁に宣言型を使用しますアプローチ。

概要

IaCは、ユーティリティコンピューティングと第2世代のWebフレームワークによってもたらされる困難への対応として成長しました。2006年、AmazonWebServicesElasticComputeCloudとRubyonRailsの1.0バージョン[2]の立ち上げにより、以前は大規模な多国籍企業でしか経験されていなかった広範なスケーリングの問題が企業に発生しました。[3]この成長し続ける分野を処理するための新しいツールが登場したことで、IaCのアイデアが生まれました。コードを使用してインフラストラクチャをモデリングし、既知のソフトウェアのベストプラクティスを使用してアプリケーションインフラストラクチャを設計、実装、および展開する機能を持つという考えは、ソフトウェア開発者とITインフラストラクチャ管理者の両方にアピールしました。インフラストラクチャをコードのように扱い、他のソフトウェアプロジェクトと同じツールを使用できるため、開発者はアプリケーションを迅速に展開できます。[4]

利点

IaCの価値は、コスト、速度、リスクの3つの測定可能なカテゴリに分類できます。[要出典]コスト削減は、企業の経済的支援だけでなく、人と労力の面でも役立つことを目的としています。つまり、手動コンポーネントを削除することで、人々は他の企業タスクに再び注力できるようになります。[要出典]インフラストラクチャの自動化により、インフラストラクチャを構成する際の実行速度が向上し、企業全体の他のチームが迅速かつ効率的に作業できるように可視性を提供することを目的としています。自動化により、手動による設定ミスなどの人的エラーに関連するリスクが排除されます。これを削除すると、ダウンタイムが減少し、信頼性が向上します。これらの成果と属性は、企業が開発運用を組み合わせたDevOpsの文化の実装に向けて前進するのに役立ちます。[5]

短所

IaCは機械可読な定義ファイルを使用し、チューリング完全である場合とそうでない場合がありますチューリング完全性の欠如は、作成者がインフラストラクチャ定義と同じ言語でソフトウェアテストを提供することを妨げる可能性があります。[6]テストが不足していると、インフラストラクチャの展開に対する信頼が失われたり、テストへの参入障壁が高くなったりする可能性があります。[6] [7]

アプローチの種類

IaCには、一般に2つのアプローチがあります。宣言型(機能的)と命令型(手続き型)です。宣言型アプローチと命令型アプローチの違いは、本質的に「何」「どのように」です。宣言型アプローチは、最終的なターゲット構成がどうあるべきかに焦点を当てています。theこれに対応するためにインフラストラクチャをどのように変更するかに焦点を当てる必要があります。[8]宣言型アプローチは目的の状態を定義し、システムはその目的の状態を達成するために必要なことを実行します。命令型は、目的の結論で終了するために適切な順序で実行する必要がある特定のコマンドを定義します。[9]

メソッド

IaCには、プッシュプルの2つの方法があります。主な違いは、サーバーに構成方法を指示する方法です。プル方式では、構成するサーバーが制御サーバーから構成をプルします。pushメソッドでは、制御サーバーが構成を宛先システムにプッシュします。[10]

ツール

インフラストラクチャの自動化機能を実現し、IaCを使用するツールは多数あります。大まかに言えば、プログラムによるアプローチに基づいて宣言的または必須的にインフラストラクチャを変更または構成するフレームワークまたはツールは、IaCと見なすことができます。[11]従来、 IaCを実現するために、サーバー(ライフサイクル)の自動化および構成管理ツールが使用されていました。現在、企業は継続的構成自動化ツールや、MicrosoftのPowerShellDSC [12]AWSCloudFormationなどのスタンドアロンのIaCフレームワークも使用しています[13]

継続的構成の自動化

すべての継続的構成自動化(CCA)ツールは、従来のIaCフレームワークの拡張と考えることができます。IaCを活用してインフラストラクチャを変更、構成、自動化し、インフラストラクチャの管理方法の可視性、効率性、柔軟性も提供します。[3]これらの追加属性は、エンタープライズレベルのセキュリティとコンプライアンスを提供します。

コミュニティコンテンツ

CCAツールを検討する際の重要な側面は、オープンソースの場合、コミュニティコンテンツです。ガートナーが述べているように、CCAツールの価値は、「自動化ツールの商業的成熟度とパフォーマンスと同様に、ユーザーコミュニティが提供するコンテンツとサポートに依存しています」。[3] PuppetChefのようなベンダーは、かなりの期間を費やしており、独自のコミュニティを作成しています。ChefにはChefCommunityリポジトリがあり、PuppetにはPuppetForgeがあります。[14]他のベンダーは隣接するコミュニティに依存しており、PowerShellDSCなどの他のIaCフレームワークを活用しています。[12]コンテンツ主導ではなく、コンテンツを配信するための製品のインテリジェンスを備えたモデル主導の新しいベンダーが出現しています。これらの視覚的なオブジェクト指向システムは開発者にとってはうまく機能しますが、コンテンツのスクリプトよりもモデルを重視する本番指向のDevOpsおよび運用構成要素にとって特に役立ちます。この分野が発展し変化し続けるにつれて、コミュニティベースのコンテンツは、モデル駆動型でオブジェクト指向でない限り、IaCツールの使用方法にとってこれまで以上に重要になります。

注目すべきCCAツールは次のとおりです。

道具 によってリリース 方法 アプローチ で書かれている コメントコメント
シェフ シェフ(2009) 引く 宣言型および命令型 ルビー -
カワウソ 稲戸 押す 宣言型および命令型 - Windows指向
傀儡 人形(2005) 引く 宣言型および命令型 4.0以降のC++Clojure 、 Ruby -
SaltStack SaltStack プッシュアンドプル 宣言型および命令型 Python -
CFEngine Northern.tech 引く 宣言型 C -
Terraform HashiCorp(2014) 押す 宣言型 行け -
Ansible / Ansible Tower Red Hat(2012) 押す 宣言型および命令型 Python -

その他のツールには、AWS CloudFormationcdistStackStormJujuなどがあります。

DevOpsとの関係

IaCは、 DevOpsでベストプラクティスを実現するための重要な属性になる可能性があります。開発者は構成の定義により深く関与し、Opsチームは開発プロセスの早い段階で関与します。[15] IaCを利用するツールは、サーバーの状態と構成を可視化し、最終的には企業内のユーザーに可視性を提供し、チームをまとめて最大限の努力をすることを目的としています。[16]自動化は一般に、手動プロセスの混乱とエラーが発生しやすい側面を取り、それをより効率的かつ生産的にすることを目的としています。柔軟性、ダウンタイムの削減、および会社全体の費用対効果の高い方法で、より優れたソフトウェアとアプリケーションを作成できるようにします。IaCは、手動構成の効率を損なう複雑さを軽減することを目的としています。自動化とコラボレーションは、DevOpsの中心的なポイントと見なされています。インフラストラクチャ自動化ツールは、多くの場合、DevOpsツールチェーンのコンポーネントとして含まれています。[17]

セキュリティとの関係

Unit 42(サイバーセキュリティプロバイダーPalo Alto Networksの脅威インテリジェンスユニット)によってリリースされた2020 Cloud Threat Reportは、インフラストラクチャの約200,000の潜在的な脆弱性をコードテンプレートとして特定しました。[18]

も参照してください

参照

  1. ^ Wittig、Andreas; Wittig、Michael(2016)。動作中のAmazonWebサービスマニングプレス。p。93. ISBN 978-1-61729-288-0
  2. ^ バウアー、ジョセフL .; Christensen、Clayton M.「破壊的技術:波をキャッチする」。ハーバードビジネスレビュー
  3. ^ a b c フレッチャー、コリン; テレンスのコスグローブ(2015年8月26日)。継続的構成自動化ツールのイノベーションインサイトガートナー(レポート)。[デッドリンク]
  4. ^ ライリー、クリス(2015年11月12日)。「インフラストラクチャのバージョン管理」DevOps.com
  5. ^ フィリップス、アンドリュー(2015年5月14日)。「インフラストラクチャ自動化から真のDevOpsへの移行」DevOps.com
  6. ^ a b Schiemann、Wulf(2​​020年3月13日)。「コードとしてのインフラストラクチャのテスト(IaC):決定的なガイド2020」meshcloud.io/2020/03/13/testing-infrastructure-as-codemeshcloudGmbH 2021年10月1日取得
  7. ^ Nóva、Kris(2021年6月13日)。「ソフトウェアとしてのインフラストラクチャ」nivenly.comNivenly.com 2021年10月1日取得
  8. ^ 「構成管理のための宣言型v。命令型モデル:どちらが本当に優れているか?」Scriptrock.com 2015年12月14日取得
  9. ^ ロシュヴィッツ、マーティン(2014年11月14日)。「主要なオープンソース構成マネージャーの選択」管理ネットワークとセキュリティ米国カンザス州ローレンス:Linux New MediaUSALLC。
  10. ^ ベネチア、ポール(2013年11月21日)。「Puppetvs。Chefvs.Ansiblevs.Salt」networkworld.comネットワークワールド2015年12月14日取得
  11. ^ Garner Market Trends:DevOps –市場ではなく、継続的デリバリーのバリューチェーンをサポートするツール中心の哲学(レポート)。ガートナー。2015年2月18日。
  12. ^ a b Chaganti、Ravikanth(2016年1月5日)。「DevOps、コードとしてのインフラストラクチャ、およびPowerShell DSC:はじめに」PowerShellマガジンPowerShellマガジン2016年1月11日取得
  13. ^ https://aws.amazon.com/about-aws/whats-new/2011/02/25/introducing-aws-cloudformation/
  14. ^ チョウザメ、フィル(2012年10月28日)。「人形かシェフか?」
  15. ^ ラモス、マーティン(2015年11月4日)。「継続的インテグレーション:DevOpsのコードとしてのインフラストラクチャ」easydynamics.com2016年2月6日にオリジナルからアーカイブされました2016年1月29日取得
  16. ^ コードとしてのインフラストラクチャ:より高速なアプリケーション配信のための火を煽る(レポート)。フォレスター。2015年3月。
  17. ^ Wurster、Laurie F .; コルビル、ロニーJ .; 高さ、キャメロン; Tripathi、Somendra; ラストギ、アディティ。新たなテクノロジー分析:DevOpsはテクノロジーではなく文化の変化(レポート)。ガートナー。
  18. ^ 「クラウド脅威レポートは一貫したDevSecOpsの必要性を示しています」InformationWeek 2020年2月24日取得