1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@s_tsuchida(Shoichi Tsuchida)

Terraform vs Pulumi vs Crossplane：現代のInfrastructure as Codeを支える3大ツールを徹底比較

Posted at

背景

クラウドインフラ／DevOps／プラットフォームエンジニアリングの潮流の中で、インフラをコードで管理する「Infrastructure as Code（IaC）」の重要性はますます高まっています。
本記事では、主要なIaCツールである Terraform、Pulumi、Crossplane を比較し、「どの場面でどれを選ぶべきか」を整理します。

この 記事を読むことで、以下が理解できることを期待しています：

  • 3大ツールの特徴を整理し、得意／不得意領域を把握できる
  • 自己のチーム・環境に即したツール選定の視点を得られる
  • “選定時に押さえておきたいポイント”が理解できる

各ツールの概要と特徴

Terraform

  • 概要：HashiCorp 社が開発した IaC ツール。宣言的にインフラ（クラウド／オンプレ／サービス）を記述し、状態（state）を管理して構築・変更を実現します。
  • 言語：HCL (HashiCorp Configuration Language) または JSON。
  • 強み：
    • 圧倒的なプロバイダ（provider）エコシステムを持つ（AWS, Azure, GCP, 各種 SaaS など多数）
    • マルチクラウド対応／既存インフラ移行の選択肢として実績がある
    • 宣言型構成のため、比較的学習コストが抑えられる（特にインフラ寄りのエンジニアには馴染みやすい）
  • 弱み・注意点：
    • 動的ロジック（ループや条件分岐、プログラム的生成）を扱う際には限界・工夫が必要
    • “継続的リコンシリエーション（状態の自動修復）”という観点では Kubernetes ネイティブな仕組みほどではない
    • 2023年8月、HashiCorpはTerraformを含むすべての製品を「Business Source License（BSL）」へ移行することを発表しました（公式発表）。
      このライセンスでは、商業的な利用の判定が「本番使用（production use）」という用語で定義されており、
      「この用語の定義が明確でないために正確な基準がどこにあるかはライセンサー側しか判断できない構造になっている」
      という指摘があります（出典：shujisado.com）。
      筆者の所属する組織でもこの部分が議論となり、
      「ライセンサー側しか判断できないリスクがあるのであれば使うのをやめておこう」
      という結論に至り、結果的に一時的に AWS CloudFormation の利用へ切り替える判断をしました。

Pulumi

  • 概要：Pulumi Corporation が開発・提供している IaC ツール。一般的なプログラミング言語（TypeScript／Python／Go／C#など）を用いてインフラをコード化できます。
  • 言語：上述のように多言語対応。
  • 強み：
    • ソフトウェア開発者としてのスキルセット（IDE, テスト, パッケージ管理など）を活かしやすい
    • ループ・条件・関数といったプログラミング構造を活用でき、抽象化や再利用がしやすい
    • アプリケーションコードと同じ言語の延長でインフラコードを書くという体験が好きなチームには親和性が高い
  • 弱み・注意点：
    • プログラミングできる分、構造が複雑化しやすく、明確なパターン設計やガバナンスが必要
    • Terraform に比べるとプロバイダ数・コミュニティの成熟度はまだ発展途上の部分もある

Crossplane

  • 概要：Kubernetes ネイティブな制御ループ（コントローラ／CRD）を活用して、クラウドリソースを Kubernetes のリソースとして扱えるようにする IaC／プラットフォームエンジニアリング向けツール。
  • 言語／構成：YAML（Kubernetes Manifest）＋CRD 定義。K8s を前提とした環境設計が必要です。
  • 強み：
    • Kubernetes クラスターをすでに運用している／運用予定の組織には、開発者向け “セルフサービス” プラットフォーム構築に強い
    • 継続的リコンシリエーション（“望ましい状態”を Kubernetes が常に監視・修復）というモデルが組み込みやすい
    • インフラとアプリケーションの境界が曖昧になる “Platform Engineering” の設計にマッチする
  • 弱み・注意点：
    • Kubernetes の運用・理解が前提となるため、純粋なインフラチームのみ・K8s未導入環境には導入ハードルが高い
    • ツールそのものの導入設計／CRD設計／運用ガバナンス設計という“次のレベル”の工程がある

ツール選定：どんな場面で使い分けるべきか

ツール 適したシーン 補足ポイント
Terraform マルチクラウド環境／既存インフラの IaC 化／CI／CD で標準化したい場合 状態管理／チーム分割／モジュール設計を早めに整備することが鍵。
Pulumi アプリ開発チームとインフラチームが近く、プログラマブルなインフラ設計を取り入れたい場合 “言語”を扱える分ガバナンスや可読性・保守性をきちんと考える必要があります。
Crossplane 既に Kubernetes を中心基盤とし、開発者にセルフサービスでインフラを提供したい場合 運用・設計のハードルが高めなので “K8s前提” でなければ導入検討を慎重に。

ライセンス変更とその影響（Terraform のケース）

  • Terraform を提供する HashiCorp 社は、2023 年 8 月 10 日付で「すべての製品を Business Source License (BSL) 1.1 へ移行する」と発表しました。
    → 公式発表（HashiCorp Newswire）

  • BSL は“ソース公開あり”の形態ですが、従来の OSS（MPL や Apache など）とは異なり、商用サービスとして利用する場合の制限が追加された「ソースアベイラブル」ライセンスです。

  • 特に以下の点が問題視されています。

    商業的な利用の判定は「本番使用」(production use)という用語で定義されており、この用語の定義が明確でないために正確な基準がどこにあるかはライセンサー側しか判断できない構造になっている。
    — 出典：Terraformのライセンス変更とBUSLとは（shujisado.com）

    筆者の組織でもこの点が大きな議論となり、
    「ライセンサー側しか判断できないリスクがあるのであれば、業務基盤として使うのは避けよう」
    という結論に至り、一時的に AWS CloudFormation への移行を決定しました。

この経験から、ツール選定時には「機能・導入容易性・チーム体制」だけでなく、
ライセンス・コミュニティ・開発ロードマップ・ベンダーロックインといった要素も評価軸に含めるべきではと思います。

比較まとめ（機能・運用観点）

観点 Terraform Pulumi Crossplane
コード記述方式 HCL／宣言型 プログラミング言語（TS／Python／Go等）／プログラマブル Kubernetes CRD／YAML＋コントローラ型
マルチクラウド対応 高い 高い 対応ありだが Kubernetes 前提
学習コスト 中 中〜高 高
運用モデル plan/apply 実行型 同様に実行型 継続的リコンシリエーション
開発者体験 安定的 柔軟で動的 自動化・セルフサービス志向
適用フェーズ 基盤構築 アプリ／動的インフラ Platform Engineering
注意点 ライセンス 設計複雑性 導入難度

コードスニペット比較

Terraform

provider "aws" {
  region = "ap-northeast-1"
}

resource "aws_s3_bucket" "example" {
  bucket = "my-unique-bucket-name"
  acl    = "private"
}

Pulumi (TypeScript)

import * as aws from "@pulumi/aws";

const bucket = new aws.s3.Bucket("example", {
  bucket: "my-unique-bucket-name",
  acl: "private",
});

Crossplane (YAML)

apiVersion: s3.aws.crossplane.io/v1alpha3
kind: Bucket
metadata:
  name: example
spec:
  forProvider:
    bucketName: my-unique-bucket-name
    acl: private
  providerConfigRef:
    name: aws-provider

まとめ

  • Terraform／Pulumi／Crossplane はそれぞれ異なる思想で設計されており、「万能ツール」は存在しません。
  • Terraform のライセンス変更を契機に、IaCツールを選定する際は技術面だけでなく、ライセンスや将来のリスクも重要な要素であることが浮き彫りになりました。
  • 結果として、チームのスキルセットや運用モデル、ライセンスポリシーに応じて適切なツールを選ぶことが不可欠です。
  • 今後は「Terraform で基盤構築」「Pulumi でアプリ寄りリソース」「Crossplane でセルフサービスレイヤーを実現」するような、Polyglot IaC 戦略が現実的な選択肢になるでしょう。

タグ候補：Terraform Pulumi Crossplane IaC PlatformEngineering

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?