Transcript
First, let me introduce myself. My name is Sato and I am a solution architect at ClassMethod Co., Ltd. I support AWS and Terraform products. I have also published an entry for HttpTerraform in ZenBook. You can read it for free. If you are interested in HttpTerraform, please read it in ZenBook. First, let me talk about this session. This session is for those who are using Terraform to implement IAC. Also, it is for those who are interested in Terraform Stacks. I think this feature was published in HashiConf 2024. I've only heard of the name, but I don't know what kind of feature it is. I'm targeting those people. As a goal, I hope you can understand the overview of Terraform Stacks and the use case. Before we get into Terraform Stacks, let's review the state file. First, I think there is a problem with state files that are not properly divided. As you can see in the figure on the right, all environments are in one state file. I don't think there are many cases like this. If it's a monolith state file like this, I think it's because of the large range of resource changes. I tried to change the resource in Dev, but I unintentionally made changes to the actual environment. Also, if the implementation time of Terraform is longer, the number of resources will increase, and the number of calls to the API will increase. As a result, I think that the implementation time will be longer. Also, if the management team is divided into a network or a database, it is difficult to understand which state file belongs to which team. It is necessary to make changes while being aware of the other team. I think it is also a problem that the management responsibility cannot be divided. In order to solve this problem, I will divide the state files. Here is another example of the division of state files. This time, it is a pattern that is divided into an environment and a resource type. First, there are three environments in Prod, Stage, and Dev. This is a pattern that can be divided into a resource type, such as a network or a computer. It was 1 state file earlier, but this time it is 4 resource types in 3 environments, so it was divided into 12 state files. This is what I said earlier to realize the division of state files with HCP Terraform. In general, I think that it will be like the figure on the right when creating a workspace for each state file. It is a little supplementary, but it is a supplementary for those who are not familiar with HCP Terraform and workspaces. First of all, HCP Terraform is a platform for using the Terraform provided by HashiCorp. There are various functions such as CICD. This is a workspace, which is a unit that manages the resources of Terraform and manages the execution and state files. As a result of this, I think that a new topic will be born. As the number of workspaces increases, I think the number of projects will also increase. Since it was 1 state file earlier, I was able to apply all the changes by running the Terraform plan apply once. Since the number of workspaces and state files has increased, it is necessary to apply the plan to each workspace. So the number of provisioning will increase. Also, I would like to define a dependency. In one state file, I think that you can easily define a dependency using DependZone. However, if the state file is separated, you will not be able to do that. I think this is also a bit of a problem. Also, it is necessary to set up each workspace. I think it will be a lot of work when the number increases. Specifically, in the workspace, which GitHub repository to use, which branch to use, etc. I set these things up in the workspace and set up the deployment, etc. However, I think that if the number of workspaces increases, it will be a hassle to set up. I think that Terraform Stacks can be used to solve such problems. By creating in Stacks, state files and workspaces were in each resource. There is a unit called Stacks at the top. You can manage it in one new layer. By using Stacks, you can manage multiple workspaces. Stacks changes the concept of a workspace. You can make it easier by using multiple workspaces. Provisioning and dependency relations can be easily managed. This is a summary of Terraform Stacks. First of all, this function is a function that allows you to simplify large-scale infrastructure management. The phase is now called public beta. It was announced in a private preview at HashiConf in 2013. It is a status that the public beta version was announced at HashiConf this year. As a precaution, it can only be used in Terraform. I think there are quite a few people who use the community version, but it is something that cannot be used in the community version at present. It was written in the blog of HashiConf, but in the community version, some functions will be integrated. I think there are some functions that can be used. Since this is a public beta, there is a limit to the number of resources. There is a limit of up to 500 resources. This is not just a free plan, but a standard plus plan. There is a similar limit in the user plan as well. As a use case for Terraform Stacks, there are things like this. Multiple environments, such as Pro, Stage, and Dev. I think it will be useful in the pattern of deploying to multiple regions. A pattern that wants to deploy different data resources as a single unit. Network and compute. Although the state file is divided, I think Stacks is quite useful in the pattern of wanting to deploy with the dependency of the network compute. I would like to talk about how to use Stacks while mixing the sample configuration. This sample configuration is composed of API Gateway, Lambda, and S3. It is a multi-account and multi-region configuration. Each environment has Pro, Stage, and Dev. Each environment has a separate account. In Pro and Stage, we take the multi-region configuration and deploy with US East 1 and US West 1. Dev is a single region. I would like to talk about each configuration element in the pattern of deploying to multiple regions. There are four major configuration elements of Stacks. Today, I would like to explain each of these four elements. First, let's talk about components. Components are things that define resources, including Stacks. If you look at the figure on the right, I think it is easy to understand. For example, this time, we create a component with API Gateway and create a component with Lambda and S3. How do we define these components? This time, we use a new component block in Stacks to define it. This has three components, S3, Lambda, and API Gateway. This source Lambda is surrounded by a frame. This is like a call to a module. It reads the tf file there. This Lambda main tf has a normal Terraform code. In the resource AWS Lambda function, there is a Terraform code to create Lambda. Input, this is the Lambda main tf. There is a variable tf in Lambda, and you can receive variables there. You can also output other components. There is an S3 component. Create a bucket of S3 here. In the S3 component, the S3 bucket ID is passed as an output, and it is received by this component Lambda. Since this is received by the output, the dependency relationship is automatically taken into account, and this is taken into account when planning or applying. This is Deployments. In the component section, it was a resource-specific component. In Deployments, it is a component that defines the deployment destination. It is a component that passes AWS account or region. In Deployments, it is a component that defines the deployment block and passes it as a Prod stage. In Prod, I think it is passed to regions or role ARN, but in Prod, it is passed to US East and US West as a multi-region, and as a role ARN, it is passed here to run the HAP Terraform in the Prod account. In Prod, it is passed the IAM role ARN of the account. In each stage account, it is passed the role for the stage account. In Deployments, it is a component that defines the deployment destination. As for the directory configuration, it is a component that defines the resource at the top, such as API Gateway, Lambda, and S3. This is a component that defines the resource, but it uses the Terraform code as it is, so it can be defined as it is. As for the definition for Stacks, it defines the components and deployments that have been newly created with Stacks. As for the components I mentioned earlier, there are components such as components.tf.stack.html, deployments.tf.deploy.html, and so on. As for outputs, providers, and variables, if you use Stacks a little, the items that can be set are different, but it doesn't change much, so please remember that components and deployments can be newly created with Stacks. This is a slide that shows the actual image of the screen. This is what it looks like when you actually try to create Stacks. First, go to Projects, and I think you can create a workspace or a stack from there. You can see Stacks here, so please select Stacks. After this, it's almost the same as a workspace. Set VCS to where the GitHub repository is, and where the GitHub repository has the code I mentioned earlier, and click Create Stacks. When this Create Stack is completed, it looks like the screen on the left, and you can see the overall screen of Stacks. There is a configuration page on the top, and it is information such as which commit is currently hit, and the bottom is called deployments, and I set it with the deployment block at the DevPro stage earlier, and you can see the names of the deployments there. If you click on the Dev, or the stage of the deployment, you can see the detailed content of the plan. If you can confirm this plan, you can confirm the plan from here, and after that, there is a button called Approve Plan at the command line, so if you click on this, you can actually run the application. If you click on the Approve Plan, there was a DevPro stage, but only the Dev is healthy, and you can see that the application has been completed. The Pro stage has not been approved yet, so you can see that the application has not been completed yet. Next, I will introduce the orchestration rules. This is the rule to manage the deployment earlier. You can re-run the plan for specific conditions, or automate it. In the previous screen, it was a default setting, so it is all planned. You can't apply to the platform. If you use this orchestration rule, the production environment will leave the manual transaction, and the other environments, such as stages and Dev, will automatically transact if you deploy immediately without manual transaction every time. If a commit is sent, it will be possible to apply. This is how it is actually written. This is where you write the orchestration. It is like writing in the defined file of the deployment. This is the orchestration block. This is also a new block. This is where you set up the resource auto-approve. This is where you can choose between auto-approve, replan, auto-transaction, and re-run the plan. This is the auto-transaction rule for auto-approve. This is where you make the rules in the check block. There is information on context, plan, and deployment. If the deployment is outside of the deployment prodo, this is the check block's condition. If it is this time, Dev and Stage will match this rule. Therefore, the auto-approve for Dev and Stage will be valid. The right side of the screen, other than the prodo, will be automatically transacted, and automatically applied. Finally, I would like to talk about Deferred Changes. This is a function that automatically manages the dependency. To be more specific, when using other components and outputs in the provider settings, the plan is automatically delayed. This can be used in a pattern that requires multiple-step deployment. For example, EKS clusters and K8S manifest are managed by Terraform. I think this is quite useful. First, let's look at the pattern that does not use the orchestration rules. As a premise, I would like you to assume that the definition of EKS and the resource of Kubernetes manifest are divided into state files. I think it's quite natural, but the Kubernetes provider of K8S manifest needs EKS cluster information. If you look at the provider hl, you can see that I omitted it, but it's called config-host in the Kubernetes provider. This is how it is written. It is written in a way that takes EKS cluster endpoints from the remote state with data. If there is no EKS cluster, there is no information in the state, so you can't do anything like init. So this is the figure on the left. If there is no EKS cluster in the Terraform plan, I think it will be an error in the Terraform plan of Kubernetes manifest. This is because you need to work on the plan while being aware of the state of the EKS side. I think this is the use of the workspace so far. Let's see what it looks like when you use deferred changes. As before, if there is no EKS, if there is no EKS, this plan will not become an error, but will be delayed. Provider tf.stack.hl is defined as a Terraform stack. Here, the EKS cluster is defined as a separate component. If you use the output here, on the stack side, if there is no EKS cluster, Kubernetes will recognize that the provider cannot be used, so it will not make this plan an error, but delay it. What kind of screen will this deferred changes be? It looks like this. There are two components. The cluster is normally planned. You can see the message here. The cube is like using the Kubernetes provider, so you can see that it is automatically delayed. If you apply this plan, the EKS cluster will be completed, and then the plan will run again, and then the plan will be executed normally. If you approve there, you can deploy both. I talked about each component of Terraform stacks here. In conclusion, by using Terraform stacks, you can easily build and manage multiple workspaces. Currently, it is public beta, so you can try it for free. Please try it, and give feedback to HashiCorp, and I hope it will become a better feature. There is a tutorial by HashiCorp, so if you are interested, I think it is best to start from this tutorial. Finally, I would like to advertise one thing. Tomorrow, there will be an IAC webinar hosted by ClassMethod. The webinar will be held from 2 p.m. to 3 p.m. tomorrow. I think today's talk about Terraform stacks was an application-oriented talk. I think it was an application-oriented talk for some people. In this seminar, I will talk about why IAC is important, the basic functions of HTTP Terraform, and so on. Please check it out. That's all I have to say. Thank you for listening.
