ホーム
Topics
Infrastructure as Code
Infrastructure as Code(IaC)は、高レベルの記述的なコーディング言語を用いて、ITインフラストラクチャーのプロビジョニングを自動化します。 この自動化により、開発者は、ソフトウェア・アプリケーションの開発、テスト、またはデプロイのたびに、サーバー、オペレーティング・システム、データベース接続、ストレージ、およびその他ののインフラストラクチャー要素を手動でプロビジョニングおよび管理する必要がなくなります。
企業にとって1日に何百ものアプリケーションを本番環境にデプロイすることが珍しくない時代に、開発者やユーザーの要求に応じて、インフラストラクチャーが常に立ち上げられ、削減され、さらには規模が拡大、縮小されたりする中、コストを管理し、リスクを低減し、新たなビジネスチャンスや競争上の脅威に迅速に対応するために、組織にとってインフラストラクチャーの自動化は不可欠です。 IaCはこの自動化を可能にします。
IaCはまた、競争力のあるペースのソフトウェア・デリバリー・ライフサイクルに欠かせない、DevOpsの必須の手法でもあります。 これにより、DevOpsチームは、ソースコードをバージョン管理するのと同様に、インフラストラクチャーを迅速に作成、バージョン管理、およびこれらのバージョンを追跡することができ、デプロイ時に深刻な問題を引き起こす可能性のあるIT環境間の不整合を回避することができます。
Sai Vennamが、以下の動画「Infrastructure as Codeとは」でIaCについて詳しく説明しています。
従来のITのプロビジョニングは、ハードウェアの物理的なセットアップ、オペレーティング・システム・ソフトウェアのインストールと構成、ミドルウェア、ネットワーク、ストレージなどへの接続などを専門の担当者が行う必要があり、時間とコストがかかるものでした。
仮想化とクラウド・ネイティブ開発は、物理的なハードウェア管理の問題を解消し、開発者が必要に応じて独自の仮想サーバーやコンテナをプロビジョニングすることを可能にします。 しかし、仮想化インフラのプロビジョニングは、開発者のコーディングへの集中力を削ぎ、新しいデプロイメントのたびにプロビジョニング作業を繰り返さなければならず、環境の変化を追跡し、デプロイメントに影響を与える不整合を防ぐ簡単な方法も提供されていません。
Infrastructure as Code(IaC)は、開発者がスクリプトを実行することで、完全に文書化され、バージョン管理されたインフラを効果的に「オーダー」できるようにする最終的なステップです。 そのメリットは、まさに想像通りです。
Infrastructure as Code(IaC)でインフラを自動化する際、またIaCソリューションを選択する際の重要な決断は、変更可能またはイミュータブルなインフラストラクチャーのどちらを構築するかということです。
ミュータブル・インフラストラクチャーは、最初にプロビジョニングされた後に、変更や更新が可能なインフラのことです。 ミュータブル・インフラストラクチャーでは、開発チームは、開発やアプリケーションの要件に合わせてサーバーを柔軟にカスタマイズしたり、緊急のセキュリティ問題に対応したりすることができます。 しかし、これはIaCの主な利点である、デプロイメント間またはバージョン内での一貫性を維持する能力を損なうものであり、インフラストラクチャーのバージョン追跡をより困難にする可能性があります。
このような理由から、ほとんどのIaCは、最初にプロビジョニングされた後は変更できないイミュータブル・インフラストラクチャーとして実装されています。 イミュータブル・インフラストラクチャーを変更する必要がある場合は、新しいインフラに交換しなければなりません。 特にIaCでは、クラウド上で新しいインフラストラクチャーをすぐに立ち上げることができるため、イミュータブル・インフラストラクチャーは思ったよりもずっと実現可能で実用的です。
イミュータブル・インフラストラクチャーは、IaCをさらに論理的に進化させ、IaCを強固にすることで、IaCがもたらすメリットをさらに確実なものにします。 これにより、構成のドリフトがほとんどなくなり、テスト環境とデプロイ環境の間で一貫性を保つことがより容易になります。 また、インフラストラクチャーのバージョンを維持および追跡することが容易になり、必要に応じて任意のバージョンに自信を持ってロールバックすることができます。
IaCソリューションを選択する際には、インフラストラクチャーの自動化に対する宣言型アプローチと命令型アプローチの違いを理解することも重要です。
多くの組織では、宣言型アプローチ(機能型アプローチとも呼ばれる)が最適です。 宣言型アプローチでは、プロビジョニングしたいインフラストラクチャーの最終的な状態を指定すると、あとはIaCソフトウェアが、仮想マシン(VM)やコンテナの立ち上げ、必要なソフトウェアのインストールと構成、システムやソフトウェアの相互依存性の解決、バージョン管理などを行います。 宣言型アプローチの最大の欠点は、設定と管理に熟練した管理者が必要で、これらの管理者は自分の好きなソリューションに特化していることが多いことです。
命令型アプローチ(手続き型アプローチとも呼ばれる)では、特定のステップごとにインフラストラクチャーのプロビジョニングを行う自動化スクリプトを作成することができます。 規模が大きくなると管理が大変になりますが、既存の管理スタッフにとっては理解しやすく、すでに導入している構成スクリプトを活用することができます。
宣言型アプローチと命令型アプローチの選択は、GPSを使うか、角ごとに曲がる方向の指示を受けるのか、に似ています。 GPSでは、住所を入力すると、あとはGPSが最速のルートや渋滞回避をしてくれますが、なぜそのような選択をしたのかは、専門家に聞いてみないとわかりません。 ターンバイターンの指示は個人的な経験に基づいています。提供者はルートとその選択理由を知っていますが、障害物に遭遇したり、ルートを最適化したい場合は、助けを求めるか、自分で作業をしなければなりません。
オープン・ソースのIaCツールは数多くありますが、最も一般的に採用されているツールはAnsibleとTerraformです。
Ansible (ibm.com外部へのリンク)は、Red Hatがスポンサーを務めるオープン・ソースのコミュニティー・プロジェクトで、プロビジョニング、構成管理、およびアプリケーションのデプロイメントを自動化することを目的としています。 宣言型の自動化ツールであるAnsibleは、「プレイブック」(構成言語YAMLで記述)を作成して、インフラストラクチャーの望ましい状態を指定し、プロビジョニングを行います。 Ansibleは、DockerコンテナやKubernetesのデプロイメントのプロビジョニングを自動化するための一般的な選択肢です。
Terraformは、宣言型のプロビジョニングおよびインフラストラクチャー・オーケストレーション・ツールで、エンジニアは企業のクラウドベースおよびオンプレミスのインフラストラクチャーのあらゆる側面のプロビジョニングを自動化することができます。
Terraformは主要なクラウド・プロバイダーに対応しており、物理的なサーバーやDNSサーバー、またはデータベースの設置場所に関わらず、複数のプロバイダーのリソースを並行して構築することを自動化できます。 また、あらゆる言語で書かれたアプリケーションを提供することができます。
Ansibleとは異なり、Terraformは構成管理機能を提供しませんが、構成管理ツール(Cloud Formationなど)と連携して、構成ファイルで記述された状態のインフラを自動的にプロビジョニングしたり、構成の変更に応じて必要に応じてプロビジョニングを自動的に変更したりします。
IaCツールの選択についてより深く知りたい方は、「Infrastructure as Code: Chef, Ansible, Puppet, or Terraform?」をご覧ください。
カスタマイズ可能で共有可能なテンプレートを備えたIBMのIaC機能は、クラウドへの移行がどこまで進んでいるかに関わらず、アプリケーションをモダナイゼーションするための基礎を築くことができます。
次のステップへ
IBM Cloudアカウントで今すぐ始めましょう。