ご使用の前に

Q. SourceDeployとは何ですか?

  • SourceDeployは、新規または更新されたソースを自動でサーバに展開して適用する展開自動化サービスです。
  • SourceDeployは、あらかじめ設定されたユーザーベースのコマンドで、ソースの展開、実行、および検証を自動化でき、展開中にサービスの中断時間を最小限に抑えることができます。
  • SourceDeployは、展開の実行管理者を介して展開実行を制御するので、必ず必要な展開のみを適用してサービスの質を保証することができます。

Q. SourceDeployの使用手順を教えてください。

devtools-4-1-101

  1. 展開プロジェクトの作成: コンソールのDev Tools > SourceDeployで新しい展開プロジェクトを作成します。
  2. エージェントのインストール: 展開したいターゲットサーバにSourceDeploy用のエージェントをインストールします。
  3. 展開シナリオの作成: 展開するファイルとコマンドを設定することができる展開シナリオを作成します。
  4. 展開の実行: 作成したプロジェクトをクリックして、展開の実行ページで展開を実行します。

Q. SourceDeploy用エージェントのインストールは必須ですか?

SourceDeployを使用するには、展開したいターゲットサーバにSourceDeploy用のエージェントのインストールが、 必須です。 エージェントをインストールする方法は、次のリンクで確認してください。(エージェントのインストールガイドに移動する)

Q. SourceDeployがサポートする展開環境は何ですか?

SourceDeployは、Naverクラウドプラットフォームで作成したサーバ、Auto Scaling、Kubernetesを対象に展開をサポートします。 よって、SourceDeployを使用するためには、事前にサーバ、Auto Scaling Group、Kubernetesが作成されていなければなりません。

また、CentOS、Ubuntuの画像タイプをサポートします。 詳細はエージェントのインストールガイドでご確認下さい。

参考: NaverクラウドプラットフォームのSecure Zone内に作成したサーバは、SourceDeployで展開することができません。

Q. 作成した展開プロジェクトは、どこで確認できますか?

SourceDeployで作成した展開プロジェクトは、Naverクラウドプラットフォームのコンソールで確認することができます。

  • 展開プロジェクトと展開ステージ、展開シナリオを作成、変更、削除することができます。
  • 展開プロジェクトを使用するサブアカウントを追加して、権限を変更することができます。
  • 展開を実行することができます。
  • 展開履歴と展開ログを確認することができます。

SourceDeployの使用権限

SourceDeployは、次のような権限があります。

展開プロジェクトの作成権限

この権限は、顧客のアカウントが、Management > Sub Accountメニューでサブアカウントに付与することができます。(Sub Account利用ガイドに移動する)

1. NCP_SOURCE_DEPLOY_MANAGER

  • コンソールで、「展開プロジェクトの作成」で展開プロジェクトを作成することができ、自分が作成した展開プロジェクトを管理、または他のサブアカウントに共有することができます。

  • お客様のアカウントは、当該権限が基本的に付与されており、サブアカウントはお客様のアカウントユーザーからManagement > Sub Accountメニューで、当該権限を割り当てられます。

    参考: NCP_SOURCE_DEPLOY_MANGERの権限を付与する

devtools-4-1-102

① サブアカウントにSourceDeployの管理者権限を付与するためには、Sub AccountメニューのSub Accountsを選択します。

② 付与するサブアカウントを選択します。

devtools-4-1-103

① 選択したサブアカウントのポリシーでNCP_SOURCE_DEPLOY_MANAGERポリシーを選択します。

② 該当するポリシーを追加します。

展開プロジェクトの使用権限

この権限は、顧客のアカウントやSourceDeploy管理者(サブアカウント)が、SourceDeployで展開プロジェクトを共有するサブアカウントに付与する権限です。

1. ADMIN

  • 展開プロジェクトの照会、設定の変更、削除の権限が含まれています。
  • 展開プロジェクト内の展開、ステージの作成、設定の変更、削除の権限が含まれています。
  • 展開ステージ内の展開、シナリオの作成、設定の変更、削除の権限が含まれています。
  • 展開プロジェクトを作成したアカウントは、自動的にADMIN権限が与えられます。
  • 展開プロジェクトのユーザーアカウント(サブアカウント)を割り当て、権限を付与することができます。
  • 展開を実行することができます。

2. USER

  • 展開プロジェクト、展開ステージ、展開シナリオの照会権限が含まれています。
  • 展開を実行することができます。

展開プロジェクトの作成

Step 1.コンソールにアクセス

コンソールで、Dev Tools > SourceDeployメニューにアクセスします。

devtools-4-3-104

展開プロジェクト作成 ボタンをクリックして、新規の展開プロジェクトを作成します。

  • 展開プロジェクトを作成するには、ログインしているアカウントがお客様のアカウントか、NCP_SOURCE_DEPLOY_MANAGER権限、あるいはNCP_INFRA_MANAGER権限を持っているサブアカウントが必要です。
  • NCP_SOURCE_DEPLOY_MANAGER権限、あるいはNCP_INFRA_MANAGER権限は、コンソールのManagement > Sub Accountメニューから割り当てることができます。

② SourceDeployに最初にアクセスすると、次のような文言が表示されます。

  • 現在、作成された展開プロジェクトがありません。 展開プロジェクトの作成ボタンをクリックして、展開プロジェクトを作成してください。

Step 2.基本設定

展開プロジェクトの作成に必要な情報を入力します。

devtools-4-3-105

① 作成する展開プロジェクト名を入力します。

Step 3.展開環境の設定

展開環境を設定します。

devtools-4-3-106

① 展開Stageは、基本的にdev、test、realが表示されます。 必要なStageを設定して、環境を構成することができます。

② 新規の名前のStageを作成できます。

③ 設定されたサーバーには、SourceDeploy用エージェントがインストールされていなければなりません。(エージェントのインストールガイドに移動する)

④ Stageを設定に変更すると、詳細情報を設定することができます。

  • 展開ターゲットは、Naverクラウドプラットフォームで作成したサーバ、Auto Scaling、Kubernetes Serviceの中から選択できます。
  • 現在保有しているサーバ、Auto Scaling、Kubernetes Serviceのリストが表示されます。 展開するターゲットを選択します。
  • サーバ、Auto Scaling、Kubernetes Serviceは、Naverクラウドプラットフォームの各商品で作成できます。
  • 展開ターゲットがAuto Scaling Groupの場合、そのグループでスケールアウトされたサーバーに対して自動展開が実行されます。 (以前、Auto Scaling Groupに展開したことがある場合にのみ実行されます。)

Step 4.ユーザー共有

展開プロジェクトを共有するユーザーと展開の実行管理者を設定します。

devtools-4-3-107

① 選択したビルドプロジェクトに設定されているサブアカウントが、テーブルに自動で追加されます。

② 展開プロジェクトを共有するユーザーを、リストから選択します。

  • 展開プロジェクトを共有するユーザーを、サブアカウントの中から選択できます。 サブアカウントユーザーを追加するためには、まず、Sub Accountメニューでアカウントを追加登録してください。((Sub Account利用ガイドに移動する)

③ 共有するユーザーに割り当てるアクセス権を選択します。 アクセス権は、2つあります。

  • ADMIN: 展開プロジェクトの設定を変更/削除、Stage、シナリオの作成/設定変更/削除、および展開の実行権限が含まれています。
  • USER: 展開プロジェクト、Stage、シナリオの照会、および展開の実行権限が含まれています。

④ 展開の実行に対する承認の手続きが必要な場合、展開の実行管理者を設定します。

  • 展開の実行管理者を設定すると、そのStageで発生する展開は、展開の実行管理者から承認を受けなければ実行されません。
  • 展開の実行管理者は、ユーザー共有に追加したサブアカウント、およびお客様のアカウントの中から選択できます。

⑤ 展開の承認プロセスを適用するStageを選択します。

  • Stageは、Step 2.展開環境の設定段階で設定したStageから選択することができます。

⑥ 展開を実行させる展開の承認に必要な最小人数を選択します。

  • 1名: 最小1名の展開実行管理者から承認を受ければ、展開が実行されます。
  • 全員: 設定された全員の展開実行管理者から承認を受ければ、展開が実行されます。

Step 5.最終確認

展開プロジェクトの作成を完了します。

devtools-4-3-108

① 前の段階で設定した展開プロジェクトの情報を確認します。

展開プロジェクトの作成ボタンをクリックして、作成を完了します。

展開シナリオの作成(展開ターゲット: Server, Auto Scalingの場合)

展開ファイルと展開コマンドを設定することができる展開シナリオを作成します。

Step 1.展開シナリオの作成

devtools-4-3-109

① 作成された展開プロジェクトを選択します。

作成ボタンをクリックします。

  • 展開シナリオを作成するには、ログインしているアカウントがお客様のアカウントか、NCP_INFRA_MANAGER権限、あるいは選択した展開プロジェクトに対してADMIN権限を持っているサブアカウントが必要です。
  • NCP_INFRA_MANAGER権限は、コンソールのManagement > Sub Accountメニューから割り当てることができます。

Step 2.基本設定

devtools-4-3-110

① 選択した展開プロジェクトです。

② 選択した展開stageです。

③ 作成する展開シナリオ名を入力します。

④ 作成する展開シナリオの説明を入力します。

Step 3.展開戦略の設定

展開ターゲット: Server

devtools-4-3-133

① 展開戦略を設定します。

  • 基本: 設定された展開サーバに対して順次展開を進めます。
展開ターゲット: Auto Scaling

devtools-4-3-134

① 展開戦略を設定します。

  • 基本: 設定されたAuto Scaling Group内のサーバに対して順次展開を進めます。
  • ブルー/グリーン: 設定されたAuto Scaling Groupをコピーして 新規のAuto Scaling Groupを作成し、当該グループに展開を進めます。 展開が正常に完了すると、新しいAuto Scaling Group内のサーバがロードバランサに接続し、そのGroupにトラフィックがルーティングされます。 ブルー/グリーン戦略で、展開中断時間を最小限に抑えることができます。

② 新しいAuto Scaling Groupに接続されるロードバランサを選択します。 展開ターゲットに設定されたAuto Scaling Groupに接続されたロードバランサリストの中から選択することができます。

③ ブルー/グリーンの展開完了後、既存のAutoScaling Group内のサーバーに対する処理方法を選択します。

  • 維持: ブルー/グリーンの展開が完了しても 既存のAutoScaling Group内のサーバは、返却されず、ロードバランサからのみ接続が解除されます。
  • 自動返却: ブルー/グリーンの展開が完了した後、既存のAutoScaling Group内のサーバーを自動で返却します。 サーバーのみ返却され、AutoScaling Group自体は削除されません。

Step 4.展開ファイルの設定

devtools-4-3-111

① 展開するファイルを選択します。

  • SourceBuild: 選択したビルドプロジェクトの最後のビルド結果を照会して、そのビルド結果を自動展開します。 最後のビルド結果が失敗したり、ビルド結果をアップロードしていない場合には、展開が実行されません。

  • Object Storage: 保有しているObject Storage内のバケットの中から展開ファイルを選択します。 展開ファイルは、zipフォーマットで圧縮されたファイルのみ展開することができます。

  • 後で設定: 展開ファイルは、後で設定できます。

Step 5.展開コマンドの設定

devtools-4-3-112

① 展開の前に、サーバで実行するコマンドを設定します。 複数を入力することができ、順次実行されます。

  • 実行アカウント: コマンドを実行するサーバアカウントを入力します。
  • 実行コマンド: サーバで実行するコマンドを入力します。

② ファイルを展開するパスを設定します。 複数を入力することができ、順次展開されます。

  • ソースファイルのパス: 展開するファイルのパスを入力します。 パスは、展開ファイルに基づいて作成します。
  • 展開ファイルのパス: 展開するサーバのパスを入力します。 サーバの全てのパスを作成します。
  • 展開ファイルを「後で設定」するか、またはSourceBuildの最後のビルド結果がない場合、メッセージが表示されます。

③ 展開の後、サーバで実行するコマンドを設定します。 複数を入力することができ、順次実行されます。

  • 実行アカウント: コマンドを実行するサーバアカウントを入力します。
  • 実行コマンド: サーバで実行するコマンドを入力します。

④ ロールバックを使用すると、展開を失敗した場合、自動的に以前のバージョンにロールバックします。

  • ロールバックは、Stageを基準に最終的に成功した展開を再実行させることで、ロールバックが行われます。

  • 前に展開したファイルがObject Storageに存在しないか、最後の成功した展開がない場合、ロールバックが失敗します。

Step 6.最終確認

展開シナリオの作成を完了します。

devtools-4-3-113

① 前の段階で設定した展開シナリオの情報を確認します。

展開シナリオの作成ボタンをクリックして、作成を完了します。

展開シナリオを作成する(展開ターゲット: Kubernetesの場合)

展開シナリオの作成

devtools-4-3-135

① 作成された展開プロジェクトを選択します。

展開シナリオの作成ボタンをクリックします。

  • 展開シナリオを作成するには、ログインしているアカウントがお客様のアカウントか、NCP_FIN_INFRA_MANAGER権限、あるいは選択した展開プロジェクトに対してADMIN権限を持っているサブアカウントが必要です。
  • NCP_FIN_INFRA_MANAGER権限は、コンソールのManagement > Sub Accountメニューから割り当てることができます。

展開シナリオの基本設定:

devtools-4-3-136

① 選択した展開プロジェクトです。

② 選択した展開stageです。

③ 作成する展開シナリオ名を入力します。

④ 作成する展開シナリオの説明を入力します。

マニフェストの設定

devtools-4-3-137

① SourceCommit内の保有リポジトリとブランチを選択します。

② 展開するマニフェストファイルのパスを入力して、追加/削除することができます。

マニフェストの作成

Kubernetesクラスタにオブジェクトを展開するためにマニフェストの作成が必要であり、展開に使用するマニフェストはSourceCommitのリポジトリに保存されていなければなりません。

  • ブルー/グリーン、Canaryの更新のための新しいマニフェストを作成する必要はありません。 ブルー/グリーン、Canaryに必要な新しいオブジェクトは、SourceDeployで自動展開します。
  • ブルー/グリーンの展開の場合、新しいバージョン(Green)のオブジェクトが展開されるため、オブジェクト名が変更されます。 展開されたオブジェクト名が変更されても、マニフェスト名を毎回変更する必要はありません。

Ex ) 既に展開されたKubernetesのオブジェクト(kind : Deployment, name : sampleapp, namespace : dev)

devtools-4-1-138

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sampleapp
  namespace: dev

--省略--

展開戦略の設定

  • Rollingアップデート戦略の場合、既に展開されているオブジェクトがないと、新しいオブジェクトが展開されます。
  • ブルー/グリーン、Canaryのアップデート戦略の場合、既に展開されているオブジェクトがないと、展開は失敗します。
  • ブルー/グリーンの展開の場合、新しいバージョン(Green)のオブジェクトが展開されるため、オブジェクト名が変更されます。 展開されたオブジェクト名が変更されても、マニフェスト名を毎回変更する必要はありません。

展開戦略の設定(Rolling)

devtools-4-3-139

① Rollingの展開戦略を設定します。

展開戦略の設定(ブルー/グリーン)

devtools-4-3-140

① ブルー/グリーンの展開戦略を設定します。

展開戦略の設定(Canary - 分析方法: 手動)

devtools-4-3-141

① Canaryの展開戦略を設定します。

② Baseline、Canary版のPod数を設定することができ、1〜10まで設定可能です。

  • Baseline、Canary版のアプリケーションに適用するreplicasを設定します。

③ Canaryの分析方法を手動で設定します。

  • Baseline、Canary版のアプリケーションをユーザーが手動で分析して、展開の承認/取消の可否を決定します。

④ ユーザーがCanaryの展開/取消を決定することができる最大時間であり、1分〜360分まで設定可能です。

  • 設定された時間を超えると、自動的に展開が取り消され、baseline、canaryアプリケーションは終了します。

展開戦略の設定(Canary - 分析方法: 自動)

devtools-4-3-142

① Canaryの展開戦略を設定します。

② Baseline、Canary版のPod数を設定することができ、1〜10まで設定可能です。

  • Baseline、Canary版のアプリケーションに適用するreplicasを設定します。

③ Canaryの分析方法を自動で設定します。

  • BaselineとCanary版のアプリケーションを自動で分析して、分析結果に応じて展開を進めます。

④ Prometheus収集ログのリクエストのためのPrometheus endpointを入力します。

  • アプリケーションを自動分析するために Kubernetes ClusterにPrometheusがインストールされていなければなりません。
  • エンドポイントは、SourceDeployでアクセスできなければならないので、グローバルIPに設定する必要があります。 (Prometheus ServiceをLB typeに設定してください。)

⑤ Prometheusを分析する際、BaselineとCanaryを区分するため使用します。

  • その入力値はPromQL構文で$ {basecanary}として活用することができます。
  • 分析環境変数は、Baseline、CanaryそれぞれPod Labelのncp_sourcedeploy_canary="baselineenv" / ncp_sourcedeploy_canary="canaryenv" で設定され、その値をCanaryの解析時に活用することができます。

⑥ 評価の対象となるMetricを作成、変更、削除することができます。

  • すべてのMetric Weightの総和は、100にしなければなりません。
  • 作成: 作成ボタンをクリックします。 (「Metric作成」の詳細は、下記の内容を参照してください。)
  • 設定変更: 変更するMetricを選択した後、設定の変更をクリックします。
  • 削除: 変更するMetricを選択した後、削除をクリックします。

⑦ 分析の設定:

  • 分析遅延時間: Baseline、Canary版のアプリケーションを展開した後、設定した時間の後に分析を開始します。設定は0〜60分まで可能です。

  • 分析時間: 総分析を実行する時間です。設定は10分〜360分まで可能です。

  • 分析周期: 分析を実行する周期で、設定は1分〜360分まで可能ですが、分析時間を超えることはできません。

  • Metricの収集周期: 分析中に収集されたmetric値をサンプリングする周期です。設定は1秒〜360秒まで可能です。

分析成功スコア: 分析時のすべてのメトリックに対する分析評価です。設定は1〜100まで可能です。

  • 分析フェーズごとに、そのスコアを満たさなければ展開が行われません。
  • 分析フェーズで、そのスコアを満たしていない場合、分析がすぐに停止されて、Baseline、Canary版のアプリケーションは終了します。
  • 登録された すべてのメトリックスコアの合計です。 (メトリックスコアの詳細については、「Metricの作成」フェーズを参考にして下さい。

Metricの作成

devtools-4-1-143

名前 : そのMetricを設定する名前を設定します。

成功基準: 登録したqueryのクエリ結果の成功基準で、成功または失敗に分析されます。

  • クエリ結果は、n個になることがあり、各クエリの結果ごとに成功/失敗が決定します。

  • 登録されたメトリックスコアは、(成功したクエリの結果/全クエリの結果)* 加重値で計算されます。

  • baseline > canary: baseline versionの値がcanary versionの値よりも大きい場合、成功(偏差値が負の値であるか、同じである場合に成功)

  • baseline < canary: baseline versionの値がcanary versionの値よりも大きい場合、成功(偏差値が正の値であるか、同じである場合に成功)

クエリタイプDefault

  • Label selectorのみ活用する際に使用することができます。

    Metric: 入力したPrometheus Urlの設定されたMetricリストです。

    Filter: 任意のラベル条件を入力します。

    Ex) Filterで

    kubernetes_namespace="dev" , ncp_sourcedeploy_canary="${basecanary}"
    

クエリタイプPromQL

  • クエリ: ユーザーが直接PromQLを入力して、使用することができます。

    Ex)ウェブアプリケーションのrequests成功率PromQL例示

    sum(requests_total{kubernetes_namespace="dev",custom_status="good", ncp_sourcedeploy_canary="${basecanary}"})/sum(requests_total{kubernetes_namespace="dev", ncp_sourcedeploy_canary="${basecanary}"})
    

    ==> success_rate = sum( 成功 request ) / sum( 全 request )

⑤ ${basecanary}

  • BaselineとCanaryの比較分析のために${basecanary}を予約語として提供し、クエリに該当する予約語を使用して分析する時、分析環境変数値に置換されてクエリします。

  • Ex) Metric: requests_total / Filter : ncp_sourcedeploy_canary=${basecanary} /

    canary: canaryenv, baseline: baselineenv(展開戦略の設定(Canary - 分析方法:自動> 5 参照)

[Baseline版のクエリ] requests_total{ncp_sourcedeploy_canary="baselineenv"}

[canary版のクエリ] requests_total{ncp_sourcedeploy_canary="canaryenv"}

Weight : そのMetricを適用する加重値を設定します。 1~100まで入力できます。

展開シナリオの最終確認:

devtools-4-3-144

① 前の段階で設定した展開シナリオの情報を確認します。

展開シナリオの作成ボタンをクリックして、作成を完了します。

kubernetes clusterにCI/CD環境を構築

  1. SourceDeploy商品を使用して、kubernetes clusterに継続的な展開を構成するには、展開画像がContainer Registryに格納されていなければなりません。

  2. 画像tagをlatestに設定します。 SourceDeployで自動的にlatest tagをdigest形に変更して展開をしようとするので、画像の設定が変更されなくても、正常に継続的な展開を実行することができます。

  3. SourceBuild商品とSourcePipeline商品を一緒に使用すると、手軽にCI/CD環境を構築することができます。

    • SourceBuildガイドに移動する

      • Docker imageビルド機能を使用してドッカーイメージをビルド、Container Registryに格納することができます。
      • 画像のバージョン管理とともに「latestに設定」オプションを利用して、常にlatest画像を作成することができます。
    • SourcePipelineガイドに移動する

      • Docker imageビルドが設定されたSourceBuildプロジェクトと、Kubernetes Service展開が設定されたSourceDeployプロジェクトを、パイプラインで構成してCI/CD環境を構築することができます。 -「triggerの設定」機能を利用して、SourceCommitにpushするとともに、Docker image、Kubernetes Serviceのclusterに新しいオブジェクトを展開して、サービスを運営することができます。

Kubernetesクラスタにオブジェクトを展開する時の注意事項

  • マニフェストが複数ある場合、1つでも失敗すると、すべてのオブジェクトがロールバックされます。
  • オブジェクトを更新する際は、同じ名前空間への更新のみ可能です。
  • オブジェクトの更新ではない、新しいオブジェクトを展開する際、rolling update戦略を使用して下さい。 ブルー/グリーン、Canary戦略で、新しいオブジェクトの展開はできません。
  • マニフェストのkindに関係なく、SourceDeployは展開戦略メカニズムに基づいて展開を行います。
  • ブルー/グリーンの更新戦略で、展開時に新しいバージョン(Green)のオブジェクトが展開されるため、オブジェクト名が変更されます。 オブジェクト名が変更されても、SourceDeployで展開すれば、マニフェストを修正しなくても持続的な展開が可能です。 ただし、当該マニフェストを利用してkubectl applyなどを手動で展開して、既にある名前のオブジェクトが作成される場合、更新するオブジェクトを特定することができないため、SourceDeployでの持続的な展開が不可能になります。
  • Replica Set、Replication Controllerと同じ種類のオブジェクトは、更新がされてもk8s specにより、画像が更新されません。 よって、k8s推奨のように、Deploymentのご利用をおすすめします。 (https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/) (https://kubernetes.io/ko/docs/concepts/workloads/controllers/replicationcontroller/)

展開を実行する(展開の実行管理者が設定されていない場合)

Step 1.展開プロジェクトの選択

devtools-4-3-123

① 展開プロジェクト名を選択して、展開実行ページに移動します。

展開に移動ボタンをクリックして、展開実行ページに移動します。

Step 2.展開シナリオの選択と実行

devtools-4-3-124

① 展開を実行する展開シナリオを選択します。

② 展開シナリオの基本情報と展開環境を確認できます。

③ 展開シナリオに設定された展開の設定(展開ファイル、展開コマンド、ロールバックの可否)を確認し、変更することができます。

  • このページで変更した展開の設定は保存されず、その展開で一度だけ適用されます。

展開を始めるボタンをクリックして、展開を実行します。

Step 3.展開ログの確認

展開ターゲットが、ServerまたはAuto Scalingで、かつ展開戦略が基本の場合

devtools-4-3-125

① 展開を実行すると、作業結果ページに移動します。

② 実行した展開の状態を確認できます。

③ 設定したコマンドがサーバで実行され、発生するログを確認することができます。

  • 展開ログは、展開サーバの下のパスに保存されます。 下のパスを削除し、展開ログを確認することができます。
/var/sourcedeploy/log
  • 展開ログは、最大30日まで保存します。

④ 展開の途中で取り消すこともできます。

  • 展開を取り消すと、現在実行中のフェーズまで進み、それ以降のフェーズは行われません。
展開ターゲットがAuto Scalingで、かつ展開戦略がブルー/グリーンの場合

devtools-4-3-145

① 展開を実行すると、作業結果ページに移動します。

② 実行した展開の状態を確認できます。

③ 各展開フェーズ別のログを確認することができます。

  • 展開の準備: ブルー/グリーンの展開を実行するために必要なプロセスを実行します。

    • 新規Auto Scaling Groupの作成
    • 新規Auto Scaling Group内のサーバ作成完了の待機
    • 新規Auto Scaling Group内のサーバに対してSourceDeploy Agentの接続確認
  • 新規グループに展開: 新規Auto Scaling Group内に作成されたサーバに展開します。 コマンドは順次実行されます。

    • 展開ログは、展開サーバの下のパスに保存されます。 下のパスを削除し、展開ログを確認することができます。
    /var/sourcedeploy/log
    
    • 展開ログは、展開サーバで最大30日まで保存します。
  • 新規グループを検証: 新規Auto Scaling Group内に作成されたサーバーを、ロードバランサに接続し、ロードバランサのヘルスチェックが正常であることを確認します。 すべてのヘルスチェックを成功すれば、次のフェーズに進みます。 タイムアウト(1時間)内にヘルスチェックが失敗した場合、展開は失敗として終了します。

  • 展開仕上げ: ブルー/グリーンの展開を完了した後、仕上げの段階を進めます。

    • 「既存グループ内サーバ」に設定された値に基づいて、既存のAuto Scaling Group内のサーバ処理
    • 既存のAuto Scaling Groupに接続されたCloud Insightイベントが存在する場合、イベントのコピー

④ 展開の途中で取り消すこともできます。

  • 展開を取り消すと、現在実行中のフェーズまで進み、それ以降のフェーズは行われません。
  • 取消し、もしくは展開を失敗した時、ブルー/グリーン展開で作成されたAuto Scaling Groupや、サーバは自動返却されません。 不要の場合、直接該当商品で返却/削除する必要があります。
展開ターゲットがKubernetes Serviceの場合

devtools-4-3-146

① 展開の途中で取り消すことができません。

Canaryの展開/取消を設定します。(分析: 手動)

devtools-4-3-147

① ユーザーが直接、Baseline、Canary版のアプリケーションを分析した後、Canaryの展開/取消を決定します。

  • 展開: Canary版が展開され、Baseline、Canary版のアプリケーションが終了します。
  • 取消: Canary版が展開されず、Baseline、Canary版のアプリケーションが終了します。

Canary分析レポートを確認

devtools-4-1-148

devtools-4-1-149

① 分析レポートは、ユーザーのPrometheusが設定された保存周期 の間だけ確認できます。

② シナリオで設定した分析時間、分析周期で分析フェーズが決められます。分析データは蓄積されて、分析されています。

  • Ex)分析時間: 10分、分析周期: 3分

    ==>10分間に3分ごと合計4回の分析フェーズのスコアが出て、最後の分析フェーズの時間は1分である。

分析フェーズスコアであり、そのスコアがPass(分析成功スコア)スコア以上になれば成功です。 そのスコアが失敗した場合、次の分析は行われません。

  • 分析フェーズスコアの計算方法

    • Metricスコア: (成功したクエリの結果/全クエリの結果)*(メトリック加重値)

      • Metric Name : success_rate1

        成功クエリ結果 : 2個(#1, #3)

        全クエリ結果 : 3個(#1, #2, #3)

        Weight : 30

        Metricスコア: ( 2 / 3 ) * 30 = 20

      • Metric Name : success_rate2

        成功クエリ結果 : 1個(#1)

        全クエリ結果 : 1個(#1)

        Weight : 70

        Metricスコア: ( 1 / 1 ) * 70 = 70

  • 分析フェーズスコア : 20 + 70 = 90

④ 分析の開始時間/終了時間です。

⑤ シナリオで設定したPass(分析成功スコア)、Step(Metric収集周期)です。

⑥ シナリオで設定したMetricとWeight(加重値)であり、Metricをクリックすると、Canary分析結果が出ます。

Canary分析の結果

  • Elementの結果: Prometheusクエリ結果からのデータのelement値であり、BaselineとCanaryのクエリ結果elementが同じなら、正常な分析が行われます。

  • 偏差: Baseline値と比べたCanary値の増加/減少率です。

  • 結果: baseline基準のcanaryの偏差で計算され、メトリック設定で設定した成功基準に基づいて、結果(成功/失敗)が決定されます。

    • baseline版の結果とcanary版の結果が同じ場合、成功と決定され、5%の誤差の範囲があります。 つまり、-5 <= 偏差 <= +5 の場合成功と決定されます。
    • 種類Baseline-[Baseline版クエリ] Canary- [Canary版クエリ]のクエリ結果です。
    • 開始時間/終了時間: 分析の開始時間/終了時間です。
    • Count: 分析時間の間に出てきた実際のデータ数
    • AVG: データの平均値
    • MAX: データの最大値
    • MIN: データの最小値
Elementの確認

devtools-4-1-150

① 確認したいElementをクリックします。

② Elementの結果を確認できます。

展開を実行する(展開の実行管理者が設定されている場合)

Step 1.展開プロジェクトの選択

devtools-4-3-123

① 展開プロジェクト名を選択して、展開実行ページに移動します。

展開に移動ボタンをクリックして、展開実行ページに移動します。

Step 2.展開シナリオの選択と展開承認のリクエスト

devtools-4-3-126

① 展開を実行する展開シナリオを選択します。

② 展開シナリオの基本情報と展開環境を確認できます。

③ 展開シナリオに設定された展開の設定(展開ファイル、展開コマンド、ロールバックの可否)を確認し、変更することができます。

  • このページで変更した展開の設定は保存されず、その展開で一度だけ適用されます。

展開承認リクエストボタンをクリックして、展開の実行を展開実行管理者に依頼します。

  • 展開は、設定された展開承認の最小人員を満たすと、自動的に展開が実行されます。

Step 3.展開承認の状態を確認する(展開実行管理者以外のアカウント)

devtools-4-3-127

作業結果ページに移動します。

② 承認リクエストした展開の確認ボタンをクリックします。

③ 承認リクエストした展開の承認状態を確認できます。

Step 3.展開を承認、または却下する(展開実行管理者のアカウント)

devtools-4-3-128

作業結果ページに移動します。

② 承認が必要な展開の承認ボタンをクリックします。

③ 承認が必要な展開の情報を確認し、その展開の承認あるいは却下を選択することができます。

  • 展開は、設定された展開承認の最小人員を満たすと、自動的に展開が実行されます。

設定の変更

展開プロジェクトの設定の変更

devtools-4-3-114

① 設定を変更する展開プロジェクトを選択します。

設定の変更ボタンをクリックします。

  • 展開プロジェクトの設定を変更するには、ログインしているアカウントがお客様のアカウントか、NCP_INFRA_MANAGER権限、あるいは選択した展開プロジェクトに対してADMIN権限を持っているサブアカウントが必要です。
  • NCP_INFRA_MANAGER権限は、コンソールのManagement > Sub Accountメニューから割り当てることができます。

devtools-4-1-115

③ 選択したビルドプロジェクトに設定されているサブアカウントが、自動で追加されます。

④ 展開プロジェクトを使用するユーザーを変更することができます。

⑤ 展開実行管理者に関するユーザーを変更することができます。

⑥ 変更事項を適用します。

展開Stageの設定変更

devtools-4-3-116

① 設定を変更する展開Stageを選択します。

設定の変更ボタンをクリックします。

  • 展開Stageの設定を変更するには、ログインしているアカウントがお客様のアカウントか、NCP_INFRA_MANAGER権限、あるいは選択した展開プロジェクトに対してADMIN権限を持っているサブアカウントが必要です。
  • NCP_INFRA_MANAGER権限は、コンソールのManagement > Sub Accountメニューから割り当てることができます。

devtools-4-1-117

③ 展開Stageに設定されている展開環境を変更することができます。

④ 変更事項を適用します。

展開シナリオの設定変更

devtools-4-3-118

① 設定を変更する展開シナリオを選択します。

設定の変更ボタンをクリックします。

  • 展開シナリオの設定を変更するには、ログインしているアカウントがお客様のアカウントか、NCP_INFRA_MANAGER権限、あるいは選択した展開プロジェクトに対してADMIN権限を持っているサブアカウントが必要です。
  • NCP_INFRA_MANAGER権限は、コンソールのManagement > Sub Accountメニューから割り当てることができます。
展開ターゲットが、ServerまたはAuto Scalingの場合

devtools-4-1-119

③ 展開シナリオの説明を変更できます。

④ 展開ファイルを変更できます。

⑤ 展開コマンドを変更できます。

⑥ 展開が失敗したとき、ロールバックを行うかどうかを変更することができます。

⑦ 変更事項を適用します。

展開ターゲットがKubernetes Serviceの場合

devtools-4-1-152

③ 展開シナリオの説明を変更できます。

④ SourceCommitのリポジトリを変更できます。

⑤ マニフェストファイルを変更できます。

⑥ 展開戦略を変更できます。

⑦ 変更事項を適用します。

削除

展開プロジェクトの削除

devtools-4-3-120

① 削除した展開プロジェクトを選択します。

[削除] ボタンをクリックします。

  • 展開プロジェクトを削除するには、ログインしているアカウントがお客様のアカウントか、NCP_INFRA_MANAGER権限、あるいは選択した展開プロジェクトに対してADMIN権限を持っているサブアカウントが必要です。
  • NCP_INFRA_MANAGER権限は、コンソールのManagement > Sub Accountメニューから割り当てることができます。
  • 選択した展開プロジェクト内で展開が行われている場合には、削除ができません。 行われている展開がない場合にのみ、展開プロジェクトを削除することができます。

展開Stageの削除

devtools-4-3-121

① 削除する展開Stageを選択します。

[削除] ボタンをクリックします。

  • 展開Stageを削除するには、ログインしているアカウントがお客様のアカウントか、NCP_INFRA_MANAGER権限、あるいは選択した展開プロジェクトに対してADMIN権限を持っているサブアカウントが必要です。
  • NCP_INFRA_MANAGER権限は、コンソールのManagement > Sub Accountメニューから割り当てることができます。
  • 選択した展開プロジェクト内で展開が行われている場合には、削除ができません。 行われている展開がない場合にのみ、展開プロジェクトを削除することができます。

展開シナリオの削除:

devtools-4-3-122

① 削除する展開シナリオを選択します。

[削除] ボタンをクリックします。

  • 展開シナリオを削除するには、ログインしているアカウントがお客様のアカウントか、NCP_INFRA_MANAGER権限、あるいは選択した配布プロジェクトに対してADMIN権限を持っているサブアカウントが必要です。
  • NCP_INFRA_MANAGER権限は、コンソールのManagement > Sub Accountメニューから割り当てることができます。
  • 選択した展開プロジェクト内で展開が行われている場合には、削除ができません。 行われている展開がない場合にのみ、展開プロジェクトを削除することができます。

関連情報に移動する

以下のガイドで関連情報を確認できます。

に対する検索結果は~件です。 ""

    に対する検索結果がありません。 ""

    処理中...