「Infrastructure as Code」とは何ですか？

13

「インフラストラクチャとしてのインフラストラクチャ」というフレーズは、過去2週間でさまざまな文脈で何度も言及されています。Infrastructure as Codeを持つことは、実際的な意味で実際に何を意味しますか？

terminology infrastructure-as-code

11

TL; DR：コードとしてのインフラストラクチャは、環境を自動化してバックアップする方法です。理想的な場合、災害後、新しいリソースのプロビジョニング、コードリポジトリからの構成の復元、およびバックアップからのデータの復元により、インフラストラクチャを完全かつ自動的に復元できます。

概要

Infrastructure as Codeは、3つの主要な概念に依存しています。

自動化構成管理と呼ばれ、継続的なコンフィギュオートメーション教授によって開拓フィールド。マーク・バージェス
インフラストラクチャへの変更用のコードリポジトリ。変更は最初にコミットされ、文書化され、レビューされ、テストされ、自動化によって展開されます。
管理インフラストラクチャのプロビジョニング。サービスとしてのインフラストラクチャ（IaaS）。クラウドコンピューティング、プライベートクラウド、マネージドクラウド、またはマネージドデータセンターサービスのいずれか

オートメーション

構成管理は、第3世代のツールです。CFEngineをベースに、自動構成管理用の新しいツールセットが広く導入されています。アルファベット順に最も人気のあるのは、Ansible、CFEngine、Chef、Puppet、PowerShell DSC、およびSaltStackです。それぞれに、インフラストラクチャの状態を記述する言語、それらの変更を適用してツールを拡張する機能を提供するコードモジュール、サーバーでそれらを実行するエージェント、および情報の中央リポジトリがあります。

通常、プッシュまたはプルモードで動作し、中央の場所からサーバーに接続してリモートで変更を実行するか、各サーバーで実行して、中央の場所から状態に関する情報を取得します。仕方。

重要な概念は、システム管理者またはサイトの信頼性技術者のためである直接変更を加えないインフラストラクチャに、しかし、自動化は、変更を行うことができます。何も人間によって手動で行うには、いずれかの生鮮考慮しなければならないすぐに自動化するか、より厳格な形で戻って修正された整合性違反インフラを破壊をトリガーし、影響を受けるコンポーネントの再構築します。

コードリポジトリ

理想的にはソフトウェアを保持するリポジトリとは別のコードリポジトリを使用して、インフラストラクチャおよび関連する自動化に対するすべての変更を管理します。構成ファイルとテンプレート、レビュー対象の変更プロセスを説明するプレイブック（クックブック）、CM自動化ツールを拡張するコード、プロビジョニング構成、インフラストラクチャテストとアラート、ステージング/展開テスト、ドキュメント、マニュアル（まだ自動化されていない）プロセスの説明を保持する必要があります。

重要な概念は、変更についてピアレビューを実施し、すべての変更を記録し、予測できない問題やテストされていない問題が発生した場合に自動的に以前の状態に戻す機能、ステージング環境に展開して構成の変更をテストし、自動的に展開する機能を備えていることですヒューマンエラーによる変動のない変更。

マネージドインフラストラクチャ

物理インフラストラクチャの管理は、ソフトウェアを超える現実世界のタスクであり、非常に異なるスキルセットが必要です。クラウドコンピューティングまたはマネージドデータセンターを通じてこのレイヤーを抽象化できることにより、ビジネス価値を高めるインフラストラクチャの管理にチームを集中させることができます。

クラウドコンピューティングは、後の段階で迅速に開始および拡張する方法を提供しますが、企業は多くの場合、ハイブリッドモデル用に自社のデータセンター内のインフラストラクチャの一部を移動することで、いくつかの利点と大幅な節約を実現します。ハードウェアを所有またはレンタルしているからといって、それを扱う人を雇わなければならないわけではありません。この規模では、世界中に地理的に分散したデータセンターが必要であり、すべての場所で必要なスキルをすべて備えた人材を確保するには非常に費用がかかります。それらを世界中に飛ばすと、すべての変更に高いレイテンシーが追加され、運用上の非効率性が増加します。これは、データセンター管理をアウトソーシングするもう1つの理由です。

重要なポイントは、マネージド物理インフラストラクチャが概念を忘れたり見落とされたりすることが多いことですが、それと同じくらい重要です。すべてを自動化したとしても、すべての構成はバックアップされたコードリポジトリに保存されますが、迅速にプロビジョニングする方法がない限り、巨大なボトルネックがあり、他の2つのステップで得られたすべての利点を簡単に消去できます。

— ジリ・クロダ
ソース

5

それが正確に何であるかを説明する前に、ウィキペディアから直接、本当に素晴らしい定義を引用させてください：

Infrastructure as Code（IaC）は、物理的なハードウェア構成やインタラクティブな構成の使用ではなく、コンピューターインフラストラクチャ（プロセス、ベアメタルサーバー、仮想サーバーなど）とその構成を管理およびプロビジョニングするプロセスです。ツール。

さて、コンセプトをよりよく理解するために、そのようなIaCツールであるTerraformを見てみましょう：https : //www.terraform.io/

また、これはTerraformがそれ自体について言っていることです：

Terraformを使用すると、生産インフラストラクチャを安全かつ予測どおりに作成、変更、改善できます。これは、APIを宣言的な構成ファイルに体系化するオープンソースツールであり、チームメンバー間で共有し、コードとして扱い、編集、レビュー、およびバージョン管理することができます。

つまり、インフラ全体をコーディングできます。これには、サーバーインスタンス、ロードバランサーなどのクラウド（/ infra）リソースの作成と、コードとしての完全な構成（基本設定の調整、セキュリティ設定、リージョンなど）の作成が含まれます。もちろん、レビュー可能です。

これは、AWSリソースをプロビジョニングするためのTerraformコードのサンプル例です。

resource "aws_elb" "frontend" {
  name = "frontend-load-balancer"
  listener {
    instance_port     = 8000
    instance_protocol = "http"
    lb_port           = 80
    lb_protocol       = "http"
  }

  instances = ["${aws_instance.app.*.id}"]
}

resource "aws_instance" "app" {
  count = 5

  ami           = "ami-408c7f28"
  instance_type = "t1.micro"
}

ボーナスPS：また、プロビジョニングツールとオーケストレーションツールの違いを理解する必要があります。開発者は、一方を他方と混同することが非常に多いため、使用目的ではないツールを微調整して使用しようとするミスを犯しがちです。

— Dawny33
ソース