Luận văn 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ụ

79 4 0
Luận văn 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ụ

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

Thông tin tài liệu

MỤC LỤC LỜI CAM ĐOAN -1 LỜI CẢM ƠN BẢNG CÁC KÝ HIỆU VÀ CHỮ VIẾT TẮT -1 DANH MỤC HÌNH VẼ DANH MỤC BẢNG BIỂU 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 -5 1.2 Tích hợp, chuyển giao triển khai liên tục -6 1.2.1 Tích hợp liên tục 1.2.2 Chuyển giao liên tục -7 1.2.3 Triển khai liên tục 1.3 Kiến trúc hệ thống -8 1.3.1 Kiến trúc khối 1.3.2 Kiến trúc hướng dịch vụ - 10 1.3.3 Kiến trúc vi dịch vụ 11 1.4 Các mơ hình triển khai - 13 1.4.1 Mơ hình triển khai tùy biến - 13 1.4.2 Mơ hình không tùy biến kết hợp với Reverse Proxy - 14 1.4.3 Mơ hình khơng tùy biến với ứng dụng vi dịch vụ 15 1.5 Khái niệm Container 17 CHƯƠNG 2: YÊU CẦU CỦA HỆ THỐNG TRIỂN KHAI LIÊN TỤC - 21 2.1 Yêu cầu điều phối container - 21 2.1.1 Khám phá dịch vụ 21 2.1.2 Bộ lập lịch - 22 2.1.3 Điều phối container 23 2.2 Yêu cầu cho nhà phát triển - 24 2.2.1 Khả tự triển khai - 24 2.2.2 Nhận thông tin kết build - 25 2.3 Yêu cầu vận hành 25 2.3.1 Quản lý cấu hình 25 2.3.2 Thu thập lưu trữ log 25 2.3.3 Giám sát thông báo lỗi - 26 2.3.4 Triển khai không bị gián đoạn có khả đảo ngược phiên - 27 2.3.5 Thiết kế mạng triển khai - 27 CHƯƠNG 3: THIẾT KẾ HỆ THỐNG TRIỂN KHAI LIÊN TỤC - 28 3.1 Luồng triển khai 28 3.2 Phân tích lựa chọn công nghệ - 29 3.2.1 Hệ thống quản lý mã nguồn - 29 3.2.2 Máy chủ CI máy chủ triển khai - 30 3.2.3 Công nghệ container - 32 3.2.4 Nền tảng điều phối container - 32 3.2.5 Kubernetes - 36 3.2.6 Kênh thông báo - 38 3.2.7 Hệ thống thu thập quản lý log - 39 3.2.8 Công nghệ giám sát hệ thống cảnh báo 41 3.2.9 Giải pháp quản lý cấu hình 43 3.3 Luồng triển khai liên tục hoàn thiện - 43 CHƯƠNG 4: CÀI ĐẶT VÀ ĐÁNH GIÁ - 47 4.1 Cài đặt - 47 4.1.1 Hệ thống vi dịch vụ mẫu - 47 4.1.2 Cách thức tổ chức mã nguồn trình build ảnh docker 48 4.1.3 Cài đặt môi trường sản phẩm - 53 4.2 Đánh giá kết - 58 KẾT LUẬN - 61 TÀI LIỆU THAM KHẢO - 63 PHỤ LỤC - 65 BẢNG CÁC KÝ HIỆU VÀ CHỮ VIẾT TẮT STT Thuật ngữ viết tắt Thuật ngữ đầy đủ EFK Elasticsearch, Fluentd, Kibana VPC Virtual Private Cloud VM Virtual Machine CI Continuous Integration IaaS Infrastructure as a Service PaaS Platform as a Service SaaS Software as a Service IAC Infrastructure as code DNS Domain Name System 10 SOA Service Oriented Architecture 11 Container Công nghệ container, ảo hóa mức hệ điều hành DANH MỤC HÌNH VẼ Hình 1.1: Các bước tích hợp liên tục [5] Hình 1.2: Bảng so sánh kiến trúc khối, kiến trúc hướng dịch vụ kiến trúc vi dịch vụ [5] Hình 1.3: Kiến trúc khối cho ứng dụng đặt hàng Hình 1.4: Kiến trúc hướng dịch vụ cho ứng dụng đặt hàng 11 Hình 1.5: Kiến trúc vi dịch vụ cho ứng dụng đặt hàng 12 Hình 1.6: Mơ hình triển khai khơng tùy biến - cập nhật ứng dụng [5] 14 Hình 1.7: Mơ hình triển khai khơng tùy biến - cấu hình reverse proxy cập nhật [5] 15 Hình 1.8: Mơ hình triển khai khơng tùy biến với vi dịch vụ - cập nhật dịch vụ [5] 16 Hình 1.9: Mơ hình triển khai khơng tùy biến với vi dịch vụ - cấu hình reverse proxy [5] 16 Hình 1.10: Cơng nghệ container 17 Hình 1.11: Khác biệt container máy ảo 18 Hình 1.12: Kiến trúc Docker 19 Hình 1.13: Kiến trúc chi tiết Docker 20 Hình 2.1: Bộ lập lịch 22 Hình 2.2: Điều phối container thành phần 23 Hình 2.3: Cách thức thu thập log trước 26 Hình 3.1: Luồng triển khai liên tục 28 Hình 3.2: Mơ hình rẽ nhánh 30 Hình 3.3: Máy chủ CI Jenkins 31 Hình 3.4: Kiến trúc master-slave Jenkins [15] 32 Hình 3.5: Kiến trúc Docker Swarm [16] 33 Hình 3.6: Kiến trúc Apache Mesos 35 Hình 3.7: Kiến trúc Mesosphes Marathon [17] 35 Hình 3.8: Kiến trúc Kubernetes [10] 36 Hình 3.9: Ánh xạ Service Pod Kubernetes 37 Hình 3.10: Phần mềm Slack 39 Hình 3.11: Luồng sử dụng Fluentd với Elasticsearch Kibana 41 Hình 3.12: Heapster Kubernetes [20] 42 Hình 3.13: Kiến trúc Prometheus [21] 43 Hình 3.14: Hệ thống triển khai liên tục hồn thiện 44 Hình 3.15: Kết nối mạng triển khai 45 Hình 4.1: Mối quan hệ ccs-service forex-service 47 Hình 4.2: Mỗi vi dịch vụ có nhiều chạy 48 Hình 4.3: Cách tổ chức mã nguồn 48 Hình 4.4: Cấu hình webhook cho build tiền hợp Gitlab 49 Hình 4.5: Cấu hình Gitlab plugin Jenkins cho tiền hợp 50 Hình 4.6 Trạng thái build tiền hợp cập nhật theo thời gian thực Gitlab 51 Hình 4.7: Build tiền hợp chạy thành cơng 51 Hình 4.8: Thông báo từ Jenkins tới Slack 52 Hình 4.9: Groovy DSL cho Jenkins 52 Hình 4.10: Các tác vụ Jenkins 53 Hình 4.11: Cách thức kết nối mạng kubernetes 54 Hình 4.12: Các máy Kubernetes cluster 55 Hình 4.13: Cách thức cài đặt quản lý log 55 Hình 4.14: Cách thức cài đặt Prometheus 56 DANH MỤC BẢNG BIỂU Bảng 3-1: So sánh Docker Swarm, Mesosphere Marathon Kubernetes 38 Bảng 3-2: So sánh Logstash Fluentd 40 Bảng 4-1: Kết giải pháp triển khai liên tục 58 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 [1] 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 cịn 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ừ dịch 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 cịn 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 Lớp cùng, chịu trách nhiệm giao tiếp với người dùng, lớp giao diện Lớp giao diện thực việc 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 sử dụng Ngay phía lớp giao diện 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 logic nghiệp vụ không tương tác với sở liệu cách trực tiếp mà dựa vào lớp truy xuất liệu phía Cuối lớp truy xuất liệu Đây 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 q 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 Đầu tiên, vviệ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ý Ngồi ra, tính chất độc lập, 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 toàn ứng dụng trở nên dễ dàng (cập nhật lần lượt) Nhờ có kiến trúc vi dịch vụ, việc 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 Không thế, việc mmở rộng (scale) ứng dụng trở nên đơn giản nhanh chóng, việc mở rộng ứng dụng phân nhỏ thành mở rộng 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 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 tập trung vào việc phân tích 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 Dựa vào yêu cầu phân tích Chương 2, Chương đưa đề xuất thiết kế luồng triển khai liên tục cho hệ thống dựa vi dịch vụ nói chung, đồng thời trình bày so sánh cơng nghệ cho thành phần luồng để xây dựng nên thiết kế hoàn thiện Trong Chương 4, luận văn trình bày cụ thể cách thức cài đặt luồng triển khai liên tục mẫu cho hệ thống phần mềm chuyển đổi tiền tệ đánh giá kết đạt Phần Kết luận tổng kết thành nghiên cứu luận văn hướng phát triển dự định tương lai CHƯƠNG 1: KIẾN THỨC CƠ BẢN Cùng với xuất phổ biến phương pháp phát triển phần mềm linh hoạt, ý tưởng liên tục xuất để tận dụng tối đa lợi ích mà phương pháp mang lại Trong đó, bật ý tưởng việc tích hợp, chuyển giao triển khai liên tục: phần mềm dịch (build), đóng gói phát hành có thay đổi hệ thống quản lý mã Tuy nhiên, ý tưởng thực thời điểm mà đề xuất nhiều giới hạn công nghệ sở hạ tầng Với xuất tính tốn đám mây, tiến hóa kiến trúc phần mềm (từ kiến trúc khối tới kiến trúc vi dịch vụ) hay ý tưởng đóng gói ứng dụng container, việc xây dựng hệ thống triển khai liên tục trở nên khả thi Để giúp làm rõ nội dung chương tiếp theo, chương giới thiệu khái niệm nêu cách chi tiết 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 [2] 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 ngun tính tốn cho nhà cung cấp dịch vụ, thứ cung ứng gần Một đặc điểm quan trọng đám mây dịch vụ gần suốt với người dùng, nghĩa người dùng gần không cần quan tâm làm mà dịch vụ cung ứng mà cần tập trung vào việc làm để sử dụng chú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 ba mơ hình [3]: • Cơ sở hạ tầng dịch vụ (Infrastructure as a service - IaaS): cung cấp cho người dùng tài ngun tính tốn cấp độ thấp nhất, bao gồm: máy chủ, mạng, hệ thống lưu trữ, trung tâm liệu, giá tính theo khối lượng sử dụng Đối với người sử dụng, đặc biệt doanh nghiệp, lợi ích mà IaaS mang lại lớn, điển hình việc khơng cần đầu tư phần cứng, sở hạ tầng Qua kết đạt thể Bảng 4-1: Kết giải pháp triển khai liên tụ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) Chu kỳ phát hành tính từ thời gian có yêu cầu tới phát hành cập nhật môi trường sản phẩm Bằng hệ thống triển khai liên tục, thay đổi mã triển khai mơi trường mà khơng gặp khó khăn Ngay nhận yêu cầu người dùng, nhà phát triển phân tích, sửa đổi mã nguồn gửi yêu cầu hợp mã vào nhánh để kích hoạt q trình triển khai Việc triển khai ngồi cách kích hoạt tự động cịn thực thông qua giao diện Jenkins (chỉ áp dụng cho người dùng với quyền hạn phù hợp) Với cách sử dụng đơn giản, hệ thống sau cài đặt khơng địi hỏi chun gia triển khai để quản lý mà trách nhiệm phân phối đội Điều góp phần khuyến khích việc thực cập nhật với tần suất cao hơn, từ cải thiện chu kỳ phát hành thay đổi sản phẩm • Tăng suất lao động Tăng suất lợi ích rõ hệ thống triển khai liên tục Việc triển khai thường xuyên giúp tổ chức phát vấn đề nhận phản hồi sớm từ người dùng, từ đưa giải pháp phù hợp thời gian sớm Bằng việc tự động hố q trình build, kiểm thử cung cấp công cụ triển khai dễ dàng, nhà phát triển tập trung vào việc phát triển tính cịn đội vận hành giảm thiểu thời gian giám sát hệ thống để tập trung vào nâng cao chất lượng dịch vụ khác Trước đây, việc triển khai, giám sát cluster gồm hàng trăm máy địi hỏi đội vận hành hàng chục người Với hệ thống triển khai liên tục, tích hợp với chế giám sát thông báo lỗi tự động cho bên liên quan, cần vài người đảm bảo môi trường sản phẩm hoạt động tốt với độ tin cậy cao • Thỏa mãn yêu cầu cho đội phát triển Các nhà phát triển thường quen thuộc với cách thức truy cập trực tiếp vào môi trường sản phẩm để đọc phân tích log có lỗi xảy Tuy nhiên, kinh nghiệm thực tế cách làm gây nhiều thiệt hại lợi ích mà mang lại, tạo sửa đổi khiến máy triển khai chuyển sang trạng thái hoạt động bất thường 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 59 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ụ 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 60 KẾT LUẬN Các ứng dụng dựa vào đám mây xu hướng ngành công nghiệp công nghệ thông tin, giúp phát triển triển khai phần mềm cách nhanh chóng hiệu việc sử dụng dịch vụ đám mây Nó giúp cải thiện tốc độ làm việc cho đội phát triển họ tập trung vào việc phát triển tính thay lo lắng sở hạ tầng Nó giúp cho cơng ty, tổ chức đưa phần mềm thị trường nhanh dành thời gian cho thủ tục chuẩn bị máy móc phức tạp Các khái niệm tích hợp, chuyển giao liên tục, kiến trúc vi dịch vụ giúp tận dụng tối đa lợi ích mà đám mây mang lại Công nghệ container, với xuất Docker, cách mạng hóa cách thức đóng gói triển khai vi dịch vụ Bản chất nhẹ, sử dụng tài nguyên container giúp việc thiết lập môi trường chạy cho ứng dụng trở nên đơn giản, nhanh chóng (giảm thời gian từ vài chục phút cho việc khởi động máy ảo gồm toàn hệ điều hành tới vài phút cho việc bật container) Sự đời container, tích hợp với cơng nghệ trước đó, biến việc triển khai liên tục trở thành thực Các công cụ liên tục xuất để hỗ trợ cho việc triển khai container như: công cụ khám phá dịch vụ, khung điều phối container, giải pháp thu thập quản lý log hay cách thức giám sát hệ thống Tuy nhiên, tồn cơng cụ, tảng hay công nghệ nêu xuất tồn cách rời rạc, chưa có thống Câu hỏi đặt làm để phối hợp công nghệ để đưa luồng triển khai liên tục hiệu quả, đảm bảo thỏa mãn yêu cầu bên liên quan 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ệ 61 nhân tạo để tự học liệu đưa định tối ưu q trình scale Ngồ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 ngoà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 trình phát triển ngành cơng nghiệp phần mềm 62 TÀI LIỆU THAM KHẢO [1] “Survey Agile,” Techbeacon, 2018 [Online] Available: https://techbeacon.com/survey-agile-new-norm [2] Amazon Web Services, Inc, “What is Cloud Computing,” [Online] Available: https://aws.amazon.com/what-is-cloud-computing/ [3] IBM, “What is cloud computing?,” [Online] Available: https://www.ibm.com/cloud/learn/what-is-cloud-computing [4] S Guckenheimer, “What is Continuous Integration?,” [Online] Available: https://www.visualstudio.com/learn/what-is-continuous-integration/ [5] V Farcic, The DevOps 2.0 Toolkit, Leanpub, 2016 [6] P Maresca, “From Monolithic Three-tiers Architectures to SOA Vs Microservices,” [Online] Available: https://thetechsolo.wordpress.com/2015/07/05/from-monolith-three-tiersarchitectures-to-soa-vs-microservices/ [7] A Kharenko, “Monolithic vs Microservices Architecture,” [Online] Available: https://articles.microservices.com/monolithic-vs-microservices-architecture5c4848858f59 [8] I Miri, “Microservices vs SOA,” [Online] Available: https://dzone.com/articles/microservices-vs-soa-2 [9] Docker Inc., “What is a container,” [Online] Available: https://www.docker.com/what-container [10] Docker Inc All rights reserved., “Docker overview,” [Online] Available: https://docs.docker.com/engine/docker-overview/#docker-engine [11] M Hausenblas, Docker Networking and Service Discovery, O’Reilly Media, 2016 [12] J Sitakange, “Infrastructure as Code: A Reason to Smile,” [Online] Available: https://www.thoughtworks.com/insights/blog/infrastructure-code-reason-smile [13] A Mouat, Using Docker, O’Reilly Media, 2016 [14] Fluentd Project, “What is Fluentd?,” [Online] Available: https://www.fluentd.org/architecture [15] A s G b model, “A successful Git branching model,” [Online] Available: http://nvie.com/posts/a-successful-git-branching-model/ [16] S J Tirkey, “Setting Up Master Slave Machines Using Jenkins,” [Online] Available: https://blog.knoldus.com/2018/03/27/setting-up-master-slavemachines-using-jenkins/ [17] A Parthasarathy, “Kubernetes vs Docker Swarm,” [Online] Available: https://platform9.com/blog/kubernetes-docker-swarm-compared/ [18] A Parthasarathy, “Kubernetes vs Mesos + Marathon,” [Online] Available: https://platform9.com/blog/kubernetes-vs-mesos-marathon/ [19] T K Authors, “Services,” [Online] Available: https://kubernetes.io/docs/concepts/services-networking/service/ [20] N Peri, “Fluentd vs Logstash: A Comparison of Log Collectors,” [Online] 63 Available: https://logz.io/blog/fluentd-logstash/ [21] V K a V Marmol, “Resource Usage Monitoring in Kubernetes,” [Online] Available: https://kubernetes.io/blog/2015/05/resource-usage-monitoringkubernetes [22] Prometheus, “Prometheus,” [Online] Available: https://github.com/prometheus/prometheus [23] NetApp, “What Is Configuration Management (CM),” [Online] Available: https://www.netapp.com/us/info/what-is-configuration-management.aspx [24] Apache Mesos, “What is Mesos?,” [Online] Available: http://mesos.apache.org/ [25] MongoDB, Inc, “Containers and Orchestration Explained,” [Online] Available: https://www.mongodb.com/containers-and-orchestration-explained [26] https://docs.docker.com/get-started/part4/, “https://docs.docker.com/getstarted/part4/,” [Online] Available: https://docs.docker.com/get-started/part4/ [27] Mesosphere, Inc., “Marathon,” [Online] Available: https://mesosphere.github.io/marathon/ [28] Amazon Web Services, Inc, “What are Containers,” [Online] Available: https://aws.amazon.com/what-are-containers/ [29] Fluentd Project, “Why use Fluentd,” [Online] Available: https://www.fluentd.org/why [30] C Richardson, “Scale Cube,” [Online] Available: http://microservices.io/articles/scalecube.html [31] “kube-state-metrics,” [Online] Available: https://github.com/kubernetes/kubestate-metrics [32] R Karanam, “Microservices With Spring Boot,” [Online] Available: https://dzone.com/articles/microservices-with-spring-boot-part-1-getting-star [33] “Flannel,” [Online] Available: https://github.com/coreos/flannel 64 PHỤ LỤC Phụ lục thể số phần mã nguồn cho Hệ thống triển khai liên tục mẫu xây dựng luận văn I Các vi dịch vụ Forex-service • Controller @RestController public class ForexController { @Autowired private Environment environment; @Autowired private ExchangeValueRepository repository; private static final Counter requestTotal = Counter.build() name("msa_request_count") labelNames("msa_request_count") help("Number of request received").register(); @GetMapping("/currency-exchange/from/{from}/to/{to}") public ExchangeValue retrieveExchangeValue (@PathVariable String from, @PathVariable String to){ ExchangeValue exchangeValue = repository.findByFromAndTo(from, to); if(exchangeValue != null) { requestTotal.labels("success").inc(); exchangeValue.setPort( Integer.parseInt(environment.getProperty("local.server.port"))); } else { requestTotal.labels("error").inc(); } return exchangeValue; } @GetMapping("/health/status") public boolean healthCheck() { return true; } } • Dockerfile FROM release-docker.deanthesis.com:5000/release-test/oracle-jdk:8u121 MAINTAINER Dean Nguyen RUN mkdir -p /forex-service COPY script/start.sh /forex-service/ COPY forex-service-0.0.1-SNAPSHOT.jar /forex-service/ RUN chmod +x /forex-service/start.sh 65 EXPOSE 8000 WORKDIR /forex-service Current-conversion-service • Controller @RestController public class CurrencyConversionController { private Logger logger = LoggerFactory.getLogger(this.getClass()); private static final Counter requestTotal = Counter.build() name("msa_request_count") labelNames("msa_request_count") help("Number of request received").register(); @Autowired private CurrencyExchangeServiceProxy proxy; // @GetMapping("/currencyconverter/from/{from}/to/{to}/quantity/{quantity}") @RequestMapping(value = "/currencyconverter/from/{from}/to/{to}/quantity/{quantity}", method = RequestMethod.GET) public CurrencyConversionBean convertCurrency(@PathVariable String from, @PathVariable String to, @PathVariable BigDecimal quantity) { Map uriVariables = new HashMap(); uriVariables.put("from", from); uriVariables.put("to", to); ResponseEntity responseEntity = new RestTemplate().getForEntity( "http://localhost:8000/currency-exchange/from/{from}/to/{to}", CurrencyConversionBean.class, uriVariables); CurrencyConversionBean response = responseEntity.getBody(); return new CurrencyConversionBean(response.getId(), from, to, response.getConversionMultiple(), quantity, quantity.multiply(response.getConversionMultiple()), response.getPort()); } // @GetMapping("/currency-converterfeign/from/{from}/to/{to}/quantity/{quantity}") @RequestMapping(value = "/currency-converterfeign/from/{from}/to/{to}/quantity/{quantity}", method = RequestMethod.GET) public CurrencyConversionBean convertCurrencyFeign(@PathVariable String from, @PathVariable String to, @PathVariable BigDecimal quantity) { CurrencyConversionBean response = proxy.retrieveExchangeValue(from, to); logger.info("{}", response); if(response != null) { requestTotal.labels("success").inc(); } else { requestTotal.labels("error").inc(); } return new CurrencyConversionBean(response.getId(), from, to, response.getConversionMultiple(), quantity, quantity.multiply(response.getConversionMultiple()), 66 response.getPort()); } @GetMapping("/health/status") public boolean healthCheck() { return true; } } • Dockerfile FROM release-docker.deanthesis.com:5000/release-test/oracle-jdk:8u121 MAINTAINER Dean Nguyen RUN mkdir -p /currency-conversion-service COPY script/start.sh /currency-conversion-service/ COPY currency-conversion-service-0.0.1-SNAPSHOT.jar /currencyconversion-service/ RUN chmod +x /currency-conversion-service/start.sh EXPOSE 8100 WORKDIR /currency-conversion-service II Mã nguồn cấu hình triển khai Ansible Khởi tạo máy triển khai - name: Add work-terminal to the ansible host hosts: localhost connection: localhost gather_facts: False vars_files: - /vars/main.yml - /vars/main-{{ CLUSTER_SETUP }}.yml - /vars/const.yml roles: - { role: on-premises-work-terminal/init-create/set-hosts, tags: workterminal } - name: Initializing work terminal hosts: work-terminal vars_files: - /vars/main.yml - /vars/main-{{ CLUSTER_SETUP }}.yml - /vars/const.yml vars: DOWNLOAD_ONLY_INIT_FILES: True roles: - { role: on-premises-work-terminal/init-deploy/prerequisites, tags: workterminal } - { role: work-terminal/init-deploy/artifacts, tags: work-terminal } Triển khai vi dịch vụ vào cụm Kubernetes - hosts: localhost vars_files: - /vars/main.yml - /vars/const.yml - /roles/kubernetes/init-create/vars/main.yml roles: - kubernetes/init-deploy/set-services tags: - config - jar - hosts: kubernetes gather_facts: True 67 vars_files: - /vars/main.yml - /vars/const.yml - /roles/kubernetes/init-create/vars/main.yml roles: - kubernetes/init-deploy/nginx tags: - config - jar - hosts: localhost gather_facts: True vars_files: - /vars/main.yml - /vars/const.yml - /roles/kubernetes/init-create/vars/main.yml roles: - kubernetes/init-deploy/apps tags: - config - hosts: kubernetes-master vars_files: - /vars/main.yml - /vars/const.yml - /roles/kubernetes/init-create/vars/main.yml roles: - kubernetes/init-deploy/nginx/reload tags: config # - hosts: localhost # connection: localhost # vars_files: # - /vars/main.yml # - /vars/const.yml # - /roles/kubernetes/init-create/vars/main.yml # # roles: # - kubernetes/init-deploy/health-check # tags: jar Giải pháp thu thập quản lý log • Thu thập log - hosts: kubernetes,ntp-servers,kubernetes-master vars: td_agent_middleware_kubernetes: [ kubernetes ] td_agent_middleware_nginx: [ kubernetes ] vars_files: - /vars/main.yml - /vars/const.yml - /vars/main-{{ CLUSTER_SETUP }}.yml - /roles/td-agent/common-vars/vars/main.yml roles: - td-agent/init-create - limits - hosts: td-agent-aggregator vars_files: - /vars/main.yml - /vars/const.yml - /vars/main-{{ CLUSTER_SETUP }}.yml - /roles/td-agent/common-vars/vars/main.yml vars: EXTERNAL_STORAGE_DIRECTORY: /tmp/td-agent EXTERNAL_STORAGE_DEVICE: /dev/xvdk EXTERNAL_STORAGE_OWNER_USER: td-agent EXTERNAL_STORAGE_OWNER_GROUP: td-agent roles: - external-storage/init-create - td-agent-aggregator/init-create - limits 68 • Quản lý log - hosts: elasticsearch-log:kibana vars_files: - /vars/const.yml - /vars/main.yml roles: - apt/init-create - ntp/init-create - ntp/timezone # Download plugins and dictionaries to local (ansible server) - hosts: localhost vars_files: - /vars/main.yml - /vars/const.yml roles: - elasticsearch-log/file-preparation - hosts: elasticsearch-log vars_files: - /vars/main.yml - /vars/const.yml vars: EXTERNAL_STORAGE_DIRECTORY: /var/lib/elasticsearch EXTERNAL_STORAGE_DEVICE: /dev/xvdf EXTERNAL_STORAGE_OWNER_USER: elasticsearch EXTERNAL_STORAGE_OWNER_GROUP: elasticsearch roles: - external-storage/init-create - java/init-create - elasticsearch-log/init-create - hosts: kibana vars_files: - /vars/main.yml - /vars/const.yml roles: - java/init-create - kibana/init-create Cài đặt hệ thống giám sát cảnh báo lỗi • Hệ thống thu thập thông tin lỗi - name: Initialize disks hosts: prometheus vars_files: - /vars/main.yml - /vars/const.yml vars: EXTERNAL_STORAGE_DEVICE: /dev/xvdk EXTERNAL_STORAGE_DIRECTORY: /var/lib/prometheus roles: - external-storage/init-create - name: Deploying node exporters hosts: all:!zabbix-proxy vars_files: - /vars/main.yml - /vars/const.yml roles: - prometheus/init-create/node-exporter - name: Deploying Prometheus configurations hosts: prometheus vars_files: - /vars/main.yml - /vars/const.yml roles: - prometheus/init-create/pushgateway 69 - prometheus/init-create/config - name: Launch Prometheus hosts: localhost vars_files: - /vars/main.yml - /vars/const.yml - /roles/kubernetes/init-create/vars/main.yml roles: - prometheus/init-create/server - name: Reload Prometheus hosts: prometheus roles: - prometheus/init-create/reload-server tags: - reload • Hệ thống cảnh báo lỗi - name: Launch AlertManager hosts: alertmanager vars_files: - /vars/main.yml - /vars/const.yml roles: - prometheus/init-create/alertmanager III Mã nguồn hệ thống build triển khai cho Jenkins Mã DSL để tạo tác vụ Jenkins • Tác vụ build import domain.Test import domain.PremergeBuildForex import domain.PremergeBuildCcs // job def dirName = "pre-merge-build" def label = "ci-cd-report" def thesisMsaSampleGit = "gitlab.com" def gitlabPrivateToken = "kpGvcSxApii8L7W9XxhC" notifySlackForPremergeBuild=true slackChannelForBuild="#ci-cd-report" def createFolder(String jobPath) { jobPathString = ""; jobPath.split("/").each { path -> if (!jobPathString.isEmpty()) { jobPathString = "${jobPathString}/" } jobPathString = "${jobPathString}${path}" folder("${jobPathString}") } } // create folder createFolder(dirName) // function list def createTest = {Map config -> Test.applyTo(job("${dirName}/test"), [ label : label, script : readFileFromWorkspace('resources/scripts/test.sh') ]) } def createPremergeBuildForex = {Map config -> PremergeBuildForex.applyTo(job("${dirName}/premerge-build-forex"), [ gitlabPrivateToken: gitlabPrivateToken, slackChannelForBuild : slackChannelForBuild, 70 notifySlackForPremergeBuild : notifySlackForPremergeBuild, label : label, script : readFileFromWorkspace('resources/scripts/premerge-build-forex.sh'), notifyScript : readFileFromWorkspace('resources/scripts/notification/notifybuild-result.sh') ]) } def createPremergeBuildCcs = {Map config -> PremergeBuildForex.applyTo(job("${dirName}/premerge-build-ccs"), [ gitlabPrivateToken: gitlabPrivateToken, slackChannelForBuild : slackChannelForBuild, notifySlackForPremergeBuild : notifySlackForPremergeBuild, label : label, script : readFileFromWorkspace('resources/scripts/premerge-build-ccs.sh'), notifyScript : readFileFromWorkspace('resources/scripts/notification/notifybuild-result.sh') ]) } // execute createTest() createPremergeBuildForex() createPremergeBuildCcs() • Tác vụ triển khai package domain import javaposse.jobdsl.dsl.Job class RunUnitDeploy { static void applyTo(Job job, Map config) { job.with { parameters { stringParam("ENVIRONMENT", config.environment, "msa-deanthesis-demo") stringParam("SETUP_SCRIPT_BRANCH", config.setupScriptBranch, "master") stringParam("WORK_TERMINAL_IP", config.workTerminalIp, "192.168.1.29") stringParam("WORK_TERMINAL_PASSWORD", config.workTerminalPassword, "1") stringParam("GITLAB_PRIVATE_TOKEN", config.gitlabPrivateToken, "") stringParam("UNIT_LIST", "", """# comma separated values ## sample: `forex-service, ccs-service` Must be non-empty ## If this parameter is blank, job will be failed.""") stringParam("SERVICE_LIST", "", """# comma separated values ## sample: `forex-service, ccs-service` ## If this parameter is blank all service deloy job will be run.""") stringParam("ANSIBLE_OPTION", "-vvv", """# Do not change this settings!! This settings is only for environment masters!!! """) labelParam("NODE_LABEL") { defaultValue(config.label ?: "ci-cd-report") } } scm { git { remote { url(config.repositoryUrl) } branch("\${SETUP_SCRIPT_BRANCH}") cloneTimeout(180) } } logRotator { numToKeep(10) artifactNumToKeep(10) } publishers { 71 wsCleanup() slackNotifications { projectChannel(config.slackChannelForUnitDeploy) teamDomain(config.slackTeamDomain ?: 'uet-msa-thesis') integrationToken(config.slackToken ?: 'sB6erV7N6VKelgbWWOBXWtyt') notifyBuildStart(config.notifySlackForUnitDeploy.asBoolean()) notifyFailure(config.notifySlackForUnitDeploy.asBoolean()) notifySuccess(config.notifySlackForUnitDeploy.asBoolean()) customMessage("""ENVIRONMENT : \${ENVIRONMENT} UNIT_LIST : \${UNIT_LIST} SERVICE_LIST : \${SERVICE_LIST}""") } } configure { project -> def postbuildTask = project / publishers / 'hudson.plugins.postbuildtask.PostbuildTask' postbuildTask / tasks

Ngày đăng: 02/02/2023, 11:47

Tài liệu cùng người dùng

Tài liệu liên quan