Giới thiệu

Trong hành trình khám phá điện toán đám mây của mình, tôi đã quyết định xây dựng một dashboard serverless đa chức năng sử dụng AWS. Dashboard này bao gồm nhiều ứng dụng như ExpenseApp, WeatherApp, NewsApp và GitHubApp. Mỗi ứng dụng này chạy hoàn toàn serverless với AWS Lambda, sử dụng API Gateway để định tuyến và lưu trữ dữ liệu trong DynamoDB. Để dễ dàng triển khai, tôi đã triển khai pipeline CI/CD sử dụng GitHub Actions, tự động hóa toàn bộ quy trình từ việc commit mã đến triển khai.

Sơ đồ Kiến trúc

Phân tích Công nghệ

Frontend:

Frontend của dashboard được xây dựng bằng TypeScript. Vì tôi muốn tập trung vào hạ tầng, tôi đã sử dụng các công cụ AI để xử lý phần này.

Backend:

AWS Lambda: Logic cho từng ứng dụng (Expense, Weather, News, GitHub) chạy trên các hàm AWS Lambda, được viết bằng Python. Tôi cũng đã sử dụng AI để tạo mã cho các hàm này.
API Gateway: Dịch vụ này hoạt động như một bộ định tuyến, hướng các yêu cầu đến hàm Lambda chính xác dựa trên đường dẫn API, chẳng hạn như /ExpenseApp.
DynamoDB: Tôi đã sử dụng cơ sở dữ liệu NoSQL này đặc biệt cho ExpenseApp để lưu trữ dữ liệu người dùng. Để giữ cho dự án đơn giản, tôi đã quyết định không lưu trữ API keys cho các ứng dụng khác tại đây.

CI/CD:

GitHub Actions: Tôi đã tự động hóa việc triển khai cả frontend và backend bằng cách sử dụng GitHub Actions, đảm bảo rằng mọi thay đổi đều được tự động đẩy lên AWS mà không cần bước thủ công nào.

Quyền và Vai trò IAM

Tôi đã tạo một người dùng IAM riêng biệt để quản lý các tài nguyên cần thiết cho dashboard. Người dùng này bị giới hạn vào các tài nguyên cần thiết cho từng ứng dụng. Quyền của người dùng bao gồm việc tạo và cập nhật các hàm Lambda, quản lý cấu hình API Gateway, truy cập DynamoDB và tương tác với S3 cho các tài sản frontend. Sử dụng một người dùng IAM riêng biệt là một thực hành bảo mật tốt, vì nó tuân thủ nguyên tắc tối thiểu quyền hạn.

Ví dụ Chính sách:

json Copy

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "iam:CreateRole",
                "iam:GetRole",
                "iam:AttachRolePolicy",
                "iam:ListAttachedRolePolicies",
                "iam:PassRole"
            ],
            "Resource": [
                "arn:aws:iam::123456789012:role/LambdaDynamoDBRole",
                "arn:aws:iam::123456789012:role/LambdaDynamoDBCloudWatchRole"
            ]
        }
    ]
}

Thiết kế Cơ sở Dữ liệu cho ExpenseApp

Đối với ExpenseApp, tôi đã sử dụng DynamoDB làm cơ sở dữ liệu. Tôi đã thiết kế bảng với các thông số như sau:

Tên Bảng: expenses-table
Khóa Phân vùng: expenseId (Số)
Khóa Sắp xếp: timestamp (Số)
Thuộc tính: description, amount, category, date, và timestamp.

Tôi đã sử dụng chế độ dung lượng theo yêu cầu của DynamoDB vì mô hình này lý tưởng cho việc ở trong AWS free tier, vì tôi chỉ trả tiền cho những gì tôi sử dụng, và lưu lượng thấp của ứng dụng đơn giản của tôi có khả năng sẽ nằm dưới giới hạn miễn phí.

Thiết lập Các Hàm Lambda và Tích hợp API Gateway

Mỗi ứng dụng (Expense, Weather, News, GitHub) đều có hàm Lambda riêng. Dưới đây là tổng quan về tích hợp và tự động hóa:

Triển khai Hàm Lambda:
- Mỗi ứng dụng có một tập hợp các hàm Lambda được triển khai tự động bằng một script triển khai.
- Các hàm này được kết nối với các điểm cuối API Gateway: /ExpenseApp, /WeatherApp, /NewsApp, và /GitHubApp.
Đường dẫn API Gateway:
- Tôi đã sử dụng API Gateway như là bộ định tuyến chính cho dashboard của mình. Tôi đã thiết lập một đường dẫn dành riêng cho từng phần của ứng dụng. Ví dụ, tôi đã tạo một route cụ thể gọi là /ExpenseApp cho ExpenseApp. Trên route đó, tôi đã thêm một phương thức GET. Sau đó, tôi liên kết nó trực tiếp với hàm Lambda của mình. Tôi đã sử dụng cái gọi là Lambda Proxy integration, đây là cách đơn giản để đảm bảo API Gateway gửi mọi thứ từ yêu cầu thẳng đến mã của tôi để nó có thể xử lý.
- Lỗi Cấu hình API Gateway: Một thách thức tôi đã gặp phải là lỗi tích hợp giữa API Gateway và các hàm Lambda, điều này được gây ra bởi sự không khớp trong các đường dẫn tài nguyên mong đợi. Các hàm Lambda mong đợi các đường dẫn như /ExpenseApp nhưng lại được định nghĩa dưới đường dẫn gốc /. Đây là một vấn đề gây khó chịu vì tôi không thể làm cho API Gateway khớp với Lambda của mình bất kể quyền hạn của tôi có bao nhiêu. Khi tôi điều chỉnh các đường dẫn cho phù hợp, mọi thứ đã hoạt động trơn tru.

Xử lý CORS (Chia sẻ Tài nguyên Giữa Các Nguồn)

Một vấn đề gây khó chịu khác mà tôi gặp phải là làm cho CORS (Chia sẻ Tài nguyên Giữa Các Nguồn) hoạt động. Frontend của dashboard cần phải giao tiếp với các backend khác nhau, và vì lý do nào đó, các yêu cầu cứ bị chặn. Tôi nghĩ mình đã giải quyết vấn đề này bằng cách chỉ cần bật CORS trên API Gateway chính (tài nguyên gốc), nhưng điều đó không đủ. Hóa ra tôi phải vào từng tài nguyên con (như /ExpenseApp và /WeatherApp) và bật nó ở đó nữa. Và đó chỉ là khởi đầu. Tôi cũng phải đảm bảo rằng các hàm Lambda của mình bao gồm đoạn mã để trả về các tiêu đề Access-Control đúng trong phản hồi của chúng. Thách thức cuối cùng là sử dụng AWS CLI cho việc này. Tôi không thể chỉ truyền các tiêu đề trên một dòng vì dòng lệnh cứ làm rối lên các dấu ngoặc. Để khắc phục, tôi đã phải tạo một tệp JSON riêng chỉ cho các tiêu đề và sau đó tham chiếu tệp đó trong lệnh CLI của mình. Đây là một quá trình thử và sai tốn thời gian.

Pipeline CI/CD với GitHub Actions

CI/CD Backend:

GitHub Actions tự động hóa việc triển khai các hàm Lambda mỗi khi mã được đẩy lên repository.

CI/CD Frontend:

Frontend được triển khai lên các bucket S3 tự động mỗi khi có thay đổi được commit. Pipeline GitHub Actions xây dựng các tài sản frontend và tải chúng lên bucket S3 thích hợp để công khai.

AWS CLI để Tự động hóa

Sau khi hoàn thành dashboard của mình, tôi muốn thử thách bản thân: làm thế nào để đưa tất cả những thứ này lên AWS mà không cần chạm vào bảng điều khiển AWS? Tạo thủ công tất cả các hàm Lambda, vai trò IAM và các điểm cuối API Gateway sẽ là một quá trình tốn thời gian và căng thẳng. Đó là lúc tôi sử dụng AWS Command Line Interface (CLI) để tự động hóa toàn bộ quy trình.

Tôi đã viết một script deploy_infra.sh duy nhất để xử lý mọi thứ. Script này đủ thông minh để kiểm tra xem một tài nguyên đã tồn tại chưa trước khi cố gắng tạo nó. Đối với mỗi ứng dụng của tôi, script này đầu tiên tạo các IAM roles cần thiết và cấp cho mỗi ứng dụng quyền cơ bản mà nó cần. Đối với ExpenseApp, nó thêm quyền truy cập bổ sung vào DynamoDB.

Khi các vai trò đã được thiết lập, script này sẽ chuyển sang việc triển khai hàm. Nó lấy mã Python của tôi, đóng gói nó với bất kỳ thư viện cần thiết nào, và sau đó tải lên để tạo một hàm Lambda mới. Nó cũng lấy bất kỳ API key riêng tư nào từ một tệp riêng để tôi không vô tình lộ chúng.

Phần cuối cùng, và có lẽ là phức tạp nhất, là tự động hóa API Gateway. Script này không chỉ tạo ra một API mới cho mỗi ứng dụng mà còn xây dựng các đường dẫn, như /ExpenseApp và /WeatherApp. Nó kết nối những đường dẫn này với các hàm Lambda tương ứng bằng cách sử dụng Lambda Proxy integration. Và vì CORS là một vấn đề khó cấu hình, tôi đã xây dựng một chức năng đặc biệt vào script để xử lý tất cả các tiêu đề và các yêu cầu OPTIONS trước khi bay.

Cuối cùng, script này triển khai toàn bộ API và cung cấp cho tôi điểm cuối công khai cho mỗi ứng dụng, vì vậy tôi có thể ngay lập tức bắt đầu kiểm tra. Toàn bộ quy trình này, mà trước đây sẽ mất hơn 15 phút để nhấp chuột và cấu hình thủ công, giờ đây chỉ cần một lệnh duy nhất. Đây là một chiến thắng lớn cho tôi và tôi đã học được rất nhiều khi thực hiện.

Kết luận

Dự án dashboard đa ứng dụng này đã mang lại cho tôi một trải nghiệm học tập tốt trong việc thiết kế và triển khai các kiến trúc serverless với AWS. Tôi đã có thể tập trung vào các khía cạnh kỹ thuật điện toán đám mây (như vai trò IAM, các hàm Lambda, và API Gateway), trong khi sử dụng GitHub Actions để tự động hóa quy trình triển khai. Dự án này không chỉ là một bài tập học tập mà còn là một tác phẩm để giới thiệu kỹ năng kỹ thuật điện toán đám mây của tôi. Trong tương lai, tôi rất háo hức khám phá các công cụ Infrastructure-as-Code như AWS CDK hoặc Terraform để tiếp tục tối ưu hóa việc thiết lập và triển khai các ứng dụng serverless.

Các Thực Hành Tốt Nhất

Luôn kiểm tra quyền IAM theo nguyên tắc tối thiểu.
Đảm bảo rằng các hàm Lambda xử lý ngoại lệ đúng cách để tránh việc lộ thông tin nhạy cảm.

Những Cạm Bẫy Thường Gặp

Đường dẫn API không khớp có thể gây ra lỗi tích hợp giữa API Gateway và Lambda.
CORS không được cấu hình chính xác có thể gây ra lỗi khi thực hiện yêu cầu từ frontend.

Mẹo Hiệu Suất

Sử dụng chế độ dung lượng On-Demand cho DynamoDB để tiết kiệm chi phí và tối ưu hóa hiệu suất.
Tối ưu hóa mã Lambda để giảm thiểu thời gian thực thi và chi phí.

Câu hỏi Thường Gặp

1. Làm thế nào để quản lý các phiên bản của hàm Lambda?

Sử dụng tags hoặc versioning trong AWS Lambda để quản lý các phiên bản khác nhau của hàm.

2. Có thể sử dụng các công cụ nào để tự động hóa quy trình CI/CD?

Sử dụng GitHub Actions, AWS CodePipeline hoặc Jenkins để tự động hóa quy trình CI/CD cho ứng dụng.

3. Làm thế nào để xử lý việc theo dõi và ghi log cho các hàm Lambda?

Sử dụng AWS CloudWatch để theo dõi và ghi log cho các hàm Lambda của bạn.

Kiến Trúc Dashboard Serverless với AWS Lambda và CI/CD