Control-M + Terraform

あなたのTerraformワークフローは、ワークスペースの実行が開始される前に始まります — 何か上流で壊れると失敗する可能性があります。AWS S3の展開アーティファクトが到着しない。インフラストラクチャの変更ウィンドウの後にGitHub Actionsビルドが完了します。Control-Mは、アーティファクトの到着、アプリケーションのビルド、Terraformの実行、下流の展開の完全なチェーンを調整します。

あなたのパイプラインのように見る統合の事実を見る

一般的なワークフローの問題

これがあなたの週のように聞こえますか？

これはエッジケースではありません。これは、複数のツールでTerraformワークフローを実行しているチームの通常の運用条件です。Control-Mがそれぞれをどのように処理するかを見てみましょう。

上流障害

アプリケーションビルドが失敗しました。Terraformは午前2時にまだスケジュールされています。

Control-MはビルドとTerraformの実行を依存ジョブとしてモデル化します。したがって、失敗した前提条件はワークスペースの立ち上げを妨げます。インフラストラクチャの変更は、切断されたスケジュールが実行する時期を示しているため、必要なアプリケーション状態を待ちます。

実行失敗

Terraformの実行が失敗しました。3つの下流デプロイメントジョブがまだ待機しています。

Control-MはTerraformワークスペースの実行（プランと適用）をトリガーし、その完了ステータスに基づいて依存ジョブをゲートします。失敗したインフラストラクチャの実行は下流チェーンを停止させ、アプリケーションデプロイメントを不完全なインフラに対して継続させるのではなく、失敗を含めます。

同時変更

2つのプロダクション変更が準備完了です。環境に触れるべきは1つだけです。

Control-Mのリソースプールとロックリソースは、Terraformジョブの周りにオーケストレーションコントロールを追加し、ワークフローが共有環境やリソースを競う際に実行を調整します。チームは重要な変更を直列化し、独立してスケジュールされたプロダクションワークフロー間の衝突を減らすことができます。

SLAリスク

インフラストラクチャの実行が遅れています。あなたの午前6時のリリースはそれに依存しています。

Control-Mは、TerraformサービスにSLA管理を添付し、ワークスペースの実行をより大きなワークフロー内で追跡できます。運用チームはビジネスサービスのコンテキストでインフラストラクチャの遅延を確認し、遅れたTerraformの実行が納品の約束を逃す前に介入できます。

手動ハンドオフ

Terraformが成功裏に終了しました。誰かがアプリケーションのデプロイメントを開始する必要があります。

Control-Mは、Terraformジョブを他のControl-Mジョブと1つのスケジューリング環境に統合します。ワークスペースの成功した完了は、下流の依存関係を自動的に満たすことができ、インフラストラクチャのプロビジョニング、構成、デプロイメント、検証、および他のプロダクションワークフローの段階間の手動ハンドオフを排除します。

統合の事実