GoCD on Kubernetes

Bài tóm tắt Disney Hotstar 2020 3. Quy mô lớn Độ khó: Trung bình

Disney Hotstar · 2020 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Toàn văn lấy từ bản Wayback (2021-07-15). Cùng năm với Disney Hotstar 2020 (chuyển workload lên container).

Bối cảnh

  • Mục tiêu của Platform Team ở Hotstar: tự động hoá mọi bước can thiệp tay trong deploy, từ lúc merge vào trunk tới production. Muốn vậy, không chỉ code mà cả script deploy, hạ tầng, cấu hình ứng dụng đều phải được version.
  • Jenkins làm CI tốt nhưng khó theo dõi một thay đổi đi qua các stage/môi trường. Rollback phải làm bằng tham số version trong pipeline, nên không rõ cái gì đang thật sự được deploy.

Thay đổi chính

  • Chọn GoCD (công cụ continuous delivery): pipeline là thực thể hạng nhất, mỗi lần chạy có số đếm, nên artifact và pipeline ánh xạ một-một; hết cảnh ghi version production vào wiki hay ticket. Value stream map cho thấy thay đổi phía upstream nào ảnh hưởng pipeline đang lỗi.
  • Elastic agents trên Kubernetes: agent là pod, bật khi có job và tắt khi xong (agent CI cũ phần lớn thời gian ngồi không). Phức tạp mới: agent cần credential trước khi chạy, nên dùng init-container xác thực với Vault rồi cấu hình agent (AWS role, kubeconfig, maven settings…) theo profile. Vault dùng Kubernetes auth: service account của pod chỉ đọc được secret của mình (agent dev đọc /secrets/dev, agent prod đọc /secrets/prod). Cluster profile khác nhau để chạy agent ở cụm khác, phục vụ test giả lập từ nhiều vùng địa lý.
  • Mọi thứ là code: pipeline định nghĩa bằng YAML trong git (developer tự sửa pipeline của mình), kiểm tra bằng API preflight-check vì một cấu hình sai sẽ chặn mọi thay đổi sau đó. Chính GoCD và plugin cũng cấu hình bằng code qua API, secret của plugin mã hoá bằng sops để check-in được. Deploy GoCD bằng Helm chart rồi chạy script cấu hình: dựng một GoCD server mới trong vài phút.
  • Vận hành chính công cụ deploy: backup sẵn có của GoCD không gồm artifact và dữ liệu plugin, nên viết cron job Kubernetes snapshot volume và một wrapper khôi phục từ snapshot mới nhất. Viết Prometheus exporter riêng (thời gian chờ cấp agent, thông tin lập lịch pipeline) để đưa vào hệ monitoring và alert sẵn có.

Vì sao

  • Theo Hotstar: luồng công việc từ dev tới deploy được nhìn thấy; tài nguyên agent dùng hiệu quả; agent profile tách công cụ và quyền theo trách nhiệm; dựng lại cả hệ CI/CD trong vài phút.

Bài học cho SWE

  • Công cụ deploy nên trả lời được câu "cái gì đang chạy ở production, đến từ commit nào" mà không cần ghi chép ngoài; ánh xạ một-một giữa artifact và lần chạy pipeline là cách đơn giản (Deploy và release an toàn).
  • Agent CI tạm thời (pod) tiết kiệm tài nguyên, đổi lại phải giải bài toán cấp secret lúc khởi động; gắn quyền theo service account để mỗi môi trường chỉ thấy secret của mình (Nền tảng nội bộ cho service (đường ray chung)).
  • Hệ CI/CD là hạ tầng production: cần backup, khôi phục, monitoring như mọi hệ khác, và cấu hình của nó cũng phải là code để dựng lại được.
  • Kiểm tra cấu hình pipeline trước khi merge: một file sai có thể chặn cả hàng đợi thay đổi.

Liên quan