すべてのプロダクト
Search
ドキュメントセンター

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

最終更新日:Dec 10, 2024

Serverless Application Centerを使用すると、カスタムパイプラインを設定できます。 パイプラインを設定し、タスクフローを調整することで、コードをFunction Computeに効率的に公開できます。 このトピックでは、パイプラインの設定方法、パイプラインの詳細の設定方法、パイプライン実行レコードの表示方法など、Function Computeコンソールでパイプラインを管理する方法について説明します。

背景情報

アプリケーションを作成すると、Serverless application Centerはアプリケーションの既定の環境を作成します。 環境でパイプラインのGitイベントをトリガーするメソッドを指定し、パイプライン設定を構成できます。 パイプラインを設定するときに、[自動設定] または [カスタム設定] を選択できます。 [自動設定] を選択した場合、サーバーレスアプリケーションセンターはデフォルトのパラメーター設定に基づいてパイプラインを作成します。 [カスタム構成] を選択した場合、環境内のパイプラインのGitイベントをトリガーするメソッドを指定できます。 パイプラインの実行環境を選択することもできます。 Git情報やアプリケーション情報などの情報は、実行コンテキストとしてパイプラインに渡されます。

パイプライン設定を変更するときは、トリガーメソッドと実行環境を変更できます。 DingTalk通知とYAMLファイルを設定することもできます。

  • アプリケーションまたは環境を作成するときのパイプラインの構成

    アプリケーションまたは環境を作成するときに、パイプラインのGitトリガーメソッドと実行環境を指定できます。

    image.png

  • 既存の環境のパイプラインを変更する

    既存の環境のパイプラインのGitイベントトリガーメソッド、実行環境、DingTalk通知、およびYAMLファイルは、[パイプライン管理] タブで編集できます。

    image.png

パイプラインの設定

パイプラインを設定するには、パイプライントリガーモード、YAML、DingTalkチャットボット通知設定、およびパイプライン実行環境のパラメーターを設定する必要があります。 アプリケーションと環境を作成するときは、パイプライントリガーモードとパイプライン実行環境パラメーターのみを設定できます。 アプリケーションと環境を作成したら、[パイプライン管理] タブの [パイプライン構成] の右側にある [変更] をクリックして、前述の4つのパラメーターを変更できます。

image.png

パイプライントリガーモード

Serverless Application Centerでは、パイプラインのGitイベントをトリガーするメソッドを指定できます。 Serverless Application Centerは、Webhookを使用してGitイベントを受信します。 指定されたトリガー条件を満たすイベントが受信されると、サーバーレスアプリケーションセンターは、指定したYAMLファイルに基づいてパイプラインを作成して実行します。 次のトリガーモードがサポートされています。

  • ブランチによってトリガーされる: 環境は特定のブランチに関連付けられている必要があり、ブランチ内のすべてのプッシュイベントが一致します。

  • タグによってトリガーされる: 特定のタグ式のすべてのタグ作成イベントが一致します。

  • 分岐マージによってトリガーされる: ソース分岐から環境が関連付けられている宛先分岐への要求イベントのマージとプルが一致します。

パイプライン実行環境

このパラメーターは、[デフォルト環境] または [カスタム環境] に設定できます。

デフォルト環境

Pipeline Execution EnvironmentパラメーターをDefault Environmentに設定すると、Serverless Application Centerはパイプラインリソースを完全に管理し、Function Computeはパイプラインの実行中に発生する料金を負担します。料金を支払う必要はありません。 パイプラインの各タスクは、独立したサンドボックスVM上で実行されます。Serverless Application Centerは、パイプライン実行環境の分離を保証します。 デフォルトの環境の制限を次に示します。

  • インスタンスの仕様: 4 vCPUと8 GBのメモリ。

  • 一時ディスク容量: 10 GB。

  • タスク実行タイムアウト時間: 15分。

  • リージョン: GitHubのテンプレートまたはソースコードを使用して環境を作成する場合は、シンガポールリージョンを指定します。 Gitee、GitLab、またはCodeupを使用して環境を作成する場合は、中国 (杭州) リージョンを指定します。

  • ネットワーク: 固定IPアドレスまたはCIDRブロックは使用できません。 特定のWebサイトにアクセスするようにIPアドレスホワイトリストを設定することはできません。 仮想プライベートクラウド (VPC) のリソースにアクセスすることはできません。

カスタム環境

パイプライン実行環境パラメーターをカスタム環境に設定した場合、パイプラインはAlibaba Cloudアカウントで実行されます。 デフォルト環境と比較して、カスタム環境はより多くのカスタム機能を提供します。 Serverless Application Centerは、カスタム環境でタスクを完全に管理し、Function Computeインスタンスをリアルタイムでスケジュールして、承認に基づいてパイプラインを実行します。 既定の環境と同様に、カスタム環境にはサーバーレス機能があり、インフラストラクチャを維持する必要がありません。

カスタム環境は、次のカスタム機能を提供します。

  • リージョンとネットワーク: 実行環境のリージョンとVPCを指定して、内部コードリポジトリ、アーティファクトリリポジトリ、イメージリポジトリ、およびMaven内部リポジトリにアクセスできます。 サポートされるリージョンの詳細は、「サポートされるリージョン」をご参照ください。

  • インスタンス仕様: 実行環境のCPUとメモリの仕様を指定できます。 たとえば、より大きな仕様のインスタンスを指定して、ビルドプロセスを高速化できます。

    説明

    vCPUとメモリの比率は1:1から1:4の範囲である必要があります。 メモリ容量はGB単位で測定されます。

  • 永続ストレージ: ファイルストレージNAS (NAS) またはObject storage Service (OSS) のマウントを設定できます。 たとえば、NASを使用してファイルをキャッシュし、ビルドプロセスを高速化できます。

  • ロギング: Simple Log Service (SLS) プロジェクトとLogstoreを指定して、パイプラインの実行ログを保持できます。

  • タイムアウト期間: パイプラインタスクのカスタムタイムアウト期間を指定できます。 既定値:600。 最大値: 86400。 単位は秒です。

重要

カスタム実行環境では、Alibaba Cloudアカウント内のFunction Computeでパイプラインタスクを実行できます。 この場合、タスクの実行に対して課金されます。 詳細については、「課金概要」をご参照ください。

YAML

Serverless Application Centerは、Serverless Devsと統合されています。 Serverless DevsのYAMLファイルを使用して、アプリケーションのリソース構成を定義できます。

デフォルトのYAMLファイルの名前はs.yamlです。 別のYAMLファイルを指定することもできます。 YAMLファイルを指定した後、次の方法を使用してパイプラインで使用できます。

  • @ serverless-cd/s-deployプラグインを使用して実行する場合、プラグインは指定されたYAMLファイルを自動的に使用します。 -t/-- templateコマンドは、Serverless Devsの操作命令に追加されます。 次の例では、指定された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.de ployFile }} を使用して、指定されたYAMLファイルを参照できます。 次の例では、YAMLファイルを指定した場合、s planコマンドは指定されたファイルを使用して実行されます。 それ以外の場合、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チャットボット通知の設定

この機能を有効にした後、Webhookアドレス署名キー、およびカスタムメッセージパラメーターを設定し、通知ルールを指定する必要があります。 通知を必要とするタスクを一元管理できます。 パイプラインのYAMLファイルを使用して、各タスクの通知を有効にすることもできます。 通知を設定した後、[パイプラインの詳細] セクションで各タスクの通知を設定できます。

パイプライン環境変数の設定

[パイプライン環境変数] セクションで、[変更] をクリックします。 表示されるパネルで、設定方法を選択し、環境変数を設定し、[OK] をクリックします。

  • フォームを使用した編集 (デフォルト)

    1. [変数の追加] をクリックします。

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

      • variable: カスタム変数を入力します。

      • value: 変数値を入力します。

  • JSON形式で編集

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

    2. コードエディターで、次のJSON形式でキーと値のペアを入力します。

      {
          "key": "value"
      }

      例:

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

指定された環境変数は、Serverless Devsパイプラインで有効になります。 ${env(key)} を使用してs.yamlで参照したり、$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ファイルを使用してパイプラインを管理できます。 パイプラインの詳細を設定するときは、[プラットフォームでのホスティング] または [リポジトリからの読み取り] をパイプラインYAMLパスとして選択できます。

説明
  • プラットフォームでのホスティングを選択した場合、YAMLファイル内の定義済み変数はサポートされていません。 詳細については、「aを使用します。パイプラインを記述するyamlファイル」をご参照ください。

  • [Read from Repository] を選択した場合、YAMLファイル内の定義済み変数がサポートされます。

Hosting on Platform

デフォルトでは、パイプラインのYAMLファイルは、サーバーレスアプリケーションセンターで一元管理されています。 パイプラインのYAMLファイルを更新すると、新しい設定は次の配置で有効になります。

リポジトリからの読み取り

パイプラインのYAMLファイルは、Gitリポジトリに格納されます。 Function Computeコンソールでパイプラインの設定を変更して保存した後、Serverless Application CenterはリアルタイムでGitリポジトリへの変更をコミットします。 これはパイプラインの実行をトリガーしません。 コードリポジトリ内のイベントがパイプラインの実行をトリガーすると、Serverless Application Centerは、Gitリポジトリ内の指定されたYAMLファイルを使用してパイプラインを作成および実行します。

GitリポジトリからYAMLファイルを読み取るには、[パイプラインの詳細] セクションの [変更] をクリックします。 次の図に示すように、表示されるダイアログボックスで、[リポジトリからの読み取り] を選択し、YAMLファイルのパスを入力します。

image.png

パイプラインの詳細セクションは、左側のツール領域と右側のYAML編集領域で構成されています。

  • YAML編集領域: パイプラインのYAMLファイルを編集して、パイプラインプロセスを変更できます。 詳細については、「. yamlファイルを使用してパイプラインを説明する」トピックを参照してください。

  • ツール領域には、YAMLファイルを編集するための補助ツールがあります。 次のタブが含まれています。

    • プロセスプレビュー: パイプラインプロセスをプレビューおよび変更できます。

    • タスクテンプレート: 一般的なYAMLテンプレートを提供します。

[パイプラインの詳細] セクションの右上隅に、[保存] 、[全画面] 、および [リセット] ボタンが表示されます。

  • [保存] をクリックすると、すべての変更をYAMLファイルに保存できます。 その後、保存されたすべてのデータがパイプラインのYAMLファイルに同期されます。

  • [全画面] をクリックすると、編集領域を最大化できます。

  • [リセット] をクリックすると、YAMLファイルを最後に保存したバージョンに復元できます。

重要

[リセット] をクリックすると、YAMLファイルを最後に保存してから行った変更が元に戻ります。 注意して続行し、データがバックアップされていることを確認してください。

プロセスプレビュー

[プロセスプレビュー] タブでは、パイプラインプロセスをプレビューし、タスクの基本コンテンツとタスク間の関係を編集できます。 テンプレートタスクを追加することもできます。 パイプラインプロセスは、開始ノード (コードソースおよびトリガーメソッド) 、タスクノード、および終了ノードのタイプで構成されます。 ノードは、ノード間の依存関係を示す点線矢印によって接続される。 タスクノード上にポインタを移動すると、タスクノードを追加または削除するためのアイコンが表示されます。

image.png

  • Startノード (コードソースとトリガーメソッド)

    このノードには、パイプラインのコードソースとトリガーメソッドに関する情報が含まれているため、情報を編集することはできません。 トリガーメソッドを変更する場合は、[パイプライン設定] セクションに移動します。

    重要

    コードリポジトリを変更する場合は、アプリケーションの詳細ページに移動します。 詳細については、「アプリケーションの管理」をご参照ください。 コードリポジトリを変更すると、リポジトリのコードを使用するすべてのパイプラインが無効になります。 作業は慎重に行ってください。

  • エンドノード

    パイプラインプロセスの最後のノード。 編集できません。

  • タスクノード

    タスクノードには、タスクに関する基本情報が含まれます。 デフォルトでは、タスクノードにタスク名が表示されます。 タスクノードをクリックすると、ポップアップウィンドウが表示され、[タスク名][タスクの実行前][タスクの開始] などのパラメーターを表示および変更できます。 タスクの開始タスクをクリアすると、パイプラインが実行されたときにタスクがスキップされ、タスクノードがパイプラインプロセスで暗くなります。

  • 依存関係

    ノード間の依存関係は、一方向の点線矢印で示されている。 矢印がタスクAからタスクBを指す場合、タスクBはタスクAに従って実行され、タスクAに依存します。

    Pre-taskパラメーターを変更することで、依存関係を変更できます。 たとえば、タスクBのタスクAへの依存関係を削除する場合は、[タスクB] ノードをクリックし、[タスク前] フィールドからタスクAを削除します。

  • タスクの追加

    タスクを追加する場合は、プラスアイコンをクリックします。 タスクノードの上部、下部、および右側にあるプラスアイコンをクリックできます。 たとえば、タスクAの前に実行するタスクBを追加する場合は、[タスクA] ノードの上部にあるプラスアイコンをクリックしてタスクBを作成します。このように、タスクAはタスクBの後に実行され、タスクBに依存します。タスクAノードの下部にあるプラスアイコンをクリックしてタスクCを作成します。このようにして、タスクCはタスクAの後に実行され、タスクAに依存します。タスクAと並行し、タスクAと同じ依存関係を持つタスクDを追加する場合は、タスクAノードの右側にあるプラスアイコンをクリックしてタスクDを作成します。タスクDは、タスクAと同じプリタスクを有し、タスクAと同じタスクが続く。

  • タスクの削除

    タスクを削除する場合は、タスクノードの右上隅にある十字アイコンをクリックします。 十字アイコンをクリックすると、誤った操作を防ぐためにタスクの削除を確認するように求められます。

image.png

タスクテンプレート

[タスクテンプレート] タブには、[コードチェック][作成][デプロイ][共通] のYAMLテンプレートが表示されます。 さらに、タスクの詳細設定とプラグイン用のYAMLテンプレートも提供されています。

[タスクテンプレート] タブで使用するYAMLテンプレートを見つけ、それをクリックしてテンプレートの説明と内容を表示し、テンプレートの内容をパイプラインのYAMLファイル内の適切な位置にコピーできます。

image.png

デフォルトのパイプライン処理

デフォルトでは、パイプラインプロセスは、[設定の比較][手動レビュー][ビルドとデプロイ] の3つのタスクで構成されます。 3つのタスクは順番に実行されます。 既定では、手動レビュータスクは無効になっています。 このタスクが必要な場合は、手動で有効にする必要があります。

  • 設定の比較

    このタスクは、パイプラインのYAMLファイルがオンライン設定と一致しているかどうかを確認します。 これにより、予期しない設定変更を事前に検出できます。

  • マニュアルレビュー

    アプリケーションの安全なリリースと安定性を確保するために、手動レビュータスクを有効にすることができます。 このタスクを有効にすると、手動レビューが完了するまで、パイプラインはこのノードでブロックされます。 その後の操作は、変更が手動で承認された後にのみ実行されます。 そうでなければ、パイプラインは終了する。 デフォルトでは、このタスクは無効になっています。 このタスクを手動で有効にする必要があります。

  • ビルドとデプロイ

    このタスクは、アプリケーションを構築し、アプリケーションをクラウドにデプロイします。 デフォルトでは、完全展開が実行されます。

image.png

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

環境の詳細ページで、[パイプライン管理] タブをクリックします。 [パイプライン実行履歴] セクションでは、特定のパイプラインの実行レコードを表示できます。pipeline-history

パイプラインの実行バージョンをクリックすると、実行の詳細が表示されます。 詳細パネルでは、パイプラインの実行ログとステータスを表示し、問題をトラブルシューティングできます。

パイプラインのランタイムを更新する

次の表に、パイプラインの既定のビルド環境を示します。 デフォルトパイプラインの組み込みパッケージマネージャには、Maven、pip、およびnpmが含まれます。 Debian 10 OSのみがランタイム環境としてサポートされています。

ランタイム

サポートされているバージョン

Node.js

  • Node.js 12

  • Node.js 14 (デフォルト)

  • Node.js 16

  • Node.js 18

  • Node.js 20

Java

  • Java 8 (デフォルト)

  • Java 11

  • Java 17

Python

  • Python 2.7

  • Python 3.6

  • Python 3.7

  • Python 3.9 (デフォルト)

  • Python 3.10

Golang

  • Go 1.18 (デフォルト)

  • 1.19に行く

  • 1.20に行く

  • 1.21に行く

PHP

  • PHP 7.2

.NET

  • . NET 3.1

パイプラインのランタイムバージョンを指定するには、runtime-setupプラグインを使用するか、YAMLファイルの変数を変更します。

runtime-setupプラグイン (推奨)

この方法を使用するには、Function Computeコンソールにログインし、[アプリケーション] ページで管理するアプリケーションを見つけて、その名前をクリックします。 [パイプライン管理] タブの [パイプラインの詳細] セクションで、タスクテンプレートを使用して、右側のパイプラインのYAMLファイルを更新します。 [タスクテンプレート] タブをクリックし、[タスクプラグイン] を選択し、[ランタイムの設定] テンプレートをクリックして、テンプレートの内容を右側のYAMLファイルにコピーし、[保存] をクリックします。

説明

以降のすべてのステップで有効になるように、最初のステップにランタイムセットアッププラグインを配置することをお勧めします。

image.png

runtime-setupプラグインのパラメーターの詳細については、「runtime-setupプラグインを使用してランタイムを初期化する」をご参照ください。

YAMLファイルの変数

YAMLファイルのアクションフックを使用して、Node.jsまたはPythonのバージョンを変更することもできます。 詳細は以下の通りです。

  • Node.js

    • エクスポートPATH=/usr/local/versions/node/v12.22.12/bin:$PATH

    • export PATH=/usr/local/versions/node/v16.15.0/bin:$PATH

    • export PATH=/usr/local/versions/node/v14.19.2/bin:$PATH

    • export PATH=/usr/local/versions/node/v18.14.2/bin:$PATH

    次のサンプルコードは例を示しています。

    services:
      upgrade_runtime:
        component: 'fc'
        actions:
          pre-deploy:
            - run: export PATH=/usr/local/versions/node/v18.14.2/bin:$PATH && npm run build
        props:
    ...
  • Python

    • export PATH=/usr/local/envs/py27/bin:$PATH

    • export PATH=/usr/local/envs/py36/bin:$PATH

    • export PATH=/usr/local/envs/py37/bin:$PATH

    • export PATH=/usr/local/envs/py39/bin:$PATH

    • export PATH=/usr/local/envs/py310/bin:$PATH

    次のサンプルコードは例を示しています。

    services:
      upgrade_runtime:
        component: 'fc'
        actions:
          pre-deploy:
            - run: export PATH=/usr/local/envs/py310/bin:$PATH && pip3 install -r requirements.txt -t .
        props:
    ...