コードとしてのインフラストラクチャとは何ですか? IT チームにとってのメリット、ツール、ベスト プラクティス

Accelerate State of DevOps 2019 レポート調査によると、回答者の 80% が、サポートしている主なアプリケーションまたはサービスは、ある種のクラウド プラットフォームでホストされていると回答しました。回答者の 50% は、主要なアプリケーションがパブリック クラウドでホストされていると回答しました。

コードとしてのインフラストラクチャを選択する理由

従来、サーバーが必要になったときを振り返ると、チケットを発行し、運用チームの誰かが VM インスタンスを作成するか、物理サーバーを注文していました。これには、スクリプト、ポイント アンド クリック、または手動インストールを使用する可能性があります。

そして、リクエストが発生するたびに、DNS、メール、データベースなどの VM が増加します。そして、オペレーティング システム、Web サーバー、JVM、その他すべてに対する継続的なアップデートがありました。時間の経過とともに、それらのサーバーの構成は互いにわずかに異なり (構成のドリフト)、結果としてスノーフレーク サーバーが生成されました。そして、何かが壊れたとき、どのような変更が加えられたかを追跡するのは困難でした。

サーバーの数が少なく、存続期間が長い限り、これはまだ許容可能でした。

AWSのようなクラウドサービス企業の登場で大きな変化が起きた。多くの企業は、ハードウェアやデータセンターに投資する代わりに、アプリケーションをクラウドに移行し始めました。また、クラウドでは、以前は数時間、場合によっては数日かかっていたサーバーのデプロイが数分で可能になります。

最適なパフォーマンスと可用性を維持するには、需要を満たすためにより多くのインスタンスをデプロイする必要がある場合があります。そして、後でコストを節約するためにそれらを終了しなければならない場合があります。時間単位で支払うため、毎日スケールアップまたはスケールダウンする必要がある場合があります。これを 1 日に何度も手動で行うのは明らかに困難です。

インスタンスやその他のインフラストラクチャ コンポーネントのデプロイまたは終了に必要な手順をコードで取得することで、自動化が可能になります。クラウドとインフラストラクチャのプロビジョニングの自動化は、より迅速かつ確実に価値を提供するのに役立ちます。

コードとしてのインフラストラクチャとは何ですか?

Infrastructure as Code (IaC) は、ソフトウェア開発の原則と実践を使用したインフラストラクチャの自動化です。

その考え方は、インフラストラクチャをソフトウェアのように扱い、コードを作成、テスト、実行して、インフラストラクチャを定義、展開、更新、破棄するというものです。サーバー、データベース、ネットワーク、ログ、アプリケーションの展開と構成を管理するコードを作成します。インフラストラクチャに変更を加える場合は、コードを変更してテストし、それをシステムに適用します。

利点

コードとしてのインフラストラクチャには、手動プロビジョニングに比べて大きな利点があります。

セルフサービス

インフラストラクチャはコードとして定義されるため、プロセス全体とデプロイメントは自動化でき、DevOps チームの誰でも開始できます。インフラストラクチャのユーザーは、必要なときに必要なリソースを入手できます。

べき等性

べき等であるということは、望ましい状態を定義することを意味し、スクリプトを何回実行しても、結果は同じになります。現在の状態と望ましい状態をチェックし、必要な変更のみを適用します。これを bash スクリプトで実現するのは非常に困難です。

Ansible や Terraform など のツールには、コードをべき等にする機能が組み込まれています。

コストの削減

プロビジョニングに必要な時間と労力が、手動プロビジョニングよりも大幅に削減されます。

より迅速なソフトウェア配信

開発、テスト、実稼働用のインフラストラクチャを迅速にプロビジョニングできるため、ソフトウェアをより迅速に提供できるようになります。導入プロセスは自動化されているため、一貫性があり、再現可能です。

自己文書化

インフラストラクチャの状態は、誰でも簡単に読み取れるコードで定義されます。

バージョン管理

従来、実稼働システムへの変更はリスクがあると考えられてきました。しかし、変化は避けられません。新しい機能を追加するときに、新しいデータベースの追加が必要になる場合があります。新しいサーバーまたはストレージをクラスターに追加する必要がある場合があります。コードとしてのインフラストラクチャは、インフラストラクチャに変更を加える労力とリスクを軽減します。

バージョン管理でソース ファイルをチェックインできるため、インフラストラクチャに加えられたすべての変更を追跡し、何か問題が発生した場合はすぐに前のバージョンに戻すことができます。

検証とテスト

コードとしてのインフラストラクチャを使用すると、小さな変更を継続的にテストして適用できます。すべてがコードであるため、静的解析と自動テストを使用してエラーをチェックできます。

セキュリティの向上

コードとしてのインフラストラクチャへの移行により、最初からセキュリティを組み込むことができ、変更を確実かつ安全に適用できるようになります。

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

多くのツールが利用可能ですが、使用するツールを選択するのは簡単ではない場合があります。以下に参考になる考慮事項をいくつか示します。

構成管理ツールとプロビジョニング ツールの比較

利用可能なツールは大きく 2 つのカテゴリに分類されます。

• 構成管理ツール。
• プロビジョニングツール

構成管理ツール

構成管理ツールは、ユーザーを管理し、既存のサーバーにソフトウェアとツールをインストールして管理するように設計されています。 Chef、Puppet、Ansible、SaltStack はすべて主に構成ツールです。

構成管理ツールを使用して、サーバーにソフトウェアをインストールおよび更新できます。

プロビジョニングツール

一方、Terraform、 CloudFormation 、OpenStack Heat はプロビジョニング ツールであり、サーバー、データベース サーバー、ロード バランサー、キュー、サブネット、ファイアウォール、およびインフラストラクチャのその他すべてのコンポーネントを作成するために使用されます。これらのツールは、プロバイダーに対して API 呼び出しを行って、必要なインフラストラクチャを作成します。

変更可能なインフラストラクチャと不変のインフラストラクチャ

可変インフラストラクチャは、プロビジョニング後に変更できるインフラストラクチャです。 Chef、Ansible、Puppet、SaltStack は、既存のサーバーにソフトウェアをインストールまたは更新するように設計されています。これはサーバーの存続期間中に何度も発生する可能性があります。多くの更新を行った後、各サーバーは他のサーバーと若干異なる可能性があり、構成のドリフトにつながります。たとえば、テスト サーバーでは正常に機能する一部の変更が、運用サーバーでは機能しない可能性があります。

Terraform や CloudFormation など のツールは、毎回マシン イメージまたはコンテナ イメージから新しいサーバーを作成するように設計されています。サーバーを更新する必要がある場合は、新しいサーバーに置き換えます。新しいサーバーが起動したら、古いサーバーを終了できます。各展開では不変のイメージを使用してサーバーを作成するため、構成のドリフトを回避できます。ただし、これは少し遅くなる可能性があります。

命令型ツールと宣言型ツール

命令型ツールはスクリプト作成に似ています。望ましい状態に到達するために実行する手順をリストします。宣言型ツールを使用すると、最終状態を指定でき、ツールはその状態に到達するための手順を実行します。

Chef は主に命令型ツールですが、Ansible はハイブリッド アプローチを使用し、命令型と宣言型の両方の手法をサポートします。

Terraform、CloudFormation、Puppet、OpenStack Heat、および SaltStack はすべて、目的の最終状態を宣言する宣言ツール カテゴリに属します。

複数のツールを併用する

これらのツールはそれぞれ単独で使用できますが、一般的なアプローチはこれらを組み合わせて使用​​することです。たとえば、 Terraform を使用して VPC、サブネット、インターネット ゲートウェイ、ロード バランサー、VM を構築し、Ansible を使用してこれらのインスタンスにサービスを構成およびデプロイできます。

結論

コードとして定義されたインフラストラクチャには、手動プロビジョニングに比べて多くの利点があります。バージョン管理、テストが可能で、プロビジョニングとソフトウェア配信の高速化につながります。多くの組織は、インフラストラクチャの構築と管理に IaC アプローチをすでに採用し始めています。