Dòng thời gian các sự kiện quan trọng

• Tháng 8/2023: HashiCorp đổi giấy phép sang BSL (không còn mã nguồn mở hoàn toàn)
• Tháng 9/2023: Cộng đồng công bố dự án OpenTofu
• Tháng 1/2024: OpenTofu phiên bản 1.6 ổn định
• Tháng 4/2024: Broadcom đàm phán mua HashiCorp
• Tháng 11/2024: Broadcom hoàn tất thương vụ
• 2025: Tương lai còn nhiều điều chưa rõ ràng

HCP Terraform (trước đây là Terraform Cloud)

HashiCorp đã đổi tên Terraform Cloud thành HCP Terraform:

// Cấu hình kết nối với HCP Terraform
terraform {
  cloud {
    organization = "cong-ty-cua-toi"
    workspaces {
      name = "moi-truong-san-pham"
    }
  }
}

Tính năng mới

• Quản lý trạng thái tốt hơn
• Tích hợp tốt hơn với HCP Vault
• Chính sách dưới dạng mã (Sentinel)
• Kho module riêng tư
• Tích hợp với quy trình CI/CD

Lo ngại về giá cả

Sau khi Broadcom tiếp quản, nhiều người lo ngại:

• Gói miễn phí có thể bị cắt giảm
• Giá doanh nghiệp có thể tăng
• Bị phụ thuộc vào một nhà cung cấp

OpenTofu – Nhánh mã nguồn mở

OpenTofu là phiên bản do cộng đồng phát triển, giữ giấy phép MPL mã nguồn mở:

# Chuyển đổi từ Terraform sang OpenTofu
# 1. Cài đặt OpenTofu
brew install opentofu

# 2. Thay thế lệnh (cú pháp giống hệt)
tofu init      # thay vì terraform init
tofu plan      # thay vì terraform plan  
tofu apply     # thay vì terraform apply

# 3. Tệp trạng thái tương thích hoàn toàn
# terraform.tfstate hoạt động bình thường!

Tính năng riêng của OpenTofu (2025)

# Mã hóa trạng thái (chỉ có ở OpenTofu)
terraform {
  encryption {
    key_provider "pbkdf2" "mat_khau" {
      passphrase = var.mat_khau_trang_thai
    }
    
    method "aes_gcm" "mac_dinh" {
      key_provider = key_provider.pbkdf2.mat_khau
    }
    
    state {
      method = method.aes_gcm.mac_dinh
    }
  }
}

So sánh hai công cụ

Chọn công cụ nào trong năm 2025?

Nên tiếp tục dùng Terraform khi:

• Cần hỗ trợ kỹ thuật từ nhà cung cấp
• Đang dùng Terraform Cloud/Enterprise
• Ưu tiên sự ổn định
• Tổ chức không muốn rủi ro
• Đã có hợp đồng với HashiCorp

Nên xem xét OpenTofu khi:

• Quan trọng việc mã nguồn mở
• Lo ngại về Broadcom làm chủ sở hữu
• Cần tính năng mã hóa trạng thái
• Muốn công cụ do cộng đồng phát triển
• Bắt đầu dự án mới

Các thực hành tốt cho năm 2025

# 1. Giới hạn phiên bản rõ ràng
terraform {
  required_version = ">= 1.5.0, < 2.0.0"
  
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

# 2. Lưu trữ trạng thái từ xa với mã hóa
terraform {
  backend "s3" {
    bucket         = "trang-thai-terraform"
    key            = "san-pham/terraform.tfstate"
    region         = "ap-northeast-1"
    encrypt        = true
    dynamodb_table = "khoa-terraform"
  }
}

# 3. Dùng workspace cho các môi trường
terraform workspace new staging
terraform workspace new production

# 4. Dùng module để tái sử dụng
module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "5.0.0"
}

Cách chuyển đổi

Từ Terraform sang OpenTofu

# 1. Thử nghiệm ở môi trường phát triển trước
cd moi-truong-dev
tofu init
tofu plan  # Nên thấy không có thay đổi

# 2. Cập nhật quy trình CI/CD
# Thay 'terraform' bằng 'tofu'

# 3. Cập nhật tài liệu

# 4. Triển khai dần đến môi trường sản phẩm

Giữ linh hoạt cho cả hai

#!/bin/bash
# Script bọc để dùng cả hai công cụ

if command -v tofu &> /dev/null; then
    tofu "$@"
else
    terraform "$@"
fi

Các lựa chọn khác đáng theo dõi

• Pulumi: Dùng ngôn ngữ lập trình thay vì HCL
• Crossplane: Quản lý hạ tầng trên Kubernetes
• AWS CDK: CloudFormation với mã lập trình
• CDKTF: CDK cho Terraform

Lời khuyên từ Fullstack Station

Gợi ý cho năm 2025:

• Đang dùng Terraform: Tiếp tục dùng, theo dõi tiến độ OpenTofu
• Dự án mới: Xem xét OpenTofu để đảm bảo tương lai
• Doanh nghiệp: Chờ xem chiến lược của Broadcom rõ ràng hơn
• Học cả hai: Cú pháp gần như giống nhau, dễ chuyển đổi
• Tránh bị khóa: Dùng tính năng Terraform cơ bản, tránh tính năng riêng của Cloud

Năm 2025 sẽ là năm quan trọng để xem Broadcom định hướng thế nào. Hãy giữ các lựa chọn mở!

Tham khảo

• Terraform
• OpenTofu
• HCP Terraform

The post Terraform 2025: HCP Terraform và OpenTofu appeared first on Fullstack Station.

Tổng quan

Terraform (HashiCorp)

• Ngôn ngữ: HCL (Ngôn ngữ cấu hình HashiCorp)
• Ra mắt: 2014
• Giấy phép: BSL (từ 2023, trước là MPL)
• Cách tiếp cận: Cấu hình khai báo

Pulumi

• Ngôn ngữ: Python, TypeScript, Go, C#, Java
• Ra mắt: 2018
• Giấy phép: Apache 2.0
• Cách tiếp cận: Lập trình mệnh lệnh

So sánh cú pháp

Tạo máy chủ EC2

Terraform (HCL):

resource "aws_instance" "may_chu_web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"
  
  tags = {
    Name = "may-chu-web"
  }
}

output "dia_chi_ip" {
  value = aws_instance.may_chu_web.public_ip
}

Pulumi (Python):

import pulumi
import pulumi_aws as aws

may_chu_web = aws.ec2.Instance("may_chu_web",
    ami="ami-0c55b159cbfafe1f0",
    instance_type="t3.micro",
    tags={"Name": "may-chu-web"}
)

pulumi.export("dia_chi_ip", may_chu_web.public_ip)

Pulumi (TypeScript):

import * as pulumi from "@pulumi/pulumi";
import * as aws from "@pulumi/aws";

const mayChuWeb = new aws.ec2.Instance("may-chu-web", {
    ami: "ami-0c55b159cbfafe1f0",
    instanceType: "t3.micro",
    tags: { Name: "may-chu-web" }
});

export const diaChiIp = mayChuWeb.publicIp;

Điểm mạnh của Terraform

1. Hệ sinh thái trưởng thành

# Hàng nghìn nhà cung cấp
terraform {
  required_providers {
    aws     = { source = "hashicorp/aws" }
    google  = { source = "hashicorp/google" }
    azure   = { source = "hashicorp/azurerm" }
    k8s     = { source = "hashicorp/kubernetes" }
    # ... hơn 3000 nhà cung cấp
  }
}

2. Dễ học

HCL dễ đọc, không cần biết lập trình:

# Người không phải lập trình viên cũng hiểu được
resource "aws_s3_bucket" "tinh" {
  bucket = "trang-web-tinh-cua-toi"
}

resource "aws_s3_bucket_website_configuration" "tinh" {
  bucket = aws_s3_bucket.tinh.id
  index_document { suffix = "index.html" }
}

3. Quản lý trạng thái đã được chứng minh

# Trạng thái từ xa với S3
terraform {
  backend "s3" {
    bucket = "trang-thai-terraform"
    key    = "san-pham/terraform.tfstate"
    region = "ap-northeast-1"
    encrypt = true
    dynamodb_table = "khoa-terraform"
  }
}

4. Terraform Cloud/Enterprise

• Quản lý trạng thái
• Quy trình làm việc nhóm
• Chính sách dưới dạng mã (Sentinel)
• Kho module riêng

Điểm mạnh của Pulumi

1. Ngôn ngữ lập trình thực

# Python với vòng lặp, điều kiện, hàm
import pulumi_aws as aws

# Tạo tài nguyên động
for i in range(3):
    aws.ec2.Instance(f"web-{i}",
        ami="ami-xxx",
        instance_type="t3.micro" if i < 2 else "t3.small"
    )

# Hàm có thể tái sử dụng
def tao_vpc(ten: str, cidr: str):
    vpc = aws.ec2.Vpc(ten, cidr_block=cidr)
    return vpc

2. Kiểm thử tốt hơn

import unittest
import pulumi

class KiemTraHaTang(unittest.TestCase):
    @pulumi.runtime.test
    def kiem_tra_instance_co_the(self):
        def kiem_tra_the(args):
            the = args[0]
            self.assertIn("Name", the)
        
        pulumi.Output.all(instance.tags).apply(kiem_tra_the)

3. An toàn kiểu (TypeScript)

// Tự động hoàn thành IDE, lỗi lúc biên dịch
const instance = new aws.ec2.Instance("web", {
    ami: "ami-xxx",
    instanceType: "t3.micro",  // Kiểm tra kiểu
    // lỗi chính tả: instnceType - lỗi biên dịch!
});

4. Trừu tượng component

class VpcComponent(pulumi.ComponentResource):
    def __init__(self, ten: str, cidr: str, opts=None):
        super().__init__("tuy_chinh:VpcComponent", ten, opts)
        
        self.vpc = aws.ec2.Vpc(f"{ten}-vpc",
            cidr_block=cidr,
            opts=pulumi.ResourceOptions(parent=self)
        )
        
        self.mang_con = []
        for i, az in enumerate(["a", "b"]):
            mang = aws.ec2.Subnet(f"{ten}-mang-{az}",
                vpc_id=self.vpc.id,
                cidr_block=f"10.0.{i}.0/24",
                availability_zone=f"ap-northeast-1{az}",
                opts=pulumi.ResourceOptions(parent=self)
            )
            self.mang_con.append(mang)

So sánh chi tiết

Khi nào dùng Terraform

• Nhóm hỗn hợp (có người không phải lập trình viên)
• Hạ tầng đơn giản
• Cần hệ sinh thái lớn
• Đã đầu tư vào Terraform
• Doanh nghiệp với hỗ trợ HashiCorp

Khi nào dùng Pulumi

• Nhóm lập trình viên
• Logic phức tạp (vòng lặp, điều kiện)
• Cần kiểm thử đơn vị
• Thích ngôn ngữ lập trình thực
• Ưu tiên mã nguồn mở (sau Terraform BSL)

OpenTofu - Lựa chọn thay thế

Sau khi HashiCorp đổi giấy phép sang BSL, cộng đồng tạo nhánh OpenTofu:

# Thay thế trực tiếp
# Thay terraform bằng tofu
tofu init
tofu plan
tofu apply

Lời khuyên từ Fullstack Station

Cả hai đều là công cụ tốt. Gợi ý của mình:

• Mới bắt đầu: Terraform - tài liệu học nhiều hơn
• Nhóm lập trình viên: Pulumi - tận dụng kỹ năng lập trình
• Doanh nghiệp: Terraform Cloud hoặc Pulumi Cloud
• Ưu tiên mã nguồn mở: OpenTofu (nhánh Terraform)

Xu hướng 2025: Pulumi đang phát triển nhanh, đặc biệt trong các nhóm lập trình viên. Terraform vẫn chiếm ưu thế nhưng giấy phép BSL gây lo ngại.

Tham khảo

• Terraform
• Pulumi
• OpenTofu

The post Terraform vs Pulumi: So sánh hai công cụ IaC hàng đầu appeared first on Fullstack Station.

Terraform Modules là gì?

Module là container cho nhiều resources được sử dụng cùng nhau. Thay vì copy-paste code, bạn đóng gói thành module và tái sử dụng.

Cấu trúc Module

modules/
└── vpc/
    ├── main.tf       # Resources
    ├── variables.tf  # Input variables
    ├── outputs.tf    # Output values
    └── README.md     # Documentation

Tạo Module VPC

modules/vpc/variables.tf

variable "name" {
  description = "VPC name prefix"
  type        = string
}

variable "cidr" {
  description = "VPC CIDR block"
  type        = string
  default     = "10.0.0.0/16"
}

variable "azs" {
  description = "Availability zones"
  type        = list(string)
}

variable "enable_nat" {
  description = "Enable NAT gateway"
  type        = bool
  default     = true
}

modules/vpc/main.tf

resource "aws_vpc" "this" {
  cidr_block           = var.cidr
  enable_dns_hostnames = true
  
  tags = { Name = "${var.name}-vpc" }
}

resource "aws_subnet" "public" {
  count             = length(var.azs)
  vpc_id            = aws_vpc.this.id
  cidr_block        = cidrsubnet(var.cidr, 8, count.index)
  availability_zone = var.azs[count.index]
  
  tags = { Name = "${var.name}-public-${count.index + 1}" }
}

resource "aws_subnet" "private" {
  count             = length(var.azs)
  vpc_id            = aws_vpc.this.id
  cidr_block        = cidrsubnet(var.cidr, 8, count.index + 10)
  availability_zone = var.azs[count.index]
  
  tags = { Name = "${var.name}-private-${count.index + 1}" }
}

resource "aws_internet_gateway" "this" {
  vpc_id = aws_vpc.this.id
}

resource "aws_nat_gateway" "this" {
  count         = var.enable_nat ? 1 : 0
  allocation_id = aws_eip.nat[0].id
  subnet_id     = aws_subnet.public[0].id
}

resource "aws_eip" "nat" {
  count  = var.enable_nat ? 1 : 0
  domain = "vpc"
}

modules/vpc/outputs.tf

output "vpc_id" {
  value = aws_vpc.this.id
}

output "public_subnet_ids" {
  value = aws_subnet.public[*].id
}

output "private_subnet_ids" {
  value = aws_subnet.private[*].id
}

Sử dụng Module

# main.tf
module "vpc_prod" {
  source = "./modules/vpc"
  
  name       = "prod"
  cidr       = "10.0.0.0/16"
  azs        = ["ap-northeast-1a", "ap-northeast-1c"]
  enable_nat = true
}

module "vpc_staging" {
  source = "./modules/vpc"
  
  name       = "staging"
  cidr       = "10.1.0.0/16"
  azs        = ["ap-northeast-1a"]
  enable_nat = false  # Tiết kiệm chi phí
}

# Sử dụng outputs
resource "aws_instance" "web" {
  subnet_id = module.vpc_prod.public_subnet_ids[0]
  # ...
}

Module từ Terraform Registry

# Sử dụng module public
module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "5.0.0"

  name = "my-vpc"
  cidr = "10.0.0.0/16"

  azs             = ["ap-northeast-1a", "ap-northeast-1c"]
  private_subnets = ["10.0.1.0/24", "10.0.2.0/24"]
  public_subnets  = ["10.0.101.0/24", "10.0.102.0/24"]

  enable_nat_gateway = true
}

Best Practices

• Version modules – Dùng git tags hoặc semantic versioning
• Documentation – README.md với examples
• Validation – Dùng variable validation
• Testing – Terratest cho automated testing

# Variable validation
variable "environment" {
  type = string
  validation {
    condition     = contains(["dev", "staging", "prod"], var.environment)
    error_message = "Environment must be dev, staging, or prod."
  }
}

Module Composition

# Kết hợp nhiều modules
module "vpc" {
  source = "./modules/vpc"
  # ...
}

module "eks" {
  source     = "./modules/eks"
  vpc_id     = module.vpc.vpc_id
  subnet_ids = module.vpc.private_subnet_ids
}

module "rds" {
  source     = "./modules/rds"
  vpc_id     = module.vpc.vpc_id
  subnet_ids = module.vpc.private_subnet_ids
}

Fullstack Station Tips

Modules là cách organize Terraform code cho teams:

• Bắt đầu với modules nhỏ, đơn giản
• Dùng modules từ Registry khi phù hợp – đã được test kỹ
• Pin versions để tránh breaking changes
• Document inputs/outputs rõ ràng

Tham khảo

• Terraform Modules Docs
• Terraform Registry

The post Terraform Modules: Tái sử dụng infrastructure code hiệu quả appeared first on Fullstack Station.

Chuẩn bị

AWS Credentials

# Cấu hình AWS CLI
aws configure
# AWS Access Key ID: AKIAXXXXXXXX
# AWS Secret Access Key: xxxxxxxxxxxxx
# Default region: ap-northeast-1
# Default output format: json

Project Structure

aws-infrastructure/
├── main.tf
├── variables.tf
├── outputs.tf
├── vpc.tf
├── ec2.tf
├── rds.tf
├── alb.tf
└── security-groups.tf

VPC và Networking (vpc.tf)

# VPC
resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = {
    Name = "${var.project_name}-vpc"
  }
}

# Internet Gateway
resource "aws_internet_gateway" "main" {
  vpc_id = aws_vpc.main.id
}

# Public Subnets
resource "aws_subnet" "public" {
  count                   = 2
  vpc_id                  = aws_vpc.main.id
  cidr_block              = "10.0.${count.index + 1}.0/24"
  availability_zone       = data.aws_availability_zones.available.names[count.index]
  map_public_ip_on_launch = true

  tags = {
    Name = "${var.project_name}-public-${count.index + 1}"
  }
}

# Private Subnets
resource "aws_subnet" "private" {
  count             = 2
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.${count.index + 10}.0/24"
  availability_zone = data.aws_availability_zones.available.names[count.index]

  tags = {
    Name = "${var.project_name}-private-${count.index + 1}"
  }
}

# NAT Gateway
resource "aws_eip" "nat" {
  domain = "vpc"
}

resource "aws_nat_gateway" "main" {
  allocation_id = aws_eip.nat.id
  subnet_id     = aws_subnet.public[0].id
}

# Route Tables
resource "aws_route_table" "public" {
  vpc_id = aws_vpc.main.id

  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.main.id
  }
}

resource "aws_route_table" "private" {
  vpc_id = aws_vpc.main.id

  route {
    cidr_block     = "0.0.0.0/0"
    nat_gateway_id = aws_nat_gateway.main.id
  }
}

Security Groups (security-groups.tf)

# ALB Security Group
resource "aws_security_group" "alb" {
  name        = "${var.project_name}-alb-sg"
  description = "Security group for ALB"
  vpc_id      = aws_vpc.main.id

  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

# EC2 Security Group
resource "aws_security_group" "ec2" {
  name        = "${var.project_name}-ec2-sg"
  vpc_id      = aws_vpc.main.id

  ingress {
    from_port       = 80
    to_port         = 80
    protocol        = "tcp"
    security_groups = [aws_security_group.alb.id]
  }

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = [var.allowed_ssh_cidr]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

# RDS Security Group
resource "aws_security_group" "rds" {
  name   = "${var.project_name}-rds-sg"
  vpc_id = aws_vpc.main.id

  ingress {
    from_port       = 3306
    to_port         = 3306
    protocol        = "tcp"
    security_groups = [aws_security_group.ec2.id]
  }
}

EC2 Instance (ec2.tf)

resource "aws_instance" "web" {
  count                  = 2
  ami                    = data.aws_ami.amazon_linux.id
  instance_type          = var.instance_type
  subnet_id              = aws_subnet.private[count.index].id
  vpc_security_group_ids = [aws_security_group.ec2.id]
  key_name               = var.key_pair_name

  user_data = <<-EOF
    #!/bin/bash
    yum update -y
    yum install -y httpd
    systemctl start httpd
    systemctl enable httpd
    echo "Hello from $(hostname)" > /var/www/html/index.html
  EOF

  tags = {
    Name = "${var.project_name}-web-${count.index + 1}"
  }
}

RDS Database (rds.tf)

resource "aws_db_subnet_group" "main" {
  name       = "${var.project_name}-db-subnet"
  subnet_ids = aws_subnet.private[*].id
}

resource "aws_db_instance" "main" {
  identifier             = "${var.project_name}-db"
  engine                 = "mysql"
  engine_version         = "8.0"
  instance_class         = "db.t3.micro"
  allocated_storage      = 20
  storage_type           = "gp2"
  db_name                = var.db_name
  username               = var.db_username
  password               = var.db_password
  db_subnet_group_name   = aws_db_subnet_group.main.name
  vpc_security_group_ids = [aws_security_group.rds.id]
  skip_final_snapshot    = true
  multi_az               = false

  tags = {
    Name = "${var.project_name}-db"
  }
}

Application Load Balancer (alb.tf)

resource "aws_lb" "main" {
  name               = "${var.project_name}-alb"
  internal           = false
  load_balancer_type = "application"
  security_groups    = [aws_security_group.alb.id]
  subnets            = aws_subnet.public[*].id
}

resource "aws_lb_target_group" "main" {
  name     = "${var.project_name}-tg"
  port     = 80
  protocol = "HTTP"
  vpc_id   = aws_vpc.main.id

  health_check {
    path                = "/"
    healthy_threshold   = 2
    unhealthy_threshold = 10
  }
}

resource "aws_lb_target_group_attachment" "main" {
  count            = 2
  target_group_arn = aws_lb_target_group.main.arn
  target_id        = aws_instance.web[count.index].id
  port             = 80
}

resource "aws_lb_listener" "http" {
  load_balancer_arn = aws_lb.main.arn
  port              = "80"
  protocol          = "HTTP"

  default_action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.main.arn
  }
}

Deploy

# Khởi tạo và download providers
terraform init

# Xem kế hoạch
terraform plan

# Apply
terraform apply

# Output
terraform output alb_dns_name

Chi phí ước tính

• 2x t3.micro EC2: ~$15/tháng
• 1x db.t3.micro RDS: ~$13/tháng
• ALB: ~$16/tháng + data transfer
• NAT Gateway: ~$32/tháng
• Tổng: ~$76/tháng

Fullstack Station Tips

Infrastructure này là nền tảng tốt cho production workloads nhỏ. Một số cải tiến có thể làm:

• Thêm Auto Scaling Group cho EC2
• Bật Multi-AZ cho RDS
• Thêm CloudFront cho static assets
• Sử dụng Secrets Manager cho credentials

Trong bài tiếp theo, mình sẽ hướng dẫn về Terraform Modules để tái sử dụng code hiệu quả hơn.

Tham khảo

• AWS Provider Documentation
• Terraform Modules

The post Terraform với AWS: Hướng dẫn xây dựng infrastructure thực tế appeared first on Fullstack Station.

Terraform là gì?

Terraform là công cụ IaC cho phép bạn định nghĩa và quản lý infrastructure bằng code. Thay vì click chuột trên console AWS/GCP/Azure, bạn viết file cấu hình và Terraform sẽ tự động tạo, sửa, xóa resources.

Ưu điểm của Terraform:

• Multi-cloud – Hỗ trợ AWS, GCP, Azure, và hàng trăm providers khác
• Declarative – Mô tả trạng thái mong muốn, Terraform tự tìm cách đạt được
• Version control – Infrastructure được quản lý như code, có thể review, rollback
• Reusable – Modules cho phép tái sử dụng code

Cài đặt Terraform

macOS

brew tap hashicorp/tap
brew install hashicorp/tap/terraform

Ubuntu/Debian

wget -O- https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list
sudo apt update && sudo apt install terraform

Kiểm tra cài đặt

terraform version
# Terraform v1.8.x

Cấu trúc project Terraform

Một project Terraform cơ bản gồm các file:

my-infrastructure/
├── main.tf          # Resources chính
├── variables.tf     # Khai báo biến
├── outputs.tf       # Output values
├── terraform.tfvars # Giá trị biến (không commit lên git)
└── providers.tf     # Cấu hình providers

Ví dụ: Tạo EC2 instance trên AWS

1. Cấu hình Provider (providers.tf)

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

provider "aws" {
  region = "ap-northeast-1"  # Tokyo
}

2. Khai báo biến (variables.tf)

variable "instance_type" {
  description = "EC2 instance type"
  type        = string
  default     = "t3.micro"
}

variable "instance_name" {
  description = "Name tag for the instance"
  type        = string
  default     = "my-terraform-instance"
}

3. Định nghĩa Resource (main.tf)

data "aws_ami" "amazon_linux" {
  most_recent = true
  owners      = ["amazon"]

  filter {
    name   = "name"
    values = ["amzn2-ami-hvm-*-x86_64-gp2"]
  }
}

resource "aws_instance" "web" {
  ami           = data.aws_ami.amazon_linux.id
  instance_type = var.instance_type

  tags = {
    Name = var.instance_name
  }
}

resource "aws_security_group" "web_sg" {
  name        = "web-sg"
  description = "Allow HTTP and SSH"

  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

4. Output (outputs.tf)

output "instance_public_ip" {
  description = "Public IP of EC2 instance"
  value       = aws_instance.web.public_ip
}

output "instance_id" {
  description = "ID of EC2 instance"
  value       = aws_instance.web.id
}

Các lệnh Terraform cơ bản

# Khởi tạo project, download providers
terraform init

# Xem những thay đổi sẽ được thực hiện
terraform plan

# Áp dụng thay đổi (tạo/sửa/xóa resources)
terraform apply

# Xem state hiện tại
terraform show

# Xóa toàn bộ resources
terraform destroy

# Format code
terraform fmt

# Validate cấu hình
terraform validate

State Management

Terraform lưu trạng thái infrastructure trong file terraform.tfstate. Khi làm việc nhóm, nên dùng remote backend:

terraform {
  backend "s3" {
    bucket = "my-terraform-state"
    key    = "prod/terraform.tfstate"
    region = "ap-northeast-1"
    
    # Optional: State locking với DynamoDB
    dynamodb_table = "terraform-locks"
    encrypt        = true
  }
}

Best Practices

• Không commit terraform.tfvars – Chứa secrets, credentials
• Sử dụng remote backend – Cho team collaboration
• Tách môi trường – dev/, staging/, prod/ riêng biệt
• Dùng modules – Tái sử dụng code
• Pin provider versions – Tránh breaking changes
• Chạy terraform plan trước apply – Review changes

Fullstack Station Tips

Terraform là kỹ năng quan trọng cho bất kỳ developer nào làm việc với cloud. Mình khuyên bạn:

• Bắt đầu với AWS Free Tier để thực hành không tốn phí
• Đọc documentation của provider bạn dùng – rất chi tiết
• Học Terraform Cloud/Enterprise cho production
• Kết hợp với CI/CD (GitHub Actions, GitLab CI) để tự động hóa

Trong bài tiếp theo, mình sẽ hướng dẫn chi tiết hơn về Terraform với AWS, bao gồm VPC, RDS, và các services phức tạp hơn.

Tham khảo

• Terraform Documentation
• Terraform Registry
• HashiCorp Learn

The post Terraform cơ bản: Bắt đầu với Infrastructure as Code appeared first on Fullstack Station.

Với cặp Access key ID/AWS secret access key thì sẽ được sử dụng cho Amazon SES API, nhưng các plugin dành cho wordpress thì lại không hỗ trợ, nếu có hỗ trợ thì phải sử dụng bản PRO mới có.

Vì vậy muốn sử dụng gởi email qua smtp bằng user/password thì phải “tạo mật khẩu smtp từ AWS secret access key“

Bước 1: Tạo tập tin smtp_credentials_generate.py

Cứ copy rồi lưu lại thành tập tin là được, không cần chỉnh sửa gì thêm nhé.

#!/usr/bin/env python3

import hmac
import hashlib
import base64
import argparse

SMTP_REGIONS = [
    'us-east-2',       # US East (Ohio)
    'us-east-1',       # US East (N. Virginia)
    'us-west-2',       # US West (Oregon)
    'ap-south-1',      # Asia Pacific (Mumbai)
    'ap-northeast-2',  # Asia Pacific (Seoul)
    'ap-southeast-1',  # Asia Pacific (Singapore)
    'ap-southeast-2',  # Asia Pacific (Sydney)
    'ap-northeast-1',  # Asia Pacific (Tokyo)
    'ca-central-1',    # Canada (Central)
    'eu-central-1',    # Europe (Frankfurt)
    'eu-west-1',       # Europe (Ireland)
    'eu-west-2',       # Europe (London)
    'sa-east-1',       # South America (Sao Paulo)
    'us-gov-west-1',   # AWS GovCloud (US)
]

# These values are required to calculate the signature. Do not change them.
DATE = "11111111"
SERVICE = "ses"
MESSAGE = "SendRawEmail"
TERMINAL = "aws4_request"
VERSION = 0x04


def sign(key, msg):
    return hmac.new(key, msg.encode('utf-8'), hashlib.sha256).digest()


def calculate_key(secret_access_key, region):
    if region not in SMTP_REGIONS:
        raise ValueError(f"The {region} Region doesn't have an SMTP endpoint.")

    signature = sign(("AWS4" + secret_access_key).encode('utf-8'), DATE)
    signature = sign(signature, region)
    signature = sign(signature, SERVICE)
    signature = sign(signature, TERMINAL)
    signature = sign(signature, MESSAGE)
    signature_and_version = bytes([VERSION]) + signature
    smtp_password = base64.b64encode(signature_and_version)
    return smtp_password.decode('utf-8')


def main():
    parser = argparse.ArgumentParser(
        description='Convert a Secret Access Key for an IAM user to an SMTP password.')
    parser.add_argument(
        'secret', help='The Secret Access Key to convert.')
    parser.add_argument(
        'region',
        help='The AWS Region where the SMTP password will be used.',
        choices=SMTP_REGIONS)
    args = parser.parse_args()
    print(calculate_key(args.secret, args.region))


if __name__ == '__main__':
    main()

Chạy lệnh tạo mật khẩu

python path/to/smtp_credentials_generate.py wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY us-east-1

Sau khi chạy lệnh trên, chúng ta sẽ được 1 dãy ký tự mới, đó chính là mật khẩu STMP. Sử dụng Access key ID và mật khẩu được tạo ra ở trên để cài đặt trong các plugin gởi email bằng SMTP. Bên dưới là phần thiết lập cho plugin WP MAIL SMTP:

Tham khảo thêm các bài viết về Amazon SES:

https://docs.aws.amazon.com/ses/latest/dg/smtp-credentials.html

https://cuongthach.com/email-marketing/huong-dan-su-dung-amazon-ses-smtp-de-gui-email-tu-wordpress

https://vticloud.io/amazon-ses-la-gi-huong-dan-tong-hop-ve-dich-vu-amazon-ses/

The post Tạo mật khẩu SMTP trong Amazon SES appeared first on Fullstack Station.

Grep

Thường thì “grep” được dùng để tìm kiếm text trong file, rất hay được dùng khi kiểm tra log hoặc tập tin văn bản.

$ grep 'keyword' /var/log/path.log

Một số tuỳ chọn hữu ích

$ grep -A 5 -B 6 --color 'keyword' /var/log/path.log

Lệnh trên sẽ làm nổi bật `keyword` bằng màu sắc với --color, và -A 5hiển thị 5 dòng sau (A: After) dòng có chứa keyword, tương tự với -B 6 là hiển thị 6 dòng trước (B: Before) dòng có chứa keyword, nếu dùng -C 7 thì nghĩa là trước 7 dòng và sau 7 dòng.

Kết hợp wc

Chúng ta sẽ kết hợp với wc (wordcount) để đếm số dòng, số byte, số ký tự mà chúng ta cần

$ grep 'keyword' /var/log/path.log | wc -l

Với lệnh trên, thì sẽ đếm xem có bao nhiêu dòng chứa `keyword`, hoặc thay thế tuỳ chọn -l bằng -m sẽ đếm xem có bao nhiêu ký tự, hoặc -c sẽ đếm byte, thường dùng nhất vẫn chỉ có -l.

Kết hợp awk

$ cat access.log | awk '{print $1}'

Nâng cao thêm 1 chút bằng printf

$ cat access.log | awk '{printf ("Nội dung là %s %s", $1, $2)}'

Ứng dụng vào việc tìm IP có số lượng gởi yêu cầu vào máy chủ nhiều nhất

$ cat access.log | awk '{print $1}' | sort -n | uniq -c | sort -nr | head -20

Giả sử $1 ở đây là IP (file log thông thường của server), thì lệnh awk sẽ lấy danh sách IP, và được sắp xếp và lấy duy nhất không trùng lặp bằng lệnh sort -n | uniq -c sau đó sắp xếp đảo ngược với sort -nr và kết thúc là lấy 20 kết quả đầu tiên bằng head -20

Tìm kiếm tập tin, thư mục bằng Find

Lệnh find cũng ít khi sử dụng, nhưng tầm quan trọng và tính hữu dụng thì rất cao.

find -type f -name ‘*.log’ -mtime +15

Câu lệnh trên cơ bản tìm trong thư mục hiện hành tất cả các tập tin có đuôi .log với thời gian cập nhật mtime hơn 15 ngày (+15) hoặc có thể tìm theo thời gian tạo bằng ctime

Lệnh này được sử dụng khi cần xoá các tập tin khi dung lượng ổ cứng bị đầy, hoặc là cần lập lịch tự động xoá file backup sau 15 ngày chẳng hạn.

Kết hợp xoá tập tin

find -type f -name ‘*.log’ -mtime +15 -exec rm {} \;

hoặc

find -type f -name ‘*.log’ -mtime +15 | xargs rm

Tìm thư mục có dung lượng cao

du -h | sort -hr | head -5

Câu lệnh trên cho phép tìm 5 thư mục có dung lượng cao nhất trong thư mục hiện hành, nếu ta thêm --max-depth=1 thì lệnh chỉ giới hạn ở thư mục con cấp 1.

Fullstack Station Tips

Có hằng hà sa số câu lệnh cần thiết, nhưng mấy lệnh này mình hay sử dụng nhất. Từ các lệnh cơ bản này, bạn có thể xem phần `help` của mỗi lệnh để có thêm tuỳ chọn.

The post Một số lệnh hữu ích cho xử lý tập tin, thư mục bằng command line appeared first on Fullstack Station.

Cập nhật 04/2024: Serverless AI là gì?

Serverless là gì?

Serverless là môi trường, nền tảng thực thi ứng dụng và dịch vụ mà không phải quan tâm đến máy chủ. Ứng dụng serverless không cần phải  quan tâm việc phân bổ, quản lý tài nguyên của hệ điều hành, và bỏ qua các vấn đề về nâng cấp và bảo mật. Với khái niệm là chỉ cần tập trung phát triển sản phẩm, việc còn lại về vận hành sẽ để nền tảng này đảm nhiệm.

Điều quan trọng và khác biệt nhất trong serverless là bạn chỉ trả tiền khi và chỉ những phần bạn sử dụng. Giả sử bạn có một máy chủ ảo, thì thường sẽ được tính tiền trọn gói bao gồm thời gian chạy 24/7 trong 1 tháng, CPU và RAM, băng thông, lưu trữ. Bạn vẫn sẽ phải trả tiền hàng tháng đều đặn cho dù cái máy chủ ảo đó không chạy, hoặc chỉ sử dụng 5~10% công suất thì bạn vẫn phải trả trọn gói. Hiểu một cách nôm na, thì serverless như gói cước điện thoại được tính theo block giây, gọi bao nhiêu tính tiền bấy nhiêu, còn máy chủ ảo thường thì phải trả tiền thuê bao hàng tháng dù có phải sử dụng hay không.

Ưu và nhược điểm của serverless

Ưu điểm

Xây dụng ứng dụng serverless đồng nghĩa với việc bạn chỉ tập trung vào sản phẩm cốt lõi thay vì phải lo lắng về việc quản lý và vận hành nhiều máy chủ hoặc thời gian chạy, dù trên nền tảng đám mây hay tự xây dựng hệ thống máy chủ. Sự cắt giảm công sức tổng thể này sẽ giúp cho các nhà phát triển dành thời gian và năng lượng để tập trung vào việc xây dựng các sản phẩm tuyệt vời có quy mô linh hoạt và ổn định cao.

Không cần quản lý máy chủ: Bạn sẽ không cần cung cấp hay duy trì bất kỳ máy chủ nào. Sẽ không cần phần mềm hoặc thời gian chạy để cài đặt, nâng cấp hoặc quản trị.

Thay đổi quy mô một cách linh hoạt: Ứng dụng của bạn sẽ có khả năng thay đổi quy mô tự động hoặc bằng cách điều chỉnh dung lượng thông qua việc chuyển đổi đơn vị sử dụng (ví dụ: thông lượng, bộ nhớ) thay vì với máy chủ độc lập thì sẽ phức tạp hơn.

Độ sẵn sàng cao: Ứng dụng serverless có độ sẵn sàng tích hợp và dung sai cao. Bạn sẽ không cần tạo kiến trúc cho các khả năng này do các dịch vụ chạy ứng dụng đã cung cấp cho ứng dụng theo mặc định. Ngoài ra, có để chọn trung tâm dữ liệu (một hoặc nhiều nơi) để triển khai sản phẩm một cách dễ dàng.

Tiết kiệm chi phí: chi phí gần như bằng 0 sau khi triển khai nếu bạn không có request nào (hoặc không có hành động gọi hàm), còn sử dụng bao nhiêu thì tính tiền bấy nhiêu.

Khuyết điểm

Serverless là một ý tưởng tuyệt vời nhưng không hoàn hảo, serverless có những vấn đề riêng mà bạn cũng phải suy nghĩ trước khi quyết định sử dụng:

Độ trễ: Hiệu suất có thể là một vấn đề, chính bản thân mô hình này có thể gây ra độ trễ lớn hơn trong quá trình các nguồn tài nguyên điện toán phản ứng lại với lệnh của các ứng dụng. Nếu khách hàng yêu cầu hiệu suất cao thì việc sử dụng các máy chủ ảo được phân bổ sẽ là một lựa chọn ưu việt hơn.

Gỡ lỗi (Debug): Công việc giám sát và gỡ lỗi của serverless computing cũng khá khó khăn. Việc bạn không sử dụng một nguồn tài nguyên máy chủ thống nhất làm cho cả hai hoạt động này gặp nhiều trở ngại. (Tin tốt là công cụ này sẽ dần được để cải thiện xử lý giám sát và gỡ lỗi tốt hơn trong môi trường không máy chủ.). Ngoài ra, để giám sát thường cần có 1 thêm các công cụ tương ứng nền tảng đó, chi phí có thể phát sinh thêm.

Giới hạn về bộ nhớ, thời gian: các nhà cung cấp đều giới hạn tài nguyên ở các mức cố định về bộ nhớ và thời gian thực thi (timeout). Giả sử timeout tối đa là 5 phút, nếu bạn chạy quá 5 phút, quá trình thực thi sẽ bị ngắt. Về bộ nhớ, thì sẽ thiết lập mỗi mức khác nhau tuỳ nhà cung cấp, AWS có memory là 3008MB (sẽ được cấp CPU cao tương ứng), nếu ứng dụng yêu cầu bộ nhớ lớn thì sẽ không đáp ứng được. Liên quan đến vấn đề bộ nhớ này, thì cũng cần phải lưu tâm lúc lập trình nên tối ưu tốt, để tiết kiệm chi phí.

Phụ thuộc nhà cung cấp: bạn không thể muốn chạy phiên bản của phần mềm, nền tảng chính xác như bạn muốn. Ví dụ Nodejs bạn cần 10.x nhưng nhà cung cấp chỉ hỗ trợ đến 8.x, thì bạn sẽ không sử dụng được nền tảng này. Như vậy, trước khi sử dụng, bạn cần cân nhắc các nền tảng được hỗ trợ.

Chi phí ngầm: tuỳ nhà cung cấp có tính hay không, nhưng cơ bản là sẽ phát sinh chi phí lưu trữ mã nguồn, băng thông, và chi phí về lưu trữ dữ liệu (tuỳ ứng dụng có sử dụng hay không, ví dụ DynamoDB, RDMS … thì sẽ được tính riêng). Mặc dù, tuy không nhiều nhưng nếu không tối ưu, các phần chi phí ngầm sẽ còn cao hơn cả chi phí cho serverless.

Thời gian để nghiên cứu: trước đây bạn phải học cách sử dụng, quản lý máy chủ thì giờ đây bạn cũng cần thời gian để học để quản lý các tài nguyên trong serverless, mặc dù ko phải quá khó như quản lý máy chủ, nhưng không thể không tính. Ví dụ bạn sẽ mất thời gian để hiểu về cách sử dụng CloudFormation, IAM policies, quản lý cấu hình về stage, region, memory của Functions…

Khi nào nên sử dụng serverless

Có rất nhiều trường hợp có thể ứng dụng được serverless, điểm chung là tất cả những ứng dụng không dính dáng đến điểm yếu của serverless

Websites và APIs: hoàn toàn có thể xây dựng 1 website hoặc API, website có thể là động hoặc là bán tĩnh (bán tĩnh nghĩa là nguồn gốc file là tĩnh, nhưng dùng route động). Thường thì người ta hay xây dựng Restful API với serverless, nhưng mình thích áp dụng cho Graphql hơn, vì Restful có thể trả về dữ liệu không dùng tới nhưng mình phải trả tiền băng thông (Xem thêm Graphql là gì).

Xử lý đa phương tiện: các thao tác xử lý hình ảnh, video với yêu cầu không quá cao như cắt, nén, định dạng kích thước ảnh, tạo ảnh thumbnail, hoặc chuyển đổi bộ mã của video để phù hợp với thiết bị tương ứng.

Xử lý sự kiện: có thể đóng vai trò như 1 công tắc cầu giao để thực hiện một loạt các hành động khác khi được kích hoạt tuỳ theo sự kiện.

Xử lý dữ liệu: tuỳ theo ngữ cảnh mà có thể ứng dụng như chatbot, IoT,… lý do mà serverless thích hợp với mảng này vì với chatbot hay IoT chúng ta không biết khi nào dữ liệu sẽ tới, khi nào sẽ cần xử lý dữ liệu nên chúng ta không cần phải xây dựng máy chủ luôn luôn chạy và lãng phí ở thời gian chờ.

So sánh một số nhà cung cấp hàng đầu

Hiện nay có rất nhiều nhà cung cấp dịch vụ giúp bạn tạo ra các functions sử dụng mô hình serverless một cách khá dễ dàng:

• AWS Lambda: nói về thị phần cung cấp hạ tầng cloud hiện nay thì AWS vấn đang dẫn đầu và họ cũng đưa ra dịch Lambda để người dùng có thể sử dụng và tạo ra các functions trên mô hình serverless. Khi kết hợp với các dịch vụ khác như API Gateway, S3,.. thì có thể tạo được một API server hay một hệ thống tự động xử lí khi có file upload lên S3. AWS Lambda hỗ trợ khá nhiều ngôn ngữ như Node.js, Java, C#, Python,…
• Google Cloud Function: hỗ trợ ngôn ngữ khá đa dạng (Nodejs, Go, Python, Java, PHP, .NET Core)
• Azure Functions: hàng của Microsoft, hỗ trợ C#, JavaScript, F#, Python, Batch, PHP, PowerShell

Còn nhiều nhà cung cấp khác như Kubeless, Fn,… tuy nhiên 3 ông ở trên có lẽ có thị phần lớn nhất và được quan tâm hơn. Ở dưới là chi tiết so sánh 1 số thông số giữa AWS Lambda, Google Cloud Function và Azure Function

Xây dựng hệ thống để trở thành nhà cung cấp serverless

Vì sự nổi trội về ưu điểm của serverless, nên hiện nay cũng đã có một số mã nguồn mở để xây dựng thành nền tảng cung cấp serverless

https://www.serverless.com/

OpenFaaS – Serverless Functions Made Simple

https://github.com/openfaas/faas

FireCracker – Secure and fast microVMs for serverless computing

https://github.com/firecracker-microvm/firecracker

Mình thì chỉ quan tâm tới việc xài thôi, nên không tìm hiểu được ở mảng này.

Fullstack Station Tips

Ngày nay khi mà các công cụ hỗ trợ lập trình viên tập trung vào việc xây dựng sản phẩm càng nhiều, thì rõ ràng chính lập trình viên chính là những người hưởng lợi nhất. Serverless là tương lai của những lập trình viên độc lập, khi không còn phụ thuộc vào phần cứng, máy chủ nữa.

Serverless giúp cho chúng ta không còn lo về chi phí duy trì máy chủ, không còn lo khi sản phẩm chưa có doanh thu đã phải trả tiền duy trì. Cho dù serverless là không hoàn hảo, nhưng với những ưu điểm nhiều hơn khuyết điểm và khả năng ứng dụng rộng lớn, serverless là một mảnh đất màu mỡ cho bạn phát triển.

Bạn không cần phải cân nhắc nhiều giữa các nền tảng, hãy chọn nền tảng nào bạn đã có kiến thức, hoặc được khuyến mại – giảm chi phí sử dụng. Các nhà hạ tầng luôn luôn phát triển, nên ngoại trừ về đặc điểm ngôn ngữ, các nhà cung cấp đều tương đương nhau. Hãy tập trung vào sản phẩm của mình là tốt rồi, khi có rào cản – tức là đã đạt giới hạn của sản phẩm – cũng có nghĩa là đã có thể có doanh thu, lợi nhuận thì lúc này mới nên tìm hiểu thêm để chuyển qua hệ thống cung cấp serverless khác là ổn nhất.

Quan điểm của Fullstack Station là đa năng, gọn nhẹ và không phụ thuộc, muốn trở thành lập trình viên độc lập thì càng nên học và ứng dụng serverless.

Tham khảo:

http://tech.vtijapan.co.jp/serverless-gioi-thieu-chung-chung/

https://serverless.com/learn/use-cases/

https://www.alibabacloud.com/blog/4-use-cases-of-serverless-architecture_593862

https://epsagon.com/the-best-5-use-cases-for-the-serverless-beginner/

The post Serverless là gì? Hãy sẵn sàng với serverless! appeared first on Fullstack Station.

Những dịch vụ này có tài nguyên giới hạn (RAM < 1GB) hoặc một vài hạn chế nhất định, nhưng nếu bạn biết tận dụng và cấu hình tốt thì chi phí máy chủ cho khởi nghiệp là bằng 0. Các dịch vụ này hoạt động thường với nguyên tắc là “Pay as you go” tức là xài nhiêu trả nhiêu nên khá là thoải mái nếu sau này sản phẩm của bạn phát triển lên – nghĩa là có khách hàng, có thu nhập.

Danh sách dịch vụ máy chủ miễn phí

AppHarbor

Bảng giá

• Miễn phí: 1 worker unit
• Ưu điểm: auto scaling, deploy với git, đặc biệt hỗ trợ .NET
• Giới hạn: không hỗ trợ việc sử dụng domain riêng của bạn

AWS EC2

Đăng ký

• Miễn phí: 750 giờ/tháng cho gói t2.micro
• Điểm mạnh: đầy đủ chức năng của VPS và toàn bộ tính năng của hệ thống AWS EC2
• Giới hạn: 12 tháng cho mỗi đăng ký, tương ứng 1 credit card. 

GearHost

Bảng giá

• Miễn phí: 1 shared node và 1 worker, 100MB lưu trữ, 1GB băng thông/tháng, tùy chỉnh tên miền
• Ưu điểm: hỗ trợ .NET (4.6), PHP (5.3-5.5) và ứng ụng Node.js, cơ sở dữ liệu MSSQL và MySQL, dễ dàng xuất bản với FTP, WebDeploy hoặc trực tiếp từ Git/GitHub/Bitbucket.
• Giới hạn:
  • Giới hạn tích lũy CPU (60 phút được cấp phát mỗi 24 giờ) và RAM (256 MB được cấp pháp cho mỗi giờ), 1 GB băng thông được cấp phát mỗi 24 giờ, 250 kết nối đồng thời (con số này đạt được thì kiếm được tiền rồi), không hỗ trợ SSL và chỉ hỗ trợ 32bit.
  • Khi mức sử dụng CPU, RAM, băng thông đạt giới hạn thì ứng dụng sẽ bị rơi vào trạng thái offfline và được sẽ hoạt động lại tới khi được reset.

Google App Engine

Trang sản phẩm

• TấtMiễn phí: 28 giờ instance/ngày, băng thông 1GB chiều ra/ngày,băng thông 1GB vào/ngày.
• Ưu điểm: thừa kế toàn bộ tính năng của hệ thống Google Cloud: được quản lý, tự động scale, load balancing, …
• Giới hạn: chỉ hỗ trợ Python, Java, PHP và Go, vì đây là các môi trường chuẩn chỉ được chọn phiên bản nhất định ví dụ Python 2 hoặc Python 3, PHP 5 hoặc PHP 7. Còn với môi trường linh hoạt như Ruby và Node.js thì không được miễn phí.

Heroku

Bảng giá

• Miễn phí: gói “dyno” (512MB RAM), tùy chỉnh tên miền
• Ưu điểm: hỗ trợ nhiều ngôn ngữ (Node.js, Ruby, Java, PHP, Python, Go, Scala or Clojure)
• Giới hạn: instance sẽ bị rơi vào trạng thái ngủ đông khi không có hoạt động, ví dụ web không có ai truy cập trong 30 phút thì nó sẽ bị ngủ đông. Khi có truy cập thì nó tự động khởi động và hoạt động bình thường. Mình đang dùng Heroku để triển khai Huginn, khá ngon

IBM Bluemix

Bảng giá

• Miễn phí: gói 512MB/tháng
• Ưu điểm: có thể triển khai các con VPS nhỏ với tổng cộng 512MB (Ví dụ: 4x128MB, 2x256MB…), hỗ trợ nhiều ngôn ngữ (Java, JS, Go, PHP, Python Ruby), hỗ trợ containers

OpenShift

Bảng giá

• Miễn phí: 3 small gears (1 CPU, 512MB RAM and 1GB lưu trữ), tương đương 3 CPU, 1,5GB RAM và 3 GB lưu trữ
• Ưu điểm: mỗi gear có thể để sử dụng để triển khai ứng dụng trong nhiều ngôn ngữ hoặc cơ sở dụng liệu, cũng có sẵn nhiều template cho việc triển khai.
• Giới hạn:
  • Triển khai đòi hỏi phải cài đặt ựng dụng OpenShift.
  • Bị ngủ đông nếu trong 24h không có request.
  • Nếu ứng dụng rơi vô trạng thái ngủ đông thì mất hơn 30s để hoạt động trở lại.

Zeit Now

Bảng giá

• Miễn phí: 1GB lưu trữ, băng thông 1GB tháng, 20 lần triển khai/tháng, miễn phí sao lưu
• Ưu điểm: tự động scale, miễn phí sao lưu, có thể triển khai HTTP/2, sử dụng phiên bản mới nhất của Node.js. Tất nhiên là nó cũng có thể dùng để triển khai web tĩnh.
• Giới hạn: mỗi tập tin có dung lượng tối đa 1MB (cái này thì cũng không cần lo lắm), không tùy chỉnh tên miền. Tuy nhiên, mã nguồn bị đặt ở chế độ công cộng là điểm trừ khá lớn.

Đánh giá

Tùy thuộc vào hệ thống của bạn sử dụng những công nghệ nào để chọn, nhưng theo đánh giá của mình (và có sử dụng một vài kỹ thuật tối ưu) thì máy chủ miễn phí sẽ có những thứ tự sau:

1. OpenShift
2. IBM Bluemix
3. Heroku
4. AWS EC2
5. Google App Engine
6. AppHarbor
7. GearHost
8. Zeit Now

Trong danh sách dịch vụ máy chủ miễn phí này thì tất nhiên xài cái nào cũng có giới hạn nhất định,. Nhưng mình chọn OpenShift đứng vị trí số vì ngoài tài nguyên nhiều nhất thì chúng ta cũng có thể khắc phục giới hạn của nó. Còn IBM Bluemix thì cũng khá linh động khi cho phép tạo nhiều VPS nhỏ và hỗ trợ container nữa. Heroku thì cũng có khắc phục được giới hạn thời gian.

Fullstack Station’s Tips

Trong bài giới thiệu về Next.js mình có nói về microservice, và cũng như sự lên ngôi của microservice trong thời gian tới. Mặc dù độ trễ khi kết nối các microservice là điều khó tránh khỏi nhưng về mặt linh động và hạn chế rủi ro thì microservice rất tốt. Với các dịch vụ máy chủ miễn phí này, bạn hoàn toàn có thể tự xây dựng cho mình một mạng lưới các microservice  như vậy để hạn chế chi phí trong quá trình lập trình.

Dưới đây là một số thủ thuật để nâng cao hiệu quả sử dụng các dịch vụ trên:

• AWS EC2: bạn có thể dùng 1 credit card khác đăng ký để sử dụng thêm.
• Các dịch vụ như Heroku, OpenShift bị ngủ đông sau 1 khoảng thời gian nhất định thì bạn dùng một máy khác và tạo cronjob để thực hiện request vào các máy này để không cho nó ngủ. Hoặc sử dụng các dịch vụ ngoài, hiện tại thì có UptimeRobot miễn phí với 50 monitors (tương đương 1 lệnh theo dõi)
• Với các dịch vụ trong top 4 thì bạn có thể chạy 1 website nhỏ khá thoải mái, ngoài ra còn có thể sử dụng các dịch vụ này để làm một số tác vụ như:
  • Chạy cron
  • Chỉnh sửa hình ảnh
  • API đơn giản
  • Task queue: nếu sử dụng mô hình phân tán nhiệm vụ như Gearman bạn có thể tạo ra được một hệ thống mạnh mẽ, với tổng các dịch vụ được giới thiệu tầm 4GB RAM hơn 8 CPU, đây là một con số không hề nhỏ.

Kết

Hi vọng với việc giới thiệu các dịch vụ máy chủ miễn phí này, bạn có thể thoải mái tập trung vào việc phát triển sản phẩm trong thời gian lâu hơn, và có thể nắm rõ hệ thống microservice để hạn chế chi phí sau này. Mặc dù việc nghiên cứu sử dụng các dịch vụ này là cần có, cũng như những sự cố có thể xảy ra đòi hỏi tốn thời gian bảo trì. Tuy nhiên với những kinh nghiệm bạn trải qua đó, bạn hoàn toàn có thể tận dụng những máy chủ miễn phí này để xây dựng môi trường Production. Đây là một điều lý tưởng cho khởi nghiệp khi triển khai không tốn chi phí.

Chúc mọi người thành công trong năm mới 2017, Happy New Year!!!

The post Danh sách dịch vụ máy chủ miễn phí appeared first on Fullstack Station.

Website tĩnh là gì

Website tĩnh là web không có nội dung thay đổi liên tục trong khoảng thời gian ngắn, chỉ toàn là html, javascript và css thôi. Không hề có kết nối API nào cả, nên dĩ nhiên máy chủ không có cơ sở dữ liệu. Nếu bạn sử dụng Github thì có thể biết tới Github Page, chúng ta viết bằng markdown và được máy chủ tạo (generate) thành html, hoàn toàn là website tĩnh.

Nói đến đây, chắc hẳn bạn nào đang theo dõi blog này cũng đều nghĩ “ồ, thật đơn giản, chỉ là môn học lập trình web cơ bản”, vì chắc bạn cũng đã từng học rồi. Với lại trong thế giới phẳng phát triển nhanh chóng như hiện nay, thì web tĩnh thiệt là lạc hậu, tuy nhiên sẽ là sai lầm nếu bạn chưa hiểu rõ web tĩnh có những ưu khuyết điểm đối với website của mình như thế nào. Chúng ta thường ưu tiên phát triển website động, đơn giản là vì nó nhanh, ngay cả blog này cũng sử dụng wordpress, nhanh gọn lẹ. Tuy nhiên, đó cũng chính là lỗ hổng bảo mật mà web động mang lại. Hơn nữa, khi website đạt đến một độ lớn nhất định nào đó, nằm top 1000 của VN chẳng hạn, thì vấn đề máy chủ bắt đầu trở nên phức tạp và tốn kém. Việc triển khai cân bằng tải (mức máy chủ, cơ sở dữ liệu, tài nguyên tĩnh) trở nên khó khăn hơn rất nhiều.

Ưu và khuyết của website tĩnh

Mặc dù gọi là lạc hậu, nhưng đây vẫn là cốt lõi của web, tất cả những gì hiển thị đến người dùng là html, css, js và phim, hình ảnh. Web tĩnh cũng có ưu điểm và khuyết điểm tương ứng với nhu cầu của website. Độ bảo mật của website tỉ lệ nghịch với chức năng tương tác của người dùng, có nghĩa là càng cho người dùng tương tác với với máy chủ (POST, PUT, DELETE) thì bảo mật càng thấp, tất nhiên ngay cả phương thức GET cũng chứa đầy nguy hiểm với các tham số đi kèm. Chúng ta xem danh sách ưu khuyết điểm của kỹ thuật lập trình web tĩnh sau:

Khuyết điểm

• Khó cập nhật tức thì nội dung, giả sử có sai sót trong nội dung thì thời gian cập nhật sẽ lâu hơn so với web động
• Trang web đơn thuần 1 chiều, không có tương tác từ người dùng

Ưu điểm

• Tốc độ nhanh nhất, bạn dễ dàng áp dụng các kỹ thuật Pagespeed
• An toàn nhất, loại trừ yếu tố bị tấn công từ bên trong máy chủ, việc tấn công 1 trang web tĩnh chỉ mở duy nhất port 80, 443 là rất khó, nếu không nói là không thể (trừ trường hợp lỗi của web server như Nginx, Apache thì cũng khá là hiếm).
• Nhu cầu cấu hình máy chủ thấp, nên chi phí máy chủ thấp, cũng như các chi phí vận hành, bảo trì, sao lưu dự phòng.

Mặc dù có khuyết điểm, nhưng với ưu thế tuyệt đối về ưu điểm, và áp dụng cho phần lớn các website hiện nay. Ngoại trừ các website mang tính chất trao đổi nhiều như diễn đàn, hỏi đáp/thảo luận, thương mại điện tử, trò chơi trực tuyến, và hầu hết dịch vụ có tính chất trực tuyến. Vì đặc tính cập nhật theo thời gian, nên không thể sử dụng kỹ thuật lập trình web tĩnh được, còn các loại website khác (xem tiếp phần bên dưới) đều có thể áp dụng được.

Những loại website nào nên áp dụng

Hầu hết website đều có thể áp dụng được, đặc biệt là những loại website tương tác 1 chiều như Tin tức, Giới thiệu sản phẩm, Blog đều có thể sử dụng kỹ thuật web tĩnh để tăng cường hiệu quả. Những website thể loại diễn đàn như tinhte, webtretho nếu có ấn phẩm riêng, tức là những bài viết tuyển chọn, có biên tập tạo thành bài đọc 1 chiều cũng đều có thể sử dụng web tĩnh, không nhất thiết phải dùng web động.

Các website hiện nay đa phần đều có cho phép người dùng phản hồi, góp ý kiến, chức năng này nên tách riêng ra thành một dịch vụ riêng (nằm ở máy chủ khác độc lập), nằm ở 1 cụm máy chủ khác (xem mục Mô hình triển khai bên dưới), hoặc sử dụng các dịch ngoài như Facebook Comment, Google+, Disqus là đủ. Nói đến đây, bạn cũng có thể liên tưởng đến phân quyền người dùng trong hệ thống, có những tài nguyên chỉ cho phép đọc, hoặc tài khoản dùng để kết nối database cũng có thể chia làm 2 loại: đọc và ghi (bao gồm thêm, xóa, sửa). Nếu bạn là dân lập trình web PHP, cũng có thể xem thêm qua bài Những lỗi lập trình viên PHP hay mắc phải, trong đó có đề cập đến 1 số lỗi liên quan bảo mật để hạn chế những rủi ro không đáng.

Đối với loại website có tài khoản người dùng, có thể chia ra thành 2 loại server khác nhau, một máy chủ chứa dữ liệu chỉ đọc bao gồm tài nguyên tĩnh có thể truy xuất ở chế độ công cộng (public – http://tên-miền.com), một máy chủ chứa dữ liệu có thể thay đổi ở cơ sở dữ liệu nằm riêng (Ví dụ: http://my.tên-miền.com)

Kỹ thuật lập trình Server Side Include (SSI)

Kỹ thuật thêm (include) tài nguyên từ nhiều tập tin khác nhau không có gì mới khi bạn sử dụng ngôn ngữ lập trình động (PHP, Python, Ruby, Js hay .Net). Tuy nhiên, kỹ thuật SSI bằng webserver lại ít được biết đến, vì nó không nằm trong các chương trình giảng dạy, hoặc nếu có thì hầu như không được chú ý. Với kỹ thuật web tĩnh, máy chủ web chỉ cài đặt duy nhất web server mà không có hỗ trợ ngôn ngữ động, không PHP, không Nodejs, không Ruby, … (Mặc dù có thể cài đặt  để chạy ở chế độ cli, còn ngoài ra các request đến server đều được trả về bằng tập tin tĩnh hết, tuy nhiên mình khuyến nghị không nên cài nếu không cần thiết)

Giống nhau

• Đều là hành động thêm một tập tin khác

Khác nhau

• Ngôn ngữ lập trình động có thể include tập tin cùng loại, hoặc tập tin html
• SSI chỉ có thể include html, nhưng đặc biệt là có thể include “kết quả xử lý” từ ngôn ngữ động

Ví dụ xét đoạn mã SSI của Nginx sau:

<!--# include virtual="http://server-B/remote/body.php?argument=value" wait="yes" -->

Đoạn mã trên được sử dụng trong 1 tập tin của server A, và lấy nội dung trả về từ server B, sau đó trả về cho khách. Đây chỉ là ví dụ để bạn hình dung về việc include, chứ trong thực tế thì cách include như trên ảnh hưởng đến tốc độ của máy chủ. Nếu như hai máy chủ được nằm trong 1 cụm chung data-center thì tốc độ cũng gọi là chấp nhận.

Qua ví dụ này, bạn cũng có thể thấy rõ là cấu trúc động-tĩnh hoàn toàn có thể ăn khớp với nhau, cũng giống như quảng cáo gắn trên mỗi trang, thay đổi theo thời gian, bài viết, đối tượng…thì cũng gọi là động rồi (động ở đây sử dụng javascript để lấy dữ liệu – khác với kỹ thuật SSI nhé). Vậy nên phân chia tài nguyên, nhiệm vụ cho từng máy chủ là rất cần thiết, vừa nâng cao hiệu quả hoạt động, tốc độ tốt lại bảo mật hơn.

Sử dụng cho Nginx: http://nginx.org/en/docs/http/ngx_http_ssi_module.html

Sử dụng cho Apache: https://httpd.apache.org/docs/current/howto/ssi.html

Công cụ

Hiện tại đã có một website tập hợp tất cả các công cụ mã nguồn mở:

https://www.staticgen.com/

Bạn chỉ cần sử dụng các công cụ trên tương ứng với framework và ngôn ngữ lập trình. Công cụ đó sẽ tạo ra file tĩnh, và bạn chỉ cần thiết lập cơ chế đồng bộ tuỳ theo độ lớn của website.

Nếu hệ thống là tự lập trình ra, thì chắc là khó có công cụ đáp ứng đúng, vì vậy phải tốn công sức để tạo ra html từ hệ thống. Tuy nhiên, kỹ thuật này thì không có gì khó khăn cả, quan trọng là bạn có áp dụng hay không mà thôi.

Mô hình triển khai máy chủ

Mô hình

Mô hình này ở trên được triển khai với 6 (hoặc 8 nếu tách database) máy chủ, bao gồm:

• 2 máy chủ sử dụng HA Proxy cấu hình nhỏ gọn để cân bằng tải, không cần cũng được, tuy nhiên đối với website lớn thì rất cần thiết.
• 2 máy chủ chỉ cài đặt máy chủ web (Nginx hoặc Apache) đơn giản nhất, không cài thêm bất cứ module nào nếu bạn không thực sự nắm chắc sự cần thiết.
• 2 máy chủ chính dùng để cái hệ thống quản lý (CMS, Blog, …), được đặt trong một lớp mạng riêng với 2 máy chủ web ở trên. Và chỉ đồng bộ dữ liệu 1 chiều từ 2 máy chủ (Main System) lên máy chủ web (Static files server). Để đạt độ bảo mật an toàn thì 2 máy chủ này chỉ được phép truy cập từ mạng nội bộ.
• 2 máy chủ chứa database cài đặt cơ chế Replicator (Master-Slave hoặc cả 2), nếu tình hình tài chính eo hẹp, có thể thu gọn 2 máy chủ này vào 2 máy chủ Main System.
• Các đường kết nối màu xanh và đỏ chỉ sự tương tác 1 chiều, đây là điều rất quan trọng để giảm thiểu các con đường, phương thức tấn công. Đường màu đen được diễn tả tương tác 2 chiều, ví dụ một truy vấn (request)  [GET] từ người dùng và phản hồi (response) từ máy chủ.

Mô hình ở trên được áp dụng cho công ty cần độ bảo mật cao, tốc độ và an toàn dữ liệu. Thường được sử dụng cho các công ty tài chính cỡ vừa, với công ty thuộc lĩnh vực ngân hàng thì cần mô hình tốt hơn chút.

Tuy nhiên, các công ty dù hệ thống lớn ra sao vẫn sử dụng kỹ thuật lập trình web động, rất ít công ty nghĩ đến web tĩnh như một cách bảo mật và tối ưu tốc độ.

Mô hình rút gọn của mô hình trên chỉ còn 2 máy chủ: 1 Main System và 1 cho Static files server. Vẫn hoạt động với nguyên tắc đồng bộ 1 chiều từ Main System -> Static files server.

Nguyên tắc, cơ chế đồng bộ

• Chủ động: máy chủ Main Server xác định khi nào có nội dung mới (Xuất bản/Publish) để đồng bộ lên máy chủ Static files Server. Việc xác định này có thể dễ dàng làm được với việc ra lệnh từ Main System.
• Bị động: máy chủ Main Server sử dụng cronjob để đồng bộ lên Static files Server định kỳ theo khoảng n giây định sẵn. Thường là khoảng 10 phút, hoặc 30 phút…tất cả tuỳ theo mức độ tần suất cập nhật nội dung của nghiệp vụ.

Kết luận

Các công ty lớn thường đầu tư vào hệ thống phần cứng mà ít chú trọng đến giải pháp phần mềm, thường cho ra việc ngân sách phình lên một cách không cần thiết. Với việc áp dụng giải phép phần mềm với kỹ thuật lập trình web tĩnh được trình bày ở đây, chi phí có thể giảm đi một nửa mà tốc độ được cải thiện lên ít nhất là gấp đôi. Hơn nữa, với sức mạnh của các hệ thống Cloud mạnh như Google Cloud và Amazon thì việc phân tầng lớp mạng giữa các server trong cùng hoặc khác nhóm là rất dễ dàng.

Như vậy, lợi ích của kỹ thuật lập trình web tĩnh làm cho việc xây dựng hệ thống web trở nên an toàn hơn, tốc độ cao và tiết kiệm chi phí. Hi vọng qua bài này, sẽ có nhiều đơn vị quản lý website cũng như các bạn lập trình web có cái nhìn về kỹ thuật mang lại nhiều điều tốt như vậy.

The post Kỹ thuật lập trình web tĩnh để nâng cao bảo mật website appeared first on Fullstack Station.