既存リソースを操作する
Bicep ファイルは、多くの場合、他の場所で作成されたリソースを参照する必要があります。 これらのリソースは、おそらく Azure portal を使用する同僚によって、手動で作成された可能性があります。 または、別の Bicep ファイルで作成されている可能性があります。 これらのリソースを参照する必要がある理由はたくさんあります。たとえば、次のようなものです。
- 他のユーザーが既に作成した Azure SQL 論理サーバーに SQL データベースを追加しています。
- 別の Bicep モジュールで定義されているリソースの診断設定を構成しています。
- サブスクリプションに手動でデプロイされたストレージ アカウントのキーに安全にアクセスする必要があります。
Bicep には、 このような状況で使用する existing
キーワードが用意されています。
注意
このユニットのコマンドは、概念を説明するために示されています。 コマンドはまだ実行しないでください。 ここで学習した内容をすぐに練習します。
既存のリソースを参照する
Bicep ファイル内で、既に存在するリソースを定義できます。 宣言は通常のリソース定義に似ていますが、いくつかの重要な違いがあります。 次の既存のリソース定義の例では、定義は、toydesigndocs
という名前のストレージ アカウントを参照しています。 ストレージ アカウントは、Bicep テンプレートがリソースをデプロイしているリソース グループと同じグループ内にあります。
resource storageAccount 'Microsoft.Storage/storageAccounts@2023-05-01' existing = {
name: 'toydesigndocs'
}
この定義を構成するものを詳しく見てみましょう。
通常のリソースの場合と同様に、
resource
キーワード、シンボリック名、およびリソースの種類と API バージョンを含めます。Note
シンボリック名は、この Bicep ファイル内でのみ使用されることに注意してください。 1 つの Bicep ファイルを使用してこのリソースを作成し、別の Bicep ファイル内のリソースを使用して
existing
リソースを参照する場合、シンボリック名は一致させる必要がありません。existing
キーワードは、このリソース定義が既に作成されたリソースへの参照であり、Bicep でそのデプロイを試行することはできないことを Bicep に示します。name
プロパティは、以前にデプロイされたストレージ アカウントの Azure リソース名です。テンプレートはリソースをデプロイしないため、
location
、sku
、またはproperties
を指定する必要はありません。 既存のリソースを参照するだけです。 プレースホルダー リソースとして考えてください。
子リソースを参照する
既存の子リソースも参照できます。 子リソースをデプロイするときに使用した構文と同じ種類の構文を使用します。 次の例は、仮想ネットワークの子リソースである既存のサブネットを参照する方法を示しています。 この例では、次に示すように、入れ子になった子リソースを使用します。
resource vnet 'Microsoft.Network/virtualNetworks@2024-01-01' existing = {
name: 'toy-design-vnet'
resource managementSubnet 'subnets' existing = {
name: 'management'
}
}
親と子の両方のリソースに existing
キーワードが適用されていることに注意してください。
その後、他の入れ子になった子リソースに使用するのと同じ ::
演算子を使用して、サブネットを参照できます。
output managementSubnetResourceId string = vnet::managementSubnet.id
リソース グループの外部にあるリソースを参照する
多くの場合、別のリソース グループ内のリソースを参照する必要があります。 たとえば、一元化されたリソース グループに仮想ネットワークがある場合、仮想マシンを独自のリソース グループのその仮想ネットワークにデプロイすることができます。 scope
キーワードを使用して、別のリソース グループ内の既存のリソースを参照することができます。 次の例は、networking-rg
リソース グループ内の toy-design-vnet
という名前の仮想ネットワークを参照する方法を示しています。
resource vnet 'Microsoft.Network/virtualNetworks@2024-01-01' existing = {
scope: resourceGroup('networking-rg')
name: 'toy-design-vnet'
}
scope
では resourceGroup()
キーワードを使用して、仮想ネットワークを含むリソース グループを参照することに注意してください。
サブスクリプションが Microsoft Entra テナント内にある限り、別の Azure サブスクリプション内のリソースを参照することもできます。 ネットワーク チームが別のサブスクリプションで仮想ネットワークをプロビジョニングした場合、テンプレートは次の例のように仮想ネットワークを参照できます。
resource vnet 'Microsoft.Network/virtualNetworks@2024-01-01' existing = {
scope: resourceGroup('A123b4567c-1234-1a2b-2b1a-1234abc12345', 'networking-rg')
name: 'toy-design-vnet'
}
scope
は resourceGroup()
キーワードを使用して、仮想ネットワークを含む Azure サブスクリプション ID (A123b4567c-1234-1a2b-2b1a-1234abc12345
) とリソース グループ名を参照していることに注意してください。
既存のリソースを参照する方法について理解したので、テンプレートでこの機能を使用する方法を見てみましょう。
既存のリソースに子リソースおよび拡張機能リソースを追加する
existing
キーワードと parent
キーワードの組み合わせを使用して、作成済みの親リソースに子リソースを追加できます。 次のテンプレート例では、既に存在するサーバー内に Azure SQL データベースを作成します。
resource server 'Microsoft.Sql/servers@2023-08-01-preview' existing = {
name: serverName
}
resource database 'Microsoft.Sql/servers/databases@2023-08-01-preview' = {
parent: server
name: databaseName
location: location
sku: {
name: 'Standard'
tier: 'Standard'
}
}
拡張機能リソースを既存のリソースにデプロイする必要がある場合は、scope
キーワードを使用できます。 existing
キーワードと scope
キーワードを使用して、既存のストレージ アカウントにリソース ロックを追加するテンプレートを次に示します。
resource storageAccount 'Microsoft.Storage/storageAccounts@2023-05-01' existing = {
name: 'toydesigndocs'
}
resource lockResource 'Microsoft.Authorization/locks@2020-05-01' = {
scope: storageAccount
name: 'DontDelete'
properties: {
level: 'CanNotDelete'
notes: 'Prevents deletion of the toy design documents storage account.'
}
}
既存のリソースのプロパティを参照する
多くの場合、リソースは他のリソースのプロパティを参照する必要があります。 たとえば、アプリケーションをデプロイする場合、別のリソースのキーまたは接続情報を認識する必要がある場合があります。 existing
キーワードを使用すると、参照しているリソースのプロパティにアクセスできます。
ヒント
出力を介してキーを渡すのではなく、この方法で他のリソースからキーを参照するのがベスト プラクティスです。 常に最新のデータが取得されます。 また、重要なことに、出力はキーなどのセキュリティで保護されたデータを処理するように設計されていません。
リソースに関する情報にアクセスする方法は、取得する情報の種類によって異なります。 セキュリティで保護されていないプロパティの場合は、通常、リソースの properties
のみを使用します。 次のテンプレート例では、Azure Functions アプリケーションをデプロイし、既に作成されている Application Insights インスタンスのアクセスの詳細 (インストルメンテーション キー) を使用します。
resource applicationInsights 'Microsoft.Insights/components@2020-02-02' existing = {
name: applicationInsightsName
}
resource functionApp 'Microsoft.Web/sites@2023-12-01' = {
name: functionAppName
location: location
kind: 'functionapp'
properties: {
siteConfig: {
appSettings: [
// ...
{
name: 'APPINSIGHTS_INSTRUMENTATIONKEY'
value: applicationInsights.properties.InstrumentationKey
}
]
}
}
}
この例では、インストルメンテーション キーは機密データと見なされていないので、リソースの properties
で使用できます。 リソースへのアクセスに使用する資格情報など、セキュリティで保護されたデータにアクセスする必要がある場合は、次のコードに示すように listKeys()
関数を使用します。
resource storageAccount 'Microsoft.Storage/storageAccounts@2023-05-01' existing = {
name: storageAccountName
}
resource functionApp 'Microsoft.Web/sites@2023-12-01' = {
name: functionAppName
location: location
kind: 'functionapp'
properties: {
siteConfig: {
appSettings: [
// ...
{
name: 'StorageAccountKey'
value: storageAccount.listKeys().keys[0].value
}
]
}
}
}
listKeys
関数が keys
配列を返すことに注目してください。 この Bicep コードは、keys
配列内の最初の項目の value
プロパティを取得します。 リソースの種類ごとに、listKeys()
関数から入手できる情報が異なります。 Visual Studio Code 用の Bicep 拡張機能では、各リソースの listKeys()
関数が返すデータを理解するのに役立つヒントが提供されます。 次のスクリーンショットは、ストレージ アカウントの listKeys()
関数の出力を示しています。
リソースによっては、他の機能もサポートされていることがあります。 Visual Studio Code の IntelliSense では、各リソースで使用可能な関数が一覧表示されます。 次のスクリーンショットでは、ストレージ アカウントから、listKeys()
に加えて listAccountSas()
および listServiceSas()
という名前の関数が提供されることがわかります。
重要
関数 listKeys()
は、リソースに関する機密データへのアクセスを提供します。 これは、デプロイを実行するユーザーまたはサービス プリンシパルが、リソースに対して適切なレベルの権限を持っている必要があることを意味します。 これは通常、 共同作成者の組み込みロール、または適切なアクセス許可を割り当てるカスタム ロールです。