2012-02-11 37 views
14

Các phương pháp hay nhất để triển khai ứng dụng Perl là gì? Giả sử rằng bạn đang triển khai vào một hộp vanilla với cài đặt module CPAN nhỏ. Phương pháp xây dựng, triển khai lý tưởng là gì? Module :: Xây dựng, ExtUtils :: MakeMaker, khác? Tôi đang tìm kiếm một số ý tưởng thực hành tốt nhất từ ​​những người đã làm điều này nhiều lần cho các ứng dụng quy mô lớn.Triển khai ứng dụng Perl

Ứng dụng đang triển khai trên máy chủ. Nó không phải là CPAN hay một kịch bản. Nó thực sự là một ứng dụng web PSGI. Đó là, một tấn các gói Perl.

Tôi hiện đang có tập lệnh triển khai sử dụng Net :: SSH :: Mong đợi SSH vào máy chủ mới, cài đặt một số công cụ và định cấu hình máy chủ, sau đó kéo nhánh ứng dụng mong muốn từ kiểm soát nguồn. Điều này cảm thấy đúng, nhưng là thực hành tốt nhất này?

Bước tiếp theo là tạo ứng dụng. Các phương pháp hay nhất để theo dõi và quản lý các phụ thuộc, cài đặt các phụ thuộc đó từ CPAN là gì và đảm bảo ứng dụng đã sẵn sàng để chạy?

Cảm ơn

Trả lời

3

Nếu nó có một số phụ thuộc CPAN đáng kể, sau đó bạn có thể muốn hoặc viết một kịch bản nhỏ mà sử dụng CPAN::Shell để cài đặt các module cần thiết hoặc chỉnh sửa Makefile.PL của ứng dụng của bạn để nó phản ánh sự phụ thuộc cần thiết trong phần BUILD_REQUIRES của tệp.

11

Công ty tôi đang làm việc hiện đang xây dựng RPM cho mỗi CPAN & Phụ thuộc nội bộ của một ứng dụng (khá nhiều gói!) Cài đặt vào thư mục system_perl hệ thống. Điều này có một số vấn đề:

  • Mất nhiều thời gian để tạo RPM khi các phiên bản gặp phải trong CPAN.
  • Gắn kết với hệ thống perl có nghĩa là bạn đang ở lòng thương xót của phân phối của bạn để thực hiện hoặc phá vỡ perl của bạn (trong Centos 5 chúng tôi có một phiên bản perl tối đa 5.8.8!).
  • Nếu bạn có nhiều ứng dụng được triển khai cho cùng một máy chủ, có một thư viện perl duy nhất cho tất cả các ứng dụng có nghĩa là việc nâng cấp các phụ thuộc có thể nguy hiểm mà không kiểm tra lại mọi ứng dụng của máy chủ. Chúng tôi triển khai khá nhiều bản phân phối riêng biệt với tất cả các mức độ chú ý bảo trì khác nhau, vì vậy đây là một vấn đề lớn đối với chúng tôi.

Chúng tôi đang di chuyển khỏi việc xây dựng RPM cho mọi phụ thuộc và thay vào đó lập kế hoạch sử dụng thùng carton [1] để xây dựng một thư viện perl hoàn toàn khép kín cho mọi ứng dụng chúng tôi triển khai. Chúng tôi đang xây dựng các thư viện này thành các gói hệ thống, nhưng bạn có thể dễ dàng tarball chúng và sao chép chúng theo cách thủ công nếu bạn không muốn đối phó với trình quản lý gói.

Vấn đề với thùng carton là bạn sẽ cần phải thiết lập một gương CPAN bên trong mà bạn có thể cài đặt các phụ thuộc nội bộ của bạn nếu ứng dụng của bạn phụ thuộc vào các mô-đun không có trong CPAN. Nếu bạn không muốn đối phó với điều đó, bạn luôn có thể tự cài đặt libs bạn cần vào local :: lib [2] hoặc perlbrew [3] và đóng gói các thư viện kết quả để triển khai vào các hộp sản xuất của bạn.

Với tất cả các giải pháp được quy định, hãy cẩn thận với XS perl libs. Bạn sẽ cần phải xây dựng thùng carton/cục bộ của bạn: libs/perlbrew trên cùng một kiến ​​trúc với máy chủ mà bạn đang triển khai và đảm bảo các hộp sản xuất của bạn có cùng phụ thuộc nhị phân như những gì bạn đã sử dụng để tạo.

Để trả lời cập nhật cho câu hỏi của bạn về việc thực hành tốt nhất để kiểm tra nguồn và cài đặt vào máy chủ sản xuất; Cá nhân tôi không nghĩ rằng đó là một ý tưởng hay. Lý do tại sao tôi tin rằng đó là rủi ro trong thực tế là rất khó để hoàn toàn chắc chắn rằng tập hợp các thư viện mà bạn cài đặt chính xác dòng lên đến các thư viện mà bạn đã thử nghiệm chống lại, do đó triển khai có khả năng không thể đoán trước. Vấn đề này có thể bị bực tức bởi các ứng dụng web vì bạn rất có khả năng có cùng một mã được triển khai cho nhiều hộp sản xuất có thể thoát ra khỏi đồng bộ. Trong khi cộng đồng perl làm một công việc tuyệt vời của cố gắng để phát hành mã chất lượng tốt đó là tương thích ngược, khi mọi thứ đi sai nó thường là một nỗ lực để tìm ra những thứ. Đây là lý do tại sao thùng carton đang được phát triển, vì điều này tạo ra một bộ nhớ cache của tất cả các tarballs phân phối mà bạn cần phải cài đặt đông lạnh ở các phiên bản cụ thể để bạn có thể dự đoán triển khai mã của bạn. Tất cả điều đó nói mặc dù; nếu bạn vui lòng chấp nhận rủi ro đó và sửa chữa mọi thứ khi họ phá vỡ thì cài đặt cục bộ sẽ tốt cho bạn. Tuy nhiên, ở mức tối thiểu, tôi sẽ yêu cầu đề xuất cài đặt vào một địa phương :: lib để bạn có thể sao lưu lib cục bộ cũ trước khi cài đặt bản cập nhật để có điểm khôi phục nếu mọi thứ trở nên rối loạn.

+1

+1 trên "phải rất cẩn thận về XS perl libs" – tangent

+0

Tôi nghĩ có lẽ chúng tôi đang đề cập đến hai điều khác nhau. Tôi đang nói về việc kéo một nhánh cụ thể hoặc 'phiên bản' của mã ứng dụng từ một hệ thống điều khiển nguồn trung tâm, ví dụ như GitHub. Dường như bạn đang đề cập đến chính các gói phụ thuộc, ví dụ như gói CPAN. Tôi đồng ý rằng cần phải cẩn thận để đảm bảo rằng các phiên bản mô-đun CPAN của bạn nhất quán trên các nút, bao gồm cả môi trường phát triển/dàn dựng, tuy nhiên, kéo nhánh cụ thể của nguồn đến từng nút trong quá trình triển khai có vẻ như cách đảm bảo tính nhất quán của phần mềm ứng dụng. – MadHacker

+0

Một câu hỏi khác. Theo kinh nghiệm của bạn với việc sử dụng Carton, làm thế nào tốt nó đã được xử lý các phụ thuộc của phụ thuộc? Có nghĩa là, nếu Makefile.PL của tôi chỉ chứa các gói ứng dụng của tôi một cách rõ ràng 'yêu cầu' hoặc 'sử dụng' làm thế nào tốt là Carton phân loại ra sự phụ thuộc của các mô-đun? – MadHacker

0

Bạn có thể có một cái nhìn tại sparrowdo một Perl6 công cụ quản lý cấu hình, nó đi kèm với một số plugin tiện dụng liên quan đến triển khai perl5, như cài đặt các gói cpan hoặc triển khai ứng dụng psgi.

Cập nhật: liên kết này https://dev.to/melezhik/deploying-perl5-application-by-sparrowdo-9mb có thể hữu ích.

Tiết lộ - Tôi là tác giả công cụ.

Các vấn đề liên quan