ブログ

F5applicationサービスに Ansible または Terraform を選択する

ロリ・マクヴィッティ サムネイル
ロリ・マクヴィッティ
2019年9月30日公開

F5applicationサービスを展開および運用するには、いずれか 1 つ、または両方を選択します。

オープンソース運動は常に自由に焦点を当ててきました。 スキル、予算、アーキテクチャ、目標に応じて、最適なソリューションを自由に選択できます。 この原則は、デプロイメント パイプラインの繰り返し可能なインフラストラクチャを構築する上で、今日でも重要な要素であり続けています。

applicationサービスのプロビジョニングと操作を自動化するための優れたオプションは数多くあります。 最も人気のある選択肢の 2 つは、RedHat Ansible と HashiCorp Terraform です。 

ここで、F5 がAnsibleTerraform を完全にサポートしていることを述べておきます。 当社は相互運用性と統合性を確保するために両方と連携しているので、お客様はそうする必要はありません。 どのような選択をしても、私たちがあなたをサポートします。

しかし、顧客とのやり取りの中で、一部のタスクでは Ansible が優れているのに対し、他のタスクでは Terraform が優れていることに気づきました。 これは、パイプラインの自動化と維持には異なる一連のタスクが必要になるためです。

Terraform は、オーケストレーション、つまり環境の状態の管理に優れています。 つまり、Terraform は環境がどのように見えるか、どのように動作するかを理解しているということです。 何か問題があれば、Terraform はそれをレビューのためにフラグ付けできます。

Ansible は構成管理に優れています。 つまり、個々のコンポーネントの状態を維持することに重点が置かれています。 環境内の個々のコンポーネントに問題がある場合、Ansible は構成を調整して問題に対処できます。 

各ツールの重点が異なるため、デプロイメント ライフサイクルを自動化するためにこれらが一緒に使用されるのを見ても驚くことではありません。 

これら 2 つのツールが F5applicationサービスでどのように機能するかを確認するには、展開ライフサイクルの観点から共通の基盤を設定することをお勧めします。 

デプロイメントライフサイクル

applicationsのライフサイクルとそれに対応する配信パイプラインがあるのと同様に、applicationサービスにもライフサイクルとそれに対応するデプロイメント パイプラインがあります。 そのライフサイクルには複数のステップが必要です。

  1. 規定
    a. プロビジョニングとは、仮想マシンまたはコンテナ、パブリック クラウドまたはプライベート クラウドのいずれであっても、インスタンスを実際に起動するプロセスです。
  2. 機内で
    a. BIG-IP が導入されている環境で動作するために必要なネットワークをセットアップするには、オンボーディングが必要です。
  3. 展開する
    a. ライフサイクルのデプロイ フェーズでは、applicationサービスが定義、構成、起動されます。
  4. 操作する
    a. 継続的な運用には監視と分析が必要です。 F5 テレメトリ ストリーミングにより、BIG-IP はテレメトリ パイプラインにプラグインして、必要なメトリックとデータを共有できるようになります。
  5. 変化
    a. 変更は、既存の構成 (展開フェーズで最初に指定) を変更するプロセスです。

Ansible と Terraform はどちらも、5 つのフェーズすべてで主要な自動化プロバイダーとして機能します。 ただし、それぞれが異なるフェーズで優れているため、両方を使用する方が実際にはより良い戦略となる場合があります。 Ansible はデプロイと変更 (構成管理) フェーズで使用される可能性が高く、Terraform はプロビジョニングとオンボード (オーケストレーション) に使用される可能性が高くなります。

Ansible と Terraform の連携

また、多くのお客様が正当な理由からツールチェーンを標準化したいと考えていることもわかっています。 複数のツールに関する専門知識を維持することは困難ですが、複数のツールチェーンを実行するために必要なインフラストラクチャの運用と保守も困難です。 その場合、これらの優れたツールのどれを標準化するかを選択する方法があります。

  1. インフラストラクチャの変更は頻繁に行われない
    このシナリオでは、applicationサービスに変更を加えますが、必ずしもインフラストラクチャ (BIG-IP) に変更を加える必要はありません。 これは、既存の BIG-IP を利用して新しいapplicationsを展開する場合によく発生します。 Ansible は構成管理に優れているため、ここでは良い選択です。構成管理が主な目的です。 Ansible は幅広い言語と API スタイルをサポートしているため、DevOps チームと NetOps チームの両方がapplicationサービスに変更を加えるのに最適です。 Ansible を使用して、F5 Ansible モジュールまたは F5 AS3 経由で F5applicationサービスを構成できます。 または、特定のニーズに応じて両方を使用することもできます。 Ansible アプローチの選択方法について詳しくは、 Mani Gadde と Andrius Benokraitis による素晴らしいブログをご覧ください。
  2. インフラの頻繁な変更
    クラウド、特にパブリック クラウドは、applicationsとそのサポート インフラストラクチャの高速な変更を容易にするために選択されることがよくあります。 不変のインフラストラクチャは、多くの場合、このような状況での不安定性の管理、つまりインフラストラクチャ全体の解体と再展開に役立ちます。 Terraform は、インフラストラクチャ全体のプロビジョニングとオンボーディングを迅速に行うのに優れているため、このシナリオに最適です。 オーケストレーションを重視した設計は、特にクラウドのような不安定な環境において、一貫性があり、繰り返し可能なインフラストラクチャを大規模に作成するのに適しています。 
  3. インフラストラクチャとapplicationサービスの頻繁な変更
    Terraform + Ansible は、インフラストラクチャとapplicationサービスの両方にわたる高い変更率を管理するのに最適な組み合わせです。 環境や個々のコンポーネントの状態が頻繁に変更されることが予想されるため、applicationsとそれをサポートするapplicationサービスの可用性を維持するために、変更管理ツールとオーケストレーションツールの両方が必要になります。

Ansible、Terraform、またはその両方のいずれを選択する場合でも、F5 は、ネイティブ統合とパッケージ化されたテンプレート、そして両方に積極的に貢献し改良するコミュニティによってお客様の選択をサポートすることに尽力しています。