 Hi everybody, my name is Sarah Lean and I'm a Cloud Advocate at Microsoft. I've been in the IT industry for a number of years now and I'm firmly in that IT Pro or Infrastructure Engineer camp. Now I'm used to deploying servers physically, so getting my hands dirty and actually installing servers into racks. But over the years, I've transitioned from doing that into actually deploying servers via code. Recently, I've been looking at how I can automate deployment of virtual machines within Azure using GitHub Actions. Now a GitHub Actions is something that was launched at the end of 2019, and it was designed to help automate workflows in the same place that you store your code and you collaborate with others. So in this short video, I'm going to take you through the code and the steps that I took in order to use GitHub Actions to deploy my Azure virtual machine. So here we are in my GitHub repository, and we have several files and folders within it. We have the .github slash workflows folder, and we have the IAC or Infrastructure as Code slash azclifolder. Now inside these folders are several files. In the workflows folder, we have a file called workflow.yml. The workflow file is actually where we instruct the GitHub Action to carry out the steps for us. In my azclifolder, I have a file called vmcreation.ps1, and that's a PowerShell script that runs the creation for the virtual machine and the associated resources around it to be created within Azure. See, here we are in Visual Studio Code on my laptop. Now I've cloned the GitHub repo down onto my laptop so that I can work with it and the code in Visual Studio Code. You can see I have the same files and the same folders that we spoke about when we were on the GitHub website. So we take the vmcreation.ps1 file and have a look at it, we can dissect it and understand it fully. At the start, I've declared a bunch of parameters, and you can see these are things like service principal, Azure subscription name, admin login, admin password, and all of these parameters are mandatory. All of those parameters need to be there in order for this script to fully run and to be fully successful in its run. When we scroll down, we can see that there's four different sections to this script. There's a section called login, there's a section called subscription. We've got creating resource group, and we've also got create virtual machine. So if we dive into each of those four sections and have a look at what they do, the login section actually logs us into our Azure subscription, and we're using an Azure service principal to do that, and we're doing that because it's best practice. We don't want to be using our own username and password credentials here. Now, the service principal has the right permissions within our Azure subscription to be able to deploy the necessary resource group and resources. The next section of the code is picking the Azure subscription we want to deploy these resources in, because if like me, you have multiple subscriptions and access to those, you want to make sure you're actually deploying the resources in the right subscription. The third section creates our resource group and it creates it based on the name parameter and the region parameter. And we do this because the resource group has to exist before we actually create any resources within it. And the last section, as you'd imagine, is actually the section that creates our virtual machine and it creates it within that resource group that we created in the step above. Now, I'm creating a very simple Azure virtual machine here. I'm creating it based on a default Windows image. So it's using the Windows 2016 data center operating system image that is built into Azure. And I'm just passing in the server name and the username and password for it as well. You can obviously deploy virtual machines in a much more complex way, but in terms of being able to work through GitHub Actions and learn from it, we're keeping it very simple in terms of what we're deploying resource-wise. Now let's switch over and look at our workflow file and what it actually does within the GitHub Actions. Again, within this script, we have different sections. So let's break them all down and look at them individually and make sure we understand what it's doing as it goes through. So the first section is just the metadata bit. That's where we call this workflow something. The next section is declaring environment variables and we're just declaring the output path. That's just really the working space, the working directory for this GitHub Action. The next section is the triggers section and we've specified that when we push code to our GitHub repo, it triggers the GitHub Action and it works through this workflow. Now you can change this, you can do it to a pool, you can do it to a commit. There's various different triggers that you can use. Push, again, is just keeping it very basic that whenever we change the code within our GitHub repo, this action triggers. Now the next section is called jobs and it breaks up into a couple of sections itself. So the first section is where we give this job a name. So we've just called it deploy VM and we've said that we wanna run this workflow on the Windows latest platform. Now that's basically just saying that we want a Windows environment and we execute all of our code within that Windows environment. You could select Linux or you could even select macOS for it but as we have a PowerShell script, Windows makes the most sense for this example. We then start to declare the steps that we actually want this workflow to carry out. So my first step is to check out the code from this repository and that's basically taking the code from GitHub and then putting it into that workspace or working directory that we talked about earlier. Now my next section is to change my working directory. So it's specifying we need to go and look for the PowerShell script and we're just changing the working directory. So we're saying we're in the default workspace but look for a folder called IEC and then look for a folder called AZCLI and that's where our PowerShell script will be. Once it's changed, it's working directory. We want the workflow to actually run our script and we can see we've got different sections again in this step. Now we call it provision virtual machine in Azure then we declare some environment variables. You can see here I'm declaring my resource group name, my resource group region that it'll be deployed in, the virtual machine name and the admin login account name and then we say run this PowerShell command and you can see it's quite a long PowerShell command that it's actually running and it's basically saying run PowerShell and run that PowerShell script, that VM creation script that we looked at earlier and pass in these following parameters, the service principal, the service principal secret, the service principal tenant ID, the Azure subscription name, the resource group name, resource group name region, the server name, the admin login and admin password. Now you'll have noticed I only declared four of my variables or parameters within this small section in plain text. The rest are being pulled from somewhere called secrets and this is because those bits of information are really sensitive and I don't want to be sharing them with the general public. I'm happy to share my resource group name and my admin login name. Those are just fairly innocuous bits of data but there are some things like my service principal ID, service principal secret I don't want to be using and sharing with the public. So we store them in the GitHub actions secret repository. If we switch over to the GitHub website we can have a look at that. So within our GitHub repo we go into settings and then we click on secrets and we can see here that we have a bunch of secrets already stored and they're just the ones that we saw in the script. So the admin password, the service principal ID and these are all stored in an encrypted manner and that way that the GitHub actions can actually pull out the secret information but no one else can see this data. So when someone forks our GitHub repository they aren't getting the secrets it's with them. So they'd have to clear their own secrets and set up their own secrets. So if we switch back to our code we want to trigger this GitHub action and this workflow. So what I'm going to do is change the resource group region that I want this virtual machine to be deployed in and I'm going to change it to the UK South. I then use visual studio code to commit that change to my code and then I push it up into the repository. Now if we switch back to GitHub we can go into the actions tab and we can start to see that workflow working and you can see it's running here and it runs up, it sets up the job, it's checked out the repo, it's looked for the PS1 file and I've sped this up a bit but it eventually provisions the virtual machine and you can see the running times down the right hand side so it took two minutes to create that virtual machine. So if we switch over to our Azure portal we can actually see that resource. We can see that resource group, we can see it being deployed to the UK South and we can see the virtual machine and the relative technologies around it being deployed as well. And there you have it, an Azure virtual machine deployed from code that's stored in GitHub and then GitHub actions actually implementing that code. Now the way I've deployed my Azure virtual machine isn't the way I would recommend that you deploy virtual machines in a production environment but from a getting started point of view it's a great use case example to be using. Now I'll post a link in the description box to my code repository so you can give it a go yourself and please do try it out. Please do reach out as well to share your stories about GitHub actions and how you're using it within your environment to deploy your infrastructure. Thank you for watching.