Open Sourcing Coinbase's Secure Deployment Pipeline (Odin)

Coinbase · 2018 · 2. Tăng trưởng · Độ khó: Trung bình — bài gốc

Bài cũ của blog.coinbase.com (Medium), nay redirect sang coinbase.com và chặn crawler; đọc qua trình duyệt, raw/ chỉ là placeholder.

Bối cảnh

• Theo Coinbase (5/2018): deploy hàng trăm lần mỗi ngày trên hàng trăm project; một tính năng đi từ ý tưởng tới production dưới một giờ.
• Khoảng 12/2017 traffic tăng gấp 20 lần so với một tháng trước (thành website lớn thứ 40 ở Mỹ, app iOS đứng đầu), nên mọi ứng dụng phải scale nhanh.
• Odin là bản mới, mã nguồn mở, của một deployer Ruby nội bộ; lúc viết bài vẫn đang alpha ở Coinbase.

Thay đổi chính

• Mục tiêu thiết kế: blue/green "dùng một lần" (tạo service mới, chờ khoẻ, xoá cái cũ); khai báo (mô tả release thành công trông thế nào, không mô tả cách deploy); scale cả dọc lẫn ngang; an toàn; thất bại êm; cấu hình giống nhau giữa môi trường; không cần cấu hình sau khi cài; một deployer cho mọi tài khoản AWS.
• Chỉ dùng dịch vụ AWS có sẵn: một Lambda + một Step Function assume role vào tài khoản đích. Điều kiện duy nhất để deploy vào một tài khoản là có IAM role cho phép.
• Release dạng JSON khai báo: project, config (môi trường), subnet, AMI, user data, và từng service với instance type, security group, ELB, target group, autoscaling. Mọi tài nguyên tham chiếu bằng tag, không bằng ID, để cùng file chạy được ở mọi môi trường.
• State machine: Validate → Lock (không cho deploy đồng thời cùng project/config) → ValidateResources (tài nguyên phải được tag cho đúng project/config/service) → Deploy (tạo ASG mới mỗi service) → CheckHealthy (ASG, ELB, target group; thấy instance đang bị terminate là dừng ngay) → CleanUpSuccess (xoá ASG cũ) hoặc CleanUpFailure (xoá ASG mới). Kết thúc ở Success, FailureClean, hoặc FailureDirty (dọn thất bại, cần alert; theo bài là không nên xảy ra). Mặc định chờ khoẻ 10 phút.
• Bảo mật của deployer: chỉ Odin được deploy và chỉ người được chọn gọi được Step Function; tag giới hạn tài nguyên nào dùng được cho project nào; chống replay/MITM bằng kiểm tra ngày tạo còn mới và so release với bản đã upload lên S3; audit từ log của Step Function và Lambda.
• Codeflow (nội bộ, chưa mở mã nguồn) quản lý cấu hình và gọi Odin; cho mọi engineer deploy miễn là code và cấu hình đã được review, thay vì chỉ nhóm "tin cậy".

Vì sao

• Blue/green dùng một lần giúp thực thi chính sách tuổi máy 30 ngày: mục tiêu 98% instance dưới 30 ngày tuổi.
• Đợt tăng 20 lần cuối 2017: theo Coinbase, ứng dụng chỉ cần đổi cấu hình (instance lớn hơn, min/max, policy scale theo CPU) là chịu được.
• Giới hạn người deploy làm chậm mọi người, tạo nút cổ chai, tăng lỗi deploy và theo Coinbase còn kém an toàn hơn; kiểm soát chuyển sang review + guardrail trong deployer.

Bài học cho SWE

• Deployer là hạ tầng nhạy cảm: nó cần quyền rộng nên chính nó phải bị giới hạn (ai gọi, được dùng tài nguyên nào, chống replay) và để lại audit.
• Thay máy thay vì sửa máy, kèm tuổi máy tối đa, là một cách cưỡng chế vá lỗi và chống trôi cấu hình. Slack 2026 đi tới cùng chỗ bằng image đã bake (Slack 2026).
• Trạng thái kết thúc "thất bại nhưng dọn sạch" và "thất bại, còn rác" nên tách bạch; cái sau là alert.
• Tham chiếu tài nguyên bằng tag thay vì ID là điều kiện để một file release chạy ở mọi môi trường.

Liên quan

• Coinbase 2026 · Amazon 2014 · Slack 2026 · Monzo 2022 (bỏ người phê duyệt, dồn kiểm soát vào guardrail)
• Deploy và release an toàn · Bảo mật hạ tầng và quản lý secret