Giới thiệu dự án

Trong kỷ nguyên chuyển đổi số và điện toán đám mây (Cloud Computing), việc quản lý và duy trì các hệ thống ứng dụng web đa tầng (Multi-tier Web Applications) bao gồm Load Balancer, Web Server, Database Server và hệ thống giám sát đang đối mặt với nhiều thách thức về quy mô cũng như tính ổn định. Theo thống kê thị trường điện toán đám mây toàn cầu, Amazon Web Services (AWS) dẫn đầu với 32% thị phần, theo sau là Microsoft Azure (19%) và Google Cloud (7%). Song song với sự bùng nổ của các nền tảng Public Cloud thương mại, các giải pháp Private Cloud mã nguồn mở như OpenStack cũng đóng vai trò nền tảng quan trọng trong việc xây dựng hạ tầng đám mây nội bộ cho doanh nghiệp.

Tuy nhiên, phương pháp quản trị và cấp phát hạ tầng truyền thống dựa trên giao diện đồ họa (GUI) hoặc cấu hình thủ công từng máy chủ vật lý/máy ảo bộc lộ các nhược điểm nghiêm trọng:

  • Thời gian triển khai kéo dài: Thiết lập thủ công một cụm máy chủ web, cân bằng tải, cơ sở dữ liệu và cấu hình mạng thường tiêu tốn hàng giờ đồng hồ.
  • Rủi ro sai sót do con người (Human Error): Việc cấu hình rời rạc dễ dẫn đến hiện tượng trôi lệch cấu hình (Configuration Drift) giữa các môi trường phát triển (Development, Staging, Production).
  • Khó khăn trong nhân bản và phục hồi thảm họa (Disaster Recovery): Khi xảy ra sự cố, việc tái thiết lập toàn bộ hệ thống từ đầu đòi hỏi quy trình phức tạp và tiềm ẩn nguy cơ gián đoạn dịch vụ kéo dài.

Nhằm giải quyết triệt để các hạn chế trên, đề tài khóa luận "Tự động triển khai cơ sở hạ tầng điện toán đám mây sử dụng Terraform" do sinh viên Vưu Khánh Duy và Nguyễn Minh Tuấn Hải thực hiện (Khoa Mạng máy tính và Truyền thông, Trường Đại học Công nghệ Thông tin – ĐHQG TP.HCM, dưới sự hướng dẫn của ThS. Đỗ Thị Hương Lan) đã nghiên cứu và ứng dụng mô hình Cơ sở hạ tầng dưới dạng mã (Infrastructure as Code - IaC).

graph TD
    A[Kỹ sư DevOps / Local Admin] -->|HCL Code| B[Terraform Engine]
    B -->|AWS Provider API| C[AWS Cloud Infrastructure]
    B -->|OpenStack Provider API| D[OpenStack Private Cloud]
    C -->|Auto Provisioning| E[EC2 + ALB + Docker LEMP Stack]
    D -->|Ansible Automation| F[Nova Instances + Zabbix Monitoring]

Mục tiêu của dự án:

  1. Nghiên cứu và hiện thực hóa mô hình Infrastructure as Code (IaC) thông qua Terraform nhằm tự động hóa quy trình cấp phát tài nguyên điện toán đám mây đa nền tảng (Multi-Cloud: AWS và OpenStack).
  2. Xây dựng kịch bản tự động triển khai hạ tầng mạng hoàn chỉnh: Virtual Private Cloud (VPC), Subnet đa vùng khả dụng (Multi-AZ), Internet Gateway, Route Table, Security Group, Elastic IP và Application Load Balancer.
  3. Tự động hóa quá trình cấu hình phần mềm và điều phối dịch vụ thông qua Ansible Playbook (trên OpenStack) và Docker/Docker-Compose (trên AWS) để vận hành website WordPress (ngăn xếp LEMP: Nginx, MariaDB, PHP).
  4. Thiết lập hệ thống giám sát hạ tầng tập trung Zabbix và quản lý phân giải tên miền (DNS) qua Freenom.
  5. Đo lường, so sánh hiệu năng và thời gian triển khai giữa mô hình quản trị truyền thống và tự động hóa bằng IaC.

Phạm vi và giới hạn đề tài:

  • Phạm vi: Triển khai hạ tầng mẫu trên môi trường Public Cloud (AWS vùng ap-southeast-1 Singapore) và Private Cloud (OpenStack); tự động cài đặt ứng dụng WordPress trên nền container Docker và quản lý cấu hình bằng Ansible; tích hợp công cụ giám sát Zabbix Server/Agent.
  • Giới hạn: Quá trình đăng ký tên miền trên Freenom vẫn thực hiện bán tự động; trạng thái hệ thống (terraform.tfstate) được quản lý cục bộ (Local State) có định hướng chuyển đổi sang Remote State.

Phân tích và thiết kế giải pháp

Phân tích hiện trạng

Trước khi áp dụng Terraform, các giải pháp IaC và quản lý cấu hình hiện có trên thị trường thường gắn liền với từng nhà cung cấp riêng biệt hoặc có yêu cầu phức tạp về mặt kiến trúc:

Công cụ IaC / Quản lý Kiến trúc (Architecture) Khả năng Multi-Cloud Cài đặt & Quản trị Ngôn ngữ định nghĩa
Terraform Agentless / State-based Rất cao (AWS, Azure, OpenStack, GCP...) Dễ (Single Binary) HCL (HashiCorp Config Lang)
AWS CloudFormation Proprietary AWS Engine Thấp (Chỉ dành riêng cho AWS) Dễ (Managed) JSON / YAML
OpenStack Heat Proprietary OpenStack Engine Thấp (Chủ yếu nội bộ OpenStack) Phức tạp YAML (HOT Templates)
Azure ARM Proprietary Azure Engine Thấp (Chỉ dành riêng cho Azure) Dễ (Managed) JSON
Ansible Agentless (SSH/WinRM) Trung bình (Tập trung Configuration) Dễ YAML
Chef / Puppet Server - Client Agent Thấp Khó (Cần cài Agent, học DSL) Ruby DSL / Puppet DSL

Đánh giá yêu cầu theo mô hình MoSCoW:

  • Must Have (Bắt buộc): Tự động khởi tạo VPC, Subnet, EC2 Instance trên AWS; tự động khởi tạo VM Compute v2, Security Group, Volume v2 trên OpenStack; tự động chạy container WordPress qua Docker-Compose.
  • Should Have (Nên có): Tích hợp Application Load Balancer phân tải qua 2 Availability Zones; triển khai Zabbix Agent giám sát CPU, RAM, Disk; tách biệt biến bảo mật bằng secret.tfvars.
  • Could Have (Có thể có): Tự động liên kết DNS Freenom; lưu trữ trạng thái từ xa (Remote State Backend trên AWS S3).
  • Won't Have (Chưa thực hiện): Tự động đăng ký tài khoản tên miền tự động hóa hoàn toàn CAPTCHA; xây dựng cụm Kubernetes mở rộng tự động (Autoscaling Cluster).

Thiết kế hệ thống

Kiến trúc hệ thống được thiết kế theo hướng module hóa, chia tách rõ ràng giữa tầng cấp phát hạ tầng (Infrastructure Provisioning), tầng quản lý cấu hình (Configuration Management) và tầng thực thi ứng dụng (Application Runtime).

graph LR
    subgraph AWS VPC 10.0.0.0/16
        IGW[Internet Gateway] --> ALB[Application Load Balancer]
        ALB -->|Port 80/HTTP| SubnetA[Public Subnet 10.0.1.0/24<br/>ap-southeast-1a]
        ALB -->|Port 80/HTTP| SubnetB[Private/Alt Subnet 10.0.2.0/24<br/>ap-southeast-1b]
        SubnetA --> EC2_1[Instance: terraform-web-server0<br/>CentOS 7 + Docker]
        SubnetB --> EC2_2[Instance: terraform-web-server1<br/>CentOS 7 + Docker]
    end

Ngăn xếp công nghệ và phiên bản:

  • Core Orchestrator: Terraform (HashiCorp) – Quản lý trạng thái và vòng đời tài nguyên.
  • Configuration Management: Ansible v2.9+ – Thực thi cấu hình qua SSH Agentless.
  • Operating System: CentOS 7 x86_64 (AWS AMI & OpenStack Glance Image).
  • Containerization: Docker CE Engine & Docker-Compose v1.29+.
  • Application Stack (LEMP): Nginx 1.20+ (Reverse Proxy/Web), MariaDB 10.5+ (Database Engine), PHP-FPM 7.4+ (WordPress Core Processor).
  • Monitoring & Network: Zabbix 5.0 LTS, Freenom DNS.

Thiết kế an toàn thông tin (Security Considerations):

  • Sử dụng cặp khóa bất đối xứng SSH Key Pair (id_rsa / id_rsa.pub) để xác thực bảo mật giữa trạm điều khiển cục bộ (Local Controller) và các máy ảo.
  • Cách ly tài khoản và khóa truy cập (Access Key / Secret Key) ra khỏi mã nguồn công khai, tập trung toàn bộ biến môi trường vào tệp secret.tfvars (được đưa vào .gitignore).
  • Cấu hình Security Group tuân thủ nguyên tắc đặc quyền tối thiểu (Least Privilege): chỉ mở các cổng thiết yếu gồm 22 (SSH Management), 80 (HTTP Web Traffic) và 443 (HTTPS).

Phương pháp luận (Methodology)

Dự án áp dụng phương pháp triển khai hạ tầng lặp lại (Iterative Infrastructure Delivery) với quy trình làm việc gồm 4 pha chính:

flowchart LR
    A[1. Code HCL Definition] --> B[2. Terraform Init & Plan]
    B --> C[3. Terraform Apply & Provisioning]
    C --> D[4. Verification & Zabbix Monitoring]
  1. Khởi tạo và xác thực (Init & Validate): Tải các Provider Plugins tương ứng (hashicorp/aws, terraform-providers/openstack) và kiểm tra cú pháp tệp .tf.
  2. Lập kế hoạch thực thi (Plan): So khớp trạng thái mong muốn trong code với tệp trạng thái thực tế terraform.tfstate để tạo ra đồ thị phụ thuộc tài nguyên (Dependency Graph).
  3. Cấp phát và cấu hình (Apply & Provision): Tạo tài nguyên đám mây và thực thi kịch bản bootstrap tự động thông qua các khối provisioner "file" và provisioner "remote-exec".
  4. Giám sát và bảo trì (Monitor & Maintain): Thu thập metrics vận hành liên tục qua Zabbix Agent gửi về Zabbix Server.

Implementation và kết quả

Quá trình phát triển và mã nguồn chi tiết

1. Cấu hình Provider và bảo mật thông tin xác thực

Toàn bộ thông tin định danh truy cập AWS và OpenStack được tách biệt hoàn toàn vào tệp secret.tfvars:

# File: aws_provider.tf & openstack_provider.tf
provider "aws" {
  profile    = "default"
  region     = "ap-southeast-1"
  access_key = var.aws_access_key
  secret_key = var.aws_secret_key
}

provider "openstack" {
  user_name   = var.openstack_user_name
  tenant_name = var.openstack_tenant_name
  password    = var.openstack_password
  auth_url    = var.openstack_auth_url
}

2. Cấp phát hạ tầng mạng và cân bằng tải trên AWS

Terraform khởi tạo VPC cô lập logic, chia tách thành 2 Subnet thuộc 2 Availability Zones khác nhau (ap-southeast-1a và ap-southeast-1b) nhằm đảm bảo tính sẵn sàng cao (High Availability):

# File: aws_network.tf
resource "aws_vpc" "hai-vpc" {
  cidr_block = "10.0.0.0/16"
  tags = {
    Name = "hai-vpc"
  }
}

resource "aws_internet_gateway" "igw" {
  vpc_id = aws_vpc.hai-vpc.id
  tags = {
    Name = "terraform-IGW"
  }
}

resource "aws_subnet" "public_subnet" {
  vpc_id                  = aws_vpc.hai-vpc.id
  cidr_block              = "10.0.1.0/24"
  availability_zone       = "ap-southeast-1a"
  map_public_ip_on_launch = true
  tags = {
    Name = "public-subnet-10.0.1.0/24"
  }
}

resource "aws_subnet" "private_subnet" {
  vpc_id                  = aws_vpc.hai-vpc.id
  cidr_block              = "10.0.2.0/24"
  availability_zone       = "ap-southeast-1b"
  map_public_ip_on_launch = true
  tags = {
    Name = "private-subnet-10.0.2.0/24"
  }
}

Thiết lập Application Load Balancer (ALB) kết nối trực tiếp với 2 Subnet đa vùng:

# File: aws_loadbalancer.tf
resource "aws_lb" "load_balancer" {
  name               = "aws-loadbalancer"
  internal           = false
  load_balancer_type = "application"
  security_groups    = [aws_security_group.web_sg.id]
  subnets            = [aws_subnet.public_subnet.id, aws_subnet.private_subnet.id]
  ip_address_type    = "ipv4"
  tags = {
    Name = "aws-loadbalancer"
  }
}

3. Tự động hóa cài đặt Docker và triển khai Container

Để giải quyết bài toán quyền hạn người dùng của Linux khi cài đặt Docker (người dùng centos chưa nhận quyền nhóm docker ngay trong cùng phiên), hệ thống áp dụng kỹ thuật tách 2 phiên SSH Provisioner:

# File: aws_instance.tf
resource "aws_instance" "web_server" {
  count         = 2
  ami           = var.centos7_ami
  instance_type = "t2.micro"
  key_name      = var.key_name

  # Giai đoạn 1: Chuyển script và cài đặt nền tảng Docker
  provisioner "file" {
    source      = "./script/install_docker.sh"
    destination = "~/install_docker.sh"
    connection {
      type        = "ssh"
      user        = "centos"
      private_key = file(var.ssh_key)
      host        = self.public_ip
    }
  }

  provisioner "remote-exec" {
    inline = [
      "bash ~/install_docker.sh",
      "rm -rf ~/install_docker.sh"
    ]
    connection {
      type        = "ssh"
      user        = "centos"
      private_key = file(var.ssh_key)
      host        = self.public_ip
    }
  }

  # Giai đoạn 2: Phiên SSH mới nhận quyền nhóm Docker để khởi động container
  provisioner "remote-exec" {
    inline = [
      "cd ~/khoaluan/docker",
      "docker-compose up -d --build"
    ]
    connection {
      type        = "ssh"
      user        = "centos"
      private_key = file(var.ssh_key)
      host        = self.public_ip
    }
  }
}

Nội dung kịch bản cài đặt tự động install_docker.sh:

#!/bin/bash
echo "-------- Install Docker CE --------"
sudo yum install -y yum-utils device-mapper-persistent-data lvm2
sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
sudo yum install -y docker-ce docker-ce-cli containerd.io
sudo systemctl enable docker
sudo systemctl start docker
sudo usermod -aG docker centos

echo "-------- Install Docker-Compose --------"
sudo curl -L "https://github.com/docker/compose/releases/download/1.29.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose

echo "-------- Clone Project Repositories --------"
sudo yum -y install git
cd ~
git clone https://github.com/vuukhanhduy/khoaluan.git
cd khoaluan/docker
git clone https://github.com/NguyenMinhTuanHai/wordpress-source.git
mv wordpress-source/source ./source
rm -rf wordpress-source

Định nghĩa dịch vụ ứng dụng qua docker-compose.yaml:

version: '3'
services:
  nginx:
    container_name: nginx
    build:
      context: ./nginx
      dockerfile: Dockerfile
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./source:/data/www
      - ./nginx/conf.d:/etc/nginx/conf.d
    networks:
      - project-network

  mariadb:
    image: mariadb:10.5
    container_name: mariadb
    restart: unless-stopped
    environment:
      MYSQL_ROOT_PASSWORD: root_password
      MYSQL_DATABASE: wordpress_db
    volumes:
      - ./mariadb_data:/var/lib/mysql
    networks:
      - project-network

networks:
  project-network:
    driver: bridge

4. Quản lý cấu hình máy chủ OpenStack bằng Ansible Playbook

Trên hạ tầng OpenStack, Terraform tự động sinh tệp inventory.ini chứa IP các máy chủ ảo vừa tạo và kích hoạt kịch bản Ansible Role:

# File: playbook.yml
- name: Setup LEMP on OpenStack Compute Nodes
  hosts: webserver
  become: yes
  become_user: root
  roles:
    - lemp
    - firewalld
    - import_source
    - add_ssl

Kiểm thử và đánh giá kết quả

Hệ thống đã trải qua quá trình kiểm thử nghiêm ngặt trên cả 2 môi trường:

pie title Phân bổ thời gian triển khai hệ thống (Phút)
    "Cấu hình thủ công (120 phút)" : 120
    "Terraform + Docker/Ansible (9.5 phút)" : 9.5

Bảng so sánh hiệu năng và thời gian thực thi:

Tiêu chí đánh giá Triển khai thủ công (Manual GUI/CLI) Triển khai tự động (Terraform + Docker/Ansible) Mức độ cải thiện (%)
Thời gian khởi tạo hạ tầng 45 – 60 phút 2 – 3 phút Giảm 95.0%
Thời gian cấu hình LEMP & App 60 – 75 phút 6 – 7 phút Giảm 90.5%
Tổng thời gian sẵn sàng phục vụ 105 – 135 phút 8.5 – 10 phút Giảm 92.2%
Tỷ lệ lỗi cấu hình (Human Error) 15 – 25% (nhầm port, sai IP, quên firewall) 0% (Đồng nhất theo code) Triệt tiêu hoàn toàn
Khả năng tái lập môi trường Phức tạp, phải ghi chép tài liệu từng bước 1 lệnh duy nhất (terraform apply) Tối ưu hóa 100%
Giám sát hệ thống (Monitoring) Cài đặt thủ công từng Agent Tự động cài đặt & liên kết Zabbix Server Tự động hóa

Đổi mới và đóng góp

  1. Chuẩn hóa quy trình Hybrid/Multi-Cloud IaC: Xây dựng thành công bộ khung kịch bản thống nhất có khả năng cấp phát đồng thời tài nguyên trên cả Public Cloud doanh nghiệp (AWS) và Private Cloud nội bộ (OpenStack) chỉ từ một trạm điều khiển duy nhất.
  2. Mô hình kết hợp 3 lớp chuyên biệt (Tri-Layer Automation):
    • Lớp 1 (Terraform): Đảm nhiệm vòng đời cơ sở hạ tầng (Compute, Network, Storage, ALB).
    • Lớp 2 (Ansible): Xử lý cấu hình hệ điều hành và chính sách tường lửa bảo mật (OS & Firewall Policies).
    • Lớp 3 (Docker Compose): Đóng gói và cô lập môi trường thực thi ứng dụng microservices/LEMP stack.
  3. Giải quyết triệt để bài toán đồng bộ phân quyền tự động: Sáng tạo giải pháp phân tầng Remote Provisioner trong Terraform để xử lý vấn đề cập nhật nhóm người dùng Linux (usermod -aG docker) mà không làm gián đoạn luồng tự động hóa.
  4. Đóng góp học thuật và mã nguồn mở: Đồ án cung cấp một tài liệu tham khảo chi tiết và bộ mã nguồn mẫu (Template) chuẩn chỉ cho sinh viên, kỹ sư DevOps tại các trường đại học và doanh nghiệp trong quá trình tiếp cận Cloud Automation.

Ứng dụng thực tế và triển khai

Kịch bản ứng dụng thực tế:

  • Môi trường CI/CD (Continuous Integration / Continuous Deployment): Tự động khởi tạo môi trường kiểm thử (Testing/Staging Environment) giống hệt môi trường Production trước mỗi đợt phát hành mã nguồn, sau đó tự động hủy (terraform destroy) để tối ưu hóa chi phí điện toán.
  • Phục hồi sau thảm họa (Disaster Recovery): Khi toàn bộ Data Center gặp sự cố, chỉ cần thực thi kịch bản Terraform tại một Region/Data Center dự phòng để tái thiết lập toàn bộ hệ thống mạng và ứng dụng trong vòng chưa đầy 10 phút.
  • Triển khai ứng dụng quy mô lớn cho doanh nghiệp: Cho phép các công ty phát triển phần mềm nhanh chóng bàn giao hạ tầng tiêu chuẩn cho khách hàng mà không phụ thuộc vào tay nghề của từng quản trị viên hệ thống.
gantt
    title Lộ trình triển khai hệ thống IaC trong doanh nghiệp
    dateFormat  YYYY-MM-DD
    section Giai đoạn 1: Chuẩn bị
    Khởi tạo tài khoản AWS/OpenStack & SSH Key   :2026-09-01, 3d
    Cấu hình mã nguồn & secret.tfvars            :2026-09-04, 2d
    section Giai đoạn 2: Triển khai
    Thực thi Terraform Init, Plan & Apply        :2026-09-06, 1d
    Bootstrap Docker Engine & Ansible Roles      :2026-09-07, 2d
    section Giai đoạn 3: Giám sát & Bàn giao
    Tích hợp Zabbix Monitoring & DNS Freenom    :2026-09-09, 2d
    Kiểm thử UAT & Đánh giá tải ALB             :2026-09-11, 3d

Phân tích hiệu quả kinh tế (Cost-Benefit & ROI):

  • Tiết kiệm chi phí nhân sự vận hành: Giảm hơn 90% thời gian kỹ sư phải trực tiếp thao tác trên máy chủ.
  • Tối ưu hóa chi phí tài nguyên Cloud: Do khả năng tạo lập và giải phóng tài nguyên nhanh chóng theo nhu cầu thực tế, doanh nghiệp có thể tắt hạ tầng kiểm thử ngoài giờ làm việc, tiết kiệm lên đến 60-70% chi phí hóa đơn điện toán đám mây hàng tháng.

Hạn chế và hướng phát triển

Hạn chế hiện tại:

  • Tệp trạng thái terraform.tfstate vẫn lưu trữ cục bộ tại máy local, chưa áp dụng cơ chế khóa trạng thái (State Locking) để hỗ trợ làm việc nhóm quy mô lớn đồng thời.
  • Quy trình đăng ký và gia hạn tên miền trên Freenom vẫn còn thao tác thủ công qua giao diện web do nhà cung cấp không mở API chính thức.
  • Ứng dụng chạy trên các Docker container đơn lẻ trên từng máy ảo EC2, chưa được điều phối bởi các giải pháp quản lý cụm container chuyên nghiệp như Kubernetes (K8s) hoặc AWS ECS.

Hướng phát triển tiếp theo:

  1. Chuyển dịch sang Remote State Backend: Tích hợp lưu trữ trạng thái tập trung trên Amazon S3 kết hợp DynamoDB để thực hiện cơ chế State Locking và mã hóa dữ liệu trạng thái.
  2. Tự động hóa DNS với các nhà cung cấp chuyên nghiệp: Tích hợp Terraform Provider cho AWS Route53 hoặc Cloudflare để tự động hóa 100% quy trình cấp phát Record DNS và chứng chỉ SSL Let's Encrypt.
  3. Nâng cấp kiến trúc Container Orchestration: Chuyển đổi từ Docker Compose sang Kubernetes (EKS / OpenStack Magnum) để hỗ trợ tự động co giãn theo tải thực tế (Horizontal Pod Autoscaler).

Đối tượng hưởng lợi

mindmap
  root((Đối tượng hưởng lợi))
    Sinh viên & Nghiên cứu sinh
      Học liệu tham khảo trực quan
      Nắm vững thực hành IaC & DevOps
    Kỹ sư DevOps & SysAdmin
      Kịch bản mẫu HCL & Ansible tái sử dụng
      Chuẩn hóa quy trình vận hành hệ thống
    Doanh nghiệp & Khởi nghiệp
      Rút ngắn thời gian Time-to-Market
      Tiết kiệm 92% thời gian cấp phát hạ tầng
  • Sinh viên & Giảng viên ngành Mạng & CNTT: Tài liệu học tập thực nghiệm chuyên sâu, liên kết chặt chẽ giữa lý thuyết điện toán đám mây và thực hành công nghệ tiêu chuẩn công nghiệp (AWS, OpenStack, Terraform, Ansible, Docker).
  • Kỹ sư DevOps / Quản trị hệ thống (SysAdmin): Sở hữu bộ khung kịch bản hoàn chỉnh để tái sử dụng ngay trong các dự án thực tế, loại bỏ việc cấu hình thủ công tốn thời gian.
  • Doanh nghiệp vừa và nhỏ (SMEs / Startups): Nhanh chóng đưa sản phẩm ra thị trường (Time-to-Market) với chi phí đầu tư hạ tầng thấp nhất cùng độ tin cậy và an toàn cao.

Câu hỏi thường gặp

1. Yêu cầu kỹ thuật tối thiểu để triển khai giải pháp này là gì?

Máy điều khiển (Local Machine) cần chạy hệ điều hành Linux/macOS hoặc Windows (WSL2), đã cài đặt Terraform CLI (>= v1.0.0), Ansible (>= 2.9), Git và AWS CLI v2. Về phía tài khoản đám mây, cần tài khoản AWS có quyền IAM phù hợp (EC2, VPC, ALB Full Access) và cụm OpenStack đang hoạt động với API endpoints xác thực (Keystone v3).

2. Làm thế nào để mở rộng hệ thống khi lượng người dùng truy cập website tăng đột biến?

Trên AWS, ta chỉ cần thay đổi tham số count của tài nguyên aws_instance.web_server trong tệp aws_instance.tf hoặc kết hợp với AWS Auto Scaling Group và cấu hình ALB Target Group Health Check để tự động điều chỉnh số lượng máy ảo phục vụ.

3. Tệp trạng thái terraform.tfstate có chứa dữ liệu nhạy cảm không và bảo mật như thế nào?

Có. Tệp .tfstate chứa toàn bộ ánh xạ tài nguyên, bao gồm cả địa chỉ IP nội bộ, ID tài nguyên và đôi khi cả mật khẩu dạng bản rõ (plaintext). Để bảo mật, không được commit tệp này lên Git repository công khai; cần lưu trữ trên Amazon S3 với chính sách IAM nghiêm ngặt, kích hoạt mã hóa Server-Side Encryption (SSE-S3/KMS) và bật DynamoDB Locking.

4. Tại sao đồ án kết hợp cả Terraform, Ansible và Docker thay vì chỉ dùng một công cụ duy nhất?

Mỗi công cụ được thiết kế tối ưu cho từng mục đích riêng biệt theo triết lý Unix:

  • Terraform xuất sắc nhất ở tầng Orchestration & Provisioning (cấp phát phần cứng, mạng, máy ảo).
  • Ansible tối ưu cho tầng Configuration Management (cài đặt gói phần mềm hệ thống, cấu hình firewall không cần agent).
  • Docker tối ưu cho tầng Application Runtime (đóng gói ứng dụng web, loại bỏ xung đột môi trường). Sự kết hợp này tạo nên một kiến trúc DevOps hoàn chỉnh và linh hoạt.

5. Chi phí vận hành hạ tầng thử nghiệm trên AWS trong đồ án là bao nhiêu?

Hệ thống hoàn toàn có thể chạy trong gói miễn phí AWS Free Tier (sử dụng 2 máy ảo t2.micro với 750 giờ/tháng miễn phí, 30GB EBS). Chi phí chỉ phát sinh một phần nhỏ đối với Application Load Balancer (~$0.0225/giờ) và phí dữ liệu mạng nếu vượt quá hạn mức miễn phí.

Kết luận

Đề tài khóa luận tốt nghiệp "Tự động triển khai cơ sở hạ tầng điện toán đám mây sử dụng Terraform" của nhóm tác giả Vưu Khánh Duy và Nguyễn Minh Tuấn Hải (Khoa Mạng máy tính và Truyền thông – Trường ĐH Công nghệ Thông tin, ĐHQG TP.HCM) đã giải quyết trọn vẹn và chuyên sâu bài toán tự động hóa hạ tầng trong thời đại Cloud-Native.

Bằng việc kết hợp nhuần nhuyễn sức mạnh của Terraform (IaC), Ansible, Docker và hệ thống giám sát Zabbix, đề tài đã chứng minh tính ưu việt vượt trội của phương pháp luận DevOps: cắt giảm hơn 92% thời gian triển khai, triệt tiêu hoàn toàn rủi ro sai sót do con người và đảm bảo khả năng mở rộng đa nền tảng linh hoạt giữa AWS và OpenStack. Đây là công trình nghiên cứu ứng dụng có giá trị thực tiễn cao, đóng vai trò nền tảng vững chắc cho các mô hình tự động hóa hạ tầng và CI/CD nâng cao trong doanh nghiệp.