Applying the OpenTofu plan

In the last video, we learned how to use the OpenTofu plan command to see a preview of the resources that OpenTofu will create from our OpenTofu configuration. In our case, we saw how OpenTofu will create an AWS S3 bucket for Explore California and upload all of the website's assets into it. Let's learn how to make our plan a reality. This step is really easy. All we need to do here is clear our screen and run "docker compose run --rm opentofu apply". That's it. After doing this, you'll see the plan that we created before once again. This time, however, you'll be asked whether you want to confirm your changes. Since we already know that everything looks good here, I'm going to go ahead and type in "yes" to confirm them. Once I hit Enter, we are off to the races. We'll see a lot of stuff happening here and it won't take very long. That was blazing fast. Just for curiosity, let's run "opentofu plan" again to see what differences we get this time. We can see here that we're getting a lot more output than we did before. We can also see that towards the bottom, that surely enough nothing has changed. How does OpenTofu know this? This brings us to one of OpenTofu's best features. OpenTofu doesn't just create infrastructure for you. It also tracks changes to that infrastructure. It uses something called a state file to do this. Let me show you what I mean. Our OpenTofu configuration lives in this "Infra" folder, right? Well, if we use "ls" to list the contents of that folder, we can see that there's a little bit more stuff in here. Specifically, we can see a Terraform .tf state file listed. This is OpenTofu's database of our infrastructure. Everything that we created when we ran "opentofu apply" gets persisted into here. It's just a plain text file. So we could even run "cat" against it to see what all's in it. I hope that while I'm scrolling upwards, you see the problem with this. This is OpenTofu's plain text database of all of your infrastructure. There's probably stuff in your infrastructure that you rather not have laying around like this. We're also working within a Git repository, so someone could easily commit and push this file into GitLab, which we can confirm by running "git status" and then running "git add -infra" and then running "git status" once again. If we were to push this on to GitLab, even though our GitLab instance is private, all of the Git commands that we were using before would work on a public developer platform as well. So if we were to push this up to something like the internet version of GitLab, we could leak all of our infrastructure to the entire world. There are bots on the internet that are constantly scanning Git repos like this to find AWS credentials, IP addresses, and other valuable information to gain access into all sorts of stuff. This attack happens all of the time. Another problem that might happen is contention. So what if we are applying this plan and some other colleague decides to change our Terraform infrastructure? If they apply those changes, then we're going to have a conflict. One of us isn't going to be able to apply infrastructure anymore. Fortunately, OpenTofu has a feature to solve this exact problem: remote state. Remote state configures OpenTofu to store the state file elsewhere. OpenTofu does this through backends. You can think of backends as secure places to store your state files. Some remote state backends also supports something called "locking", which prevents the collision problem that I was talking about before. It uses a technique also called "locking" to prevent the "multiple rider problem" that I mentioned before. Now, we won't cover remote states in this course, but check out the Terraform courses on LinkedIn Learning to learn more about that. Alright, back to hacking. So once again we don't want to commit any of these super secret things. So what we're going to do is we're going to use this command up here called "git restore --staged" to stage these changes. So let's go ahead and run that now, "git restore --staged infra", to remove that directory from our staging area. Confirm that it's removed with "git status". And then we're going to create a new file called "gitignore" which gets users to ignore these changes. Any files or directories that get added to the ".gitignore" file will not be tracked by Git. This is useful for sensitive data like our state file, since we can have them live inside of our codebase, but not live inside of GitLab or something like this. So to add those files to the getignore, what we're going to do is we're going to type "echo" and then we're going to type "infra terraform.tfstate". And then we're going to use two right angle brackets like this. And then we're going to type "gitignore" at the end of that. You also saw that there's a bunch of that Terraform stuff in here that we don't want to apply. So let's go ahead and run "echo infra /.terraform" and add that to the gitignore as well. So after I do that when I run "git status" you should see that there's two entries now. We should see that there's a ".gitignore" and an "infra" directory. So if I add both using "git add .gitignore" and "infra" and I run "git status", you can see that there is now just one file remaining that we would probably not want to commit, this terraform.lock file. We can do the exact same thing that we did before. We can use "git restore --staged infra/.terraform .lock.hcl" to remove it. Then we can just add that to our gitignore by typing in "echo infra/. terraform. lock.hcl >> .gitignore". And then if I run "git status" one more time, we can see that our Git ignores both staged, as well as not staged. The reason for this is because even though we've staged the gitignore file earlier, there were some changes made to it that haven't been staged yet. Remember, Git tracks individual changes, not entire files. So it's very possible that you can have files that are both staged to be committed as well as in a not-staged state. So let's go ahead and stage those changes. And then we can also see that the terraform.locl.hcl file is also gone. If I run "git status" again we can confirm that once again. Earlier we talked about using outputs to get information from our resources. Specifically, we talked about a output called WEBSITE _URL. How do we actually get that output? Well that's very easy. All we have to do is type "docker compose run --rm opentofu output". This will show us all of the outputs that OpenTofu knows about from the resources that we've created. So we only want this website URL output, and we don't need all this other junk like website URL equals and these double quotes. So to remove that what I'm going to do is I'm going to rerun this command. I'm going to add "-raw" to the end of it. And then I'm going to add "website_url". And there we go. We just got back the URL of the bucket. So what happens if I actually go to this URL in a browser? So let me actually copy this. Open a web browser, paste it into the address bar and hit Enter. If I do that we have Explore California on the internet! So it's time for the final boss. Does this work with the end-to-end test that we wrote before? Let's find out in the next video.