Terraform: 基础设施即代码

问题

现如今有很多 IT 零碎的基础设施间接应用了云厂商提供的服务，假如咱们须要构建以下基础设施：

• VPC 网络
• 虚拟主机
• 负载均衡器
• 数据库
• 文件存储
• ...

那么在私有云的环境中，咱们个别怎么做？

在云厂商提供的前端治理页面上手动操作吗？

这也太吃力了吧，尤其是当基础设施越来越多、越来越简单、以及跨多个云环境的时候，这些基础设施的配置和治理便会碰到一个微小的挑战。

Terraform

为了解决上述问题，Terrafrom 应运而生。

应用 Terraform ，咱们只须要编写简略的申明式代码，形如：

...resource "alicloud_db_instance" "instance" {  engine           = "MySQL"  engine_version   = "5.6"  instance_type    = "rds.mysql.s1.small"  instance_storage = "10"  ...}

而后执行几个简略的 terraform 命令便能够轻松创立一个阿里云的数据库实例。

这就是 Infrastructure as code 基础设施即代码。也就是通过代码而不是手动流程来治理和配置基础设施。

正如其官网文档所述，与手动治理基础设施相比，应用 Terraform 有以下几个劣势：

• Terraform 能够轻松治理多个云平台上的基础设施。
• 应用人类可读的申明式的配置语言，有助于疾速编写基础设施代码。
• Terraform 的状态容许您在整个部署过程中跟踪资源更改。
• 能够对这些基础设施代码进行版本控制，从而平安地进行合作。

Provider & Module

你兴许会感到困惑，我只是简略的利用了所写的申明式代码，怎么就构建进去了基础设施，这两头产生了什么？

其实简而言之就是 terraform 在执行的过程中外部调用了基础设施平台提供的 API 。

每个基础设施平台都会把对本身资源的操作对立封装打包成一个 provider 。provider 的概念就如同是编程语言中的一个依赖库。

在 terraform 中援用 provider ：

terraform {  required_providers {    alicloud = {      source = "aliyun/alicloud"      version = "1.161.0"    }  }}provider "alicloud" {  # Configuration options}

咱们在写代码的时候常常会把某些可重用的局部剥离进去作为一个模块，而在 terraform 中，对基础设施的治理也是如此，咱们可能把可重用的 terraform 配置组成 module 模块，咱们即能够在咱们 local 本地本人编写模块，也能够间接应用第三方组织好并且公开公布的 remote 模块。

最初

本文只是抛砖引玉罢了，无关 terraform 的更多内容还请参考官网文档及其它材料。