2012-02-11 172 views
14

部署Perl應用程序的最佳實踐是什麼?假設您將部署到安裝有少量CPAN模塊的香草盒中。什麼是理想的構建,部署方法? Module :: Build,ExtUtils :: MakeMaker,other?我正在尋找那些反覆爲大規模應用做過這些工作的人的一些最佳實踐想法。部署Perl應用程序

該應用程序正在部署到服務器上。這不是CPAN或腳本。它實際上是一個PSGI網絡應用程序。那就是,大量的Perl軟件包。

我目前有一個部署腳本,它使用Net :: SSH :: Expect將SSH連接到新的服務器,安裝一些工具並配置服務器,然後從源代碼管理下拉所需的應用程序分支。這感覺不錯,但這是最佳做法嗎?

下一步是構建應用程序。跟蹤和管理依賴關係,從CPAN安裝這些依賴關係並確保應用程序已準備好運行的最佳實踐是什麼?

感謝

回答

3

如果它有一些顯著CPAN的依賴,那麼你可能想要麼編寫使用CPAN::Shell安裝必要的模塊或編輯應用程序的Makefile.PL,以便它反映了必要的依賴一個小腳本文件的BUILD_REQUIRES部分。

11

我工作的公司目前爲每個CPAN構建RPMs安裝到系統site_perl目錄中的應用程序的內部依賴關係(相當多的包!)。這有許多問題:

  • 當版本在CPAN上碰撞時,保持構建RPM非常耗時。
  • 將你自己綁定到系統perl意味着你受到你的發行版的制約或者破壞你的perl(在Centos 5中我們有一個最大的perl版本5.8.8!)。
  • 如果您將多個應用程序部署到同一個主機,那麼對於所有應用程序擁有一個perl庫意味着如果不重新測試主機的每個應用程序,那麼升級依賴關係可能很危險。我們部署了很多單獨的發行版,並且都有不同程度的維護注意力,所以這對我們來說是很重要的。

我們正在逐步建立每個依賴項的RPM,而是打算使用carton [1]爲我們部署的每個應用程序構建一個完全自包含的perl庫。我們正在將這些庫構建到系統包中,但如果您不想處理包管理器,則可以輕鬆地將它們壓縮起來並手動複製它們。

紙箱問題在於如果您的應用程序依賴於不在CPAN上的模塊,您需要設置一個內部CPAN鏡像,您可以安裝內部依賴項。如果你不想處理這個問題,你總是可以手動安裝你需要的庫到local :: lib或perlbrew [3]中,並將生成的庫打包以便部署到生產環境中。

對於所有規定的解決方案,要非常小心XS perl庫。您需要在與要部署的主機相同的架構上構建您的紙箱/本地:libs/perlbrews,並確保您的產品盒具有與您以前構建的相同的二進制相關性。

要回答有關是否最佳實踐來源檢出並安裝到生產主機上的更新問題;我個人認爲這不是一個好主意。我認爲這樣做有風險的原因在於,很難完全確定您安裝的一系列庫與您所測試的庫完全一致,因此部署有可能無法預測。 Web應用程序可能會激怒這個問題,因爲您很可能會將相同的代碼部署到可能不同步的多個生產框。雖然perl社區在嘗試發佈向後兼容的高質量代碼方面做得非常出色,但當出現問題時,通常很難找出結果。這就是爲什麼正在開發紙箱的原因,因爲這會創建一個緩存所有需要在特定版本中凍結的分發tarball,以便可預測地部署您的代碼。儘管如此,如果您很樂意接受這種風險並在事件發生時解決問題,那麼本地安裝應該適合您。但是,至少我會強烈建議將安裝到local :: lib,這樣您可以在安裝更新之前備份舊的本地庫,以便在事情搞糟時有回滾點。

+1

+1上「非常小心的XS Perl庫」 – tangent 2012-02-11 17:46:19

+0

我想也許我們指的是兩個不同的東西。我正在討論如何從中央源代碼控制系統(如GitHub)提取特定分支或「版本」的應用程序代碼。看來你是指自己的依賴關係,即CPAN包。我同意需要非常小心地確保您的CPAN模塊版本在各個節點(包括您的開發/登臺環境)中保持一致,但是在部署期間將特定的源代碼分支拉到每個節點似乎是確保應用軟件本身。 – MadHacker 2012-02-12 14:29:54

+0

還有一個問題。在使用Carton的經驗中,處理依賴關係的依賴性有多好?意思是說,如果我的Makefile.PL只包含我的應用程序顯式「需要」或「使用」的軟件包,Carton在分析這些模塊的依賴性方面有多好? – MadHacker 2012-02-12 16:49:03