Terraformでベアメタルクラウドに物理サーバーをデプロイ – シームレスなIaC統合

Infrastructure as Code（IaC）は、仮想化クラウドリソースの管理プロセスを簡素化します。クラウドネイティブな専用サーバーの登場により、仮想マシンと同じ柔軟性で物理マシンをデプロイすることが可能になりました。

phoenixNAPのクラウドネイティブ専用サーバープラットフォーム「ベアメタルクラウド（BMC）」は、IaCとの互換性を重視して設計されています。BMCは、DevOpsで最も広く使用されているIaCツールの1つであるHashiCorp Terraformと完全に統合されています。この統合により、ユーザーはカスタム構築されたTerraformプロバイダーを活用し、わずか数行のコードで数分でBMCサーバーをデプロイできます。

なぜInfrastructure as Codeなのか

Infrastructure as Codeは、人間が読める設定ファイルを通じてクラウドリソースのデプロイと管理を自動化する手法です。スピードとアジリティが不可欠なDevOpsにおいて、極めて重要な役割を果たします。

IaC登場以前は、システム管理者がすべてを手作業でデプロイしていました。すべてのサーバー、データベース、ロードバランサー、ネットワークを手動で設定する必要がありました。現在では、さまざまなIaCエンジンを使用して、複数のプロバイダー間で数百台のサーバーを数分で起動・破棄できます。

市場には多くの強力なIaCツールが存在しますが、TerraformはIaC分野で最も著名なツールの1つとして際立っています。

Terraformの基本

HashiCorpのTerraformは、DevOpsチームがクラウドネイティブリソースを安全にデプロイ、変更、バージョン管理できるIaCエンジンです。オープンソースツールは無料で使用できますが、ほとんどのチームはコラボレーションとガバナンスを可能にするTerraform CloudやTerraform Enterpriseと共に使用しています。

Terraformでデプロイするには、開発者が目的のリソースをHashiCorp Configuration Language（HCL）で記述された設定ファイルに定義します。Terraformはそのファイルを分析して実行計画を作成し、ユーザーが確認したら計画を実行して設定ファイルで定義された通りにプロビジョニングします。

Terraformは、望ましい状態と既存のインフラストラクチャ状態の差分を特定します。このメカニズムは、複数の環境間での一貫性維持が重要なDevOpsパイプラインにおいて不可欠な役割を果たします。

Terraformでのベアメタルクラウドサーバーのデプロイ

Terraformは、そのソフトウェアをサポートするプロバイダーのリストを継続的に拡充しています。プロバイダーとは、ユーザーが設定ファイルで初期化する各サービスプロバイダーのカスタム構築プラグインです。

phoenixNAPは独自のTerraformプロバイダー「pnap」を提供しています。すべてのベアメタルクラウドユーザーは、Webベースのベアメタルクラウドポータルを使用せずに、このプロバイダーでBMCサーバーをデプロイおよび管理できます。phoenixNAPプロバイダーのソースコードとドキュメントは、公式Terraformプロバイダーページで公開されています。

ベアメタルクラウドでのTerraform使用例

TerraformでBMCサーバーのデプロイを開始するには、BMCアカウントを作成し、ローカルシステムまたはリモートサーバーにTerraformをインストールします。Terraformを実行する前に、必要な認証データを収集してconfig.yamlファイルに保存します。clientIdとclientSecretの両方が必要で、これらはBMCアカウントで確認できます。

セットアップが完了したら、目的のBMCリソースを定義します。Terraform設定ファイルを作成し、pnapプロバイダーを使用することを宣言します：

terraform {
  required_providers {
    pnap = {
      source  = "phoenixnap/pnap"
      version = "0.6.0"
    }
  }
}

provider "pnap" {
  # 設定オプション
}

configuration optionsのセクションには、BMCインフラストラクチャの望ましい状態の記述を含めます。

最も基本的なベアメタルクラウドサーバー構成s1.c1.smallを、PhoenixデータセンターでUbuntu OSと共にデプロイするには：

resource "pnap_server" "My-First-BMC-Server" {
  hostname = "your-hostname"
  os       = "ubuntu/bionic"
  type     = "s1.c1.small"
  location = "PHX"
  ssh_keys = ["ssh-rsa..."]
  # action = "powered-on"
}

引数名actionは、サーバーで実行可能な電源アクション（reboot、reset、powered-on、powered-off、shutdown）を表します。すべての引数名に対応する値が必要ですが、action引数は定義不要です。

このベアメタルクラウドインスタンスをデプロイするには、TerraformのinitCLIコマンドを実行して初期化プロセスを開始します。

Terraform設定ファイルは.tf拡張子で保存します。Terraformは独自のドメイン固有言語を使用しますが、JSONで設定ファイルを記述することも可能です。その場合、拡張子は.tf.jsonになります。

すべてのTerraform設定ファイルは再利用可能で、拡張性があり、チームでのBMCプロビジョニングスキームの共同作業を容易にするためバージョン管理できます。

1台でも数百台でも、TerraformとBMCならデプロイ可能です。設定ファイルで定義できるサーバー数に制限はありません。他のプロバイダーと併用することもできます。

複雑なセットアップをより簡単に管理するため、Terraformにはモジュールという機能があります。これは環境のアーキテクチャを抽象的に定義するコンテナで、1つ以上のインフラストラクチャオブジェクトを含む他のモジュールを呼び出す、再利用可能なコードの塊です。

Terraform CloudでのBMC設定の共同作業

Terraform設定の記述とプロビジョニングの方法を習得したら、DevOpsチーム全体が新規BMCリソースのデプロイや既存リソースの変更により効率的に取り組める方法を構築したくなるでしょう。

Terraform設定をバージョン管理システムに保存し、Terraform Cloudから無料でリモート実行できます。これにより、誤った設定のリソースをデプロイするリスクを低減し、監視を改善し、すべての変更をクラウドから確実に実行できます。

また、Terraform Cloudのリモートステートストレージを活用できます。Terraformステートファイルは、Terraform設定と現実世界にデプロイされたリソースをマッピングします。ステートファイルをTerraform Cloudで保存することで、チームが常に同じ状態を共有できます。

Terraformのもう一つの大きな利点は、すべての設定ファイルが再利用可能であることです。これにより、同じ環境を複数回複製することが非常に容易になります。複数の環境間で一貫性を維持することで、チームはより速く、より安全に本番環境へ品質の高いコードを提供できます。

インフラストラクチャを自動化

この記事では、Terraformの柔軟性を活用してベアメタルクラウドリソースをプログラムで操作する方法の概要を説明しました。phoenixNAP TerraformプロバイダーとTerraform Cloudを使用することで、わずか数行のコードで複数のBMCインスタンスを素早くデプロイ、設定、廃棄できます。

このインフラストラクチャプロビジョニングへの自動化アプローチは、DevOpsワークフローのスピードとアジリティを向上させます。BMCとTerraform Cloudの組み合わせにより、チームは専用サーバーが手動でプロビジョニングされるのを待つ時間を無駄にすることなく、ソフトウェア構築に集中できます。