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

アプリケーションの作成後、その環境情報を表示できます。このトピックでは、Function ComputeコンソールのServerless application Centerでアプリケーションの環境を管理する方法について説明します。たとえば、環境を作成、表示、削除したり、さまざまな環境でサービスを分離したりする方法について説明します。

背景

環境機能は、インフラストラクチャ管理機能を提供します。環境では、次のことができます。

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

使用上の注意

デフォルトでは、環境にドメイン名は割り当てられません。環境は、Log Service、VPC、Apsara File Storage 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でリソースを管理することはできません。

リソースバインディング情報を使用して、リソースの管理ページでリソースを管理できます。ただし、この方法はお勧めできません。リソースを管理するには、コードリポジトリのリソース説明ファイルである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担当者に付与できます。