Transcript
First of all, thank you for adjusting the session. Next time, I'll be careful not to be late, so thank you very much. Yes, so I'm going to talk about the private cloud that starts with ProcMods and HTTP Terraform. I think you're talking about the use of Terraform in your business, but I'm going to talk about using it at home. Yes. First of all, let me briefly introduce myself. My name is Akaike, and I work as a solution architect at Class Method. My favorite Terraform function is string reverse. Of course, it's just a function that reverses the order, but I've never used it. If you've ever used it, please let me know. Now that I've had the opportunity to talk about Terraform, I'd like to briefly introduce my history with Terraform. I joined the IT industry in 2021, and about a year later, I had the opportunity to use AWS for the first time. However, I was in charge of managing the infrastructure, so I had a lot of trouble managing it, and I was frustrated, but I personally managed it by using Terraform at home. I started using it at work in 2024, and that's when I finally started using it, and I felt that Terraform was great even at home. I joined Class Method around February of this year, and I'm usually in charge of AWS consulting. Basically, I'm a Terraform fan, so I use Terraform for all my projects. I think the compatibility between AI and Terraform is really good, so I feel like I'm able to implement infrastructure design and construction quite efficiently. Thank you, Terraform. Thank you very much. I look forward to working with you in the future. Now, let's talk about the main feature. The target audience is those who have used Terraform, those who are interested in the private cloud at home, and those who want to improve their home infrastructure. As a goal, I would be happy if you could understand the structure of Proxmox x HAP Terraform and start using it from tomorrow. This is a supplementary, but you can replace all the things that say home with on-pret. This is my personal hobby. Proxmox can also be applied to other virtual hard drives in the same way. Specifically, if you have a Terraform provider, you can do anything, such as VMware or Nutanix. This is the agenda. First of all, I would like to talk about the problems that arise when you manually operate Proxmox for a long time. On the other hand, I would like to talk about how to manage the configuration with Terraform, how to adjust the remote implementation environment with HAP Terraform, and how to solve problems by incorporating CI and CD with VCS. Finally, I would like to tell you in summary. First of all, as I said earlier, what is Proxmox? This is my personal opinion, but I personally think that it will become the standard for home servers. There are various features, but I think it's big that it can be used for free at the moment. I think it's a hot topic on the streets as an ESXi migration destination. As for the screen, this is a web UI, but it looks like this. You can see the information of the entire cluster, the information of the node, the information of the VM, the VM shell, and the operation log. You can see all of that in one place. I've been managing this with GUI so far, but if you run it for a long time, you'll get a lot of problems. The first problem is configuration management. If you've ever been in charge of on-prem, you may have a lot of experience, but you can't remember what you did in the past. You've completely forgotten how to make VMs. I was going to write a procedure, but I left it for a few months and left it with the actual configuration. As a result, I can't create the same environment. It's not reproducible. I think that's one thing. Next, I think there will be a problem with configuration management and change management. If it's at home, it's basically just me, but I don't know who changed what. It's a situation where I can't hear the intention or history of the past. It's a little different from change management, but I think there's also a pattern where you can't test the environment, and you can't test the environment, and you can't test the environment. I think this could have been avoided if there was a way to build the environment more easily. Finally, the problem of operation. It's related to what I've been talking about so far, but I don't know how to roll back, and it takes two hours to recover. In the first place, the environment is destroyed by manual work. Also, the server is not managed, and the server is not managed, and the environment is overgrown, and the resources are exhausted. I think this is a big problem. Actually, this is my environment before I introduced Terraform, but there are a lot of servers that I don't know the purpose of. To be honest, I don't remember when I made it, and I can't remember it. In order to improve this operation, I would like to talk about how to use HTTP Terraform and VCS. First of all, let's manage the configuration with Terraform. First, there is a question of what provider to use. Because the official Terraform provider of Blockbox does not exist at the moment. So there are some community providers, but you can use whatever you like. These two are the ones I see a lot. Personally, I recommend the BPG Blockbox below. This is a provider that can manage a wide range of resources such as VMs, containers, networks, firewalls, and Blockbox. Personally, I recommend this one. This is a rough description. First, the provider sets the end point of the Blockbox API, and then the token. There is a token that is paid by the Blockbox side, and this is how it is set. The definition of the resource side. This is an example of an LXC container. It's a node to deploy. You need to specify this. This is roughly how it is written. So far, I think we've been able to realize the configuration management of the Blockbox resource itself. I think there are some problems that come up when you manage Terraform locally. First of all, you can't run it from the outside. This is a big problem when you want to increase the number of VMs on the journey. Also, there is a problem that the exact conversion rate does not remain. As long as it is not intentionally left, the result of the plan or application does not remain. To solve this, we will introduce HTTP Terraform. Next, we will develop a remote implementation environment with HTTP Terraform. It would have been very easy if you could use HTTP Terraform as it is, but there is a problem with using it. Because HTTP Terraform is a form that can be deployed to your home via the Internet, the Blockbox provider feels like hitting the local API by default, so you can't access it via the Internet in the first place. Specifically, as I mentioned earlier, there is a part that specifies the local IP in the endpoint, so you can't run it directly from HTTP Terraform. I think there are various solutions, but personally, I think the smartest way is to use the HTTP Terraform agent. This is an environment where you can run the Terraform. You can actually run the Terraform plan or application in the environment where you install the agent. So, when you go to the HTTP Terraform application, the plan or application will be executed on the local server side, on the agent side. Another advantage is that you don't need to make a hole in the inbound. Because it's like pulling from the agent to the HTTP Terraform side, if you can communicate from home to the Internet outbound, you can basically communicate. This is what it actually looks like. People outbound apply to the HTTP Terraform via the Internet, and what they actually apply to is the server on the home side. The server with the agent is pulling, so they get the content and the application is completed in this house. This is a separate server with the agent, but of course, I think it's a good idea to make this a virtual server in BlockMox. The setting itself is simple. This is the setting of the HTTP Terraform organization. First, you create an agent pool, and in this, you pay for the agent tokens. Next, you specify and set the token you obtained on the server of the house where the agent is installed, and then you make the agent a service and run it on a regular basis. These are the two main settings. Finally, the settings on the workspace side of HTTP Terraform. In this, there is an execution mode, but if this is the default, it's called Project Default, but you can set this to Agent Custom and specify the agent pool I mentioned earlier. This completes the setting itself. As for the provider setting, of course, it runs on the HTTP Terraform, so you need to specify the organization and workspace in the Cloud. I think it's good that the remote execution environment is now complete in HTTP Terraform, but I think the next problem will arise here. First, you need to deploy and apply HTTP Terraform from the local, but when you run it, it depends on the setting, but I think it's a bit of a hassle to log in every time you want an authentication. Also, the source code and repository are not directly linked. Specifically, when you apply the Terraform code and manage the git separately, the git is not equal at that point, so if you forget to push to the repository, it will get out of hand. As a way to solve this, VCS will be introduced next. Let's incorporate CICD with VCS. This is something that can be completed on the workspace side of HTTP Terraform, and I think that in the past, you would set up CICD with GitHub Actions, but this is something that can be completed on the workspace side of HTTP Terraform. In the configuration diagram, the first and second are a little bit forward, and the push end is the GitHub repository, and in the second place, HTTP Terraform is automatically reflected by VCS, and after that, it's the same flow as before. This setup is also easy. You create a repository on GitHub, push the code, and when you create a workspace on the HTTP Terraform side, VCS will be set up. In the VCS setup, you can set up the Terraform directory and automatically apply it, and the important thing is the VCS trigger. Also, there are two types, the tag base, the tag of the repository, which reacts to a specific tag and triggers it. With these settings, I think most of the requirements of CICD can be met. This is an example of a program running. One last thing I want to tell you. First of all, it is better to take control of the configuration early. This is my experience, but if you do it later, you can't manage it manually and you can't remember how to make it. It's not limited to Terraform configuration management, but I think it's better to do it early and gradually expand it. With today's data, I did it all at once, but I don't think it's a problem to do it step by step for a month. I think it's important to continue to improve without aiming for perfection from the beginning. That's it for today. As I explained this time, if you need something, you can use a virtual hard drive, a free GitHub account, and a Terraform account that can be used for free. If you go home, please make one. That's it for today. Thank you for listening.
