Function Compute:パイプラインの管理

パイプライン構成

パイプライン構成には、主に以下の 4 つの項目があります：トリガー方式、実行環境、リソース記述 YAML、および DingTalk チャットボット通知。アプリケーションまたは環境の作成時に、トリガー方式および実行環境を構成できます。作成後に構成を変更する場合は、[編集] ボタンをクリックして、すべての 4 つの項目を設定できます。

パイプライントリガー方式

Application Center では、パイプラインを起動する Git イベントをカスタマイズできます。Application Center は Webhook を使用して Git イベントを受信します。トリガー規則に一致するイベントを受信すると、構成済みのパイプライン YAML ファイルに基づき、パイプラインが作成・実行されます。サポートされるトリガー方式は以下のとおりです。

• ブランチトリガー：環境は指定されたブランチに関連付けられている必要があります。指定されたブランチに対するすべての Push イベントに一致します。

• タグトリガー：指定されたタグ式に対するすべてのタグ作成イベントに一致します。

• ブランチマージトリガー：環境に関連付けられたターゲットブランチへの、指定されたソースブランチからの Merge または Pull Request イベントに一致します。

パイプライン実行環境

パイプラインの実行環境 には、「デフォルト実行環境」と「専用実行環境」の 2 つのモードがあります。

デフォルト実行環境

デフォルト実行環境では、プラットフォームがパイプラインリソースを完全に管理します。Alibaba Cloud Function Compute がパイプライン実行のコストを負担するため、お客様には追加料金は発生しません。各パイプラインタスクは、独立したサンドボックスコンテナ内で実行されます。プラットフォームは、パイプライン実行環境の隔離を保証します。デフォルト実行環境には、以下の制限があります。

• インスタンスリソース仕様：4 vCPU、8 GB メモリ。

• 一時ディスク領域：10 GB。

• タスク実行タイムアウト：15 分。

• リージョン制限：テンプレートによる直接デプロイおよび GitHub コードソースは中国以外のシンガポールリージョンを使用します。Gitee、パブリック GitLab、Codeup は中国 (杭州) リージョンを使用します。

• ネットワーク制限：固定 IP アドレスおよび CIDR ブロックはサポートされていません。IP アドレスホワイトリストを用いた特定ウェブサイトへのアクセスはサポートされていません。VPC 内のリソースへのアクセスはサポートされていません。

専用実行環境

専用実行環境 では、パイプラインタスクがお客様のアカウント内で実行され、より高度なカスタマイズが可能です。お客様の権限付与に基づき、Application Center は専用実行環境内のタスクを完全に管理し、お客様のアカウント内の Function Compute インスタンスをリアルタイムでスケジュールしてパイプラインを実行します。デフォルト実行環境と同様に、専用実行環境も完全なサーバーレス環境です。基盤となるインフラストラクチャの管理は不要です。

専用実行環境 では、以下のカスタマイズオプションが提供されます。

• リージョンおよびネットワーク：実行環境のリージョンおよび VPC を指定でき、プライベートネットワーク上のコードリポジトリ、アーティファクトリポジトリ、イメージリポジトリ、およびプライベート Maven サーバーへのアクセスなど、さまざまなシナリオに対応できます。対応リージョンの詳細については、「リージョン」をご参照ください。

• インスタンスリソース仕様：実行環境の CPU およびメモリ仕様を指定できます。たとえば、ビルド速度向上のためにより大きなインスタンスを指定できます。

  説明

  vCPU 数とメモリ（GB）の比率は、1:1 ～ 1:4 の範囲である必要があります。

• 永続ストレージ：NAS および OSS のマウント構成を指定できます。たとえば、ファイルキャッシュ用に NAS ファイルシステムをマウントすることで、ビルドを高速化できます。

• ログ：パイプライン実行ログの永続化先として、SLS プロジェクトおよび Logstore を指定できます。

• タイムアウト：パイプラインタスクの実行タイムアウトをカスタマイズできます。デフォルト値は 600 秒、最大値は 86,400 秒です。

リソース定義 YAML

Serverless Application Center は、Serverless Devs 開発者ツールと深く統合されています。Serverless Devs のリソース記述ファイルを使用して、アプリケーションのリソース構成を宣言できます。デフォルトのリソース記述ファイル名は `s.yaml` ですが、別のファイル名を指定することもできます。リソース記述ファイルを指定した後、パイプライン内では以下の 2 通りの方法で利用できます。

• @serverless-cd/s-deploy デプロイメントプラグインを使用する場合、プラグインは指定されたリソース記述ファイルを自動的にデプロイに使用します。これは、Serverless Devs の操作命令に -t/--template コマンドを追加することで実現されます。次の例では、指定されたリソース記述 YAML ファイルが demo.yaml であるため、プラグインによって実行されるコマンドは s deploy -t demo.yaml となります。

- name: deploy
  context:
    data:
      deployFile: demo.yaml
      steps:
      - plugin: '@serverless-cd/s-setup'
      - plugin: '@serverless-cd/checkout'
      - plugin: '@serverless-cd/s-deploy'
  taskTemplate: serverless-runner-task

• スクリプトを使用して実行する場合、${{ ctx.data.deployFile }} を用いて、特定のリソース記述ファイル名を参照できます。たとえば、次のサンプルコードでは、リソース記述ファイルが指定されている場合は `s plan` コマンドをそのファイルで実行し、指定されていない場合はデフォルトの `s.yaml` ファイルで実行します。

- name: pre-check
  context:
    data:
      steps:
      - run: s plan -t ${{ ctx.data.deployFile || s.yaml }}
      - run: echo "s plan finished."
  taskTemplate: serverless-runner-task

DingTalk ロボット通知

この構成を有効化した後、DingTalk ロボットの Webhook アドレス、署名キー、通知ルール、および カスタムメッセージ を構成してください。ここで、通知が必要なタスクを一元管理できます。また、パイプライン YAML ファイルを介して、各タスクごとに個別に通知を有効化することも可能です。ここでの全体的な通知構成を完了した後、パイプラインの詳細 で、各タスクの通知設定をさらに細かく調整できます。

パイプライン環境変数

パイプラインの環境変数 セクションで、変更 をクリックし、環境の構成方法を選択して、以下に示す手順に従って構成を完了した後、[デプロイ] をクリックします。

• フォーム形式で編集（デフォルト）

  1. +変数を追加 をクリックします。

  2. 環境変数のキーと値のペアを構成します。

     • 変数：任意に指定可能。

     • 値：任意に指定可能。

• JSON 形式で編集

  1. JSON 形式で編集 をクリックします。

  2. テキストボックスに、以下の形式でキーと値のペアを JSON 形式で入力します。

     {
         "key": "value"
     }

     次の例をご参照ください。

     {
         "REGION": "MY_REGION",
         "LOG_PROJECT": "MY_LOG_PROJECT"
     }

環境変数は Serverless Devs パイプライン内で有効になります。`s.yaml` 内では ${env(key)} を、シェルコマンド内では $Key を使用して参照できます。次の例をご参照ください。

vars:
  region: ${env(REGION)}
  service:
    name: demo-service-${env(prefix)}
    internetAccess: true
    logConfig:
      project: ${env(LOG_PROJECT)}
      logstore: fc-console-function-pre
    vpcConfig:
      securityGroupId: ${env(SG_ID)}
      vswitchIds:
        - ${env(VSWITCH_ID)}
      vpcId: ${env(VPC_ID)}

パイプライン詳細

パイプラインの詳細 セクションでは、パイプラインフローの構成およびパイプライン内のタスクとその依存関係に関する詳細設定を行えます。プラットフォームはデフォルトのパイプラインフローを自動生成しますが、これを編集することも可能です。

パイプラインは YAML ファイルで管理されます。構成方法には、「プラットフォーム管理」と「リポジトリの読み取り」の 2 つがあります。

プラットフォームホスティング

デフォルトでは、パイプライン YAML ファイルはプラットフォームがホストします。つまり、構成はプラットフォーム上で一元管理され、更新後に次回のデプロイで反映されます。

リポジトリから読み込み

パイプラインの YAML 記述ファイルは、リモート Git リポジトリに保存されます。コンソールで編集・保存すると、プラットフォームが変更内容をリアルタイムでお客様の Git リポジトリにコミットします。このコミットはパイプライン実行をトリガーしません。コードリポジトリ内のイベントがパイプラインをトリガーすると、プラットフォームはお客様が指定した Git リポジトリ内のパイプライン YAML ファイルを用いて、パイプラインを作成・実行します。

リポジトリの読み取り を、パイプラインの詳細 セクションの上部で選択し、YAML ファイル名を入力します（下図参照）。

パイプラインの詳細 セクションの主な構成要素は、左側のサポートツールエリアと右側の YAML 編集エリアです。

• YAML 編集エリア：パイプライン YAML ファイルを直接編集して、パイプラインフローを変更できます。「YAML ファイルを用いたパイプラインの記述」をご参照ください。

• サポートツールエリア：YAML 編集を支援するツールを提供しており、以下の機能が含まれます。

  • プロセスプレビュー：パイプラインフローの視覚的プレビューおよび簡単な編集機能を提供します。

  • タスクテンプレート：共通タスク向けの一連の YAML テンプレートを提供します。

セクションの右上には、[保存]、[全画面表示]、[リセット] の 3 つのボタンがあります。

• [保存] ボタン：ページ上で行った YAML ファイルの変更を保存し、パイプライン YAML ファイルと同期します。

• [全画面表示] ボタン：メイン編集エリアを全画面表示に拡大します。

• [リセット] ボタン：直近の保存以降に行ったすべての変更をキャンセルし、初期状態に戻します。

パイプライン実行履歴の表示

特定のパイプライン実行バージョンをクリックすると、その詳細を表示できます。これにより、パイプラインの実行ログおよびステータスを素早く確認でき、進行状況のモニタリングや問題のトラブルシューティングが容易になります。

パイプラインビルド環境ランタイムのアップグレード

パイプラインランタイムバージョンは、runtime-setup パイプラインプラグイン を使用するか、リソース記述ファイル内の環境変数 を変更することで設定できます。