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

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

-
Parameters: このタブには、選択したサービスとアクション、そしてそれを変更するオプションが表示されます。また、このタブで承認設定を構成します。利用可能なパラメータはサービスとアクションによって異なります。フィールドタイプや、前のノードから値(リスト全体やマップを含む)を参照する方法については、Node 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 またはメールのどちらで通知するかを指定します。前者を利用するには、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 構文を使用して条件を定義します。式はアクション結果に対して評価され、ブール値を返す必要があります。条件がまだ満たされていない場合、一定の遅延後にアクションが再度呼び出されます。これは条件が満たされるか最大リトライ回数に達するまで繰り返されます。例えば、
status == 'RUNNING'は、リソースがそのステータスを報告するまで待機します。 -
Max retries(1–30): 失敗と見なす前にアクションを再実行する最大回数です。デフォルトは 5 です。
-
Min delay (ms) / Max delay (ms): 試行間の遅延は、これらの範囲内で指数バックオフを使用します。最小遅延のデフォルトは 1000 ms、最大遅延のデフォルトは 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 を使用しない場合、次のノードはリソースがまだ保留状態の間に実行され、失敗したり予期しない動作をする可能性があります。Waiter を使用すると、条件が満たされた後にのみフローが進行します。
done フィールドを返す長時間実行オペレーションでは、done == true のような条件を使用すると、そのオペレーションが完了するまで待機します。
制限事項
このセクションでは、CloudFlow における特定の Google Cloud アクションの既知の制限を一覧で示します。
Cloud Storage: storage.objects.get
CloudFlow は、storage.objects.get の alt=media クエリパラメータをサポートしません。ファイル名やサイズなどのメタデータは取得できますが、このアクションを通じて生のファイルコンテンツを直接ダウンロードすることはできません。これにより、機密データが Run history や保存された結果に格納されることを防ぐとともに、大容量ダウンロードによる信頼性リスクを軽減します。
同様の理由から、GCS オブジェクトのファイルコンテンツを gcloud storage cat を介して渡すために [CLI node] を使用しないことを推奨します。
テスト
ノードをテストするには、Test を選択してください。