パイプラインを使用して Bicep ファイルをデプロイする
基本的なパイプラインを作成できたので、Bicep ファイルをデプロイするようにパイプラインを設定する準備ができました。 このユニットでは、パイプラインから Bicep コードをデプロイする方法と、デプロイ ステップを設定する方法について説明します。
注意
このユニットのコマンドは、概念を説明するために示されています。 コマンドはまだ実行しないでください。 ここで学習した内容をすぐに練習します。
サービス接続
ご自身のコンピューターから Bicep ファイルをデプロイするときは、Azure CLI または Azure PowerShell を使用します。 コードをデプロイする前に、Azure にサインインします。 通常は、ツールによって、ブラウザーにメール アドレスとパスワードを入力するように求められます。 資格情報の検証後、リソースをデプロイするためのアクセス許可が確認され、ツールを使用して Bicep ファイルをデプロイできるようになります。
パイプラインによるデプロイには、認証も必要です。 パイプラインは人による介入なしで実行されるので、パイプラインはサービス プリンシパルを使用して Azure に対する認証を行います。 サービス プリンシパルの資格情報は、"アプリケーション ID" とシークレット (通常はキーまたは証明書) で構成されます。 Azure Pipelines では、"サービス接続" を使用してこれらの資格情報を安全に格納し、パイプラインで使用できるようにします。 サービス接続には、デプロイ先の Azure 環境をパイプラインで識別するのに役立つその他の情報もいくつか含まれています。
ヒント
このモジュールでは、Azure DevOps を使用して、サービス接続の作成時にサービス プリンシパルを自動的に作成します。 「サービス プリンシパルを使用して Azure デプロイ パイプラインを認証する」モジュールでは、サービス プリンシパルのしくみや、それを作成し、ロールを割り当て、管理する方法など、サービス プリンシパルについてさらに詳細に説明されています。
サービス接続を作成するときに、接続の名前を指定します。 ステップでは、この名前を使用してサービス接続を参照します。そのため、パイプライン YAML コードにシークレット情報を含める必要はありません。
パイプラインが起動すると、デプロイ ステップを実行するエージェントから、その資格情報を含むサービス接続にアクセスできます。 パイプライン ステップでは、お客様が自分でサインインするのと同様に、その資格情報を使用して Azure にサインインします。 次に、ステップで定義されているアクションによって、サービス プリンシパルの ID が使用されます。
デプロイ ステップを実行するために必要なアクセス許可がサービス プリンシパルに付与されているようにする必要があります。 たとえば、リソースがデプロイされるリソース グループの共同作成者ロールをサービス プリンシパルに割り当てる必要があるかもしれません。
警告
サービス プリンシパルの資格情報を YAML ファイルに格納した後、az login
コマンドを使用してサインインする方が簡単であるように思われるかもしれません。 この方法を使用してサービス プリンシパルを認証することは避けてください。 YAML ファイル内の資格情報はクリア テキストで格納されます。 リポジトリにアクセスできるユーザーは、だれでもその資格情報を表示して使用することができます。 Azure DevOps 組織とプロジェクトへのアクセスを制限していても、だれかがリポジトリをクローンするたびに、資格情報を含む YAML ファイルがその人物のコンピューター上に作成されます。 パイプラインから Azure を操作する場合は、常にサービス接続を使用することが重要です。 サービス接続では、他のセキュリティとアクセスの制御機能も提供されます。
サービス接続は Azure DevOps プロジェクト内に作成されます。 1 つのサービス接続を複数のパイプラインで共有できます。 ただし、通常は、各パイプラインとデプロイする各環境ごとにサービス接続と対応するサービス プリンシパルを設定することをお勧めします。 この方法はパイプラインのセキュリティを強化するのに役立ち、想定とは異なる環境に誤ってリソースをデプロイしたり構成したりする可能性が少なくなります。
また、特定のパイプラインでのみ使用できるようにサービス接続を設定することもできます。 たとえば、Web サイトの運用環境にデプロイするサービス接続を作成する場合は、Web サイトのパイプラインだけがこのサービス接続を使用できるようにすることをお勧めします。 サービス接続を特定のパイプラインに制限することで、他のだれかが誤って別のプロジェクトに同じサービス接続を使用し、運用 Web サイトがダウンする可能性を防ぐことができます。
Azure リソース グループのデプロイ タスクを使用して Bicep ファイルをデプロイする
パイプラインから Bicep ファイルをデプロイする必要がある場合は、"Azure リソース グループのデプロイ" タスクを使用できます。 このタスクを使うステップを構成する方法の例を、次に示します。
- task: AzureResourceManagerTemplateDeployment@3
inputs:
connectedServiceName: 'MyServiceConnection'
location: 'westus3'
resourceGroupName: Example
csmFile: deploy/main.bicep
overrideParameters: >
-parameterName parameterValue
最初の行では、AzureResourceManagerTemplateDeployment@3
を指定しています。 これにより、このステップで使用するタスクの名前が AzureResourceManagerTemplateDeployment
であり、このタスクのバージョン 3
を使用する必要があることが Azure Pipelines に伝えられます。
Azure リソース グループのデプロイ タスクを使用するときは、inputs を指定して、操作内容をタスクに指示します。 タスクを使用するときに指定できる入力を次にいくつか示します。
connectedServiceName
は、使用するサービス接続の名前です。location
は、その値が使用されない場合でも指定する必要があります。 Azure リソース グループのデプロイ タスクでは、リソース グループを作成することもできます。作成する場合は、リソース グループを作成する Azure リージョンを指定する必要があります。 このモジュールでは、location
の入力値を指定しますが、その値は使用されません。resourceGroupName
は、Bicep ファイルをデプロイするリソース グループの名前を指定します。overrideParameters
には、デプロイ時に Bicep ファイルに渡したいすべてのパラメーター値を含めます。
タスクが開始されると、サービス接続を使用して Azure へのサインインが実行されます。 指定したデプロイがタスクによって実行されるまでに、そのタスクは認証されています。 az login
を実行する必要はありません。
Azure CLI および Azure PowerShell コマンドを実行する
Azure Pipelines の最も便利な組み込みタスクには、Azure CLI タスクと Azure PowerShell タスクの 2 つがあります。 これらのタスクを使って、1 つ以上の Azure CLI または PowerShell コマンドを実行できます。
今後の Microsoft Learn モジュールでは、Azure CLI コマンドを使用して、パイプラインからデプロイ プロセスのさらに多くの部分を自動化する方法について説明します。
変数
多くの場合、パイプラインには YAML ファイルとは別に保持したい値が含まれています。 たとえば、Bicep ファイルをリソース グループにデプロイするときは、そのリソース グループの名前を指定します。 そのリソース グループ名は、異なる環境にデプロイする場合は異なる可能性があります。 また、Bicep ファイルのパラメーターを指定する必要がある場合があります。これには、データベース サーバーのパスワードなどのシークレットが含まれます。 これらの値は、パイプライン YAML ファイルや、Git リポジトリ内の他の場所には格納しないでください。 代わりに、セキュリティを強化し、パイプライン定義を再利用可能にするために、"変数" を使用します。
変数を作成する
Azure Pipelines の Web インターフェイスには、パイプラインの変数を作成するために使用できるエディターがあります。
Azure Pipelines 変数の値をシークレットとして設定できます。 変数の値をシークレットとして設定する場合、設定した後でその値を表示することはできません。 Azure Pipelines は、パイプライン ログでシークレット値が明らかにならないように設計されています。
警告
既定では、Azure Pipelines ではパイプライン ログでシークレット変数の値が難読化されますが、同様に優れたプラクティスにも従う必要があります。 パイプライン ステップでは、シークレットを含むすべての変数の値にアクセスできます。 セキュリティで保護された変数が安全に処理されないステップがパイプラインに含まれている場合は、シークレット変数がパイプライン ログに表示される可能性があります。
ユーザーがパイプラインを手動で実行するときに、変数の値をオーバーライドできるようにすることができます。 ユーザーが指定した値は、その特定のパイプライン実行に対してのみ使用されます。 変数のオーバーライドは、パイプラインをテストするときに役立つことがあります。
パイプラインで変数を使用する
変数を作成した後は、特定の構文を使用して、パイプラインの YAML ファイル内でその変数を参照します。
- task: AzureResourceManagerTemplateDeployment@3
inputs:
connectedServiceName: $(ServiceConnectionName)
location: $(DeploymentDefaultLocation)
resourceGroupName: $(ResourceGroupName)
csmFile: deploy/main.bicep
overrideParameters: >
-environmentType $(EnvironmentType)
パイプライン定義ファイルの形式には、特別な $(VariableName)
構文が含まれています。 シークレットであるかどうかにかかわらず、この方法を使用して任意の変数を参照できます。
ヒント
上記の例では、Bicep ファイルの名前が変数に格納されていないことがわかります。 Bicep のパラメーターと同じように、すべてに対して変数を作成する必要はありません。 環境間で変化する可能性があるものと、シークレットであるものについては、変数を作成することをお勧めします。 パイプラインでは常に同じテンプレート ファイルが使用されるため、パスの変数を作成する必要はありません。
システム変数
Azure Pipelines では、"システム変数" も使用されます。 システム変数には、パイプラインで使用することができる定義済みの情報が含まれています。 パイプラインで使用できるシステム変数の一部を次に示します。
Build.BuildNumber
は、パイプライン実行の一意識別子です。 その名前にもかかわらず、Build.BuildNumber
の値は多くの場合文字列であり、数値ではありません。 この変数を使用して Azure デプロイに名前を付けることができます。これにより、トリガー元の特定のパイプライン実行までそのデプロイを追跡することができます。Agent.BuildDirectory
は、パイプライン実行のファイルが格納されている、エージェント コンピューターのファイル システム上のパスです。 この情報は、ビルド エージェント上のファイルを参照したいときに役立つことがあります。
パイプラインの YAML ファイル内で変数を作成する
Azure Pipelines の Web インターフェイスを使用して変数を作成するだけでなく、パイプラインの YAML ファイル内で変数の値を設定することもできます。 このオプションは、シークレットではない値がある場合、リポジトリに値を格納できる場合、およびファイル内の 1 か所で変数の値を保持したい場合に使用でき、パイプライン定義全体でそれらを参照できるようにすることができます。 この方法を使用すると、バージョン コントロール システムで変数への変更を追跡できます。
YAML ファイル内で変数を設定するには、variables
セクションを追加します。
trigger: none
pool:
vmImage: ubuntu-latest
variables:
ServiceConnectionName: 'MyServiceConnection'
EnvironmentType: 'Test'
ResourceGroupName: 'MyResourceGroup'
DeploymentDefaultLocation: 'westus3'
jobs:
- job:
steps:
- task: AzureResourceManagerTemplateDeployment@3
inputs:
connectedServiceName: $(ServiceConnectionName)
location: $(DeploymentDefaultLocation)
resourceGroupName: $(ResourceGroupName)
csmFile: deploy/main.bicep
overrideParameters: >
-environmentType $(EnvironmentType)
このパイプラインの例では、ServiceConnectionName
、EnvironmentType
、ResourceGroupName
、DeploymentDefaultLocation
という 4 つの変数が定義されています。
このモジュールの後半では、異なる場所で定義された変数を 1 つのパイプラインに混在させる方法について説明します。