Sự hoài nghi về việc dùng template cho YAML
- Đặt ra câu hỏi từ khi nào việc dùng template cho YAML được chấp nhận như một điều bình thường, và làm thế nào điều đó lại có thể được chấp nhận.
- Đã trình bày tại cfgmgmtcamp 2019 về nhu cầu quản lý cấu hình Kubernetes và giải pháp kr8.
- Trong bài trình bày, tác giả nêu nghi vấn về template YAML, từ đó tạo ra các cuộc thảo luận sôi nổi trên mạng và tại hội nghị.
Vấn đề cấu hình
- Khi ứng dụng và hạ tầng phát triển vượt qua một quy mô nhất định, chúng sẽ đối mặt với vấn đề về độ phức tạp cấu hình.
- Cấu hình của ứng dụng được triển khai ở các môi trường khác nhau (development, staging, production) hoặc các khu vực khác nhau (châu Âu, Bắc Mỹ) có thể khác nhau.
- Quản trị viên hệ thống hoặc kỹ sư DevOps hiểu rất rõ độ phức tạp của quản lý cấu hình, và mỗi công cụ đều dùng YAML để giải quyết vấn đề này.
Chúng ta đã thụt lùi sao?
- Khi yêu cầu của ngành thay đổi cùng với điện toán đám mây, các công cụ mới đã xuất hiện.
- Các công cụ như CloudFormation và Helm là những công cụ cấu hình xuất sắc, nhưng tác giả tin rằng toàn ngành đã mắc sai lầm khi thiết kế template YAML.
- Bài viết giải thích bằng ví dụ về việc Helm chart nhận các tham số tùy biến.
Helm chart
- Helm chart nhận các tham số bên ngoài qua tệp
values.yaml để render chart.
- Bắt đầu từ các tham số chuỗi đơn giản, rồi giải thích độ phức tạp khi cấu hình các trường tùy chọn, mảng hoặc map.
- Chỉ ra yêu cầu nghiêm ngặt của YAML về khoảng trắng và những giới hạn của hệ thống template.
JSON, Jsonnet & YAML
- YAML là siêu tập của JSON, và việc chuyển đổi giữa hai định dạng này rất đơn giản.
- Jsonnet là một ngôn ngữ template dữ liệu với mục đích tạo ra cấu hình JSON.
Giáo phái Jsonnet
- Jsonnet là một ngôn ngữ mới chưa được biết đến nhiều bên ngoài cộng đồng Kubernetes.
- Với Jsonnet, có thể dễ dàng tạo cấu hình JSON sử dụng các biến bên ngoài.
- Bài viết giải thích cách xử lý các trường tùy chọn, map, tham số và các tính năng bổ sung của Jsonnet.
Kr8
- Kr8 sử dụng mọi phương pháp để giúp việc tạo và thao tác cấu hình của nhiều cụm Kubernetes trở nên dễ dàng và đơn giản.
- Nếu bạn đồng cảm với những khái niệm được trình bày ở đây, tác giả khuyên nên thử tìm hiểu Kr8.
Ý kiến của GN⁺
- Độ phức tạp của template YAML: Bài viết chỉ ra độ phức tạp và những giới hạn của template YAML, qua đó thể hiện rõ vấn đề mà ngành đang đối mặt trong quản lý cấu hình.
- Ưu điểm của Jsonnet: Jsonnet được đưa ra như một lựa chọn thay thế cho template YAML, nhấn mạnh tính dễ dùng và linh hoạt, từ đó khơi gợi sự quan tâm tới các công cụ mới.
- Tương lai của quản lý cấu hình: Bài viết mang lại góc nhìn về tương lai của quản lý cấu hình, đồng thời mở ra cơ hội cho các kỹ sư DevOps và quản trị viên hệ thống tìm kiếm cách tiếp cận mới.
1 bình luận
Ý kiến trên Hacker News
Có rất nhiều lời phàn nàn về các tệp cấu hình YAML. Đây cũng bị xem là phần tệ nhất trong GitHub Actions, và họ cũng có cảm giác tương tự với các ngôn ngữ cấu hình độc quyền khác như HCL, ASL, v.v. API khai báo thì tốt, nhưng vẫn có nhu cầu cho phép tạo phần khai báo đó bằng lập trình.
Khai báo và sinh cấu hình bằng code mang lại trải nghiệm tốt hơn. AWS CDK hiểu rất rõ điểm này, cho phép viết các định nghĩa khai báo cho cấu hình và hạ tầng đám mây bằng ngôn ngữ an toàn kiểu dữ liệu cùng với hỗ trợ từ IDE.
Có người đồng ý rằng việc template YAML là phi lý, và cho rằng khi cần logic phức tạp thì nên dùng một ngôn ngữ lập trình thực thụ để sinh ra YAML/JSON, v.v. Làm như vậy có thể giải quyết được nhiều vấn đề.
Đã có thảo luận về Kubernetes: dù API của Kubernetes có lược đồ JSON trực quan và được định nghĩa rõ ràng, mọi người vẫn tốn rất nhiều thời gian để học cách dùng Helm chart. Jsonnet, Ksonnet, Nu, CUE không giành được nhiều phổ biến, và có vẻ phần lớn mọi người dùng Kustomize được tích hợp sẵn trong kubectl.
Có ý kiến chỉ ra rằng các lập trình viên chưa suy nghĩ đủ nhiều về cách xử lý cấu hình cho đúng. Có thể nói mọi lập trình thực chất đều là vấn đề cấu hình, và mọi cấu hình cuối cùng đều được truyền vào như tham số của một hàm. Việc lưu cấu hình trong một cơ sở dữ liệu trung tâm có thể là lựa chọn tốt hơn.
Trong CI/CD, YAML đôi khi được dùng gần như một ngôn ngữ lập trình, nhưng điều này rất dài dòng, không trực quan, và bị xem là một ngôn ngữ đặc thù nhà cung cấp được định nghĩa không đầy đủ.
Có người bày tỏ sự tiếc nuối vì Helm đã chiến thắng. Làm việc với Helm chart rất bất tiện, editor không thể hỗ trợ nhiều, và mọi dữ liệu đều phải được canh đúng bằng
indent 4. Có dự đoán rằng Helm sẽ mang đến sự cáo chung của Kubernetes.Có người giữ quan điểm cá nhân rằng việc dùng nội suy chuỗi để tạo ra code mà máy đọc được là điều không mong muốn. Những vấn đề như SQL injection và cross-site scripting sẽ tiếp tục xảy ra. Họ cho rằng không nên dùng file template để sinh HTML.
Có ý kiến cho rằng những người chọn YAML dường như không nhận ra vấn đề. Có một xung đột trực tiếp giữa cách biểu diễn dữ liệu lấy con người làm trung tâm và cách biểu diễn dữ liệu lấy máy tính làm trung tâm. YAML và JSON trên thực tế là các định dạng dữ liệu khác nhau.
Có người thích YAML nhưng ngày nào cũng phải chửi thề khi làm việc với Helm chart. Dù ghét Helm, họ vẫn sẽ tiếp tục dùng vì ai cũng đang dùng nó.
Có người đang cân nhắc chuyển sang cuelang và cho rằng nó được thiết kế tốt hơn Jsonnet. Kubernetes vốn đã có chức năng reconciliation trạng thái, nên chỉ cần bổ sung thêm khả năng xóa là được.