CHƯƠNG 2: YÊU CẦU CỦA HỆ THỐNG TRIỂN KHAI LIÊN TỤC
2.3 Yêu cầu về vận hành
Cơ sở hạ tầng được quản lý như mã (Infrastructure as code - IAC) là cách tiếp cận việc tự động hóa quản lý cơ sở hạ tầng dựa trên những kinh nghiệm từ quá trình phát triển phần mềm [12]. IAC nhấn mạnh vào tính nhất quán, lặp đi lặp lại đối với việc cung ứng và thay đổi các hệ thống cũng như cấu hình của chúng. Ý tưởng của IAC là người dùng sẽ viết và thực thi mã để định nghĩa, triển khai và cập nhật cơ sở hạ tầng. IAC thay đổi nhận thức của mọi người trong việc đối xử các hoạt động vận hành như là phần mềm, dù một số hoạt động thực tế liên quan tới phần cứng (ví dụ: cài đặt máy chủ triển khai).
Bằng việc ứng dụng IAC, không chỉ người quản trị, bất cứ ai cũng có thể đọc và hiểu về toàn bộ cấu hình hệ thống, có khả năng đảo ngược cấu hình về phiên bản chạy tốt bằng việc sử dụng hệ thống quản lí phiên bản. IAC cũng cho phép đánh giá, kiểm thử trước khi thực sự triển khai sự thay đổi về cơ sở hạ tầng.
Hệ thống quản lý cấu hình là một dạng công cụ IAC. Các hệ thống công nghệ thông tin thường xuyên thay đổi. Với mỗi bản phát hành, để hệ thống hoạt động được, người vận hành có thể cần thay đổi một số cấu hình nhất định. Trong hệ thống triển khai liên tục, tần suất triển khai cao có thể khiến cấu hình của cơ sở hạ tầng ngày một khác biệt so với trạng thái ban đầu, trở nên khó quản lý và lộn xộn. Nhằm tránh tình trạng không nhất quán này, cần có một hệ thống quản lý cấu hình phù hợp.
2.3.2 Thu thập và lưu trữ log
Thu thập và lưu trữ log là yêu cầu cơ bản đối với bất cứ hệ thống phần mềm thực tế nào [13].
Trong một hệ thống vi dịch vụ dựa vào container, các container sẽ được triển khai trong một cluster gồm nhiều máy. Với mỗi máy, ngoài các container còn có những dịch vụ khác đang chạy. Các ứng dụng sẽ sản sinh ra các tệp log với định dạng, vị trí khác nhau, khiến cho việc quản lý và sử dụng log trở nên khó khăn [14] (Hình 2.3).
Hình 2.3: Cách thức thu thập log trước đây
Cần có cơ chế để thu thập toàn bộ log cho tất cả các ứng dụng hay container này, đồng thời cho phép người dùng sử dụng chúng một cách hiệu quả: ví dụ như việc sau khi thu thập, sẽ có quá trình phân loại log, đánh chỉ số và cho phép người dùng tìm kiếm trên một giao diện phù hợp.
2.3.3 Giám sát và thông báo lỗi
Các nền tảng điều phối container có cơ chế giám sát để đảm bảo các dịch vụ hoạt động bình thường và có phương pháp sửa lỗi nếu phát hiện vấn đề. Tuy nhiên, cơ chế cung cấp bởi nền tảng điều phối container thường chỉ ở mức cơ bản.
Ví dụ: các dịch vụ cung cấp một API luôn trả lại mã trạng thái 200 (HTTP CODE), thành phần giám sát trong điều phối container sẽ gửi yêu cầu tới API này một cách định kỳ, nếu kết quả trả lại khác 200 thì thành phần giám sát sẽ thông báo tới bộ lập lịch để tắt và bật lại dịch vụ đó.
Trên thực tế, các dịch vụ thường chứa logic nghiệp vụ phức tạp, mỗi một dịch vụ lại có yêu cầu và các tham số giám sát riêng. Cần có cơ chế để các nhà phát triển có thể tùy biến các tham số cần giám sát, có công cụ trực quan để đội vận hành theo dõi và các phương thức tự động thông báo nếu có lỗi xảy ra.
2.3.4 Triển khai không bị gián đoạn và có khả năng đảo ngược phiên bản
Hệ thống triển khai liên tục cần có khả năng đảo ngược phiên bản triển khai một cách dễ dàng. Điều này giúp giảm áp lực trong việc triển khai và khuyến khich mọi người triển khai thường xuyên hơn để đẩy tính năng mới người dùng một cách nhanh chóng.
Ngoài ra, hệ thống phải cho phép cập nhật phiên bản mới của ứng dụng mà không có thời gian ngừng hoạt động để đảm bảo tính liên tục. Một kỹ thuật thường được sử dụng là triển khai dạng blue-green: chạy hai bản sao giống hệt nhau của ứng dụng. Tại thời điểm ban đầu, cả hai bản sao được gọi là blue. Khi cần cập nhật, một trong hai bản sao sẽ được cập nhật trước và được gọi là green. Sau khi đảm bảo phiên bản green hoạt động tốt, phiên bản blue còn lại sẽ được thay thế bằng phiên bản green.
Ngược lại, nếu có vấn đề xảy ra, phiên bản green sẽ bị loại và phiên bản blue sẽ được triển khai lại. Ở lần cập nhật tiếp theo, một trong hai phiên bản green sẽ được thay bằng phiên bản mới được gọi là blue. Phương pháp này là một biến thể của mô hình triển khai không tùy biến có sử dụng reverse proxy đã giới thiệu trong chương 01.
2.3.5 Thiết kế mạng triển khai
Trong thực tế, các máy triển khai trong đám mây của một công ty/tổ chức thường nằm trong một VPC (Virtual Private Cloud) với dải mạng ảo riêng. Các máy trong VPC có thể kết nối ra ngoài Internet thông qua một thiết bị NAT hoặc Internet Gateway được cung cấp bởi nhà cung cấp dịch vụ đám mây. Tuy nhiên, chúng không thể được truy cập trực tiếp từ bên ngoài nếu không gắn các địa chỉ Public IP vào những máy này với những cấu hình định tuyến thích hợp, tạo liên kết VPN hay sử dụng các dạng cấu hình port-forwarding tại các bộ định tuyến.
Máy chủ triển khai thường được cài đặt tại ngay trong mạng nội bộ của công ty, do vậy ở điều kiện bình thường sẽ không thể kết nối tới tất cả các máy trong VPC, gây khó khăn cho việc triển khai tự động. Những phương pháp nêu trên đều có thể được áp dụng để giải quyết vấn đề này. Tuy nhiên, khi số lượng các máy trong VPC tăng lên, hoặc khi công ty muốn tạo ra nhiều VPC (chẳng hạn tạo ra nhiều môi trường để kiểm thử, đánh giá, mỗi môi trường được triển khai trên một VPC) thì những cách kết nối này đều có các hạn chế nhất định. Do vậy, thiết kế hệ thống triển khai liên tục cần tìm ra giải pháp đề giải quyết được yêu cầu này.