Google Cloud ノード
Google Cloud ノードを使用すると、フローから直接 Google Cloud サービスと連携できます。これを使用してデータを取得したり、リソースを作成・変更したり、Google Cloud サービス全体でアクションを実行できます。あるノードの出力は次のノードの入力となるため、一連のアクションとオペレーションを定義できます。
アクションを見つける
フローに Google Cloud ノードを追加する際は、プロバイダとして Google Cloud を選択し、その後 Google Cloud サービス内を検索またはブラウズしてアクションを見つけます。さらに、テンプレートノードを使用すると、あらかじめ構成されたアクションのグループを現在のフローに追加できます。

アクションを設定する
アクションノードを選択すると、設定用の 3 つのタブを持つサイドパネルが開きます。

-
Parameters: このタブでは、選択したサービスとアクション、およびそれらを変更するオプションが表示されます。このタブで承認設定も構成します。利用可能なパラメータはサービスとアクションによって異なります。フィールドタイプや、前のノードから値(リスト全体やマップを含む)を参照する方法については、ノードパラメータを参照してください。
-
Permissions: このタブでは、アクションを実行するために必要な権限を保持しているかどうかを確認でき、権限が不足している場合の手順を提供します。あわせて APIs in CloudFlow も参照してください。
レスポンスフィールドをフィルタリングする
Response fields を使 用して、Google Cloud アクションの API レスポンスをワークフローで必要なフィールドのみに制限します。これによりレスポンスが小さくなり、後続ノードで返されたデータを扱いやすくなります。
デフォルトでは値は *(すべてのフィールド)です。特定のフィールドを選択するには、このセクションを展開して、アクションの出力モデルから生成されたツリーピッカーを表示します。

-
個々のフィールドのチェックボックスをオン・オフにしてフィールドを選択します。親フィールドを選択すると、その子フィールドもすべて含まれます。親フィールドが一部のみ選択されている場合は、不定状態が表示されます。
-
Search fields ボックスを使用して、フィールド名でツリーをフィルタリングします。
-
展開アイコンを選択して、複雑な出力モデルをより簡単にナビゲートできる大きなダイアログを開きます。
選択されたフィールドは Google Cloud field mask としてシリアライズされ、API リクエストの fields クエリパラメータとして送信されます。返されるフィールドを減らすことで、レスポンスは小さく高速になり、後続ノードの設定も簡素化できます。
承認を必須にする
アクションの実行前に承認が必要な場合は、Permissions タブで Require approval for this action を選択してください。

-
Notification provider: 承認者に Slack かメールのどちらで通知するかを指定します。Slack を使用する場合は、事前に DoiT との共有 Slack チャンネルを作成しておく必要があります。
-
Message (任意): 承認者へのメッセージです。前のノードのフィールドをメッセージに追加できます。メッセージが作成されると、そのフィールドのデータがメッセージ内に表示されます。これにより、受信者はシステムに移動して手動で関連情報を検索することなく、意思決定に必要な詳細を確認できるため便利です。フィールドの配列はカンマ区切りのリストとして表示されます。例:
Instance ID: i-123,i-466。 -
Reject approval after certain time (任意): アクションが承認を待機する最大時間を制限します。使用できる時間単位は Hours、Days、Weeks、Months です。例 えば、承認者が 24 時間以内にアクションを承認または拒否するよう設定できます。指定した時間内に承認者が何も行わなかった場合、そのアクションは自動的に拒否されます。
Waiter を追加する
Waiter は、フローが次のステップに進む前に、フロー内の Google Cloud アクションが完了していることを保証します。多くの Google Cloud オペレーションは非同期であり、API 呼び出しはリソースが最終状態に達する前に戻ります。Waiter を使用して、アクション結果に対する JMESPath condition を定義できます。条件が満たされるまで(または最大リトライ回数に達するまで)、アクションは繰り返し実行されます。VM が実行中になるまで待つ、bucket が存在するまで待つ、または JMESPath 式で表現できる任意の状態を待つことができます。
アクションに Waiter が必要な場合は、Enable waiter を選択し、JMESPath condition とリトライ設定を構成してください。

-
JMESPath condition: JMESPath 構文を使用し て条件を定義します。式はアクション結果に対して評価され、boolean を返す必要があります。条件がまだ満たされていない場合は、遅延後にアクションが再度呼び出されます。これは条件が満たされるか、最大リトライ回数に達するまで繰り返されます。例えば、
status == 'RUNNING'は、リソースがそのステータスを報告するまで待機します。 -
Max retries (1–30): 失敗とみなす前にアクションを再実行する最大回数です。デフォルトは 5 です。
-
Min delay (ms) / Max delay (ms): 試行間の遅延は、これらの範囲内で指数バックオフを使用します。Min delay のデフォルトは 1000 ms、Max delay のデフォルトは 10000 ms です。
Waiter の例
一般的なパターンとして、Google Cloud アクションでリソースを作成または変更し、そのリソースが目的の状態に達するまで待機してから、別のアクションや通知を続けます。
- Trigger: 例えば、schedule や manual trigger など。
- Google Cloud ノード: リソースを作成または変更するアクションを実行します(例: Compute Engine insert instance、Cloud Storage create bucket)。Waiter を有効にし、リソースの準備が整ったときに true になる JMESPath condition を設定します(例:
status == 'DONE'やstatus == 'Complete')。 - 次のノード: Notification ノード、別の Google Cloud アクション、またはBranch ノードで出力を使用し、結果に基づいて分岐処理を行います。
Waiter がない場合、次のノードはリソースがまだ pending の間に実行され、失敗したり正しく動作しなかったりする可能性があります。Waiter を使用すると、条件が満たされた後にのみフローが続行されます。
done フィールドを返す長時間実行オペレーションの場合、done == true のような条件により、オペレーションが完了するまで待機できます。
制限事項
このセクションでは、CloudFlow における特定の Google Cloud アクションの既知の制限を示します。
Cloud Storage: storage.objects.get
CloudFlow は、storage.objects.get に対する alt=media クエリパラメータをサポートしていません。ファイル名やサイズなどのメタデータは取得できますが、このアクションを通じて生のファイルコンテンツを直接ダウンロードすることはできません。これにより、Run history や保存済み結果に機密データが保存されることを防ぎ、大容量ダウンロードによる信頼性リスクも低減します。
同様の理由から、[CLI node] を使用して gcloud storage cat 経由で GCS オブジェクトのファイルコンテンツを渡すことは推奨しません。
テスト
ノードをテストするには、Test を選択してください。