AWS Study Group

Phát triển một ứng dụng serverless Slack sử dụng AWS Step Functions và AWS Lambda

Bởi Eric Johnson |  ngày 24 tháng 3 năm 2023 |  AWS Lambda, AWS Step Functions, Serverless | Permalink |

Bài viết này được viết bởi Sam Wilson (Cloud Application Architect)  và John Lopez (Cloud Application Architect).

Slack, như một dịch vụ cộng tác và giao tiếp dành cho doanh nghiệp, mở ra cơ hội cho các nhà phát triển cải thiện hiệu quả thông qua việc triển khai các Slack Applications (ứng dụng) tự viết. Một trong những cơ hội như vậy là việc cung cấp các tài nguyên AWS hiện có cho tổ chức của bạn mà không cần nhân viên của bạn truy cập AWS Management Console hoặc AWS CLI.

Ví dụ: một thành viên trong nhóm phân tích dữ liệu của bạn cần kích hoạt workflow AWS Step Functions để xử lý lại một công việc dữ liệu hàng loạt. Thay vì cấp cho người dùng quyền truy cập trực tiếp vào Step Functions workflow trong AWS Management Console hoặc AWS CLI, thì bạn có thể cấp quyền truy cập để gọi workflow từ trong kênh Slack được chỉ định.

Bài viết này trình bày cách một kiến ​​trúc serverless cho phép người dùng Slack gọi các tài nguyên AWS như AWS Lambda functions và Step Functions thông qua Slack Desktop UI và Mobile UI bằng ứng dụng Slack. Kiến trúc serverless là lựa chọn lý tưởng cho ứng dụng Slack vì khả năng mở rộng của nó. Nó có thể xử lý hàng nghìn yêu cầu đồng thời từ người dùng Slack mà không phải chịu gánh nặng trong việc quản lý chi phí vận hành.

Ví dụ này hỗ trợ tích hợp với các tài nguyên AWS khác thông qua Step Functions. Truy cập documentation để biết thêm thông tin về việc tích hợp với các tài nguyên AWS khác.

Bài viết này giải thích kiến ​​trúc ví dụ về serverless và hướng dẫn cách triển khai ví dụ đó trong tài khoản AWS của bạn. Chúng tôi sẽ trình bày ví dụ và thảo luận về các tàng buộc được phát hiện trong quá trình phát triển.

Tổng quan

Code trong bài viết này sẽ tạo ra một ứng dụng Slack được xây dựng với nhiều dịch vụ AWS serverless:

  • Amazon API Gateway sẽ nhận tất cả yêu cầu đến từ Slack. Step Functions điều phối các hoạt động yêu cầu như xác thực người dùng, truy xuất cấu hình, định tuyến yêu cầu và định dạng phản hồi.
  • Một Lambda Function gọi chức năng xác thực dành riêng cho Slack và gửi phản hồi đến Slack UI.
  • Amazon EventBridge đóng vai trò tích hợp pub-sub giữa yêu cầu và bộ xử lý yêu cầu.
  • Amazon DynamoDB sẽ lưu trữ các quyền cho từng Slack user để đảm bảo họ chỉ có quyền truy cập vào các tài nguyên mà bạn chỉ định.
  • AWS Systems Manager sẽ lưu trữ kênh Slack cụ thể nơi bạn sử dụng ứng dụng Slack.
  • AWS Secrets Manager sẽ lưu trữ signing secret của ứng dụng Slack và bot token được sử dụng để xác thực.

AWS Cloud Development Kit (AWS CDK) sẽ triển khai các tài nguyên AWS. Ví dụ này có thể tích hợp vào bất kỳ nền tảng CI/CD hiện có nào tuỳ bạn lựa chọn.

Tổng quan kiến trúc

  1. Người dùng Slack trên máy tính hoặc điện thoại sẽ bắt đầu yêu cầu bằng cách dùng command “/my-slack-bot”  hoặc tương tác với Slack Block Kit UI.
  2. API Gateway sẽ chuyển tiếp yêu cầu và chuyển đổi payload thành format mà luồng công việc Step Functions của trình xác thực yêu cầu có thể chấp nhận.
  3. Trình xác thực yêu cầu sẽ kích hoạt Lambda function là Slack authentication để xác minh yêu cầu gốc đến từ tổ chức Slack đã được định cấu hình. Lambda function này sử dụng Slack Bolt library for TypeScript để thực hiện xác thực yêu cầu và trích xuất chi tiết yêu cầu thành một tải trọng nhất quán. Ngoài ra, Secrets Manager còn lưu trữ signing secret, cái mà Slack Bolt API sử dụng trong quá trình xác thực.
  4. Trình xác thực yêu cầu sẽ truy vấn vào bảng Authorized Users trong DynamoDB với tên người dùng được trích xuất từ ​​tải trọng. Nếu người dùng không tồn tại, yêu cầu sẽ kết thúc bằng kết quả trả về là bị từ chối.
  5. Trình xác thực yêu cầu truy xuất ID của channel được cho phép và so sánh nó với ID của channel được tìm thấy trong yêu cầu. Nếu hai ID này không khớp nhau thì yêu cầu sẽ kết thúc bằng kết quả trả về là bị từ chối.
  6. Trình xác thực yêu cầu sẽ gửi yêu cầu đến Command event bus trong EventBridge.
  7. Command event bus sử dụng thuộc tính action của yêu cầu để định tuyến yêu cầu đến Step Functions workflow của bộ xử lý yêu cầu.
  8. Mỗi Step Functions workflow của bộ xử lý có thể xây dựng các thành phần Slack Block Kit UI, gửi bản cập nhật cho các thành phần UI hiện có hoặc gọi các Lambda functions và Step Functions workflow hiện có. 
  9. Ứng dụng Slack trên di động hoặc máy tính sẽ hiển thị các thành phần UI mới hoặc đưa ra các bản cập nhật cho yêu cầu hiện khi yêu cầu đó được xử lý. Người dùng có thể tương tác với các thành phần UI mới để tiếp tục yêu cầu hoặc bắt đầu lại với một yêu cầu bổ sung.

Kiến trúc của ứng dụng này sẽ thay đổi quy mô theo nhu cầu tải trọng, cung cấp khả năng xử lý đồng thời hàng nghìn người dùng Slack (thông qua chính nền tảng Slack), bỏ qua việc truy cập trực tiếp vào AWS Management Console. Kiến trúc này mang lại khả năng mở rộng dễ dàng hơn cho ứng dụng trò chuyện để hỗ trợ các command mới khi phát sinh nhu cầu người dùng.

Cuối cùng, kiến trúc và cách triển khai ứng dụng được tuân theo AWS Well-Architected về việc Operational Excellence, Security, Reliability, và Performance Efficiency.

Step Functions phù hợp cho ví dụ này vì nó hỗ trợ tích hợp với nhiều dịch vụ AWS khác. Trong ví dụ này, Step Functions cho phép điều phối các tương tác với các Lambda functions, các bảng DynamoDB, và các event bus của EventBridge với code ít nhất.

Ví dụ này tận dụng Step Functions Express Workflows để hỗ trợ high-volume, các hành động event-driven do ứng dụng Slack tạo ra. Kết quả của việc sử dụng Express Workflow là bộ xử lý yêu cầu có khả năng mở rộng, đáp ứng được nhanh và có khả năng xử lý hàng chục nghìn yêu cầu mỗi giây. Để tìm hiểu thêm, hãy xem lại sự khác biệt giữa standard and Express Workflows.

Ví dụ được trình bày sẽ sử dụng AWS Secrets Manager để lưu trữ và truy xuất thông tin xác thực một cách an toàn. AWS Secrets Manager mang lại những lợi ích sau:

  • Lưu trữ tập trung, an toàn các secrets thông qua việc mã hóa ở trạng thái lưu trữ.
  • Dễ dàng quản lý quyền truy cập thông qua AWS Identity và Access Management (IAM).
  • Hỗ trợ tích hợp ngay lập tức với tất cả các dịch vụ AWS trong kiến trúc.

Ngoài ra, ví dụ này sử dụng dịch vụ AWS Systems Manager Parameter Store để duy trì dữ liệu cấu hình của ứng dụng cho Slack Channel ID. Trong số các lợi ích mà AWS System Manager mang lại, thì ví dụ này sẽ tận dụng lợi thế của việc lưu trữ dữ liệu cấu hình đã được mã hóa với khả năng hỗ trợ versioning.

example features a variety of interactions for the Slack Mobile or Desktop application, including displaying a welcome screen, entering form information, and reporting process status. EventBridge enables this example to route requests from the Request Validator Step Function using the serverless Event Bus này và tách biệt từng hành động. Chúng tôi cấu hình Rules để liên kết một sự kiện với bộ xử lý yêu cầu Step Function.

Hướng dẫn

Đây là điều kiện tiên quyết, bạn cần cài đặt:

  • Phiên bản AWS CDK 2.19.0 hoặc mới hơn.
  • Phiên bản Node 16+.
  • Docker-cli.
  • Git.
  • Một tài khoản Slack cá nhân hoặc của công ty với quyền tạo ứng dụng.
  • Slack Channel ID của một channel trong Workspace của bạn để tích hợp với ứng dụng Slack.

Slack channel details

Để lấy Channel ID, hãy mở context menu trên Slack channel và chọn View channel details. Một modal hiển thị Channel ID của bạn ở phía dưới:

Slack bot channel details

Để biết thêm thông tin, hãy truy cập trang Getting Started with Bolt for JavaScript của Slack.

Tài liệu README cho GitHub Repository, Amazon Interactive Slack App Starter Kit, bao gồm các hướng dẫn toàn diện, có các bước chi tiết cho việc:

  • Cấu hình Slack API
  • Triển khai ứng dụng thông qua AWS Cloud Development Kit (CDK)
  • Các bản cập nhật bắt buộc dành cho AWS Systems Manager Parameters và secrets

Demo ứng dụng Slack

  1. Khởi động ứng dụng Slack bằng cách chạy command  “/my-slack-bot”

Chạy Command 

  1. Từ menu My Slack Bot action, chọn Sample Lambda.

Chọn Sample Lambda

  1. Nhập Input Value, chọn Submit, sau đó quan sát phản hồi (giá trị đầu vào này áp dụng cho Lambda function mẫu).

Lambda submit

Kết quả trả về

  1. Khởi động ứng dụng Slack bằng cách chạy lệnh “/my-slack-bot”, sau đó chọn Sample State Machine:

Khởi động ứng dụng

Chọn Sample State Machine

  1. Nhập Input Value, chọn Submit, sau đó quan sát phản hồi (giá trị đầu vào này áp dụng cho downstream state machine)

State machine submit

Kết quả state machine

Những ràng buộc trong ví dụ này

Slack có các ràng buộc trong việc gửi và nhận yêu cầu, nhưng các mẫu ánh xạ của API Gateway cung cấp cơ chế tích hợp với nhiều ràng buộc yêu cầu khác nhau.

Slack sử dụng application/x-www-form-urlencoded để gửi yêu cầu đến một URL tùy chỉnh. Chúng tôi đã thiết kế một mẫu yêu cầu để định dạng đầu vào từ Slack thành một định dạng nhất quán cho Request Validator Step Function. Các Headers như X-Slack-Signature và X-Slack-Request-Timestamp cần được chuyển tiếp để đảm bảo yêu cầu từ Slack được xác thực.

Đây là mẫu ánh xạ yêu cầu cần thiết cho việc tích hợp:

{

  “stateMachineArn”: “arn:aws:states:us-east-1:827819197510:stateMachine:RequestValidatorB6FDBF18-FACc7f2PzNAv”,

  “input”: “{\”body\”: \”$input.path(‘$’)\”, \”headers\”: {\”X-Slack-Signature\”: \”$input.params().header.get(‘X-Slack-Signature’)\”, \”X-Slack-Request-Timestamp\”: \”$input.params().header.get(‘X-Slack-Request-Timestamp’)\”, \”Content-Type\”: \”application/x-www-form-urlencoded\”}}”

}

Slack gửi message payload ở hai định dạng khác nhau: URL-encoded và JSON. May mắn thay, thư viện Slack Bolt for JavaScript có thể hợp nhất hai định dạng này thành một JSON payload duy nhất và xử lý việc xác minh.

Slack yêu cầu phản hồi trạng thái 204 cùng với phần nội dung trống để nhận biết rằng yêu cầu đã thành công. Mẫu phản hồi tích hợp sẽ ghi đè phản hồi Step Function thành định dạng mà Slack chấp nhận.

Đây là mẫu ánh xạ phản hồi cần thiết cho việc tích hợp:

#set($context.responseOverride.status = 204)

{}

Kết luận

Trong bài viết này, bạn đã tìm hiểu cách có thể cho phép người dùng Slack trong tổ chức của bạn có khả năng gọi các tài nguyên AWS hiện có mà không cần truy cập AWS Management Console or AWS CLI. Ví dụ về serverless cho phép bạn xây dựng tùy chỉnh workflows của riêng mình để đáp ứng nhu cầu của tổ chức bạn.

Để tìm hiểu thêm về các khái niệm được thảo luận trong blog này, hãy truy cập:

Để biết thêm tài nguyên học tập về serverless, hãy truy cập Serverless Land.

←
→

Leave a comment