XÂY DỰNG KIẾN TRÚC TRIỂN KHAI LIÊN TỤC CHO CÁC HỆ THỐNG DỰA TRÊN VI DỊCH VỤ

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ NGUYỄN TRỌNG HIẾU XÂY DỰNG KIẾN TRÚC TRIỂN KHAI LIÊN TỤC CHO CÁC HỆ THỐNG DỰA TRÊN VI DỊCH VỤ LUẬN VĂN THẠC SĨ KỸ THUẬT PHẦN MỀM HÀ NỘI - 2018 ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ NGUYỄN TRỌNG HIẾU XÂY DỰNG KIẾN TRÚC TRIỂN KHAI LIÊN TỤC CHO CÁC HỆ THỐNG DỰA TRÊN VI DỊCH VỤ Ngành: Công nghệ thông tin Chuyên ngành: Kỹ thuật phần mềm Mã số: 60480103 LUẬN VĂN THẠC SĨ KỸ THUẬT PHẦN MỀM HÀ NỘI - 2018 MỤC LỤC MỞ ĐẦU CHƯƠNG 1: KIẾN THỨC CƠ BẢN -4 1.1 Tính tốn đám mây 1.1.1 Giới thiệu tính tốn đám mây -4 1.1.2 Sự phổ biến ứng dụng dựa vào đám mây -4 1.2 Tích hợp, chuyển giao triển khai liên tục -4 1.2.1 Tích hợp liên tục 1.2.2 Chuyển giao liên tục -5 1.2.3 Triển khai liên tục 1.3 Kiến trúc hệ thống -5 1.3.1 Kiến trúc khối 1.3.2 Kiến trúc hướng dịch vụ (Service-Oriented Architecture) 1.3.3 Kiến trúc vi dịch vụ 1.4 Các mơ hình triển khai -7 1.4.1 Mơ hình triển khai tùy biến -7 1.4.2 Mơ hình khơng tùy biến kết hợp với Reverse Proxy -8 1.4.3 Mơ hình khơng tùy biến với ứng dụng vi dịch vụ 1.5 Khái niệm Container 1.6 Tổng kết -9 CHƯƠNG 2: YÊU CẦU CỦA HỆ THỐNG TRIỂN KHAI LIÊN TỤC - 10 2.1 Yêu cầu điều phối container - 10 2.1.1 Khám phá dịch vụ 10 2.1.2 Bộ lập lịch - 10 2.1.3 Điều phối container 10 2.2 Yêu cầu cho nhà phát triển - 11 2.2.1 Khả tự triển khai - 11 2.2.2 Nhận thông tin kết build - 11 2.3 Yêu cầu vận hành 11 2.3.1 Quản lý cấu hình 11 2.3.2 Thu thập lưu trữ log 11 2.3.3 Giám sát thông báo lỗi - 12 2.3.4 Có khả đảo ngược phiên triển khai (rollback) 12 2.3.5 Triển khai khơng có thời gian ngừng hoạt động (no-downtime deployment) - 12 2.3.6 Thiết kế mạng triển khai - 12 CHƯƠNG 3: THIẾT KẾ 13 3.1 Luồng triển khai 13 3.2 Phân tích lựa chọn cơng nghệ - 14 3.2.1 Hệ thống quản lý mã nguồn - 14 3.2.2 Máy chủ CI máy chủ triển khai - 14 3.2.3 Công nghệ container - 15 3.2.4 Nền tảng điều phối container - 15 3.2.5 Kênh thông báo - 15 3.2.6 Hệ thống thu thập quản lý log - 15 3.2.7 Công nghệ giám sát hệ thống cảnh báo 16 3.2.8 Giải pháp quản lý cấu hình 16 3.3 Luồng triển khai liên tục hoàn thiện - 17 CHƯƠNG 4: CÀI ĐẶT VÀ ĐÁNH GIÁ - 20 4.1 Cài đặt - 20 4.1.1 Hệ thống vi dịch vụ mẫu - 20 4.1.2 Cách thức tổ chức mã nguồn trình build ảnh docker 20 4.1.3 Cài đặt môi trường sản phẩm - 21 4.2 Đánh giá kết - 24 KẾT LUẬN - 26 MỞ ĐẦU Trong thập kỉ qua, chứng kiến nhiều thay đổi cách mà tổ chức phát triển chuyển giao phần mềm, đặc biệt tốc độ chất lượng chuyển giao Trước đây, mơ hình phát triển phần mềm phổ biến mơ hình thác nước, việc phát triển chia làm nhiều giai đoạn từ việc lập kế hoạch, phân tích yêu cầu, thiết kế hệ thống, cài đặt, kiểm thử, triển khai bảo trì Tuy nhiên, tỉ lệ thành cơng dự án phát triển phần mềm theo mô hình thác nước thấp Một lí phổ biến yêu cầu hệ thống khảo sát sử dụng để xây dựng phần mềm từ đầu dự án khơng xác có thiếu sót: có yêu cầu sinh người sử dụng thực dùng phần mềm Những phương pháp xây dựng phần mềm linh hoạt (agile) phát minh để khắc phục điểm yếu mơ hình thác nước Thay để người dùng phải chờ đợi tháng hay năm cho lần phát hành, tổ chức liên tục cập nhật phần mềm cho người sử dụng (thường tháng), thu thập phản hồi, sửa đổi hay bổ sung thêm yêu cầu để cải tiến phần mềm cho lần cập nhật sau Vấn đề phát triển phần mềm cải thiện đáng kể, nhiên vấn đề lại nảy sinh: công việc liên quan tới vận hành cũ khơng theo kịp tốc độ phát triển phần mềm: nhà phát triển muốn phát hành cập nhật nhanh để lấy phản hồi từ người sử dụng, qúa trình từ build tới sản phẩm triển khai thành công nhiều thời gian Các khái niệm tích hợp, chuyển giao triển khai liên tục giới thiệu với kinh nghiệm thực tiễn giúp giải vấn đề nêu Tuy nhiên, giới hạn công nghệ, mục tiêu triển khai liên tục chưa đạt vào thời điểm mà giới thiệu: triển khai đòi hỏi phần cứng, mà việc chuẩn bị phần cứng nhiều thời gian (mua bán, cài đặt, quản lý, ) Với phát triển Internet xuất tính tốn đám mây, ứng dụng khơng bị bó buộc vào sở hạ tầng vật lý mà triển khai tảng đám mây Những ứng dụng sử dụng tài nguyên co dãn đám mây để mở rộng, thu hẹp tùy vào nhu cầu sử dụng Những ứng dụng gọi ứng dụng dựa vào đám mây Kiến trúc hệ thống phần mềm tiến hóa để sử dụng lợi ích mà tảng đám mây mang lại Trước đây, dụng máy chủ (server-side application) truyền thống thường xây dựng kiến trúc gồm nhiều lớp, với lớp chứa loại thành phần khác nhau, ví dụ như: • Lớp giao diện: chịu trách nhiệm xử lý yêu cầu HTTP trả lại kết giao diện HTML liệu dạng JSON/XML tới người dùng • Lớp logic nghiệp vụ: chịu trách nhiệm tính tốn xử lý liệu thơ sang liệu có ý nghĩa theo nghiệp vụ định • Lớp truy xuất liệu: cửa ngõ để truy cập vào sở liệu lớp khác Lớp truy xuất liệu cung cấp giao diện (API) khối cho lớp khác, độc lập với sở liệu sử dụng (MySQL, PostgresSQL, …) Những ứng dụng sử dụng kiến trúc thường đóng gói triển khai khối thống Những ứng dụng gọi ứng dụng khối (monolith) Ứng dụng khối có ưu điểm dễ phát triển, kiểm thử triển khai; nhiên tất thành phần (module) đóng vào gói, ứng dụng ngày trở nên lớn phức tạp, khiến việc hiểu sửa đổi ứng dụng khó khăn Kích cỡ ứng dụng làm chậm trình khởi động Mỗi có cập nhật tồn ứng dụng cần phải triển khai lại, dẫn đến việc triển khai liên tục trở nên khó khăn Việc scale ứng dụng đòi hỏi nhiều tài nguyên phức tạp Ngoài ra, lỗi module hồn tồn khiến cho ứng dụng khối bị sập Khi muốn thay đổi công nghệ có ứng dụng cần phải phát triển lại, gây lãng phí thời gian tiền bạc Kiến trúc vi dịch vụ (microservice) sinh để giải vấn đề Ý tưởng kiến trúc chia ứng dụng dịch vụ nhỏ hơn, hoàn toàn riêng biệt với giao tiếp với thơng qua API Ví dụ: dịch vụ liên quan tới nghiệp vụ phát triển riêng, cung cấp API cho dịch vụ khác Những thành phần giao diện người dùng tách dịch vụ, chúng giao tiếp với dịch vụ nghiệp vụ để lấy liệu cần thiết hiển thị lên cho người dùng Kiến trúc vi dịch vụ giải vấn đề mà ứng dụng khối gặp phải: • Việc chia ứng dụng thành dịch vụ nhỏ cho phép dịch vụ phát triển kiểm thử nhanh chóng, độc lập Mỗi đội giao phát triển một vài dịch vụ ứng dụng, cách biệt với dịch vụ khác Điều khiến mã nguồn trở nên nhỏ hơn, dễ hiểu quản lý • Mỗi dịch vụ nhỏ ứng dụng triển khai độc lập đội • Do dịch vụ ứng dụng giao tiếp với thơng qua API, dịch vụ sử dụng công nghệ riêng Điều giúp việc cập nhật cơng nghệ cho tồn ứng dụng trở nên dễ dàng (cập nhật lần lượt) • Tích hợp liên tục trở nên khả thi việc triển khai dịch vụ độc lập với dịch vụ khác • Mở rộng (scale) ứng dụng trở nên đơn giản nhanh chóng, việc scale ứng dụng phân nhỏ thành scale dịch vụ Kiến trúc vi dịch vụ thường sử dụng với công nghệ container Mỗi ảnh container đóng gói ứng dụng kèm thư viện cần thiết để ứng dụng chạy Container sử dụng nhân chung với nhân hệ điều hành nên nhẹ nhiều so với cơng nghệ máy ảo Ngồi ra, container giúp cho ứng dụng chạy môi trường, hỗ trợ tốt việc triển khai dịch vụ kiến trúc vi dịch vụ Cùng với tảng đám mây, kiến trúc vi dịch vụ công nghệ container giúp cho ý tưởng việc triển khai liên tục trở nên ngày thực tế Tuy nhiên, vấn đề gặp phải kiến trúc vi dịch vụ sử dụng container số lượng dịch vụ tăng lên, việc quản lý phối hợp dịch vụ trở nên khó nhiều lần so với ứng dụng khối Ngoài ra, việc giám sát nhiều dịch vụ phức tạp so với cách triển khai truyền thống; có lỗi xảy việc xem log sửa lỗi gây khó khăn định cho đội phát triển Với thực trạng vậy, luận văn đề xuất giải pháp để giải vấn đề trên, từ đảm bảo việc tích hợp, triển khai liên tục cho trình phát triển phần mềm Luận văn bao gồm 04 chương với nội dung chương phân bố sau: • Chương 1: Giới thiệu khái niệm liên quan tới tính tốn đám mây, tích hợp triển khai liên tục, kiến trúc hệ thống phần mềm công nghệ container • Chương 2: Phân tích yêu cầu để xây dựng mơ hình triển khai liên tục cho cho hệ thống vi dịch vụ sử dụng container • Chương 3: Trình bày thiết kế • Chương 4: Cài đặt đánh giá • Kết luận: Kết luận hướng nghiên cứu dự định tương lai CHƯƠNG 1: KIẾN THỨC CƠ BẢN 1.1 Tính tốn đám mây 1.1.1 Giới thiệu tính tốn đám mây Tính tốn đám mây cung cấp, phân phối sức mạnh tính tốn, hệ thống lưu trữ, ứng dụng nguồn tài nguyên công nghệ thông tin khác thông qua tảng đám mây, sử dụng kênh truyền internet giá tính tốn dựa vào khối lượng sử dụng Sử dụng tính tốn đám mây, cơng ty hay tổ chức khơng cần đầu tư nhiều chi phí ban đầu vào việc chuẩn bị thiết bị phần cứng, hay dành nhiều thời gian để quản lý chúng Thay vào đó, công ty/tổ chức cần cung cấp yêu cầu chủng loại kích thước nguồn tài nguyên tính toán cho nhà cung cấp dịch vụ, thứ cung ứng gần Các dịch vụ đám mây gần suốt với người dùng, với giao diện người dùng đơn giản, hầu hết dịch vụ đám mây đòi hỏi kiến thức quản trị Tính tốn đám mây chia thành mơ hình bản: sở hạ tầng dịch vụ(Infrastructure as a service – IaaS), tảng dịch vụ(Platform as a service – PaaS), phần mềm dịch vụ(Software as a service – SaaS) 1.1.2 Sự phổ biến ứng dụng dựa vào đám mây Việc chuyển đổi sang đám mây phát triển tự nhiên việc cung ứng dịch vụ công nghệ thông tin Nền tảng đám mây cung cấp môi trường với tài nguyên đa dạng, từ tính tốn, lưu trữ mạng, có khả co dãn, linh động theo nhu cầu sử dụng Ngày nhiều công ty, tổ chức chuyển dần sang phát triển phần mềm, ứng dụng cho tảng đám mây thay cách phát triển truyền thống đặc điểm bật đám mây như: tốc độ triển khai nhanh, khả cô lập lỗi tốt, tính co dãn (scale) 1.2 Tích hợp, chuyển giao triển khai liên tục 1.2.1 Tích hợp liên tục Tích hợp liên tục q trình tự động hóa việc dịch (build) kiểm thử mã thành viên đội cập nhật mã lên hệ thống quản lý phiên (tích hợp liên tục đòi hỏi nhà phát triển phải tích hợp mã vào kho chứa mã nhất) Tích hợp liên tục khuyến khích nhà phát triển chia sẻ mã kiểm thử đơn vị (unit test) việc hợp thay đổi máy lên kho quản lý mã chung hoàn thiện tác vụ nhỏ Từ yêu cầu hợp nhất, máy chủ kích hoạt luồng (pipeline): lấy mã máy chủ CI, chạy q trình dịch, kiểm thử, … Nếu có lỗi xảy phần luồng, sửa lỗi việc ưu tiên hàng đầu Với cơng ty, tổ chức, pipeline tích hợp xác định tùy thuộc vào công cụ sử dụng, ngôn ngữ lập trình nhiều yếu tố khác, nhiên luồng thực hiên bao gồm: 4 Đẩy mã lên kho chứa mã chung Phân tích tĩnh Kiểm thử trước triển khai Đóng gói triển khai lên mơi trường kiểm thử Kiểm thử sau triển khai 1.2.2 Chuyển giao liên tục Về bản, luồng chuyển giao liên tục bao gồm bước giống luồng tích hợp liên tục liệt kê phần trước Điểm khác biệt lớn là: bước "5 Kiểm thử sau triển khai" tích hợp liên tục thường đòi hỏi việc can thiệp tay Các dịch không vượt qua kiểm tra bước bị loại Còn Chuyển giao liên tục, có chế để tự động hóa bước Kết cuối dịch mà sẵn sàng để triển khai môi trường sản phẩm thực tế 1.2.3 Triển khai liên tục Triển khai liên tục mục tiêu cuối chuỗi tự động hóa Bản dịch cuối sau bước chuyển giao liên tục dịch sẵn sàng để triển khai vào môi trường thực tế, nhiên việc triển khai hay không chọn phiên để triển khai lại phụ thuộc vào định đội vận hành Trong triển khai liên tục, dịch vượt qua tất kiểm thử triển khai tự động lên môi trường sản phẩm thực tế Khơng có can thiệp người qúa trình 1.3 Kiến trúc hệ thống Trong năm gần đây, kiến trúc phần mềm web phát triển với tốc độ nhanh chóng Với phổ biến dịch vụ Internet, thấy chuyển dịch từ kiến trúc khối theo tầng/lớp, sang kiến trúc hướng dịch vụ kiến trúc vi dịch vụ Việc lựa chọn kiến trúc phần mềm cụ thể phụ thuộc hoàn toàn vào yêu cầu về: khả co dãn (scale), độ phức tạp, khả triển khai, Đối với ứng dụng web, khả scale yếu tố quan trọng hàng đầu 1.3.1 Kiến trúc khối Kiến trúc khối thường gộp tính thiết yếu lại, từ phát triển triển khai khối Trong kiến trúc khối, cách thiết kế phổ biến phân chia thành phần theo dạng module theo lớp Ví dụ: phân chia thành lớp giao diện người dùng, tới lớp logic nghiệp vụ, lớp truy cập sở liệu cuối lớp tích hợp để tích hợp với dịch vụ ngồi Ưu điểm kiến trúc là: • Đơn giản cho việc phát triển • Đơn giản cho việc kiểm thử • Đơn giản cho việc triển khai • Đơn giản việc scale theo chiều ngang 2.3.3 Giám sát thông báo lỗi Các tảng điều phối container có chế giám sát để đảm bảo dịch vụ hoạt động bình thường có phương pháp sửa lỗi phát vấn đề Tuy nhiên, chế cung cấp tảng điều phối container thường mức Trên thực tế, dịch vụ thường chứa logic nghiệp vụ phức tạp, dịch vụ lại có yêu cầu tham số giám sát riêng Cần có chế để nhà phát triển tùy biến tham số cần giám sát, có cơng cụ trực quan để đội vận hành theo dõi phương thức tự động thông báo có lỗi xảy 2.3.4 Có khả đảo ngược phiên triển khai (rollback) Hệ thống triển khai liên tục cần có khả đảo ngược phiên triển khai cách dễ dàng Điều giúp giảm áp lực việc triển khai khuyến khich người triển khai thường xuyên để đẩy tính người dùng cách nhanh chóng 2.3.5 Triển khai khơng có thời gian ngừng hoạt động (no-downtime deployment) Hệ thống phải cho phép cập nhật phiên ứ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 sử dụng triển khai dạng blue-green: chạy hai giống hệt ứng dụng Tại thời điểm ban đầu, hai gọi blue Khi cần cập nhật, hai cập nhật trước gọi green Sau đảm bảo phiên green hoạt động tốt, phiên blue lại thay phiên green Ngược lại, có vấn đề xảy ra, phiên green bị loại phiên blue triển khai lại Ở lần cập nhật tiếp theo, hai phiên green thay phiên gọi blue Phương pháp biến thể mơ hình triển khai khơng tùy biến có sử dụng reverse proxy giới thiệu chương 01 2.3.6 Thiết kế mạng triển khai Trong thực tế, máy triển khai đám mây công ty/tổ chức thường nằm VPC (Virtual Private Cloud) với dải mạng ảo riêng Các máy VPC kết nối ngồi Internet thông qua thiết bị NAT Internet Gateway cung cấp nhà cung cấp dịch vụ đám mây Tuy nhiên, chúng truy cập trực tiếp từ bên ngồi khơng gắn địa Public IP vào máy với cấu hình định tuyến thích hợp, tạo liên kết VPN hay sử dụng dạng cấu hình port-forwarding router Máy chủ triển khai thường cài đặt mạng nội công ty, điều kiện bình thường khơng thể kết nối tới tất máy VPC, gây khó khăn cho việc triển khai tự động Những phương pháp nêu áp dụng để giải vấn đề Tuy nhiên, số lượng máy VPC tăng lên, công ty muốn tạo nhiều VPC (chẳng hạn tạo nhiều môi trường để kiểm thử, đánh giá, môi trường triển khai VPC) cách kết nối có hạn chế định Do vậy, thiết kế hệ thống triển khai liên tục cần tìm giải pháp đề giải yêu cầu 12 CHƯƠNG 3: THIẾT KẾ 3.1 Luồng triển khai Hình 3.1: Luồng triển khai liên tục Hình 3.1 thể thiết kế luồng triển khai liên tục cho hệ thống vi dịch vụ sử dụng container, hoạt động thành phần cụ thể sau: Lập trình viên đẩy mã lên kho chứa mã chung (Repository) Kho chứa mã nhận biết có thay đổi mã, kích hoạt máy chủ CI để build mã vừa cập nhật Khi mã build xong, máy chủ đóng gói build theo dạng ảnh container Các chế kiểm thử tự động dùng trình để đảm bảo mã khơng có lỗi 13 Nếu build thất bại, tồn q trình bị dừng lại Ngược lại, máy chủ đẩy build lên kho chứa chung dùng để triển khai Kết build thành cơng hay thất bại có thơng báo gửi tới nhà phát triển thông qua kênh giao tiếp chung công ty Sau build đẩy lên kho chứa, máy chủ CI kích hoạt máy chủ triển khai để triển khai build lên mơi trường sản phẩm Q trình triển khai cần đảm bảo khơng có thời gian ngừng hoạt động suốt với người sử dụng Việc lựa chọn máy để triển khai giao tiếp container máy tảng điều phối container quản lý Các build triển khai môi trường sản phẩm hệ thống giám sát kiểm tra thường xuyên Nếu có vấn đề xảy ra, hệ thống giám sát gửi thông báo tới thành phần cảnh báo Thành phần cảnh báo có trách nhiệm gửi thông báo lỗi tới nhà phát triển thông qua kênh giao tiếp Hệ thống quản lý log liên tục thu thập log từ dịch vụ triển khai, lưu trữ log vào hệ thống lưu trữ cho phép người dùng truy cập, tìm kiếm thơng tin log có lỗi xảy thơng qua giao diện người dùng 3.2 Phân tích lựa chọn công nghệ 3.2.1 Hệ thống quản lý mã nguồn Luận văn sử dụng Git làm hệ thống quản lý mã nguồn đặc điểm phân tán, khả hỗ trợ rẽ nhánh, làm việc nhóm hiệu phổ biến Mơ hình rẽ nhánh sử dụng sau: nhánh develop nhánh sử dụng cho việc phát hành Các nhà phát triển tạo nhánh cho tính mới, cho việc sửa lỗi hay vá Sau đảm bảo mã hoạt động tốt nhánh mới, nhà phát triển gửi yêu cầu hợp mã (merge request) vào nhánh develop Ngay yêu cầu tạo ra, Git sử dụng kỹ thuật Web Hook để kích hoạt q trình build với mã (pre-merge build) Kết trình build yêu cầu gửi cho người quản lý kho mã nguồn Người quản lý kho mã đánh giá yêu cầu chấp nhận hợp Ngay sau người quản lý chấp nhận, q trình build khác kích hoạt (post-merge build) Q trình đóng gói build vào ảnh container theo công nghệ container chọn, thực kiểm thử với ảnh đóng gói đẩy ảnh lên kho lưu trữ container khơng có lỗi xảy 3.2.2 Máy chủ CI máy chủ triển khai Máy chủ CI sử dụng Jenkins, phần mềm tự động hóa, mã nguồn mở viết Java Jenkins hỗ trợ hầu hết phần mềm quản lý mã nguồn Git, Subversion, Mercurial hỗ trợ mã lệnh nhiều loại ngôn ngữ script Bash, Python, Groovy, Gradle 14 3.2.3 Công nghệ container Mã nguồn sau hợp build hậu hợp đóng gói thành ảnh container lưu kho ảnh Luận văn sử dụng công nghệ container phổ biến Docker Docker sử dụng Dockerfile để miêu tả lớp ảnh, câu lệnh cần thực cho việc build ảnh container Nhằm đảm bảo tính quán việc tích hợp build ảnh container với mã nguồn, Dockerfile lưu trữ quản lý thư mục kho lưu trữ chung mã nguồn 3.2.4 Nền tảng điều phối container Hiện nay, với phổ biến công nghệ container, số lượng tảng điều phối container ngày tăng lên Trong đó, tảng phổ biến Amazon ECS, Azure Container Service, Goole Container Engine, Diego Cloud Foundry, Kubernetes, Docker Swarm, Mesosphere Marathon Tuy nhiên, hầu hết tảng điều phối thương mại cung cấp công ty điện toán đám mây, ngoại trừ Docker swarm, Mesosphere Marathon Kubernetes Luận văn tập trung hướng tới phân tích ba tảng Ba tảng điều phối cung cấp chức để quản lý container, nhiên độ phức tạp sử dụng, số lượng máy quản lý khả tùy biến tảng hoàn toàn khác nhau: Nền tảng < 10 máy ++ 10 - 100 máy + 100 – 1000 máy ? > 1000 máy ? Khả tùy biến + Tính dễ sử dụng +++ Docker swarm Mesphere Marathon Kubernetes + ++ ++ ++ ++ + ++ ++ + ? ++ ++ Bảng 3-1: So sánh Docker Swarm, Mesosphere Marathon Kubernetes Từ bảng so sánh trên, luận văn đề xuất sử dụng Kubernetes tảng điều phối container cho hệ thống triển khai liên tục 3.2.5 Kênh thông báo Kênh thông báo giúp tất bên liên quan cập nhật trạng thái luồng triển khai liên tục thường tích hợp vào kênh giao tiếp công ty email, phần mềm chat Việc lựa chọn kênh thông báo tùy thuộc đặc điểm nhu cầu công ty Trong luận văn, phần mềm Slack xem kênh giao tiếp sử dụng cho mục đích thông báo 3.2.6 Hệ thống thu thập quản lý log Cách thức thu thập log phổ biến cho cluster sử dụng log collector máy triển khai nhằm thực nhiệm vụ phân giải nội dung log thành trường thông tin gửi hệ thống lưu trữ Để cung cấp khả tìm kiếm nhanh cho người sử dụng, log thường lưu đánh số elasticsearch 15 Kibana, công cụ khám phá trực quan hỗ trợ phân tích liệu thời gian thực cho elasticsearch, sử dụng giao diện tìm kiếm log cho người dùng Như vậy, giải pháp quản lý log khác biệt thành phần log collector Trong giới mã nguồn mở, hai log collector phổ biến Logstash Fluentd, đại diện cho stack công nghệ ELK EFK Điểm khác biệt Logstash Fluentd thể bảng sau: Log collector Log stash Fluentd Phương pháp định tuyến log Dựa vào lệnh theo thuật toán Dựa vào thẻ Tầng giao vận Hiệu Cần triển khai với Redis để đảm bảo độ tin cậy Độ tin cậy tích hợp sẵn khó cấu hình Sử dụng nhiều nhớ Sử dụng Elastic Beats cho Sử dụng nhớ Dùng Fluent Bit Fluentd Forwarder cho Bảng 3-2: So sánh Logstash Fluentd Với hệ thống vi dịch vụ sử dụng container, số lượng container lớn với khối lượng chủng loại log khổng lồ Do sử dụng Fluentd giúp người vận hành cấu hình cách thức định tuyến log linh hoạt, đảm bảo độ tin cậy mà không cần cài đặt thêm dịch vụ ngồi tối ưu hóa tài ngun hiệu sử dụng 3.2.7 Công nghệ giám sát hệ thống cảnh báo Việc hiểu ứng dụng hoạt động triển khai yếu tố quan trọng để scale ứng dụng cung cấp dịch vụ đáng tin cậy Prometheus công cụ giám sát hệ thống phát triển SoundCloud xuất phần mềm mã nguồn mở Prometheus hoạt động cách thu thập (Prometheus sử dụng thuật ngữ scrape) mục tiêu, endpoints dạng key-value Prometheus sau lưu trữ thơng tin thu thập khung sở liệu theo thời gian (time series database), từ cho phép người dùng thực truy vấn đồ thị chức khác cảnh báo Prometheus cho phép nhà phát triển thu thập thông tin thư viện, dịch vụ cách tích hợp thư viện Prometheus vào mã nguồn để xây dựng thông tin (metrics) tùy biến Đối với thư viện với cách thức cung cấp thơng tin khác, Prometheus có exporter để chuyển đổi thông tin sang dạng thơng tin mà Prometheus sử dụng Ngồi ra, thân mã nguồn Prometheus cung cấp thành phần cảnh báo lỗi AlertManager, giúp gửi thông tin tới bên liên quan qua nhiều kênh giao tiếp khác Thơng tin mà Prometheus cung cấp thể trực quan qua phần mềm bên thứ ba Grafana Prometheus giúp đảm bảo mục đích đa dạng việc giám sát hệ thống vi dịch vụ gồm nhiều container 3.2.8 Giải pháp quản lý cấu hình Có nhiều giải pháp giúp quản lý cấu Chef, Puppet hay Ansible Các giải pháp hỗ trợ việc tự động hóa q trình cài đặt, cấu hình cho máy triển khai 16 phù hợp để tích hợp vào luồng triển khai liên tục Luận văn sử dụng Ansible đơn giản việc cài đặt cú pháp dễ hiểu, dễ viết 3.3 Luồng triển khai liên tục hồn thiện Với công nghệ chọn nêu phần trước, luận văn đề xuất xây dựng hệ thống triển khai liên tục hồn thiện sau (Hình 3.2): Như vậy, luồng triển khai liên tục hoàn thiện hoạt động chi tiết sau: Lập trình viên gửi yêu cầu hợp từ nhánh phụ sang nhánh develop Gitlab Dựa vào WebHooks, Gitlab kích hoạt trình build tiền hợp Jenkins Kết build gửi qua Slack cho tất bên liên quan Người quản lý mã nguồn lựa chọn chấp nhận hợp mã WebHooks Gitlab kích hoạt trình build hậu hợp Jenkins Mã nguồn sau build đóng gói vào ảnh Docker lưu máy Jenkins Người quản lý mã nguồn lựa chọn chấp nhận hợp mã WebHooks Gitlab kích hoạt q trình build hậu hợp Jenkins Mã nguồn sau build đóng gói vào ảnh Docker lưu máy Jenkins Các kiểm thử cho ảnh Docker thực máy Jenkins Nếu tất kiểm thử thành công, ảnh Docker đẩy lên Docker Registry riêng công ty Đồng thời, tác vụ triển khai Jenkins kích hoạt Jenkins dựa vào Ansible để triển khai ảnh Docker vào Kubernetes cluster Việc lựa chọn máy triển khai phụ thuộc vào lập lịch Kubernetes Master Mã nguồn tích hợp với thư viện prometheus để tùy biến metrics cần thiết cho việc giám sát Ngoài ra, exporter prometheus sử dụng để chuyển đổi thông tin metrics cung cấp từ thư viện khác môi trường Prometheus Alert Manager sử dụng làm máy chủ để gửi cảnh báo dựa vào thông tin nhận từ máy chủ promethus nguyên tắc cảnh báo viết người vận hành Tất cảnh báo gửi tới Slack thông báo lỗi khác Grafana sử dụng để cung cấp giao diện trực quan cho người dùng 10 Fluentd lựa chọn để làm log collector cho ảnh container Cách thức thu thập log sau: tệp log container ánh xạ máy triển khai Fluentd dựa vào plugin tail để đọc nội dung log, phân giải trường thông tin, xây dựng luồng kiện gửi tới máy đóng vai trò Log Aggregator Từ máy log aggregator, log chuyển vào lưu trữ Elasticsearch Tại đây, log lưu trữ đánh số để phục vụ cho việc tìm kiếm nhanh 11 Một số plugin sử dụng để cung cấp giao diện khả truy vấn liệu Elasticsearch Ngoài ra, Kibana cài đặt liên kết với Elasticsearch để cung cấp giao diện linh hoạt cho người sử dụng 17 Hình 3.2: Hệ thống triển khai liên tục hoàn thiện Đối với phần kết nối mạng để triển khai (trong trường hợp máy triển khai cài đặt VPC riêng tảng đám mây), luận văn đề xuất phương án kết nối sau: 18 Hình 3.3: Kết nối mạng triển khai Như vậy, máy VPC đóng vai trò work-terminal, chứa kịch triển khai Ansible Máy work-terminal truy cập tới tất máy khác VPC thông qua kết nối SSH Máy work-terminal gắn với địa Public IP định tuyến để truy cập từ máy mạng 19 CHƯƠNG 4: CÀI ĐẶT VÀ ĐÁNH GIÁ 4.1 Cài đặt 4.1.1 Hệ thống vi dịch vụ mẫu Để kiểm tra tính hiệu thiết kế luồng triển khai liên tục đề xuất chương trước, luận văn xây dựng ứng dụng gồm hai vi dịch vụ sau: • Forex-service: vi dịch vụ cung cấp chức tra cứu tỷ giá tiền tệ • Ccs-service: vi dịch vụ cung cấp chức chuyển đổi lượng tiền định từ đơn vị tiền tệ sang đơn vị tiền tệ khác Vi dịch vụ ccs-service sử dụng forex-service để lấy thông tin tỷ giá Khi triển khai, vi dịch vụ nêu có nhiều chạy Luận văn sử dụng chế load-blance cho Service, cung cấp Kubernetes, để đảm bảo định tuyến yêu cầu tới cách (round-robin) Hai vi dịch vụ lập trình ngơn ngữ Java, sử dụng khung Spring Boot 4.1.2 Cách thức tổ chức mã nguồn q trình build ảnh docker • Sử dụng cách thức tổ chức thư mục quy ước dựa án Maven • Tạo thư mục docker-build mức với thư mục mã nguồn src, chứa Dockerfile dùng để build ảnh docker, tệp script để sử dụng tài nguyên cho ảnh Ngoài ra, script để tự động hóa q trình build đẩy ảnh lên kho chứa ảnh đặt thư mục Để có tồn quyền cấu hình, luận văn cài đặt hệ thống quản lý mã Gitlab máy chủ CI Jenkins ứng dụng nội Jenkins cần sử dụng plugin để cung cấp chức tự động hóa cụ thể Trong bài, scm-plugin sử dụng để tải mã từ gitlab máy chủ Jenkins gitlab-plugin sử dụng để giúp Jenkins nhận thông báo kiện thay đổi mã Gitlab, từ kích hoạt q trình build cập nhật kết qủa lên commit kích hoạt Có hai q trình build sử dụng luồng triển khai cài đặt: build tiền hợp build hậu hợp Slack sử dụng luận văn kênh giao tiếp Slack-plugin cài đặt Jenkins để gửi thông báo tới Slack dựa vào trạng thái trình build Tất trạng thái trình build cập nhật trực tiếp lên Gitlab, cung cấp thông tin trực quan cho nhà phát triển Sau build tiền hợp thực thành công, luận văn sử dụng API cung cấp Jenkins để kích hoạt tiếp q trình triển khai, từ cập nhật ứng dụng vào môi trường sản phẩm (production environment) Hầu hết tác vụ Jenkins cấu hình thơng qua mã Groovy DSL cách tự động Điều giúp cho việc cấu hình trở nên đơn giản, nhanh chóng quan trọng kiểm thử từ trước thực chạy 20 4.1.3 Cài đặt môi trường sản phẩm 4.1.3.1 Cài đặt tảng điều phối container Một kubernetes cluster cần có thành phần sau: • Một master node: chứa thành phần api-server, controller-manager, lập lịch thành phần setup Tất các thành phần cài đặt ảnh Docker hypercube cung cấp Google • Các worker node: chứa thành phần kubelet, kube-proxy Các thành phần cài đặt ảnh hypercube với tham số phù hợp • Etcd: cung cấp chức lưu trữ phân tán giá trị dạng key-value Kubernetes cấu hình để kết nối lưu trữ liệu trạng thái etcd cluster Etcd cài đặt dịch vụ hệ thống dạng systemd • Cách thức kết nối mạng multihost: luận văn sử dụng dịch vụ flannel để đảm bảo kết nối mạng multihost cho máy khác Kết nối mạng chi tiết thể Hình 4.1 Hình 4.1: Cách thức kết nối mạng kubernetes • Giải pháp khám phá dịch vụ: SkyDNS sử dụng làm giải phát khám phá dịch vụ Kubernetes Các container chạy POD kubernetes tương tác với container POD khác DNS name Service đại diện POD Các vi dịch vụ forex-service ccs-service luận văn triển khai vào worker node kubernetes cluster Đối với tổ chức, thông thường máy triển khai môi trường sản phẩm cài đặt VPC với cấu hình mạng cách ly với mơi trường bên ngồi Do vậy, cần có cách thức phép yêu cầu gửi từ bên chuyển vào vi dịch vụ chạy lòng VPC Luận văn đề xuất cách thức cài đặt Hình 4.2: 21 Hình 4.2: Các máy Kubernetes cluster 4.1.3.2 Cài đặt cách thức thu thập quản lý log Các thức cài đặt hệ thống thu thập quản lý log thể Hình 4.3 Hình 4.3: Cách thức cài đặt quản lý log Khi vi dịch vụ chạy docker container, log chúng cấu hình để ghi tệp log vị trí xác định theo mẫu sau: /var/log/msa/${TÊN_VI_DỊCH_VỤ}/${TÊN_POD}/ Các tệp log container mount vào thư mục /var/log/msa máy mà container chạy Kubernetes tự động sinh tên pod ngẫu nhiên dựa vào tên dịch vụ cung cấp, tên pod thay đổi theo thời gian Việc quy định đảm bảo tệp log pod cũ tồn node để phục vụ mục đích thu thập Các fluentd agent cài đặt tất máy cấu hình 22 để đọc (tail) tệp log vị trí xác định, phân giải trường thông tin log tạo luồng log để gửi tới máy tập trung gọi fluentd-aggregator Về bản, fluentd-aggregator máy chạy fluentd bình thường; nhiên, fluentd cấu hình để lắng nghe kiện log gửi tới (tại port xác định) Trên máy fluentd-aggregator, kiện log lọc, thêm trường thông tin cần thiết, gửi tới hệ thống lưu trữ đánh số Elasticsearch Phần mềm Kibana cấu hình máy khác, kết nối tới Elastichsearch để truy vấn liệu, từ hiển thị thơng tin cho người dùng Elasticsearch Kibana cài đặt dịch vụ hệ thống systemd 4.1.3.3 Cài đặt hệ thống giám sát Hình 4.4: Cách thức cài đặt Prometheus Prometheus thành phần quan trọng hệ thống giám sát, có nhiệm vụ thu thập thơng tin trạng thái tất máy ứng dụng Các thơng tin cần thu thập bao gồm: • Tài nguyên sử dụng máy triển khai • Trạng thái đối tượng Kubernetes cluster • Các thông tin khác sinh thân ứng dụng Prometheus cài đặt Kubernetes cluster, sử dụng docker container Đối với thông tin tài nguyên sử dụng máy triển khai, luận văn sử dụng 23 dịch vụ node-exporter, cài đặt tất máy Các thông tin sau chuyển đổi cung cấp port 9100 máy đó, với endpoint /metrics Đối với trạng thái đối tượng Kubernetes cluster (như thông tin pod, container, service), luận văn sử dụng kube-state-metrics, cài đặt cách sử dụng docker container Kubernetes cluster Đối với trường thông tin khác sinh ứng dụng, luận văn sử dụng chế gắn thích vào docker container Ví dụ: thước đo msa_request_count tích hợp vào forex-service ccs-service với nhãn success, error để tính số lượng yêu cầu thành công hay thất bại gửi tới chúng Prometheus cấu hình để gửi thơng tin cảnh báo tới Alert Manager trạng thái hệ thống vượt qua ngưỡng định Từ Alert Manager, cảnh báo gửi thông qua kênh thông báo khác (trong sử dụng Slack) Alert Manager luận văn chạy docker, nhiên nằm riêng biệt với Kubernetes cluster ALERT high_error_request IF msa_request_count{msa_request_count="error"} > FOR 1m LABELS { severity = "slack" } ANNOTATIONS { summary = "Number of error request error is too high", description = "Receives lots of error request% Reported by instance {{ $labels.instance }} of job {{ $labels.job }}.", } Trong luận văn, tất các trình cài đặt hệ thống phức tạp viết Ansible Việc cài đặt máy hay nhóm máy thực nhanh chóng thơng qua cấu hình tệp 4.2 Đánh giá kết Qua việc sử dụng luồng triển khai liên tục cho hệ thống phần mềm dựa vào vi dịch vụ cụ thể phần trước, ta thấy số lợi ích rõ rệt mà mang lại như: • Giảm chu kỳ phát hành sản phẩm (Cycle Time) • Tăng suất lao động • Thỏa mãn yêu cầu cho đội phát triển Với việc sử dụng mơ hình triển khai khơng tùy biến, khơng có nhiều khác biệt môi trường sản phẩm môi trường local (tất thư viện, yêu cầu để dịch vụ chạy đóng gói vào ảnh container), nhà phát triển hồn tồn tự tái kiểm tra lỗi máy sử dụng Ngồi ra, tất cấu hình máy triển khai khai báo tệp kịch Ansible, lưu quản lý mã nguồn kho quản lý mã chung mà nhà phát triển truy cập Bằng việc tích hợp EFK stack sử dụng công cụ 24 giám sát với giao diện thể trực quan, thông tin trước cần phải truy cập trực tiếp vào máy xem hữu giao diện người dùng Thiết kế hệ thống triển khai liên tục luận văn thực tế đáp ứng gần tất yêu cầu mà bên phát triển mong muốn, đồng thời hạn chế rủi ro mà phương pháp làm việc trước gây 25 KẾT LUẬN Qua việc thu thập u cầu, phân tích cơng nghệ, luận văn đưa thiết kế hệ thống triển khai liên tục đáp ứng gần toàn yêu cầu cho ứng dụng dựa vào kiến trúc vi dịch vụ sử dụng container Tuy nhiên, giới hạn thời gian độ dài, số vấn đề chưa đề cập tới thiết kế Đầu tiên chế tự động scale-out scale-in hệ thống Việc sử dụng giải pháp quản lý cấu hình với tảng điều phối container điện toán đám mây cho phép hệ thống triển khai liên tục cung ứng thêm máy triển khai tạo container cách nhanh chóng Kèm với việc sử dụng Load Balancer Reverse Proxy, việc scale-out scale-in mà khơng có thời gian ngừng hoạt động hồn tồn thực Tuy nhiên, câu hỏi mà luận văn chưa giải lựa chọn thời điểm để scale-out/in phù hợp Hệ thống giám sát cluster cho phép thu thập thông tin tài nguyên sử dụng thông tin chưa tận dụng tối đa Nếu xây dựng thành phần trí tuệ nhân tạo để tự học liệu đưa định tối ưu trình scale Ngoài ra, việc cập nhật đảo ngược phiên triển khai áp dụng cấp bậc container Nếu container sử dụng sở liệu ngồi, hành động đòi hỏi thay đổi tương ứng bảng sở liệu Cách thức làm để đảo ngược sở liệu chưa đề cập tới Hiện nay, có số phương án thường sử dụng lưu gia tăng (incremental backup), áp dụng migration script, luận văn chưa đề cập tới đưa phân tích, so sánh thỏa đáng để áp dụng Trong tương lai, tác giả tiếp tục nghiên cứu hoàn thiện giải pháp để giải vấn đề nêu đáp ứng yêu cầu nảy sinh q trình phát triển ngành cơng nghiệp phần mềm 26