Hạ tầng dưới dạng mã (IaC, Infrastructure as Code)

1. Tổng quan

A. Định nghĩa

IaC (Infrastructure as Code) là phương thức khai báo trạng thái mong muốn của hạ tầng IT như máy chủ·mạng·lưu trữ·chính sách bảo mật bằng mã (tệp cấu hình), rồi thực thi mã đó để tự động cấp phát (provisioning)·thay đổi·quản lý hạ tầng. Nó thay thế các thiết lập thủ công trên console bằng mã có thể quản lý phiên bản.

Bản chất của IaC là 'đối xử với hạ tầng như phần mềm'. Trước đây, khi tăng thêm máy chủ hay thay đổi quy tắc tường lửa, người phụ trách phải nhấp chuột và gõ lệnh từng bước trên console quản trị. Cách này chậm, hay sai sót, và trên hết dẫn đến tình trạng không ai biết chính xác "vì sao máy chủ này có cấu hình khác máy chủ kia". Hiện tượng các dấu vết sửa tay tích tụ dần theo thời gian khiến hạ tầng thực tế lệch khỏi tài liệu·ý đồ được gọi là trôi cấu hình (configuration drift), một rủi ro vận hành tiêu biểu gây khó khăn cho việc truy vết nguyên nhân sự cố và khôi phục.

IaC khai báo trạng thái mong muốn của hạ tầng bằng mã và thực thi mã đó để tạo hạ tầng. Khi đó, hạ tầng được tài liệu hóa bằng mã, có thể theo dõi phiên bản·review mã·tái sử dụng nhờ quản lý cấu hình như Git, và có thể tái tạo y hệt các môi trường phát triển·kiểm thử·vận hành bằng cùng một mã. Phần lớn vấn đề kinh điển "trên máy tôi thì chạy được" bắt nguồn từ khác biệt cấu hình môi trường, và IaC loại bỏ khác biệt đó bằng cách cố định chính cấu hình thành mã. Khi kết hợp với API đám mây, có thể cấu hình đồng nhất hàng trăm máy chủ trong vài phút, và thu hồi chúng bằng một dòng mã khi không còn cần. Tức là IaC không chỉ là công cụ tự động hóa mà là sự chuyển đổi mô hình, biến vận hành hạ tầng từ 'tay nghề thủ công' thành 'kỹ thuật có thể kiểm chứng'.

B. Bối cảnh ra đời và sự cần thiết

Có ba áp lực khiến IaC trở nên thiết yếu. Thứ nhất, tính co giãn của đám mây. Đám mây cho phép tăng giảm tài nguyên tức thì qua API, nhưng con người không thể theo kịp sự linh hoạt này bằng tay. Không có định nghĩa tự động, tính co giãn lại trở thành hỗn loạn. Thứ hai, sự bùng nổ về quy mô·tần suất thay đổi do microservice·container. Trong môi trường hàng trăm dịch vụ đòi hỏi hạ tầng khác nhau và được triển khai nhiều lần mỗi ngày, quản lý thủ công không thể đáp ứng tốc độ·tính nhất quán·khả năng tái tạo. Thứ ba, văn hóa DevOps. Để xóa nhòa ranh giới giữa phát triển và vận hành, tự động hóa triển khai, hạ tầng cũng phải đưa được vào pipeline như mã ứng dụng. Ba áp lực này đan xen, biến IaC thành kỹ năng cơ bản của vận hành cloud native.

2. Cách thức hoạt động: Khai báo vs Mệnh lệnh

flowchart LR
  DEV["Lập trình viên/Vận hành viên"] --> CODE["Mã hạ tầng<br/>(tệp định nghĩa cấu hình)"]
  CODE --> VCS["Quản lý cấu hình<br/>(Git·Review·Lịch sử)"]
  VCS --> TOOL["Thực thi công cụ IaC<br/>(plan → apply)"]
  TOOL --> CLOUD["Tự động cấp phát hạ tầng<br/>(Máy chủ·Mạng·Lưu trữ)"]
  TOOL --> STATE["Tệp trạng thái<br/>(theo dõi trạng thái hiện tại)"]
  STATE -. So sánh .-> TOOL
  style TOOL fill:#e8f0fe,stroke:#2f6fed,stroke-width:2px
  style STATE fill:#fde8e8,stroke:#d64545,stroke-width:2px

Có hai cách tiếp cận IaC, và khác biệt giữa chúng nằm ở 'mô tả cái gì'. Khai báo (Declarative) mô tả "trạng thái cuối cùng mong muốn (what)", công cụ tự so sánh với trạng thái hiện tại và chỉ áp dụng những thay đổi cần thiết để đạt trạng thái đó (Terraform·CloudFormation·Pulumi). Người dùng chỉ khai báo 'phải có 3 máy chủ với cấu hình như thế này', còn thủ tục 'hiện có 2 máy nên tạo thêm 1' do công cụ tính toán. Mệnh lệnh (Imperative) mô tả thủ tục "làm gì theo thứ tự nào (how)" (shell script truyền thống, playbook Ansible theo một số quan điểm).

Có lý do rõ ràng khiến kiểu khai báo thường được ưa chuộng. Kiểu khai báo theo dõi trạng thái hiện tại nên tự nhiên bảo đảm tính lũy đẳng (idempotency) — chạy cùng một mã nhiều lần vẫn cho cùng kết quả. Script mệnh lệnh dễ gây tác dụng phụ như chạy hai lần thì sinh thêm hai máy chủ. Ngoài ra, kiểu khai báo có thể hiển thị trước chênh lệch (diff) 'trạng thái hiện tại → trạng thái mong muốn' (plan của Terraform), tạo cơ chế an toàn để review và phê duyệt những gì sẽ thay đổi trước khi áp dụng. Tuy nhiên, ranh giới giữa các công cụ không tuyệt đối. Ansible mô tả thủ tục nhưng thiết kế mỗi tác vụ lũy đẳng nên được dùng gần với kiểu khai báo; trong thực tế, hai tính chất thường đan xen.

Mặt khác, cấp phát (tạo hạ tầng) và quản lý cấu hình (cài đặt·thiết lập) thuộc các tầng khác nhau. Terraform mạnh ở cấp phát — 'tạo ra' tài nguyên như máy chủ·mạng — còn Ansible·Chef·Puppet mạnh ở quản lý cấu hình — 'thiết lập' phần mềm trên máy chủ đã được tạo, vì vậy trong thực tế thường kết hợp cả hai.

Hệ sinh thái công cụ và tiêu chí lựa chọn

Lựa chọn công cụ không nên dựa trên 'cái nào ưu việt hơn' mà trên 'cái nào phù hợp với chiến lược đám mây·năng lực nhân sự của tổ chức'. Terraform là tiêu chuẩn khai báo không phụ thuộc đám mây cụ thể (đa đám mây) với hệ sinh thái provider rộng, nhưng cần quản lý trạng thái riêng. CloudFormation chuyên cho AWS, tiện lợi ở chỗ dịch vụ tự quản lý trạng thái nhưng tính di động thấp. Pulumi mô tả hạ tầng bằng ngôn ngữ lập trình đa dụng như Python·TypeScript nên thân thiện với lập trình viên nhưng kéo theo độ phức tạp của ngôn ngữ·runtime. Ansible thực hiện quản lý cấu hình qua SSH mà không cần agent (agentless) nên rào cản gia nhập thấp. Như vậy, mỗi công cụ có những đánh đổi khác nhau về tính di động·đường cong học tập·cách quản lý trạng thái, nên chọn dựa trên đám mây đang dùng và năng lực ngôn ngữ của đội ngũ là thực tế.

3. Quản lý trạng thái và luồng thực thi

flowchart TD
  W["Viết/Sửa mã"] --> P["plan: so sánh với trạng thái hiện tại"]
  P --> R{"Review·Phê duyệt thay đổi"}
  R -->|Phê duyệt| A["apply: chỉ áp dụng phần thay đổi"]
  R -->|Từ chối| W
  A --> S["Cập nhật tệp trạng thái"]
  S --> M["Phát hiện drift<br/>(thực tế vs mã)"]
  M -->|Không khớp| W
  style A fill:#e8f0fe,stroke:#2f6fed,stroke-width:2px

Trái tim của IaC khai báo là trạng thái (state). Công cụ phải so sánh 'trạng thái mà mã mong muốn' với 'trạng thái hiện tại của hạ tầng thực tế' và chỉ thao tác đúng phần chênh lệch, vì vậy nó duy trì một tệp trạng thái ghi lại trạng thái hiện tại. Tệp trạng thái chính là bản đồ của hạ tầng thực tế, nên nếu tệp này bị hỏng hoặc lệch khỏi thực tế, công cụ có thể đưa ra phán đoán sai (tạo lại tài nguyên đã có, hoặc xóa tài nguyên cần thiết). Do đó, nguyên tắc cơ bản của vận hành là đặt tệp trạng thái trên kho lưu trữ từ xa mà đội ngũ có thể chia sẻ·khóa (locking) (ví dụ: object storage + khóa), ngăn hai người cùng apply làm hỏng trạng thái.

Việc thực thi thường theo luồng plan → review·phê duyệt → apply. Ở bước plan, công cụ trình bày kế hoạch thay đổi dạng con người đọc được như "tạo mới máy chủ này, thay đổi quy tắc kia, xóa volume này". Thay đổi hạ tầng như xóa·tạo lại có thể dẫn thẳng đến gián đoạn dịch vụ, nên việc review trước này là cửa ải quyết định ngăn chặn sự cố. Sau khi phê duyệt, bước apply chỉ phản ánh phần thay đổi và cập nhật trạng thái. Trong quá trình vận hành, có thể phát sinh drift khi ai đó thay đổi tài nguyên thủ công trên console khiến mã và thực tế lệch nhau; cần quản lý phát hiện định kỳ và đưa trở lại theo mã.

4. Hiệu quả kỳ vọng và áp dụng thực tiễn

Hiệu quả của IaC không đơn thuần là 'tiện hơn', mà thể hiện qua nhiều trục nâng cao mức độ trưởng thành vận hành của tổ chức. Cần hiểu rằng mỗi hiệu quả trong bảng dưới đây là kết quả phái sinh từ các nguyên lý 'trạng thái·lũy đẳng·quản lý cấu hình' đã giải thích ở trên.

Xét các ví dụ cụ thể: thứ nhất, các doanh nghiệp dịch vụ quy mô lớn khi mở rộng dịch vụ sang vùng (region) mới đã tái sử dụng mã hạ tầng hiện có để nhân bản môi trường gồm hàng trăm tài nguyên trong vài giờ. Nếu làm bằng tay, công việc này sẽ mất vài tuần và có thể gây sự cố do khác biệt cấu hình tinh vi giữa các vùng. Thứ hai, trong kịch bản khôi phục sau thảm họa (DR), mã IaC chính là 'tài liệu quy trình khôi phục', khi thảm họa xảy ra thì dựng lại hạ tầng đồng nhất ở vùng khác bằng mã, rút ngắn thời gian khôi phục (RTO). Thứ ba, phổ biến là trường hợp đội phát triển tạo môi trường kiểm thử cách ly theo từng tính năng bằng mã khi cần, rồi tự động xóa sau khi kiểm thử, giảm đáng kể chi phí tài nguyên nhàn rỗi vốn luôn được duy trì. Như vậy, giá trị của IaC nổi bật ở các giai đoạn lặp lại·tái tạo·thu hồi hơn là tự động hóa lần đầu.

Nhìn các hiệu quả này ở cấp tổ chức, IaC chuyển vận hành hạ tầng vốn phụ thuộc vào tay nghề cá nhân thành tài sản của đội ngũ. Khi 'tri thức ngầm về cấu hình' mà chỉ người phụ trách nhất định biết được hiện hóa thành mã, ngay cả khi thay đổi nhân sự hay ứng phó trực sự cố (on-call), có thể đọc ngay cấu trúc và ý đồ của hạ tầng từ mã. Ngoài ra, về mặt kiểm toán (audit), ai đã thay đổi gì, khi nào và vì sao đều được lưu trong lịch sử quản lý cấu hình, giúp ứng phó quy định·tuân thủ dễ dàng hơn. Đây là lợi thế đặc biệt quan trọng trong các ngành kiểm soát thay đổi nghiêm ngặt như tài chính·khu vực công.

5. Chuyên sâu — Phát triển sang GitOps và bảo mật (Policy as Code)

Xu hướng mới nhất của IaC là mở rộng sang GitOps. GitOps là nguyên tắc 'lấy kho Git làm nguồn sự thật duy nhất (Single Source of Truth) cho trạng thái hạ tầng·ứng dụng'. Thay vì vận hành viên trực tiếp chạy công cụ, khi hợp nhất (merge) thay đổi vào Git, agent tự động hóa sẽ liên tục đồng bộ khai báo đó vào cụm thực tế (ví dụ: Argo CD·Flux trong môi trường Kubernetes). Phương thức này có ba thế mạnh. Mọi thay đổi đều thông qua Pull Request nên review·phê duyệt·truy vết kiểm toán hòa vào quy trình phát triển tiêu chuẩn; khi trạng thái thực tế lệch khỏi khai báo trong Git, agent tự động đưa trở lại (self-healing), chặn drift từ gốc; và rollback trở nên đơn giản như 'hoàn tác Git'.

Một trục khác là mã hóa bảo mật·quản trị. Khi hạ tầng trở thành mã, việc tự động kiểm chứng mã đó có tuân thủ chính sách tổ chức hay không cũng có thể thực hiện bằng mã. Bằng Policy as Code (chính sách dưới dạng mã, ví dụ: OPA/Rego, Sentinel), các quy tắc như "cấm lưu trữ mở công khai", "cấm triển khai volume không mã hóa" được cưỡng chế trong pipeline, và quét tĩnh IaC như tfsec·Checkov phát hiện cấu hình bảo mật sai trước khi triển khai. Tuy nhiên, nếu khóa truy cập·mật khẩu bị hardcode trong mã hạ tầng, chúng sẽ lưu vĩnh viễn trong lịch sử quản lý cấu hình và trở thành rò rỉ nghiêm trọng, vì vậy nhất thiết phải song hành nguyên tắc đặt bí mật (secret) bên ngoài mã (hệ thống quản lý bí mật như Vault). Như vậy, IaC bắt đầu từ 'tự động hóa' và mở rộng ngoại diên sang 'GitOps (mô hình vận hành)' và 'Policy as Code (quản trị)', trở thành nền móng của vận hành cloud native.

Tóm tắt khác biệt giữa IaC truyền thống (chạy công cụ trực tiếp) và GitOps như sau.

Hướng ra đề dự kiến và chiến lược cấu trúc bài làm

Trong kỳ thi Kỹ sư chuyên nghiệp (Professional Engineer), IaC có xu hướng được ra đề gắn với đám mây·DevOps·container hơn là chủ đề độc lập. Khi cấu trúc bài làm, nên lưu ý các trục sau.

• Khái niệm·Sự cần thiết: Nối từ trôi cấu hình·giới hạn của thao tác thủ công → định nghĩa và bối cảnh ra đời của IaC.
• So sánh phương thức: Trình bày khai báo vs mệnh lệnh đến tận 'lý do' về lũy đẳng·quản lý trạng thái.
• Nguyên lý hoạt động: Trình bày bằng sơ đồ plan → review → apply và vai trò của tệp trạng thái.
• Công nghệ liên kết: Mở rộng sang mối quan hệ với DevOps·CI/CD·GitOps·container (Kubernetes)·platform engineering.
• Bảo mật·Quản trị: Đề cập quản lý bí mật, Policy as Code, quét IaC từ góc độ quản lý rủi ro.
• Kết luận: Khép lại bằng chiến lược áp dụng (từng bước·module hóa), mức độ trưởng thành tổ chức và triển vọng (Everything as Code).

6. Các vấn đề cần cân nhắc và hàm ý (góc nhìn Kỹ sư chuyên nghiệp)

1. Quản lý trạng thái là điểm yếu chí mạng của vận hành IaC. Mọi phán đoán của công cụ khai báo đều dựa trên tệp trạng thái, nên lưu trữ từ xa·khóa·sao lưu·mã hóa trạng thái là bắt buộc chứ không phải tùy chọn. Bản thân tệp trạng thái có thể chứa thông tin nhạy cảm nên cần thiết kế đồng thời kiểm soát truy cập và mã hóa, và phải xây dựng hệ thống vận hành trên tiền đề rằng nếu trạng thái hỏng thì toàn bộ hạ tầng gặp nguy hiểm.

2. Cần góc nhìn bảo mật 'mã chính là quyền hạn'. IaC trao cho mã quyền hạn mạnh mẽ có thể tự động thay đổi hạ tầng. Do đó, cần nội tại hóa review mã·nguyên tắc đặc quyền tối thiểu·tách bí mật·Policy as Code·quét IaC vào pipeline, phòng thủ để mã sai hoặc pipeline bị chiếm đoạt không lan thành sự cố quy mô lớn.

3. Chiến lược áp dụng từng bước và module hóa quyết định thành bại. Rất khó chuyển toàn bộ hạ tầng thủ công hiện có sang mã trong một lần. Cách tiếp cận theo giai đoạn là thực tế: quản lý bằng IaC từ tài nguyên mới, chuẩn hóa cấu hình lặp lại thành module tái sử dụng, và cùng phát triển văn hóa review mã·kiểm thử trong toàn đội. Mấu chốt là mức độ trưởng thành vận hành của tổ chức hơn là bản thân việc đưa công cụ vào.

4. Quản lý drift và kỷ luật thay đổi là cốt lõi của vận hành bền vững. Rất khó ngăn hoàn toàn các thay đổi thủ công khẩn cấp trên console, nhưng nếu bỏ mặc, khả năng tái tạo của IaC sẽ sụp đổ. Cần phát hiện·điều chỉnh drift định kỳ và thiết lập kỷ luật để về nguyên tắc mọi thay đổi đều đi qua mã (nếu là GitOps thì qua PR), lợi ích của IaC mới được duy trì.

5. Triển vọng: Nền tảng tiêu chuẩn của vận hành cloud native. IaC đã trở thành nền tảng chung của DevOps·GitOps·platform engineering (nền tảng nhà phát triển nội bộ, IDP). Hơn nữa, nó đang mở rộng thành 'Everything as Code' quản lý cả chính sách·bảo mật·chi phí bằng mã, và được kỳ vọng phát triển theo hướng đồng thời nâng cao độ tin cậy·khả năng kiểm toán·hiệu quả chi phí của vận hành hạ tầng.

Tài liệu tham khảo

• HashiCorp — What is Infrastructure as Code?: https://developer.hashicorp.com/terraform/intro
• AWS — Infrastructure as Code: https://aws.amazon.com/what-is/iac/
• OpenGitOps Principles: https://opengitops.dev/
• Open Policy Agent (OPA): https://www.openpolicyagent.org/

Tóm tắt một câu: IaC là phương thức khai báo trạng thái mong muốn của hạ tầng bằng mã để tự động cấp phát·quản lý, gồm kiểu khai báo (lũy đẳng·theo dõi trạng thái) và mệnh lệnh, mang lại tính nhất quán·khả năng tái tạo·tốc độ·quản lý phiên bản·tối ưu chi phí, và khi được trang bị quản lý trạng thái cùng bảo mật (tách bí mật·Policy as Code) sẽ trở thành nền tảng tiêu chuẩn của vận hành cloud native, mở rộng sang GitOps·platform engineering.