インフラストラクチャ・アズ・コード
コンテンツへジャンプ
フリー百科事典『ウィキペディア』より
( Infrastructure as Softwareからリダイレクト)
データセンター管理方法
「IaC」はここにリダイレクトされます。類似した名前のトピックについては、IAC（曖昧さ回避）を参照してください。

Infrastructure as code（IaC ）は、物理的なハードウェア構成や対話型の構成ツールではなく、機械が読み取り可能な定義ファイルを通じてコン​​ピュータデータセンターの リソースを管理およびプロビジョニングするプロセスです。 [ 1 ]このプロセスによって管理されるITインフラストラクチャは、ベアメタルサーバーなどの物理的な機器と仮想マシン、および関連する構成リソースの両方で構成されます 。定義は、手動プロセスを通じてコードを保守するのではなく、バージョン管理システムに格納される場合があります。定義ファイル内のコードでは、スクリプトまたは宣言型定義のいずれかを使用できますが、IaCでは宣言型のアプローチがより多く採用されています。

概要

[編集]

IaCは、ユーティリティコンピューティングや第二世代のウェブフレームワークがもたらす困難への対応として発展しました。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 [ 11 ]などのスタンドアロンのIaCフレームワークも使用しています。

継続的な構成自動化

[編集]

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

コミュニティコンテンツ

[編集]
参照:システム管理システムの一覧とオープンソース構成管理ソフトウェアの比較

コミュニティコンテンツは、オープンソースのCCAツールの品質を決定づける重要な要素です。ガートナー社が述べているように、CCAツールの価値は「自動化ツールの商業的成熟度とパフォーマンスだけでなく、ユーザーコミュニティが提供するコンテンツとサポートにも大きく依存します」。[ 3 ] PuppetやChefなどの大手ベンダーは独自のコミュニティを構築しています。ChefにはChef Community Repositoryがあり、PuppetにはPuppetForgeがあります。[ 12 ]他のベンダーは隣接するコミュニティを活用し、 PowerShell DSCなどの他のIaCフレームワークを活用しています。 [ 10 ]コンテンツ駆動型ではなく、製品にインテリジェンスを備えたモデル駆動型の新しいベンダーが登場しています。これらの視覚的なオブジェクト指向システムは開発者にとって有効ですが、特に、コンテンツのスクリプト作成よりもモデルを重視する本番環境指向のDevOpsおよび運用担当者にとって有用です。この分野が発展し、変化し続けるにつれて、IaC ツールがモデル駆動型かつオブジェクト指向でない限り、コミュニティ ベースのコンテンツは IaC ツールの使用方法においてこれまで以上に重要になります。

注目すべきCCAツール
道具 リリース元 方法 アプローチ 書かれた コメント
CFエンジン ノーザンテック（1993） 引く 宣言的 C —
人形 パペット（2005） 押すと引く 宣言文と命令文 C++およびClojure 4.0 以降、Ruby —
シェフ シェフ（2009） 引く 宣言文と命令文 ルビー —
ソルトスタック ソルトスタック（2011） 押すと引く 宣言文と命令文 パイソン —
アンシブル/アンシブルタワー レッドハット（2012） 押すと引く 宣言文と命令文 パイソン —
テラフォーム ハシコープ（2014） 押す 宣言文と命令文 行く —
カワウソ イネド（2015） 押す 宣言文と命令文 — Windows向け
プルミ プルミ（2018） 押す 宣言文と命令文 行く —
オープントーフ Linux Foundationと貢献者（2023） 押す 宣言文と命令文 行く Terraformフォーク

その他のツールには、AWS CloudFormation、cdist、StackStorm、Juju、Step CI などがあります。

人間関係

[編集]

DevOpsとの関係

[編集]

IaCは、 DevOpsにおけるベストプラクティスを実現するための重要な要素となり得る。開発者は構成の定義に深く関わるようになり、運用チームは開発プロセスの早い段階から関与するようになる。[ 13 ] IaCを活用するツールは、サーバーの状態と構成を可視化し、最終的には企業内のユーザーに可視性を提供することで、チームを結集し、その努力を最大限に引き出すことを目指している。[ 14 ]自動化は一般的に、手動プロセスの混乱やエラーが発生しやすい側面を取り除き、より効率的で生産性の高いものにすることを目的としています。柔軟性、ダウンタイムの削減、そして企業にとって全体的に費用対効果の高い方法で、より優れたソフトウェアとアプリケーションを作成できるようになります。IaCは、手動構成の効率を低下させる複雑さを軽減することを目的としています。自動化とコラボレーションはDevOpsの中心点と考えられており、インフラストラクチャ自動化ツールはDevOpsツールチェーンのコンポーネントとして組み込まれることが多い。[ 15 ]

セキュリティとの関係

[編集]

ユニット42（サイバーセキュリティプロバイダーであるパロアルトネットワークスの脅威インテリジェンス部門）が発表した2020年クラウド脅威レポートでは、コードテンプレートとしてのインフラストラクチャに約20万件の潜在的な脆弱性が特定されました。[ 16 ]

参照

[編集]

参考文献

[編集]
  1. ^ Wittig, Andreas; Wittig, Michael (2016). Amazon Web Services in Action . Manning Press. p. 93. ISBN 978-1-61729-288-0。
  2. ^ Bower, Joseph L.; Christensen, Clayton M.「破壊的技術：波に乗る」ハーバード・ビジネス・レビュー。
  3. ^ a b c Fletcher, Colin; Cosgrove, Terrence (2015年8月26日).継続的な構成自動化ツールに関するイノベーションの洞察. Gartner (レポート).[リンク切れ]
  4. ^ Riley, Chris (2015年11月12日). 「インフラストラクチャのバージョン管理」 . DevOps.com .
  5. ^ Phillips, Andrew (2015年5月14日). 「インフラストラクチャ自動化から真のDevOpsへの移行」 . DevOps.com .
  6. ^ 「構成管理における宣言型モデルと命令型モデル：どちらが優れているか？」Scriptrock.com。2015年3月31日時点のオリジナルよりアーカイブ。 2015年12月14日閲覧。
  7. ^ Loschwitz, Martin (2014年11月14日). 「主要なオープンソース構成マネージャの選択」 . Admin Network & Security . ローレンス、カンザス州、米国: Linux New Media USA LLC.
  8. ^ Venezia, Paul (2013年11月21日). 「Puppet vs. Chef vs. Ansible vs. Salt」 . Network World . Network World. 2018年7月18日時点のオリジナルよりアーカイブ。2015年12月14日閲覧。
  9. ^ Garner Market Trends: DevOps – 市場ではなく、継続的デリバリーバリューチェーンを支えるツール中心の哲学（レポート）. Gartner. 2015年2月18日.
  10. ^ a b Chaganti, Ravikanth (2016年1月5日). 「DevOps、Infrastructure as Code、PowerShell DSC: 入門」 . PowerShell Magazine . PowerShell Magazine . 2016年1月11日閲覧。
  11. ^ 「AWS CloudFormation の紹介」。
  12. ^ Sturgeon, Phil (2012年10月28日). “Puppet or Chef?” 2016年2月1日時点のオリジナルよりアーカイブ。 2016年1月29日閲覧。
  13. ^ Ramos, Martin (2015年11月4日). 「Continuous Integration: Infrastructure as Code in DevOps」 . easydynamics.com . 2016年2月6日時点のオリジナルよりアーカイブ。 2016年1月29日閲覧。
  14. ^ Infrastructure As Code：より高速なアプリケーション配信への推進力（レポート）。Forrester。2015年3月。
  15. ^ Wurster, Laurie F.; Colville, Ronni J.; Height, Cameron; Tripathi, Somendra; Rastogi, Aditi. 「新興技術分析：DevOpsは技術ではなく文化の転換（レポート）」Gartner.
  16. ^ 「クラウド脅威レポートは一貫したDevSecOpsの必要性を示している」 InformationWeek 、 2020年2月13日。 2020年2月24日閲覧。

「 https://en.wikipedia.org/w/index.php?title=Infrastructure_as_code&oldid=1326340538」より取得

インフラストラクチャ・アズ・コード

データセンター管理方法

Infrastructure as code（IaC ）は、物理的なハードウェア構成や対話型の構成ツールではなく、機械が読み取り可能な定義ファイルを通じてコン​​ピュータデータセンターの リソースを管理およびプロビジョニングするプロセスです。 [1]このプロセスによって管理されるITインフラストラクチャは、ベアメタルサーバーなどの物理的な機器と仮想マシン、および関連する構成リソースの両方で構成されます 。定義は、手動プロセスを通じてコードを保守するのではなく、バージョン管理システムに格納される場合があります。定義ファイル内のコードでは、スクリプトまたは宣言型定義のいずれかを使用できますが、IaCでは宣言型のアプローチがより多く採用されています。

概要

IaCは、ユーティリティコンピューティングや第二世代の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 [11]などのスタンドアロンのIaCフレームワークも利用しています。

継続的な構成自動化

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

コミュニティコンテンツ

コミュニティコンテンツは、オープンソースCCAツールの品質を決定づける重要な要素です。ガートナー社が述べているように、CCAツールの価値は「自動化ツールの商業的成熟度とパフォーマンスだけでなく、ユーザーコミュニティが提供するコンテンツとサポートにも大きく依存する」のです。[3] PuppetやChefといった大手ベンダーは独自のコミュニティを構築しています。ChefにはChef Community Repositoryがあり、PuppetにはPuppetForgeがあります。[12]他のベンダーは、隣接するコミュニティに依存し、 PowerShell DSCなどの他のIaCフレームワークを活用しています。 [10]コンテンツ駆動型ではなく、製品にインテリジェンスを備えたモデル駆動型でコンテンツを提供する新しいベンダーが登場しています。これらの視覚的なオブジェクト指向システムは開発者にとって効果的ですが、特に、コンテンツ作成においてスクリプトではなくモデルを重視する、本番環境志向のDevOpsや運用担当者にとって有用です。この分野が発展し変化していくにつれ、IaCツールがモデル駆動型かつオブジェクト指向でない限り、コミュニティベースのコンテンツはIaCツールの使用方法においてますます重要になるでしょう。

注目すべきCCAツール
道具 リリース元 方法 アプローチ 書かれた コメント
CFエンジン ノーザンテック（1993） 引く 宣言的 C —
人形 パペット（2005） 押すと引く 宣言文と命令文 C++およびClojure 4.0 以降、Ruby —
シェフ シェフ（2009） 引く 宣言文と命令文 ルビー —
ソルトスタック ソルトスタック（2011） 押すと引く 宣言文と命令文 パイソン —
アンシブル/アンシブルタワー レッドハット（2012） 押すと引く 宣言文と命令文 パイソン —
テラフォーム ハシコープ（2014） 押す 宣言文と命令文 行く —
カワウソ イネド（2015） 押す 宣言文と命令文 — Windows向け
プルミ プルミ（2018） 押す 宣言文と命令文 行く —
オープントーフ Linux Foundationと貢献者（2023） 押す 宣言文と命令文 行く Terraformフォーク

その他のツールには、AWS CloudFormation、cdist、StackStorm、Juju、Step CI などがあります。

人間関係

DevOpsとの関係

IaCは、 DevOpsのベストプラクティスを実現するための重要な要素となり得ます。開発者は構成の定義に深く関わるようになり、運用チームは開発プロセスの早い段階から関与するようになります。[13] IaCを活用するツールは、サーバーの状態と構成を可視化し、最終的には企業内のユーザーに可視性を提供することで、チームを結集し、その努力を最大限に活かすことを目的としています。[14]自動化は一般的に、手動プロセスの混乱やエラーが発生しやすい側面を取り除き、より効率的で生産性の高いものにすることを目的としています。柔軟性、ダウンタイムの削減、そして企業にとって全体的に費用対効果の高い方法で、より優れたソフトウェアとアプリケーションを作成できるようになります。IaCは、手動構成の効率を低下させる複雑さを軽減することを目的としています。自動化とコラボレーションはDevOpsの中心点と考えられており、インフラストラクチャ自動化ツールはDevOpsツールチェーンのコンポーネントとして組み込まれることがよくあります。[15]

セキュリティとの関係

ユニット42（サイバーセキュリティプロバイダーであるパロアルトネットワークスの脅威インテリジェンス部門）が発表した2020年クラウド脅威レポートでは、コードテンプレートとしてのインフラストラクチャに約20万件の潜在的な脆弱性が特定されました。[16]

参照

参考文献

  1. ^ Wittig, Andreas; Wittig, Michael (2016). Amazon Web Services in Action . Manning Press. p. 93. ISBN 978-1-61729-288-0。
  2. ^ Bower, Joseph L.; Christensen, Clayton M.「破壊的技術：波に乗る」ハーバード・ビジネス・レビュー。
  3. ^ abc Fletcher, Colin; Cosgrove, Terrence (2015年8月26日). 継続的な構成自動化ツールに関するイノベーションの洞察. Gartner (レポート).[リンク切れ]
  4. ^ Riley, Chris (2015年11月12日). 「インフラストラクチャのバージョン管理」. DevOps.com .
  5. ^ Phillips, Andrew (2015年5月14日). 「インフラストラクチャ自動化から真のDevOpsへの移行」. DevOps.com .
  6. ^ 「構成管理における宣言型モデルと命令型モデル：どちらが優れているのか？」Scriptrock.com。2015年3月31日時点のオリジナルよりアーカイブ。 2015年12月14日閲覧。
  7. ^ Loschwitz, Martin (2014年11月14日). 「主要なオープンソース構成マネージャの選択」. Admin Network & Security . ローレンス、カンザス州、米国: Linux New Media USA LLC.
  8. ^ Venezia, Paul (2013年11月21日). 「Puppet vs. Chef vs. Ansible vs. Salt」. Network World . Network World. 2018年7月18日時点のオリジナルよりアーカイブ。 2015年12月14日閲覧。
  9. ^ Garner Market Trends: DevOps – 市場ではなく、継続的デリバリーバリューチェーンを支えるツール中心の哲学（レポート）. Gartner. 2015年2月18日.
  10. ^ ab Chaganti, Ravikanth (2016年1月5日). 「DevOps、Infrastructure as Code、PowerShell DSC：入門」. PowerShell Magazine . PowerShell Magazine . 2016年1月11日閲覧。
  11. ^ 「AWS CloudFormation の紹介」。
  12. ^ Sturgeon, Phil (2012年10月28日). “Puppet or Chef?”. 2016年2月1日時点のオリジナルよりアーカイブ。 2016年1月29日閲覧。
  13. ^ Ramos, Martin (2015年11月4日). 「Continuous Integration: Infrastructure as Code in DevOps」. easydynamics.com . 2016年2月6日時点のオリジナルよりアーカイブ。 2016年1月29日閲覧。
  14. ^ Infrastructure As Code：より高速なアプリケーション配信への推進力（レポート）。Forrester。2015年3月。
  15. ^ Wurster, Laurie F.; Colville, Ronni J.; Height, Cameron; Tripathi, Somendra; Rastogi, Aditi. 「新興技術分析：DevOpsは技術ではなく文化の転換（レポート）」Gartner.
  16. ^ 「クラウド脅威レポートは一貫したDevSecOpsの必要性を示している」InformationWeek、2020年2月13日。 2020年2月24日閲覧。

Retrieved from "https://en.wikipedia.org/w/index.php?title=Infrastructure_as_code&oldid=1326340538"
Original text
Rate this translation
Your feedback will be used to help improve Google Translate