DEV Community: Quoc-Hung Hoang

AWS Lambda Deployment Made Easy with GitHub Actions

Quoc-Hung Hoang — Sat, 09 Aug 2025 16:13:21 +0000

Great News for the Serverless Community! 🚀

On August 7th, AWS released the aws-actions/aws-lambda-deploy action for GitHub Actions, designed to streamline the deployment and configuration updates for Lambda functions on AWS.

How Did Lambda Deployment Work Before?

Previously, developers had to manually define AWS SDK commands (or use IaC tools like Terraform or SAM) to build, package code artifacts, and upload them as zip files or through S3 buckets for Lambda function deployment:

Build code from source
Package into ZIP files or container images
Upload to S3 buckets, ECR, or as zip files
Update Lambda function configuration

The New Solution: Just One Action!

Now you simply need to declare aws-actions/aws-lambda-deploy in your GitHub Actions workflow with parameters like: function-name, code-artifacts-dir (directory containing Lambda function source code), handler, and runtime.

Under the hood, this action leverages the AWS SDK for JavaScript and packages everything into a unified, user-friendly experience.

Check out the detailed release announcement here.

Real-World Implementation

Here's a GitHub Actions workflow from the Instagram Post Extractor project—a Lambda function that extracts metadata from Instagram posts.

name: Lambda CD Pipeline
permissions:
  id-token: write # Required for OIDC authentication

on:
  push:
    branches: [ development ]
  workflow_dispatch:

env:
  AWS_REGION: ap-southeast-1
  S3_BUCKET: ig-post-extractor-artifact
  LAMBDA_NAME: IgPostExtractor

jobs:
  deploy:
    name: Deploy
    runs-on: ubuntu-latest

    steps:
    - name: Checkout
      uses: actions/checkout@v4

    - name: Configure AWS credentials with OIDC
      # Use OpenID Connect (OIDC) to authenticate with AWS to avoid
      # storing AWS credentials as long-lived GitHub secrets
      uses: aws-actions/configure-aws-credentials@v4
      with:
        role-to-assume: ${{ secrets.AWS_ROLE_TO_ASSUME }}
        aws-region: ${{ env.AWS_REGION }}

    - name: Deploy Lambda Function
      id: deploy
      uses: aws-actions/aws-lambda-deploy@v1
      with:
        function-name: ${{ env.LAMBDA_NAME }}
        code-artifacts-dir: src/functions/
        s3-bucket: ${{ env.S3_BUCKET }}
        # Generate unique S3 key with timestamp and git commit hash
        s3-key: functions/"$(date +%Y%m%d%H%M%S)-${{ github.sha }}"
        handler: ig_post_extractor.lambda_handler
        runtime: python3.12

Triển khai AWS Lambda functions nay đã dễ dàng hơn với Github Actions

Quoc-Hung Hoang — Sat, 09 Aug 2025 16:09:08 +0000

Tin vui cho cộng đồng Serverless! 🚀

Ngày 07 tháng 8 vừa rồi, AWS vừa release action aws-actions/aws-lambda-deploy tích hợp trong Github Actions nhằm cập nhật cấu hình và mã nguồn của Lambda functions trên môi trường AWS.

Việc deploy Lambda trước kia như thế nào?

Developers cần định nghĩa thủ công các dòng lệnh AWS SDK (hoặc IaC như Terraform hay SAM) để thực hiện build, đóng gói code artifact rồi upload ở dạng zip hoặc thông qua S3 bucket để triển khai Lambda function:

1. **Build code** từ source
2. **Đóng gói** thành file ZIP hoặc container image
3. **Upload** lên S3 bucket hoặc ECR hoặc zip file
4. **Update** Lambda function configuration

Giải pháp mới: Chỉ cần 1 action duy nhất!

Giờ đây bạn chỉ cần khai báo aws-actions/aws-lambda-deploy trong Github Actions workflow kèm các tham số như: function-name, code-artifacts-dir (thư mục chứa mã nguồn Lambda function), handler, runtime

Về cách thức hoạt động, action này sẽ dựa vào AWS SDK for JavaScript và đóng gói thành khối thống nhất để thuận tiện cho người dùng.

Xem chi tiết thông báo release tại đây

Thực hành với dự án thực tế

Dưới đây là một Github Actions workflow lấy từ dự án Instagram Post Extractor, một Lambda function để extract metadata từ Instagram posts.

name: Lambda CD Pipeline
permissions:
  id-token: write # Cần thiết cho OIDC authentication


on:
  push:
    branches: [ development ]
  workflow_dispatch:


env:
  AWS_REGION: ap-southeast-1
  S3_BUCKET: ig-post-extractor-artifact
  LAMBDA_NAME: IgPostExtractor

jobs:
  deploy:
    name: Deploy
    runs-on: ubuntu-latest

    steps:
    - name: Checkout
      uses: actions/checkout@v4

    - name: Configure AWS credentials with OIDC
      # use OpenID Connect (OIDC) to authenticate with AWS to avoid
      # storing AWS credentials as long-lived GitHub secrets.
      uses: aws-actions/configure-aws-credentials@v4
      with:
        role-to-assume: ${{ secrets.AWS_ROLE_TO_ASSUME }}
        aws-region: ${{ env.AWS_REGION }}

    - name: Deploy Lambda Function
      id: deploy
      uses: aws-actions/aws-lambda-deploy@v1
      with:
        function-name: ${{ env.LAMBDA_NAME }}
        code-artifacts-dir: src/functions/
        s3-bucket: ${{ env.S3_BUCKET }}
        # Tạo unique S3 key với timestamp và git commit hash
        s3-key: functions/"$(date +%Y%m%d%H%M%S)-${{ github.sha }}"
        handler: ig_post_extractor.lambda_handler
        runtime: python3.12

Bổ sung ngữ cảnh cho LLM: Nâng cao độ chính xác và tin cậy cho ứng dụng GenAI

Quoc-Hung Hoang — Wed, 25 Jun 2025 15:13:22 +0000

Các Mô hình Ngôn ngữ Lớn (LLM) là những công cụ đa năng mạnh mẽ, nhưng giá trị thực sự của chúng trong môi trường kinh doanh chỉ được khai phá khi chúng có thể hoạt động với thông tin cụ thể và phù hợp. Mặc định, một LLM không có kiến thức về dữ liệu nội bộ, các sự kiện thời gian thực, hay hoàn cảnh riêng của người dùng. Để thu hẹp khoảng cách này, chúng ta phải cung cấp cho nó ngữ cảnh.

Có nhiều kỹ thuật để làm điều này, mỗi kỹ thuật đại diện cho một mức độ phức tạp, chi phí và năng lực khác nhau. Hiểu rõ các phương pháp này cho phép bạn lựa chọn chiến lược phù hợp với nhu cầu cụ thể của mình. Dưới đây là bốn kỹ thuật thiết yếu, được sắp xếp theo thứ tự từ đơn giản đến phức tạp nhất.

Các phương thức bổ sung ngữ cảnh cho LLMs

1: Kỹ thuật Prompt theo Ngữ cảnh (Contextual Prompt Engineering)

Đây là phương pháp trực tiếp và đơn giản nhất. Nó bao gồm việc chèn thông tin mà LLM cần trực tiếp vào câu lệnh (prompt), cùng với truy vấn của người dùng.
Cách thức hoạt động: Bạn xây dựng một câu lệnh bao gồm cả ngữ cảnh thực tế cần thiết và câu hỏi bạn muốn LLM trả lời. Mô hình sử dụng thông tin được cung cấp này để hình thành phản hồi cho duy nhất lượt tương tác đó.

❌

Write about climate change

✅

You are an environmental science educator writing for high school students.

Write a 300-word explanation of climate change that:
- Defines climate change in simple terms
- Explains 2-3 main causes
- Describes 2-3 observable effects
- Suggests 2 actionable steps students can take

Use clear, accessible language and include one concrete example or analogy to make the concept relatable. Structure your response with clear paragraphs and avoid technical jargon.

Format: Start with a hook sentence, then provide the explanation, and end with an encouraging call to action.

💡 Cách tiếp cận này là con đường nhanh nhất để bắt đầu. Nó không đòi hỏi hạ tầng đặc biệt và hoàn hảo cho việc tạo mẫu thử nghiệm và các ứng dụng đơn giản nơi ngữ cảnh nhỏ và thay đổi theo từng truy vấn. Nó xem LLM như một bộ máy suy luận thuần túy, cung cấp tất cả các dữ kiện cần thiết một cách tạm thời.

✅ Ưu điểm: Rào cản gia nhập cực kỳ thấp; không yêu cầu huấn luyện hay quản lý dữ liệu.
⚠️ Nhược điểm: Bị giới hạn nghiêm trọng bởi cửa sổ ngữ cảnh (lượng văn bản tối đa mà mô hình có thể xử lý cùng lúc). Nó không hiệu quả khi triển khai ở quy mô lớn, vì bạn liên tục gửi và trả phí cho cùng một ngữ cảnh. Kiến thức này chỉ là tạm thời và sẽ bị "lãng quên" ngay sau khi phản hồi được tạo ra.

2: Sinh Nội dung Tăng cường bằng Truy xuất (RAG)

RAG là phương pháp tiếp cận phổ biến và thực tế nhất để xây dựng các ứng dụng mạnh mẽ, giàu kiến thức hiện nay. Nó tự động hóa quá trình tìm kiếm và cung cấp ngữ cảnh phù hợp cho LLM.

Cách thức hoạt động: Đây là một quy trình hai bước:

Truy xuất (Retrieve): Khi người dùng đặt câu hỏi, hệ thống trước tiên sẽ tìm kiếm trong một kho kiến thức riêng (ví dụ: tài liệu công ty, bài viết hỗ trợ, cơ sở dữ liệu) để tìm thông tin phù hợp nhất. Điều này thường được thực hiện bằng cơ sở dữ liệu vector, nơi tìm kiếm tài liệu dựa trên sự tương đồng về ngữ nghĩa.
Tăng cường & Sinh nội dung (Augment & Generate): Thông tin được truy xuất sau đó được tự động chèn vào câu lệnh cùng với câu hỏi ban đầu của người dùng. LLM sử dụng ngữ cảnh đã được chọn lọc này để tạo ra một câu trả lời có căn cứ và xác thực.

🔩 RAG khắc phục những hạn chế chính của việc tạo prompt thủ công. Nó cho phép LLM truy cập vào kho kiến thức có tính chất thay đổi thuờng xuyên. RAG nhằm lọc và đưa những phần thông tin phù hợp nhất vào cửa sổ ngữ cảnh có giới hạn của LLMs, mang lại sự cân bằng tuyệt vời giữa chi phí và lợi ích bởi cho phép truy cập dữ liệu độc quyền mà không tốn kém chi phí khổng lồ để huấn luyện lại mô hình. Nó cũng giảm đáng kể nguy cơ "ảo giác" (hallucination) bằng cách neo mô hình vào các tài liệu nguồn cụ thể.

✅ Ưu điểm: Khả năng mở rộng cao, cho phép truy cập thông tin thời gian thực và tương đối tiết kiệm chi phí.
⚠️ Nhược điểm: Mang lại sự phức tạp về mặt kỹ thuật, đòi hỏi quản lý một chuỗi xử lý dữ liệu, quy trình nhúng (embedding) và một cơ sở dữ liệu vector. Chất lượng của câu trả lời cuối cùng phụ thuộc rất nhiều vào chất lượng của bước truy xuất.

3: Tinh chỉnh Mô hình (Fine-Tuning)

Tinh chỉnh là việc lấy một mô hình nền tảng đã được huấn luyện trước và tiếp tục quá trình huấn luyện nó trên một tập dữ liệu nhỏ hơn, đã được tuyển chọn của riêng bạn.

💡 Cách thức hoạt động: Bạn chuẩn bị một tập dữ liệu chất lượng cao gồm các cặp câu lệnh-phản hồi mẫu để thể hiện một hành vi cụ thể mà bạn muốn mô hình học theo. Ví dụ, học cách trả lời theo giọng văn thương hiệu của công ty, áp dụng một tính cách cụ thể, hoặc luôn xuất ra một định dạng có cấu trúc như JSON.

🔔 Tinh chỉnh không phải là để dạy cho mô hình những dữ kiện mới; nó là để dạy cho mô hình một kỹ năng, phong cách, hoặc cấu trúc mới. Trong khi RAG cung cấp kiến thức, tinh chỉnh định hình hành vi của mô hình. Đây là lựa chọn đúng đắn khi bạn cần mô hình tuân thủ một phong cách nhất quán hoặc xuất sắc trong một nhiệm vụ chuyên biệt khác với việc huấn luyện chung của nó.

✅ Ưu điểm: Có thể mang lại hiệu suất vượt trội cho các nhiệm vụ chuyên biệt và cải thiện độ tin cậy về văn phong và định dạng.
⚠️ Nhược điểm: Đây là một cách không hiệu quả để thêm kiến thức thực tế, vì dữ liệu có thể trở nên lỗi thời. Nó đòi hỏi sự chuẩn bị dữ liệu cẩn thận và có chi phí tính toán cao hơn RAG.

🧷 Phân biệt quan trọng: Kiến thức vs. Hành vi (RAG vs. Fine-Tuning)
Sử dụng RAG để cung cấp cho mô hình quyền truy cập vào kiến thức.
Sử dụng Fine-Tuning để dạy cho mô hình cách hành xử.

Các hệ thống mạnh mẽ nhất thường kết hợp cả hai: một mô hình được tinh chỉnh để có hành vi chuyên gia, sử dụng RAG để lấy ngữ cảnh thực tế năng động.

4: Huấn luyện Mô hình từ đầu

Đây là phương pháp mạnh mẽ và đòi hỏi khắt khe nhất, chỉ dành cho các trường hợp sử dụng cực kỳ chuyên biệt.

Cách thức hoạt động: Bao gồm việc thu thập một tập dữ liệu khổng lồ, chuyên sâu về một lĩnh vực (hàng terabyte văn bản) và huấn luyện một mô hình nền tảng mới từ con số không.
Lý do và Lập luận: Lựa chọn này chỉ được theo đuổi khi các mô hình hiện có về cơ bản không phù hợp với lĩnh vực của bạn, chẳng hạn như trong các ngành khoa học chuyên sâu (ví dụ: di truyền học) hoặc để tạo ra một mô hình có kiến trúc hoàn toàn mới. Mục tiêu là xây dựng một "bộ não" đã học được các nguyên tắc cốt lõi của một lĩnh vực từ những nguyên lý đầu tiên.

✅ Ưu điểm: Cung cấp quyền kiểm soát tối đa, hiệu suất đỉnh cao cho lĩnh vực mục tiêu và tạo ra lợi thế cạnh tranh đáng kể.
⚠️ Nhược điểm: Chi phí cực kỳ đắt đỏ, đòi hỏi hàng triệu đô la chi phí tính toán và một đội ngũ các nhà khoa học nghiên cứu hàng đầu. Đây là một nỗ lực kéo dài nhiều năm chỉ dành cho một số ít các tổ chức lớn.

Kết luận: Lựa chọn Chiến lược Phù hợp

Xây dựng AI có nhận thức về ngữ cảnh là một bài toán về việc đưa ra các quyết định đánh đổi mang tính chiến lược. Con đường tối ưu thường bao gồm:

Bắt đầu với Kỹ thuật Prompt để nhanh chóng xác thực một ý tưởng.
Triển khai RAG như một giải pháp mặc định cho hầu hết các ứng dụng cần truy cập thông tin độc quyền hoặc năng động.

Bổ sung thêm Fine-Tuning nếu bạn cần cải thiện hiệu suất hành vi, phong cách hoặc định dạng của mô hình.
Cân nhắc huấn luyện từ đầu chỉ khi bạn có đủ nguồn lực và nhu cầu chiến lược mà không một mô hình hiện có nào có thể đáp ứng.

Bằng cách hiểu rõ các kỹ thuật này, bạn có thể lựa chọn phương pháp phù hợp nhất cho dự án, ngân sách và mục tiêu của mình, từ đó biến đổi một LLM tổng quát thành một công cụ chuyên biệt có giá trị cao.

TERRAFORM - ANSIBLE: SỰ PHÂN ĐỊNH TRONG MÔ HÌNH CẤU HÌNH DEVOPS

Quoc-Hung Hoang — Wed, 07 May 2025 07:41:46 +0000

1. Tổng quan 🛠️

Terraform

Terraform là một công cụ Infrastructure as Code (IaC) mã nguồn mở được phát triển bởi HashiCorp, tập trung vào việc cung cấp và quản lý cơ sở hạ tầng cloud và on-premises. Terraform sử dụng phương pháp declarative thuần túy. 🌟

Ansible

Ansible là một công cụ tự động hóa, mã nguồn mở được phát triển bởi Red Hat, tập trung vào triển khai các tác vụ song song trên nhiều máy chủ cùng một lúc. Ansible sử dụng phương pháp procedural declarative. 🤖

2. Mô hình Declarative vs Imperative 🔄

Declarative Configuration (Cấu hình khai báo) ✍️

Mô tả trạng thái mong muốn của hệ thống
Công cụ tự quyết định cách đạt được trạng thái đó
Tập trung vào "CÁI GÌ" (what), không phải "LÀM THẾ NÀO" (how)
Duy trì trạng thái (state) để biết những gì đã tồn tại

Imperative Configuration (Cấu hình mệnh lệnh) 🧩

Xác định chuỗi các lệnh cụ thể để thực hiện
Người dùng đặc tả chính xác cách thực hiện từng bước
Tập trung vào "LÀM THẾ NÀO" (how) để đạt được kết quả
Thường không theo dõi trạng thái hiện tại của hệ thống

3. Phân tích sâu về Terraform: Declarative thuần túy 🌱

Ưu điểm của cách tiếp cận Declarative

Idempotency: Có thể chạy nhiều lần mà không gây ra tác dụng phụ 🔄
Consistency: Đảm bảo trạng thái cuối cùng luôn nhất quán ✅
Dễ đọc: Code mô tả chính xác cái gì sẽ được tạo ra 📖
Quản lý thay đổi: Dễ dàng thêm, sửa, xóa tài nguyên qua mã dựa trên đồ thị phụ thuộc giữa các tài nguyên ✏️

4. Phân tích sâu về Ansible: "Procedural Declarative" ⚙️

Ở góc nhìn "frontend", Ansible khéo léo khoác lên mình chiếc áo choàng declarative nhưng thực chất vẫn tuân thủ triết lý imperative, tức là nó cho phép người dùng định nghĩa trạng thái mong muốn (what) nhưng đồng thời cũng yêu cầu chỉ rõ cách thức đạt được trạng thái đó (how). Điều này tạo nên một mô hình lai độc đáo được gọi là "procedural declarative".

Tính chất "Procedural Declarative"

Declarative: Mô tả trạng thái mong muốn trong modules (state: present, absent, etc.)
Task-based: Thực thi các task theo thứ tự từ trên xuống 📋
Procedural: Các task được thực thi tuần tự, không tự động giải quyết phụ thuộc
Agentless: Không yêu cầu agent trên máy đích, sử dụng SSH/WinRM 🔒
Limited State Management: Không duy trì trạng thái tổng thể của hệ thống
Idempotency: Cố gắng đạt được idempotency nhưng đòi hỏi lập trình viên phải đảm bảo

5. So sánh qua ví dụ cụ thể 🔍

Ví dụ 1: Triển khai máy chủ web 🌐

Cách tiếp cận Declarative (Terraform)

Với Terraform, bạn khai báo: "Tôi muốn có 3 máy chủ web, mỗi máy có 2GB RAM, sử dụng hệ điều hành Ubuntu 22.04, và tất cả đều nằm trong nhóm bảo mật web_servers."

Terraform sẽ:

Tự động xác định có cần tạo mới, cập nhật hay xóa máy chủ nào không
Tự quản lý trình tự tạo tài nguyên (ví dụ: tạo network trước, sau đó mới tạo máy chủ)
Đảm bảo trạng thái cuối cùng luôn khớp với mô tả, bất kể trạng thái ban đầu

Cách tiếp cận Procedural Declarative (Ansible)

Với Ansible, bạn sẽ viết:

"Tạo 3 máy chủ web với 2GB RAM và Ubuntu 22.04"
"Cấu hình mỗi máy chủ để chạy dịch vụ web"
"Thêm các máy chủ vào nhóm bảo mật web_servers"

Ansible sẽ:

Thực hiện tuần tự từng bước theo thứ tự đã định
Sử dụng các module để đạt được trạng thái mong muốn cho từng bước
Không tự động theo dõi trạng thái tổng thể của hệ thống

Ví dụ 2: Triển khai ứng dụng 📦

Cách tiếp cận Declarative (Terraform)

Với Terraform: "Ứng dụng của tôi cần 1 cơ sở dữ liệu, 2 máy chủ ứng dụng, và 1 cân bằng tải ở phía trước. Cơ sở dữ liệu cần kết nối với các máy chủ ứng dụng, và cân bằng tải cần phân phối lưu lượng đến các máy chủ ứng dụng."

Terraform sẽ:

Tạo một đồ thị phụ thuộc giữa các tài nguyên
Xác định thứ tự tạo tài nguyên (cơ sở dữ liệu → máy chủ ứng dụng → cân bằng tải)
Đảm bảo tất cả các kết nối và quan hệ phụ thuộc được đáp ứng

Cách tiếp cận Procedural Declarative (Ansible)

Với Ansible:

"Tạo cơ sở dữ liệu với cấu hình X"
"Tạo 2 máy chủ ứng dụng với cấu hình Y"
"Cấu hình kết nối giữa cơ sở dữ liệu và máy chủ ứng dụng"
"Tạo cân bằng tải với cấu hình Z"
"Cấu hình cân bằng tải để phân phối lưu lượng đến các máy chủ ứng dụng"

Ansible sẽ:

Thực hiện từng bước theo thứ tự đã định
Nhà phát triển phải xác định rõ thứ tự thực hiện
Sử dụng các biến và đăng ký kết quả để truyền thông tin giữa các bước

6. Triết lý Immutable vs Mutable Infrastructure 🏗️

Immutable Infrastructure: "Không sửa, chỉ thay" 🔄

Immutable Infrastructure là phương pháp trong đó các thành phần cơ sở hạ tầng không bao giờ được sửa đổi sau khi triển khai. Thay vì cập nhật cấu hình trên máy chủ đang chạy, toàn bộ máy chủ được thay thế bằng phiên bản mới đã được cấu hình sẵn.

Đặc điểm chính:

Máy chủ được xem như "gia súc" (cattle), không phải "thú cưng" (pet) 🐄
Cập nhật = Hủy cũ + Tạo mới
Dựa vào các template, image, snapshot 📸
Loại bỏ "configuration drift" và "snowflake servers" ❄️

Mutable Infrastructure: "Sửa chữa tại chỗ" 🔧

Mutable Infrastructure là phương pháp truyền thống, trong đó các thành phần cơ sở hạ tầng được cập nhật và sửa đổi tại chỗ khi cần thiết.

Đặc điểm chính:

Máy chủ được xem như "thú cưng" cần chăm sóc 🐕
Thực hiện các thay đổi trực tiếp trên hệ thống đang chạy
Dễ dẫn đến "configuration drift"
Lịch sử thay đổi có thể không được ghi lại đầy đủ

Terraform: Người ủng hộ trung thành của Immutable Infrastructure 🌟

Terraform, với triết lý declarative thuần túy, là công cụ lý tưởng cho Immutable Infrastructure:

Quản lý toàn diện: Tạo và quản lý toàn bộ vòng đời của tài nguyên
Tất cả hoặc không có gì: Thay đổi tài nguyên thường đồng nghĩa với việc tạo mới và hủy cái cũ
Nhất quán: Đảm bảo môi trường luôn ở trạng thái đã định nghĩa
Dễ dàng roll back: Quay lại version cũ chỉ đơn giản là apply lại cấu hình cũ

Terraform giống như một kiến trúc sư khó tính: "Nếu cần thay đổi, tôi sẽ xây lại từ đầu!" 🏗️

Ansible: "Kẻ đa năng" trong thế giới infrastructure 🔧

Ansible, với bản chất procedural declarative, thích nghi tốt với Mutable Infrastructure nhưng cũng có thể hỗ trợ Immutable:

Trong thế giới Mutable:

Chuyên gia "chỉnh sửa": Thay đổi cấu hình trên các máy chủ đang chạy
Linh hoạt: Thực hiện các thay đổi nhỏ mà không cần rebuild toàn bộ
Nhanh chóng: Không cần chu kỳ tạo-hủy cho mỗi thay đổi nhỏ

Hỗ trợ Immutable khi cần:

Xây dựng các image (AMI, Docker)
Cấu hình ban đầu cho các instance mới
Phần của pipeline CI/CD cho immutable deployments

Ansible giống như một thợ sửa chữa đa năng: có thể xây mới, nhưng cũng rất giỏi trong việc sửa chữa tại chỗ! 🛠️

7. Trường hợp sử dụng phù hợp 🎯

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

Provisioning hạ tầng: Tạo mới toàn bộ cơ sở hạ tầng 🏗️
Quản lý tài nguyên cloud: AWS, Azure, GCP, etc. ☁️
Kiến trúc bất biến (Immutable Infrastructure): Tạo mới thay vì cập nhật 🔄
Quản lý trạng thái phức tạp: Nhiều tài nguyên phụ thuộc lẫn nhau 🔗

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

Cấu hình máy chủ: Cài đặt phần mềm, cập nhật cấu hình 🖥️
Triển khai ứng dụng: Deployment pipelines 🚀
Tự động hóa tác vụ lặp đi lặp lại: Patches, updates 🔄
Điều phối nhiều máy chủ: Các tác vụ cần thực hiện đồng thời trên nhiều máy ⚡

Kết hợp cả hai công cụ 🤝

Mô hình phổ biến:

Sử dụng Terraform để provision infrastructure
Sử dụng Ansible để cấu hình và triển khai ứng dụng

8. Kết luận 🏁

Terraform và Ansible đại diện cho hai triết lý khác nhau trong quản lý hạ tầng và tự động hóa:

Terraform: Declarative thuần túy, tập trung vào việc quản lý trạng thái và mối quan hệ phụ thuộc giữa các tài nguyên.
Ansible: Procedural declarative, kết hợp giữa mô tả trạng thái mong muốn và thực thi tuần tự.

Cả hai công cụ đều có giá trị riêng và thường được sử dụng bổ sung cho nhau trong các pipeline DevOps hiện đại. Hiểu rõ sự khác biệt giữa cách tiếp cận declarative và imperative giúp đội ngũ DevOps lựa chọn công cụ phù hợp cho từng loại tác vụ. 🚀

Tái Cấu Trúc Terraform: Chuyển Đổi Từ State Monolithic Sang Kiến Trúc Mô-đun Theo Môi Trường

Quoc-Hung Hoang — Sun, 20 Apr 2025 09:47:08 +0000

Trong quá trình phát triển công cụ tự đông hoá truy vấn Google Maps theo địa chỉ dưới dạng văn bản trên nền tảng Instagram (chi tiết tại đây), nhận thấy sự cần thiết trong việc chuyển đổi cấu trúc quản lí trạng thái của Terraform từ dạng phẳng, phi cấu trúc, monolith sang dạng mô-đun, phân tách môi trường theo file directory

Dưới đây là hướng dẫn sơ khai các bước để tổ chức lại codebase Terraform của bạn để có sự tách biệt, tái sử dụng và triển khai an toàn hơn.

Nội dung chính

Tổ chức State Ban Đầu
Giới Thiệu Về Terraform Module
Cấu Trúc Mới: Mô-đun Hóa, Hướng Theo Môi Trường
Thực hiện Migrate & Quản Lý State
Xác Minh Quá Trình Chuyển Đổi
Kết quả và lời kết

Tổ Chức State Ban Đầu

terraform-serverless-project/
├── main.tf                 # All infrastructure defined here
├── variables.tf            # All variables defined here
├── outputs.tf              # All outputs defined here
├── providers.tf            # AWS provider configuration
├── terraform.tfstate       # Single state file managing everything
├── terraform.tfstate.backup
├── .terraform.lock.hcl
├── src                     # Application code goes here

Cấu Trúc & Quy Trình

Một thư mục gốc terraform/ với main.tf, variables.tf, v.v.
Một file state duy nhất (terraform.tfstate), thường được lưu trữ trong S3 hoặc cục bộ.
Sử dụng .tfvars (dev.tfvars, prod.tfvars) ghi đè biến để phân tách môi trường.

Lợi ích

Cấu trúc đơn giản, trực quan đối với người mới và dự án nhỏ.

Hạn Chế & Nhược Điểm
Sẽ bộc lộ khi số lượng tài nguyên tăng lên:

State phình to: tất cả tài nguyên (dev/staging/prod) đều nằm trong một file.
Triển khai rủi ro: vô tình thay đổi tài nguyên production.
Mô-đun hóa kém: mọi thay đổi đối với API, IAM, Lambda đều nằm trong cùng một file.
Không có ranh giới rõ ràng: khó để đào tạo thành viên mới hoặc phân chia trách nhiệm.

Giới Thiệu Về Terraform Module

Module Là Gì?
Một thư mục chứa mã Terraform (resources, inputs, outputs) mà bạn có thể gọi từ một cấu hình khác.

Root module: main.tf cấp cao nhất và các file liên quan.
Child modules: các khối xây dựng có thể tái sử dụng (ví dụ: modules/lambda/).

Kiến Trúc và Giao Tiếp Của Module

Một module Terraform không chỉ là một thư mục mã—nó là một đối tượng đóng gói độc lập với một hợp đồng (ràng buộc) rõ ràng về cách tương tác với thế giới bên ngoài thông qua biến (var):

modules/lambda/
├── main.tf         # Định nghĩa tài nguyên chính
├── variables.tf    # Tham số đầu vào (API của module)
├── outputs.tf      # Giá trị được hiển thị cho module cha
├── locals.tf       # Tính toán và biến đổi nội bộ
├── data.tf         # Data sources và lookups
└── README.md       # Tài liệu về mục đích, inputs, và outputs

Mỗi file có một mục đích cụ thể:

main.tf - Chứa và tập hợp các định nghĩa tài nguyên cốt lõi (thường đi kèm với nhau) để thực hiện một hành động/tính năng hoàn chỉnh mà module tạo và quản lý. Đối với module Lambda, nó sẽ bao gồm:

resource "aws_lambda_function" "functions" {
  for_each = var.functions

  function_name = "${var.name_prefix}-${each.key}"
  handler       = each.value.handler
  runtime       = each.value.runtime
  role          = var.execution_role_arn

  filename         = each.value.source_file
  source_code_hash = filebase64sha256(each.value.source_file)

  memory_size = each.value.memory_size
  timeout     = each.value.timeout

  environment {
    variables = merge(var.common_environment_variables, each.value.environment_variables)
  }

  tags = merge(var.common_tags, each.value.tags)
}

# Các tài nguyên bổ sung như permissions, CloudWatch log groups, v.v.

variables.tf - Định nghĩa các tham số đầu vào của module, với mô tả và ràng buộc kiểu:

variable "name_prefix" {
  description = "Tiền tố được thêm vào trước tất cả tên tài nguyên"
  type        = string
}

variable "functions" {
  description = "Bản đồ các hàm Lambda cần tạo"
  type = map(object({
    handler               = string
    runtime               = string
    source_file           = string
    memory_size           = number
    timeout               = number
    environment_variables = map(string)
    tags                  = map(string)
  }))
}

variable "execution_role_arn" {
  description = "ARN của IAM role được sử dụng bởi các hàm Lambda"
  type        = string
}

variable "common_environment_variables" {
  description = "Biến môi trường áp dụng cho tất cả các hàm"
  type        = map(string)
  default     = {}
}

variable "common_tags" {
  description = "Tags áp dụng cho tất cả tài nguyên"
  type        = map(string)
  default     = {}
}

outputs.tf - Định nghĩa các giá trị mà module hiển thị cho các module cha:

output "function_arns" {
  description = "ARNs của các hàm Lambda đã tạo"
  value = {
    for name, function in aws_lambda_function.functions : name => function.arn
  }
}

output "function_names" {
  description = "Tên của các hàm Lambda đã tạo"
  value = {
    for name, function in aws_lambda_function.functions : name => function.function_name
  }
}

output "invoke_urls" {
  description = "URLs cơ sở để gọi các hàm Lambda (nếu tích hợp API Gateway được bật)"
  value = {
    for name, _ in var.functions :
    name => aws_apigatewayv2_stage.api[name].invoke_url
    if contains(keys(aws_apigatewayv2_stage.api), name)
  }
}

Sự Kết Hợp và Tái Sử Dụng Module

Các module có thể gọi các module khác, tạo thành một mẫu kết hợp. Điều này cho phép bạn xây dựng các trừu tượng cấp cao hơn:

# Bên trong một module "serverless_api" kết hợp các module khác
module "lambda" {
  source = "../lambda"

  name_prefix        = var.name_prefix
  functions          = var.functions
  execution_role_arn = module.iam.lambda_execution_role_arn
}

module "api_gateway" {
  source = "../api_gateway"

  name_prefix     = var.name_prefix
  api_name        = "${var.name_prefix}-api"
  lambda_function = module.lambda.function_arns["api_handler"]
  stage_name      = var.environment
}

module "iam" {
  source = "../iam"

  name_prefix = var.name_prefix
  services    = ["lambda.amazonaws.com"]
}

Phiên Bản Module

Để đảm bảo tính ổn định, bạn nên đánh phiên bản cho các module của mình bằng một trong những cách tiếp cận sau:

1️⃣ Tham chiếu Git - Gắn với một commit hoặc tag cụ thể:

   module "lambda" {
     source = "git::https://github.com/company/terraform-modules.git//modules/lambda?ref=v1.2.3"
     # Cấu hình module...
   }

2️⃣ Terraform Registry - Cho các module trong registry công khai hoặc riêng tư:

   module "lambda" {
     source  = "terraform-aws-modules/lambda/aws"
     version = "2.7.0"
     # Cấu hình module...
   }

3️⃣ Đường dẫn cục bộ với phiên bản - Cho phát triển nội bộ:

   module "lambda" {
     source = "../../modules/lambda"  # Với quy trình kiểm soát phiên bản nội bộ
     # Cấu hình module...
   }

Lợi Ích

Đóng gói: nhóm các tài nguyên liên quan (Lambda + aliases + permissions).
Tái sử dụng: chia sẻ các mẫu tiêu chuẩn giữa các dự án.
Tùy biến: hiển thị inputs (var.memory_size, var.aliases) và outputs.
Đánh phiên bản: gắn nguồn module với một Git tag hoặc phiên bản registry.

Cách Sử Dụng

module "lambda" {
  source             = "../../modules/lambda"
  functions          = local.lambda_functions
  execution_role_arn = module.iam.execution_role_arn
}

Định nghĩa inputs (maps, lists, primitives).
Sử dụng outputs (module.lambda.alias_arns["myfunc_dev"]).
Tận dụng for_each / count cho tính năng động.

Cấu Trúc Mới: Mô-đun Hóa, Hướng Theo Môi Trường

terraform/
├── environments/
│   ├── dev/
│   │   └── main.tf
│   ├── staging/
│   │   └── main.tf
│   └── prod/
│       └── main.tf
└── modules/
    ├── lambda/
    ├── iam/
    ├── api_gateway/
    └── cloudwatch/

Thư mục theo môi trường: cô lập state, vars, backends.
Modules: triển khai các vấn đề cốt lõi (compute, IAM, logging, API).
Locals & tagging: định nghĩa local.project, local.environment, local.common_tags trong mỗi môi trường.

Thực hiện Migrate & Quản Lý State

Ở phần phần này, mính sẽ giới thiệu qua các lệnh phổ biển của Terraform CLI để dịch chuyển state và các tài nguyên liên quan.

Có it nhất 2 cách để thực hiện:

terraform state rm và terraform import để import tài nguyên vào module mới.
Sử dụng terraform state mv để di chuyển tài nguyên vào module mới.

📌 Đi kèm là 2 công cụ đắc lực để theo dõi hiện trạng state: terraform state list và terraform state show.

Sử dụng `terraform state rm` và `terraform import` để import tài nguyên vào module mới

Flow cơ bản:

1️⃣ Khởi tạo state cho từng môi trường, ở đây là dev

cd terraform/environments/dev
terraform init \
  -backend-config="key=dev/terraform.tfstate"

2️⃣ Định nghĩa module ở môi trường mới

# my_project/terraform/modules/lambda/main.tf
resource "aws_lambda_function" "my_lambda_function" {
  function_name = var.function_name

  # Function-specific configuration
  handler          = var.handler
  runtime          = var.runtime
}

3️⃣ Định nghĩa các biến đầu vào cho module trên

# my_project/terraform/modules/lambda/variables.tf
variable "function_name" {
  type = string
}

variable "handler" {
  type = string
}

variable "runtime" {
  type = string
}

4️⃣ Gọi module lambda trong file main.tf của môi trường mới

Để đơn giản, chúng ta hardcode các tham số đầu vào, tuy nhiên thực tế chúng ta nên định nghĩa các biến đầu vào trong variables.tf kết hợp terraform.tfvars của module.

# my_project/terraform/environments/dev/main.tf
module "lambda" {
  source = "../../modules/lambda"

  function_name = "my_lambda_function"
  handler       = "index.handler"
  runtime       = "python3.8"
}

5️⃣ Xác định tài nguyên cần di chuyển ở môi trường cũ
Tại môi trường cũ, hãy xem các tài nguyên hiện có rồi xoá tài nguyên khỏi file trạng thái:

# my_project/
> terraform state list
> terraform state show aws_lambda_function.my_lambda_function
> terraform state rm aws_lambda_function.my_lambda_function

Rồi xoá thủ công tài nguyên trên khỏi code ở môi trường cũ.

6️⃣ Import tài nguyên vào module mới

# my_project/terraform/environments/dev
> terraform import module.lambda.aws_lambda_function.my_lambda_function <resource_id>

Bạn có thể phải cần truyền các tham số đầu vào thông qua flag --var hoặc --var-file.
Ví dụ:

> terraform import module.lambda.aws_lambda_function.my_lambda_function <resource_id> --var "function_name = 'my_lambda_function'" --var "handler = 'index.handler'" --var "runtime = 'python3.8'"

Xác Minh Quá Trình Chuyển Đổi

Xác Thực Bằng Plan

   terraform plan

Xác nhận không có thay đổi (các tài nguyên trỏ đến cùng một cơ sở hạ tầng vật lý).
- Liệt kê state

  terraform state list

Hiển thị chi tiết tài nguyên

  terraform state show module.lambda.aws_lambda_function.functions["ig_post_extractor"]

Kết quả plan
- Không có thay đổi đồng nghĩa với thành công.
- Bất kỳ sự khác biệt nào cho thấy một sự ánh xạ sai cần phải sửa bằng state mv hoặc cập nhật biến.
Triển Khai Qua Các Môi Trường
- Lặp lại init/import/plan trong staging và prod.
- Mỗi môi trường sử dụng khóa backend state riêng (staging/terraform.tfstate, v.v.).

Cấu Trúc Cuối Cùng Thành Công

Sau khi di chuyển, cấu trúc của chúng ta trông như thế này:

terraform/
├── environments/
│   ├── dev/
│   │   ├── main.tf
│   │   └── terraform.tfstate (trong S3)
│   ├── staging/
│   │   ├── main.tf
│   │   └── terraform.tfstate (trong S3)
│   └── prod/
│       ├── main.tf
│       └── terraform.tfstate (trong S3)
└── modules/
    ├── lambda/
    ├── api_gateway/
    ├── iam/
    └── cloudwatch/
├── src                 # Application code goes here

Kết Quả và lời kết

Tách biệt: mỗi môi trường có state riêng, không có sự nhiễm chéo.
Mô-đun hóa: các module đóng gói các phương pháp hay nhất và dễ dàng đánh phiên bản.
Lặp lại: tạo môi trường mới bằng cách sao chép một thư mục và điều chỉnh các biến.
An toàn: các lệnh plan + state đảm bảo di chuyển có kiểm soát, không bị gián đoạn.
Dễ bảo trì: thành viên mới trong nhóm có thể nhanh chóng hiểu cấu trúc codebase.
Quản trị: dễ dàng triển khai quy trình phê duyệt cho từng môi trường.

Sau khi di chuyển, các nhóm có thể làm việc độc lập trên các môi trường hoặc module khác nhau, với ranh giới rõ ràng và giảm nguy cơ thay đổi vô tình các tài nguyên sản xuất.

Zero-Code Authentication: Unleashing AWS Application Load Balancer's Built-in capabilities for simplifying user login

Quoc-Hung Hoang — Mon, 07 Apr 2025 04:58:25 +0000

In this guide, I'll walk you through setting up ALB authentication at a high level, demonstrating how you can leverage this serverless approach to handle user login flows. This solution can significantly streamline your authentication implementation.

Unlock the Hidden Power of Application Load Balancer Authentication

While many developers overlook a game-changing security feature, AWS Application Load Balancers (ALBs) harbor a secret weapon: native OpenID Connect (OIDC) authentication. This lesser-known capability transforms authentication from a complex, resource-draining challenge into a streamlined, efficient solution that operates directly at the infrastructure level.

By enabling OIDC authentication at the load balancer, you can offload critical authentication work from your application servers, reducing complexity, minimizing potential security vulnerabilities, and delivering a more robust authentication strategy with minimal additional configuration.

Benefits

✅ Application Load Balancer acts as an OIDC Relying Party (RP) that provides authentication backend with seamless integration with AWS Cognito, public IdP (such as Facebook, Google) and corporate identities using SAML, LDAP, Microsoft AD, or OIDC
✅ Offloading the responsibility of authentication to the Application Load Balancer, while benefiting from its scale, availability, and reliability.
✅ Cost-Effectiveness: Managed authentication reduces the need for custom solutions, saving time and resources on development and maintenance.

How it works

📌 OIDC client is implemented in ALB via configured listener rules that simplifies authorization in the backends
📌 Cognito User Pool Domain serves as the OIDC Provider (OP), hosting the authorization server endpoints

Limitations

⚠️ Cookie Size Restrictions:
The session cookies used by ALB have size limitations (maximum 4KB). if token payloads exceed this limit (e.g., larger than 11KB), the load balancer may return errors like HTTP 500.
⚠️ Dependency on Publicly Resolvable DNS:
For OIDC-compliant IdPs, the OIDC Provider's endpoints must be publicly resolvable even if they resolve to private IPs, which may not be feasible in certain private network setups.
⚠️ No Custom Login Pages:
Applications relying on ALB for authentication must use the login page hosted by the IdP (e.g., Amazon Cognito). Customization of the login UI may be limited.
⚠️ Complex Configuration for Multiple Applications:
When supporting multiple applications via a single ALB, developers must configure unique session cookies and listener rules to avoid conflicts between client authentications

Design Overview

Configuration Components

1. DNS and SSL Configuration

Create CNAME record in your domain registrar:
- Record: app.[your-domain].com
- Target: [your-load-balancer-dns-name].region.elb.amazonaws.com
Request SSL certificate in AWS Certificate Manager (ACM):
- Domain name: app.[your-domain].com
- Validation: DNS validation recommended

2. Amazon Cognito Configuration

User Pool Setup

User Pool Name: [Your Application Name]-user-pool
Domain: [your-domain].auth.[region].amazoncognito.com
App client:
- Name: of your choice
- Generate client secret: Yes
- Allowed OAuth Flows: Authorization code grant
- Allowed OAuth Scopes: openid, email, profile
- Callback URLs: https://[your-load-balancer-domain]/oauth2/idpresponse and https://[your-domain]/oauth2/idpresponse (this is an ALB-specific endpoint required for the OIDC authentication flow)

3. Application Load Balancer Configuration

Our Application Load Balancer is configured with two listeners:

HTTP Listener (Port 80)

Rule Configuration: Redirects all HTTP traffic to HTTPS (port 443)
Status Code: HTTP 301 (Permanent Redirect)
Security Purpose: Ensures all authentication traffic is encrypted

HTTPS Listener (Port 443)

Configuration: Serve HTTPS traffic as path routing, handles authentication through AWS Cognito before routing to downstream applications depending on different listener rules
This listener has two distinct rules that handle different access patterns:

Public Resource Rule (Priority: 1)
- Path Pattern: Exact match for root path "/"
- Actions: Direct forward to target group without authentication
- Purpose: Allows public access to the homepage without requiring authentication
Protected Resources Rule (Default Rule)
- Path Pattern: All other paths not explicitly matched by other rules
- Actions: Configured in the following order:
  1. authenticate-cognito (Order: 1): Authenticates users via Cognito before allowing access. We need to specify Cognito User Pool, User Pool Domain, App Client and include TLS/SSL Certificate here.
  2. forward (Order: 2): Forwards authenticated requests to the target group
- Purpose: Protects all application resources by requiring authentication

Django 5.2's Smart Shell: Goodbye Manual Model Imports!

Quoc-Hung Hoang — Tue, 11 Mar 2025 06:58:12 +0000

One of the most convenient features from django-extensions has finally made its way into Django's core. Starting with Django 5.2, the shell comes with automatic model imports, streamlining your development workflow.

The Old Way

Remember how we used to start our Django shell sessions? It typically looked something like this:

from myapp.models import User, Product, Order
# More imports...

The New Way

Behind the Scene

This feature was previously available through the excellent shell_plus command in django-extensions package. The Django core team recognized its value and integrated it into the main framework, making development just a bit more pleasant for everyone.

Why This Matters

This small but meaningful improvement:

Reduces boilerplate code
Speeds up debugging sessions
Makes interactive development more fluid
Eliminates a common source of frustration

Quick AWS Console Navigation: A Chrome Search Engine Hack The Problem

Quoc-Hung Hoang — Sat, 22 Feb 2025 08:08:07 +0000

We've all been there - navigating the AWS Console can be a pain.

Your browser does not support the video tag.

Whether you're:

Clicking through multiple levels of the navigation bar
Trying to remember which category contains the service you need
Googling "how to find X service in AWS console"

It's time-consuming and breaks your workflow momentum.

The Solution

What if you could jump directly to any AWS service by typing aws ec2 or aws s3 in your Chrome address bar? No more searching, no more clicking through menus.
[Image: Screenshot showing Chrome address bar with "aws ec2" typed in]

All you need to type is:

aws [tab] ec2 [enter]

And you're there! It's that simple.

Setup Guide

Here's how to set this up in Chrome:

Open Chrome Settings for Search Engines

Go to chrome://settings/searchEngines in Chrome
Scroll down to Site Search and click Add
Fill in the following details:

Name: AWS Console
Shortcut: aws
URL: https://console.aws.amazon.com/%s
Click "Add" to save

How It Works

Once configured, here's how to use it:

Your browser does not support the video tag.

Pro Tips

The service name should match its URL path in the AWS Console
You can use this technique for other services too - not just AWS!

Conclusion
This simple Chrome setup can save you countless clicks and searches throughout your day. It's especially helpful if you frequently switch between different AWS services.
No more menu diving or Google searches - just aws [tab] and go!

API Gateway Authorization Methods: My quick evaluation

Quoc-Hung Hoang — Sat, 25 Jan 2025 08:37:41 +0000

API Gateway Authorization Methods: My quick evaluation

Intro

I'm developing a utility tool for my internal team using API Gateway + Lambda. One aspect I'd like to apply when it comes to securing APIs is limiting API access. AWS provides us three primary authorization methods exist: IAM, Amazon Cognito, and Lambda Authorizers. Here is my quick evaluation of each method's implementation effort, and ideal use cases.

Authorization Method Comparisons

1. IAM Authorization

Complexity: Low
Best For: Internal AWS environments
Implementation Effort: 1/5
Key Advantages:
- Native AWS ecosystem integration
- Minimal custom code requirements
Limitations:
- Restricted to AWS infrastructure
- Limited external user support

2. Amazon Cognito

Complexity: Medium
Best For: User-centric applications
Implementation Effort: 3/5
Key Advantages:
- Managed user authentication
- Built-in social login capabilities
- Multi-factor authentication support
Challenges:
- Requires initial configuration
- Steeper learning curve for advanced features

3. Lambda Authorizers

Complexity: High
Best For: Enterprise-level, custom authentication scenarios
Implementation Effort: 5/5
Key Advantages:
- Maximum authentication customization
- Supports intricate authentication logic
- Integrates with external identity providers
Challenges:
- Requires custom Lambda function development
- Higher maintenance overhead
- Potential performance implications

Recommendation Matrix

Scenario	Recommended Method
Small/Internal Projects	IAM
User-Focused Applications	Cognito
Complex Enterprise Requirements	Lambda Authorizers

My closing thoughts

I'm developing some web-bases utility tools for my internal team. IAM Authorization seems a no-brainer to me. Minimal coding and configuration required helps me to ship fast to collect users' feedback as we also use AWS as our cloud provider.

In case, security concerns and authorization grow more complex, I'll look into Lambda Authorizers thanks to its flexibility while I'd like to avoid AWS Cognito as it requires steep learning curve when requirements are more complex.

What I Learned from the 'Amazon DynamoDB for Serverless Architectures' Course on AWS Skill Builder

Quoc-Hung Hoang — Thu, 09 Jan 2025 04:00:33 +0000

TL;DR

DynamoDB is well designed for at Online Transaction Processing (OLTP) workloads where you need consistent single-digit millisecond response times at any scale
Unlike traditional databases, the key to unlocking DynamoDB's power lies in knowing your request patterns upfront - not as an afterthought, but as a fundamental part of your design process. You can't just throw any query at it; instead, you design your data model around specific questions you need to answer. This approach makes it ideal for applications with well-defined workflows, like e-commerce carts, user sessions, or game states, but less suitable for exploratory analytics or ad-hoc queries.

How it works

Data is stored in tables. A table contains items with attributes.
You can think of items as rows or tuples in a relational database and attributes as columns.

Primary keys

Basic item requests:

Write

PutItem: Write item to specified primary key.
UpdateItem: Change attributes for item with specified primary key.
BatchWriteItem: Write bunch of items to the specified primary keys.
DeleteItem: Remove item associated with specified primary key.

Read

GetItem: Retrieve item associated with specified primary key.
BatchGetItem: Retrieve items with this bunch of specified primary keys.
Query: For specified partition key, retrieve items matching sort key expression (forward/reverse order).
Scan: Give me every item in my table.

Details: Working with items and attributes in DynamoDB

Secondary indexes: allow to query data based on other attributes than your table's primary key.

Local secondary indexes
- index is local to partition key
- allow you to query items with the same partition key
Global secondary indexes:
- allow you to query over the entire table
- index is across all partitions

Pros:

Improved query performance
Support complex queries
Non-Unique Indexing: They allow for indexing on non-unique attributes, which broadens the range of query possibilities, such as searching for products by category or timestamps in logs

Cons:

Write Performance Overhead: Each time an item in the base table is updated, corresponding entries in the secondary index must also be updated. This can slow down insert and update operations, especially if there are multiple secondary indexes on a table
Storage Costs: While secondary indexes reduce data retrieval time, they also consume additional storage space, which can be a consideration in environments with limited resources
Limited Use Cases: Secondary indexes should not be applied to attributes with low or very high cardinality; low cardinality can lead to inefficient queries, while high cardinality can result in excessive scanning across nodes

Important notes:

The secondary index should not apply to the values with too low (e.g. gender -> male/female) or too high cardinality (e.g. user's unique id)
- former case: querying won't be efficient as leads to wide index partitions and automatically we've a lot of data to scan
- latter case: queries can be executed at best on 1 node and at worst in all nodes
- Learn more: https://www.waitingforcode.com/general-big-data/secondary-index-nosql-data-stores/read?t#sample_implementation

Design considerations

Partition keys

When selecting an attribute as a partition key in a NoSQL database, it is crucial to consider several key factors to ensure that read and write operations are evenly distributed across partitions. Here are the primary considerations:

High Cardinality (that means there are lots of unique values):
• Definition: Choose attributes that have a large number of distinct values (high cardinality). For instance, using user_id, email, or order_id can help ensure that data is spread across many partitions.
• Impact: High cardinality minimizes the risk of “hot partitions,” where one partition receives significantly more traffic than others, leading to performance bottlenecks .
Avoid Monotonically Increasing Values:
• Examples: Attributes like timestamps or sequential IDs can lead to uneven distribution because new entries will always be directed to the same partition until it reaches its capacity.
• Recommendation: Instead, consider using composite keys or appending random suffixes to create variability in the partition key .

Hot and Cold Data

Separate data that is frequently accessed (hot) from data that is not accessed frequently (cold)

Large attributes

Ideally should keep item size small

Compress large data before storing it
Store large data in external storage like S3
Break it up into smaller items

Closing Thoughts

DynamoDB represents a fundamental shift in how we approach database design. While traditional databases let us figure out our queries after the fact, DynamoDB asks us to think differently – to start with our application's access patterns and build our data model around them. This isn't just a technical constraint; it's a design philosophy that rewards careful planning with exceptional performance and scalability.

Throughout this course, I've come to appreciate that success with DynamoDB isn't about fighting its constraints but embracing them. Whether it's choosing the right partition keys, managing hot and cold data, or designing secondary indexes, each decision flows from understanding your application's specific needs upfront.

Run additional script when starting a Postgres container

Quoc-Hung Hoang — Tue, 23 May 2023 13:17:20 +0000

Today, I've just explored a feature when you start a postgres instance on Docker which allows you to set up initial data like CREATE ROLE or GRANT .

You may learn more details here

We create *.sql or *.sh script to run SQL statement or bash script to prepare initial data. Postgres container will run any *.sql and *.sh found in the directory (which containing docker-compose.yml) to do further initialization before starting the service.

NOTE: scripts in /docker-entrypoint-initdb.d are only run if you start the container with a data directory that is empty; any pre-existing database will be left untouched on container startup.

And visit my example code at my gist

Commit message with title and body with one-liner git command

Quoc-Hung Hoang — Thu, 11 Aug 2022 09:51:52 +0000

When you use git, one of the most frequent used command is

git commit -m "my commit message"

But most of the time, you would give a more meaningful commit message. Meaningful I mean here is that the message should consist of subject line (a short description of your changes in code) and body (to give more detailed description of what you did)

Today I learn that git commit accept multiple message flag 😉
If you run this command

git commit -m "subject line" -m "commit description"

It will result in this

Author: hunghoang-saritasa <hung.hoang@saritasa.com>
Date:   Thu Aug 11 16:29:07 2022 +0700

    Subject line

    Commit message

This new finding helps me save time a lot. No need to open a vim editor when committing message with subject and body. And actually the git documentation do mention it.

Bonus: Another way to achieve this commit message structure is opening quotes then press enter and closing the commit with quotes again

DEV Community: Quoc-Hung Hoang

AWS Lambda Deployment Made Easy with GitHub Actions

Great News for the Serverless Community! 🚀

How Did Lambda Deployment Work Before?

The New Solution: Just One Action!

Real-World Implementation

Triển khai AWS Lambda functions nay đã dễ dàng hơn với Github Actions

Tin vui cho cộng đồng Serverless! 🚀

Việc deploy Lambda trước kia như thế nào?

Giải pháp mới: Chỉ cần 1 action duy nhất!

Thực hành với dự án thực tế

Bổ sung ngữ cảnh cho LLM: Nâng cao độ chính xác và tin cậy cho ứng dụng GenAI

Các phương thức bổ sung ngữ cảnh cho LLMs

1: Kỹ thuật Prompt theo Ngữ cảnh (Contextual Prompt Engineering)

2: Sinh Nội dung Tăng cường bằng Truy xuất (RAG)

3: Tinh chỉnh Mô hình (Fine-Tuning)

4: Huấn luyện Mô hình từ đầu

Kết luận: Lựa chọn Chiến lược Phù hợp

TERRAFORM - ANSIBLE: SỰ PHÂN ĐỊNH TRONG MÔ HÌNH CẤU HÌNH DEVOPS

1. Tổng quan 🛠️

Terraform

Ansible

2. Mô hình Declarative vs Imperative 🔄

Declarative Configuration (Cấu hình khai báo) ✍️

Imperative Configuration (Cấu hình mệnh lệnh) 🧩

3. Phân tích sâu về Terraform: Declarative thuần túy 🌱

Ưu điểm của cách tiếp cận Declarative

4. Phân tích sâu về Ansible: "Procedural Declarative" ⚙️

Tính chất "Procedural Declarative"

5. So sánh qua ví dụ cụ thể 🔍

Ví dụ 1: Triển khai máy chủ web 🌐

Cách tiếp cận Declarative (Terraform)

Cách tiếp cận Procedural Declarative (Ansible)

Ví dụ 2: Triển khai ứng dụng 📦

Cách tiếp cận Declarative (Terraform)

Cách tiếp cận Procedural Declarative (Ansible)

6. Triết lý Immutable vs Mutable Infrastructure 🏗️

Immutable Infrastructure: "Không sửa, chỉ thay" 🔄

Mutable Infrastructure: "Sửa chữa tại chỗ" 🔧

Terraform: Người ủng hộ trung thành của Immutable Infrastructure 🌟

Ansible: "Kẻ đa năng" trong thế giới infrastructure 🔧

7. Trường hợp sử dụng phù hợp 🎯

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

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

Kết hợp cả hai công cụ 🤝

8. Kết luận 🏁

Tái Cấu Trúc Terraform: Chuyển Đổi Từ State Monolithic Sang Kiến Trúc Mô-đun Theo Môi Trường

Nội dung chính

Tổ Chức State Ban Đầu

Giới Thiệu Về Terraform Module

Cấu Trúc Mới: Mô-đun Hóa, Hướng Theo Môi Trường

Thực hiện Migrate & Quản Lý State

Sử dụng terraform state rm và terraform import để import tài nguyên vào module mới

Xác Minh Quá Trình Chuyển Đổi

Kết Quả và lời kết

Zero-Code Authentication: Unleashing AWS Application Load Balancer's Built-in capabilities for simplifying user login

Unlock the Hidden Power of Application Load Balancer Authentication

Benefits

How it works

Limitations

Design Overview

Configuration Components

1. DNS and SSL Configuration

2. Amazon Cognito Configuration

User Pool Setup

3. Application Load Balancer Configuration

HTTP Listener (Port 80)

HTTPS Listener (Port 443)

Django 5.2's Smart Shell: Goodbye Manual Model Imports!

The Old Way

The New Way

Behind the Scene

Why This Matters

Quick AWS Console Navigation: A Chrome Search Engine Hack The Problem

The Solution

Setup Guide

How It Works

Pro Tips

API Gateway Authorization Methods: My quick evaluation

API Gateway Authorization Methods: My quick evaluation

Sử dụng `terraform state rm` và `terraform import` để import tài nguyên vào module mới