ĐỒ ÁN TỐT NGHIỆP: NGHIÊN CỨU GIẢI PHÁP DEVSECOPS HỖ TRỢ PHÁT TRIỂN WEBSITE MÔ HÌNH MICROSERVICE

Công Nghệ Thông Tin, it, phầm mềm, website, web, mobile app, trí tuệ nhân tạo, blockchain, AI, machine learning - Công Nghệ Thông Tin, it, phầm mềm, website, web, mobile app, trí tuệ nhân tạo, blockchain, AI, machine learning - Công nghệ thông tin HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH VIỄN THÔNG KHOA CÔNG NGHỆ THÔNG TIN 1 ------------------------------------- ĐỒ ÁN TỐT NGHIỆP ĐẠI HỌC NGHIÊN CỨU GIẢI PHÁP DEVSECOPS TRONG HỖ TRỢ PHÁT TRIỂN PHẦN MỀM Giảng viên hướng dẫn: ThS. Nguyễn Đình Hiến Sinh viên thực hiện: Lê Quý Hoàng Mã sinh viên: B19DCCN276 Lớp: D19CNPM06 Niên khóa: 2019-2024 Hệ đào tạo: Đại học chính quy Hà Nội – 2023 ĐỒ ÁN TỐT NGHIỆP ĐẠI HỌC HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH VIỄN THÔNG KHOA CÔNG NGHỆ THÔNG TIN 1 CỘNG HÒA XÃ HỘI CHỦ NGHĨA VIỆT NAM Độc lập – Tự do – Hạnh phúc ĐỀ TÀI ĐỒ ÁN TỐT NGHIỆP ĐẠI HỌC Họ và tên: Lê Quý Hoàng Mã SV: B19DCCN276 Lớp: D19CNPM06 Khóa: 2019 Ngành đào tạo: Công nghệ thông tin Hệ đào tạo: Đại học chính quy Email: lequyhoang265gmail.com Số điện thoại: 0394643981 1 Tên đồ án tốt nghiệp: NGHIÊN CỨU GIẢI PHÁP DEVSECOPS TRONG HỖ TRỢ PHÁT TRIỂN PHẦN MỀM 2 Nội dung chính của đồ án: - Tìm hiểu cơ sở lý thuyết. - Tìm hiểu các công nghệ áp dụng. - Thiết kế giải pháp và hệ thống. - Cài đặt và vận hành hệ thống. 3 Cơ sở dữ liệu ban đầu: 4 Ngày giao đồ án: 5 Ngày nộp đồ án: GIÁO VIÊN HƯỚNG DẪN (Ký, ghi rõ họ tên) SINH VIÊN THỰC HIỆN (Ký, ghi rõ họ tên) TRƯỞNG KHOA (duyệt) (Ký, ghi rõ họ tên) ĐỒ ÁN TỐT NGHIỆP ĐẠI HỌC LỜI CẢM ƠN Lời đầu tiên, cho em xin gửi lời cảm ơn chân thành đến các thầy cô của Học viện Công nghệ Bưu chính Viễn thông, đặc biệt là các thầy cô khoa Công nghệ thông tin 1 đã trang bị cho em những kiến thức quý báu trong suốt quá trình học tập tại trường, tạo điều kiện thuận lợi nhất để em hoàn thành đồ án. Em xin trân trọng gửi lời cảm ơn đặc biệt đến thầy Nguyễn Đình Hiến, người đã hướng dẫn và đề xuất hướng giải quyết khi em gặp khó khăn, giúp em hoàn thành đồ án đúng tiến độ. Cuối cùng em cũng xin được cảm ơn gia đình, bạn bè, anh chị khóa trên đã giúp đỡ, bên cạnh quan tâm, ủng hộ trong suốt quá trình thực hiện đồ án. Dù đã cố gắng nhưng do thời gian và kinh nghiệm còn hạn chế nên trong đồ án chắc chắn còn nhiều điều thiếu sót, em mong nhận được sự góp ý cũng như chỉ bảo tận tình từ các thầy cô. Hà Nội, tháng 12 năm 2023 Sinh viên thực hiện Lê Quý Hoàng Lê Quý Hoàng - B19DCCN276 i ĐỒ ÁN TỐT NGHIỆP ĐẠI HỌC NHẬN XÉT ĐỒ ÁN TỐT NGHIỆP ĐẠI HỌC CỦA GIẢNG VIÊN HƯỚNG DẪN Giảng viên hướng dẫn: Ths. Nguyễn Đình Hiến Sinh viên thực hiện: Lê Quý Hoàng Tên đồ án: Nghiên cứu giải pháp DevSecOps trong hỗ trợ phát triển phần mềm NỘI DUNG NHẬN XÉT I. Nội dung báo cáo ................................................................................................................................ ................................................................................................................................ II. Sản phẩm ................................................................................................................................ ................................................................................................................................ III. Ưu nhược điểm ................................................................................................................................ ................................................................................................................................ IV. Kết luận: .........................................................................................................................… Điểm:..................................... (Bằng chữ: ) Đồng ýKhông đồng ý cho sinh viên bảo vệ trước hội đồng chấm đồ án tốt nghiệp? Hà Nội, ngày.....tháng 12 năm 2023 GIẢNG VIÊN HƯỚNG DẪN Nguyễn Đình Hiến Lê Quý Hoàng - B19DCCN276 ii ĐỒ ÁN TỐT NGHIỆP ĐẠI HỌC NHẬN XÉT ĐỒ ÁN TỐT NGHIỆP ĐẠI HỌC CỦA GIẢNG VIÊN PHẢN BIỆN Giảng viên phản biện: ........................................................................... Sinh viên thực hiện: Lê Quý Hoàng Tên đồ án: Nghiên cứu giải pháp DevSecOps trong hỗ trợ phát triển phần mềm NỘI DUNG NHẬN XÉT I. Nội dung báo cáo ..................................................................................................................................... ..................................................................................................................................... II. Sản phẩm ..................................................................................................................................... ..................................................................................................................................... III. Ưu nhược điểm ..................................................................................................................................... ..................................................................................................................................... IV. Kết luận: ....................................................................................................................... Điểm:..................................... (Bằng chữ: ) Đồng ýKhông đồng ý cho sinh viên bảo vệ trước hội đồng chấm đồ án tốt nghiệp? Hà Nội, ngày.....tháng 12 năm 2023 GIẢNG VIÊN PHẢN BIỆN Lê Quý Hoàng - B19DCCN276 iii ĐỒ ÁN TỐT NGHIỆP ĐẠI HỌC MỤC LỤC DANH MỤC HÌNH ẢNH..........................................................................................vi DANH MỤC TỪ VIẾT TẮT...................................................................................viii DANH MỤC TỪ THUẬT NGỮ.................................................................................x DANH MỤC BẢNG BIỂU.......................................................................................xii CHƯƠNG 1: GIỚI THIỆU ĐỀ TÀI, CÔNG NGHỆ VÀ GIẢI PHÁP SỬ DỤNG ...........................................................................................................1 1.1. Giới thiệu đề tài............................................................................................1 1.1.1. Lí do chọn đề tài.......................................................................................1 1.1.2. Mục tiêu nghiên cứu đề tài........................................................................2 1.1.3. Đối tượng và phạm vi................................................................................2 1.2. Giải pháp sử dụng.........................................................................................2 1.2.1. Lịch sử phương pháp triển khai ứng dụng.................................................2 1.2.2. DevSecOps và các khái niệm liên quan....................................................5 1.2.3. Các thành phần cần để xây dựng ứng dụng theo mô hình DevSecOps......8 1.2.4. DevSecOps như quy trình trong phát triển phần mềm............................10 1.3. Công nghệ sử dụng.....................................................................................14 1.3.1. Hệ thống quản lí mã nguồn và Gitea.......................................................14 1.3.2. Jenkins....................................................................................................16 1.3.3. SonarQube..............................................................................................18 1.3.4. Harbor.....................................................................................................18 1.3.5. Trivy........................................................................................................20 1.3.6. Argo CD..................................................................................................20 1.3.7. Kubernetes..............................................................................................23 1.3.8. MetalLB..................................................................................................28 1.3.9. Istio.........................................................................................................29 CHƯƠNG 2: THIẾT KẾ GIẢI PHÁP DEVSECOPS TRONG PHÁT TRIỂN PHẦN MỀM ..........................................................................................................31 2.1. Bài toán đặt ra............................................................................................31 2.2. Phân tích bài toán và đưa ra kiến trúc tổng quan của giải pháp..................31 2.3. Thành phần cấu trúc hệ thống theo công nghệ sử dụng..............................33 2.4. Luồng làm việc tổng quan của cả hệ thống.................................................35 2.5. Tích hợp liên tục.........................................................................................36 2.6. Triển khai liên tục.......................................................................................37 2.7. Giám sát sau triển khai...............................................................................39 2.8. Mô hình một microservice triển khai bằng Argo CD trên Kubernetes........40 2.9. Kiến trúc microservice giao tiếp khi áp dụng Istio.....................................42 Lê Quý Hoàng - B19DCCN276 iv ĐỒ ÁN TỐT NGHIỆP ĐẠI HỌC CHƯƠNG 3: ÁP DỤNG GIẢI PHÁP DEVSECOPS HỖ TRỢ PHÁT TRIỂN MỘT WEBSITE MÔ HÌNH MICROSERVICE....................................................43 3.1. Chuẩn bị hệ thống áp dụng giải pháp DevSecOps......................................43 3.1.1. Cấu hình webhook trên Gitea..................................................................43 3.1.2. Cấu hình Jenkins để nhận được webhook từ Gitea..................................44 3.1.3. Cấu hình token SonarQube để Jenkins sử dụng......................................46 3.1.4. Cấu hình tài khoản Harbor để tích hợp với Jenkins và cụm K8s.............46 3.1.5. Tạo ứng dụng Argo CD và cấu hình tự động đồng bộ.............................47 3.2. Cấu trúc của ứng dụng web Bookinfo........................................................49 3.3. Bài toán thực tế...........................................................................................50 3.4. Sử dụng giải pháp DevSecOps để triển khai phiên bản cập nhật cho ứng dụng web Bookinfo.................................................................................................51 3.4.1. Quy trình tích hợp liên tục......................................................................51 3.4.2. Quy trình triển khai liên tục....................................................................54 3.4.3. Quy trình giám sát...................................................................................55 3.5. Giải pháp DevSecOps và giải pháp truyền thống.......................................57 3.5.1. Nếu thực hiện triển khai cập nhật ứng dụng web Bookinfo bằng giải pháp truyền thống.........................................................................................................57 3.5.2. So sánh giải pháp DevSecOps và giải pháp truyền thống.......................57 3.6. Đánh giá việc sử dụng giải pháp DevSecOps trong phát triển phần mềm. .58 KẾT LUẬN................................................................................................................ 60 TÀI LIỆU THAM KHẢO........................................................................................61 Lê Quý Hoàng - B19DCCN276 v ĐỒ ÁN TỐT NGHIỆP ĐẠI HỌC DANH MỤC HÌNH ẢNH Hình 1.1 Cấu trúc của máy ảo.......................................................................................3 Hình 1.2 So sánh mô hình của container và máy ảo......................................................5 Hình 1.3 Vòng đời của mô hình DevOps......................................................................7 Hình 1.4 Logo Gitea....................................................................................................15 Hình 1.5 Logo Jenkins................................................................................................16 Hình 1.6 Logo SonarQube..........................................................................................18 Hình 1.7 Logo Harbor.................................................................................................18 Hình 1.8 Logo Trivy....................................................................................................20 Hình 1.9 Logo Argo CD..............................................................................................20 Hình 1.10 Kiến trúc tổng quan của Argo CD..............................................................21 Hình 1.11 Logo Kubernetes........................................................................................23 Hình 1.12 Cấu trúc của control plane..........................................................................24 Hình 1.13 Cấu trúc của worker node...........................................................................25 Hình 1.14 Deployment, Pod và container....................................................................26 Hình 1.15 Một Pod có thể có nhiều container.............................................................26 Hình 1.16 Cách các container trong một Pod giao tiếp...............................................27 Hình 1.17 Hướng scale của Pod trong Kubernetes......................................................27 Hình 1.18 Các Service giúp giao tiếp trong Kubernetes..............................................28 Hình 1.19 Logo MetalLB............................................................................................28 Hình 1.20 Logo Istio...................................................................................................29 Hình 2.1 Vòng lặp quy trình phát triển........................................................................33 Hình 2.2 Các công nghệ sử dụng phân loại theo nhóm chức năng..............................34 Hình 2.3 Luồng làm việc của hệ thống........................................................................35 Hình 2.4 Quy trình tích hợp liên tục............................................................................36 Hình 2.5 Quy trình triển khai liên tục..........................................................................37 Hình 2.6 Quy trình giám sát........................................................................................39 Hình 2.7 Các thành phần trong Kubernetes của một microservice được Argo CD quản lí.................................................................................................................................. 41 Hình 2.8 Kiến trúc ứng dụng với Istio.........................................................................42 Hình 3.1 Giao diện của một repository trên Gitea.......................................................43 Hình 3.2 Cấu hình webhook tới Jenkins......................................................................44 Hình 3.3 Giao diện tạo một luồng làm việc trên Jenkins.............................................44 Hình 3.4 Các lựa chọn cần thiết cho Git của Jenkins Pipeline....................................45 Hình 3.5 Cấu hình URL của reposiory mã nguồn ứng dụng.......................................45 Hình 3.6 Các credential cần thiết để Jenkins giao tiếp với các hệ thống khác.............46 Hình 3.7 Giao diện quản lí token của SonarQube.......................................................46 Hình 3.8 Giao diện quản lí tài khoản robot của Harbor...............................................47 Hình 3.9 Giao diện cài đặt của một project trên Harbor..............................................47 Hình 3.10 Giao diện tại ứng dụng Argo CD 1.............................................................48 Hình 3.11 Giao diện tạo ứng dụng Argo CD 2............................................................48 Hình 3.12 Cấu trúc ứng dụng Bookinfo......................................................................49 Hình 3.13 Giải thích giao diện ứng dụng microservice Bookinfo...............................50 Lê Quý Hoàng - B19DCCN276 vi ĐỒ ÁN TỐT NGHIỆP ĐẠI HỌC Hình 3.14 Phần tiêu đề mong muốn cập nhật..............................................................51 Hình 3.15 Giao diện terminal khi lập trình viên thực hiện git push.............................51 Hình 3.16 Trang web của repository mã nguồn...........................................................51 Hình 3.17 Giao diện Jenkins sau khi tự động chạy Pipeline........................................52 Hình 3.18 Trang chủ của SonarQube với kết quả quét mã nguồn mới........................52 Hình 3.19 Giao diện quản lí artifact của repository bookinfo-productpage.................53 Hình 3.20 Kết quả quét lỗ hổng bảo mật image của Trivy..........................................53 Hình 3.21 Giao diện của repository cấu hình triển khai sai khi cập nhật.....................53 Hình 3.22 Giao diện Argo CD sau khi tự động đồng bộ với repository cấu hình triển khai............................................................................................................................. 54 Hình 3.23 Kết quả kubectl trước khi cập nhật.............................................................54 Hình 3.24 Kết quả kubectl sau khi cập nhật................................................................55 Hình 3.25 Giao diện ứng dụng sau khi cập nhật..........................................................55 Hình 3.26 Giao diện biểu đồ của Kiali để theo dõi ứng dụng......................................55 Hình 3.27 Giao diện phân tích một request của Jaeger................................................56 Hình 3.28 Giao diện Grafana......................................................................................56 Lê Quý Hoàng - B19DCCN276 vii ĐỒ ÁN TỐT NGHIỆP ĐẠI HỌC DANH MỤC TỪ VIẾT TẮT Viết tắt Viết đầy đủ Giải nghĩaý nghĩa tiếng Việt CI Continous integration Tích hợp liên tục CD Continous delivery Cung cấp liên tục CD Continous deployment Triển khai liên tục IaC Infrastructure as code Quy trình quản lí và triển khai tài nguyên phần cứng bằng các file cấu hình định nghĩa. FTP File Transfer Protocol Một giao thức truyền file IDE Integrated development environment Một dạng công cụ phần mềm sử dụng cho lập trình CLI Command line interface Giao diện dùng lệnh để thao tác với máy tính UI User interface Giao diện người dùng DSL Domain-Specific Language Ngôn ngữ dành riêng cho một vấn đề HA High availability Các thành phần công nghệ thông tin có thể chạy liên tục ổn định mà không cần có can thiệp của con người. LDAP Lightweight Directory Access Protocol Một giao thức để tìm kiếm thông tin hoặc thiết bị trong một mạng AD Active Directory Giao thức từ điển của Microsoft, cho phép quản lí quyền truy cập các thành phần trong mạng OIDC OpenID Connect Giao thức xác thực danh tính mở rộng từ OAuth 2.0 YAML YAML Ain''''t Markup Language Định dạng file phổ biến dùng để chứa thông tin về cấu hình JSON JavaScript Object Notation Dạng file chứa dữ liệu đọc được bởi con người theo dạng key- value gRPC gRPC Remote Procedure Calls Công nghệ giao tiếp máy chủ- máy khách RBAC Role-based access control Quản lí quyền truy cập theo vai trò URL Uniform Resource Locator Địa chỉ dẫn tới một tài nguyên nào đó trên mạng SAML Security Assertion Markup Language Một cách tiêu chuẩn để cho ứng dụng hoặc dịch vụ ngoài biết được danh tính của người dùng, dùng cho xác thực. SSO Single sign-on Kiểu xác thực mà cho phép Lê Quý Hoàng - B19DCCN276 viii ĐỒ ÁN TỐT NGHIỆP ĐẠI HỌC người dùng có thể dùng chung một danh tính cho nhiều hệ thống phần mềm độc lập với nhau. DNS Domain Name System Từ điển của Internet, phân giải tên miền thành IP IaaS Infrastructure as a service Kiểu dịch vụ cloud cung cấp tài nguyên xử lí, bộ nhớ và mạng. K8s Kubernetes SSH Secure Socket Shell Giao thức cho phép người dùng truy cập vào máy tính qua mạng SSL Secure Sockets Layer Giao thức cung cấp bảo mật, xác thực và tính toàn vẹn cho truyền thông trên Internet Lê Quý Hoàng - B19DCCN276 ix ĐỒ ÁN TỐT NGHIỆP ĐẠI HỌC DANH MỤC TỪ THUẬT NGỮ Thuật ngữ Giải nghĩa Hypervisor Một dạng phần mềm, hoặc phần cứng có thể tạo và chạy máy ảo Microservice Kiến trúc và cách tổ chức phần mềm gồm nhiều thành phần dịch vụ độc lập với nhau và giao tiếp qua các API được định nghĩa rõ ràng Metric Ý nghĩa áp dụng trong giám sát, là dữ liệu thô từ nhiều nguồn như phần cứng, phần mềm, ứng dung, website, cung cấp thông tin về tài nguyên sử dụng, hiệu năng và hành vi của người dùng. Build Thao tác đưa mã nguồn qua các công cụ để biến thành một dạng file chạy được trên máy tính Script Phương pháp lập trình cho phép thực hiện các thay đổi, tuỳ biến và tự động hoá các thành phần của một hệ thống có sẵn Docker image Dạng tĩnh của container, dùng để tạo ra các container giống hệt nhau về nội dung bên trong và có thể lưu trữ Repository Một phần bộ nhớ (có thể trên máy tính hoặc cloud) chứa, quản lí và theo dõi sự thay đổi của file và thư mục. Là thành phần rất quan trọng của Git. Git merge Thao tác git cho phép ghép hai lịch sử phát triển vào với nhau (thường là khi có xung đột từ hai bên) Git commit Thao tác git ghi tại các thay đổi vào trong repository Git tag Thao tác git để đánh dấu các điểm quan trọng trong lịch sử thay đổi của một repository Git hook Chức năng của git cho phép tự động chạy các script khi một sự kiện quan trọng nào đó trong git xảy ra Git cherry-pick Thao tác git mà áp dụng thay đổi từ một commit nào đó có sẵn Pull request Là một đề xuất khi muốn ghép các thay đổi từ một nhánh sang một nhánh khác. Production Ở đây dùng với nghĩa là một môi trường mà đã có ứng dụng triển khai thành công và đang có người sử dụng thực tế Artifact Tất cả các dạng file có được sau khi thực hiện build từ mã nguồn thành công Orchestration Sử dụng để nói tới các hệ thống có thể cấu hình tự động, phối hợp và quản lí các hệ thống mạng và dịch vụ phức tạp Monolithic Mô hình phát triển phần mềm truyền thống khi mọi thứ được build vào thành một đơn vị duy nhất và độc lập với ứng dụng khác Downtime Khoảng thời gian mà các hệ thống không thể hoạt động và cung cấp dịch vụ Image tag Tên đặt cho Docker image để có thể quản lí Scale Khả năng mở rộng và thu nhỏ hệ thống phần mềm và phần cứng Self-hosted Cách triển khai ứng dụng bằng cách sử dụng hạ tầng có sẵn của bản thân cá nhân, tổ chức Cloud native Cách build, triển khai và quản lí phần mềm định hướng cho việc chạy ở trên một môi trường cloud Registry Hệ thống chứa và phân phối container image và artifact Lê Quý Hoàng - B19DCCN276 x ĐỒ ÁN TỐT NGHIỆP ĐẠI HỌC K8s node La một máy chủ hoặc máy ảo được K8s quản lí. Bare-metal Là một máy chủ vật lí chỉ được dùng cho một đối tượng duy nhất, hoặc trong ý nghĩa với K8s là việc sử dụng máy chủ vật lí như là node của K8s Canary testing Một dạng kiểm thử phần mềm khi chỉ phát hành phiên bản mới với một lượng người dùng nhỏ Reverse proxy Một máy chủ đứng trước các máy chủ web và điều hướng máy khách tới các máy chủ web đó Push image Thao tác tải lên image lên trên registry Pull image Thao tác tải xuống image từ registry Rollback K8s Khả năng trong K8s cho phép lùi lại phiên bản đã triển khai trước đó Rollout K8s Khả năng trong K8s cho phép triển khai tự động theo cấu hình K8s namespace Cung cấp khả năng cô lập các nhóm tài nguyên trong một cụm K8s Lê Quý Hoàng - B19DCCN276 xi ĐỒ ÁN TỐT NGHIỆP ĐẠI HỌC DANH MỤC BẢNG BIỂU Bảng 3.1 Bảng so sánh điểm mạnh của DevSecOps so với phương pháp truyền thống .................................................................................................................................... 58 Lê Quý Hoàng - B19DCCN276 xii ĐỒ ÁN TỐT NGHIỆP ĐẠI HỌC ÁP DỤNG GIẢI PHÁP DEVSECOPS HỖ TRỢ PHÁT TRIỂN MỘT WEBSITE MÔ HÌNH MICROSERVICE CHƯƠNG 1: GIỚI THIỆU ĐỀ TÀI, CÔNG NGHỆ VÀ GIẢI PHÁP SỬ DỤNG 1.1. Giới thiệu đề tài 1.1.1. Lí do chọn đề tài Trong vài thập kỉ gần đây, quy trình phát triển phần mềm đã thay đổi một cách chóng mặt, và đặc biệt với cuộc cách mạng gần nhất: dịch chuyển khỏi việc triển khai thủ công, hướng tới tư duy DevOps và tự động hoá (CICD). Sự dịch chuyển này không những đã tăng năng suất và độ hiệu quả trong vòng đời phát triển phần mềm, mà còn nâng cao sự hợp tác giữ các đội phát triển, vận hành và đảm bảo chất lượng. Sự thay đổi này sinh ra không phải ngẫu nhiên, mà là do chính thị trường công nghệ đi với sự phát triển mạnh của các công nghệ triển khai ứng dụng và sự hỗ trợ, đầu tư cực kì mạnh tay của các ông lớn trong ngành công nghệ như Google, Amazon, Microsoft. Các dịch vụ ngày một phức tạp, việc thay đổi kiến trúc là điều không thể tránh khỏi, cũng như việc phát triển cực mạnh mẽ của cloud. Hay yêu cầu của khách hàng cũng ngày một tăng cao, yêu cầu việc phát triển phầm mềm ngày càng phải linh hoạt hơn, ổn định hơn, và đặc biệt sản phẩm phải đến với khách hàng nhanh hơn và liên tục hơn. Trong những năm gần đây, chuyển đổi số trong doanh nghiệp trở thành một điều tất yếu, các doanh nghiệp, tổ chức trong mọi lĩnh vực hiện đã và đang khai thác các chiến lược chuyển đổi số, từ các tổ chức tư nhân đến nhà nước. Chuyển đổi số là số hóa toàn bộ cả một tổ chức. Chuyển đổi số là thay đổi quy trình mới, mô hình tổ chức mới, phương thức cung cấp dịch vụ, tư duy mới cho nhân viên và việc khai thác các công cụ hỗ trợ mới. DevOps và DevSecOps cũng chính là một phần trong chuỗi những thay đổi rất nhiều các doanh nghiệp đã bắt đầu áp dụng để tiến tới chuyển đổi số hoàn toàn. Trải nghiệm người dùng ngày càng trở thành trung tâm, và khi đưa lại những trải nghiệm tốt nhất cho khách hàng thì sẽ đưa lại những lợi thế cạnh tranh khi mà thị trường sản phẩm công nghệ thông tin ngày càng bão hoà. DevOps không phải sinh ra để rút ngắn quy trình hay thời gian phát triển, mà là để thời gian từ mã nguồn đến sản phẩm trở thành ngắn nhất, hay tức là đưa sản phẩm đến tay người dùng nhanh nhất có thể. Hơn nữa, việc một sản phẩm đến được tay khách hàng, tất yếu sẽ sinh ra đóng góp, ý kiến và phản ảnh từ khách hàng, từ đó cho phép đổi mới và cải tiến liên tục sản phẩm. Một sản phẩm được cập nhật liên tục, đúng với mong muốn, yêu cầu và có các tính năng mong đợi của khách hàng chắc chắn sẽ có lợi thế cực lớn so với các đối thủ. DevSecOps đóng một vai trò nòng cốt, song hành với việc thay đổi tư duy phát triển sản phẩm để có thể tiến tới chuyển đổi số. Vì vậy nên em đã lựa chọn đề tài “Nghiên cứu giải pháp DevSecOps trong hỗ trợ phát triển phần mềm”. Thông qua đề tài em muốn chứng minh được những lợi ích vô cùng to lớn và thiết thực mà DevSecOps và Lê Quý Hoàng - B19DCCN276 1 ĐỒ ÁN TỐT NGHIỆP ĐẠI HỌC ÁP DỤNG GIẢI PHÁP DEVSECOPS HỖ TRỢ PHÁT TRIỂN MỘT WEBSITE MÔ HÌNH MICROSERVICE tự động hoá có thể mang lại trong phát triển phần mềm, và đưa ra được một giải pháp tổng thể và thực tiễn để có thể áp dụng trong thực tế. 1.1.2. Mục tiêu nghiên cứu đề tài - Nghiên cứu về lý thuyết của DevOps, và mở rộng ra DevSecOps trong hỗ trợ quy trình phát triển phần mềm. - Đặt ra một giải pháp mang tính tổng thể theo tư duy DevSecOps để giải quyết bài toàn tự động hoá trong phát triển phàn mềm. - Áp dụng giải pháp DevSecOps vào trong việc phát triển một ứng dụng web mô hình microservice. 1.1.3. Đối tượng và phạm vi Các đội nhóm và doanh nghiệp phát triển sản phẩm, đặc biệt các đội nhóm đã và đang chuyển dịch, áp dụng Agile trong phát triển phần mềm. 1.2. Giải pháp sử dụng 1.2.1. Lịch sử phương pháp triển khai ứng dụng Ứng dụng là một phần đã giúp việc phổ biến hoá máy tính đến đại chúng, một trang web, một dịch vụ xử lí ảnh, một ứng dịnh tính toán trên mạng, tất cả đều là ứng dụng. Vậy ứng dụng chạy ở đâu? Hầu hết, nhất là các ứng dụng, dịch vụ online là chạy ở trên các máy chủ. a) Thời kì máy chủ vật lí Thời kì sơ khai nhất, gần như chỉ có thể chạy một ứng dụng trên một máy chủ, đây là giới hạn đặc tính kĩ thuật của thời kì này. Chính vì những hạn chế đó, mỗi khi doanh nghiệp cần có thêm, hoặc triển khai, mở rộng thêm các dịch vụ mới thì sẽ cần thêm một máy chủ mới. Tuy nhiên, yêu cầu về hiệu năng của các ứng dụng hầu như không được làm rõ với những ứng dụng mới đó, nên việc chọn mua máy chủ mới phần lớn phụ thuộc vào suy đoán. Từ vấn đề trên, sinh ra một các giải quyết đơn giản nhất: mua máy chủ phải to, phải mạnh, tốn nhiều tiền. Lí do giải thích đơn giản là vì yêu cầu kĩ thuật hiệu năng không rõ ràng, các doanh nghiệp không bao giờ muốn ứng dụng sẽ chạy chậm chỉ vì phần cứng quá yếu, từ đó có thể mất khách hàng. Kết cục là các máy chủ thường không bao giờ chạy hết hiệu năng tối đa, là một sự lãng phí tiền của rất lớn. b) Máy ảo Lê Quý Hoàng - B19DCCN276 2 ĐỒ ÁN TỐT NGHIỆP ĐẠI HỌC ÁP DỤNG GIẢI PHÁP DEVSECOPS HỖ TRỢ PHÁT TRIỂN MỘT WEBSITE MÔ HÌNH MICROSERVICE Hình 1.1 Cấu trúc của máy ảo Những năm cuối của thế kỉ 20, máy ảo ra đời một cách rộng rãi. Máy ảo ngay lập tức thay đổi các ứng dụng chạy trên máy chủ, cho phép nhiều ứng dụng có thể chạy trên một máy chủ duy nhất. Từ đó cũng làm việc mua máy chủ mới cho ứng dụng mới biến mất, thay vào đó là sử dụng chính tài nguyên của những máy chủ sẵn có một các hiệu quả hơn. Tuy nhiên, máy ảo không phải là một giải pháp hoàn hảo. Mỗi máy ảo đều phải có một hệ điều hành hoàn chỉnh riêng biệt cho chính nó là một điểm trừ lớn. Hệ điều hành sẽ tiêu tốn tài nguyên của máy chủ, gây lãng phí khi những tài nguyên đó có thể để sử dụng để chạy nhiều ứng dụng hơn. Ngoài ra, mỗi hệ điều hành đều cần theo dõi và cập nhật, sửa lỗi. Và trong một số trường hợp, hệ điều hành sẽ yêu cầu bản quyền. Tất cả các điều trên đều gây lãng phí thời gian và tài nguyên. Lê Quý Hoàng - B19DCCN276 3 ĐỒ ÁN TỐT NGHIỆP ĐẠI HỌC ÁP DỤNG GIẢI PHÁP DEVSECOPS HỖ TRỢ PHÁT TRIỂN MỘT WEBSITE MÔ HÌNH MICROSERVICE Chưa kể thêm mô hình máy ảo có một số điểm trừ khác như máy ảo thường khởi động chậm và tính di động không cao, một khi đã sử dụng một dạng máy ảo (hypervisor hoặc các nền tảng cloud) thì khá khó để có thể chuyển dịch sang một hypervisor hoặc một nhà cung cấp khác. c) Container và Docker Các tập đoàn lớn trong mảng dịch vụ web, ví dụ như Google, đã sử dụng container để giải quyết các điểm yếu của máy ảo từ khá lâu. Cơ bản thì một container có thể nói là ngang hàng với một máy ảo. Điểm khác biệt rõ ràng nhất là container không cần có một hệ điều hành đầy đủ của riêng nó như máy ảo, mà thay vào đó là sẽ chia sẻ hệ điều hành với cả máy chủ (máy cho phép các container chạy trên nó). Điểm khác biệt này cũng giúp một lượng lớn tài nguyên như RAM, CPU và bộ nhớ dược giải phóng. Ngoài ra còn giúp giảm được chi phí để mua bản quyền hệ điều hành, hay công sức để bảo trì, cập nhật, vá lỗi hệ điều hành. Kết quả là giúp tiếp kiệm thời gian, tài nguyên và tiền bạc. Container cũng có khả năng khởi động nhanh hơn và có tính di động rất cao. Việc chuyển và chạy container từ laptop cá nhân, lên cloud, hay vào trong máy ảo, hoặc chạy trên một máy chủ trực tiếp đều rất dễ dàng. Container hiện đại bắt nguồn từ thế giới Linux và là một sản phẩm được sinh ra từ sự góp sức khổng lồ từ rất nhiều người trông cộng đồng mã nguồn mở trong một thời gian dài. Ví dụ như Google đã có rất nhiều công sức trong việc viết các phần liên quan đến công nghệ container cho Linux kernel, nếu không có những thành phần này, container hiện như như có hiện nay có thể không tồn tại. Những công nghệ chính đã cho phép sự phát triển cực kì mạnh mẽ của container trong những năm gần đây có thể kể đến như kernel namespace, control group, union filesystem và Docker. Tuy nhiên, trước khi có Docker, container vẫn là một công nghệ rất phực tạp và ngoài tầm với của phần lớn tổ chức. Nhờ có Docker, container đã trở thành một công nghệ được phổ rộng hoá, cho phép đại chúng sử dụng một cách dễ dàng. Và từ sự phổ rộng hoá của Docker nói riêng và container nói chung, đã sinh ra nhu cầu cần thay đổi từ máy ảo sang container trong quy trình phát triển và triển khai ứng dụng của doanh nghiệp. Cùng với cách mà ứng dụng được phát triển cũng đang dần dịch chuyển theo một hướng mới. Tuy nhiên container không phải sinh ra để thay thế hoặc cạnh tranh với máy ảo, thay vào đó là một sự cộng hưởng và cùng hỗ trợ với nhau để sinh ra một hệ thống phát triển và vận hành phần mềm phù hợp với thời kì hiện đại. Lê Quý Hoàng - B19DCCN276 4 ĐỒ ÁN TỐT NGHIỆP ĐẠI HỌC ÁP DỤNG GIẢI PHÁP DEVSECOPS HỖ TRỢ PHÁT TRIỂN MỘT WEBSITE MÔ HÌNH MICROSERVICE Hình 1.2 So sánh mô hình của container và máy ảo Container là một đơn vị phần mềm độc lập, chứa tất cả các thành phần cần thiết để chạy một ứng dụng hoặc một website, một container bao gồm mã nguồn, các thư viện phụ thuộc, hệ điều hành độc lập và tài nguyên hệ thống ảo hóa. Container giúp đóng gói và triển khai ứng dụng một cách đáng tin cậy và dễ dàng hơn, cũng như tăng tính di động, linh hoạt của ứng dụng cho phép các nhà phát triển có thể triển khai ứng dụng của mình trên nhiều nền tảng, môi trường khác nhau một cách đơn giản và nhanh chóng. Mỗi container được xem như một môi trường độc lập với các container khác trên cùng một máy chủ. Các container được ảo hóa ở mức hệ điều hành và dùng chung nhân hệ điều hành với máy chủ chạy các container này. Container nhỏ gọn và linh hoạt hơn so với máy ảo do đó nó khởi động nhanh chóng hơn một máy ảo tuy nhiên do dùng chung nhân hệ điều hành với máy chủ nên vấn đề bảo mật của container yếu hơn máy ảo, các lỗ hổng bảo mật chạy bên trong container có khả năng truy cập vào phần còn lại của hệ thống máy chủ. Để dễ dàng trong quá trình quản lý và vận hành các container, một công cụ quản lý tập trung đã ra đời, đó chính là container runtime. Container runtime là một công cụ đóng vai trò quản lý tất cả quá trình running của một container, bao gồm tạo và xóa container, đóng gói và chia sẻ container. 1.2.2. DevSecOps và các khái niệm liên quan - Dev: Software development – phát triển phần mềm. - Sec: Security – bảo mật, an toàn thông tin. Lê Quý Hoàng - B19DCCN276 5 ĐỒ ÁN TỐT NGHIỆP ĐẠI HỌC ÁP DỤNG GIẢI PHÁP DEVSECOPS HỖ TRỢ PHÁT TRIỂN MỘT WEBSITE MÔ HÌNH MICROSERVICE - Ops: IT operations – vận hành công nghệ thông tin. Đây là ba thành phần, ba công việc cơ bản để đưa được một phần mềm từ mức ý tưởng đến tay của người dùng, và DevSecOps dùng sẽ giải quyết cả ba vấn đề này theo một tư tưởng mới, nhất là để áp dụng hiệu quả nhất với container. a) DevOps và DevSecOps: DevOps là một sự kết hợp của tư tưởng văn hoá, cách thức thực hiện và các công cụ giúp tăng khả năng cung cấp phần mềm và dịch vụ ở một nhịp độ cao hơn, tiến hoá và nâng cấp sản phẩm ở một tốc độ cao hơn so với các tổ chức sử dụng quy trình phát triển phần và quy trình quản lí hạ tầng truyền thống. Trong một mô hình DevOps, đội ngũ phát triển và đội ngũ vận hành không còn bị tách lẻ ra nữa. Thông thường hai đội nhóm này sẽ được ghép vào thành một nhóm duy nhất, kĩ sư trong nhóm sẽ làm việc trên toàn bộ vòng đời của phần mềm, từ phát triển, kiểm thử đến triển khai, vận hành, và phát triển các kĩ năng không giới hạn ở một mảng duy nhất. Một mô hình mở rộng của DevOps là khi các đội quản lí chất lượng và đội ngũ an toàn thông tin cũng được tích hợp chặt chẽ vào việc phát triển và vận hành trong suốt vòng đời của ứng dụng – thường được gọi là DevSecOps. Các đội nhóm DevOps sẽ sử dụng các phương pháp để tự động hoá các quy trình mà trước đây làm bằng tay và rất chậm. Kết hợp với việc sử dụng các nhóm công nghệ và công cụ để giúp vận hành và nâng cấp sản phẩm nhanh và có độ tin cậy cao. Các công cụ này cũng giúp cho một kĩ sư có thể hoàn thành các công việc một cách độc lập các công việc trước đây là phải yêu cầu sự hỗ trợ của các đội nhóm khác (ví dụ như triển khai hoặc cung cấp hạ tầng), từ đó tăng tốc độ của cả nhóm. Lợi ích của DevOps: - Tốc độ: Giúp khả năng thích ứng trước thị trường tốt hơn, phát triển, sáng tạo, cập nhật nhanh hơn. - Liên tục cung cấp: Tăng số lượng và nhịp độ ra mắt, cập nhật sản phẩm. Giúp cho việc bản sửa lỗi, bản nâng cấp tính năng đến rất nhanh tới người dùng cuối, thích ứng tốt hơn theo nhu cầu cảu khách hàng. - Độ tin cậy cao: Đảm bảo chất lượng của các bản cập nhật ứng dụng và thay đổi về mặt hạ tầng, đảm bảo việc phân phối ứng dụng nhanh và vẫn đảm bảo trải nghiệm tốt cho người dùng. - Scale: Vận hành và quản lý hạ tầng cùng với quy trình phát triển với khả năng scale. Tự động hoá sẽ tăng tính nhất quán trong việc quản lý các hệ thống phức tạp và thay đổi liên tục một cách hiệu quả với ít rủi ro. - Bảo mật: Đi nhanh không có nghĩa là đánh đổi lấy bảo mật. Các quy tắc bảo mật có thể áp dụng một cách tự động ở nhiều giai đoạn trong quá trình phát triển cũng như triển khai bằng nhiều công cụ khác nhau. Lê Quý Hoàng - B19DCCN276 6 ĐỒ ÁN TỐT NGHIỆP ĐẠI HỌC ÁP DỤNG GIẢI PHÁP DEVSECOPS HỖ TRỢ PHÁT TRIỂN MỘT WEBSITE MÔ HÌNH MICROSERVICE DevOps là một quy trình vòng lặp khép kín, bước trước sẽ là đầu vào của bước sau, bước cuối là đầu vào của bước đầu. Quy trình phát triển sẽ tiếp diễn như vậy trong suốt vòng đời sản phần để liên tục có thể đối mới và phát triển theo đúng hướng đi đặt trong tâm trải nghiệm người dùng là trên hết. Hình 1.3 Vòng đời của mô hình DevOps b) Tại sao DevOps trở nên quan trọng? Phần mềm và Internet đã thay đổi thế giới và nhiều ngành công nghiệp, từ mua sắm đến giải trí hay ngân hàng. Phần mềm còn chỉ là một thứ để hỗ trợ một doanh nghiệp nữa mà đã trở thành một phần quan trọng trong mọi thành phần của một doanh nghiệp. Các công ty có thể tương tác với khách hàng thông qua phần mềm được cung cấp dưới dạng dịch vụ trực tuyến hoặc ứng dụng trên rất nhiều kiểu thiết bị. Ứng dụng cũng giúp tăng tính hiệu quả vận hành của mọi phần của chuỗi giá trị. Cũng giống như cách các công ty sản xuất đã thay đổi cách thiết kế, xây dựng và phân phối sản phẩm trong cuộc cách mạng công nghiệp tự động hoá trong thế kỉ 20, công ty trong thế giới hiện đại cũng phải chuyển hoá cách xây dựng và phân phối sản phẩm phần mềm. c) DevOps là một văn hoá, không phải là một công cụ duy nhất Chuyển hoá sang DevOps yêu cầu sự thay đổi trong văn hoá và tư duy. Ở dạng đơn giản nhất, DevOps là loại bỏ rào cản giữa hai nhóm khác nhau: đội phát triển và đội vận hành. Trong một số tổ chức có thể không tồn tại sự phân chia này mà kĩ sư sẽ làm cả hai. Với DevOps, hai nhóm sẽ làm việc với nhau để tối ưu hoá năng suất của lập trình viên và độ tin cậy của vận hành. Đội nhóm sẽ trực tiếp chịu hoàn toàn trách nhiệm và quyền sở hữu của dịch vụ của họ, vượt qua cả danh nghĩa trên giấy hay vị trí truyền thống được đặt ra từ trước bằng cách suy nghĩ tới nhu cầu của người dùng cuối, và làm thế nào để giải quyết được các nhu cầu đó. Quản lý chất lượng và an toàn thông tin cũng có thể được tích hợp vào theo. Một tổ chức sử dụng mô hình DevOps, Lê Quý Hoàng - B19DCCN276 7 ĐỒ ÁN TỐT NGHIỆP ĐẠI HỌC ÁP DỤNG GIẢI PHÁP DEVSECOPS HỖ TRỢ PHÁT TRIỂN MỘT WEBSITE MÔ HÌNH MICROSERVICE sẽ có các đội nhóm chịu trách nhiệm toàn bộ vòng đời phát triển và vận hành sản phẩm. Chính vì DevOps không phải là một công cụ, mà chỉ là một văn hoá, một cách tích hợp các công cụ hỗ trợ trong phát triển phần mềm để nâng cao chất lượng sản phẩm, phương pháp hay giải pháp ứng dụng DevOps vào thực tế có vô số biến thể khác nhau, được tuỳ biến tuỳ vào hoàn cảnh thực tiễn và yêu cầu đặc thù để áp dụng. d) Các nguyên tắc của DevOps Một nguyên tắc nền tảng là cung cấp rất đều đặn các bản cập nhật nhỏ. Đây là cách mà tổ chức sẽ đổi mới nhanh hơn cho khách hàng. Những bản cập nhật này thường sẽ mang tính tăng thêm nhỏ so với những bản cập nhật thỉnh thoàng có dưới mô hình cung cấp truyền thống. Nhỏ và đều đặn giúp cho mỗi lần triển khai có ít rủi ro hơn, giúp các đội nhóm có thể xử lí các lỗi nhanh hơn bởi có thể sử dụng bản triển khai nào sinh ra lỗi. Tuy rằng mức độ to nhỏ và nhịp cập nhật của các bản cập nhật này sẽ còn tuỳ thuộc vào nhiều yếu tố khác, thông thường các tổ chức sử dụng mô hình DevOps sẽ cung cấp nhiều bản cập nhật hơn so với các tổ chức sử dụng mô hình phát triển phần mềm truyền thống. Tổ chức cũng có thể sử dụng mô hình microservice để làm ứng dụng linh hoạt hơn và cho phép đổi mới nhanh hơn. Kiến trúc microservice biến các hệ thống to lớn phức tạp thành các dự án nhỏ, đơn giản và độc lập. Một ứng dụng được tách lẻ ra thành rất nhiều các thành phần chỉ phụ trách đảm nhận một công việc duy nhất, hoạt động độc lập với các dịch vụ ngang hàng và ứng dụng tổng thể. Kiến trúc này giúp giảm gánh nặng đồng bộ khi cập nhật ứng dụng, bởi mỗi thành phần có thể cập nhật độc lập hoàn toàn. Tuy nhiên, sự phối hợp của microservice và tăng tần suất cập nhật sẽ dẫn đến nhiều bản triển khai hơn đáng kể, có thể sinh ra các thử thách về mặt vận hành. Vì thế, các phương pháp như tích hợp liên tục và cung cấp liên tục giải quyết các vấn đề đó, và cho phép việc phát triển nhanh nhưng vẫn đảm bảo an toàn và tính ổn định. Các phương pháp tự động hoá hạ tầng như IaC và quản lí cấu hình, sẽ giúp tài nguyên có khả năng phản ứng tốt hơn tới các thay đổi theo yêu cầu thực tế. Thêm vào với việc sử dụng theo dõi và ghi log sẽ giúp kiểm soát hiệu năng của ứng dụng và hạ tầng để tăng khả năng phản ứng trước các vấn đề phát sinh. 1.2.3. Các thành phần cần để xây dựng ứng dụng theo mô hình DevSecOps Để có thể xây dựng mô hình ứng dụng theo mô hình DevSecOps, phải đảm bảo và đi qua các yếu tố, thành phần sau để có thể biến ý tưởng trở thành một sản phẩm dùng được: - Tích hợp liên tục. - Cung cấp liên tục. - Triển khai liên tục. - Hạ tầng triển khai. Lê Quý Hoàng - B19DCCN276 8 ĐỒ ÁN TỐT NGHIỆP ĐẠI HỌC ÁP DỤNG GIẢI PHÁP DEVSECOPS HỖ TRỢ PHÁT TRIỂN MỘT WEBSITE MÔ HÌNH MICROSERVICE - Giám sát. a) Tích hợp liên tục Tích hợp liên tục nghĩa là một phương pháp để tự động hoá việc tích hợp các thay đổi trong mã nguồn từ nhiều người khác nhau trong một dự án phần mềm. Nó là một trong các bước quan trọng của một quy trình DevSecOps, cho phép liên tục merge các thay đổi của mã nguồn vào một repository tập trung và quá trình build và kiểm thử sẽ chạy ở đó. Các công cụ tự động sẽ dùng để đảm bảo tính đúng của mã nguồn mới trước khi tích hợp. Một hệ thống quản lí phiên bản mã nguồn là xương sống của quy trình CI, ngoài ra cũng sẽ cung cấp thêm một số kiểm tra khác như tự động kiểm tra chất lượng mã nguồn hoặc kiểm tra cú pháp mã nguồn. Để hiểu được tầm quan trọng của CI thì phải nhìn vào trường hợp và các vấn đề sinh ra khi không có CI. Lập trình viên sẽ phải thủ công hợp tác và liên lạc mỗi khi cần đóng góp các thay đổi vào sản phẩm. Sự hợp tác này kéo dài từ đội phát triển cho đến vận hành, và kể cả tổ chức. Đội sản phẩm thì phải phối hợp khi ra mắt lần lượt các tính năng mới và sửa lỗi. Việc giao tiếp trong một môi trường không có CI có thể trở thành rất phức tạp, vòng vèo với các công đoạn cần đồng bộ nhưng lại chồng chéo lên nhau, tiêu tốn về cả mặt thời gian và công sức. Điều này cũng dẫn đến chậm trễ trong việc phát hành mã nguồn mới và có khả năng hỏng hóc cao do việc tích hợp phải luôn có bàn tay con người trực tiếp tác động vào. Những rủi ro cũng càng nghiêm trọng hơn khi số người đội nhóm và độ lớn của dự án tăng lên. Nếu không có một quy trình CI chắc chắn, sẽ có một rào cản giữa đội ngũ kĩ thuật và phần còn lại của tổ chức. Giao tiếp giữa đội sản phẩm và đội kĩ thuật có thể trở nên khó khăn. Đội kĩ thuật sẽ trở thành một “hộp đen” mà các đội nhóm khác đưa yêu cầu, hoặc tính năng mong muốn như đầu vào, và mong đợi có thể có được kết quả. Từ đó cũng làm chính đội kĩ thuật khó có thể đoán được thời gian hoàn thành yêu cầu bởi thời gian tích hợp các thay đổi mới là một rủi ro không biết và không đoán được. CI thường được sử dụng trong một luồng làm việc phát triển phần mềm Agile. Một tổ chức sẽ xây dựng được một danh sách bao gồm các việc trên con đường phát triển của sản phẩm. Các công việc này sẽ được chia ra cho cái đội ngũ phát triển, và CI sẽ cho phép mọi người trong nhóm này làm việc song song độc lập với nhau cùng lúc. Và khi có một công việc hoàn tất, lập trình viên sẽ ghép mã nguồn vào và đưa lên hệ thống CI để được tích hợp vào trong phần còn lại của dự án. b) Cung cấp liên tục Cung cấp liên tục là tự động hoá tất cả các thay đổi của mã nguồn thành một phiên bản chạy được trên một môi trường thử nghiệm và sẵn sàng để có thể được đưa lên môi trường production. Cung cấp liên tục thường xảy ra sau tích hợp liên tục. Nếu Lê Quý Hoàng - B19DCCN276 9 ĐỒ ÁN TỐT NGHIỆP ĐẠI HỌC ÁP DỤNG GIẢI PHÁP DEVSECOPS HỖ TRỢ PHÁT TRIỂN MỘT WEBSITE MÔ HÌNH MICROSERVICE được áp dụng đầy đủ, sẽ luôn có một phiên bản artifact sẵn sàng để triển khai mà đã đạt và thông qua các tiến trình kiểm tra. Cung cấp liên tục cho phép tự đông hoá cao hơn mức chỉ có kiểm thử đơn vị, cho phép lập trình viên kiểm tra việc cập nhật phần mềm ở nhiều khía cạnh khác trước khỉ triển khai tới khách hàng. Kiểm thử bước này có thể bao gồm cả kiểm thử giao diện, kiểm thử tải, kiểm thử tích hợp, kiểm thử tính ổn định của API, … Cái này cho phép mức độ kiểm tra phiên bản cập nhật kĩ càng hơn và có khả năng phát hiện vấn đề sớm hơn. c) Triển khai liên tục Triển khai liên tục là mức độ tự động hoá cao hơn cung cấp liên tục. Mã nguồn khi có thay đổi sẽ được phát hành tự động hoàn toàn tới người dùng ngay sau khi các bài kiểm thử đặt trước thành công. Ở đây không thể có sự can thiệp để biến thành thủ công, đấy là điểm khác biệt rõ nhất của cung cấp liên tục và triển khai liên tục, vì vậy các bài kiểm thử cũng phải tự động hoàn toàn mà không có sự can thiệp của con người trong quá trình kiểm thử. d) Hạ tầng triển khai Sau khi kết thúc pipeline CICD, nghĩa là phần mềm đã chạy được, thì để triển khai cho khách hàng, người dùng thì cần phải có một hạ tầng để phần mềm chạy trên nó. Tuy nhiên hạ tầng không có bất kì giới hạn nào, có thể là một máy chủ vật lí, có thể là một máy ảo, có thể làm một hệ thống container orchestration. Tuy nhiên để có thể lấy được nhiều lợi ích nhất thì các hệ thống container orchestration sẽ là nổi bật nhất về các lợi ích thu lại được sau khi triển khai, với vô hạn các khả năng có thể làm được với ứng dụng sau khi triển khai. e) Giám sát Giám sát trong DevSecOps bao trọn toàn bộ quy trình phát triển, từ kế hoạch, phát triển, tích hợp và kiểm thử đến triển khai, vận hành. Cung cấp một cái nhìn tổng thể và theo thời gian thực trạng thái của ứng dụng, dịch vụ và hạ tầng trong môi trường production. Các chức năng như theo dõi thời gian thực, xem lại lịch sử và hình tượng hoá là thành phần tất yếu của việc giám sát phần mềm, dịch vụ. Giám sát cũng cho phép các đội nhóm phản ứng nhanh và tự động với bất kì sự giảm sút nào về trải nghiệm của khách hàng. Quan trọng hơn nữa, cho phép các giai đoạn phát triển được tập trung hơn để giảm lượng hỏng hóc sinh ra trong môi trường production. Theo dõi các metric để biết được ảnh hưởng của hiệu năng ứng dụng và hạ tầng tới trải nghiệm của người dùng. Thu thập, phân loại và phân tích dữ liệu sinh ra bởi phần mềm và hạ tầng sẽ giúp các tổ chức hiểu hơn thay đổi hoặc cập nhật đã ảnh hưởng đến người dùng như nào, thấu hiểu được gốc rễ của các vấn đề sinh ra hoặc thay đổi ngoài dự kiến. Theo dõi tích cực (active monitoring) ngày càng trở nên quan trọng bởi dịch Lê Quý Hoàng - B19DCCN276 10 ĐỒ ÁN TỐT NGHIỆP ĐẠI HỌC ÁP DỤNG GIẢI PHÁP DEVSECOPS HỖ TRỢ PHÁT TRIỂN MỘT WEBSITE MÔ HÌNH MICROSERVICE vụ phải đảm bảo 247 và ứng dụng, hạ tầng liên tục được cập nhật. Thêm khả năng báo động và phân tích theo thời gian thực các dữ liệu này càng cho phép kiểm soát các dịch vụ tốt hơn. 1.2.4. DevSecOps như quy trình trong phát triển phần mềm Như đã nói ở trên, DevOps và DevSecOps là một khái niệm tổng hợp của văn hoá, cách thức và công cụ. Nếu chỉ nói ở mặt cách thức, hay coi như DevSecOps là một quy trình có thể áp dụng được vào trong quy trình phát triển phần mềm, với các công nghệ và công cụ liên quan thì có thể nói DevSecOps có thể áp dụng rất sâu, rất tốt và hiệu quả, cả với phần mềm monolithic lẫn microservice. Quay lại về mô hình monolithic, mặc dù đúng là tất cả các dịch vụ ở trong đều sẽ được đóng gói lại thành một khối duy nhất (ví dụ thành một file nhị phân chạy được) nhưng vậy trong các giai đoạn phát triển sẽ như nào? a) Triển khai truyền thống Ở ngay bước đầu tiên của phát triển, coi như giai đoạn thiết kế đã hoàn tất, vậy một ứng dụng cho doanh nghiệp lớn sẽ có nhiều người cùng lập trình, ví dụ là sản phẩm đang sử dụng SpringBoot, Java 11 kèm với MySQL 8.0.35. Để đảm bảo môi trường phát triển giống hệt nhau khi code, sẽ phải cài chính xác tất cả các phiên bản của các công cụ trên cho mọi máy để khi chạy, môi trường giống hệt nhau. Việc đảm bảo này sẽ là quản lí bằng tay, hoặc một phần tự động bằng các cấp máy tính cài sẵn môi trường cho lập trình viên. Và việc phát triển hầu như sẽ kẹt ở chuỗi công nghệ này, hầu như không nâng cấp được lên các bản cập nhật mới hơn của công nghệ hay ứng dụng các công nghệ mới khác. Tiếp theo, ở công đoạn xây dựng ứng dụng sau khi lập trình viên làm xong, sẽ là các đoạn kiểm thử, xây dựng, tiếp tục là các công đoạn chạy bằng tay hoặc bán tự động với một dạng script nào đó. Sẽ yêu cầu ít nhất một người của đội vận hành lấy mã nguồn, chạy lệnh build, kiểm tra xem build thành công không? Sau đó chuyển sang cho đội kiểm thử để kiểm thử ứng dụng sau khi build đó. Tiếp tục, sau khi kiểm thử xong, nếu đạt mọi chỉ tiêu sẽ đến công đoạn triển khai. Tiếp tục lại có một người ở đội vận hành, chuyển tiếp file nhị phân chạy được sau build đã được kiểm thử đó lên máy chủ đang chạy sẵn ứng dụng đó để cập nhật – lại là một việc làm thủ công hoặc bán tự động. Và đặc biệt rủi ro lớn nếu như bản cập nhật khi chạy trên máy chủ lại lỗi (ví dụ do thiếu một thư viện nào đó mới thêm vào ở giai đoạn phát triển), gây ra downtime cho dịch vụ mà khách hàng sử dụng. Ở trong môi trường production, theo dõi sức khoẻ của ứng dụng khi triển khai dạng truyền thống gần như là không có hoặc rất ít vì hầu như chỉ có hai trạng thái: ứng dụng có chạy, và ứng dụng không chạy. Tất nhiên có thể áp dụng ghi log ra file, hoặc báo lỗi ra terminal, nhưng hầu hết theo dõi chỉ hạn chế ở dạng theo dõi xem phần cứng có đầy không, có chậm không, ứng dụng còn “sống” không. Lê Quý Hoàng - B19DCCN276 11 ĐỒ ÁN TỐT NGHIỆP ĐẠI HỌC ÁP DỤNG GIẢI PHÁP DEVSECOPS HỖ TRỢ PHÁT TRIỂN MỘT WEBSITE MÔ HÌNH MICROSERVICE Cuối cùng, vậy nếu đang triển khai ứng dụng dạng truyền thống trên một máy chủ vật lý, hoặc một máy ảo. Vậy nếu lượng người dùng tăng giảm thì sao? Nếu cần giảm thì có thể đành chịu lãng phí tài nguyên, nhưng nếu tăng thì rất khó, thường bắt buộc phải có downtime do phải dừng hoàn toàn máy ảo để cấp thêm tài nguyên, hoặc dừng hẳn máy thật để lắp thêm phần cứng. Tất cả các điểm trừ trên, có các cách khắc phục phần nào đó, tuy nhiên đều chỉ mang lại lợi ích nhỏ, và các giai đoạn đều có sự tác động của con người đáng kể, từ phát triển đến vận hành, mà lỗi con người là lỗi rất dễ xảy ra. b) Triển khai theo một quy trình DevSecOps Đầu tiên, những gì ở trong quy trình truyến thống có thể thay đổi để áp dụng vào quy trình DevSecOps? Giai đoạn phát triển, việc kẹt ở công nghệ như Java 11, Spring Boot hay MySQL 8.0.35 thì vẫn không thể thay đổi. Tuy nhiên việc tạo môi trường để lập trình viên làm việc và thử nghiệm sẽ dễ hơn nhiều. Đội vận hành đơn giản sẽ tạo một Docker image gồm đầy đủ và đã cài sẵn mọi môi trường cần thiết, khi lập trình viên muốn thử nghiệm trên máy cá nhân, chỉ cần có Docker image là có thể build được ứng dụng mà không cần phải suy nghĩ là có thiếu thư viện A, phần mềm B hay không nữa. Và tất cả các máy có thể được triển khai điều này rất nhanh và đơn giản, hầu như chỉ với một lệnh duy nhất để lấy Docker image. Từ đó không còn phải lo vấn đề như nhân viên mới cài sẵn Java 17 mới mất rồi hay MySQL tự động cập nhật lên bản mới hơn trên máy cá nhân. Vậy sau khi lập trình xong, lập trình viên đã cho mã nguồn lên trên git repository của dự án, việc xây dựng và kiểm thử thì sao? Các đoạn kiểm thử có thể được tự động hoá cùng với việc tự động hoá xây dựng. Ở đây biến thành một mảnh của giai đoạn CI. Chính Docker image dùng cho lập trình viên, có thể sử dụng để build thành phiên bản mới bằng công cụ CI tự động, các công cụ này cho phép tự động hoá hoàn toàn giai đoạn build bằng cách tự nhận biết thay đổi theo git commit. Thêm vào đó cũng cho phép chạy công cụ kiểm thử tự động trên giai đoạn build này, vởi khả năng theo dõi quá trình build để biết có lỗi có xảy ra hay không. Giai đoạn này cũng có thể do chính lập trình viên làm mà không cần sự giúp đỡ của người khác khi hạ tầng đã được cấu hình đúng. Sau giai đoạn này, công cụ CI đã sinh ra được một binary chạy được, hoặc phổ biến nhất là một Docker image chạy được. Vậy triển khai thì sao? Triển khai cũng có thể biến trở thành một thao tác tự động hoàn toàn. Ví dụ khi đã có một hệ thống triển khai container. Phiên bản cũ có thể đang chạy sẵn, khi cập nhật, hệ thống sẽ tự động lấy phiên bản mới (tự động có chọn lọc), chạy trên hệ thống cho đến khi ứng dụng thực sự chạy được thì mới dừng và tắt phiên bản cũ. Điều này nghĩa là không có bất kì downtime nào cả, kể cả một giây. Trong trường hợp bản mới lỗi khi triển khai như này thì cũng không ảnh hưởng gì vì bản cũ vẫn sẽ chạy cho đến khi nào Lê Quý Hoàng - B19DCCN276 12 ĐỒ ÁN TỐT NGHIỆP ĐẠI HỌC ÁP DỤNG GIẢI PHÁP DEVSECOPS HỖ TRỢ PHÁT TRIỂN MỘT WEBSITE MÔ HÌ

GIỚI THIỆU ĐỀ TÀI, CÔNG NGHỆ VÀ GIẢI PHÁP SỬ DỤNG

Giới thiệu đề tài

1.1.1 Lí do chọn đề tài

Trong vài thập kỉ gần đây, quy trình phát triển phần mềm đã thay đổi một cách chóng mặt, và đặc biệt với cuộc cách mạng gần nhất: dịch chuyển khỏi việc triển khai thủ công, hướng tới tư duy DevOps và tự động hoá (CI/CD) Sự dịch chuyển này không những đã tăng năng suất và độ hiệu quả trong vòng đời phát triển phần mềm, mà còn nâng cao sự hợp tác giữ các đội phát triển, vận hành và đảm bảo chất lượng.

Sự thay đổi này sinh ra không phải ngẫu nhiên, mà là do chính thị trường công nghệ đi với sự phát triển mạnh của các công nghệ triển khai ứng dụng và sự hỗ trợ, đầu tư cực kì mạnh tay của các ông lớn trong ngành công nghệ như Google, Amazon, Microsoft. Các dịch vụ ngày một phức tạp, việc thay đổi kiến trúc là điều không thể tránh khỏi, cũng như việc phát triển cực mạnh mẽ của cloud Hay yêu cầu của khách hàng cũng ngày một tăng cao, yêu cầu việc phát triển phầm mềm ngày càng phải linh hoạt hơn, ổn định hơn, và đặc biệt sản phẩm phải đến với khách hàng nhanh hơn và liên tục hơn.

Trong những năm gần đây, chuyển đổi số trong doanh nghiệp trở thành một điều tất yếu, các doanh nghiệp, tổ chức trong mọi lĩnh vực hiện đã và đang khai thác các chiến lược chuyển đổi số, từ các tổ chức tư nhân đến nhà nước Chuyển đổi số là số hóa toàn bộ cả một tổ chức Chuyển đổi số là thay đổi quy trình mới, mô hình tổ chức mới, phương thức cung cấp dịch vụ, tư duy mới cho nhân viên và việc khai thác các công cụ hỗ trợ mới DevOps và DevSecOps cũng chính là một phần trong chuỗi những thay đổi rất nhiều các doanh nghiệp đã bắt đầu áp dụng để tiến tới chuyển đổi số hoàn toàn.

Trải nghiệm người dùng ngày càng trở thành trung tâm, và khi đưa lại những trải nghiệm tốt nhất cho khách hàng thì sẽ đưa lại những lợi thế cạnh tranh khi mà thị trường sản phẩm công nghệ thông tin ngày càng bão hoà DevOps không phải sinh ra để rút ngắn quy trình hay thời gian phát triển, mà là để thời gian từ mã nguồn đến sản phẩm trở thành ngắn nhất, hay tức là đưa sản phẩm đến tay người dùng nhanh nhất có thể Hơn nữa, việc một sản phẩm đến được tay khách hàng, tất yếu sẽ sinh ra đóng góp, ý kiến và phản ảnh từ khách hàng, từ đó cho phép đổi mới và cải tiến liên tục sản phẩm Một sản phẩm được cập nhật liên tục, đúng với mong muốn, yêu cầu và có các tính năng mong đợi của khách hàng chắc chắn sẽ có lợi thế cực lớn so với các đối thủ.

DevSecOps đóng một vai trò nòng cốt, song hành với việc thay đổi tư duy phát triển sản phẩm để có thể tiến tới chuyển đổi số Vì vậy nên em đã lựa chọn đề tài “Nghiên cứu giải pháp DevSecOps trong hỗ trợ phát triển phần mềm” Thông qua đề tài em muốn chứng minh được những lợi ích vô cùng to lớn và thiết thực mà DevSecOps và tự động hoá có thể mang lại trong phát triển phần mềm, và đưa ra được một giải pháp tổng thể và thực tiễn để có thể áp dụng trong thực tế.

1.1.2 Mục tiêu nghiên cứu đề tài

- Nghiên cứu về lý thuyết của DevOps, và mở rộng ra DevSecOps trong hỗ trợ quy trình phát triển phần mềm.

- Đặt ra một giải pháp mang tính tổng thể theo tư duy DevSecOps để giải quyết bài toàn tự động hoá trong phát triển phàn mềm.

- Áp dụng giải pháp DevSecOps vào trong việc phát triển một ứng dụng web mô hình microservice.

1.1.3 Đối tượng và phạm vi

Các đội nhóm và doanh nghiệp phát triển sản phẩm, đặc biệt các đội nhóm đã và đang chuyển dịch, áp dụng Agile trong phát triển phần mềm.

Giải pháp sử dụng

1.2.1 Lịch sử phương pháp triển khai ứng dụng Ứng dụng là một phần đã giúp việc phổ biến hoá máy tính đến đại chúng, một trang web, một dịch vụ xử lí ảnh, một ứng dịnh tính toán trên mạng, tất cả đều là ứng dụng. Vậy ứng dụng chạy ở đâu? Hầu hết, nhất là các ứng dụng, dịch vụ online là chạy ở trên các máy chủ. a) Thời kì máy chủ vật lí

Thời kì sơ khai nhất, gần như chỉ có thể chạy một ứng dụng trên một máy chủ, đây là giới hạn đặc tính kĩ thuật của thời kì này.

Chính vì những hạn chế đó, mỗi khi doanh nghiệp cần có thêm, hoặc triển khai, mở rộng thêm các dịch vụ mới thì sẽ cần thêm một máy chủ mới Tuy nhiên, yêu cầu về hiệu năng của các ứng dụng hầu như không được làm rõ với những ứng dụng mới đó, nên việc chọn mua máy chủ mới phần lớn phụ thuộc vào suy đoán.

Từ vấn đề trên, sinh ra một các giải quyết đơn giản nhất: mua máy chủ phải to, phải mạnh, tốn nhiều tiền Lí do giải thích đơn giản là vì yêu cầu kĩ thuật hiệu năng không rõ ràng, các doanh nghiệp không bao giờ muốn ứng dụng sẽ chạy chậm chỉ vì phần cứng quá yếu, từ đó có thể mất khách hàng Kết cục là các máy chủ thường không bao giờ chạy hết hiệu năng tối đa, là một sự lãng phí tiền của rất lớn. b) Máy ảo

Hình 1.1 Cấu trúc của máy ảo

Những năm cuối của thế kỉ 20, máy ảo ra đời một cách rộng rãi Máy ảo ngay lập tức thay đổi các ứng dụng chạy trên máy chủ, cho phép nhiều ứng dụng có thể chạy trên một máy chủ duy nhất Từ đó cũng làm việc mua máy chủ mới cho ứng dụng mới biến mất, thay vào đó là sử dụng chính tài nguyên của những máy chủ sẵn có một các hiệu quả hơn.

Tuy nhiên, máy ảo không phải là một giải pháp hoàn hảo Mỗi máy ảo đều phải có một hệ điều hành hoàn chỉnh riêng biệt cho chính nó là một điểm trừ lớn Hệ điều hành sẽ tiêu tốn tài nguyên của máy chủ, gây lãng phí khi những tài nguyên đó có thể để sử dụng để chạy nhiều ứng dụng hơn Ngoài ra, mỗi hệ điều hành đều cần theo dõi và cập nhật, sửa lỗi Và trong một số trường hợp, hệ điều hành sẽ yêu cầu bản quyền.Tất cả các điều trên đều gây lãng phí thời gian và tài nguyên.

Chưa kể thêm mô hình máy ảo có một số điểm trừ khác như máy ảo thường khởi động chậm và tính di động không cao, một khi đã sử dụng một dạng máy ảo (hypervisor hoặc các nền tảng cloud) thì khá khó để có thể chuyển dịch sang một hypervisor hoặc một nhà cung cấp khác. c) Container và Docker

Các tập đoàn lớn trong mảng dịch vụ web, ví dụ như Google, đã sử dụng container để giải quyết các điểm yếu của máy ảo từ khá lâu.

Cơ bản thì một container có thể nói là ngang hàng với một máy ảo Điểm khác biệt rõ ràng nhất là container không cần có một hệ điều hành đầy đủ của riêng nó như máy ảo, mà thay vào đó là sẽ chia sẻ hệ điều hành với cả máy chủ (máy cho phép các container chạy trên nó) Điểm khác biệt này cũng giúp một lượng lớn tài nguyên như RAM, CPU và bộ nhớ dược giải phóng Ngoài ra còn giúp giảm được chi phí để mua bản quyền hệ điều hành, hay công sức để bảo trì, cập nhật, vá lỗi hệ điều hành Kết quả là giúp tiếp kiệm thời gian, tài nguyên và tiền bạc.

Container cũng có khả năng khởi động nhanh hơn và có tính di động rất cao Việc chuyển và chạy container từ laptop cá nhân, lên cloud, hay vào trong máy ảo, hoặc chạy trên một máy chủ trực tiếp đều rất dễ dàng.

Container hiện đại bắt nguồn từ thế giới Linux và là một sản phẩm được sinh ra từ sự góp sức khổng lồ từ rất nhiều người trông cộng đồng mã nguồn mở trong một thời gian dài Ví dụ như Google đã có rất nhiều công sức trong việc viết các phần liên quan đến công nghệ container cho Linux kernel, nếu không có những thành phần này, container hiện như như có hiện nay có thể không tồn tại.

Những công nghệ chính đã cho phép sự phát triển cực kì mạnh mẽ của container trong những năm gần đây có thể kể đến như kernel namespace, control group, union filesystem và Docker.

Tuy nhiên, trước khi có Docker, container vẫn là một công nghệ rất phực tạp và ngoài tầm với của phần lớn tổ chức Nhờ có Docker, container đã trở thành một công nghệ được phổ rộng hoá, cho phép đại chúng sử dụng một cách dễ dàng.

Và từ sự phổ rộng hoá của Docker nói riêng và container nói chung, đã sinh ra nhu cầu cần thay đổi từ máy ảo sang container trong quy trình phát triển và triển khai ứng dụng của doanh nghiệp Cùng với cách mà ứng dụng được phát triển cũng đang dần dịch chuyển theo một hướng mới.

Tuy nhiên container không phải sinh ra để thay thế hoặc cạnh tranh với máy ảo, thay vào đó là một sự cộng hưởng và cùng hỗ trợ với nhau để sinh ra một hệ thống phát triển và vận hành phần mềm phù hợp với thời kì hiện đại.

Hình 1.2 So sánh mô hình của container và máy ảo

Container là một đơn vị phần mềm độc lập, chứa tất cả các thành phần cần thiết để chạy một ứng dụng hoặc một website, một container bao gồm mã nguồn, các thư viện phụ thuộc, hệ điều hành độc lập và tài nguyên hệ thống ảo hóa Container giúp đóng gói và triển khai ứng dụng một cách đáng tin cậy và dễ dàng hơn, cũng như tăng tính di động, linh hoạt của ứng dụng cho phép các nhà phát triển có thể triển khai ứng dụng của mình trên nhiều nền tảng, môi trường khác nhau một cách đơn giản và nhanh chóng

Công nghệ sử dụng

1.3.1 Hệ thống quản lí mã nguồn và Gitea

Hệ thống quản lí mã nguồn sử dụng để theo dõi các thay đổi xảy ra trong một repository mã nguồn Cho phép lưu trữ lại lịch sử các thay đổi và giải quyết tranh chấp xảy ra khi ghép mã nguồn lại từ nhiều người khác nhau Để đảm bảo việc đội nhóm làm việc hiệu quả, hệ thống quản lí mã nguồn là tất yếu thay cho tất cả việc giao tiếp và quản lí mã nguồn bằng tay. a) Tầm quan trọng của hệ thống quản lí mã nguồn

Khi có nhiều người cùng làm trên một dự án, sẽ có trường hợp hai hoặc nhiều người cùng sửa một file mã nguồn cùng lúc Hai người có thể đang làm các chức năng khác hẳn nhau và cô lập với nhau, nhưng lại cùng sử dụng chung một module nào đó Vậy người 1 đang làm chức năng 1, có thể sẽ chỉnh sửa một file cùng với người 2 đang làm chức năng 2.

Trước khi có hệ thống quản lí mã nguồn, xung đột khi cùng chỉnh sửa một file có thể dẫn đến mất mát dữ liệu Bởi chỉ có các dạng giao thức lưu trữ file phổ thông như FTP, không có lịch sử nào lưu lại, người 1 có thể ghi đè lên những gì người 2 đã chỉnh sửa khi cùng phải sử dụng một file đó, dẫn đến mọi thay đổi của người 2 mất hoàn toàn do bị ghi đè.

Hệ thống quản lí mã nguồn với khả năng quản lí phiên bản bảo đảm khỏi việc mất mất dữ liệu vì xung đột ghi đè file Đảm bảo bằng cách theo dõi mọi sự thay đổi từ mọi người và phát hiện ra các chỗ có xung đột và chống ghi đè Và hệ thống sẽ cho phép người dùng dễ dàng kiểm định các chỗ có xung đột và xử lí một cách an toàn.

Ngoài ra, hệ thống cũng có cung cấp toàn lịch sử thay đổi của mã nguồn, cho phép tìm kiếm và xác định được lần chỉnh sửa nào đã gây ra lỗi hoặc giảm chất lượng phần mềm. b) Lợi ích của hệ thống quản lí mã nguồn

Hệ thống quản lí mã nguồn luôn đi kèm theo các công cụ giúp việc phối hợp công việc thân thiện cho người sử dụng hơn Từ việc hệ thống theo dõi sự thay đổi của mã nguồn sẽ cho phép sinh ra một lịch sử chi tiết về những thay đổi Và lịch sử này cho phép lùi lại những thay đổi gây ra lỗi, hỏng một cách rất đơn giản, cho phép chống lỗi diễn ra liên tục trên nhiều bản cập nhật và sửa lỗi dễ dàng hơn.

Lịch sử cũng có thể được sử dụng để sinh ra danh sách thay đổi giữa các phiên bản. Vừa có thể giúp người dùng biết điều gì đã thay đổi qua các bản cập nhật và tiến độ của dự án.

Loại bỏ được tiêu tốn thời gian do giao tiếp khi ghép mã nguồn thủ công, tăng tốc độ cung cấp sản phẩm, cho phép nhiều người làm việc cùng lúc, song song và độc lập trên nhiều tính năng khác nhau và có thể ghép lại sau đó. c) Git

Thực tế hiện tại, hệ thống quản lí mã nguồn phổ biến nhất thế giới là Git Git là một dự án mã nguồn mở vẫn đang được liên tục phát triển, phát triển đầu tiên bởi cha đẻ nổi tiếng của Linux kernel Linus Torvalds.

Một lượng khổng lồ các dự án phần mềm hiện nay phụ thuộc vào Git để quản lí mã nguồn, từ dự án thương mại đến các dự án mã nguồn mở Git có thể hoạt động trên hầu hết các hệ điều hành và các IDE phổ biến.

Git sử dụng kiến trúc phân tán, là một điển hình của hệ thống quản lí mã nguồn phân tán Khác với các hệ thống cũ mà chỉ chứa thay đổi trong mã nguồn ở một chỗ duy nhất như CVS hoặc Subversion (còn có tên khác là SVN), khi dùng Git, mỗi người có bản sao của toàn bộ repository mã nguồn cũng đều có toàn bộ lịch sử thay đổi.

Git cũng được thiết kế để đảm bảo hiệu năng, bảo mật và tính linh hoạt.

Sử dụng Git làm lõi, rất nhiều các dịch vụ đã được sinh ra như GitHub, GitLab, BitBucket Các dịch vụ này sinh ra nhằm cung cấp một giao diện web hoàn chỉnh hơn cho Git với nhiều các tính năng hỗ trợ khác giúp làm việc với Git dễ dàng hơn. d) Gitea

Gitea là một dịch vụ self-hosted cho quy trình phát triển phần mềm với rất nhiều tính năng và dễ dàng có thể cài đặt nhanh chóng.

Các chức năng chính của Gitea:

- Nơi chứa mã nguồn: Gitea cho phép tạo và quản lí repository, duyệt lịch sử commit và các file mã nguồn, duyệt và merge mã nguồn, quản lí cộng tác viên, quản lí nhánh và nhiều tính năng khác Cũng như kèm theo các tính năng phổ biến của Git như tag, cherry-pick, hook, …

- Nhẹ và nhanh: Mục tiêu thiết kế của Gitea là đạt được phản hồi nhanh và nhẹ nhất có thể để có thể hoạt động trên các môi trường máy chủ có giới hạn tài nguyên.

- Dễ triển khai và bảo trì: Có thể dễ dàng triển khai với nhiều máy chủ khác nhau mà không cần cấu hình phức tạp hoặc lo đến các thư viện, phần mềm phụ thuộc khác, từ đó cho phép kể cả các đội nhóm nhỏ cũng có thể tự dựng lên các dịch vụ Git dành riêng cho nhóm.

THIẾT KẾ GIẢI PHÁP DEVSECOPS TRONG PHÁT TRIỂN PHẦN MỀM

Bài toán đặt ra

Một đội ngũ phát triển cần phát triển một ứng dụng web áp dụng mô hình microservice, với yêu cầu cần có một hệ thống tự động hoá các giai đoạn như xây dựng, kiểm thử, triển khai và giám sát sau triển khai, yêu cầu toàn bộ giải pháp là mã nguồn mở để có thể phát triển thành các quy trình nội bộ về sau.

Khả năng liên tục cập nhật với các phiên bản build liên tục, đảm bảo downtime thấp nhất có thể và quy trình có thể tự động thực hiện chỉ với một tác động là lập trình viên với mã nguồn

Từ vấn đề trên sẽ cần có một giải pháp theo tư duy DevSecOps, kèm với bộ công cụ giải quyết các vấn đề, câu hỏi sau:

- Quản lí mã nguồn kiểu gì?

- Làm sao để build tự động?

- Làm sao để kiểm tra chất lượng mã nguồn tự động?

- Làm sao để triển khai tự động? Lưu trữ các artifact build ở đâu?

- Đảm bảo chất lượng phiên bản triển khai kiểu gì?

- Giám sát, theo dõi dịch vụ như nào? Cung cấp được những thông tin gì?

- Bảo mật và tính an toàn thông tin trong và sau quá trình phát triển được đảm bảo bởi điều gì? Để giải quyết bài toàn trên, câu trả lời ngắn gọn sẽ là cần một giải pháp DevSecOps, bao trùm toàn bộ vòng đời của việc phát triển ứng dụng trên, nghĩa là từ giai đoạn phát triển, đến giai đoạn triển khai, đến giai đoạn theo dõi sau triển khai và cập nhật, theo dõi sau triển khai.

Một giải pháp DevSecOps không mang tính chất một chiều mà là một vòng lặp vô hạn, đầu ra của giai đoạn, công cụ trước sẽ là đầu vào của công cụ sau Và sau triển khai cũng chỉ là một trong số hàng trăm, thậm chí hàng nghìn lần kết quả để đưa vào đầu vào cho giai đoạn phát triển phiên bản cải tiến tiếp theo.

Phân tích bài toán và đưa ra kiến trúc tổng quan của giải pháp

Phân tích theo hướng quy trình Đầu vào của giải pháp sẽ đơn giản là mã nguồn của đội lập trình, và sản phẩm đầu ra cuối cùng sẽ là một ứng dụng được triển khai thành công đến với người dùng Đây là mục tiêu quan trọng nhất của một giải pháp DevSecOps, đưa sản phẩm đến tay người dùng nhanh, tốt và hiệu quả nhất có thể.

Giải pháp bao gồm 4 giai đoạn, và lặp lại vòng tròn sau khi kết thúc giai đoạn 4: a) Giai đoạn 1:

Phát triển, là giai đoạn đầu tiên của giải pháp, việc chính ở đây là phát triển ứng dụng. Đầu ra: Mã nguồn sản phẩm được phát triển. b) Giai đoạn 2:

Tích hợp liên tục, giai đoạn này mục tiêu là để đưa mã nguồn trở thành dạng chạy được và được kiếm tra về chất lượng mã nguồn và tính bảo mật của mã nguồn đó một cách tự động Ở giải pháp này ứng dụng mô hình microservice nên việc sử dụng container image là tất yếu.

- Đầu vào: Mã nguồn của giai đoạn phát triển.

- Đầu ra: Docker image của mã nguồn sản phẩm, đã được thông qua các bước kiểm thử và được kiểm tra về tính bảo mật. c) Giai đoạn 3:

Triển khai liên tục, mục tiêu giai đoạn này là để đưa được ứng dụng đến với người dùng một cách tự động

- Đầu vào: Là Docker image của giai đoạn tích hợp liên tục.

- Đầu ra: Ứng dụng được triển khai trên cụm K8s, cho phép người dùng sử dụng, và các công cụ giám sát metric liên tục ghi dữ liệu theo dõi ứng dụng. d) Giai đoạn 4:

Giám sát, là giai đoạn cuối của một vòng tròn giải pháp DevSecOps, mục tiêu của giai đoạn này là thu thập các dữ liệu liên quan đến ứng dụng, từ mức phần cứng đến phần mềm, phục vụ cho mục đích đánh giá và giám sát được chất lượng của ứng dụng khi người dùng sử dụng Các dữ liệu sẽ được phân tích để đạt được các thông tin mong muốn.

- Đầu vào: Metric thu thập được trong quá trình ứng dụng chạy trên K8s.

- Đầu ra: Dữ liệu, thông tin về những điểm cần sửa đổi, các lỗi, lí do lỗi, hướng nâng cấp để trở thành đầu vào cho giai đoạn phát triển tiếp theo.

Hình 2.21 Vòng lặp quy trình phát triển

Phân tích theo hướng công nghệ áp dụng Ứng dụng web theo mô hình microservice Tức là việc áp dụng container cho đóng gói ứng dụng và sử dụng một hệ thống orchestrator là bắt buộc để có thể tự động hoá.

Lập trình viên tương tác với mã nguồn liên tục, và là một đội ngũ nhiều người Một hệ thống quản lí mã nguồn là bắt buộc để có thể hợp tác, có lịch sử đóng góp và trách nhiệm của từng cá nhân, chống mất mát dữ liệu và cho phép làm việc song song. Để liên tục cập nhật với các bản build mới liên tục, tức là phải tự động hoá quy trình biến mã nguồn thành dạng chạy được, thì phải có hệ thống hỗ trợ tích hợp liên tục và triển khai liên tục.

Và để hai hệ thống trên hoạt động được với nhau, thì phải có một nơi để lưu trữ các phiên bản artifact được build ra đó, tức là cần một hệ thống registry do đã lựa chọn sử dụng container để đóng gói ứng dụng.

Tiếp theo, để đảm bảo chất lượng mã nguồn và phiên bản triển khai, đi kèm với an toàn thông tin về tính bảo mật của container xây dựng ra, sẽ cần có hệ thống quét chất lượng mã nguồn tự động và công cụ quét lỗ hổng bảo mật cho container sau khi build.

Giám sát và theo dõi dịch vụ sẽ sử dụng service mesh, sau đó áp dụng thêm các công cụ mở rộng để lấy dữ liệu ra từ service mesh và phân tích dữ liệu đó thành thông tin có ý nghĩa Vì khi sử dụng service mesh, rất ít mã nguồn hoặc không cần sửa mã nguồn mà vẫn có thể đạt được khả năng giám sát với các thông số chi tiết.

Thành phần cấu trúc hệ thống theo công nghệ sử dụng

Hạ tầng triển khai bao gồm:

- 1 máy chủ Harbor có tích hợp Trivy ở trong.

- 1 cụm Kubernetes gồm 1 control plane và 1 worker, có cài đặt Argo CD, MetalLB và Istio trên cụm này.

Các máy chủ, hệ thống đều độc lập với nhau và chỉ giao tiếp qua Internet.

Hình 2.22 Các công nghệ sử dụng phân loại theo nhóm chức năng

Ngoài ra, các máy chủ được triển khai để có thể giao tiếp với nhau thông qua Internet,với tên miền và chứng chỉ SSL được cấu hình đi qua reverse proxy Nginx.

Luồng làm việc tổng quan của cả hệ thống

Hình 2.23 Luồng làm việc của hệ thống

Tích hợp liên tục

Hình 2.24 Quy trình tích hợp liên tục

Tích hợp liên tục sẽ chỉ có một thao tác duy nhất cần làm thủ công, đó là khi lập trình viên sử dụng lệnh git push để đưa bản mã nguồn sau khi phát triển lên trên hệ thống quản lí mã nguồn vào repository của mã nguồn ứng dụng.

Các thành phần sau được tự động hoá hoàn toàn khi cấu hình đúng các hệ thống với nhau

Trên cài đặt của repository mã nguồn ứng dụng sẽ cần tạo một webhook cấu hình với tên miền của máy chủ Jenkins, kèm theo branch sẽ theo dõi để gửi webhook khi có thay đổi về mã nguồn trong branch đó - ở đây cấu hình là mỗi commit sẽ gửi một lần.

Khi Jenkins nhận thấy được sự thay đổi của repository mã nguồn, sẽ tự động kích hoạt pipeline đã cấu hình từ trước, và cho phép tự động chạy pipeline đó thể thực hiện các thao tác:

- Đồng bộ mã nguồn mới với hệ thống quản lí mã nguồn.

- Gọi tới máy chủ SonarQube, sau khi máy chủ SonarQube quét xong sẽ lưu lại một bản báo cáo để có thể xem lại lúc sau.

- Đóng gói ứng dụng thành Docker image với lệnh docker build, tag sẽ tự động gắn với ID của phiên bản pipeline đang chạy của Jenkins, sau khi build xong sẽ dùng lệnh docker push để tải image lên trên máy chủ Harbor.

- Tải về repository cấu hình triển khai, sửa thông tin iamge tag để tương ứng với phiên bản vừa build xong của bước trước, sau đó tự commit lên trên repository đó. Ở trong máy chủ Harbor, sau khi nhận được image mới thì sẽ tự động thực hiện quét lỗ hổng bảo mật cho image đó và lưu lại báo cáo ứng với image đó trên Harbor.

Như vậy, kết thúc giai đoạn tích hợp liên tục, và kết quả của giai đoạn này là:

- Có được một container image sẵn sàng triển khai trên Harbor được kiểm thử và kiểm tra lỗ hổng bảo mật.

- Repository cấu hình triển khai đã đư0ợc cập nhật và sẵn sàng.

Triển khai liên tục

Hình 2.25 Quy trình triển khai liên tục

Triển khai liên tục phần lớn sẽ tự động hoàn toàn, trừ các thao tác sau do kĩ sư vận hành thực hiện:

- Tạo repository cấu hình triển khai.

- Có những thay đổi quá lớn không thể tự động cập nhật được trong quy trình tích hợp liên tục.

- Cấu hình Argo CD để tạo ứng dụng khi triển khai lần đầu, hoặc rollback trong trường hợp cần thiết.

Khi ở trường hợp là sau tích hợp liên tục, luồng làm việc tự động sẽ thực hiện các thao tác sau:

- Argo CD sẽ liên tục quét repository cấu hình triển khai để kiểm tra xem có cập nhật hay không.

- Khi phát hiện ra có thay đổi trên repository cấu hình triển khai, Argo CD sẽ đồng bộ dữ liệu đang có với bản mới của repository cấu hình triển khai.

- Argo CD sẽ sử dụng file cấu hình YAML để thực hiện việc triển khai ứng dụng trên cụm Kubernetes.

- Cụm Kubernetes sẽ nhận việc (chính là cấu hình), thực hiện việc tải image ứng với phiên bản mới, sau đó triển khai thật sự trên worker node.

Istio và MetalLB sẽ được cấu hình/cài đặt từ trước, đóng vai trò hạ tầng hỗ trợ ứng dụng ở đây và ít thay đổi:

- Istio sẽ là điểm để mở ứng dụng ở trong cụm Kubernetes ra mạng bên ngoài, cho phép người dùng truy cập được vào và thu thập metric của ứng dụng sau khi triển khai.

- MetalLB là cân bằng tải, cung cấp IP ngoài cho Istio và Argo CD trong hệ thống mạng Nếu không có MetalLB, Istio Ingress Gateway và Argo CD sẽ không thể có IP để truy cập vào.

Giám sát sau triển khai

Hình 2.26 Quy trình giám sát

Việc thu thập metric giám sát là hoàn toàn tự động sau khi triển khai ứng dụng, chạy liên tục 24/7 để thu thập các thông tin từ bản thân ứng dụng.

Istio Service Mesh cho phép thu thập metric ở mọi thành phần đã được thêm Envoy Proxy vào.

Chức năng của bộ công cụ giám sát trong hệ thống:

- Istio nằm giữa mọi thành phần, từ đó Istio có thể lấy được các metric.

- Prometheus sẽ đóng vai trò là một cơ sở dữ liệu chứa metric nhận được từ Istio.

- Grafana và Kiali là ứng dụng web đọc dữ liệu từ Prometheus để cung cấp một giao diện cho phép sử dụng các metric một cách có ý nghĩa Grafana đặc biệt có khả năng tuỳ biến rất sâu, cho phép tự tạo các bảng biểu theo metric tuỳ ý.

- Jaeger là cung cụ truy vết (tracing) mọi giao dịch giữa các thành phần trong ứng dụng, ví dụ ở đây là các request khi các microservice cần giao tiếp với nhau.

Luồng làm việc trong giai đoạn giám sát sau triển khai:

- Kĩ sư vận hành sẽ là người trực tiếp sử dụng các công cụ để giám sát.

- Khi có các vấn đề phát sinh phát hiện ra trong quá trình giám sát liên quan đến bên trong ứng dụng, sẽ giao tiếp hai chiều với lập trình viên để giải quyết.

- Khi các vấn đề liên quan đến hạ tầng như hiệu năng, hoặc các vấn đề về hệ thống thì kĩ sư vận hành sẽ là người giải quyết.

Mục tiêu của giám sát liên tục là để nâng cao chất lượng sản phẩm liên tục Đầu ra của giai đoạn này là metric được phân tích, từ đó đặt ra các bài toán mới để xử lí, và chính là đầu vào giai đoạn phát triển Đó là lí do quy trình DevSecOps là một vòng lặp cho đến hết vòng đời sản phẩm.

Thêm nữa, dù quyền hạn và trách nhiệm của đội phát triển và đội vận hành được tách biệt rõ ràng, nhưng không có nghĩa là lỏng lẻo mà là được chuyên biệt hoá ở mức cao hơn Thêm nữa việc giám sát liên tục như này đưa lại nhiều thông tin hơn rất nhiều so với cách giám sát truyền thống với lượng thông tin rất giới hạn.

Mô hình một microservice triển khai bằng Argo CD trên Kubernetes

Argo CD khi triển khai một microservice từ file cấu hình định sẵn, sẽ quản lí những thành phần sau trong Kubernetes:

- Pod: cho phép container chạy trên Kubernetes.

- ReplicaSet: quản lí Pod, cung cấp thêm khả năng tự hồi phục và scaling.

- Deployment: quản lí ReplicaSet, cung cấp thêm khả năng tiến lùi phiên bản.

- ServiceAccount: định danh cho các thành phần của ứng dụng trong K8s.

- Service: cung cấp một IP, tên trong DNS và port cố định cho ứng dụng.

- Endpoint và EndpointSlice: cung cấp danh sách các IP ở mạng đằng sau cho service (có thể đơn giản là IP của các Pod)

Hình 2.27 Các thành phần trong Kubernetes của một microservice được Argo CD quản lí

Tuy nhiên, ở đây có sử dụng thêm Istio, nên có một điểm khác biệt là ở trong một Pod sẽ bao gồm hai container chạy cùng với nhau Container Envoy Proxy sẽ đóng vai trò là đường giao tiếp ra vào cho container ứng dụng để có thể sử dụng các tính năng của Istio trong giám sát, tức là mọi dữ liệu vào ra qua mạng của container ứng dụng sẽ cần đi qua Envoy Proxy thì mới có thể đi ra tầng trên của mạng.

Kiến trúc microservice giao tiếp khi áp dụng Istio

Hình 2.28 Kiến trúc ứng dụng với Istio

Kiến trúc trên cho thấy được mối quan hệ của các microservice với nhau, và vai trò trực tiếp của Istio trong toàn bộ kết nối mạng của ứng dụng, từ giao tiếp giữa các microservice, đến việc mở ứng dụng ra ngoài cụm Kubernetes và là đường vào cho người dùng khi truy cập vào ứng dụng

CHƯƠNG 3: ÁP DỤNG GIẢI PHÁP

DEVSECOPS HỖ TRỢ PHÁT TRIỂN MỘT WEBSITE MÔ HÌNH MICROSERVICE

Chuẩn bị hệ thống áp dụng giải pháp DevSecOps

3.1.1 Cấu hình webhook trên Gitea Ở trong một repository microservice, chọn Settings.

Hình 3.29 Giao diện của một repository trên Gitea

Chọn Webhooks, chọn Add Webhook và thêm vào Target URL là tên miền của Jenkins với đuôi là /gitea-webhook/post và chọn Branch filter cho branch muốn thực hiện tích hợp liên tục, ở đây chọn branch main.

Hình 3.30 Cấu hình webhook tới Jenkins

3.1.2 Cấu hình Jenkins để nhận được webhook từ Gitea

Tạo một Pipeline trong Jenkins.

Hình 3.31 Giao diện tạo một luồng làm việc trên Jenkins Ở mục Build Triggers cấu hình các tuỳ chọn để Jenkins Pipeline tự động chạy khi nhận được webhook từ Gitea.

Hình 3.32 Các lựa chọn cần thiết cho Git của Jenkins Pipeline

Cấu hình Pipeline chạy Jenkinsfile tìm thấy ở trong repository Gitea.

Hình 3.33 Cấu hình URL của reposiory mã nguồn ứng dụng

Cấu hình các tài khoản và token cần để kết nối đến hệ thống khác:

- Harbor: Tài khoản và mật khẩu của một user robot để có thể push image sau khi build.

- Gitea: Tài khoản và mật khẩu để có thể commit lên repository cấu hinh triển khai.

- SonarQube: Token cho phép sử dụng máy chủ SonarQube để quét mã nguồn trong pipeline.

Hình 3.34 Các credential cần thiết để Jenkins giao tiếp với các hệ thống khác

3.1.3 Cấu hình token SonarQube để Jenkins sử dụng

Cần tạo token cho Jenkins dùng ở MyAccount => Security.

Hình 3.35 Giao diện quản lí token của SonarQube

3.1.4 Cấu hình tài khoản Harbor để tích hợp với Jenkins và cụm K8s

- User cho Jenkins: Để cho phép Jenkins push image.

- User cho cụm Kubernetes: Cho phép Kubernetes pull image.

Hình 3.36 Giao diện quản lí tài khoản robot của Harbor

Cấu hình tự động quét lỗS hổng bảo mật của image ngay sau khi được Jenkins push image lên ở mục Vulnerability scanning.

Hình 3.37 Giao diện cài đặt của một project trên Harbor

3.1.5 Tạo ứng dụng Argo CD và cấu hình tự động đồng bộ

Chọn New App, sau đó đặt tên ứng dụng trong Argo CD và bật tự động đồng bộ bằngSync Policy Automatic.

Hình 3.38 Giao diện tại ứng dụng Argo CD 1

Cấu hình nguồn là Git, và đưa đường dẫn Gitea của repository cấu hình triển khai vào kèm theo thư mục ở trong repository đó chứa các file yaml cần để triển khai ứng dụng này.

Chọn URL của cụm Kubernetes muốn triển khai, ở đây lựa chọn luôn cụm Kubernetes mà Argo CD đang được triển khai và chọn namespace sẽ dùng để triển khai ứng dụng này.

Hình 3.39 Giao diện tạo ứng dụng Argo CD 2

Cấu trúc của ứng dụng web Bookinfo

Hình 3.40 Cấu trúc ứng dụng Bookinfo Ứng dụng Bookinfo sẽ gồm 3 microservice:

- Microservice Productpage: là microservice mà người dùng có thể truy cập trực tiếp vào theo dạng một đường dẫn URL trên trình duyệt và là trang chủ của cả ứng dụng và gọi đến hai microservice Details và Reviews để hiển thị thông tin được hai microservice này trả về.

- Microservice Details: là microservice chứa thông tin của sách.

- Microservice Reviews: là microservice chứa thông tin đánh giá sách.

Thêm nữa, ứng dụng này có microservice đa ngôn ngữ lập trình, lần lượt là:

- Reviews: Viết bằng Java. Ứng dụng sẽ cung cấp trang web với trả về thông tin của sách và đánh giá nhận xét về sách đó, tất cà trên một giao diện web duy nhất.

Khi truy cập vào trang chủ chính là gọi vào microservice Productpage, và giao diện hiện ra gồm nội dung từ cả 3 microservice:

- Productpage: Cung cấp giao diện gồm tiêu đề trang web và phần miêu tả sách.

- Details: Thông tin của sách gồm (kiểu, số trang, nhà xuất bản, ngôn ngữ, mã ISBN).

- Reviews: Các nhận xét đánh giá về sách.

Hình 3.41 Giải thích giao diện ứng dụng microservice Bookinfo

Bài toán thực tế

Thực hiện việc cài đặt và cấu hình chuẩn bị thành công hệ thống sẽ có các thành phần sau:

- Một máy chủ Harbor, cài đặt dạng bật sẵn Trivy.

- Một cụm K8s với mô hình gồm 1 control plane node và 1 worker node, đã cài sẵn Argo CD, MetalLB và Istio, và kèm theo Kiali, Jaeger, Prometheus và Grafana.

Trạng thái của các hệ thống:

- Gitea hiện đã có ba repository mã nguồn của website gồm ba microservice: ProductPage, Details và Reviews của ứng dụng microservice Bookinfo phục vụ hiển thị thông tin của sách và một repository cấu hình triển khai để triển khai ứng dụng lên hạ tầng, được đồng bộ với Argo CD.

- Đã chạy quy trình CI/CD trước đây và đã triển khai thành công website lên cụm K8s.

Tình trạng hiện tại là đã cấu hình chuẩn bị các hệ thống chính xác và đã triển khai được ứng dụng lần đầu thành công Ở đây sẽ thấy tiêu đề là “Bookinfo Sample Update V2.0”, và tiêu đề này nằm trong microservice Productpage

Lập trình viên muốn đưa một bản cập nhật mới lên ở microservice trang chủ Productpage, đã viết xong mã nguồn cập nhật và sẵn sàng push lên repository Git của Productpage.

Mong đợi của lập trình viên là với mã nguồn là đầu vào, hệ thống sẽ tự động thực hiện mọi thao tác cần thiết từ build, kiểm thử, quét lỗ hổng bảo mật và triển khai để đưa bản cập nhật mới đến cho người dùng, và cho phép có các phương pháp giám sát ứng dụng web sau khi triển khai.

Bản cập nhật sẽ thay đổi phần tiêu đề “Bookinfo Sample Update V2.0” thành

Hình 3.42 Phần tiêu đề mong muốn cập nhật

Sử dụng giải pháp DevSecOps để triển khai phiên bản cập nhật cho ứng dụng web Bookinfo

3.4.1 Quy trình tích hợp liên tục

Lập trình viên sử dụng lệnh git push để đưa mã nguồn bản mới nhất lên, có đặt tag là

“Bump to version 3.0” (việc này được thực hiện trên máy tính cá nhân).

Hình 3.43 Giao diện terminal khi lập trình viên thực hiện git push

Trên trang repository Gitea tương ứng với microservice Productpage nhận được bản cập nhật mới nhất với tag đúng với tên lập trình viên đã đặt: “Bump to version 3.0”.

Hình 3.44 Trang web của repository mã nguồn

Truy cập vào Jenkins và kiểm tra Jenkins Pipeline tương ứng với microservice sẽ thấy pipeline được tự động chạy và thực hiện các thao tác được đặt trước ở trongJenkinsfile trên chính repository Gitea của productpage, và là phiên bản chạy số 16 của Pipeline này.

Hình 3.45 Giao diện Jenkins sau khi tự động chạy Pipeline

Kiểm tra trên SonarQube sẽ thấy báo cáo của SonarQube về mã nguồn mới, tức là ở đây Jenkins Pipeline đã gọi sang SonarQube và yêu cầu SonarQube thực hiện việc quét chất lượng mã nguồn và kiểm thử mã nguồn

Hình 3.46 Trang chủ của SonarQube với kết quả quét mã nguồn mới

Kiểm tra máy chủ Harbor cho thấy Harbor đã nhận được image mới với tag là 16,tương ứng với phiên bản build của Pipeline bên Jenkins.

Hình 3.47 Giao diện quản lí artifact của repository bookinfo-productpage

Thông tin khi xem báo cáo của Trivy sau khi quét image mới ở trong chính Harbor cho thấy đúng tag của image vừa build, kèm theo các lổ hổng bảo mật Trivy phát hiện ra sau khi quét image.

Hình 3.48 Kết quả quét lỗ hổng bảo mật image của Trivy

Repository cấu hình triển khai trên Gitea có một cập nhật mới do Jenkins tự động thực hiện với tên commit từ Jenkins báo đã cập nhật được microservice productpage lên phiên bản image 16.

Hình 3.49 Giao diện của repository cấu hình triển khai sai khi cập nhật

Vậy trong quy trình tích hợp liên tục, có thể thấy được hệ thống chạy tự động hoàn toàn chỉ với một thao tác thủ công của lập trình viên là git push mã nguồn lên Gitea, và sau khi kết thúc quy trình tích hợp liên tục, sản phẩm đầu ra lúc này bao gồm:

- Một báo cáo về chất lượng mã nguồn trên SonarQube.

- Một báo cáo về lỗ hổng bảo mật của image từ Trivy trên Harbor

- Một image trên Harbor sẵn sàng để được triển khai.

- Repository cấu hình triển khai được cập nhật tự động, chuẩn bị cho triển khai.

Có thể thấy được tích hợp liên tục đã đảm bảo được phần Dev và phần Sec của giải pháp DevSecOps với việc đầu ra có một sản phẩm sẵn sàng để chạy (Dev thành công) và sản phẩm đó đã được thông qua kiểm thử, quét mã nguồn và quét lỗi hổng bảo mật (đảm bảo an toàn thông tin – Sec thành công).

3.4.2 Quy trình triển khai liên tục

Argo CD tự động đồng bộ với commit mới của repository cấu hình triển khai, sau đó thực hiện yêu cầu cụm Kubernetes triển khai phiên bản mới cho microservice productpage.

Hình 3.50 Giao diện Argo CD sau khi tự động đồng bộ với repository cấu hình triển khai

Kiểm tra bằng kubetctl có thể thấy sự thay đổi của microservice productpage, chứng minh được rằng phiên bản mới đã được triển khai thành công và thay thế gọn gàng phiên bản cũ trong thời gian thực, không có downtime cho người dùng kể cả lúc đó người dùng vẫn đang sử dụng.

Hình 3.51 Kết quả kubectl trước khi cập nhật

Hình 3.52 Kết quả kubectl sau khi cập nhật Ứng dụng web đã được thay đổi sau khi cập nhật, tiêu đề đã được cập nhật và thay đổi so với phiên bản trước, từ “Bookinfo Sample Update V2.0” đã trở thành “BookInfo Sample UPDATE V3.0”, chứng tỏ việc triển khai phiên bản cập nhật mới đã thành công và cho phép người dùng sử dụng ngay lập tức.

Hình 3.53 Giao diện ứng dụng sau khi cập nhật

Như vậy, kết thúc triển khai liên tục, đầu ra chính là mong đợi của lập trình viên, từ mã nguồn đã biến thành sản phẩm dùng được cho người dùng, được triển khai trực tiếp và tự động lên hạ tầng K8s Phiên bản cập nhật được triển khai có tính liền mạch đến mức người dùng sẽ không thấy được downtime, bởi trên thực tế downtime không có.

Giao diện của Kiali cho thấy luồng chạy dữ liệu giữa các microservice khi có tải, và ở đây có thể thấy rất rõ mối liên hệ giữa các microservice, và rất nhiều thông số khác như tốc độ phản hồi, lương truy cập trên giây, phản hồi các request thành công hay thất bại với mã lỗi HTTP và nhịp độ của request (nhanh hay chậm).

Hình 3.54 Giao diện biểu đồ của Kiali để theo dõi ứng dụng

Màn hình Jaeger của một request, cho phép phân tích chi tiết thông tin của request này.

- Istio Gateway tức là request của người dùng đầu vào, gọi tới productpage.

- Sau đó productpage gọi tới details và được details trả lại dữ liệu.

- Điều tương tự xảy ra giữa productpage và reviews.

Từ các thông tin truy vết này, có thể tìm lỗi ở mức độ rất chi tiết: request thất bại ở đâu, do microservice nào, khi các microservice nào gọi nhau, và các request cũng như response là gì.

Hình 3.55 Giao diện phân tích một request của Jaeger

Màn hình Grafana Dashboard về hệ thống Istio.

Giai đoạn giám sát này cung cấp cho đội vận hành một cái nhìn chuyên sâu hơn về thông tin khi ứng dụng đang chạy sau khi triển khai thành công, hỗ trợ trong việc truy vết, sửa lỗi và theo dõi trên thời gian thực “sức khoẻ” của ứng dụng Các thông tin này được thu thập bởi Istio trong quá trình chạy, bởi Istio đã thêm envoy proxy vào mọi thành phần của các microservice của ứng dụng, và từ các thông tin đó cho phép các công cụ như Kiali, Jaeger sẽ hình tượng hoá, biểu đồ hoá và trở thành dữ liệu có ích.

Từ chính những thông tin, dữ liệu có ích này sẽ là đầu vào hỗ trợ cho phiên bản cập nhật tiếp theo của ứng dụng.

Giải pháp DevSecOps và giải pháp truyền thống

3.5.1 Nếu thực hiện triển khai cập nhật ứng dụng web Bookinfo bằng giải pháp truyền thống

Giải pháp truyền thống sẽ có khác biệt hoàn toàn về hạ tầng triển khai, không có bất kì công cụ tự động nào mà thay vào đó, hệ thống sẽ đơn giản chỉ gồm:

- 1 máy chủ chạy microservice Producpage.

- 1 máy chủ chạy microservice Details.

- 1 máy chủ chạy microservice Reviews.

Hệ thống này sẽ triển khai với các giai đoạn sau:

- Lâp trình viên phát triển và build thử trên máy cá nhân để đảm bảo chạy được, sau đó đưa mã nguồn lên một repository tập trung.

- Kiểm thử viên sẽ sử dụng mã nguồn ở repository tập trung, build thành một bản trên máy cá nhân và thực hiện kiểm thử cả mã nguồn lẫn ứng dụng sau khi build.

- Sau khi kiểm thử đạt, đội vận hành sẽ thực hiện việc build cho từng microservice trên máy chủ dành cho microservice đó và sau đấy thực hiện chạy các microservice trên ba máy chủ dó.

Như vậy có thể thấy việc cập nhật một microservice Productpage như bài toàn thực tế đặt ra có thể không gây ảnh hưởng đến cho hai microservice Details và Reviews kể cả triển khai Productpage thất bại và sử dụng phương pháp triển khai truyền thống nhờ vào việc mô hình của ứng dụng dựa theo microservice, và 3 microservice nằm ở các máy chủ độc lập nhau.

Tuy nhiên, không ảnh hưởng nhưng vẫn có thể sinh ra downtime nếu triển khai thất bại, bởi vì thao tác sẽ thực hiện thủ công nên việc khôi phục lại trạng thái trước có thể mất thời gian đáng kể.

3.5.2 So sánh giải pháp DevSecOps và giải pháp truyền thống

Giải pháp DevSecOps Giải pháp truyền thống

Tự động hoá phần lớn hoặc toàn bộ

Thủ công bằng tay phần lớn các công đoạn

Tốc độ triển khai (thời gian từ mã nguồn đến người dùng)

Rất nhanh, thường gần với thời gian biên dịch và đóng gói mã nguồn

Chậm, do cần cài đặt thư viện, cóp thủ công mã nguồn hoặc binary lên trên máy chủ triển khai

Downtime Rất thấp, thông thường sẽ là không có Gián đoạn theo tốc độ của người triển khai, dịch vụ có thể dừng hoạt động hoàn toàn

Thấp do ít yếu tố con người tác động trực tiếp và độ nhỏ của bản cập nhật

Rủi ro lớn do có nhiều tác động trực tiếp của con người vào mọi thao tác triển khai và độ lớn của bản cập nhật

Thấp vì áp dụng container Cao vì có thể là máy ảo hoặc máy chủ vật lý Khả năng scale

Có khả năng scale lớn và dễ dàng, có thể tự động scale để đáp ứng nhu cầu khi tăng giảm tải

Scale mang tính chất vật lý nhiều, và khi scale có thể dẫn đến downtime

Dễ dàng đảm bảo nhờ các quy trình tự động và sự phối hợp chặt chẽ từ các đội nhóm

Có thể khó khăn do tính tách rời của đội nhóm phát triển và đội nhóm kiểm thử Độ tương thích với mô hình ứng dụng microservice

Rất tốt vì sử dụng container làm nền tàng, từ kết nối giữa các microservice đến việc triển khai đều được hỗ trợ bởi các công nghệ trên hạ tầng

Phức tạp vấn đề vì phải cài đặt, cấu hình thủ công từ mức mã nguồn đến hạ tầng triển khai, kết nối giữa các microservice trở nên phức tạp hơn

Khả năng giám sát Đơn giản, không cần chỉnh sửa mã nguồn nhiều, metric dễ dàng thu thập và phân tích

Thường phải thay đổi mã nguồn lớn để lấy được các metric mong muốn, và các công cụ phân tích có thể phải tự phát triển

Bảng 3.1 Bảng so sánh điểm mạnh của DevSecOps so với phương pháp truyền thống

Đánh giá việc sử dụng giải pháp DevSecOps trong phát triển phần mềm .58 KẾT LUẬN

Việc áp dụng quy trình DevSecOps trong trường hợp tốt nhất như trên đã rút ngắn thời gian mà sản phẩm cung cấp từ đội ngũ phát triển đến khách hàng xuống thấp chưa từng có, có thể nhanh đến mức chỉ vài phút, với một thao tác thủ công duy nhất là lập trình viên push mã nguồn lên repository Git, thì phiên bản mới đã ngay lập tức có thể sử dụng bởi người dùng.

Thêm nữa, việc quy trình hoàn toàn tự động kể từ sau khi lập trình viên push mã nguồn, tránh được hoàn toàn khả năng lỗi con người có thể phát sinh khi vận hành bằng tay Tính thống nhất trong toàn bộ quy trình sẽ quy lại về một đối tượng duy nhất: container image Đội ngũ lập trình, đội ngũ kiểm thử, và đội vận hành hệ thống sẽ có chung một phiên bản giống hệt nhau đến từng bit cho công việc của mỗi đội ngũ.

Việc có thể theo dõi giám sát kể cả sau khi triển khai, với dữ liệu thu thập được theo thời gian thực, thì cho phép sử dụng chính những dữ liệu giám sát đó, phân tích và tạo thành những bài toán mới, những vấn đề mới để trở thành công việc tiếp theo cho đội ngũ phát triển ở mở đầu của một vòng lặp cập nhật tiếp theo.

Tóm lại, việc áp dụng một giải pháp DevSecOps, vào trong một mô hình microservice đã biến việc phát triển phần mềm trở nên hiệu quả, nhanh gọn bởi khả năng tự động hoá, tính thống nhất và bài bản trong toàn bộ quy trình phát triển, từ đó cho phép việc phát triển ứng dụng, phần mềm với một tốc độ rất cao, nhịp độ cập nhật đều đặn và sẽ đưa lại những giá trị về mặt kinh tế cũng như sự hài lòng trải nghiệm của người dùng.

Qua quá trình xây dựng đồ án, đạt được những kết quả:

- Nắm được tư tưởng DevSecOps trong phát triển phần mềm.

- Nghiên cứu chuỗi công nghệ, công cụ mã nguồn mở áp dụng cho các giai đoạn trong một giải pháp DevSecOps hoàn chỉnh.

- Đặt ra một giải pháp ví dụ khi phát triển một phần mềm mô hình microservice.

- Hiểu biết về cài đặt và dựng các hệ thống máy chủ.

- Hiểu biết thêm về cách cấu hình các hệ thống trong giải pháp DevSecOps.

- Khả năng nắm bắt và quản lí toàn bộ hạ tầng công nghệ thông tin cần cho phát triển và triển khai phần mềm.

- Các kĩ năng phân tích và giải quyết vấn đề để đưa ra giải pháp DevSecOps phù hợp với các tình huống khác nhau.

- Nghiên cứu giải pháp phát triển phần mềm hướng cloud native.

- Hoàn thiện giải pháp hiện tại để ứng dụng trong trường hợp các môi trường kiểm thử và production khác nhau và cho các kiểu tổ chức đội nhóm khác nhau.

- Nghiên cứu các công nghệ và khái niệm mới nhất của cloud native để hướng tới tự động hoá với các môi trường hybrid cloud.

- Áp dụng giải pháp cho các dịch vụ cloud và các công cụ quản trị doanh nghiệp như Jira.