Skip to content

Commit a750594

Browse files
v-shilsv-shils
authored
Merge pull request #280713 from mumian/0711-merge-repo
embed the repo sample in the articles
2 parents 0cdfa36 + f593392 commit a750594

17 files changed

+1407
-71
lines changed

‎articles/azure-resource-manager/bicep/bicep-functions-files.md

Lines changed: 78 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -70,11 +70,40 @@ The contents of the file as an Any object.
7070

7171
The following example creates a JSON file that contains values for a network security group.
7272

73-
::: code language="json" source="~/azure-docs-bicep-samples/syntax-samples/functions/loadJsonContent/nsg-security-rules.json" :::
73+
```json
74+
{
75+
"description": "Allows SSH traffic",
76+
"protocol": "Tcp",
77+
"sourcePortRange": "*",
78+
"destinationPortRange": "22",
79+
"sourceAddressPrefix": "*",
80+
"destinationAddressPrefix": "*",
81+
"access": "Allow",
82+
"priority": 100,
83+
"direction": "Inbound"
84+
}
85+
```
7486

7587
You load that file and convert it to a JSON object. You use the object to assign values to the resource.
7688

77-
::: code language="bicep" source="~/azure-docs-bicep-samples/syntax-samples/functions/loadJsonContent/loadsharedrules.bicep" highlight="3,12" :::
89+
```bicep
90+
param location string = resourceGroup().location
91+
92+
var nsgconfig = loadJsonContent('nsg-security-rules.json')
93+
94+
resource newNSG 'Microsoft.Network/networkSecurityGroups@2023-11-01' = {
95+
name: 'example-nsg'
96+
location: location
97+
properties: {
98+
securityRules: [
99+
{
100+
name: 'SSH'
101+
properties: nsgconfig
102+
}
103+
]
104+
}
105+
}
106+
```
78107

79108
You can reuse the file of values in other Bicep files that deploy a network security group.
80109

@@ -112,11 +141,38 @@ The contents of the file as an Any object.
112141

113142
The following example creates a YAML file that contains values for a network security group.
114143

115-
::: code language="yml" source="~/azure-docs-bicep-samples/syntax-samples/functions/loadYamlContent/nsg-security-rules.yaml" :::
144+
```yaml
145+
description: "Allows SSH traffic"
146+
protocol: "Tcp"
147+
sourcePortRange: "*"
148+
destinationPortRange: "22"
149+
sourceAddressPrefix: "*"
150+
destinationAddressPrefix: "*"
151+
access: "Allow"
152+
priority: 100
153+
direction: "Inbound"
154+
```
116155
117156
You load that file and convert it to a JSON object. You use the object to assign values to the resource.
118157
119-
::: code language="bicep" source="~/azure-docs-bicep-samples/syntax-samples/functions/loadYamlContent/loadsharedrules.bicep" highlight="3,12" :::
158+
```bicep
159+
param location string = resourceGroup().location
160+
161+
var nsgconfig = loadYamlContent('nsg-security-rules.yaml')
162+
163+
resource newNSG 'Microsoft.Network/networkSecurityGroups@2023-11-01' = {
164+
name: 'example-nsg'
165+
location: location
166+
properties: {
167+
securityRules: [
168+
{
169+
name: 'SSH'
170+
properties: nsgconfig
171+
}
172+
]
173+
}
174+
}
175+
```
120176

121177
You can reuse the file of values in other Bicep files that deploy a network security group.
122178

@@ -153,7 +209,24 @@ The contents of the file as a string.
153209

154210
The following example loads a script from a file and uses it for a deployment script.
155211

156-
::: code language="bicep" source="~/azure-docs-bicep-samples/syntax-samples/functions/loadTextContent/loaddeploymentscript.bicep" highlight="13" :::
212+
```bicep
213+
resource exampleScript 'Microsoft.Resources/deploymentScripts@2023-08-01' = {
214+
name: 'exampleScript'
215+
location: resourceGroup().location
216+
kind: 'AzurePowerShell'
217+
identity: {
218+
type: 'UserAssigned'
219+
userAssignedIdentities: {
220+
'/subscriptions/{sub-id}/resourcegroups/{rg-name}/providers/Microsoft.ManagedIdentity/userAssignedIdentities/{id-name}': {}
221+
}
222+
}
223+
properties: {
224+
azPowerShellVersion: '8.3'
225+
scriptContent: loadTextContent('myscript.ps1')
226+
retentionInterval: 'P1D'
227+
}
228+
}
229+
```
157230

158231
## Next steps
159232

‎articles/azure-resource-manager/bicep/child-resource-name-type.md

Lines changed: 62 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -66,7 +66,24 @@ A nested resource declaration must appear at the top level of syntax of the pare
6666

6767
When defined within the parent resource type, you format the type and name values as a single segment without slashes. The following example shows a storage account with a child resource for the file service, and the file service has a child resource for the file share. The file service's name is set to `default` and its type is set to `fileServices`. The file share's name is set `exampleshare` and its type is set to `shares`.
6868

69-
:::code language="bicep" source="~/azure-docs-bicep-samples/syntax-samples/child-resource-name-type/insidedeclaration.bicep" highlight="9,12":::
69+
```bicep
70+
resource storage 'Microsoft.Storage/storageAccounts@2023-04-01' = {
71+
name: 'examplestorage'
72+
location: resourceGroup().location
73+
kind: 'StorageV2'
74+
sku: {
75+
name: 'Standard_LRS'
76+
}
77+
78+
resource service 'fileServices' = {
79+
name: 'default'
80+
81+
resource share 'shares' = {
82+
name: 'exampleshare'
83+
}
84+
}
85+
}
86+
```
7087

7188
The full resource types are still `Microsoft.Storage/storageAccounts/fileServices` and `Microsoft.Storage/storageAccounts/fileServices/shares`. You don't provide `Microsoft.Storage/storageAccounts/` because it's assumed from the parent resource type and version. The nested resource may optionally declare an API version using the syntax `<segment>@<version>`. If the nested resource omits the API version, the API version of the parent resource is used. If the nested resource specifies an API version, the API version specified is used.
7289

@@ -101,15 +118,57 @@ When defined outside of the parent resource, you format the type and with slashe
101118

102119
The following example shows a storage account, file service, and file share that are all defined at the root level.
103120

104-
:::code language="bicep" source="~/azure-docs-bicep-samples/syntax-samples/child-resource-name-type/outsidedeclaration.bicep" highlight="10,12,15,17":::
121+
```bicep
122+
resource storage 'Microsoft.Storage/storageAccounts@2023-04-01' = {
123+
name: 'examplestorage'
124+
location: resourceGroup().location
125+
kind: 'StorageV2'
126+
sku: {
127+
name: 'Standard_LRS'
128+
}
129+
}
130+
131+
resource service 'Microsoft.Storage/storageAccounts/fileServices@2023-04-01' = {
132+
name: 'default'
133+
parent: storage
134+
}
135+
136+
resource share 'Microsoft.Storage/storageAccounts/fileServices/shares@2023-04-01' = {
137+
name: 'exampleshare'
138+
parent: service
139+
}
140+
```
105141

106142
Referencing the child resource symbolic name works the same as referencing the parent.
107143

108144
## Full resource name outside parent
109145

110146
You can also use the full resource name and type when declaring the child resource outside the parent. You don't set the parent property on the child resource. Because the dependency can't be inferred, you must set it explicitly.
111147

112-
:::code language="bicep" source="~/azure-docs-bicep-samples/syntax-samples/child-resource-name-type/fullnamedeclaration.bicep" highlight="10,11,17,18":::
148+
```bicep
149+
resource storage 'Microsoft.Storage/storageAccounts@2023-04-01' = {
150+
name: 'examplestorage'
151+
location: resourceGroup().location
152+
kind: 'StorageV2'
153+
sku: {
154+
name: 'Standard_LRS'
155+
}
156+
}
157+
158+
resource service 'Microsoft.Storage/storageAccounts/fileServices@2023-04-01' = {
159+
name: 'examplestorage/default'
160+
dependsOn: [
161+
storage
162+
]
163+
}
164+
165+
resource share 'Microsoft.Storage/storageAccounts/fileServices/shares@2023-04-01' = {
166+
name: 'examplestorage/default/exampleshare'
167+
dependsOn: [
168+
service
169+
]
170+
}
171+
```
113172

114173
> [!IMPORTANT]
115174
> Setting the full resource name and type isn't the recommended approach. It's not as type safe as using one of the other approaches. For more information, see [Linter rule: use parent property](./linter-rule-use-parent-property.md).

‎articles/azure-resource-manager/bicep/deploy-github-actions.md

Lines changed: 35 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -148,7 +148,41 @@ You need to provide your application's **Client ID**, **Tenant ID**, and **Subsc
148148
149149
Add a Bicep file to your GitHub repository. The following Bicep file creates a storage account:
150150
151-
::: code language="bicep" source="~/azure-docs-bicep-samples/samples/create-storage-account/azuredeploy.bicep" :::
151+
```bicep
152+
@minLength(3)
153+
@maxLength(11)
154+
param storagePrefix string
155+
156+
@allowed([
157+
'Standard_LRS'
158+
'Standard_GRS'
159+
'Standard_RAGRS'
160+
'Standard_ZRS'
161+
'Premium_LRS'
162+
'Premium_ZRS'
163+
'Standard_GZRS'
164+
'Standard_RAGZRS'
165+
])
166+
param storageSKU string = 'Standard_LRS'
167+
168+
param location string = resourceGroup().location
169+
170+
var uniqueStorageName = '${storagePrefix}${uniqueString(resourceGroup().id)}'
171+
172+
resource stg 'Microsoft.Storage/storageAccounts@2023-04-01' = {
173+
name: uniqueStorageName
174+
location: location
175+
sku: {
176+
name: storageSKU
177+
}
178+
kind: 'StorageV2'
179+
properties: {
180+
supportsHttpsTrafficOnly: true
181+
}
182+
}
183+
184+
output storageEndpoint object = stg.properties.primaryEndpoints
185+
```
152186

153187
The Bicep file requires one parameter called **storagePrefix** with 3 to 11 characters.
154188

‎articles/azure-resource-manager/bicep/deploy-to-resource-group.md

Lines changed: 35 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -187,7 +187,41 @@ For more information, see [Management group](deploy-to-management-group.md#manag
187187

188188
To deploy resources in the target resource group, define those resources in the `resources` section of the template. The following template creates a storage account in the resource group that is specified in the deployment operation.
189189

190-
:::code language="bicep" source="~/azure-docs-bicep-samples/samples/create-storage-account/azuredeploy.bicep":::
190+
```bicep
191+
@minLength(3)
192+
@maxLength(11)
193+
param storagePrefix string
194+
195+
@allowed([
196+
'Standard_LRS'
197+
'Standard_GRS'
198+
'Standard_RAGRS'
199+
'Standard_ZRS'
200+
'Premium_LRS'
201+
'Premium_ZRS'
202+
'Standard_GZRS'
203+
'Standard_RAGZRS'
204+
])
205+
param storageSKU string = 'Standard_LRS'
206+
207+
param location string = resourceGroup().location
208+
209+
var uniqueStorageName = '${storagePrefix}${uniqueString(resourceGroup().id)}'
210+
211+
resource stg 'Microsoft.Storage/storageAccounts@2023-04-01' = {
212+
name: uniqueStorageName
213+
location: location
214+
sku: {
215+
name: storageSKU
216+
}
217+
kind: 'StorageV2'
218+
properties: {
219+
supportsHttpsTrafficOnly: true
220+
}
221+
}
222+
223+
output storageEndpoint object = stg.properties.primaryEndpoints
224+
```
191225

192226
## Deploy to multiple resource groups
193227

‎articles/azure-resource-manager/bicep/deploy-what-if.md

Lines changed: 59 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -211,7 +211,39 @@ The following results show the two different output formats:
211211

212212
To see how what-if works, let's runs some tests. First, deploy a Bicep file that creates a virtual network. You'll use this virtual network to test how changes are reported by what-if. Download a copy of the Bicep file.
213213

214-
:::code language="bicep" source="~/azure-docs-bicep-samples/samples/deploy-what-if/what-if-before.bicep":::
214+
```bicep
215+
resource vnet 'Microsoft.Network/virtualNetworks@2023-11-01' = {
216+
name: 'vnet-001'
217+
location: resourceGroup().location
218+
tags: {
219+
CostCenter: '12345'
220+
Owner: 'Team A'
221+
}
222+
properties: {
223+
addressSpace: {
224+
addressPrefixes: [
225+
'10.0.0.0/16'
226+
]
227+
}
228+
enableVmProtection: false
229+
enableDdosProtection: false
230+
subnets: [
231+
{
232+
name: 'subnet001'
233+
properties: {
234+
addressPrefix: '10.0.0.0/24'
235+
}
236+
}
237+
{
238+
name: 'subnet002'
239+
properties: {
240+
addressPrefix: '10.0.1.0/24'
241+
}
242+
}
243+
]
244+
}
245+
}
246+
```
215247

216248
To deploy the Bicep file, use:
217249

@@ -243,7 +275,32 @@ az deployment group create \
243275

244276
After the deployment completes, you're ready to test the what-if operation. This time you deploy a Bicep file that changes the virtual network. It's missing one of the original tags, a subnet has been removed, and the address prefix has changed. Download a copy of the Bicep file.
245277

246-
:::code language="bicep" source="~/azure-docs-bicep-samples/samples/deploy-what-if/what-if-after.bicep":::
278+
```bicep
279+
resource vnet 'Microsoft.Network/virtualNetworks@2023-11-01' = {
280+
name: 'vnet-001'
281+
location: resourceGroup().location
282+
tags: {
283+
CostCenter: '12345'
284+
}
285+
properties: {
286+
addressSpace: {
287+
addressPrefixes: [
288+
'10.0.0.0/15'
289+
]
290+
}
291+
enableVmProtection: false
292+
enableDdosProtection: false
293+
subnets: [
294+
{
295+
name: 'subnet002'
296+
properties: {
297+
addressPrefix: '10.0.1.0/24'
298+
}
299+
}
300+
]
301+
}
302+
}
303+
```
247304

248305
To view the changes, use:
249306

0 commit comments

Comments
 (0)