> For the complete documentation index, see [llms.txt](https://asafahmadov.gitbook.io/cloud-and-devops/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://asafahmadov.gitbook.io/cloud-and-devops/devops-bootcamp/infrastructure-as-code-with-terraform/introduction-to-terraform.md).
# Introduction to Terraform
Terraform allows us to describe our complete infrastructure in the form of code. Even if our servers come from different providers such as AWS or [Azure](https://www.varonis.com/blog/what-is-azure-devops/?hsLang=en), Terraform helps us build and manage these resources in parallel across providers. We can think of the Terraform as a connective tool and common language that we can utilize to manage our entire IT stack.
▪ An open-source infrastructure as code (IaC) tool by HashiCorp
▪ Let us automate and manage:
● our infrastructure
● our platform
● services that run on that platform
▪ By defining the resources in human-readable configuration files that you can:
● version
● reuse
● share
▪ Definition of configuration files is `declarative!`
{% hint style="info" %} **Declarative** = define WHAT end result or desired state you want
**Imperative** = define exact steps - HOW
{% endhint %}
### Benefits of Infrastructure as Code
IaC solves many common problems with provisioning Infrastructure.
* New environments or infrastructure can be provisioned easily from your IaC configuration code. Infrastructure deployments with IaC are **repeatable**.
* Manually configured environments are difficult to scale. With environments provisioned using IaC, they can be **deployed and scaled rapidly**.
* If you want to make changes to the existing infrastructure that has been deployed with IaC, this can be done in code, and the changes will be **tracked**.
* When IaC is used with a declarative tool (it describes the state you want your environment to look like), you can **detect and correct environment drift.** If a part of the infrastructure is modified manually outside the code, it can be brought back in line with the desired state on the next run.
* Changes can be applied multiple times without changing the result beyond the initial application. This is known as **idempotence***.*
* **Avoid manual configuration** of environments which can typically introduce mistakes due to human error. With IaC, these can be avoided.
* IaC is a means to achieve **consistency** across environments and infrastructure. The code can be reused.
* Infrastructure **costs are lowered** as the time to deploy and effort to manage, administer and maintain environments decrease.
* IaC can be used in Continuous Integration / Continuous Deployment (or CI/CD) pipelines. The main benefit of doing this is to **automate** your Infrastructure deployments.
* DevOps teams can **test applications** in production-like environments early in the development cycle.
* With your Infrastructure configuration code held in your version control system alongside your application source code, commonly in the same repository. Now everything can be **held together**.
* **Productivity will increase** due to a combination of all the benefits of using IaC.
* As the code is held in your version control system, it **gains all the benefits of the VCS**. More on that in the next section.
### Difference of Ansible and Terraform
Infrastructure Provisioning
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://asafahmadov.gitbook.io/cloud-and-devops/devops-bootcamp/infrastructure-as-code-with-terraform/introduction-to-terraform.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.