Control-M + GCP仮想マシン

GCP仮想マシンのワークフローは、Compute Engine VMライフサイクル操作が実行される前に開始されます。上流で何かが壊れると失敗する可能性があります。Cloud Storageのデプロイメントアーティファクトが到着しません。Cloud Buildジョブが遅れて終了し、インフラストラクチャウィンドウを逃します。Control-Mは、Cloud Storageアーティファクトの到着、Cloud Buildイメージの作成、Compute Engine VMのプロビジョニング、デプロイメントの引き渡しのフルチェーンを調整します。

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

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

今週のあなたの状況に聞こえますか？

これらはエッジケースではありません。これらは、複数のツールでGCP VMワークフローを実行しているチームのための通常の運用条件です。Control-Mがそれぞれをどのように処理するかをご覧ください。

依存関係の失敗

Cloud Buildジョブが失敗しました。VMのスタートは発生してはいけません。

Control-Mは、GCP VM操作をリリースする前に上流ジョブの状態を評価し、依存するスタートが失敗したビルドの後に実行されないようにします。インフラストラクチャステップは、実際に安全に実行できるワークフローと調整されたままです。

状態確認

VMのスタートリクエストは成功しました。インスタンスはまだ準備ができていません。

Control-Mは、構成可能な検証間隔と許容範囲を使用してGCP VM操作をポーリングし、結果のジョブステータスを記録します。下流の作業は、インフラストラクチャが準備できていることを意味するAPIリクエストを仮定するのではなく、Control-Mのジョブ結果に依存できます。

艦隊操作

20のタグ付きVMが処理ウィンドウの前に開始する必要があります。

Control-Mはタグを使用してGCP VMを開始、停止、または再起動でき、1つのワークフローステップが複数の一致するインスタンスをターゲットにできます。プラットフォームチームは、各個別のVMの周りで別々のスケジューリングロジックを構築することなく、艦隊レベルのライフサイクルアクションを調整します。

SLAリスク

遅延したVM操作が06:00の処理SLAを危険にさらしています。

Control-MはGCP VMジョブをその上流および下流の作業と同じスケジューリング環境に持ち込み、チームにSLAジョブを添付させます。オペレーターは、ビジネスワークフローをサポートするコンテキストでインフラストラクチャ依存関係を見ることができます。

手動ライフサイクル

バッチが終了しました。誰かがCompute Engine VMを停止する必要があります。

Control-Mは、必要な処理が完了した後にトリガーされる下流のワークフローステップとしてGCP VMの停止操作を行うことができます。VMライフサイクル管理は、別のコンソールタスクや手動で維持されるスケジュールではなく、製造フローの一部となります。

統合事実