diff --git a/_data/authors.yml b/_data/authors.yml index dc58aca..19b6351 100644 --- a/_data/authors.yml +++ b/_data/authors.yml @@ -167,3 +167,20 @@ Dave Placeholder: - label: "Blogsite" icon : "fas fa-fw fa-link" url : "http://monsieurfromageblog.com" # Author details. + +Arjun Bahree: + name : Arjun Bahree + bio : Cloud Architect | Advisor | Developer.
Infrastructure/IaC, Native Apps, Automation, Containers, OSS, DevOps, Networking, Storage, Compute ... + avatar : images/authors/bahree.jpg + email : arjun.bahree@gmail.com + twitter : arjunbahree + github : bahreex + linkedin : bahree + links: + - label: "Blogsite #1" + icon : "fas fa-fw fa-link" + url : "http://azurepost.com" + - label: "Blogsite #2" + icon : "fas fa-fw fa-link" + url : "http://cloudchakra.com" + \ No newline at end of file diff --git a/automation/arm/lab2.md b/automation/arm/lab2.md index 9c99dfb..6d4cf79 100644 --- a/automation/arm/lab2.md +++ b/automation/arm/lab2.md @@ -51,13 +51,18 @@ You will find yourself needing to check the most recent ARM reference informatio There are three short URLs that you really need to remember from these labs, and that was the first of them. -The full pathing to take you direct to individual resource type pages is `https://docs.microsoft.com/en-gb/azure/templates/_resource.provider_/_type_`, so you can quickly go straight to the right page. +The full pathing to take you direct to individual resource type pages is in the format `https://docs.microsoft.com/azure/templates/Resource.Provider/type`. -Take a look at the reference page for the [Microsoft.Storage/storageAccounts](https://docs.microsoft.com/en-gb/azure/templates/microsoft.storage/storageaccounts) and you will see that the API version is far newer than June 2015, and includes newer features such as v2 storage accounts. You will find that some of the property values are not usefully described in the reference pages, and the documentation does not always provide good examples. We will see how we can use the resource group level export to work around that later. +* Go to +* Append the URL in the address bar with `Microsoft.Storage/storageAccounts` and hit enter -Note that only the most recent API version is shown in the reference documentation, and there is sometimes a small lag between a new API being released and the documentation catching up. There is a huge amount of innovation on the Azure platform so this is a neverending task. If you do need to look backwards then there is a full list of the various [API versions](https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-manager-supported-services#supported-api-versions). You can also look at the [schemas](https://github.com/Azure/azure-resource-manager-schemas/tree/master/schemas) directly on GitHub. If you are feeling masochistic then you can use the schemas to check differences in API releases. +You will be taken straight to the most recent version of the [Microsoft.Storage/storageAccounts](https://docs.microsoft.com/azure/templates/Microsoft.Storage/storageAccounts) API page. -For Azure Stack there is a new root element called [apiProfile](https://docs.microsoft.com/en-us/azure/azure-stack/user/azure-stack-version-profiles) which can be used to globally set the apiVersion across public Azure Cloud and Azure Stack deployments. When this is used then apiVersion does not need to be specified within the resource objects. +You will notice that the API version is far newer than the snippet you have been using, and includes newer features such as v2 storage accounts. These pages are auto-generated from the [schemas](https://github.com/Azure/azure-resource-manager-schemas/tree/master/schemas) and therefore you may find that some of the property values are not usefully described in the reference pages, and would benefit from some good examples. We will see how we can use the resource group level export to work around that later. + +Note that you can use the drop down box to select from the various iterations of the API version. + +> For Azure Stack there is a new root element called [apiProfile](https://docs.microsoft.com/en-us/azure/azure-stack/user/azure-stack-version-profiles) which can be used to globally set the apiVersion across public Azure Cloud and Azure Stack deployments. When this is used then apiVersion does not need to be specified within the resource objects. ------------------ @@ -65,8 +70,8 @@ For Azure Stack there is a new root element called [apiProfile](https://docs.mic We'll now look at different places to source templates and we'll start with exporting templates directly out of the Azure portal itself. There are a couple of ways of doing this: -1. viewing the _automation options_ prior to resource deployment -1. creating a full export of a whole resource group +1. viewing the ARM generated template prior to resource deployment using the _Download a template for automation_ link (NB. may be labelled _Automation options_ in certain resources blades) +1. Creating a full export of a whole resource group Both have their benefits and limitations and the labs will hopefully illustrate this. This is also a good lab to talk about API versions and to start utilising the reference documentation. @@ -92,7 +97,7 @@ OK, let's export an example template and parameters file. * Location: **West Europe** * Pricing tier: **F1 Free** -**_DO NOT CLICK ON THE CREATE BUTTON!_** Click on the _Automation Options_ link instead. +**_DO NOT CLICK ON THE CREATE BUTTON!_** Click on the _Download a template for automation_ link instead. This will open up the template that the portal has created on the fly. If you tab through the Template, Parameters, CLI, PowerShell, .NET and Ruby tabs then you will see the two JSON templates, plus deployment code for the various CLIs and key SDKs. @@ -176,8 +181,6 @@ Here are the example initial files: } ``` -> You may find that the portal has created the template based on the `2014-04-01-preview` version of the ARM schema. If this is the case then change it to `2015-01-01` (as above). You may also want to change the API version of the `Microsoft.Web/sites` resource to `2016-08-01` which is the current API version at the time of writing. This will remove any of the "problems" as triggered by the ARM Tools extension. - Configure VS Code to have both the azuredeploy.json and the azuredeploy.parameters.json side by side. (Use either `CTRL`+`ALT`+`<|>`, or drag the parameters tab towards the right hand side until the snap area is shown.) ![vscode](/automation/arm/images/lab2-3-vscode.png) @@ -202,8 +205,6 @@ Quick guide: 1. Strip down the parameters file to only the required webAppName parameter value 1. Test -> Note that the "name" parameter as generated from the portal would cause a problem for PowerShell submissions. This is because the PowerShell New-AzResourceGroupDeployment cmdlet automatically creates new switches on the fly based on the parameter names, but these must not clash with existing switches. As `-name` is one of those switches you will see an error. Changing it to 'webAppName' avoids this. - It is worth going through the pain of this refactoring section as it is really good practice for you. If you do get stuck then the video below shows the files being edited. @@ -214,7 +215,7 @@ Here is the resulting azuredeploy.json: ```json { - "$schema": "http://schema.management.azure.com/schemas/2014-04-01-preview/deploymentTemplate.json#", + "$schema": "http://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#", "contentVersion": "1.0.0.0", "parameters": { "webAppName": { @@ -260,8 +261,6 @@ Here is the resulting azuredeploy.json: } ``` -> Note that we could also change the schema from _2014-04-01-preview_ to _2015-01-01_ - And the matching azuredeploy.parameters.json file should only have one parameter: ```json @@ -297,13 +296,13 @@ You will also see implicit dependencies, where resource properties in one resour It is possible to export a whole resource group definition as ARM JSON. This is very verbose and it will hardcode many of the property values. Frankly it is not pretty and is of limited use. However, one thing it is very useful for is to compare the files before and after a manual change to see how that can be driven using ARM. 1. Open up the blade for the lab2 resource group once it has successfully deployed -1. Click on Export Template in the Settings section +1. Click on _Export Template_ in the Settings section 1. Copy out the JSON into a new file within VS Code 1. Open up the Web App blade 1. Select CORS in the API section 1. Enter in a valid origin site and port, e.g. `http://azurecitadel.github.io:1976` into the Allowed Origins field 1. Click on Save -1. Go back up to the resource group and click on Export Template again +1. Go back up to the resource group and click on _Export Template_ again 1. Copy out the "after" version of the JSON and paste it into another new file in VS Code 1. Type `CTRL-SHIFT-P` to bring up the Command Palette 1. Use the 'File: Compare Active File With...' to see the difference @@ -438,4 +437,4 @@ Clean up your lab2 resource group containing the web app before moving on. From In the next section we will handle secrets and securetext. -[◄ Lab 1: Basics](../lab1){: .btn .btn--inverse} [▲ Index](../#index){: .btn .btn--inverse} [Lab 3: Shh Secrets ►](../lab3){: .btn .btn--primary} \ No newline at end of file +[◄ Lab 1: Basics](../lab1){: .btn .btn--inverse} [▲ Index](../#index){: .btn .btn--inverse} [Lab 3: Secrets ►](../lab3){: .btn .btn--primary} diff --git a/automation/arm/lab3.md b/automation/arm/lab3.md index dd0808e..45deba6 100644 --- a/automation/arm/lab3.md +++ b/automation/arm/lab3.md @@ -209,8 +209,10 @@ OK, we've addressed the password. Let's start turning the template itself into * subnetName, defaulting to "Subnet" * subnetPrefix, defaulting to "10.0.0.0/24" 1. Remove the corresponding variables - * vnetName is replacing virtualNetworkName - * vnetPrefix is replacing addressPrefix + * vnetName parameter is replacing virtualNetworkName variable + * vnetPrefix parameter is replacing addressPrefix variable + * subnetName parameter is replacing subnetName variable + * subnetPrefix parameter is replacing subnetPrefix variable 1. Remove the default for the vmName 1. Change the value for the nicName variable to be the vmName with '-nic' at the end 1. Change the publicIPAddressName variable to pipName diff --git a/images/authors/bahree.jpg b/images/authors/bahree.jpg new file mode 100644 index 0000000..a8a2ac5 Binary files /dev/null and b/images/authors/bahree.jpg differ