環境の作成とターゲット設定
Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020
この記事では、Azure Pipelines 環境を作成してターゲットにする方法について説明します。 環境は、パイプラインからのデプロイを対象にできるリソースのコレクションです。
環境は、パイプラインがソフトウェアをデプロイする論理ターゲットを表します。 一般的な環境名は、開発、テスト、QA、ステージング、運用です。
Note
Azure DevOps 環境は、クラシック パイプラインでは使用できません。 クラシック パイプラインでは、 デプロイ グループ 同様の機能が提供されます。
環境には、次の利点があります。
デプロイ履歴。 パイプライン名と実行の詳細は、環境とそのリソースへのデプロイに関して記録されます。 同じ環境またはリソースを対象とする複数のパイプラインのコンテキストでは、環境の デプロイ履歴 を使用して、変更のソースを識別できます。
コミットと作業項目の追跡可能性。 環境を対象とするパイプライン実行内のジョブを表示できます。 環境に新しくデプロイされた コミットと作業項目を表示することもできます。 また、追跡可能性により、コード変更コミットまたは機能/バグ修正作業項目が環境に到達したかどうかを追跡することもできます。
診断リソースの正常性。 アプリケーションが目的の状態で機能しているかどうかを検証できます。
セキュリティ。 環境をターゲットにすることを許可するユーザーとパイプラインを指定することで、環境をセキュリティで保護できます。
環境とは、リソース自体が実際のデプロイ ターゲットを表すリソースのグループです。 Azure Pipelines 環境では現在、 Kubernetes および 仮想マシン リソースの種類がサポートされています。
YAML パイプラインが存在しない環境を参照している場合:
操作を実行しているユーザーがわかっており、アクセス許可を割り当てることができると、Azure Pipelines によって環境が自動的に作成されます。
Azure Pipelines に、外部コード エディターからの YAML 更新など、操作を実行しているユーザーに関する情報がない場合、パイプラインは失敗します。
前提条件
環境を追加するには、次の前提条件が必要です。
- Azure DevOps 組織とプロジェクト。
- プロジェクト内の環境の Creator ロール。
環境の作成
最初の環境を作成するには:
https://dev.azure.com/{yourorganization}で Azure DevOps 組織にサインインし、プロジェクトを開きます。[パイプライン] >[環境]>[環境の作成] を選択します。
環境の情報を入力し、[作成] を選択します。 後で既存の環境にリソースを追加できます。
ヒント
空の環境を作成し、デプロイ ジョブから参照して、環境に対するデプロイ履歴を記録できます。
Azure Pipelines を使用して環境にデプロイできます。 詳細については、「Azure Pipelines を使用して Azure Kubernetes Service にビルドしてデプロイする」を参照してください。
デプロイ ジョブから環境をターゲットとする
デプロイ ジョブは、順番に実行されるステップのコレクションです。 次の YAML スニペットの例に示すように、デプロイ ジョブを使用して、リソースの環境グループ全体をターゲットにすることができます。 そのリソース名が指定されているため、パイプラインは myVM コンピューター上で実行されます。
- stage: deploy
jobs:
- deployment: DeployWeb
displayName: deploy Web App
pool:
vmImage: 'Ubuntu-latest'
# creates an environment if it doesn't exist
environment:
name: 'smarthotel-dev'
resourceName: myVM
resourceType: virtualMachine
strategy:
runOnce:
deploy:
steps:
- script: echo Hello world
デプロイ ジョブから特定の環境リソースをターゲットとする
デプロイ ターゲットのスコープを環境内の特定のリソースに設定して、特定のリソースのデプロイ履歴を記録できます。 デプロイ ジョブの手順では、デプロイ ジョブがターゲットとするリソースからサービス接続の詳細が自動的に継承されます。
次の例では、 kubernetesServiceConnection の値は、 environment.resource 入力からタスクに自動的に渡されます。
environment:
name: 'smarthotel-dev.bookings'
strategy:
runOnce:
deploy:
steps:
- task: KubernetesManifest@0
displayName: Deploy to Kubernetes cluster
inputs:
action: deploy
namespace: $(k8sNamespace)
manifests: $(System.ArtifactsDirectory)/manifests/*
imagePullSecrets: $(imagePullSecret)
containers: $(containerRegistry)/$(imageRepository):$(tag)
Note
プライベート AKS クラスターを使用している場合は、API サーバー エンドポイントがパブリック IP アドレスを介して公開されないため、クラスターの仮想ネットワークに接続されていることを確認してください。
Azure Pipelines では、クラスターの仮想ネットワークにアクセスできる VNET 内にセルフホステッド エージェントを設定することをお勧めします。 詳細についてはプライベート クラスターに接続するための Options を参照してください。
手動承認チェックを使用する
運用環境へのデプロイを制御するために、Azure Pipelines では環境に対する手動承認チェックがサポートされています。 承認チェックは、パイプライン内のステージがリソースを使用するタイミングを制御するために、リソース所有者が使用できます。 リソース所有者は、そのリソースを使用するステージを開始する前に満たす必要がある承認とチェックを定義できます。
環境 Creator、 Administrator、 User ロールは管理できますが、 Reader ロールは承認とチェックを管理できません。 環境所有者は、承認チェックを使用してステージを実行するタイミングを手動で制御できます。 詳細については、「承認とチェックを定義する」を参照してください。
実行の詳細で環境を表示する
パイプライン実行の詳細の Environments タブには、パイプライン実行のデプロイ ジョブの対象であったすべての環境が表示されます。
![実行の詳細に [環境] を示すスクリーンショット。](media/environments-run.png?view=azure-devops-2020)
Note
Azure Kubernetes Service (AKS) プライベート クラスターを使用している場合、 Environments タブは使用できません。
デプロイ履歴を表示する
Azure Pipelines Environments セクションの Deployments タブを選択すると、デプロイ履歴を表示できます。
特定の環境をターゲットとするすべてのパイプラインからのジョブを表示します。 たとえば、それぞれが独自のパイプラインを持つ 2 つのマイクロサービスを同じ環境にデプロイできます。 デプロイ履歴は、環境に影響を与えるすべてのパイプラインを識別するのに役立ちます。また、各パイプラインによるデプロイのシーケンスを視覚化するのにも役立ちます。
ジョブの詳細をドリルダウンするには、展開ページの Changes と Work アイテム タブを選択します。 タブには、環境にデプロイされたコミットと作業項目の一覧が表示されます。 各リスト アイテムは、その展開内の新しい項目を表します。
[ Changes ] タブの最初の一覧には、その時点へのすべてのコミットが含まれます。次の一覧には、そのジョブの変更だけが含まれます。 複数のコミットが同じジョブに関連付けられている場合、 Changes タブには複数の結果があります。
複数の作業項目が同じジョブに関連付けられている場合、 作業項目 タブに複数の結果が表示されます。
セキュリティ
ユーザーのアクセス許可とパイプラインのアクセス許可を設定することで、環境をセキュリティで保護できます。
ユーザーのアクセス許可
ユーザーアクセス許可を持つ環境を作成、表示、使用、管理できるユーザーを制御できます。 Creatorには、すべての環境のスコープ、Reader、User、Administrator の 4 つのロールがあります。
環境の User アクセス許可 パネルを使用してユーザーを追加するには、承認する特定の Environment に移動し、 [その他のアクション ] アイコンを選択して、[ Security] を選択します。
Security ページの User アクセス許可 パネルで、追加を選択し、ユーザーまたはグループ適切なRoleを選択します。
ユーザーのアクセス許可 パネルで、継承されるアクセス許可を設定したり、環境のロールをオーバーライドしたりすることもできます。
| ロール | 説明 |
|---|---|
| Creator | グローバル ロール。環境ハブのセキュリティ オプションから使用できます。 このロールのメンバーは、プロジェクトに環境を作成できます。 既定では、共同作成者がメンバーとして追加されます。 環境がまだ存在しない場合に YAML パイプラインをトリガーするために必要です。 |
| Reader | このロールのメンバーは、環境を表示できます。 |
| User | このロールのメンバーは、YAML パイプラインを作成または編集するときに環境を使用できます。 |
| Administrator | このロールのメンバーは、アクセス許可の管理、環境の作成、管理、表示、使用を行うことができます。 特定の環境の場合、その作成者は既定で管理者として追加されます。 管理者は、すべてのパイプラインへの環境へのアクセスを開くこともできます。 |
重要
環境を作成するときは、作成者のみが管理者ロールを持っています。
| ロール | 説明 |
|---|---|
| Creator | グローバル ロール。環境ハブのセキュリティ オプションから使用できます。 このロールのメンバーは、プロジェクトに環境を作成できます。 既定では、共同作成者がメンバーとして追加されます。 環境がまだ存在しない場合に YAML パイプラインをトリガーするために必要です。 |
| Reader | このロールのメンバーは、環境を表示できます。 |
| User | このロールのメンバーは、YAML パイプラインを作成または編集するときに環境を使用できます。 |
| Administrator | このロールのメンバーは、環境の使用に加えて、環境の他のすべてのロールのメンバーシップを管理できます。 既定では、作成者がメンバーとして追加されます。 |
パイプラインのアクセス許可
Security ページの Pipeline アクセス許可 パネルを使用して、環境へのデプロイのためにすべてのパイプラインまたは選択したパイプラインを承認します。
環境またはリソースで開いているアクセス権を削除するには、Pipeline のアクセス許可でRestrict アクセス許可を選択します。
アクセス許可が制限されている場合は、特定のパイプラインに環境または特定のリソースへのデプロイを許可できます。 +を選択し、許可するパイプラインの一覧から選択します。
よく寄せられる質問
環境を作成しようとするとエラー メッセージが表示されるのはなぜですか?
アクセスが拒否されました: {User} にはアクションを実行するための作成アクセス許可が必要ですメッセージが表示された場合は、Organization Settings>Users に移動して、Stakeholder ロールがあるかどうかを確認します。 Stakeholder ロールは、利害関係者がリポジトリにアクセスできないため、環境を作成できません。
アクセス レベルを変更してから、環境を作成できるかどうかを確認してください。 詳しくは、「ユーザーとアクセス許可の管理に関する FAQ」をご覧ください。
環境が見つからないというエラーが発生する理由
「ジョブ XXXX: 環境 XXXX が見つかりませんでした 」というメッセージが表示された場合。環境が存在しないか、または use. が承認されていない場合、エラーの原因として考えられるいくつかの理由があります。
ランタイム パラメーターは実行時にのみ展開されるため、環境作成時には機能しません。 変数を使用して環境を作成するか、templateContext を使用してプロパティをテンプレートに渡すことができます。
Azure Pipelines には、環境を作成するユーザーに関する情報がない可能性があります。
YAML パイプライン ファイルに存在しない環境を参照すると、次のような場合に、Azure Pipelines によって自動的に環境が作成される場合があります。
- Azure Pipelines の Web エクスペリエンスで YAML パイプライン作成ウィザードを使用し、まだ作成されていない環境を参照します。
- Azure Pipelines の Web エディターを使用して YAML ファイルを更新し、存在しない環境へのリファレンスを追加した後にパイプラインを保存します。
次の場合、Azure Pipelines には環境を作成するユーザーに関する情報がないため、パイプラインは失敗します。
- 別の外部コード エディターを使用して YAML ファイルを更新します。
- 存在しない環境へのリファレンスを追加し、手動または継続的インテグレーション パイプラインをトリガーします。
以前は、すべてのプロジェクトの投稿者を環境の管理者ロールに追加することで、Azure Pipelines はこのケースを処理していました。 その後、プロジェクトのメンバーは、これらのアクセス許可を変更し、他のユーザーが環境にアクセスできないようにすることができます。 この結果を防ぐために、Azure Pipelines はこれらのジョブを失敗させるようになりました。