How to Know if You Have Access Rights to Repo

In this post, I volition prove you how to get those ARM templates sitting in an Azure DevOps repo deploying into Azure using a pipeline. With every merge, the pipeline will automatically trigger (y'all tin can disable this) to update the deployment. In other words, a complete CI/CD deployment where you manage your infrastructure/services as code.

Annoyance

I'g not a DevOps guru. I use DevOps every day. Every deployment I do for a customer runs from JSON that I've helped write into the customers' Azure tenants. Only we accept people who are DevOps gurus and we have one seriously fancy deployment arrangement that literally just uses a DevOps pipeline as a trigger machinery and aught more. Merely I use that, not develop it. I wanted to create & run a pipeline for my own needs (Cloud Mechanix Azure training). Admittedly, I've tried this before, lost patience, and abandoned it. This time, I persisted and succeeded.

What didn't assist? The dreadful Microsoft documentation. I md, from DevOps was rubbish. Some other had deprecated YAML lawmaking (pipelines are written in YAML). A third had an example that was full of errors. OK, let's expect at blogs. Just as with many blogs on this topic, those few that were originals simply showed how to push code into an existing App Service and the rest were copies and pastes of App Services posts or bad Microsoft examples.

When it comes to tech similar this, I have the feeling that many who take the knowledge don't like to share it.

Concept

What I'1000 dealing with hither is infrastructure-equally-code (Iac). The lawmaking (Azure JSON in ARM templates) volition describe the resources and configurations of those resources that I want to deploy. In my example, it'due south an Azure Firewall and its configuration, including the rules. I accept created a repository (repo) in Azure DevOps and I edit the JSON using Visual Studio Code (VS Code), the complimentary version of Visual Studio. When I make a change in VS Code, information technology will be done in a branch of the master copy of the code. I will sync that branch to the Cloud. To merge the changes, I will create a pull request. This pull request starts a change command process, where the owners of the repo tin can review the code and decide to accept or reject the changes. If the changes are accepted they are merged into the principal copy of the code. And now the magic happens.

A pipeline is a description of a procedure that will take the main code from the repo and do stuff with it. In my case, deploy the lawmaking to a resource group in an Azure subscription. If the resources are already there, and then the pipeline volition do an update.

I will end up with an Azure Firewall that is managed as code. The rules and configuration are described in a parameter file then that'southward all that I should ordinarily need to touch. To make a rules change, I edit the parameter file and do a pull request. A security officer will review the modify and approve/reject it. If the change is approved, the new firewall configuration will be deployed. And aye, this approach could probably be used with Azure Firewall Policy resources – I haven't tested thateven so. At present I tin give people Read access only to my subscription and force all configuration changes through the pull asking review process of Azure DevOps.

Your deployment tin be any Azure resources that you can deploy using a template.

Azure Subscription

In Azure I have two resource groups:

[Resource Group] p-devops: Where I tin can do "DevOps stuff"
- [Storage Account] pdevopsstorsjdhf983: I will employ this to store admission the code that I want to deploy using the pipeline
[Resources Group] p-we1fw: Where my hub virtual network is and the Azure Firewall will be
- [Virtual Network]: p-we1fw-vnet: The virtual network that contains a subnet called AzureFirewallSubnet

Remember that storage account!

DevOps Repo

I created and configured a DevOps repo chosen AzureFirewall in a DevOps projection. There are two files in there:

[Template] azurefirewall.json: The file that will deploy the Azure Firewall
[Parameter] azurefirewall-parameters.json: The configuration of the firewall, including the rules!

New DevOps Service Connection

DevOps will need a way to authenticate with your Azure tenant and get say-so to employ your tenant, subscription, or resources group. You lot can become real fancy hither. I'm going elementary and using a feature of DevOps called a Service Connectedness, found in DevOps > [Project] >Projection Settings > Service Connections (under Pipelines):

Click New Service Connection
Select Azure Resources Manager and hit Next
Select Service Principal (Automatic) which is recommended by DevOps.
Here I selected the subscription option and the Azure subscription that my resources groups are in.
I granted access permission to all pipelines.
I named the service connection later my subscription: p-we1net.

Every bit I said, you tin can get existent fancy here considering there are lots of options.

New DevOps Pipeline

At present for the fun!

Dorsum in the projection, I went to Pipelines and created a new Pipeline:

I selected Azure Repos Git because I'thousand storing my code in an Azure DevOps (Git) repo. The contents of this repo will exist deployed by the pipeline.
I selected my AzureFirewall repo.
And so I selected "Starter Pipeline".
An editor appeared – at present you're editing a file called azure-pipelines.yml that resides in the root of your repo.

There is an option (instead of Starter Pipeline) where you choose an existing YAML file, maybe one from a binder chosen .pipelines in your repo.

Edit the Pipeline

Here is the code:

proper name: AzureFirewall.$(Date:yyyy.MM.dd)  trigger:   batch: truthful  pool:   name: Hosted Windows 2019 with VS2019  steps: - task: AzureFileCopy@3   displayName: 'Phase files'   inputs:     SourcePath: ''     azureSubscription: 'p-we1net'     Destination: 'AzureBlob'     storage: 'pdevopsstorsjdhf983'     ContainerName: 'AzureFirewall'     outputStorageUri: 'artifactsLocation'     outputStorageContainerSasToken: 'artifactsLocationSasToken'     sasTokenTimeOutInMinutes: '240' - task: AzureResourceGroupDeployment@2   displayName: 'Deploy template'   inputs:      ConnectedServiceName: 'p-we1net'      action: 'Create Or Update Resources Group'      resourceGroupName: 'p-we1fw'      location: 'westeurope'      templateLocation: 'URL of the file'      csmFileLink: '$(artifactsLocation)azurefirewall.json$(artifactsLocationSasToken)'      csmParametersFileLink: '$(artifactsLocation)azurefirewall-parameters.json$(artifactsLocationSasToken)'      deploymentMode: 'Incremental'      deploymentName: 'AzureFirewall-Pipeline'

That is a working pipeline. It is fabricated up of several pieces:

Trigger

This controls how the pipeline is started. You can set it to none to terminate automatic executions – in the early on days when you're trying to go this right, automatic runs can exist abrasive.

Pool

Your pipeline is going to run in a container. I'thousand using a stock Microsoft container based on WS2019. You can supply your own container from Azure Container Registry, but that'south getting fancy!

Task: AzureFileCopy

Now we move into the Steps. The first task is to download the contents of the repo into a storage account. Nosotros demand to exercise this because the following deployment task cannot direct access the raw files in Azure DevOps. A task is created with the human friendly name of Stage Files. At that place are a few settings to configure here:

azureSubscription: This is not the name of your subscription! Aint that tricky?! This is the name of the service connexion that authenticates the pipeline against the subscription. So that'south my service connection called p-we1net, which I happened to name afterwards my subscription.
storage: This is the storage business relationship in my target Azure subscription in the p-devops resource group. My service connexion has access to the subscription so it has access to the storage account – be careful with restricting access of the service connection to just a resources group and placing the staging storage account elsewhere.
ContainerName: This is the name of the container that will be created in your storage business relationship. The contents of the repo will exist downloaded into this container.
outputStorageUri: The URI/URL of the storage account/container will be stored in a variable which is called artifactsLocation in this example.
outputStorageContainerSasToken: A SAS token volition be created to allow temporary secure access to the contents of the container. The token volition be stored in a variable chosen artifactsLocationSasToken in this case.

Task: AzureResourceGroupDeployment

This task will take the contents of the repo from the storage account, and deploy them to a resource grouping in the target subscription. There are a few things to change:

azureSubscription: Once again, specify the proper noun of the service connection, not the Azure subscription.
resourceGroupName: Enter the name of the target resource group.
location: Specify the Azure region that you are targeting.
csmFileLink: This is the URI of the template file that you want to deploy. More in a moment.
csmParametersFileLink: This is the URI of the parameters file that you want to deploy. More in a moment.
deploymentName: I have hard-fix the deployment name and so I don't take to clean up versioned deployments from the resources group later. Every resource group has a difficult set limit on deployment objects, and with a resource such as a firewall, that could exist hit quite quickly.

csmFileLink

There are 3 parts to the cord: $(artifactsLocation)azurefirewall.json$(artifactsLocationSasToken). Together, the three parts requite the task secure access to the template file in the staging storage account.

$(artifactsLocation): This is the storage account/container URI/URL variable from the AzureFileCopy task.
azurefirewall.json: This is the name of the template file that I desire to deploy.
$(artifactsLocationSasToken): This is the SAS token variable from the AzureFileCopy task.

csmParametersFileLink

There are 3 parts to the cord: $(artifactsLocation)azurefirewall-parameters.json$(artifactsLocationSasToken). Together, the three parts give the task secure access to the parameter file in the staging storage account.

$(artifactsLocation): This is the storage account/container URI/URL variable from the AzureFileCopy task.
azurefirewall-parameters.json: This is the name of the parameter file that I want to use to customise the template deployment.
$(artifactsLocationSasToken): This is the SAS token variable from the AzureFileCopy chore.

Pipeline Execution

There are three ways to run the pipeline now:

Exercise an update (or a merge) to the master branch of the repo thank you to my trigger.
Manually run the pipeline from Pipelines.
Salvage a change to the pipeline in the DevOps editor if the principal is non locked – which will trigger option ane, to exist honest.

You lot tin open the pipeline, or celebrated runs of it, to view/track the execution:

You'll too go an email to allow yous know the condition of an ended pipeline run:

Happy pipelining!

michaelstens2000.blogspot.com

Source: https://aidanfinn.com/?p=21878