Chủ đề về kho lưu trữ đơn lẻ đã được thảo luận nhiều lần và theo quy luật, gây ra tranh cãi rất tích cực. Bằng cách tạo ra là một công cụ nguồn mở được thiết kế để cải thiện quy trình xây dựng mã ứng dụng từ hình ảnh Git sang Docker (và sau đó phân phối chúng đến Kubernetes), chúng tôi không nghĩ nhiều về lựa chọn nào là tốt nhất. Đối với chúng tôi, điều quan trọng nhất là cung cấp mọi thứ cần thiết cho những người ủng hộ các quan điểm khác nhau (tất nhiên nếu điều này không mâu thuẫn với lẽ thường).
hỗ trợ mono-repo gần đây của werf là một ví dụ điển hình về điều này. Nhưng trước tiên, hãy tìm hiểu xem sự hỗ trợ này thường liên quan như thế nào đến việc sử dụng werf và Docker Registry phải làm gì với nó ...
Vấn đề
Hãy tưởng tượng một tình huống như vậy. Công ty có nhiều nhóm phát triển làm việc trên các dự án độc lập. Hầu hết các ứng dụng chạy trên Kubernetes và do đó được chứa trong vùng chứa. Để lưu trữ các thùng chứa, hình ảnh, bạn cần có một sổ đăng ký (registry). Công ty sử dụng Docker Hub làm sổ đăng ký như vậy với một tài khoản COMPANY. Tương tự như hầu hết các hệ thống lưu trữ mã nguồn, Docker Hub không cho phép phân cấp kho lưu trữ lồng nhau, chẳng hạn như COMPANY/PROJECT/IMAGE. Trong trường hợp đó... làm cách nào bạn có thể lưu trữ các ứng dụng không nguyên khối trong sổ đăng ký với giới hạn này mà không tạo tài khoản riêng cho từng dự án?
Có lẽ, tình huống được mô tả đã quen thuộc với ai đó trực tiếp, nhưng chúng ta hãy xem xét vấn đề tổ chức lưu trữ ứng dụng nói chung, tức là. mà không cần tham khảo ví dụ trên và Docker Hub.
Các giải pháp
Nếu ứng dụng nguyên khối, xuất hiện trong một hình ảnh, thì không có câu hỏi nào và chúng tôi chỉ cần lưu hình ảnh vào sổ đăng ký bộ chứa của dự án.
Khi một ứng dụng được trình bày dưới dạng nhiều thành phần, vi dịch vụ, thì cần phải có một cách tiếp cận nhất định. Trên ví dụ về một ứng dụng web điển hình bao gồm hai hình ảnh: frontend и backend - các tùy chọn có thể là:
- Lưu trữ hình ảnh trong các kho lưu trữ lồng nhau riêng biệt:
- Lưu trữ mọi thứ trong một kho lưu trữ và xem xét tên hình ảnh trong thẻ, chẳng hạn như sau:
NB: Trên thực tế, có một tùy chọn khác với việc lưu vào các kho lưu trữ khác nhau, PROJECT-frontend и PROJECT-backend, nhưng chúng tôi sẽ không xem xét nó vì sự phức tạp của việc hỗ trợ, tổ chức và phân phối quyền giữa những người dùng.
hỗ trợ người sói
Ban đầu, werf tự giới hạn trong các kho lưu trữ lồng nhau - may mắn thay, hầu hết các cơ quan đăng ký đều hỗ trợ tính năng này. Bắt đầu từ phiên bản , đã thêm công việc với các cơ quan đăng ký trong đó làm tổ không được hỗ trợ, và Docker Hub là một trong số đó. Từ thời điểm này, người dùng có thể lựa chọn cách lưu trữ hình ảnh ứng dụng.
Thực hiện có sẵn theo tùy chọn --images-repo-mode=multirepo|monorepo (mặc định multirepo, I E. lưu trữ trong các kho lưu trữ lồng nhau). Nó xác định các mẫu mà hình ảnh được lưu trữ trong sổ đăng ký. Chỉ cần chọn chế độ mong muốn khi sử dụng các lệnh cơ bản là đủ và mọi thứ khác sẽ không thay đổi.
Bởi vì hầu hết các tùy chọn werf đều có thể được đặt biến môi trường, trong các hệ thống CI/CD, chế độ lưu trữ thường dễ cài đặt trên toàn cầu cho toàn bộ dự án. Ví dụ, trong trường hợp của GitLab chỉ cần thêm một biến môi trường trong cài đặt dự án: Cài đặt -> CI/CD -> Biến: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
Nếu chúng ta nói về việc xuất bản hình ảnh và triển khai ứng dụng (bạn có thể đọc chi tiết về các quy trình này trong các bài viết tài liệu liên quan: и ), thì chế độ này chỉ xác định mẫu mà bạn có thể làm việc với hình ảnh.
Ma quỷ là trong các chi tiết
Điểm khác biệt và khó khăn chính khi thêm phương thức lưu trữ mới là ở quá trình dọn dẹp registry (đối với các tính năng thanh lọc được hỗ trợ bởi werf, hãy xem ).
Khi dọn dẹp, werf sẽ tính đến các hình ảnh được sử dụng trong các cụm Kubernetes, cũng như các chính sách do người dùng định cấu hình. Các chính sách dựa trên việc phân chia các thẻ thành các chiến lược. Các chiến lược hiện được hỗ trợ:
- 3 chiến lược được liên kết bởi các nguyên hàm Git như thẻ, nhánh và cam kết;
- 1 chiến lược cho các thẻ tùy chỉnh tùy ý.
Chúng tôi lưu thông tin về chiến lược thẻ khi xuất bản hình ảnh trong nhãn của hình ảnh cuối cùng. Ý nghĩa của chính nó là cái gọi là thẻ meta - Yêu cầu áp dụng một số chính sách. Ví dụ: khi xóa một nhánh hoặc thẻ khỏi kho lưu trữ Git, việc xóa liên quan là hợp lý. không sử dụng hình ảnh từ sổ đăng ký, thuộc phạm vi điều chỉnh của một phần chính sách của chúng tôi.
Khi được lưu trong một kho lưu trữ (monorepo), trong thẻ hình ảnh, ngoài thẻ meta, tên của hình ảnh cũng có thể được lưu trữ: PROJECT:frontend-META-TAG. Để tách chúng ra, chúng tôi không giới thiệu bất kỳ dấu tách cụ thể nào mà chỉ cần thêm giá trị cần thiết vào nhãn của hình ảnh cuối cùng khi xuất bản.
NB: Nếu bạn muốn xem mọi thứ được mô tả trong mã nguồn werf, thì điểm bắt đầu có thể là .
Trong bài viết này, chúng tôi sẽ không chú ý nhiều hơn đến các vấn đề và sự biện minh cho cách tiếp cận của chúng tôi: về chiến lược gắn thẻ, lưu trữ dữ liệu trong nhãn và toàn bộ quy trình xuất bản - tất cả điều này được mô tả chi tiết trong một báo cáo gần đây của Dmitry Stolyarov: “'.
Tóm tắt
Việc thiếu hỗ trợ cho các cơ quan đăng ký không được lồng ghép không phải là yếu tố cản trở đối với chúng tôi hoặc những người dùng werf mà chúng tôi biết - xét cho cùng, bạn luôn có thể tạo một cơ quan đăng ký hình ảnh riêng (hoặc chuyển sang Cơ quan đăng ký vùng chứa có điều kiện trong Google Cloud) ... Tuy nhiên, việc loại bỏ hạn chế như vậy có vẻ hợp lý để công cụ trở nên thuận tiện hơn trong cộng đồng DevOps rộng lớn hơn. Khi triển khai nó, chúng tôi gặp khó khăn chính trong việc làm lại cơ chế dọn dẹp sổ đăng ký vùng chứa. Bây giờ mọi thứ đã sẵn sàng, thật tuyệt khi nhận ra rằng nó đã trở nên dễ dàng hơn đối với ai đó và chúng tôi (với tư cách là nhà phát triển chính của dự án) sẽ không gặp bất kỳ khó khăn đáng chú ý nào trong việc hỗ trợ thêm tính năng này.
Ở lại với chúng tôi và rất sớm chúng tôi sẽ cho bạn biết về những đổi mới khác trong !
PS
Đọc thêm trên blog của chúng tôi:
- «»;
- «'.
Nguồn: www.habr.com