💭

【Terraform vs Crossplane】各IaCツールのメリットとデメリットを比較してみた

2023/01/08に公開

Docker

内容

Crossplaneに入門したので、同じIaCツールの代表格Terraformとの違いをまとめます。(間違いがあったら指摘いただけると幸いです)

IaCツールとは

そもそも、TerraformやCrossplaneといったIaCツールとは何か？IaCツールを使うメリット・デメリットを以下の記事にまとめてあるので、IaCツールに対する理解があまりない方は先にご一読ください。

TerraformとCrossplaneの共通点

コードを使った宣言的構成管理
OSSである(強いコミュニティがある)

など、IaCツールとして重要なポイントは共通しています。そのため、

レビューを通したリリースサイクルの構築
常に新しい機能がリリースされ続ける
複数環境を簡単に作成・管理できる

といったIaCツールの特徴は両者とも兼ね備えています。

TerraformとCrossplaneの相違点

TerraformとCrossplaneでは動作方法が異なることを始め、様々な点で相違点があります。

動作方式の違い

まず、 CLIツールとして動作するTerraform と Control Planeとして動作するCrossplane という点で両者は大きく異なります。

Control Planeとして動作するCrossplaneは、EC2やVMインスタンスなどのリソースの変更を自動で検知して自動でコードと同じ状態に戻してくれます。つまり、誰かが間違えてAWSのコントロールパネルから操作をしてしまった場合、Crossplaneは自動でその変更を検知し、ソースで管理している状態と同じ状態に引き戻してくれます。git上で管理しているソースを常に正として、インフラリソースに変更があった場合は、強制的にソースと同じ状態に引き戻します。(GitOps的アプローチ)　

上記のようなGitOps的アプローチが可能なCrossplaneの方が便利に感じますが、常に変更を検知し続けないといけないため、クラスター上でCrossplaneを常に稼働させておかなければなりません。一方、TerraformはCLIツールとして動作するため、Terraformが常に稼働しているサーバーを用意する必要はありません。

リソースの管理方法について(stateファイル)

Terraformはstateファイルにて各リソース(AWSのEC2やセキュリティグループなど)の依存関係を管理するため、誰かが変更を加えるたびにstateファイルがロックされます。そして、ロックされている間は他のエンジニアはリリースができないため、大規模サービスを運用する場合、開発速度に影響が出る可能性があります。

一方Crossplaneは各リソースを単体で管理し、リソース間の依存関係をそこまで重視しません。そのため、各エンジニアが自律的にリリースを行うことが可能です。

stateファイルがあることによるメリットとデメリット

stateファイルでステートフルに状態管理をするTerraformは、変更差分をstateファイルにimportしたり、version upの際にstateファイルも変更が必要になる等、ステートフルゆえのつらさがあります。しかし、stateファイルがあるおかげ、実際のリソースとソースコードのdiffを検証したり、これから反映するソースコードがどのようにリソースに変更を与えるかを事前に検証できるというメリットもあります。

Crossplaneは現状、terraform planのような便利な差分検知機能がないので、リリースする際の安心感ではTerraformの方が優れている印象です。

記述方法の違い

Kubernetes上で、ControlPlaneとして動作するCrossplaneは、yamlファイルにて構成管理を行います。そのため、Platformエンジニアではないアプリケーションエンジニアでも構成管理ファイルを読み書きできるというメリットがあります。(個人的にCrossplaneのyamlファイルは読みやすいとは思いませんが...笑)

一方、Terraformは独自の構文にそった記述方法が必要になり、 dynamic や count をはじめとした、少しクセのあるTerraform構文(HCL)を覚えなければなりません。そのため、Terraformは学習コストという面でデメリットがあります。

Platformチームが抽象化されたコンポーネントを作成し、各サービスのアプリケーションエンジニアチームがそのコンポーネントを呼び出すことで、自律的にインフラリソースを作成するといったスピード感のある開発組織を作る際に、Hashicorpの独自構文(HCL)を使うTerraformよりもエンジニアなら誰しも見覚えがあるyamlファイルを使うCrossplaneの方が有利に働くでしょう。

CrossplaneでVPCを作る記述

apiVersion: ec2.aws.crossplane.io/v1beta1
kind: VPC
metadata:
  name: main
spec:
  forProvider:
    cidrBlock: 10.0.0.0/16
    enableDnsSupport: true
    enableDnsHostNames: false

TerraformでVPCを作る記述

resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true
  enable_dns_support   = false
}

アクセスコントロール

Terraformと比べるとCrossplaneは細かなアクセスコントロールが可能です。CrossplaneはKubernetes上で動作し、KubernetesのAPIとしてXR(Terraformのmoduleみたいなもの)を作成するため、チームAはS3バケットの作成・更新・閲覧・削除のみが可能なRBACを付与する、チームBはEC2の作成・削除のみ可能なRBACを付与するといった細かなアクセスコントロールが可能です。

情報量

Terraformに比べるとCrossplaneの情報は圧倒的に少なく感じます。
特に日本語の情報に関しては、Crossplaneは絶望的に少ないです。そのため、Crossplaneをproduction環境で使う場合は、英語の情報に対する抵抗感がなく、Crossplane自体のソースを読めないと危険な気がしています。(現状では、Terraformを選んだ方がリスクは少ないと思います。)

まとめ

個人的には、 CLIツールを利用してモノリスにインフラを管理しようとするTerraform と ControlplaneとしてGitOpsアプローチを適用しながらマイクロサービス的にインフラを管理しようとするCrossplane という点が両者の大きな違いだと思っています。

CrossplaneもTerraformもそれぞれ強力なツールです。自分達が運用するサービスのスケール・特徴を鑑みて、最適なツール選定をすることが重要でしょう。

note

勉強法やキャリア構築法など、エンジニアに役立つ記事をnoteで配信しています。

https://note.com/ring_belle/membership