Ghi lần triển khai đám mây đầu thành quy trình

Lần triển khai đám mây đầu tiên dễ học được nhiều hơn khi bạn ghi thành quy trình người khác có thể làm theo. Tôi muốn sổ ghi giải thích bản dựng đầu vào, nguồn cấu hình, cách xác minh và đường phục hồi. Một trang lệnh sao chép có thể tái tạo hoạt động mà vẫn để mô hình triển khai không rõ ràng.

Dùng dịch vụ xem trước giả định hiển thị danh mục nhỏ từ dữ liệu hư cấu. Môi trường không có lưu lượng khách hàng thật. Nhờ đó bài tập đầu tập trung vào cách mã trở thành ứng dụng đang chạy và cách nhận ra kết quả khác phiên bản dự định.

Ghi đầu vào triển khai

Bắt đầu từ phiên bản mã nguồn hoặc bản dựng. Viết phiên bản định triển khai và cách tạo bản dựng. Nếu nền tảng dựng từ mã nguồn, xác định lệnh dựng và tệp khóa phụ thuộc. Nếu nhận bản dựng có sẵn, xác định chính bản đó cùng các giả định dùng lúc tạo.

Cấu hình là đầu vào riêng. Liệt kê tên và mục đích thiết lập bắt buộc mà không đưa giá trị bí mật vào sổ. Phân biệt giá trị lúc dựng với giá trị lúc chạy. Giá trị frontend công khai đã được nhúng khi dựng không thể đổi chỉ bằng sửa môi trường lúc chạy của máy chủ về sau.

Khung AWS Well-Architected coi vận hành, bảo mật và độ tin cậy là các mối quan tâm thiết kế cùng hiệu năng và chi phí. Những câu hỏi đó hữu ích cho lần triển khai đầu dù dùng nhà cung cấp khác. Bài tập cần dạy điều gì vận hành ứng dụng, không chỉ vị trí nút Deploy.

Mô tả ranh giới môi trường

Ghi tài nguyên nào thuộc môi trường xem trước: dịch vụ, nơi lưu và danh tính nó dùng. Bản xem trước không nên âm thầm trỏ tới dữ liệu sản xuất vì biến sao chép còn giữ đích cũ.

Đầu vào	Điều sổ ghi lưu lại
Phiên bản ứng dụng	Phiên bản mã nguồn hoặc định danh bản dựng bất biến
Cấu hình	Tên thiết lập, mục đích và nơi cung cấp giá trị
Dữ liệu	Bộ dữ liệu hư cấu và nơi lưu dự định
Danh tính	Danh tính dịch vụ và hành động cần thực hiện
Điểm cuối công khai	Tuyến mong đợi và yêu cầu xác minh vô hại

Bảng chủ ý không chứa thông tin xác thực. Người đọc cần biết cấu hình được cấp phép được cung cấp thế nào, không cần nhận bí mật trong quy trình. Hướng dẫn bảo mật IAM khuyến nghị những cách như thông tin xác thực tạm thời và quyền tối thiểu trên AWS; dùng mô hình danh tính tương ứng của nền tảng bạn chọn.

Mở ảnh kích thước đầy đủ ↗

Nhánh phục hồi cần có trong sổ trước lần phát hành thất bại đầu tiên. Xác định thế nào là phiên bản hoạt động dễ hơn khi môi trường hiện tại vẫn khỏe.

Xác minh hành vi, không chỉ trạng thái nền tảng

Nền tảng có thể báo triển khai thành công trong khi ứng dụng dùng sai nguồn dữ liệu hoặc phục vụ tuyến không mong đợi. Với danh mục, mở trang và kiểm tra một mục hư cấu đã biết cùng tuyến chi tiết của nó. Phép kiểm tra này xác nhận tuyến và bộ dữ liệu đó; hai bản dựng vẫn có thể trả về cùng một phản hồi.

Xác minh riêng định danh bản dựng bất biến qua thông tin triển khai đáng tin cậy của nền tảng hoặc dấu phiên bản gắn với chính bản dựng đó. So sánh với định danh bản dựng dự định đã ghi trong sổ. Phép kiểm tra hành vi thành công và định danh bản dựng khớp nhau trả lời hai câu hỏi khác nhau, nên cần ghi cả hai kết quả.

Cũng xem bằng chứng khởi động hoặc yêu cầu của chính ứng dụng. Xác nhận cấu hình cần thiết hiện diện mà không in giá trị. Nếu có nơi lưu, kiểm tra ứng dụng dùng đích xem trước và danh tính dịch vụ làm được thao tác dự định.

Ghi mỗi phép kiểm tra xác lập điều gì. Tải trang thành công chứng minh tuyến đó trong môi trường ấy. Nó không chứng minh mọi thao tác cơ sở dữ liệu, quy tắc truy cập hay đường lỗi. Sổ chính xác giữ các giới hạn để người đọc sau không hiểu “đã xác minh triển khai” là cam kết không giới hạn.

Diễn tập một lần phát hành lỗi

Tạo lỗi có kiểm soát trong môi trường xem trước tách biệt, như giá trị cấu hình không bí mật nhưng không hợp lệ khiến ứng dụng không khởi động. Dự đoán nền tảng và ứng dụng biểu lộ lỗi thế nào. Sau đó dùng cơ chế phục hồi đã ghi để trở lại bản dựng và cấu hình biết là hoạt động.

Đây là diễn tập được đề xuất cho đến khi thực sự chạy. Khi đã làm, ghi tín hiệu quan sát và kết quả phục hồi. Nếu quay lui đổi mã nhưng giữ cấu hình, khác biệt đó cần nằm trong quy trình. Bản dựng trước vẫn có thể lỗi khi ghép với thiết lập sai.

Thay đổi dữ liệu làm phục hồi khó hơn. Bài đầu có thể tránh đổi lược đồ để hiểu triển khai ứng dụng riêng. Khi lần phát hành sau đổi dữ liệu, mở rộng quy trình về tương thích và phục hồi thay vì mặc định bản dựng cũ đọc được mọi trạng thái mới.

Giữ sổ hữu ích sau thành công đầu tiên

Bỏ chi tiết ngẫu nhiên chỉ có ý nghĩa lúc thiết lập, như đường dẫn terminal tạm, và giữ giả định ảnh hưởng lần triển khai tiếp theo. Ghi bước nào tự động, bước nào vẫn cần quyết định. Nếu dễ quên thao tác thủ công, mô tả hậu quả và cân nhắc tự động hóa khi luồng đã ổn định.

Đổi lại là công bảo trì: quy trình không còn theo hệ thống đã triển khai sẽ gây hiểu nhầm. Xem lại khi cách dựng, danh tính hoặc bố trí tài nguyên thay đổi. Kiểm tra cuối hữu ích là để người khác làm theo sổ trong môi trường xem trước và chỉ ra chỗ họ phải đoán.

Ghi lần phát hành như một tổ hợp đầu vào

Gán ba nhãn cho lần chạy tốt đầu của bài tập: bản dựng A, cấu hình lúc chạy C1 và dữ liệu D1. Đây là định danh minh họa, không phải mã băm bản dựng thật. Khi diễn tập, sổ cần nối định danh thật tương ứng với kết quả xác minh. Tên nhánh có thể thay đổi; định danh bản dựng bất biến giúp người sau tìm đúng thứ đã triển khai.

Tiếp theo đề xuất bản phát hành B với cấu hình C2. Giả sử C2 chỉ tới backend danh mục không hợp lệ nên dịch vụ không tải được dữ liệu. Trở lại bản dựng A nhưng giữ C2 có thể giữ nguyên lỗi. Hành động phục hồi phải nêu đầu vào nào trở lại tổ hợp biết là hoạt động, không chỉ gọi tên phiên bản mã nguồn trước.

Tổ hợp diễn tập	Cách hiểu mong đợi
A + C1 + D1	Mốc hoạt động đã biết sau khi xác minh
B + C2 + D1	Cấu hình backend cố ý không hợp lệ
A + C2 + D1	Chỉ quay mã vẫn giữ đầu vào sai
A + C1 + D1 sau phục hồi	Phải kiểm tra lại mốc ban đầu

Hàng cuối là quan sát mới, không phải bằng chứng thừa kế từ thành công trước. Đích dữ liệu, tuyến hoặc danh tính đang chạy có thể đổi trong quá trình phục hồi. Giữ cùng các trường hợp xác minh vô hại để so sánh trước và sau có ý nghĩa.

Mở ảnh kích thước đầy đủ ↗

Tách cấu hình nhúng sẵn khỏi cấu hình lúc chạy

Hướng dẫn môi trường của Vite giải thích các hằng mà Vite cung cấp được thay lúc dựng, và giá trị của các biến có tiền tố VITE_ có thể nằm trong mã máy khách. Tài liệu cũng nêu thứ tự ưu tiên giữa tệp theo chế độ và biến môi trường đã có khi Vite chạy. Chi tiết đó giải thích vì sao sửa tệp .env thuận tay có thể không đổi frontend đang phục vụ.

Với bài danh mục, giả sử URL gốc của API được nhúng vào gói mã trình duyệt. Đổi thiết lập lúc chạy của backend không viết lại gói đó. Quy trình cần dựng lại frontend với giá trị công khai dự định rồi triển khai bản dựng mới. Nếu ứng dụng lấy cấu hình qua điểm cuối lúc chạy, ghi hợp đồng khác ấy và xác minh trình duyệt nhận gì.

Ghi tên cấu hình, giai đoạn sử dụng và nguồn có quyền quyết định giá trị. Đừng chép toàn bộ môi trường vào sổ. Hằng dựng công khai và thông tin xác thực máy chủ có quy tắc lộ dữ liệu khác nhau; tên biến không chứng minh giá trị an toàn để công bố.

Xác định lúc nào lần phát hành được đi tiếp

Chương Canarying Releases của Google SRE Workbook mô tả canary là triển khai một phần trong thời gian giới hạn, được đánh giá trước khi tiếp tục. Nó cần cách chọn nhóm nhận thay đổi, quy trình đánh giá và tích hợp với quy trình phát hành. Môi trường xem trước không có lưu lượng đại diện không tự cung cấp các bảo đảm ấy.

Với sổ đầu tiên, lấy bài học đơn giản hơn: nêu bằng chứng cần có trước khi coi lần phát hành xem trước thành công, cùng hành động khi thiếu bằng chứng. Trang danh mục trả 200 nhưng hiện sai dữ liệu hư cấu sẽ không đạt phép kiểm tra đã chọn. Lỗi trạng thái phát hành trên nền tảng cần điều tra dù một trang lưu đệm vẫn mở được.

Khi ứng dụng sau này cần phát hành sản xuất dần dần, mở rộng quy trình bằng so sánh đại diện, khoảng quan sát và điều kiện dừng. Đừng đổi tên một yêu cầu xem trước thành công thành đánh giá canary. Kết quả học tập hữu ích là quy trình có lời khẳng định phù hợp môi trường và hướng dẫn phục hồi có thể diễn tập với cùng đầu vào.