Today, I’m going to write a series of articles on how to use Terraform to define and manage infrastructure as Code (IaC) in a production environment. If you haven’t used it before, Terraform is a simple, declarable programming language that allows you to define infrastructure for various cloud services (AWS,Azure,Aliyun, etc.) and deploy and manage it with commands.
At Gruntwork, we use Terraform as one of the main IaC tools for Infrastructure as Code Library. This is a collection of over 300,000 lines of reusable, battle-tested, production-level infrastructure code for widely used cloud vendors AWS, GCP, and Azure. In this introductory article, we’ll discuss why we believe every software company should use IaC. Next we will cover the following topics:
- Why we use Terraform instead of Chef, Puppet, Ansible, SaltStack.
- Introduction of Terraform
- How do I manage Terraform status
- How do I create reusable infrastructure using the Terraform module
- Terraform tips: Loops, conditional statements, and various pits
- How is Terraform used in the team
All right, now to the point. Now let’s dive into why every Internet software company should define their IaC.
Why infrastructure as code
Once upon a time, in a remote data center. An ancient and experienced, known system administrator manually deploys the infrastructure. Each server, routing table entry, database configuration, and load balancer are created and managed manually. It was a dark and fearful time: fear of downtime, fear of unexpected configuration file errors, fear of slow and error-prone deployments. The good news is that thanks to the rise of DevOps, we now have a better way to do these things: Infrastructure-as-code (IAC).
Compare that to clicking on a Web interface or SSH to a server and then executing commands manually. The idea behind IAC is to define, extend, and manage your infrastructure by writing code. This has many benefits:
- You can automate your entire extension and deployment process, making it faster and more reliable than doing it manually.
- You can represent the state of the entire infrastructure in a source file so that anyone’s can read it, not just administrators.
- You can versioned these source files, which means that the entire history of your infrastructure can be traced in the commit log, which allows you to debug problems and roll back to older versions if necessary.
- You can validate every infrastructure change through code reviews and automated tests.
- You can create (or buy) a collection of production-level infrastructure code that can be reused, battle-tested.
There’s another important reason why it’s particularly noteworthy: it makes developers happier. Deploying code is a tedious and tedious task. Computers can do these things quickly and efficiently, but humans are inefficient and fallible. Also, developers hate to work. Because it’s not tasking creative, challenging, and validated. You can deploy code perfectly month after month, but no one will care or notice until one day you make a mistake.
All this creates a stressful and unpleasant environment. IAC offers a better option for computers and developers to just do what they’re good at.
Why Terraform?
There are many ways to implement IAC, from the simplest of manually creating shell scripts to administrative services like Puppet, Ansible, and so on. So why do we insist on Terraform as our IAC tool? For more details, see the next section — No1: Why we use Terraform instead of Chef, Puppt, Ansible.
Three minutes a day, knowledge efficiency is high. Light article, more efficient.
Three minutes a day, knowledge is easier.
Welcome to follow geek 24H, a public wechat account of the same name.