Trường hợp sử dụng – Triển khai liên tục vào môi trường chưa biết với Docker, Mesosphere, Artifactory và Bintray

Talk Transcription:

(Gilad) Chúng ta sẽ cùng nhau tìm hiểu về cách thực thi quy trình CI/CD tại VMware. Trước tiên, tôi muốn cung cấp một chút bối cảnh về Common SaaS Platform (CSP) – nền tảng SaaS dùng chung mà VMware đang phát triển nội bộ. Lưu ý, đây không phải là một sản phẩm thương mại, chỉ là ví dụ kỹ thuật nội bộ. Tiếp theo, chúng ta sẽ đi sâu vào quy trình CI/CD áp dụng cho CSP, sau đó tìm hiểu về quy trình nâng cấp CSP khi đã triển khai thực tế. Nếu còn thời gian, tôi sẽ chia sẻ thêm về Xenon – framework mã nguồn mở cho distributed control plane từ VMware.

Tôi là Gilad, kiến trúc sư tại VMware, cùng với Kiril Nesenko – trưởng nhóm DevOps. Chúng tôi thuộc bộ phận phát triển dịch vụ cho các nhà cung cấp đám mây (cloud provider software). Nói đơn giản, nhóm chuyên tạo ra các dịch vụ dành cho các đối tác cung cấp hạ tầng đám mây.

Có thể bạn sẽ thắc mắc: VMware ngoài các giải pháp như vSphere còn phát triển các dịch vụ nào khác? Hiện tại, VMware đang chuyển đổi từ công ty thuần sản phẩm sang công ty định hướng dịch vụ phần mềm. vSphere vẫn tiếp tục được phát triển, song VMware ngày càng mở rộng các dịch vụ SaaS. Qua quá trình triển khai SaaS, chúng tôi nhận ra có nhiều điểm kết nối chung giữa các dịch vụ nội bộ như hệ thống billing, xác thực, monitoring… Đa số dịch vụ đều phải tích hợp với các hệ thống chung này để cung cấp trải nghiệm xuyên suốt cho người dùng (ví dụ đăng nhập chỉ với một tài khoản VMware ID, không cần tạo nhiều tài khoản khác nhau).

Thực tế, developer thường không thích viết code tích hợp với các hệ thống như billing – quá trình này vừa phức tạp, vừa tốn thời gian (thường gặp API SOAP hoặc xử lý lượng lớn XML). Vì vậy, nhóm kỹ sư VMware quyết định tập trung nguồn lực xây dựng một nền tảng dùng chung – CSP – giúp các dịch vụ nội bộ chỉ cần tập trung phần business logic, còn mọi tích hợp với hệ thống billing, xác thực… CSP sẽ đảm nhận.

CSP mà nhóm chúng tôi xây dựng hướng tới các nguyên tắc thiết kế: Độc lập nền tảng đám mây (cloud agnostic), Khả năng mở rộng & sẵn sàng cao, Public API mạnh mẽ cho nội bộ, modular và dễ dàng vận hành. Thay vì cố gắng phát triển một hệ thống độc quyền, CSP chỉ cần hạ tầng hỗ trợ container – ví dụ: deploy một container chạy file jar trên bất kỳ cloud provider nào. Dữ liệu lưu trữ trực tiếp trên platform (không dùng CSDL phía sau), tận dụng file system cho backup và recover.

Về scale, CSP triển khai dạng cluster động, sử dụng giao thức SWIM để thêm node linh hoạt. Toàn bộ API CSP đều là public, các chức năng là các thư viện đóng gói dạng jar, giao tiếp qua public API – không có “lối tắt” nội bộ. CSP chỉ cần deploy một file jar duy nhất, không phụ thuộc Tomcat, không dựa trên Spring Bootstrap mà tối ưu cho mục đích nội bộ. Kết quả, nền tảng CSP trở nên đơn giản, dễ vận hành và phát triển.

Triển khai thực tế CSP gồm các container đơn lẻ, mỗi container chứa một jar (platform), kết nối với nhau qua ad-hoc network. Mỗi lần cần scale chỉ việc “kéo” thêm container mới, cung cấp IP peer là xong. Tuy nhiên, trọng tâm hôm nay sẽ chuyển sang quy trình CI/CD, và Kiril sẽ trình bày chi tiết quy trình DevOps áp dụng cho CSP.

(Kiril)

Quy trình CI/CD mà chúng tôi áp dụng cho CSP là một điển hình có thể chia sẻ và áp dụng lại. Hầu hết thành phần sử dụng mã nguồn mở (open source), bạn hoàn toàn có thể tái sử dụng cấu trúc này cho hệ thống của mình với các công cụ tương tự hoặc thay thế linh hoạt.

Mô hình hệ thống ở cấp cao bao gồm Gerrit (code review), Git (source control), Jenkins (CI server), Artifactory, Bintray (phân phối artifact) và nhiều môi trường triển khai. Về orchestration, CSP dùng Docker container và chạy trên hạ tầng Mesos (có thể thay thế bằng Kubernetes hoặc Swarm nếu cần). Mesos chịu trách nhiệm điều phối toàn bộ hệ thống.

Các môi trường triển khai gồm tự động hóa, lead, staging, production và cả môi trường của khách hàng. Quy trình diễn ra như sau: developer gửi commit, chuyển qua hệ thống review, Jenkins sẽ đảm nhiệm khâu kiểm thử, build, phân tích mã nguồn. Artifact sau cùng là Docker Image được lưu trong internal Docker Artifactory, sau đó deploy & test trên automation environment (Mesos). Nếu ổn, Artifact sẽ được đẩy lên Bintray cho khách hàng tải về hoặc chuyển thẳng lên Docker registry của riêng khách hàng. Hệ thống deploy không theo từng commit mà thường nhật hoặc theo lịch phù hợp.

Trong triển khai, Mesos đảm nhận orchestration với ba master node, sử dụng Marathon làm scheduler cho các Docker slave. Marathon-lb dùng để cân bằng tải nội bộ, có thể kết hợp load balancer bên ngoài tuỳ trường hợp.

Các công cụ sử dụng: Artifactory & Bintray (artifact), Jenkins (CI), Git (SCM), Gerrit (code review), Dockers làm Jenkins slave linh động (spin up slave container khi cần). Infrastructure gồm Mesos, Docker. Sonar là giải pháp phân tích mã nguồn; Gradle, Makefile để build; các công nghệ phát triển gồm Java, JavaScript, Python, Go; Automation sử dụng shell Python; thông báo qua Slack.

Nội bộ hệ thống có khoảng 300 job Jenkins (và tăng lên theo nhu cầu), các dự án đều được tách Git repo riêng cho dễ kiểm soát và quản lý pipeline. Ngưng sử dụng UI Jenkins cho việc quản trị job hàng loạt, chuyển sang quản lý cấu hình dưới dạng YAML với Jenkins Job Builder (dự án open source của OpenStack). Bạn có thể lưu cấu hình job dạng yaml trong Git, từ đó tự động sinh ra file XML khi Jenkins chạy – giúp tiết kiệm thời gian, giảm sai sót thủ công và dễ dàng backup hoặc phục hồi toàn bộ cấu hình job qua Git.

YAML file hỗ trợ template, giúp kế thừa cấu hình dùng chung và chỉ cần điều chỉnh những tham số khác biệt, ví dụ một thay đổi cần cập nhật hàng loạt job chỉ cần chỉnh chỉnh ở template chính – toàn hệ thống sẽ tự động đồng bộ. Các kịch bản shell, Groovy, Python đều có thể nhúng trong yaml và quản trị tập trung.

Các dạng job chủ đạo: gating job (nghe patch-set-created, dùng để build/test/post kết quả về hệ thống review), build job (build rpm, war, jar, docker…), listener job (nghe change-merged để kích hoạt dynamic pipeline). Mỗi thay đổi đều cần qua step review: Jenkins test/build/code coverage, xét duyệt qua Gerrit, và phải có xét duyệt thủ công bởi developer khác trước khi merge. Khi patch được merge, hệ thống tự động triển khai dynamic pipeline dựa trên BuildFlow plugin (cho phép orchestrate quy trình bằng code Groovy).

Chuỗi CI/CD này đảm bảo mọi thay đổi đều được kiểm soát minh bạch, fail sẽ tự động báo về Slack, giúp developer nhanh chóng tiếp cận và khắc phục. Pipeline triển khai dạng song song, tự động kiểm tra, build, test, phân tích source code, code coverage, đẩy Docker image qua các môi trường automation, R&D, staging, production. Hệ thống hỗ trợ blue-green deployment, data integration và hoạt động xoá/hủy cluster cũ tự động. Mỗi commit có thể tuỳ chỉnh chuỗi pipeline phù hợp loại dự án và đặc thù môi trường.

Để đạt tiêu chuẩn CI/CD liên tục, yêu cầu hệ thống test tự động và monitor thật mạnh mẽ. Jenkins đảm nhận vai trò này, chạy nhiều pipeline song song với các dài/ngắn khác nhau, tất cả dùng chung base code. Có các job chuyên dò quét dependency open source và tích hợp tự động với hệ thống nội bộ VMware để đảm bảo compliance, license…

(Gilad)

Chúng tôi đã xây dựng pipeline CI/CD toàn diện: từ máy developer, build nội bộ, kiểm tra pháp lý, bảo mật source open source, cho đến khâu chuyển sản phẩm vào vận hành thật trên production – chỉ qua một pipeline duy nhất.

Khi lên production, việc nâng cấp CSP yêu cầu xử lý đặc biệt vì hệ thống lưu trạng thái (stateful platform). Các mẫu nâng cấp như blue-green, red-black và rolling upgrade được áp dụng để đảm bảo tối ưu – mục tiêu chính là giảm tối đa downtime, đảm bảo khách hàng không bị ảnh hưởng khi nâng cấp, đồng thời đảm bảo quá trình nâng cấp schema kết hợp nâng cấp business logic liền mạch trên cùng một nền tảng dữ liệu.

Thách thức: CSP dạng cluster đối xứng, không thể thêm node với version mã khác nhau nên luôn cần blue-green deploy khi upgrade. Layer business logic và data persistency luôn bám sát nhau. Giải pháp: xây dựng cơ chế upgrade qua chu kỳ migration, mỗi chu kỳ sẽ copy dữ liệu từ cluster cũ sang cluster mới, phân tích các metric về hiệu suất và decide khi nào cắt traffic, tiến hành migration lần cuối (khoá traffic vào proxy, backup delta còn lại), trả traffic về cluster mới và giữ cluster cũ để phòng rủi ro.

Ví dụ: Ở lần migration đầu, hệ thống copy 50 triệu bản ghi hết 25 giây, kiểm tra metric chốt threshold, tiếp tục migration tiếp (6 triệu bản ghi, 5 giây), đến vòng cuối chỉ còn vài nghìn bản ghi (<1 giây). Khi delta dưới ngưỡng threshold, hệ thống sẽ chính thức cut-over chuyển toàn bộ traffic qua cluster mới.

CSP được xây dựng dựa trên Xenon – framework open source distributed control plane của VMware. Khi phát triển một nền tảng SaaS, thường cần orchestration, persistency layer, translation/ORM, coordination, UI server, caching, message bus… Xenon tổng hợp phần lớn các lớp này thành một nền tảng “pin sạc” sẵn sàng dùng: REST APIs, data persistency, leader election, pub-sub, metric, UI serve… giúp giải quyết bài toán “zoo công nghệ” gây phức tạp khi vận hành và phát triển. Xenon cung cấp microservice/nanoservice, dễ mở rộng và tích hợp.

Cảm ơn bạn đã quan tâm! Nếu bạn cần tư vấn về triển khai CI/CD hiện đại, phát triển nền tảng SaaS hoặc muốn tìm hiểu các giải pháp tối ưu hoá DevOps, hãy liên hệ đội ngũ Softribution để được hỗ trợ chuyên sâu hoặc đặt mua các giải pháp phù hợp với nhu cầu doanh nghiệp của bạn.

Additional Resources:

• Artifactory as your Docker Registry
• How to set up a Private, Remote and Virtual Docker Registry