Làm thế nào để bạn quản lý và triển khai các cổng của FreeBSD trong một môi trường rộng lớn?

19

Tôi tò mò về cách mọi người triển khai các cổng của FreeBSD trong môi trường của họ. Tôi giả định rằng hầu hết mọi người sử dụng FreeBSD thực sự đang sử dụng Cổng (và thường là nâng cấp để nâng cấp với nhị phân). Tuy nhiên tôi quan tâm đến cách bạn có thiết lập này, vì tôi không hài lòng với cách mọi thứ hoạt động trong các phiên bản gần đây. Tôi hiện đang chạy FreeBSD 9.0 và đang gặp sự cố.

Tôi đã thiết lập mọi thứ như sau:

/ usr / cổng được chia sẻ qua NFS từ một nút (với bản cập nhật 'portnap fetch update') hàng đêm.
Mỗi nút gắn kết / usr / cổng với đọc-ghi
Tôi đã đặt "WRKDIRPREFIX = / usr / tmp" trong /etc/make.conf trên tất cả các nút
Tôi đã định cấu hình Cổng để sử dụng chỉ mục cục bộ bằng cách thêm đoạn sau vào /usr/local/etc/pkgtools.conf:

ENV['LOCALINDICES'] ||= '/var/db'

ENV['PORTS_INDEX'] ||= ENV['LOCALINDICES'] + '/INDEX.local'

Tôi có thể chạy thành công portupgrade -p packageđể xây dựng một gói và sau đó portupgrade -P packagecài đặt nhị phân trên các nút khác.

Tuy nhiên, đôi khi tôi nhận được vấn đề sau: /var/db/INDEX.local:23265:dbm_store failed

Tôi không thể nghĩ ra bất kỳ tối ưu hóa nào khác mà tôi có thể làm với hệ thống, vì chỉ mục hiện nằm ở cục bộ và thứ duy nhất thực sự được xuất là cây cổng và không có gì được ghi vào đó từ các nút.

freebsd

— vpeterson
nguồn

Một tùy chọn sẽ là có một cây cổng cục bộ đầy đủ trên mỗi nút (và có lẽ chỉ cần gắn 'distfiles' và 'gói'), nhưng điều này cảm thấy như một sự lãng phí không gian lớn (và không đề cập đến nhiều cập nhật không cần thiết).

— vpeterson

vpeterson: Đây là một câu hỏi cần được hỏi (Tôi bị chặn ngay lúc này. Và 5 phiếu bầu và 3 sao cho thấy chúng tôi không đơn độc). Có lẽ làm sạch câu hỏi này và nêu một số vấn đề cụ thể mà bạn đang cố gắng giải quyết. (FWIW, ai đó đã bỏ phiếu để đóng câu hỏi của bạn. Cá nhân tôi rất muốn thấy điều này, hoặc một câu hỏi tương tự, được lưu).

— Stefan Lasiewski

Tôi không chắc làm thế nào để làm cho câu hỏi rõ ràng hơn. Tôi cũng không nghĩ rằng @ voretaq7 thực sự trả lời các câu hỏi, mà là gợi ý một phương pháp thay thế. Câu hỏi thực sự là về những gì chủ đề gợi ý - mọi người triển khai các cổng của FreeBSD như thế nào trong môi trường nhiều nút.

— vpeterson

13

Tôi chưa bao giờ hoàn toàn hài lòng với hệ thống cổng trong một môi trường rộng lớn - Có vẻ như bạn luôn cần áp dụng một số quản lý bên ngoài để làm cho nó hoạt động tốt.

Lời khuyên tốt nhất của tôi (theo thứ tự ưu tiên tăng dần, giải pháp "tệ nhất" cho giải pháp "tốt nhất"):

Nếu bạn đang xây dựng trên mỗi máy chủ, đừng .
Nếu bạn phải, đừng làm điều đó qua NFS với các giá trị đọc ghi như bạn mô tả: Bạn thường có thể tin tưởng các cổng để thực hiện đúng và không dậm chân trên cây cổng nếu bạn cung cấp các thư mục công việc thay thế, nhưng luôn tốt hơn an toàn hơn xin lỗi: Chạy một gương CVS / csup cục bộ và csup tất cả các máy chủ của bạn từ hộp đó, sau đó xây dựng cục bộ như bạn muốn nếu chúng là các máy riêng lẻ.
Vâng, tôi biết điều này có nghĩa là có nhiều không gian đĩa trên máy chủ và thêm một bước. Nó cũng gần như được đảm bảo là không có vấn đề.
Hãy cẩn thận: Bạn có thể muốn đồng bộ hóa các tệp cấu hình gói (rsync hoặc tương tự) từ một "máy chủ cấu hình" được chỉ định để đảm bảo tính nhất quán trên mỗi máy (thậm chí bạn có thể rsync toàn bộ cây cổng nếu muốn, thay vì sử dụng csup trên mỗi nút).

Sử dụng Build Host, tạo các gói và cài đặt chúng.
Một giải pháp tốt hơn nhiều so với xây dựng trên từng máy riêng lẻ: Sử dụng máy chủ lưu trữ để tạo các gói và trỏ các công cụ của bạn vào các gói đó.
Điều này có nghĩa là giữ một máy chủ xây dựng xung quanh cho mọi kiến trúc bạn chạy (hoặc biên dịch chéo), nhưng cuối cùng nó sẽ đẹp hơn cho các máy mục tiêu của bạn (không có công việc biên dịch lớn, đảm bảo tính nhất quán)

Sử dụng một công cụ quản lý cấu hình / hệ thống.
Đây là giải pháp tôi sử dụng - Tôi xây dựng hình ảnh máy chủ tiêu chuẩn và triển khai nó xung quanh môi trường của mình bằng cách sử dụng radmind. Bạn có thể làm những điều tương tự với Puppet hoặc Chef . Điều này có tất cả các lợi thế của việc sử dụng máy chủ xây dựng (tính nhất quán, tải ít hơn trên các máy chủ riêng lẻ) và thêm lợi ích của việc quản lý cấu hình.

Hãy cẩn thận: Điều này chỉ hoạt động thực sự tốt nếu máy của bạn "giống hệt nhau" - Đó là bạn có thể cài đặt cùng một bộ cổng trên tất cả chúng. Nó có thể hoạt động nếu bạn có các bộ cổng khác nhau, nhưng điều đó làm tăng đáng kể chi phí quản trị.

Tuyên bố miễn trừ trách nhiệm: Tôi là người duy trì cổng sysutils/radmind. Vâng, tôi thích nó rất nhiều mà tôi đã chấp nhận nó.

Tất cả điều này dựa trên kinh nghiệm của tôi khi quản lý các môi trường FreeBSD có kích thước khác nhau (từ 1-2 máy đến hơn 100). Các công cụ quản lý cấu hình / hệ thống đẩy và duy trì hình ảnh chuẩn hóa thực sự là cách tốt nhất để xử lý vấn đề này theo kinh nghiệm của tôi.

— voretaq7
nguồn

Con trỏ tốt. Tôi đã chơi với Puppet một chút trong quá khứ và yêu thích nó trên Ubuntu. Tuy nhiên, tôi không chắc nó chơi tốt như thế nào với FreeBSD. Tôi vẫn chưa thử. Bất kể, ngay cả với Puppet, tôi nghĩ rằng nó kêu gọi PortupTHER, đưa chúng ta trở lại hình vuông. Tôi không thấy bất kỳ cách nào khác nó có thể hoạt động, vì sau đó nó sẽ cần phải thực hiện pkg_delete / pkg_add hoặc 'pkg_add -f' sẽ không phải là một ý tưởng tốt. Về phần cứng, tất cả đều giống hệt nhau vì chúng chạy trong đám mây công cộng (KVM / Qemu).

— vpeterson

Nếu cấu hình phần cứng và phần mềm cơ bản của bạn giống hệt nhau, tôi sẽ đề xuất một cái gì đó như radmind, quản lý toàn bộ hình ảnh hệ thống. Puppet và Chef là những công cụ tuyệt vời, tuy nhiên như bạn đã chỉ ra, chúng gọi các nhị phân hệ điều hành cơ bản, khiến bạn không sử dụng máy chủ xây dựng và phân phối các gói. radmind tránh điều này bằng cách tiếp quản quản lý ở cấp hệ thống tệp ("Nếu không phải là thứ cần có ở đây, hãy thay thế hoặc xóa nó") thay vì cố gắng trở thành một sysadmin thay thế ("Chạy các lệnh này / thay đổi các tệp này để tôi định cấu hình cái hộp").

— voretaq7

Vâng, các hệ thống có phần cứng giống hệt nhau, nhưng cấu hình không giống nhau. Tôi sẽ phải xem xét Radmind nhưng tôi không chắc đó có phải là cách tiếp cận tốt nhất không. Sử dụng các công cụ tích hợp sẽ hoạt động IMHO, đó là lý do tại sao tôi tiếp cận cộng đồng để xem liệu tôi có bỏ sót điều gì rõ ràng không. Tôi khó có thể là người duy nhất cố gắng làm điều này.

— vpeterson

Việc xây dựng trong các công cụ chắc chắn DO làm việc, họ chỉ đòi hỏi rất nhiều sự giúp đỡ (xây dựng các máy chủ, phân phối địa phương của bao bì, vv) - Họ đang thực sự hướng tới quản lý một máy, và không mở rộng quy mô cũng như họ có thể. Lưu ý rằng tôi đã bỏ qua tùy chọn cuộn máy chủ cập nhật freebsd của riêng bạn - Tôi chưa bao giờ thử điều này không chỉ cho hệ thống cơ bản, nhưng về mặt lý thuyết là có thể. Tôi chỉ bị mắc kẹt với những thứ tôi biết hoạt động :)

— voretaq7

Vâng, đó thực sự là một ý tưởng thú vị. Tôi chỉ không chắc liệu nó có hoạt động với việc phân phối các gói cổng mà không cần sửa đổi nhiều không. Tôi thực sự tò mò về cách các hệ thống của các hệ thống lớn quản lý việc này, vì có rất nhiều triển khai FreeBSD. Có phải tất cả trong số họ cuộn giải pháp riêng của họ? Nếu vậy, điều đó cảm thấy khá kỳ lạ và không phải là Nguồn mở-ish.

— vpeterson

6

Kỳ lạ là không ai đề cập đến cổng-mgmt / tinderbox :

Tinderbox là một hệ thống xây dựng gói cho các cổng FreeBSD, dựa trên các tập lệnh Portbuild chính thức được sử dụng trên cụm tòa nhà nhọn. Tinderbox được viết bởi Joe Marcus Clarke.

Bạn có thể xác định nhiều tù (phiên bản hệ thống cơ sở) và nhiều cổng. Sự kết hợp giữa nhà tù và portstree được gọi là bản dựng. Một nhà tù Tinderbox không phải là một nhà tù trong FreeBSD, thực tế nó là một thế giới nhất định trong một chroot. Tinderbox hỗ trợ tự động theo dõi các phụ thuộc và chỉ xây dựng lại các gói đã thay đổi kể từ lần chạy trước. Tinderbox có hỗ trợ thông báo qua email về các bản dựng không thành công. Tinderbox cũng tích hợp tốt với ccache.

Tinderbox được thiết kế để dễ dàng cung cấp các gói cổng bạn cần, cho các nền tảng và kiến trúc bạn cần. Tinderbox cũng là công cụ tuyệt vời để thử nghiệm các cổng mới và nâng cấp cổng, đặc biệt là để kiểm tra các phụ thuộc và danh sách đóng gói. Nó cũng hữu ích để kiểm tra các cổng trên các bản phát hành FreeBSD khác nhau, vì bạn có thể chạy thế giới FreeBSD 6.X như một nhà tù trên máy chủ FreeBSD 7.X / 8.X.

Ngoài ra, chuyển sang pkgng đơn giản hóa rất nhiều việc triển khai gói.
Hãy xem thử trên github: https://github.com/pkgng/pkgng

— LưuTheRbtz
nguồn

1

Mặc dù điều đó chắc chắn có thể thuận tiện cho việc xây dựng các gói thực tế trong một môi trường đa dạng (nhiều phiên bản, kiến trúc, v.v.), nhưng nó không thực sự giải quyết được vấn đề triển khai các gói.

— vpeterson

Tinderbox cung cấp các gói có sẵn qua HTTP, vì vậy bạn có thể kết hợp điều này với các nhận xét về câu trả lời của voretaq7 để có giải pháp triển khai của bạn (ví dụ: đặt PACKAGEROOT/ PACKAGESITEvà sử dụng radmind hoặc Puppet / Chef).

— James O'Gorman

Có, nhưng việc xây dựng và phân phối các gói không phải là vấn đề. Tôi có thể sử dụng portupTHER (-p) để xây dựng gói và phân phối chúng thông qua NFS (có hoặc không có cây cổng). Vấn đề là mô hình này vẫn yêu cầu a) một cây cổng hoàn chỉnh cục bộ hoặc b) cây cổng được xuất qua NFS, điều này đưa chúng ta trở lại vấn đề.

— vpeterson

2

PortupTHER sẽ thực hiện chính xác những gì bạn phải làm nếu bạn đang xây dựng từ nguồn hoặc sử dụng các gói nhị phân - pkg_deletephải được chạy trước và sau đó cài đặt phiên bản mới. OpenBSD đã xử lý việc này tốt hơn bằng cách đưa vào tùy chọn nâng cấp pkg_add. Không chắc chắn về PortupTHER nhưng portmaster có thể hoạt động chỉ bằng cách sử dụng INDEX và không phải là cây cổng đầy đủ.

— James O'Gorman

1

Đúng, nhưng pkg_delete hầu như không phải là một cách tiếp cận hợp lý. Giả sử bạn muốn nâng cấp Ruby, Python hoặc bất kỳ gói nào khác là điều kiện tiên quyết cho một số lượng lớn các gói khác. pkg_delete sau đó sẽ yêu cầu bạn xóa tất cả các phụ thuộc, hầu như không phải là một tùy chọn cho một hệ thống sản xuất. Portupgrade hiện một xa công việc tốt hơn với điều này, nhưng một lần nữa, nó dường như không quy mô.

— vpeterson 17/03 '

3

Tôi đã quản lý hơn 100 máy chủ FreeBSD bằng cách chia sẻ / usr chỉ đọc qua NFS được điều chỉnh tốt, chuyển cơ sở dữ liệu gói từ / var sang / usr và liên kết với chúng (không thực sự cần thiết nhưng cho phép pkg_info và như vậy). Có thể có một hoặc hai tệp khác cần được di chuyển theo hướng này hay hướng khác và được liên kết với nhau nhưng toàn bộ thiết lập đã khiến tôi mất khoảng một giờ để tìm ra. Nó làm việc rất, rất tốt. Nếu tôi gặp vấn đề mở rộng, tôi sẽ thêm các máy chủ NFS bổ sung và phân chia khối lượng công việc nhưng nó không bao giờ xuất hiện. Hiệu suất chưa bao giờ là vấn đề đối với tôi (thực tế nó rất tuyệt) nhưng tôi cho rằng bạn có thể đặt / usr của máy chủ NFS (hoặc bản sao của nó) trên md.

— lông tơ
nguồn

Chia sẻ các tệp gói được xây dựng qua NFS (có vẻ như bạn đang nói về vấn đề gì?) Chắc chắn là một cách tiếp cận hợp lý khác - sau đó bạn có thể sử dụng một cái gì đó như con rối (hoặc thậm chí các tập lệnh SSH-and-shell trong nhà) để cài đặt / nâng cấp các gói từ chia sẻ NFS.

— voretaq7

1

Có vẻ như không ai có một giải pháp tốt cho điều này không may. Nhiều khả năng điều này là do những hạn chế trong các công cụ lót.

Đây là những gì tôi nghĩ ra: Tôi đã loại bỏ ý tưởng về việc xuất toàn bộ cây cổng. Thay vào đó, tôi đã đưa vào và đặt một cây cổng đầy đủ trên mỗi nút. Sau đó tôi đã gắn 'gói' qua NFS (để cho phép phân phối gói).

Tôi cũng có ý định sử dụng proxy lưu trữ (có thể là Squid) để tăng tốc quá trình portnap. Tôi đã viết một bài viết ngắn về cách thiết lập điều này trên blog của tôi.

Tài liệu tham khảo:

— vpeterson
nguồn