AzAPI masterclass replace_triggered_by-2

hi welcome back today we're going to be talking about providers you might know that the Azure RM provider contains lots of quality of life improvements that go over and above sort of crud operations that the normal API calls would provide but what do we do when we're using a API well keep watching to find [Music] out so the use case for today's video is the subscription vending machine module it uses a API because it allows us to create a subscription and deploy

resources into it in a single apply but in using aapi we actually lose some of the cool stuff that hrrm provides one of those features has been raised as a GitHub issue on the repo and is to do with resynchronizing a virtual Network peering when the address spe changes so let's have a look into this in more detail so let's start by looking at how you actually sync the remote address space of appearing anyway now obviously in the portal you can click the button

but what's it actually doing behind the scenes enter the rest API specs for virtual Network peerings we're looking at the create or update operation here so an HTTP put if we look down here we've got a section on URI parameters most of these are self-explanatory and are part of the path but there are a couple of query uh parameters now obviously the API version which is mandatory but then you have this sync remote address space option and that is a um a query parameter if we go down here it's just set to true if

you want it to be true so okay so let's go back up and look at the examples now they've got one for sync peering so we can see what that looks like so this is a standard put to um a virtual Network peering resource you can see it's a um virtual Network called vet1 a virtual Network appearing called pier and then we have the query parameter sync remote address space equals true cool so that's how we do that now let's look at the Azure RM provider because uh apparently

that supports this feature but I didn't know how it did it until I went and had a look so this is the code from the Azure RM provider you can see it's the virtual Network peering resource code and we're looking at function resource virtual Network peering create so this is the function that's run whenever you create a virtual Network peering and this line here line 143 uh is where it's calling the client to create or update appearing and you'll notice this last parameter Network do sync remote address space true um essentially all that does

is pass uh uh a custom type which is based on a Boolean so it just passes the value true essentially to that client function um and it does it on the creation of appearing and actually it also does it on the update of appearing so this is the update function which is slightly different um it's a different function but it's the same client call and it's got that Network synchrom address space true parameter on there so actually in Azure RM you'll only synchronize the remote address space when you either create the pairing or

update the pairing interesting does that mean that it won't do it if the address bace of the remote of the reference virtual networks changes because I'm not sure the peering object would know would it I haven't tested this out but it' be interesting one to try what I want to do though is for aapi I I want to use terraform to actually query the state of the address spaces of both virtual networks on either side of the appearing and update the pairing and resynchronize appearing if the address space has

changed um let's have a look and see how we can do that so here we are in es code I've created a little demo for this and I've broken it up into two terraform States so the first state is for the Hub Network and the second state is for the uh spoke Network and the peerings so if we look at the Hub Network we can see that we create a resource Group and we create a Hub Network so virtual network

with an address space all very standard I then output the resource ID for use in the spoke module so this is the root module here we can see that in locals. TF I have oops Got The Hub Network resource ID so that's that's the Hub Network that I've just created vet Hub and I've also got the bodies for the virtual Network earings I'll explain why I've put them in locals in a minute but essentially I just done the Json and code uh to make into a string and stored

it in that local there let's have a look at I've got separate files here to make it slightly easier to read but we've got the v-net peering from The Hub so we've got the vet peing from Hub and with the parent ID is the virtual net Hub Network resource ID and the body is that local which essentially points it to the remote virtual Network that we're creating here and then we've got the appearing um from The Hub uh and to the hub both of them are in there essentially exactly the same just we've

got the two Hub body there and the from Hub body there we create the virtual Network as you'd expect and the resource Group and these are fully applied so tly um would mean that it says no changes and if I get see Hub Network and I go see apply then there are also no changes there this is reflected in the portal so if we look here we've got our two resource groups one for a hub and one for a Spoke if we look at the spoke Network we've got the

spoke and we can have a look at peerings and you can see the peering is connected so that means both halves of the pairing are created and in sync with each other okay so let's start adding to this code now and seeing how we can make this a little bit more clever to start resynchronizing these pairings um when the address space changes the pattern we're going to be using to do this is the terraform data managed resource type together with replace triggered by and what that allows us to do is store data

in a terraform managed resource which is built in you don't need a provider for it and using replace triggered by we can essentially create a chain reaction of events that will trigger terraform to do something when another property of resource changes so they've got an example here so you've got uh terraform data uh resource here which has got a v. revision and an example database here with a replace triggers by the T from data. replacement which is this thing so

essentially when you when you change this number here um this resource will be uh recreated that's not quite what we want but aapi has got some resources called aapi Action Resources which enable us to do almost like curl or AZ rest kind of commands um but built into terraform so we can run it in a managed and structured way um let's have a look at the code to see how we do

that so first of all we're going to see this in action you I've got the same code as I did before but I've added a few extra bits to make this v-net resync work so let's just prove everything's fine so we got terraform plan here and we see no changes if we go to the Hub Network got terraform plan and there are no changes there as well now um what I'm going to do now is put this window here what we can see is that uh the v-net

paing is in a synchronized state so it's from The Hub perfect so that from The Hub one if we change the IP address of the spoke that would normally go I need to resynchronize so let's go and do that and see what happens first thing we need to change the uh address range of the spoke 10 0 1 024 okay done that now if we clear um I'm just going to use a little utility

that I wrote to um display the plan output in a kind of summary way oh why didn't that work cuz I'm in the Hub Network there you go Matthew uh so we're going to run a little utility that's going to says it's going to do some stuff but um uh I'm going to run this utility called TF plan doc I'm going to uh show you to show you exactly what's going on in a nice summary way so most of the resources there's no

op the vet spoke is going to be updated because we're updating the address space that's expected then we've got this time sleep resource in here which I've added because you need a little gap between updating the address space and then resynchronizing it because sometimes it doesn't realize it needs resynchronizing um then you've got this uh a API resource action v-net piring from Hub sync so this is the new resource I've added to actually synchronize the peering and you'll notice that it only does it when the I when the virtual Network changes when

the spoke vet changes so let's go and apply that now uh and see what happens so you can see that it's modifying the uh virtual Network um what I'm going also going to do is speed this up because obviously there's a 20 second sleep in there oky doie so that's done it that's changed one that's the virtual Network and it's uh done some other stuff as

well if we just go back to the portal quickly we can see if we give this a refresh that peing is still in sync which is fantastic um if we look at the spoke uh Network we can see the address space has got both address spaces in it now so that's cool we've added that and we've then resynchronized appearing all in wall in One operation what's cool is that this is IDM potent as well so if I go teron plan uh now it'll say cool I don't need to do anything

or I should do there we go cool no changes it's in sync so there we can see we've got an ID imponent way of resynchronizing a v appearing when the virtual address space of the virtual Network changes so let's have a look at how this works if I look at uh the peering from The Hub we've got that trusty time sleep and that is triggered by triggered replaced by the

v-net spoke being updated so any change to the v-ne spoke means that this time sleep will be recreated now I wasn't able to be specific and only change it on the address space but hey this is pretty good still then what we do this aapi resource action sync is triggered by the time sleep being recreated so it will then recreate this resource action nice thing is because this is a resource action and not a resource the delete operation on this is a no op it doesn't do anything

so that means it's not going to delete the v-net pairing it's just going to uh update it whenever we do a create whenever we do a put so essentially when that this uh when this virtual Network changes we're going to wait 20 seconds and then we are going to resynchronize the peering now the way we do that is by adding on this parameter onto the resource ID and telling it do a put over the top now this is why we had

the the body of the request in a local so we can be absolutely sure we're not going to make any changes to it when we do this so that's how that works by chaining these things together so any update to the virtual Network sleep for 20 seconds then run this that means that we can resync the peering whenever the address bace changes well that one certainly took some time you may have know noticed the costume change halfway through that's

because um essentially I've been refining this solution over the last couple of days and actually made it quite a lot simpler than it was I had L of four or five resources all chained together at one point and then I realized that that wasn't necessary I hope you find it interesting uh as ever the link for the repo will be in the video description if you have found this useful and enjoyed it please give us a like And subscribe it would be much appreciated and as a little bonus feature I'm going to show you how the opposite way around Works in that how we detect changes in the Hub Network and

resynchronize the peering um on the local side uh so yeah if you want to see that stick around if you just want to check out the code in the rep po it's all up there please do so and uh see you next time as a little bonus feature I'm going to show you what happens when the Hub Network changes as well if you want to have a look at this we're going to add another address space to the Hub Network uh 168 oh no I can't do that let's just do um

10.16 0.016 okay we should be a to see now that the uh address space is being added so if we apply that we can now see that the Hub Network address space is going to be updated

okay so that's fine what you'll see now is in the portal eventually you should see uh the peerings and it's local sync required okay so because the Hub Network is in a different state file we can't automatically resynchronize the pairing um because we don't necessarily because the peering has been created in in another state so we don't know uh which ones exist so in the model that we use for landing Z vending uh machine um we do this all from the state file that

contains the The vended Landing Zone plus the virtual networks and perings so if I go like that and go teron plan what we should see is that there we go so stuff has changed and it's going to um replace the sync resource again because we've got data sources and things okay so if I go terraform apply I'm going to say yes

and it's now recreating the sync resource which is going to reput that peering with the synchr address space parameter on top of it and it says it's done it if we go into here and click refresh it's fixed so there you go quick look at the code for that one we do the slightly differently so we've got the uh the peering that comes to the hub um from the spoke network with think got a data resource which

pulls out the um data of the remote virtual Network and we export the address pie prefixes value because you can't use replace triggered uh triggered by um on a data source uh you have to then put that into a terraform data resource which I've done here I've just chucked in the data in there and Jason decoded it then I've got exactly the same action as we did before so aapi resource action sync the uh Hub with the sync remote address

spaces and um make that dependent on the terraform data resource which stores The Hub address space and that's how you do it