Tại True Engineering, chúng tôi đã thiết lập một quy trình liên tục phân phối các bản cập nhật tới máy chủ của khách hàng và muốn chia sẻ trải nghiệm này.
Để bắt đầu, chúng tôi đã phát triển một hệ thống trực tuyến cho khách hàng và triển khai nó trong cụm Kubernetes của riêng chúng tôi. Giờ đây, giải pháp tải trọng cao của chúng tôi đã chuyển sang nền tảng của khách hàng, nơi chúng tôi đã thiết lập quy trình Triển khai liên tục hoàn toàn tự động. Nhờ đó, chúng tôi đã đẩy nhanh thời gian đưa ra thị trường - đưa ra những thay đổi đối với môi trường sản phẩm.
Trong bài viết này, chúng tôi sẽ nói về tất cả các giai đoạn của quy trình Triển khai liên tục (CD) hoặc phân phối các bản cập nhật cho nền tảng của khách hàng:
- Quá trình này bắt đầu như thế nào?
- đồng bộ hóa với kho Git của khách hàng,
- lắp ráp backend và frontend,
- triển khai ứng dụng tự động trong môi trường thử nghiệm,
- triển khai tự động tới Prod.
Chúng tôi sẽ chia sẻ chi tiết thiết lập trong quá trình thực hiện.
1. Khởi động CD
Triển khai liên tục bắt đầu bằng việc nhà phát triển đẩy các thay đổi lên nhánh phát hành của kho lưu trữ Git của chúng tôi.
Ứng dụng của chúng tôi chạy trên kiến trúc microservice và tất cả các thành phần của nó được lưu trữ trong một kho lưu trữ. Nhờ đó, tất cả các vi dịch vụ đều được thu thập và cài đặt, ngay cả khi một trong số chúng đã thay đổi.
Chúng tôi đã tổ chức công việc thông qua một kho lưu trữ vì nhiều lý do:
- Dễ phát triển - ứng dụng đang tích cực phát triển, vì vậy bạn có thể làm việc với tất cả mã cùng một lúc.
- Một quy trình CI/CD duy nhất đảm bảo rằng ứng dụng dưới dạng một hệ thống duy nhất vượt qua tất cả các thử nghiệm và được chuyển đến môi trường sản xuất của khách hàng.
- Chúng tôi loại bỏ sự nhầm lẫn trong các phiên bản - chúng tôi không phải lưu trữ bản đồ các phiên bản microservice và mô tả cấu hình của nó cho từng microservice trong tập lệnh Helm.
2. Đồng bộ với kho Git mã nguồn của khách hàng
Những thay đổi được thực hiện sẽ tự động được đồng bộ hóa với kho Git của khách hàng. Ở đó, tập hợp ứng dụng được cấu hình, tập hợp này được khởi chạy sau khi cập nhật nhánh và triển khai để tiếp tục. Cả hai quá trình đều bắt nguồn từ môi trường của chúng từ kho lưu trữ Git.
Chúng tôi không thể làm việc trực tiếp với kho lưu trữ của khách hàng vì chúng tôi cần môi trường riêng để phát triển và thử nghiệm. Chúng tôi sử dụng kho Git của mình cho những mục đích này - nó được đồng bộ hóa với kho Git của họ. Ngay sau khi nhà phát triển đăng các thay đổi lên nhánh thích hợp trong kho lưu trữ của chúng tôi, GitLab sẽ ngay lập tức gửi những thay đổi này cho khách hàng.
Sau này, bạn cần phải thực hiện việc lắp ráp. Nó bao gồm một số giai đoạn: lắp ráp phụ trợ và giao diện người dùng, thử nghiệm và chuyển giao cho sản xuất.
3. Lắp ráp backend và frontend
Xây dựng backend và frontend là hai nhiệm vụ song song được thực hiện trong hệ thống GitLab Runner. Cấu hình lắp ráp ban đầu của nó nằm trong cùng một kho lưu trữ.
.
GitLab Runner lấy mã từ kho lưu trữ được yêu cầu, lắp ráp nó bằng lệnh xây dựng ứng dụng Java và gửi nó đến sổ đăng ký Docker. Tại đây, chúng tôi tập hợp phần phụ trợ và giao diện người dùng, lấy hình ảnh Docker mà chúng tôi đưa vào kho lưu trữ ở phía khách hàng. Để quản lý Docker image chúng tôi sử dụng .
Chúng tôi đồng bộ hóa các phiên bản hình ảnh của mình với phiên bản phát hành sẽ được xuất bản trong Docker. Để hoạt động trơn tru, chúng tôi đã thực hiện một số điều chỉnh:
1. Các container không được xây dựng lại giữa môi trường thử nghiệm và môi trường sản xuất. Chúng tôi đã thực hiện các tham số hóa để cùng một vùng chứa có thể hoạt động với tất cả cài đặt, biến môi trường và dịch vụ cả trong môi trường thử nghiệm và trong môi trường sản xuất mà không cần xây dựng lại.
2. Để cập nhật ứng dụng qua Helm, bạn phải chỉ định phiên bản của ứng dụng đó. Chúng tôi xây dựng phần phụ trợ, giao diện người dùng và cập nhật ứng dụng - đây là ba nhiệm vụ khác nhau, vì vậy điều quan trọng là phải sử dụng cùng một phiên bản ứng dụng ở mọi nơi. Đối với nhiệm vụ này, chúng tôi sử dụng dữ liệu từ lịch sử Git, vì cấu hình và ứng dụng cụm K8S của chúng tôi nằm trong cùng một kho lưu trữ Git.
Chúng ta lấy phiên bản ứng dụng từ kết quả thực hiện lệnh
git describe --tags --abbrev=7.
4. Tự động triển khai mọi thay đổi đối với môi trường thử nghiệm (UAT)
Bước tiếp theo trong tập lệnh xây dựng này là tự động cập nhật cụm K8S. Điều này xảy ra với điều kiện là toàn bộ ứng dụng đã được xây dựng và tất cả các tạo phẩm đã được xuất bản lên Docker Register. Sau đó, quá trình cập nhật môi trường thử nghiệm sẽ bắt đầu.
Cập nhật cụm được bắt đầu sử dụng . Do đó, nếu có điều gì đó không diễn ra theo kế hoạch, Helm sẽ tự động và độc lập khôi phục tất cả các thay đổi của nó. Công việc của anh ta không cần phải được kiểm soát.
Chúng tôi cung cấp cấu hình cụm K8S cùng với cụm lắp ráp. Do đó, bước tiếp theo là cập nhật nó: configMaps, triển khai, dịch vụ, bí mật và bất kỳ cấu hình K8S nào khác mà chúng tôi đã thay đổi.
Sau đó, Helm sẽ chạy bản cập nhật RollOut của chính ứng dụng đó trong môi trường thử nghiệm. Trước khi ứng dụng được triển khai vào sản xuất. Điều này được thực hiện để người dùng có thể kiểm tra thủ công các tính năng kinh doanh mà chúng tôi đưa vào môi trường thử nghiệm.
5. Tự động triển khai mọi thay đổi đối với Prod
Để triển khai bản cập nhật cho môi trường sản xuất, bạn chỉ cần nhấp vào một nút trong GitLab - và các vùng chứa ngay lập tức được chuyển đến môi trường sản xuất.
Cùng một ứng dụng có thể hoạt động trong các môi trường khác nhau—thử nghiệm và sản xuất—mà không cần xây dựng lại. Chúng tôi sử dụng các tạo phẩm giống nhau mà không thay đổi bất kỳ điều gì trong ứng dụng và chúng tôi đặt các tham số bên ngoài.
Tham số hóa linh hoạt của cài đặt ứng dụng tùy thuộc vào môi trường mà ứng dụng sẽ được thực thi. Chúng tôi đã chuyển tất cả cài đặt môi trường ra bên ngoài: mọi thứ đều được tham số hóa thông qua cấu hình K8S và thông số Helm. Khi Helm triển khai một bộ phận vào môi trường thử nghiệm, các cài đặt thử nghiệm sẽ được áp dụng cho nó và các cài đặt sản phẩm sẽ được áp dụng cho môi trường sản xuất.
Điều khó khăn nhất là tham số hóa tất cả các dịch vụ và biến được sử dụng phụ thuộc vào môi trường, đồng thời chuyển chúng thành các biến môi trường và cấu hình mô tả của các tham số môi trường cho Helm.
Cài đặt ứng dụng sử dụng các biến môi trường. Giá trị của chúng được đặt trong các vùng chứa bằng sơ đồ cấu hình K8S, được tạo khuôn mẫu bằng các mẫu Go. Ví dụ: việc đặt biến môi trường cho tên miền có thể được thực hiện như sau:
APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}
.Values.global.env – biến này lưu trữ tên của môi trường (prod, stage, UAT).
.Values.app.properties.app_external_domain – trong biến này, chúng tôi đặt tên miền mong muốn trong tệp .Values.yaml
Khi cập nhật một ứng dụng, Helm tạo tệp configmap.yaml từ các mẫu và điền giá trị APP_EXTERNAL_DOMAIN với giá trị mong muốn tùy thuộc vào môi trường bắt đầu cập nhật ứng dụng. Biến này đã được đặt trong vùng chứa. Nó có thể được truy cập từ ứng dụng, vì vậy mỗi môi trường ứng dụng sẽ có một giá trị khác nhau cho biến này.
Gần đây, hỗ trợ K8S đã xuất hiện trong Spring Cloud, bao gồm cả hoạt động với configMaps: . Trong khi dự án đang tích cực phát triển và thay đổi căn bản, chúng tôi không thể sử dụng nó trong sản xuất. Nhưng chúng tôi chủ động theo dõi tình trạng của nó và sử dụng nó trong cấu hình DEV. Ngay khi nó ổn định, chúng tôi sẽ chuyển từ sử dụng biến môi trường sang nó.
trong tổng số
Vì vậy, Triển khai liên tục đã được định cấu hình và hoạt động. Tất cả các cập nhật xảy ra với một lần nhấn phím. Việc thực hiện các thay đổi đối với môi trường sản phẩm là tự động. Và quan trọng là các bản cập nhật không dừng hệ thống.
Kế hoạch tương lai: di chuyển cơ sở dữ liệu tự động
Chúng tôi đã nghĩ đến việc nâng cấp cơ sở dữ liệu và khả năng khôi phục những thay đổi này. Rốt cuộc, hai phiên bản khác nhau của ứng dụng đang chạy cùng lúc: phiên bản cũ đang chạy và phiên bản mới đang hoạt động. Và chúng tôi sẽ chỉ tắt cái cũ khi chắc chắn rằng phiên bản mới hoạt động. Việc di chuyển cơ sở dữ liệu sẽ cho phép bạn làm việc với cả hai phiên bản của ứng dụng.
Vì vậy, chúng ta không thể đơn giản thay đổi tên cột hoặc dữ liệu khác. Nhưng chúng ta có thể tạo một cột mới, sao chép dữ liệu từ cột cũ vào cột đó và viết các trigger mà khi cập nhật dữ liệu sẽ đồng thời sao chép và cập nhật nó vào cột khác. Và sau khi triển khai thành công phiên bản mới của ứng dụng, sau thời gian hỗ trợ sau khi ra mắt, chúng tôi sẽ có thể xóa cột cũ và trình kích hoạt đã trở nên không cần thiết.
Nếu phiên bản mới của ứng dụng không hoạt động chính xác, chúng ta có thể quay lại phiên bản trước, bao gồm cả phiên bản trước của cơ sở dữ liệu. Tóm lại, những thay đổi của chúng tôi sẽ cho phép bạn làm việc đồng thời với nhiều phiên bản của ứng dụng.
Chúng tôi dự định tự động hóa việc di chuyển cơ sở dữ liệu thông qua công việc K8S, tích hợp nó vào quy trình CD. Và chúng tôi chắc chắn sẽ chia sẻ trải nghiệm này trên Habré.
Nguồn: www.habr.com