Infrastructure as Code và GitOps là gì? Hướng dẫn Terraform, OpenTofu, Argo CD và Flux cho đội IT

Ảnh đã kiểm tra hiển thị được trước khi đưa vào file. Ảnh trích xuất từ tài liệu HashiCorp Terraform, file PNG, không phải SVG.¹

Ảnh đã kiểm tra hiển thị được trước khi đưa vào file. Ảnh trích xuất từ tài liệu HashiCorp Terraform, file PNG, không phải SVG.²

Ảnh đã kiểm tra hiển thị được trước khi đưa vào file. Ảnh trích xuất từ tài liệu Argo CD, file PNG, không phải SVG.³

Tóm tắt nhanh

Infrastructure as Code hay IaC là cách quản lý hạ tầng bằng file cấu hình có thể version control, review, test và tự động hóa. Thay vì bấm tay trong cloud console để tạo VM, VPC, database, firewall, DNS hoặc Kubernetes resource, bạn mô tả trạng thái mong muốn bằng code rồi dùng công cụ như Terraform hoặc OpenTofu để tạo, thay đổi và quản lý vòng đời hạ tầng.

HashiCorp mô tả Terraform là công cụ infrastructure as code cho phép build, change và version cloud/on-prem resources an toàn và hiệu quả; workflow lõi gồm Write, Plan và Apply.⁴ OpenTofu cũng mô tả mình là công cụ IaC cho phép định nghĩa cloud và on-prem resources trong file cấu hình human-readable, có thể version, reuse và share.⁵

GitOps là cách vận hành hạ tầng và ứng dụng trong đó Git là nguồn sự thật cho desired state. Flux mô tả GitOps là cách quản lý infrastructure và applications sao cho toàn bộ hệ thống được mô tả declaratively, version controlled, và có automation đảm bảo môi trường deployed khớp với trạng thái trong Git repositories.⁶ Argo CD là công cụ continuous delivery GitOps cho Kubernetes; nó theo mô hình dùng Git repositories làm source of truth cho desired application state.⁷

Nói ngắn gọn: IaC quản lý hạ tầng bằng code; GitOps dùng Git và controller để tự động đưa hệ thống về đúng trạng thái đã khai báo.

Vì sao cần IaC và GitOps?

Nếu quản lý hạ tầng thủ công, đội IT dễ gặp các vấn đề:

• không biết ai đã đổi cấu hình;
• môi trường dev/staging/prod khác nhau;
• rollback khó;
• cấu hình firewall/security group sai;
• tài nguyên cloud bị tạo thừa;
• không có review trước khi thay đổi;
• tài liệu không khớp thực tế;
• deployment phụ thuộc người có kinh nghiệm;
• disaster recovery chậm vì phải dựng lại thủ công.

IaC và GitOps thay đổi mô hình:

Code trong Git
  ↓
Review qua Pull Request
  ↓
Plan / diff / policy check
  ↓
Apply hoặc reconcile tự động
  ↓
Audit trail rõ ràng

Với cách này, hạ tầng và ứng dụng được quản lý gần giống phần mềm: có version, review, test, release, rollback và ownership.

IaC không phải là gì?

IaC không tự động làm hạ tầng an toàn. Nếu bạn viết sai security group, IAM policy hoặc Kubernetes manifest, công cụ vẫn có thể tạo cấu hình sai. Vì vậy IaC cần đi kèm review, scan, policy và monitoring.

GitOps không phải là gì?

GitOps tốt yêu cầu kỷ luật: không sửa production trực tiếp nếu không đồng bộ lại Git; mọi thay đổi phải đi qua review.

Terraform và OpenTofu hoạt động thế nào?

Terraform/OpenTofu thường có ba bước chính:

Write → Plan → Apply

Write

Bạn viết file cấu hình mô tả hạ tầng mong muốn.

Ví dụ Terraform/OpenTofu đơn giản:

resource "aws_s3_bucket" "logs" {
  bucket = "company-prod-logs"
}

resource "aws_s3_bucket_versioning" "logs" {
  bucket = aws_s3_bucket.logs.id

  versioning_configuration {
    status = "Enabled"
  }
}

Plan

Công cụ so sánh cấu hình với state và hạ tầng thực tế, sau đó tạo execution plan.

terraform plan
# hoặc
tofu plan

Plan giúp bạn thấy trước tài nguyên nào sẽ create, update, replace hoặc destroy.

Apply

Sau khi review, bạn áp thay đổi:

terraform apply
# hoặc
tofu apply

OpenTofu docs cũng mô tả workflow Write, Plan, Apply tương tự Terraform.⁸

State là gì và vì sao quan trọng?

State là file/record mô tả hạ tầng mà Terraform/OpenTofu đang quản lý. Nó ánh xạ giữa resource trong code và resource thật trong cloud hoặc API provider.

Ví dụ:

aws_instance.web → i-0abcd1234
aws_db_instance.main → database production thật

State quan trọng vì:

• dùng để tính plan;
• biết resource nào đang được quản lý;
• chứa metadata;
• có thể chứa dữ liệu nhạy cảm;
• nếu mất state, việc quản lý hạ tầng trở nên rủi ro;
• nếu state bị lộ, attacker có thể biết cấu trúc hạ tầng và secret output.

Khuyến nghị:

• không lưu state local cho team production;
• dùng remote backend;
• bật locking;
• mã hóa state;
• hạn chế quyền đọc state;
• backup state;
• không output secret nếu không cần;
• không commit state vào Git.

Backend và locking

Remote backend giúp nhiều người cùng làm việc an toàn hơn.

Ví dụ backend S3 với locking:

terraform {
  backend "s3" {
    bucket         = "company-terraform-state"
    key            = "prod/network/terraform.tfstate"
    region         = "ap-southeast-1"
    dynamodb_table = "terraform-locks"
    encrypt        = true
  }
}

Mục tiêu:

• state lưu tập trung;
• apply không đè nhau;
• audit được truy cập;
• backup dễ hơn;
• phù hợp CI/CD.

Nếu không có locking, hai người apply cùng lúc có thể tạo trạng thái hỏng.

Module là gì?

Module là cách đóng gói hạ tầng tái sử dụng.

Ví dụ module VPC:

module "vpc" {
  source = "../modules/vpc"

  name       = "prod"
  cidr_block = "10.0.0.0/16"
  azs        = ["ap-southeast-1a", "ap-southeast-1b"]
}

Lợi ích:

• chuẩn hóa cấu hình;
• giảm copy-paste;
• enforce best practices;
• dễ review;
• giúp platform team cung cấp building blocks.

Sai lầm thường gặp:

• module quá phức tạp;
• module không version;
• input quá nhiều;
• output lộ secret;
• thay module gây breaking change không kiểm soát.

Drift là gì?

Drift xảy ra khi hạ tầng thực tế khác với cấu hình trong Git/IaC.

Ví dụ:

Git: security group chỉ mở port 443
Thực tế: ai đó mở thêm port 22 từ 0.0.0.0/0 trên cloud console

Cách xử lý:

• hạn chế quyền sửa tay;
• chạy plan định kỳ;
• dùng drift detection;
• quản lý thay đổi qua PR;
• cảnh báo khi có drift nguy hiểm;
• nếu cần hotfix thủ công, cập nhật lại code ngay.

GitOps controller như Argo CD/Flux cũng phát hiện drift giữa desired state trong Git và trạng thái Kubernetes thực tế.

GitOps với Kubernetes

Trong Kubernetes, GitOps thường hoạt động như sau:

Developer/Platform Engineer
  ↓ Pull Request
Git repository chứa manifests/Helm/Kustomize
  ↓
GitOps controller trong cluster
  ↓
So sánh desired state với live state
  ↓
Sync/reconcile
  ↓
Kubernetes cluster đạt trạng thái mong muốn

Argo CD docs nói Argo CD theo GitOps pattern, dùng Git repositories làm source of truth, và tự động triển khai desired application state tới target environments.⁹ Flux docs mô tả reconciliation là đảm bảo state thực tế khớp với desired state được khai báo trong Git hoặc nguồn khác.¹⁰

Argo CD là gì?

Argo CD là công cụ declarative GitOps continuous delivery cho Kubernetes.⁷

Điểm mạnh:

• UI trực quan;
• so sánh desired state và live state;
• sync tự động hoặc thủ công;
• hỗ trợ Helm, Kustomize, Jsonnet, YAML;
• quản lý nhiều cluster;
• SSO và RBAC;
• rollback về commit cũ;
• health status;
• audit trails;
• Prometheus metrics.

Phù hợp nếu team muốn giao diện rõ ràng, onboarding dễ và quan sát trạng thái app tốt.

Flux CD là gì?

Flux là bộ GitOps controllers cho Kubernetes. Flux concepts mô tả GitOps Toolkit là tập hợp controllers, APIs và Go packages dùng để xây continuous delivery workflows trên Kubernetes theo GitOps principles.¹¹

Điểm mạnh:

• Kubernetes-native;
• reconciliation model rõ;
• hỗ trợ GitRepository, OCIRepository, HelmRepository, Bucket;
• có thể dùng OCI artifacts làm source;
• phù hợp automation;
• tích hợp tốt với SOPS/Sealed Secrets và cloud-native workflow.

Phù hợp nếu team thích declarative CRD, automation sâu và ít phụ thuộc UI.

Terraform/OpenTofu và GitOps khác nhau thế nào?

Hai mô hình không thay thế nhau. Chúng thường đi cùng nhau:

Terraform/OpenTofu tạo cluster + network + IAM + database
Argo CD/Flux deploy applications vào cluster

Mô hình repo cho IaC

Mono repo đơn giản

infra/
  modules/
    vpc/
    eks/
    database/
  envs/
    dev/
    staging/
    prod/

Phù hợp team nhỏ.

Multi repo

infra-modules/
infra-live-dev/
infra-live-prod/
platform-gitops/
app-manifests/

Phù hợp tổ chức lớn, cần tách quyền.

App repo + environment repo

app-repo/
  src/
  Dockerfile
  helm-chart/

env-repo/
  clusters/
    prod/
      apps/
        checkout/

Phù hợp GitOps: app team build artifact; environment repo quyết định version nào deploy.

Cấu trúc GitOps repo mẫu

gitops/
  clusters/
    prod/
      apps/
        checkout/
          kustomization.yaml
          deployment.yaml
          service.yaml
        payments/
      platform/
        ingress/
        cert-manager/
        monitoring/
    staging/
  base/
    checkout/
    payments/
  policies/

Nguyên tắc:

• tách base và overlay;
• tách prod/staging;
• có owner rõ;
• không commit secret plaintext;
• mọi thay đổi qua PR;
• dùng branch protection;
• đặt policy scan trước merge.

Bảo mật IaC

Checklist:

• không commit credentials vào Git;
• không output secret;
• state remote + encrypted + locked;
• IAM least privilege cho CI/CD;
• plan trong PR;
• apply chỉ sau approval;
• giới hạn quyền destroy production;
• scan IaC bằng Checkov/Trivy/tfsec;
• policy-as-code bằng OPA/Sentinel/Kyverno nếu phù hợp;
• pin provider version;
• review module source;
• tách workspace/environment rõ;
• audit cloud changes.

Ví dụ pin provider:

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

Bảo mật GitOps

Checklist:

• repo Git có branch protection;
• PR required reviews;
• commit signing nếu cần;
• không commit secret plaintext;
• dùng SOPS/Sealed Secrets/External Secrets;
• Argo CD/Flux RBAC tối thiểu;
• không cho mọi người admin GitOps controller;
• tách quyền sync prod;
• admission policy chặn manifest nguy hiểm;
• image pin bằng digest;
• verify image signature nếu có;
• audit sync history;
• alert khi app OutOfSync/Degraded;
• backup GitOps repo và controller config.

Secrets trong GitOps

Không nên commit Secret YAML plaintext:

apiVersion: v1
kind: Secret
data:
  password: cGFzc3dvcmQ=

Base64 không phải encryption. Thay vào đó dùng:

• SOPS + KMS/age/PGP;
• Sealed Secrets;
• External Secrets Operator;
• cloud secret manager;
• Vault.

Ví dụ mô hình:

Git repo
  ↓ encrypted secret / external secret reference
GitOps controller
  ↓ decrypt hoặc sync từ secret manager
Kubernetes Secret

Policy-as-Code

Policy-as-code giúp chặn lỗi trước khi hạ tầng được tạo hoặc workload được deploy.

Ví dụ policy:

Không cho S3 bucket public
Không cho security group mở 0.0.0.0/0 port 22
Không cho Kubernetes pod chạy privileged
Không cho image tag latest
Bắt buộc resource limits
Bắt buộc label owner/team/environment

Chạy ở nhiều điểm:

pre-commit
  ↓
CI pull request
  ↓
Terraform plan policy check
  ↓
Admission controller trong Kubernetes
  ↓
Drift/compliance scan định kỳ

CI/CD workflow cho IaC

Pull Request
  ↓
terraform fmt / tofu fmt
  ↓
terraform validate / tofu validate
  ↓
IaC security scan
  ↓
terraform plan / tofu plan
  ↓
Comment plan vào PR
  ↓
Approval
  ↓
Apply qua protected environment
  ↓
Post-apply drift/compliance check

Không nên auto-apply production từ mọi branch. Production nên có protected environment và approval.

GitOps workflow cho ứng dụng

App code merge
  ↓
CI build image
  ↓
Scan image + sign image
  ↓
Push registry
  ↓
Update GitOps repo image tag/digest
  ↓
PR review
  ↓
Merge
  ↓
Argo CD/Flux sync
  ↓
Health check + metrics + rollback nếu cần

Với production, nên pin image bằng digest:

image: registry.example.com/checkout@sha256:abc123...

Roadmap 30/60/90 ngày

Ngày 1–30: IaC nền tảng

• Kiểm kê hạ tầng đang quản lý tay.
• Chọn Terraform hoặc OpenTofu.
• Tạo repo infra.
• Viết module nhỏ cho network hoặc staging.
• Thiết lập remote backend và locking.
• Bật branch protection.
• Chạy fmt/validate/plan trong PR.
• Không commit state/secrets.
• Scan IaC cơ bản bằng Trivy/Checkov.
• Document workflow.

Ngày 31–60: chuẩn hóa và bảo mật

• Tách env dev/staging/prod.
• Tạo modules tái sử dụng.
• Pin provider/module versions.
• Thêm policy-as-code.
• Giới hạn quyền cloud cho CI/CD.
• Thêm approval cho apply prod.
• Bắt đầu drift detection.
• Tạo runbook rollback/state recovery.
• Quản lý secret bằng secret manager.
• Tạo dashboard cost/resource.

Ngày 61–90: GitOps và vận hành

• Cài Argo CD hoặc Flux cho Kubernetes.
• Tạo GitOps repo.
• Deploy app staging bằng GitOps.
• Thêm SOPS/Sealed Secrets/External Secrets.
• Bật RBAC/SSO cho controller.
• Enforce policy admission.
• Sync production app đầu tiên.
• Alert OutOfSync/Degraded.
• Tạo app-of-apps hoặc bootstrap model.
• Review incident: drift, bad apply, leaked secret.

Sai lầm phổ biến

• Commit state vào Git.
• Lưu secret plaintext trong .tfvars.
• Dùng một workspace cho mọi môi trường.
• Không review plan.
• Auto-apply production không approval.
• Dùng IAM admin cho CI/CD.
• Không pin provider/module version.
• Module quá phức tạp.
• Sửa cloud console rồi không cập nhật code.
• Dùng GitOps nhưng vẫn sửa trực tiếp trong cluster.
• Commit Kubernetes Secret base64 vào Git.
• Cho GitOps controller quyền quá rộng.
• Không có drift detection.
• Không có rollback runbook.

Tooling tham khảo

FAQ

Infrastructure as Code là gì?

Infrastructure as Code là cách định nghĩa và quản lý hạ tầng bằng file cấu hình có thể version control, review, reuse và tự động hóa. Terraform và OpenTofu là hai công cụ IaC phổ biến.⁴⁵

GitOps là gì?

GitOps là cách quản lý hạ tầng và ứng dụng bằng desired state trong Git, kết hợp automation để đảm bảo môi trường deployed khớp với trạng thái trong Git.⁶

Terraform và OpenTofu khác gì?

Terraform là công cụ IaC của HashiCorp. OpenTofu là công cụ IaC cộng đồng, fork từ Terraform và thuộc hệ sinh thái Linux Foundation. Cả hai có workflow tương tự: Write, Plan, Apply.⁴⁵

Argo CD và Flux khác gì?

Argo CD thường nổi bật với UI, app view và workflow GitOps dễ quan sát. Flux thiên về Kubernetes-native controllers và automation sâu. Cả hai đều dùng GitOps principles để reconcile trạng thái Kubernetes.

Có nên dùng GitOps cho mọi thứ không?

Không nhất thiết. GitOps rất phù hợp Kubernetes và workload declarative. Với tài nguyên cloud như VPC, IAM, database, Terraform/OpenTofu thường phù hợp hơn. Nhiều team dùng cả hai.

Secret có nên lưu trong GitOps repo không?

Không nên lưu plaintext. Nếu cần lưu trong Git, hãy dùng SOPS hoặc Sealed Secrets; tốt hơn nữa là dùng External Secrets với secret manager.

Kết luận

Infrastructure as Code và GitOps là hai nền tảng quan trọng của DevOps hiện đại. IaC giúp hạ tầng có version, review, plan, apply và tái lập. GitOps giúp Kubernetes/application deployment có source of truth rõ ràng, drift detection và reconciliation tự động. Khi kết hợp đúng, đội IT có thể giảm thao tác thủ công, tăng auditability, rollback dễ hơn và chuẩn hóa vận hành.

Cách triển khai thực tế là bắt đầu nhỏ: đưa một phần hạ tầng vào Terraform/OpenTofu, dùng remote state an toàn, chạy plan trong PR, thêm scan/policy, rồi mới mở rộng sang GitOps với Argo CD hoặc Flux. Bảo mật phải đi cùng từ đầu: không commit secrets, không cấp quyền CI/CD quá rộng, không auto-apply production thiếu approval và không để controller GitOps có quyền vượt nhu cầu.

Nguồn tham khảo

Footnotes

1. HashiCorp Terraform docs image. intro-terraform-apis.png. https://web-unified-docs-hashicorp.vercel.app/api/assets/terraform/latest/img/docs/intro-terraform-apis.png ↩

2. HashiCorp Terraform docs image. intro-terraform-workflow.png. https://web-unified-docs-hashicorp.vercel.app/api/assets/terraform/latest/img/docs/intro-terraform-workflow.png ↩

3. Argo CD docs image. argocd_architecture.png. https://argo-cd.readthedocs.io/en/stable/assets/argocd_architecture.png ↩

4. HashiCorp Developer. “What is Terraform?” https://developer.hashicorp.com/terraform/intro ↩ ↩² ↩³

5. OpenTofu Docs. “What is OpenTofu?” https://opentofu.org/docs/intro/ ↩ ↩² ↩³

6. Flux Docs. “GitOps.” https://fluxcd.io/flux/concepts/ ↩ ↩²

7. Argo CD Docs. “What Is Argo CD?” https://argo-cd.readthedocs.io/en/stable/ ↩ ↩²

8. OpenTofu Docs. Core OpenTofu workflow. https://opentofu.org/docs/intro/ ↩

9. Argo CD Docs. “How it works.” https://argo-cd.readthedocs.io/en/stable/ ↩

10. Flux Docs. “Reconciliation.” https://fluxcd.io/flux/concepts/ ↩

11. Flux Docs. “GitOps Toolkit.” https://fluxcd.io/flux/concepts/ ↩