Ansible とTerraform の違いとは？

Red Hat® Ansible® Automation Platform と HashiCorp Terraform はどちらもオープンソースに基づく自動化製品であり、Infrastructure as Code (IaC) のアプローチで IT 環境を自動化します。 

組織にとってのこれらのソリューションの評価は、単純な比較ではありません 。自動化には絶対的に正しい方法があるわけではなく、唯一絶対のツールもありません。問題を解決するための方法が 1 つではないのと同じです。同じ業種であっても、ビジネスニーズの要件は組織によってまったく異なります。

自動化ソリューションについて調べていると、製品の主な違いや機能を表すのに多くの用語が使われているのに気づかれたことでしょう。それらのうちで特に一般的なもののいくつかを定義し、それらが互いにどのように関係しているか、また Ansible と Terraform とどのように関連しているかを見ていきましょう。

オーケストレーションとは、複数のワークフローを調整して実行することです。各ワークフローは 1 つ以上のタスクを実行します。これらのワークフローをオーケストレーションすることで、複雑なシステム、アプリケーション、サービスの設定と管理が自動化されます。この調整は通常、ポリシーで定義された事前に確立されたルールに従います。オーケストレーションでは、複数の自動化ソリューションを調整することもできます。そうして調整されたソリューションが自動化ワークフローを実行します。 

Ansible と Terraform は、特定のポリシーに従って複数の自動化ワークフローを順番に呼び出すことができるため、オーケストレーションを実行できます。Ansible には、Terraform を含む他の自動化ツールに接続して管理するためのモジュールが組み込まれています。その結果、Ansible をすべてのチームのトップレベルの共通言語として使用することで、IT 資産全体で自動化へのアプローチを標準化できます。 

プロビジョニングは、アプリケーションとサービスのための IT インフラストラクチャを作成してデプロイするプロセスです。 

Ansible と Terraform はどちらも、IT インフラストラクチャをプロビジョニング (およびプロビジョニング解除) できます。Ansible はアプリケーションとサービスをプロビジョニングすることもできます。

構成管理は、インフラストラクチャ、アプリケーション、サービスの構成を定義および保守するプロセスです。

他の多くの自動化ソリューションと同様、Ansible と Terraform はどちらも構成を定義し、さまざまなインフラストラクチャ・ターゲットに適用できます。ただし、構成管理に対するアプローチは異なります。Terraform は、宣言型プログラミングと呼ばれるアプローチを使用します。これは、望ましい状態を定義することによって IT インフラストラクチャの構成を保持しようとします。Ansible は手続き型 (または命令型) プログラミングのアプローチを使用します。望ましい状態に到達するための手順を定義することで、IT インフラストラクチャの設定を保持しようとします。これらについては後ほど詳しく説明します。 

Infrastructure as Code (IaC) のアプローチでは、手動のプロセスではなく自動的に実行されるコードを通じてインフラストラクチャを定義およびプロビジョニングします。IT インフラストラクチャをコードとして扱うことで、管理タスクを自動化し、ソフトウェア開発のベストプラクティスを活用して人的エラーを減らすことができます。 

Ansible と Terraform はどちらも IaC ツールですが、前述のように、各ソリューションで使用されるプログラミングは異なります。

宣言型プログラミングは、方法の詳細ではなく、プログラムの望ましい結果を記述するコードを作成する方法です。最終状態に到達するために必要な特定のコマンドや手順ではなく、最終状態に焦点を当てています。 

Terraform は、自動化言語として Hashicorp Configuration Language (HCL) を使用し、宣言型プログラミングのアプローチを採用しています。つまり、必要な構成変更を行うために Terraform が実行する必要がある一連のコマンドは、エンドユーザーには見えず、知ることもできません。 

手続き型 (または命令型) プログラミングは、タスクを完了するための命令のリスト (ステップバイステップガイド) をコンピュータに提供するコードを作成する方法です。最終状態ではなく、そこに至るプロセスに焦点を当てています。Ansible は自動化言語として、人間が判読可能なデータシリアル化言語 YAML を使用します。YAML 構文は手続き的な方法で解釈および実行されます。つまり、自動化ワークフローは記述された順序で実行されます。 

Ansible は宣言型と手続き型の両方に対応します。多くのモジュールは宣言型で動作しますが、手続き型プログラミングアプローチを使用するモジュールもあります。さらに、条件やループなど、Ansible 言語の一部の構成要素では、手続き型ロジックをユーザーが定義できます。この組み合わせにより、1 つのパラダイムに固執するのではなく、実行する必要があることに集中できる柔軟性が得られます。 

設定の不変性は、(インフラストラクチャまたはアプリケーションの) 設定を変更できないことを意味します。たとえば、アプリケーションの新しいバージョンをプロビジョニングするには、以前のバージョンを変更して更新するのではなく、削除して置き換える必要があります。リソースは自動的に破棄され、再作成されます。 

Terraform は不変インフラストラクチャのアプローチを使用しています。リソースをスピンアップし、テストしてから破棄するのが簡単であるため、ユーザーはすぐに使い始めることができます。ただし、インフラストラクチャの規模によっては、管理が複雑で困難になることがあります。Ansible は設定の可変性を想定して設計されていますが、一部の自動化ワークフローは不変性のアプローチを採用した設計にできます。

設定の可変性は、(インフラストラクチャまたはアプリケーションの) 設定を変更できることを意味します。たとえば、既存のリソースを削除または置き換えるのではなく、更新または変更することで、新しいバージョンのアプリケーションをプロビジョニングできます。 

Ansible は、設定の可変性を想定して設計されています。このアプローチの利点は、自動化ワークフローが理解しやすく、トラブルシューティングが容易であることです。ただし、特定のシナリオでは、正しい操作順序を知らない場合リソースのプロビジョニング解除が困難なことがあります。 

設定ドリフトは、手動の変更、未承認の変更、または監視されていない変更により、時間の経過とともにインフラストラクチャが変更され、それらの変更が体系的に記録または追跡されない状態のことを言います。多くの場合、そうした変更は緊急事態や過度の複雑さによるものであり、結果として従業員が確立されたプロセスに従わなくなる可能性があります。そのため、大規模な組織では構成ドリフトが珍しくありません。 

IaC アプローチはドリフトの管理に役立ちますが、その他の方策も取り入れることが不可欠です。Ansible では、ドリフトを検出する Ansible Playbook (自動化ワークフロー) を作成してドリフトへの対処に役立てることができます。ドリフト検出時には通知が適切な担当者に送信され、担当者は必要な変更を加えてシステムをベースラインに戻すことができます。 

Ansible は手続き型プログラミングのアプローチを使用しているため、開発者は自動化の設定がいつどこで変更されたかを把握しやすく、迅速に設定の問題の部分を分離してドリフトを修正できます。IT インフラストラクチャの複雑さによっては、宣言型プログラミング・アプローチを使用する自動化ソリューション (Terraform など) では構成の変更が極めて困難になる場合があります。そのため、Terraform のようなソリューションを使用して IT システム全体を包括的に再構成するよりも、Ansible を使用して単純な構成変更を行う方法が好まれることがあります。

この質問はおそらく、「自社の特定のユースケースにおいて、ビジネスに必要なものは何か」としたほうがよいでしょう。特定のビジネス課題と要件を評価し、最適なソリューションを選択する必要があります。一方のアプローチが適している問題もあれば、別のアプローチのほうがより効果的に解決できる問題もあります。また、ソリューションを組み合わせることが成功の鍵になることもあります。

Terraform と Ansible Automation Platform はどちらも一般的な自動化製品であり、人気の DevOps ツールですが、ソリューションの機能は大きく異なります。Terraform はパブリッククラウド・インフラストラクチャのプロビジョニングを専門としています。これは IT 自動化の世界における多くのユースケースの 1 つです。Ansible Automation Platform は幅広い自動化のユースケースに対応します。Ansible Automation Platform は自動化に対して単一のアプローチではなく、さまざまなアプローチを提供して多様な問題に対処します。また、お客様が遭遇した問題が 2 つの自動化ソリューションを組み合わせることで最も効果的に解決できる場合、Ansible Automation Platform は、Helm や Terraform だけでなく、Amazon Web Services (AWS) CloudFormation、Microsoft Azure Resource Manager、Google Cloud Platform (GCP) Cloud Deployment Manager など、主要なクラウドプロバイダーの他の製品と統合できます。

当社のお客様の多くは、同時に複数の自動化ソリューションを使用しています。たとえば、クラウドにアプリケーションをデプロイする場合、多くの場合、CloudFormation または Terraform を使用してクラウド・インフラストラクチャのプロビジョニングを開始し、Ansible Automation Platform を使用してアプリケーションとプロセスの継続的な設定を実行します。このプロセスの効率を高めるため、Red Hat では先頃 Red Hat Ansible Certified Content Collection for Terraform を発表しました。これは Red Hat がサポートするコレクションで、Terraform を Ansible Automation Platform 実行環境で使用して、IaC の管理とプロビジョニングを自動化します。

クラウドデプロイメントのユースケースだけでなく他のものも自動化したいという理由で、Ansible Automation Platform のみに投資するお客様もいます。たとえば、ルーターやスイッチの再設定などのネットワークプロセスとともに、脅威の調査やインシデント対応などのセキュリティプロセスを自動化したいと考えるお客様もいます。

このようなお客様は、投資収益率を最大化するために、すべてのユースケースで自動化へのアプローチを標準化したいと考えています。

エンタープライズ向け自動化製品にはさまざまなものがあるので、特長と能力を理解することが不可欠です。そして最も重要なのは、自社の特定のニーズに最適なものを選ぶことです。 
 
オープンソースを中核とする Red Hat Ansible Automation Platform は、組織にライフサイクル全体のサポートを提供する、強化されたテスト済みのサブスクリプション製品です。世界中の何千人ものコントリビューターの経験とインテリジェンスが活用されているコミュニティ版の Ansible を基盤として構築されています。Ansible Automation Platform は、組織による自動化ワークロードの作成、管理、スケーリングを支援するように設計されています。ハイブリッドクラウド、エッジロケーション、ネットワーク、セキュリティ、インフラストラクチャ、およびその他の多くのユースケースの自動化を含む、エンドツーエンドの自動化ソリューションをデプロイするための、柔軟で安定したセキュリティ重視の基盤を提供します。 

Terraform は、IaC アプローチによるクラウド・インフラストラクチャのプロビジョニングおよびプロビジョニング解除ツールとして優れています。特定の目的を持つ特定のツールです。Ansible は、多目的のクロスドメイン自動化ソリューションです。どちらも活発なオープンソース・コミュニティがあり、十分にサポートされたダウンストリームの商用製品を持っています。どちらのソリューションにもそれぞれの強みがあり、組み合わせると効果的に機能し、多くのビジネスで効率を生み出します。簡単に言えば、自動化ソリューションの選択は、必ずしも「いずれか一方」を選ぶことではありません。「どちらも選ぶ」が答えの場合も少なくないのです。