Function ComputeコンソールのServerlessアプリケーションセンターでアプリケーションの環境を管理する - Function Compute

アプリケーションの作成後、アプリケーションの環境情報を表示できます。このトピックでは、Function ComputeコンソールのServerlessアプリケーションセンターでアプリケーションの環境を作成、表示、および削除する方法について説明します。このトピックでは、さまざまな環境でサービスを分離する方法についても説明します。

背景情報

環境機能は、以下のインフラストラクチャ管理機能を提供します。

独立したインフラストラクチャの環境にサービスをデプロイして、本番サービスの高可用性または低レイテンシを実現できます。たとえば、異なるリージョンや仮想プライベートクラウド (VPC) のサービスを分離できます。
さまざまなパイプラインルールをさまざまな環境に関連付けて、運用プロセスを正確かつ安全に制御できます。たとえば、開発ブランチのコミットアクションがテスト環境で継続的統合 (CI) をトリガーし、メインブランチのマージアクションが本番環境でリリースをトリガーするように指定できます。

使用上の注意

デフォルトでは、環境にドメイン名は割り当てられません。環境は、Simple Log Service (SLS) 、VPC、ファイルストレージNAS (NAS) リソースなどのAlibaba Cloudリソースをホストできます。リソースは異なる環境で分離されています。環境ごとに異なるドメイン名を使用する場合は、リポジトリのs.yamlファイルでcustomDomainsフィールドを指定する必要があります。
環境が特定のリソースをホストする場合、対応するAlibaba Cloudサービスへのアクセス許可が必要です。関連するAlibaba Cloudサービスに対して必要な権限を含むポリシーをAliyunFCServerlessDevsRoleロールにアタッチできます。
サービスは、さまざまな環境にデプロイできます。環境によって提供される設定を使用するかどうかを決定できます。

環境に関する情報の表示

Function Compute コンソールにログインします。左側のナビゲーションウィンドウで、[アプリケーション] をクリックします。表示される [アプリケーション] ページで、管理するアプリケーションを見つけ、アプリケーションの左側にある xiala アイコンをクリックして、アプリケーションの環境を表示します。

環境の名前をクリックして、環境に関する情報を表示します。この情報には、基本情報、コードソース構成、デプロイ履歴、およびリソースが含まれます。クラウド内の環境に関連付けられたコードを開発し、パイプラインを構成することもできます。

環境ロールバック

重要

環境をロールバックするとリスクが発生する可能性があります。エラーが発生した場合は、特定の時点に環境をロールバックできます。ロールバックは、アプリケーションのビジネスコードに対してのみ実行できます。上流および下流のビジネスはロールバックできません。たとえば、現在のアプリケーションがデータベースを使用しており、エラーのためにデータベースを接続できない場合、この問題はアプリケーションのビジネスコードをロールバックすることで解決できない場合があります。

環境をロールバックするには、アプリケーションの詳細ページの [環境の詳細] タブに移動し、[デプロイ履歴] セクションの [ロールバック] をクリックします。

env-rollback

環境ロールバックは、過去のデプロイのスナップショットに基づいてビジネスロジックと構成を再デプロイします。ビジネスロジックと設定は、コードリポジトリの特定のコミットアクション内のs.yamlファイルなどのコードとリソースの設定を参照します。

リソース管理

Serverless Application Centerでは、リソースバインディング情報を表示できます。ただし、Serverless Application Centerでリソースを管理することはできません。

リソースバインディング情報を使用して、リソースの管理ページでリソースを管理できます。ただし、この方法はFunction Computeでは推奨されません。リソースを管理するには、コードリポジトリのリソース説明ファイルであるs.yamlファイルを使用することを推奨します。リソース管理ページでリソースに対して操作を実行しても、コードリポジトリのs.yamlファイルを変更しないと、リソースが上書きされる可能性があります。たとえば、環境のブランチ内のコードリポジトリのs.yamlファイルは、関数のメモリサイズが1,024 MBであることを指定します。開発者は、リソース管理ページで関数のメモリサイズを2,048 MBに直接変更しますが、コードリポジトリのs.yamlファイルは変更しません。環境のパイプライン展開がトリガーされると、関数のメモリサイズは2,048 MBから1,024 MBに戻ります。

クラウドベースの開発

サーバーレスアプリケーションセンターは、クラウドベースの開発機能を提供します。アプリケーションの詳細ページの [クラウド開発] タブで、[コードリポジトリの初期化] をクリックしてコードを初期化します。

初期化後、WebIDEでコードを表示し、基本的な開発およびデバッグ操作を実行できます。操作を実行した後、ターミナルまたはGitプラグインを使用してコードをコードリポジトリにプッシュできます。左上隅の [コードをリポジトリに保存] をクリックして、コードを追加、コミット、プッシュすることもできます。

cloud-develop

パイプライン管理

詳細については、「パイプラインの管理」をご参照ください。

環境を作成するCreate an environment

サーバーレスアプリケーションセンターは、マルチ環境機能を提供します。アプリケーションの詳細ページで [環境の作成] をクリックすると、環境を作成できます。 create-environment

次の表に、環境を作成するために設定する必要があるパラメーターを示します。

パラメーター	説明
環境名	環境の名前。環境名は、さまざまな環境を区別するのに役立ちます。環境タイプは複数の環境名に対応できます。
環境タイプ	環境のタイプ。環境タイプは、環境の分類とフィルタリングに役立ちます。テスト環境、ステージング環境、および本番環境のタイプがサポートされています。
説明	環境の説明、リージョン、ロール名などの基本情報。リージョン、ロギング、ネットワーク、ストレージの設定などの設定は、`s.yaml`ファイルの設定よりも環境の作成ページで優先されます。たとえば、コードリポジトリの`s.yaml`ファイルでリージョンとして中国 (杭州) を指定し、環境の作成時にリージョンを中国 (北京) に設定した場合、リソースは中国 (北京) リージョンにデプロイされます。
パイプライン構成	デフォルトでは、各環境はServerless Application Centerのパイプラインに対応します。さまざまな環境にパイプラインを設定できます。

Serverless Application Centerが提供するマルチ環境機能は、コードリポジトリのコードブランチによりリンクされています。推奨されるベストプラクティスは、1つの環境が1つのパイプラインに対応し、1つのパイプラインが1つのブランチに対応することです。たとえば、開発環境のdevブランチ、テスト環境のtestブランチ、および実稼働環境のmain/masterブランチをコードリポジトリに作成できます。これにより、コードを別のブランチにコミットしてパイプラインをトリガーできます。これにより、環境を期待どおりに更新できます。コードリポジトリによって提供されるプルリクエスト (PR) およびマージリクエスト (MR) 機能を使用して、開発ブランチからテストブランチ、およびメインブランチへのコード環境のフローを実装できます。

実際のビジネスシナリオでは、異なるユーザーに対して同じコードを使用して複数のアプリケーションをデプロイすることができます。この場合、1つのコードブランチを介して複数のパイプラインをトリガーできます。その結果、コードが更新された後、一度に複数の環境が有効になります。

環境の削除

Function Compute コンソールにログインします。左側のナビゲーションウィンドウで、[アプリケーション] をクリックします。 [アプリケーション] ページで、削除する環境を見つけ、[操作] 列の [削除] をクリックします。

警告

環境を削除するときにリソースを削除する必要がある場合があります。環境を削除する前に、削除するリソースの名前とタイプを決定する必要があります。削除しないリソースの左侧にあるチェックボックスは选択しないでください。

delete-environment

環境を使用してサービスを分離する

Serverless Application CenterはGitOpsを使用してDevOpsのベストプラクティスを実装します。 Gitリポジトリは、アプリケーションのインフラストラクチャと継続的統合および継続的配信 (CI/CD) プロセスを管理するために使用されます。 Gitリポジトリは、アプリケーションステータスの唯一のソースです。環境ベースのサービス分離を実装するには、仕様を満たすYAMLファイルを使用する必要があります。 YAML仕様の詳細については、YAMLの仕様をご参照ください。

多くの場合、開発とO&Mの役割は企業で区別されます。 2つのタイプの役割には明確な責任があります。ほとんどの場合、O&M担当者は企業のインフラストラクチャを管理し、開発者にインフラストラクチャの使用を許可します。すべてのインフラストラクチャがGitリポジトリで維持されている場合、O&M担当者はインフラストラクチャを変更するためのコードを提出する必要がありますが、これはほとんどのO&Mエンジニアの習慣に反します。したがって、Serverless Application Centerでは、次の配置方法を使用できます。

方法 1
環境ごとに異なるYAMLファイルを維持します。環境でパイプラインを構成し、指定されたYAMLファイルをデプロイに使用します。
YAML継承は、YAML設定の繰り返しを減らすためにServerless Devsでサポートされています。詳細については、「
YAML継承。
方法 2
異なる環境で同じYAMLファイルを使用します。環境の差別化された構成は、パイプラインの環境変数を使用して指定されます。 YAMLファイルでこれらの環境変数を参照して、分離を実装できます。環境変数の設定方法の詳細については、「パイプラインの管理」トピックの「パイプライン環境変数」セクションをご参照ください。
```
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)}
```

方法 3

異なる環境で同じYAMLファイルを使用し、環境のリソース情報を使用して、指定されたサービスを設定します。次のサンプルコードに例を示します。

service:
  logConfig:
    project: ${environment.outputs.slsProject}
    logstore: ${environment.outputs.slsLogStore}
  vpcConfig:
    vpcId: ${environment.outputs.vpcId}
    securityGroupId: ${environment.outputs.securityGroupId}
    vswitchIds:
    - ${environment.outputs.vswitchId}
  nasConfig:
    userId: 10003
    groupId: 10003
    mountPoints:
    - serverAddr: ${environment.outputs.nasMountTargetId}
      nasDir: /fc-deploy-service
      fcDir: /mnt/auto

異なる展開方法は、異なるシナリオに適しています。

方法 1
これは、R&DおよびO&M担当者が同じチームに所属し、すべての担当者がYAMLファイルに対する権限を持っているシナリオに適用されます。この方法は効率的です。
方法 2
これは、インフラストラクチャの変更がまれであり、環境の数が少ないシナリオに適用されます。 O&M担当者は、事前にリソースを計画し、パイプラインの環境変数でリソースを構成します。 YAMLファイルで環境変数を宣言して参照するだけです。この方法は、R&DおよびO&M担当者の責任を完全に分離します。しかし、この方法は、大量のインフラストラクチャが使用される場合に拡張することが困難である。
方法 3
これは、最新のサーバーレスアプリケーションの開発に適用されます。たとえば、CIプロセス中に、さまざまな環境をトリガーしてクラウドリソースを取得し、テスト後に環境リソースを削除できます。環境を使用して、数回クリックするだけでサービスを有効にできます。 R&DおよびO&M担当者の責任は、本番環境で分けることができます。生産リソースに対するアクセス許可は、オンデマンドでR&D担当者に付与できます。