<p>about your learning experience to help us improve.</p>

You've completed

cleanFiles/bookmap_Getting_Started_with_Terraform_on_SAP_BTP_en-US_learning-sap-com_lsc-prod.zip (MMCP-DROPZONE) - 2025-02-18T09:44:29.000Z

Adding Multiple Resources to the Terraform Configuration

Lesson Content

Getting Started with Terraform on SAP BTP

SAP_MOOC_terra1_unit4_lesson3_MULTI_Video.mp4

Welcome back to Unit 3, Enhancing the Terraform Configuration Lesson 3, adding multiple resources to the Terraform configuration. Switching to our already well-known journey map, we are now one step further, and after making our Terraform configuration more flexible, we are now adding more resources and getting more flash on the bones of our Terraform setup. Based on that, our main learning objective is how to add new resources to a configuration. Besides that, we will learn something about the concept of data sources. In other words, how can we pull in additional information for our resource setup? And finally, we will see how to handle dependencies between resources. Rui, how can we start when we want to add new resources to our configuration? Well, for now, we already use the resource BTP subaccount to create the sub-account. We will now use the same approach to add additional resources like entitlements, service instances and subscriptions, because the way it's done is very similar. Now, how is it done? We find all the available resources and the necessary parameters in the Terraform registry. And there you see, for example, the BTP Directory resource, or the BTP Global Account Role Collection, or the BTP subaccount entitlement resource that you see here, on this slide. There you can see what kind of attributes those resources have. Now, handing over again to Christian, is that the only way or is it the only thing that we are able to do? Or is there something more? Well, there is one more functionality that the provider gives in our hands, and that's data sources. Up to now, we talked about resources. That's mainly about creating, updating and deleting infrastructure assets like subaccount like we saw in the previous lesson. But there are situations where you want to read data from the platform and use it within your configuration. Looking, for example, into a resource like service instance, we see that we need the technical idea of the service plan to create such an instance. Now, this information is not returned by any resource that we use in the configuration. So the question is, how can we access that data? And that's why data source is come into play. They enable us to read information from the platform. Data sources are part of the Terraform provider, and consequently they are also part of the documentation. In this scenario, we need the data source for a service plan to get access to its technical information, especially its ID, and then use it in the resource of a service instance. There might be one more question that comes in our mind when dealing with different resources. The resources might depend on each other. How can we handle that, Rui? Well, normally Terraform will find out via Terraform plan what the right sequence is, meaning that there are some implicit dependencies. Like, for example, when creating an entitlement for a subaccount, you need to have a subaccount ID. You can only create an entitlement if you either provide the subaccount ID in a variable, or if a resource has been used to create a sub -account before and that resource can then provide the subaccount ID. This is an implicit dependency. But in some cases, Terraform cannot determine certain dependencies and for that we have explicit dependencies, meaning that you tell Terraform within the source code via the meta-argument called Depends-on. This will only create this resource if the other depending on resource is available. But there is one problem that we did not talk about yet. What about resources that take actually longer to be created? Is there also a mechanism for such long-running provisioning resources in Terraform, Christian? That's indeed an excellent question. Usually we assume that resources are provisioned in a reasonable amount of time, but there are some exceptions. Some resources might take a bit longer until they are successfully provisioned. Now in the Terraform provider we have a fixed time out for provisioning a resource which is 10 minutes. If the resource is not ready after 10 minutes, the execution of the Terraform script fails. Of course, there are some resources that we are aware of that might take longer. Typically the sample are service instances, environments or even subscriptions. Here, we provide the functionality to customize the timeout so you can freely define it for create, update as well as delete operations. You find the information about the availability of this customization functionality in the resource documentation. Now, I think that's enough of theory around adding additional resources. Should we go to the hands-on? Absolutely. So what will we do now in the hands-on exercise? We will enhance our Terraform configuration and you will add additional resources like entitlements, service instances and subscriptions. We will use the data sources as well that we just learned before to read in some information about the service plan from our SAP BTP subaccount. And we will look into the handling of explicit dependencies between resources with the depends on metadata field. So let's have a look. Okay, so let's start with the hands-on of Unit 3 Liston 3. We want to add multiple resources to the Terraform configuration so that the subaccount has more functionality in it. We will add entitlements, subscriptions, as well as service instances. And yeah, let's walk them through one by one. First thing we have to add entitlements. Of course, you find all the information that's available for entitlements in the documentation on the Terraform registry, you take a look at the resource, and it's BTP subaccount entitlement. And there you see what you can add. I would say as expected, you have the subaccount ID, the service name, as well as the plan name. Yeah, and there are some additional, so there is a schema again that you see here down below as well as also in an optional field here. Yeah, exactly. So especially if you have a service plans that allow a quota, you need this optional parameter. So what we want to have within our subaccount setup for our development teams are basically three entitlements. We want to have the alert notification service, we want to have feature flags, and we want to have the feature flex dashboard, which is a subscription. So yeah, let's just... Let's copy over this block here to our main TF file, right? And yeah, that's where the configuration lives. So let's add that and let's shortly walk through. So what we see is again we have a resource block, we define the resource type, BTP account entitlement, and we give it a name or an address. Now it needs the subaccount ID, the service plan name, the plan name. We hard code that here, well debatable if that makes sense or not, but for this course we will stick to that. And the subaccount ID is something that we created before, right? So that's kind of something, some technical ID that we can fetch from there. So that's now an implicit dependency that we can add here, right? That's right. So due to adding this BTP subaccount project subaccount id. We define an implicit dependency so Terraform knows, hey, I first need the subaccount before I can start with the entitlements. Yep. So with that, I think we can already... And the same is true actually also for the... Yeah, for all three services, right? Yeah, yeah. So I jumped over that. So all three resources, of course, have the sub-account ID in there. Now, Terraform will paralyze. So it knows, hey, those resources don't depend on each other, but they depend on the sub-account. So if there is a sub-account, I can basically kick the creation, kick off the creation of those three. In parallel. Resources in parallel, exactly. So I would say let's start. Let's do our usual game. We do a Terraform FMT. All good. Terraform validate. Did we do anything that breaks it? No. Then let's do a Terraform plan. And again, we give it a name. Yeah, Unit 3.3. And let's see what happens. So, yeah. A lot of stuff. Three, three plans are added. As you see down below here. And we see that the three entitlements are listed here, including the plan name, the service name. And we also see the sub-account ID for all three entitlements, which is actually exactly what we wanted to have, right? Now, that's one thing to mention. we have already created the sub-account. So you have the sub -account within the state. If we would have coded this main TF file without applying it to create the sub-account, this would also be a known after apply. Right, exactly. So then let's again apply the stuff to get things going. And as you can see, it really kicks off in parallel. Yeah, all three are now... All three are now creating in parallel. Takes a bit. And once this is done, our sub-account is entitled to use those three services, correct? Exactly, that's the expectation. Okay, three are added. Let's shortly again make a cross -check, so Terraform list, yep. In addition to the two ones we had before the subaccount and the UUID, we have now also the three entitlements. Good. Then let's continue, right? Yeah. So now we want to add maybe a service instance? Yep. Okay. So we, scrolling through, we want to add the alert notification service instance. Now, let's take a look at the documentation first. Because that would be the way how you would do that. You have the BTP subaccount service instance. And as you can see here, we scroll down to the schema. We need the service plan ID in order to create an instance. We know the subaccount ID. The name is something that we give. So how do we get it? How do we get this service plan ID? Now, unfortunately, we don't get it from the end. entitlement, which might be something that you expect, but that's not the case. But after you have entitled your subaccount, you can use a data source, which is the second area within the documentation. And if we take a look at BTP subaccount service plan, what we can see is you have two options how to call this data source, how to read the data, one is by ID. And one is by name. So we can use the name of the service plan, the name of the offering, and then we get back all the data of the service plan. And let's take a look at the schema. And ID, of course, is part of the schema. So this is exactly what we're looking for, right? Yeah. So let's go to our description. Just copy over the respective block into our main TF file. You just edit at the end. And in line 39, we see that we call the data source, BDP subaccount service plan, give it also a name, and providing the name and the offering name. And we are then using again an implicit dependency by providing the service plan ID by, yeah, writing the connection to data BTB subaccount service plan dot alert notification service standard dot ID so that's how we look up the name and then we give it a name of course every service instance needs to have a name and there we again make use of a local which is the service name prefix and then we add alert notification now again we see those red curly line so let's check if we also need something for the locals and of course we need. And this is here available as code. So we create the prefix again as a combination of sub-account stage and project name and replace any spaces and make it lowercase. So we add it to the locals block in our code at the very top again to make our code better readable. We save this. We save this and okay that doesn't look to... Shabby. Now, as I said before, to have the service plan available, we need to have the entitlement in praise, right? Yep. But we have no connection to the entitlement here in the data source. So we need to make that explicit. Yeah. So this is the point in time and this is also part of the document, of the ReadMe file. We need to add this explicit. dependency via the depends on meta argument that's something we need to add here in road 44 so to actually say you can only create or it only makes sense to fetch the data if there is already an entitlement for that one so going again through the sequence we have to have an entitlement which we say okay that's the depends on block on the entitlement then we can fetch the technical idea of the service plan yeah and then we can create the service instance and the service instance already has an implicit dependency to the data source, so we don't need any depends on here. So we close the loop now in here. Exactly. So let's shortly check. Back to muscle memory. Terraform FMT. You know the game. Terraform validate. All good. Looks good. Then we do a Terraform plan. with the plan out. Now we already did that before but Terraform will override that. Also something to be a bit more cautious then. It's refreshing the state, of course. It has to check what's already there on the platform. And now it will calculate the execution plan consequently. And, well, as expected, right? Yeah, one addition, so we will add the service instance to this because the entitlements we already did in our previous Terraform Apply run. And the thing that it will do now is creating the service instance. That's one service plan which is still pending. So we do again a Terraform Apply, Unit 3.3. Let's first clear up the mess and then we do the apply. And now it will create this service instance. So that's actually the first instance that you also see now in our global account, or try global account. So let's switch over there and... ...and refresh. Probably it makes sense to refresh it. Yeah. So, okay, and we go there are instances and subscriptions. We already see that there is one instance, the one that we actually did. here and we also see in the name of the instance that's exactly the naming convention we have added as a locals as in this locals block over here so it looks good it looks good to me so what else is a typical action that you have to do when setting up sub accounts i would say that's probably adding a subscription right yeah so let's add a subscription to the feature flags dashboard which is an app subscription. It's also a different resource now, resource now called BTP sub account subscription. Exactly. Let's shortly switch there and go to the resource. And there we have BTP account subscription. Yeah. So I think you already get the idea. So if you want to have a new resource within your configuration, go to the documentation, check for the parameters that are available that are required. In this case, app name, plan name, and sub account ID. So here we don't need a data source. And now we already copied the code block. So let's add that to our configuration. Main Tf file, just add it at the bottom again, save it. What we see there. We also have a subaccount ID again, fetching it from the sub -account ID we have anyways. And we have added here as well an explicit dependency, which is referring to the entitlement for this subscription, which needs to be there. Exactly. So the entitlement for an app subscription must also be there. Here we don't have to hop over the service plan fetching. So we have to add this depends on meta argument directly on the resource. And... Now the usual drill. You know the drill, right? Terraform FMT. Good, then we do a Terraform validate. All good. Looks good. And then we do a Terraform plan, like before. Again, it has to check what is available on the platform. It has to compare that with the Terraform state that we have stored locally. And then it can calculate the execution plan. This takes a bit. And hopefully then... Again, we see one thing to add, which is actually the subscription. And this looks good. Looks good, a lot of parameters that we don't use or that we get back from the platform, so... So the last thing missing to apply this. Terraform, apply unit 3-3. And now it automatically starts creating the subscription for this application and, oh, already done. That was quick. Yeah, let's go there. Let's go. to the global account. Refresh the page. And we should see now as well, not only the service instance, but as well the app subscription. And there it is. Here we go. FeatureFlex service. That looks good. So with that, we have added quite some stuff to our configuration. We added now entitlements. We added a service instance, we added a subscription, and we made use of a data source cool. Yeah, and we also learned the implicit and explicit dependencies, how they work. Right. So with that, that was the hands-on. We are back from the hands-on. Let's look at what we learned within this lesson. First, a Terraform configuration can contain multiple resources as well as data sources. Besides the create update and delete operations that the Terraform resources provide, we also have the option to use data sources to read information and use that within our configuration. Talking about dependencies between resources, this is usually handled by Terraform automatically when it calculates its execution plan. In some cases, Terraform won't be able to determine the dependencies correctly because there is no implicit dependency between the resources. In these cases, you must declare an explicit dependency to ensure a correct execution sequence. Finally, we learned that sometimes it takes a bit longer to provide resources. In these cases, you must use a custom timeout to deal with such long-running provisioning processes. This timeout configuration option is available on some resources as described in the provider documentation. And with that, we are at the end of this lesson. Thanks for watching and looking forward to seeing you in the next lesson. Bye. Bye.