Latest posts by Graham Beer (see all)
- AWS vCPU-based On-Demand EC2 instance limits - Fri, Oct 25 2019
- Remove users and groups in AWS Identity and Access Management (IAM) with PowerShell - Mon, Aug 26 2019
- IAM administration in AWS with PowerShell - Mon, Aug 12 2019
In part one of this two-part series of articles, I will be looking at how to create an account in Azure to create a Service Endpoint in VSTS to allow a connection, Azure Resource Manager templates, and using a YAML configuration file in VSTS to create a build.
Setting up an account in Azure ^
The first step, to allow VSTS to build in Azure, is to setup a Service Endpoint. The account needs to be created in Azure first, before adding the required detail to the Service Endpoint in VSTS.
VSTS requires the following information to create a Service Endpoint:
Service Principal Client ID
Service Principal Key
Log in to your Azure portal and, from the blade, click Subscriptions. Here you can obtain your Subscription ID and Name. To get the Tenant ID, open the Azure Active Directory blade and select Properties. The Directory ID field is copied to populate the Tenant ID. The Tenant ID is a reference to the Azure Active Directory instance within the subscription.
For the Service Principal details, we need to create an application and register it within Azure Active Directory. This step is basically an account allowing VSTS to authenticate with Azure Active Directory with permissions to Azure. While still in Azure Active Directory, open the App Registration menu from the blade and select New Application registration.
Add a name, leave the application type as Web App / API, and make the Sign-on URL unique. (Apart from being unique, the Sign-on URL can be any value.)
Under the new application properties, the Application ID will be shown. Make a note of this, as it will be used for the Service Principal Client ID field.
The last value we require is the Service Principal Key. Open the Keys menu in your newly created application and, under an empty field, type a descriptive name for the key you are creating. Set the expiration time for an appropriate amount of time and then click Save. The application’s key is displayed, so take a copy of the key at this point, as there is no way to go back and view this key again.
The last part to this is to give VSTS permissions on Azure so we can build the Virtual Machine and its components. Open the Subscriptions blade and click on your subscription, then select Access control (IAM) menu. Next, click on Add, and for the role, choose Contributor. For the Select field, type in the application name we created at the start in Azure Active Directory. Once this is done, click Save at the bottom of the screen. We now have our account in Azure, and the details we captured along the way that we need to add to VSTS.
Add Service Endpoints in Visual Studio Team Services ^
From the blue bar at the top of the screen inside VSTS, click on the cog icon and choose Services.
On the left side of the screen, open New Service Endpoint and choose Azure Resource Manager. When the dialogue box appears, click on the highlighted link; use the full version of the endpoint dialog.
Add Azure Resource Manager Service Endpoint
From the details we collected in the first part of this article, Setting up an account in Azure, go ahead and fill in form. Before clicking on OK, test that everything is set up right by using the Verify connection option. If a green tick is shown, carry on. Make a note of your connection name for later, as this will be added to our YAML file.
Azure Resource Manager templates ^
The two JSON files we will be working with are template.json and parameters.json. The template.json file is set up to build a Windows 2016 Datacenter server.
The best explanation for parameters.json file is defined on the Microsoft Azure pages:
In the parameters section of the template, you specify which values you can input when deploying the resources. These parameter values enable you to customize the deployment by providing values that are tailored for a particular environment (such as dev, test, and production). You do not have to provide parameters in your template, but without parameters, your template would always deploy the same resources with the same names, locations, and properties.
The great thing with Azure templates is that you can run through the GUI wizard of any configuration and, before creating, have the option to view and save in JSON files! This is such a great feature, as you can reuse the files to build in the future with a few tweaks to a JSON parameter file. Plus, it’s a great source to use for documenting your builds.
These two JSON files and the YAML file I will talk about next are hosted in my GitHub pages.
YAML in VSTS ^
Having the ability to use YAML in VSTS gives the advantages of configuration as code. For example, I can use version control to easily identify and fix changes made. The YAML file I’m using to deploy our templates is as follows:
- repo: self
- task: AzureResourceGroupDeployment@2
location: 'West Europe'
overrideParameters: '-adminPassword $(Password)'
The first line uses VSTS’ built-in variables to set a naming convention for our build. The resource step is using the VSTS repository, and the queue is stating the agent to use. I’ve added one variable to the YAML file—the Resource Group Name. Anything that is built within Azure requires a Resource Group.
We set a task and the inputs. With the Azure subscription, we add the Service Endpoint previously created, which has the permissions to access Azure (NOTE: My Service Endpoint was named MyAzure). Also, through the file, we set a location for Azure to build the server, along with our JSON files.
For the Admin password of the server we are creating, I’ve stated a variable name. When I set up the task in VSTS, I will create a variable secret, which will hold my password securely. The variable in the YAML file will reference the VSTS variable.
Lastly, I’ve enabled our server deployment to be configured with WinRM for remoting. Once we have our YAML file, we can easily make small changes for any future deployments.
VSTS new project ^
Open Visual Team Studio Services. If you don’t have an account, you can sign up for free and follow along with this guide if you wish. On the main account page once you have signed in, select New Team Project. Give the project a name and leave the version control and work item process as the default values. Click Create, and after a few moments, we will have a new project to work with.
The first screen you will see is Get started with your new project! This is about creating a repository for our code with version control. The default value we accepted on the New Team Project was git for our version control. We will be using Visual Studio Code with the extension Visual Studio Team Services, which allows you to monitor your builds and manage your pull requests and work items for your TFVC or Git source repositories.
From the link under Clone to your computer, make a copy of the URL:
Click Generate Git credentials, and from there, open the link Create a personal access token.
We need to create a new token, so click on Add. Provide a description and an expiration time.
Under Authorized Scopes, choose Selected scopes and enable the following:
- Build (read),
- Code (read, write, and manage)
- Work items (read and write)
Once completed, click on Create token. Make a note of the token, as you can only capture it once.
Enable YAML Preview Feature in VSTS ^
Before creating a local repository, let’s enable the YAML feature to create our build. Select your profile from the top right-hand corner of the screen and click on Preview features. Make sure you change the drop-down box from for me to for this account, then enable Build YAML definitions.
In the second article of this two-part series, I will be looking at integrating VSCode with Visual Studio Team Services to setup source control and defining our build with YAML to create our Windows Server and configuration in Azure!