Cho tới gần đây, mọi thay đổi ở phần web của ứng dụng chợ mà tôi đang làm đều được đưa lên theo đúng cách của một thay đổi trên API Django: build Docker image, đẩy lên, rồi triển khai lần lượt (rolling) lên từng máy trên Fly.io. Giao diện web (bản xuất web của ứng dụng di động, cộng với các trang giới thiệu do một trình tạo trang tĩnh (static site generator) build ra) được sao chép vào image ngay cạnh API, nên không có cách nào khác để đưa nó ra. Sửa một dòng CSS mất khoảng bảy phút và khởi động lại 11 máy. Có một ngày trong tháng Tám tôi làm việc đó sáu lần.
Bài này đi lần lượt qua thứ tôi đã thay vào đó: một script triển khai build cả hai cây giao diện, tải chúng lên object storage dưới một tiền tố có phiên bản, đổi một đối tượng con trỏ, đợi đến khi mọi máy đều đang phục vụ phiên bản mới, rồi xóa bộ nhớ đệm của Cloudflare qua API. Ở phía bên kia, Django đọc con trỏ ở mỗi yêu cầu và phục vụ đúng phiên bản được ghi trong đó. API không khởi động lại chút nào.
Vì sao cách cũ có vấn đề#
Chi phí lớn nhất là việc khởi động lại. Mười một máy triển khai lần lượt nghĩa là mười một lần khởi động nguội (cold start), và trên CPU dùng chung thì Django mất khoảng mười ba giây để lên, trong đó bảy giây chỉ để import Django. Tôi có thêm một bước làm nóng ở cuối script triển khai, gọi vào từng máy một để người dùng thật không phải là người trả cái giá đó, và hệ quả là mỗi lần phát hành web đều kết thúc bằng việc ngồi đợi máy chậm nhất. Những lần khởi động nguội đó tốn kém thế nào trên Fly.io, tôi đã viết trong bài Thu về 0 (scale to zero), và mỗi lần khởi động lại là một lần sập 30 giây. Nói ngắn gọn, mỗi lần khởi động lại là một khoảng thời gian người dùng có thể nhận lỗi 504, nên một đường triển khai không khởi động lại gì cả sẽ đóng hẳn khoảng đó cho các lần phát hành web.
Vấn đề thứ hai là đầu ra của trang tĩnh bị tách đôi. HTML thì vào image, nhưng RSS feed và chỉ mục tìm kiếm thì lên thẳng bucket. Chúng được build từ cùng một nguồn, chỉ là không cùng thời điểm, nên có thể lệch nhau mà chẳng ai nhận ra cho đến khi lệch thật.
Vấn đề thứ ba thiên về thói quen. Khi một lần phát hành tốn bảy phút cộng một lần khởi động lại, bạn sẽ thôi làm những lần phát hành nhỏ. Tôi để ba bốn bản sửa chất đống thay vì đưa lên từng cái, và đó chính xác là cách một thay đổi một dòng bị đưa lên cùng với thứ gì đó đang hỏng.
Bố cục trong bucket#
Mọi thứ nằm trong một bucket tương thích S3, dưới tiền tố web/:
web/current ← a text file containing one version string
web/a1b2c3d-20260914021500/manifest.json ← every file in this version
web/a1b2c3d-20260914021500/app/... ← the app's web export
web/a1b2c3d-20260914021500/site/... ← the static site's output
web/9f8e7d6-20260912093012/... ← the previous version, still therePhiên bản là mã git SHA ngắn cộng với dấu thời gian UTC, nên nhìn vào là biết commit nào và đưa lên lúc nào. web/current là thứ duy nhất thay đổi khi một bản phát hành lên sóng.
Script triển khai làm gì#
Toàn bộ là một script, chạy từ thư mục gốc của repo. Theo thứ tự:
1. Từ chối cây git chưa sạch. Việc đầu tiên nó làm là git status --porcelain, và nếu có bất kỳ dòng nào trả về thì thoát. Cái gì nằm trên đĩa là cái được tải lên, và script triển khai cũ của trang giới thiệu từng đưa lên nội dung chưa commit đúng theo cách đó. Có một cờ để bỏ qua bước này cho lúc bạn biết rõ mình đang làm gì, nhưng tôi chưa dùng. Sau đó nó tính chuỗi phiên bản từ git rev-parse --short HEAD và thời điểm hiện tại.
2. Build cả hai cây. Với ứng dụng, nó chạy bản xuất web với địa chỉ API và WebSocket của production được nhúng sẵn, tiếp theo là một lượt nén trước bằng Brotli. Việc nén trước đáng để giải thích: Cloudflare có nén Brotli tại chỗ, nhưng ở mức chất lượng thấp, và trên bundle này đo ra còn tệ hơn gzip (2,04MB so với 1,66MB). Nén một lần lúc build với chất lượng 11 đưa nó xuống 1,28MB, nên script ghi một tệp .br song sinh cạnh mỗi tệp JS, CSS và JSON trên 1KB. Với trang giới thiệu, nó chạy trình tạo trang tĩnh với chế độ rút gọn (minify) bật.
3. Tải lên. Nó duyệt cả hai thư mục build, rồi tải mọi tệp lên web/<version>/app/... và web/<version>/site/... bằng mười sáu luồng. Mỗi đối tượng được gán Content-Type đoán từ tên tệp (bỏ .br trước), và các tệp Brotli song sinh có thêm Content-Encoding: br. Chỉ khi mọi tệp đã lên hết, nó mới ghi manifest.json, một đối tượng JSON với hai danh sách đường dẫn tương đối. Thứ tự này quan trọng: phía Django coi một phiên bản không có tệp kê khai là không tồn tại, nên một phiên bản tải dở dang không bao giờ có thể được đặt làm hiện tại. Hiện giờ là vài trăm tệp và tải lên mất khoảng sáu giây.
4. Đổi con trỏ. Một lệnh put_object ghi chuỗi phiên bản vào web/current. Đó là phát hành.
5. Đợi các máy. Mỗi máy API đệm con trỏ năm giây, nên trong chốc lát sau khi đổi, vài máy vẫn còn ở phiên bản cũ. Script thăm dò một endpoint báo phiên bản trên API mỗi nửa giây và đếm số câu trả lời liên tiếp mang phiên bản mới. Fly cân bằng tải qua tất cả các máy, nên một chuỗi mười sáu câu trả lời khớp liên tiếp (nhiều hơn số máy) là cách nó biết mọi máy đều đã đọc lại con trỏ. Một câu trả lời cũ là đếm lại từ đầu. Sau 90 giây nó bỏ cuộc và bảo bạn kiểm tra bằng tay; lần đổi thật đầu tiên mất hơn 30 giây một chút, nên giới hạn không đặt thấp hơn.
6. Xóa bộ nhớ đệm Cloudflare. Một lời gọi API, nói ở dưới. Nếu thất bại, script in cảnh báo rồi đi tiếp.
7. Báo lên kênh chat của đội. Cùng webhook mà cảnh báo lỗi lúc chạy dùng nhận một dòng với phiên bản và người chạy, để một loạt lỗi có thể được đọc đối chiếu với thứ vừa thay đổi. Quay lui đăng bằng màu hổ phách.
Từ đầu đến cuối, một lần phát hành mất hơn một phút một chút, phần lớn là thời gian xuất bản web.
Phía Django#
Django vốn đã là thứ phục vụ giao diện. Mọi URL không phải API đều được trả lời bằng trang đã dựng sẵn (prerender) trong bản xuất web cho route đó, còn các trang giới thiệu, chính sách bảo mật và hỗ trợ lấy từ đầu ra của trang tĩnh. Trước đây những view này mở tệp trên đĩa. Giờ chúng đọc qua một lớp nhỏ biết cách lấy dữ liệu từ bucket.
Với mỗi yêu cầu, nó xác định ba thứ: phiên bản hiện tại (đọc từ web/current, đệm năm giây), tệp kê khai của phiên bản đó (đệm chừng nào phiên bản đó còn là hiện tại), và bản thân tệp (một LRU nhỏ trong bộ nhớ chứa nội dung tệp, nên HTML của trang và bundle chính luôn nằm sẵn trong bộ nhớ). Tệp kê khai là thứ khiến 404 rẻ: đường dẫn không có trong danh sách thì trả lời không luôn, không cần hỏi bucket. Nếu client chấp nhận Brotli, nó đọc tệp .br song sinh thay thế và đặt header mã hóa tương ứng. Tài nguyên tĩnh đi ra với header cache immutable một năm, vì tên tệp đã gắn hash theo nội dung. Những gì suy ra từ danh sách tệp, chẳng hạn bảng ánh xạ route sang trang dựng sẵn, cũng được đệm theo phiên bản, nên một bản triển khai mới sẽ dựng lại chúng ở yêu cầu đầu tiên chứ không sớm hơn.
Rồi đến endpoint mà script triển khai thăm dò:
def web_version(request):
# bundle: the layer that reads web/current and the manifest
response = JsonResponse({"source": bundle.source(), "version": bundle.version()})
response["Cache-Control"] = "no-store"
return responseNó trả về bucket:<version> trên production, hoặc filesystem khi đang phục vụ từ image. Mỗi máy Fly chỉ trả lời cho chính nó, nên gọi chừng chục lần là biết cả cụm đã đồng bộ chưa. Đây cũng là cách nhanh nhất để xem một máy đang nghĩ cái gì là bản chạy khi có gì đó trông không ổn.
Xóa bộ nhớ đệm Cloudflare#
HTML trên trang được đệm ở biên của Cloudflare trong năm phút. Nếu không xóa, bản triển khai đã chạy trên máy nhưng hầu hết người dùng vẫn nhận trang cũ tới tận năm phút, thế thì mất hết ý nghĩa.
Việc xóa chỉ là một lời gọi API:
urllib.request.Request(
f"https://api.cloudflare.com/client/v4/zones/{zone}/purge_cache",
data=json.dumps({"hosts": ["example.com", "www.example.com"]}).encode(),
headers={"Authorization": f"Bearer {token}", "Content-Type": "application/json"},
)Tôi xóa theo host thay vì theo URL để khỏi phải liệt kê từng trang. Các tài nguyên tĩnh (asset) thì không cần xóa: tên tệp đã gắn hash theo nội dung, nên bản build mới trỏ tới tên tệp mới và các tệp cũ đơn giản là không còn được tham chiếu. Chỉ phần HTML tham chiếu tới chúng là cần làm mới.
Script đợi các máy trước khi xóa đệm là có chủ ý. Nếu xóa trước, Cloudflare có thể nạp lại bộ nhớ đệm từ một máy vẫn còn ở phiên bản cũ, và trang đó sẽ nằm ở biên thêm năm phút nữa.
Nếu xóa đệm thất bại, script in một cảnh báo rồi vẫn chạy cho xong. Bộ nhớ đệm tự hết hạn trong vòng năm phút, nên trường hợp xấu nhất là một lần phát hành chậm chứ không phải một lần phát hành hỏng. Tôi thà như vậy còn hơn để việc triển khai bị hủy ở bước cuối.
Kiểm tra một bản build trước khi lên sóng#
Chế độ không đổi con trỏ (no-flip) làm đến hết bước 3 rồi dừng. Phiên bản đã nằm trong bucket nhưng chưa có gì phục vụ nó. Để xem, tôi đặt một biến môi trường trên một máy để ghim máy đó vào bản build ấy, bất kể web/current nói gì. Khi thấy ổn, lệnh rollback sẽ đặt nó làm hiện tại. Lệnh tên là rollback nhưng thực chất là “trỏ current vào phiên bản này”, và tiến lên hay lùi lại đều là cùng một thao tác.
Quay lui#
Các phiên bản cũ vẫn nằm trong bucket, nên quay lui (rollback) là chạy đúng lệnh đó với một phiên bản trước, và một lệnh liệt kê cho thấy có những gì, mới nhất trước. Nó cũng đợi máy và xóa đệm y như một lần triển khai tiến lên. Tôi chưa cần dùng tới. Hiện chưa có gì dọn các phiên bản cũ; chúng nhỏ và tôi thà giữ còn hơn không.
Những gì vẫn như cũ#
API vẫn triển khai theo cách cũ, qua script triển khai riêng của nó, và nên như vậy: nó có trạng thái và là nơi migration chạy. Dockerfile cũng vẫn sao chép cả hai bản build giao diện vào image. Đó là chủ ý. Khi không cấu hình bucket (phát triển cục bộ, bộ kiểm thử) hoặc không đọc được bucket, lớp phục vụ tệp lùi về những thư mục đó trên đĩa, nên sự cố lưu trữ nghĩa là người dùng nhận được giao diện đi kèm image gần nhất thay vì một trang lỗi. Chỉ một biến môi trường là ép được hành vi đó trên production, nếu có lúc cần tạm gạt bucket ra khỏi luồng.
Giao diện thay đổi thường xuyên hơn API nhiều, và giờ mỗi lần phát hành mất khoảng một phút thay vì bảy. Tôi đã thôi dồn lại mà chẳng cần cố.