Terraform Provider — Vì sao Provider không chỉ đơn giản là Plugin

Ở bài trước chúng ta đã tìm hiểu về Terraform Module.

Module giúp chúng ta chia nhỏ Infrastructure thành các khối có thể tái sử dụng.

Nhưng đến đây sẽ xuất hiện một câu hỏi rất thú vị.

Terraform chỉ là một chương trình duy nhất.

Làm sao nó có thể tạo được:

• AWS EC2
• Azure Virtual Machine
• Google Cloud Storage
• Kubernetes Deployment
• GitHub Repository
• Cloudflare DNS
• Vercel Project
• Supabase Project

Mỗi nền tảng đều có:

• API khác nhau
• Authentication khác nhau
• Resource khác nhau
• Quy tắc hoạt động khác nhau

Terraform đâu thể biết tất cả những điều này.

Nếu mỗi khi có một Cloud Provider mới xuất hiện, HashiCorp phải sửa Terraform Core thì gần như Terraform sẽ không bao giờ mở rộng được.

Đó là lý do Terraform được thiết kế theo một kiến trúc rất hay.

Terraform Core chỉ chịu trách nhiệm lập kế hoạch.

Còn việc giao tiếp với từng nền tảng sẽ được giao cho Provider.

Terraform Core không biết gì về AWS

Đây là điều khiến nhiều người bất ngờ.

Terraform hoàn toàn không biết EC2 là gì.

Nó cũng không biết:

• S3
• VPC
• IAM
• Kubernetes
• Docker
• GitHub

Terraform Core chỉ hiểu một vài khái niệm rất trừu tượng.

Ví dụ:

• Resource
• Data Source
• Dependency Graph
• State
• Execution Plan

Ngoài những thứ này, Terraform không biết gì về Infrastructure.

Có thể hình dung như sau.

                Terraform Core

          Parse Configuration
                 │
          Build Dependency Graph
                 │
           Compare Terraform State
                 │
             Execution Plan
                 │
          Gọi Provider thực hiện

Terraform chỉ quyết định:

Resource nào cần tạo.

Resource nào cần sửa.

Resource nào cần xoá.

Còn việc làm như thế nào sẽ do Provider đảm nhiệm.

Provider giống như Driver của hệ điều hành

Một ví dụ rất gần gũi.

Khi bạn cắm một chiếc máy in vào máy tính.

Hệ điều hành không biết:

• cách in
• tốc độ in
• độ phân giải
• giao thức truyền dữ liệu

Nó chỉ biết:

Tôi cần in tài liệu này.

Driver của máy in sẽ xử lý phần còn lại.

Terraform Provider cũng hoạt động tương tự.

Terraform
      │
      ▼
AWS Provider
      │
      ▼
AWS API

Hay.

Terraform
      │
      ▼
Cloudflare Provider
      │
      ▼
Cloudflare API

Terraform không gọi API trực tiếp.

Nó luôn đi thông qua Provider.

Provider không chỉ là một Plugin

HashiCorp thường mô tả Provider là Plugin.

Điều này đúng.

Nhưng chưa đủ.

Một Provider thực chất là một chương trình độc lập.

Terraform Core và Provider chạy ở hai process khác nhau.

+----------------------+
| Terraform Core       |
+----------------------+
           │
           │ RPC
           ▼
+----------------------+
| AWS Provider         |
+----------------------+
           │
           ▼
      AWS REST API

Điều này mang lại rất nhiều lợi ích.

Ví dụ.

Terraform Core không cần release mỗi khi AWS ra thêm dịch vụ mới.

Chỉ cần AWS Provider cập nhật.

Terraform vẫn hoạt động bình thường.

Đây là một trong những quyết định kiến trúc quan trọng nhất của Terraform.

Nhờ đó hiện nay Terraform có hàng nghìn Provider khác nhau.

Một Provider có thể quản lý rất nhiều Resource

Nhiều người mới học thường nghĩ.

AWS Provider

↓

EC2

Thực tế hoàn toàn khác.

Một Provider có thể quản lý hàng trăm loại Resource.

Ví dụ.

AWS Provider hiện hỗ trợ:

• EC2
• VPC
• IAM
• Route53
• Lambda
• CloudFront
• S3
• DynamoDB
• RDS
• EKS
• ECS
• SNS
• SQS

...

Tất cả đều nằm trong cùng một Provider.

Điều tương tự cũng xảy ra với Azure hay Google Cloud.

Provider hoạt động như thế nào?

Khi chạy.

terraform init

Terraform sẽ đọc phần khai báo Provider.

Ví dụ.

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"
    }
  }
}

Sau đó.

Terraform sẽ tải Provider từ Terraform Registry.

Terraform Registry

        │

Download AWS Provider

        │

Lưu vào local cache

        │

Terraform sử dụng Provider

Lần sau chạy lại.

Terraform sẽ không cần tải lại nếu phiên bản vẫn giống nhau.

Đó cũng là lý do trong project luôn xuất hiện file:

.terraform.lock.hcl

File này sẽ "khóa" phiên bản Provider để mọi thành viên trong team sử dụng cùng một version.

Điều này giúp tránh rất nhiều lỗi khó debug do khác phiên bản Provider.

Terraform Core và Provider giao tiếp với nhau như thế nào?

Đây là phần mà rất ít bài viết nhắc tới.

Terraform Core không import Provider như một thư viện.

Thay vào đó.

Terraform sẽ khởi động Provider như một process riêng.

Terraform Core

      │

Spawn Process

      │

AWS Provider

      │

RPC

      │

AWS API

Mỗi khi Terraform cần tạo một EC2.

Nó sẽ gửi yêu cầu tới AWS Provider.

AWS Provider sẽ:

• kiểm tra dữ liệu đầu vào
• chuyển đổi thành AWS SDK
• gọi AWS API
• nhận kết quả
• chuyển lại cho Terraform Core

Terraform Core sau đó sẽ cập nhật Terraform State.

Toàn bộ quá trình này diễn ra hoàn toàn tự động.

Đó là lý do Terraform Core có thể hoạt động với hàng nghìn Provider khác nhau mà gần như không cần biết chúng được triển khai ra sao.

Provider không chỉ tạo Resource

Một hiểu lầm phổ biến là:

Provider chỉ dùng để tạo Resource.

Thực tế, Provider chịu trách nhiệm cho hầu hết mọi tương tác giữa Terraform và nền tảng bên ngoài.

Ví dụ với AWS Provider.

Terraform có thể:

• tạo EC2
• cập nhật Security Group
• xoá VPC
• đọc thông tin AMI mới nhất
• lấy danh sách Availability Zone
• kiểm tra Route53 Zone
• đọc Secret từ Secrets Manager

Có thể thấy.

Một số thao tác tạo ra Infrastructure.

Một số thao tác chỉ đơn giản là đọc dữ liệu.

Đó chính là lúc hai khái niệm Resource và Data Source xuất hiện.

Resource

Resource đại diện cho một đối tượng mà Terraform sẽ quản lý.

Ví dụ.

resource "aws_instance" "web" {
 
  ami           = "ami-xxxxxxxx"
 
  instance_type = "t3.micro"
 
}

Khi chạy.

terraform apply

Terraform sẽ yêu cầu AWS Provider:

Hãy tạo một EC2.

Sau khi EC2 được tạo thành công.

Terraform sẽ lưu thông tin của Resource này vào Terraform State.

Terraform State

↓

aws_instance.web

↓

EC2 ID

↓

i-0123456789

Kể từ thời điểm đó.

Terraform sẽ tiếp tục theo dõi Resource này trong suốt vòng đời của nó.

Ví dụ.

Create

↓

Update

↓

Replace

↓

Destroy

Đây chính là ý nghĩa của từ Infrastructure as Code.

Terraform không chỉ tạo Resource.

Terraform còn chịu trách nhiệm quản lý toàn bộ vòng đời của Resource đó.

Data Source

Không phải lúc nào Terraform cũng cần tạo mới.

Trong thực tế.

Infrastructure thường đã tồn tại trước.

Ví dụ.

• VPC đã được tạo bởi team Platform.
• Route53 Zone đã tồn tại nhiều năm.
• Kubernetes Cluster được quản lý bởi một project khác.
• IAM Role được Security Team tạo sẵn.

Nếu Terraform cố tạo lại những Resource này.

Kết quả thường sẽ là lỗi.

Lúc này chúng ta chỉ cần đọc thông tin.

Terraform cung cấp Data Source cho mục đích này.

Ví dụ.

data "aws_vpc" "main" {
 
  tags = {
 
    Name = "production"
 
  }
 
}

Terraform sẽ không tạo VPC mới.

AWS Provider chỉ gọi API để tìm VPC có tag phù hợp.

Sau đó trả kết quả về cho Terraform.

Terraform

↓

AWS Provider

↓

Describe VPC API

↓

VPC Information

Không có Resource nào được tạo.

Không có gì được lưu vào Terraform State ngoài metadata cần thiết để đánh giá biểu thức trong lần chạy hiện tại.

Đây là điểm khác biệt rất quan trọng.

Resource và Data Source khác nhau như thế nào?

Có thể hình dung như sau.

Ví dụ.

resource "aws_vpc"

↓

Terraform sở hữu VPC

Trong khi.

data "aws_vpc"

↓

Terraform chỉ biết VPC tồn tại

Hai khái niệm này thường được sử dụng cùng nhau trong một project.

Kết hợp Resource và Data Source

Giả sử công ty đã có sẵn một VPC.

Bạn chỉ cần tạo EC2.

Khi đó.

Terraform sẽ làm như sau.

data "aws_vpc" "main" {
 
  tags = {
 
    Name = "production"
 
  }
 
}
 
resource "aws_instance" "web" {
 
  subnet_id = data.aws_vpc.main.default_route_table_id
 
}

Quy trình thực tế sẽ là.

Đọc VPC

↓

Lấy thông tin VPC

↓

Tạo EC2

↓

Gắn EC2 vào VPC

Terraform sẽ tự hiểu rằng.

Muốn tạo EC2.

Trước tiên phải đọc được thông tin của VPC.

Đây là lúc Terraform bắt đầu xây dựng Dependency Graph.

Terraform không chạy từ trên xuống dưới

Đây là một trong những điều khiến nhiều người mới học Terraform bất ngờ nhất.

Hãy xem ví dụ.

resource "aws_security_group" "web" {}
 
resource "aws_instance" "web" {
 
  vpc_security_group_ids = [
 
    aws_security_group.web.id
 
  ]
 
}

Có vẻ như.

Terraform sẽ đọc từ trên xuống dưới.

Nhưng thực tế không phải vậy.

Terraform sẽ đọc toàn bộ Configuration trước.

Sau đó xây dựng một đồ thị phụ thuộc.

aws_security_group.web

            │

            ▼

aws_instance.web

Sau khi có Dependency Graph.

Terraform mới quyết định thứ tự thực thi.

Điều này có nghĩa là.

Ngay cả khi bạn đổi vị trí hai Resource.

resource "aws_instance" "web" {
 
  ...
 
}
 
resource "aws_security_group" "web" {
 
  ...
 
}

Terraform vẫn tạo Security Group trước.

Bởi vì Dependency Graph không phụ thuộc vào thứ tự trong file.

Nó phụ thuộc vào mối quan hệ giữa các Resource.

Provider chính là người xây dựng Dependency Graph?

Không hẳn.

Đây là điểm rất dễ bị nhầm.

Terraform Core chịu trách nhiệm xây dựng Dependency Graph.

Provider không tham gia vào quá trình này.

Provider chỉ chịu trách nhiệm trả lời những câu hỏi như:

• Resource này có những thuộc tính gì?
• Thuộc tính nào là bắt buộc?
• Khi tạo Resource cần gọi API nào?
• Khi xoá Resource cần gọi API nào?

Terraform Core sẽ sử dụng những thông tin đó để xây dựng đồ thị.

Configuration

↓

Terraform Core

↓

Dependency Graph

↓

Execution Plan

↓

Provider

↓

Cloud API

Điều này cũng giải thích vì sao Terraform Core có thể làm việc với hàng nghìn Provider khác nhau mà không cần biết chi tiết cách từng Provider được triển khai.

Provider Schema

Làm sao Terraform biết rằng.

instance_type

là hợp lệ.

Trong khi.

instance_size

lại báo lỗi.

Câu trả lời nằm ở Provider Schema.

Mỗi Provider sẽ khai báo toàn bộ schema của từng Resource.

Ví dụ.

aws_instance

├── ami
├── instance_type
├── subnet_id
├── tags
├── user_data
└── ...

Terraform sẽ sử dụng Schema này để:

• validate Configuration
• xây dựng Execution Plan
• phát hiện thay đổi
• sinh thông báo lỗi khi người dùng khai báo sai

Nói cách khác.

Terraform Core không biết instance_type nghĩa là gì.

Chính AWS Provider nói với Terraform rằng:

aws_instance có thuộc tính tên là instance_type, kiểu dữ liệu là string, bắt buộc phải có và sẽ được dùng khi gọi API tạo EC2.

Đó cũng là lý do khi Provider được nâng cấp.

Một số Resource hoặc Attribute mới sẽ tự động xuất hiện mà không cần thay đổi Terraform Core.

Khai báo Provider

Đến đây chúng ta đã hiểu Provider là gì.

Vậy Terraform biết phải sử dụng Provider nào bằng cách nào?

Thông thường, mọi project đều bắt đầu bằng việc khai báo Provider.

Ví dụ.

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"
    }
  }
}

Trong đó.

source

xác định Provider sẽ được tải từ đâu.

Ví dụ.

hashicorp/aws

hay.

cloudflare/cloudflare

vercel/vercel

supabase/supabase

Còn.

version

cho Terraform biết phiên bản nào được phép sử dụng.

Đây là một điểm rất quan trọng trong môi trường production.

required_providers và provider là hai khái niệm khác nhau

Đây là chỗ rất nhiều người mới học Terraform bị nhầm.

Họ thường nghĩ.

required_providers

và.

provider

là một.

Thực tế.

Hai block này có nhiệm vụ hoàn toàn khác nhau.

Ví dụ.

terraform {
 
  required_providers {
 
    aws = {
 
      source  = "hashicorp/aws"
 
      version = "~> 6.0"
 
    }
 
  }
 
}
 
provider "aws" {
 
  region = "ap-southeast-1"
 
}

Trong đó.

required_providers

chỉ trả lời câu hỏi.

Cần sử dụng Provider nào?

Còn.

provider

trả lời câu hỏi.

Provider đó sẽ được cấu hình như thế nào?

Ví dụ.

• Region
• Credentials
• Retry
• Custom Endpoint

Terraform sẽ tải Provider trước.

Sau đó mới khởi tạo Provider với phần Configuration.

terraform init thực sự làm gì?

Một trong những lệnh đầu tiên mà chúng ta học là.

terraform init

Đa số mọi người chỉ nhớ.

Init để khởi tạo project.

Nhưng thực tế.

Terraform đang thực hiện rất nhiều công việc.

Ví dụ.

Đọc Configuration

↓

Tìm required_providers

↓

Kiểm tra Lock File

↓

Download Provider

↓

Giải nén

↓

Lưu vào local cache

↓

Khởi tạo Backend

Nếu Provider đã tồn tại.

Terraform sẽ không tải lại.

Điều này giúp việc chạy Terraform nhanh hơn rất nhiều.

Terraform Registry

Provider thường được tải từ Terraform Registry.

https://registry.terraform.io

Đây là nơi HashiCorp và cộng đồng phát hành Provider.

Ví dụ.

hashicorp/aws

hashicorp/azurerm

hashicorp/google

cloudflare/cloudflare

vercel/vercel

supabase/supabase

Khi chạy.

terraform init

Terraform sẽ:

• tìm đúng Provider
• tải đúng phiên bản
• xác minh checksum
• lưu vào local cache

Sau đó.

Terraform Core sẽ giao tiếp với Provider này trong suốt quá trình Plan và Apply.

Vì sao cần khóa phiên bản Provider?

Nhiều người mới học thường bỏ qua dòng.

version = "~> 6.0"

Hoặc thậm chí.

Không khai báo Version.

Điều này khá nguy hiểm.

Giả sử hôm nay.

AWS Provider đang ở phiên bản:

6.0

Ngày mai.

HashiCorp phát hành:

7.0

Trong phiên bản mới.

Một Resource có thể:

• đổi tên Attribute
• thay đổi hành vi mặc định
• loại bỏ Resource cũ
• thêm Validation mới

Nếu project tự động cập nhật.

Một ngày đẹp trời.

terraform plan

có thể xuất hiện hàng trăm thay đổi ngoài ý muốn.

Đó là lý do hầu hết project production đều khóa phiên bản Provider.

.terraform.lock.hcl

Sau lần chạy đầu tiên.

Terraform sẽ sinh ra file.

.terraform.lock.hcl

Đây không phải file cấu hình.

Nó giống như.

package-lock.json

của npm.

Hoặc.

pom.lock

nếu Java có lock file.

File này lưu:

• phiên bản Provider
• checksum
• thông tin xác minh

Ví dụ.

Developer A.

terraform init

Developer B.

terraform init

Cả hai đều nhận đúng cùng một phiên bản Provider.

Điều này giúp giảm rất nhiều lỗi "máy mình chạy được".

Một project có thể sử dụng nhiều Provider

Terraform không giới hạn mỗi project chỉ dùng một Provider.

Ví dụ.

Một hệ thống có thể cần.

• AWS để chạy Application
• Cloudflare để quản lý DNS
• Vercel để deploy Frontend
• GitHub để quản lý Repository
• Supabase để quản lý Database

Khi đó.

Configuration có thể như sau.

terraform {
 
  required_providers {
 
    aws = {
 
      source = "hashicorp/aws"
 
    }
 
    cloudflare = {
 
      source = "cloudflare/cloudflare"
 
    }
 
    vercel = {
 
      source = "vercel/vercel"
 
    }
 
  }
 
}

Terraform sẽ tải toàn bộ Provider cần thiết.

Sau đó.

Mỗi Resource sẽ tự biết cần sử dụng Provider nào.

Ví dụ.

aws_instance

↓

AWS Provider

cloudflare_dns_record

↓

Cloudflare Provider

vercel_project

↓

Vercel Provider

Đây là một trong những điểm mạnh nhất của Terraform.

Một Execution Plan duy nhất.

Nhưng có thể quản lý hạ tầng trên rất nhiều nền tảng khác nhau.

Provider Alias

Đôi khi.

Một Provider cần nhiều cấu hình khác nhau.

Ví dụ.

Hai AWS Region.

provider "aws" {
 
  region = "ap-southeast-1"
 
}
 
provider "aws" {
 
  alias  = "tokyo"
 
  region = "ap-northeast-1"
 
}

Sau đó.

Resource có thể chỉ định rõ Provider.

resource "aws_instance" "web" {
 
  provider = aws.tokyo
 
  ...
 
}

Terraform sẽ sử dụng Provider có Alias tương ứng.

Đây là tính năng rất hữu ích khi làm việc với:

• Multi Region
• Multi Account
• Multi Subscription
• Multi Cluster

Có nên tạo nhiều Provider?

Câu trả lời là.

Chỉ khi thực sự cần.

Nếu toàn bộ Infrastructure chỉ nằm trong một AWS Account.

Một Provider là đủ.

Việc tạo quá nhiều Provider Alias sẽ khiến:

• Configuration khó đọc hơn
• Dependency Graph phức tạp hơn
• Dễ cấu hình nhầm Region hoặc Credentials

Trong production.

Chúng ta thường chỉ tạo Alias khi có lý do rõ ràng.

Ví dụ.

• Disaster Recovery
• Cross Region Replication
• Multi Account Architecture
• Shared Services

Thay vì tạo Alias chỉ vì "để sau này có thể dùng".

Đây cũng là một nguyên tắc quen thuộc trong thiết kế phần mềm.

Đừng thiết kế cho những yêu cầu chưa tồn tại.

Provider không chỉ dành cho Cloud

Khi nhắc đến Terraform.

Đa số mọi người sẽ nghĩ ngay đến:

• AWS
• Azure
• Google Cloud

Điều này đúng.

Nhưng chưa đầy đủ.

Terraform Provider có thể được xây dựng cho bất kỳ hệ thống nào có API.

Ví dụ.

Cloud

├── AWS
├── Azure
├── Google Cloud
└── Oracle Cloud

Container

├── Kubernetes
├── Docker
└── Helm

Developer Platform

├── GitHub
├── GitLab
├── Vercel
└── Netlify

Database

├── PostgreSQL
├── Snowflake
└── Supabase

Networking

├── Cloudflare
├── Fastly
└── Akamai

Điều này có nghĩa là.

Infrastructure không chỉ là Virtual Machine hay Network.

Nếu một hệ thống có API đủ mạnh.

Terraform hoàn toàn có thể quản lý nó.

Terraform không quản lý Server

Đây là một quan điểm rất quan trọng.

Terraform không được tạo ra để quản lý Server.

Terraform được tạo ra để quản lý Infrastructure thông qua API.

Ví dụ.

Bạn có thể dùng Terraform để tạo.

• GitHub Repository
• GitHub Team
• Branch Protection Rule
• Vercel Project
• Cloudflare DNS Record
• PagerDuty Service
• Datadog Dashboard

Không có bất kỳ Virtual Machine nào ở đây.

Nhưng tất cả vẫn là Infrastructure.

Đó cũng là lý do Terraform ngày càng được sử dụng nhiều ngoài phạm vi Cloud Computing.

Provider có phải lúc nào cũng gọi API không?

Gần như là có.

Mỗi Resource đều được Provider ánh xạ thành một hoặc nhiều lời gọi API.

Ví dụ.

resource "aws_s3_bucket" "blog" {
 
  bucket = "my-blog"
 
}

Khi Apply.

AWS Provider sẽ thực hiện các bước tương tự.

Validate Input

↓

Build AWS SDK Request

↓

Call CreateBucket API

↓

Receive Response

↓

Convert Response

↓

Return Result

Terraform Core không biết API nào được gọi.

Nó chỉ biết rằng.

Provider đã hoàn thành việc tạo Resource.

Điều này cũng đúng với các thao tác:

• Update
• Read
• Delete

Điều gì xảy ra khi Provider gặp lỗi?

Ví dụ.

AWS trả về.

403 Access Denied

Hoặc.

429 Too Many Requests

Hay.

500 Internal Server Error

Terraform Core không tự xử lý những lỗi này.

Provider sẽ:

• nhận lỗi từ API
• phân tích lỗi
• chuyển thành thông báo dễ hiểu hơn
• trả lại cho Terraform Core

Ví dụ.

Error: creating EC2 Instance

UnauthorizedOperation

You are not authorized to perform this operation.

Thông báo này thực chất đến từ Provider.

Terraform Core chỉ hiển thị lại cho người dùng.

Đó là lý do chất lượng thông báo lỗi phụ thuộc khá nhiều vào từng Provider.

Không phải Provider nào cũng giống nhau

HashiCorp cung cấp rất nhiều Provider chính thức.

Ví dụ.

• AWS
• AzureRM
• Google
• Kubernetes

Những Provider này thường có:

• tài liệu đầy đủ
• cộng đồng lớn
• được cập nhật thường xuyên
• tương thích tốt với Terraform mới

Ngoài ra còn có rất nhiều Provider do cộng đồng phát triển.

Chất lượng của chúng có thể rất khác nhau.

Một số Provider được bảo trì rất tốt.

Một số khác có thể đã ngừng phát triển từ lâu.

Trước khi sử dụng một Provider trong production.

Bạn nên kiểm tra:

• tần suất phát hành phiên bản mới
• số lượng người sử dụng
• issue đang mở
• tài liệu
• khả năng tương thích với phiên bản Terraform hiện tại

Đừng chỉ nhìn thấy Provider tồn tại trên Registry mà mặc định cho rằng nó phù hợp với production.

Những hiểu lầm phổ biến về Provider

Terraform tự gọi Cloud API

Không đúng.

Terraform Core gần như không biết gì về Cloud API.

Toàn bộ việc giao tiếp đều được thực hiện thông qua Provider.

Một Provider chỉ có một Resource

Không đúng.

AWS Provider hiện hỗ trợ hàng nghìn Resource và Data Source.

Điều tương tự cũng xảy ra với Azure và Google Cloud.

Provider chỉ dùng để tạo Resource

Không đúng.

Provider còn chịu trách nhiệm:

• đọc Data Source
• validate cấu hình
• ánh xạ Resource Schema
• gọi API Create
• gọi API Read
• gọi API Update
• gọi API Delete
• chuyển đổi dữ liệu giữa Terraform và nền tảng bên ngoài

Có thể nói.

Provider là "cầu nối" giữa Terraform Core và toàn bộ thế giới bên ngoài.

Chỉ Cloud mới có Provider

Không đúng.

Ngày nay Terraform được sử dụng để quản lý rất nhiều loại hệ thống.

Từ GitHub.

Đến Kubernetes.

Từ Cloudflare.

Đến Vercel.

Từ Datadog.

Đến PagerDuty.

Chỉ cần hệ thống có API phù hợp.

Hoàn toàn có thể xây dựng một Provider cho nó.

Tổng kết

Trong bài này chúng ta đã tìm hiểu một trong những thành phần quan trọng nhất của Terraform.

Đó là Provider.

Thay vì tích hợp trực tiếp với từng nền tảng.

Terraform Core chỉ tập trung vào những nhiệm vụ cốt lõi như:

• phân tích Configuration
• xây dựng Dependency Graph
• so sánh Terraform State
• tạo Execution Plan

Mọi công việc liên quan đến nền tảng cụ thể sẽ được giao cho Provider.

Chính kiến trúc này giúp Terraform có thể hỗ trợ hàng nghìn nền tảng khác nhau mà không cần thay đổi Terraform Core.

Chúng ta cũng đã hiểu:

• Provider thực chất là một chương trình độc lập.
• Terraform Core và Provider giao tiếp thông qua RPC.
• Resource và Data Source đều được triển khai bởi Provider.
• required_providers và provider có hai vai trò hoàn toàn khác nhau.
• Một project có thể sử dụng nhiều Provider để quản lý hạ tầng trên nhiều nền tảng cùng lúc.

Có thể nói.

Nếu Terraform State là trí nhớ của Terraform, thì Provider chính là đôi tay giúp Terraform tương tác với thế giới bên ngoài.

Ở bài tiếp theo, chúng ta sẽ tiếp tục tìm hiểu một khái niệm rất hữu ích nhưng cũng thường bị sử dụng chưa đúng:

Terraform Data Source — Khi nào nên đọc hạ tầng thay vì tạo mới?

Đây cũng là bước giúp chúng ta hiểu rõ hơn cách kết hợp giữa Infrastructure đã tồn tại và Infrastructure được Terraform quản lý trong các hệ thống production.