David Eastman主持了一場技術(shù)版的古董鑒定節(jié)目，通過回顧前容器(甚至是Chef之前!)時代的軟件工具Capistrano。

譯自 Why Capistrano Got Usurped by Docker and Then Kubernetes 。

當(dāng)我聽著受歡迎的知識產(chǎn)權(quán)和數(shù)字權(quán)利倡導(dǎo)者Cory Doctorow朗讀他的新書的一小部分時，我聽到他提到了加利福尼亞州的 Capistrano。但我當(dāng)然還記得Capistrano，這是一種流行于2010年代初的遠程服務(wù)器自動化工具——它實際上是容器和Kubernetes之前的工具。

我有時對隨著時間流逝失去流行度的常用技術(shù)感興趣。當(dāng)然，Capistrano并沒有真正死亡——即使我正在使用過去式來描述它。開源工具從未真正死亡，它們只是變得不受歡迎(并可能被儲存在閣樓中)。我記得在十多年前曾將Capistrano用作遠程服務(wù)器自動化工具。它會使用SSH按照腳本允許您將更新部署到目標服務(wù)器。更新可能是一個新的可執(zhí)行文件，可能是一些代碼，可能是一些配置，可能是一些數(shù)據(jù)庫更改。很好，但為什么要回顧一個不再常用的系統(tǒng)呢？

首先，為了理解趨勢，回顧過去的例子很有幫助。當(dāng)某樣?xùn)|西的流行度下降時注意其點也很有幫助，同時檢查我們是否失去了任何東西。當(dāng)前的技術(shù)只是時間線上的一個小插曲，如果你偶爾回頭看一眼，預(yù)測接下來會發(fā)生什么會容易得多。如果您需要在新站點上處理部署，除了您自己偏愛的工具之外，擁有一系列工具也很好。您甚至可能不得不在舊堆棧中使用Capistrano。因此，讓我們來評估這件古董，看看它有多大的價值。

環(huán)境

Capistrano了解您將處理的三個基本環(huán)境: 通常是生產(chǎn)，暫存和開發(fā)。開發(fā)環(huán)境可能是筆記本電腦;暫存環(huán)境可能是某種QA可以訪問的云服務(wù)器。使用這些定義，Capistrano可以針對特定計算機執(zhí)行操作。

任務(wù)和角色

Capistrano中的基本命令是任務(wù)。這些是在部署的不同階段執(zhí)行的。但是要過濾這些任務(wù)，您可以使用角色來描述您正在處理的系統(tǒng)的哪一部分:

role :app, "my-app-server.com"
role :web, "my-static-server.com"
role :db, "my-db-server.com"

這表示應(yīng)用程序服務(wù)器(生成動態(tài)內(nèi)容的部分)、網(wǎng)頁或Web服務(wù)器以及數(shù)據(jù)庫作為單獨的部分。您當(dāng)然可以創(chuàng)建自己的定義。

或者，您可以更多地關(guān)注環(huán)境分離，而角色在其下操作。對于生產(chǎn)環(huán)境的描述，我們可能會設(shè)置以下內(nèi)容:

# config/deploy/production.rb


server "11.22.333.444"， user: "ubuntu"， roles: %w{app db web}

默認部署任務(wù)具有代表部署階段的幾個子任務(wù):

• deploy:starting 開始部署，確保先決條件得到滿足
• deploy:updating 使用新版本更新服務(wù)器
• deploy:publishing 發(fā)布新版本
• deploy:finishing 完成部署，開始清理
• deploy:upload 將文件復(fù)制到當(dāng)前部署的版本。這對于分階段更新文件很有用
• deploy:rollback 全部回滾

這是一個自定義的部署任務(wù)的示例。這種類似ruby的代碼使用角色來過濾任務(wù)，以及部署的階段。在本例中，我們可以在完成之前更新style.css文件:

namespace :deploy do
   after :finishing, :upload do
     on roles(:web) do
       path = "web/assets"
       upload! "themes/assets/style.css", "#{path}"
     end
     on roles(:db) do
       # Migrate database
     end
   end
 end

在Capistrano安裝后，您可以在命令行中使用以下命令觸發(fā)此操作:

默認部署流程及相應(yīng)的回滾流程。這是一個更詳細的示例:

deploy
  deploy:starting
    [before]
      deploy:ensure_stage
      deploy:set_shared_assets
    deploy:check
  deploy:started
  deploy:updating
    git:create_release
    deploy:symlink:shared
  deploy:updated
    [before]
      deploy:bundle
    [after]
      deploy:migrate
      deploy:compile_assets
      deploy:normalize_assets
  deploy:publishing
    deploy:symlink:release
  deploy:published
  deploy:finishing
    deploy:cleanup
  deploy:finished
    deploy:log_revision

您可以看到鉤子——"started"、"updated"、"published"和"finished"——它們對應(yīng)于動作"starting"、"publishing"等。這些用于使用before和after子句將自定義任務(wù)掛鉤到流程中，就像我們上面看到的那樣。

請注意，在發(fā)布后創(chuàng)建或更新一個指向最新版本的"current"符號鏈接。如果在任何步驟中部署失敗，current符號鏈接仍指向舊版本。

那么發(fā)生了什么?

"先運行這個，然后運行那個"的模型并不能總是很好地預(yù)測部署后您的系統(tǒng)會是什么樣子。像Chef這樣的工具更擅長處理蔓延的系統(tǒng)，因為它們從模型開始，然后說“使這個設(shè)置為真”。Chef以收斂和冪等作為工作方式。丟失的位會被添加，但在那之后重新應(yīng)用相同的步驟不會改變?nèi)魏问虑椤Ｒ虼?，對相同操作的多次?zhí)行不會對狀態(tài)產(chǎn)生副作用。

Capistrano的靈活性會允許較少經(jīng)驗的開發(fā)人員建立工作但不穩(wěn)定的部署。

相比之下，單個Docker鏡像允許對OS、包、庫和代碼進行系統(tǒng)性控制。它還允許筆記本電腦和云服務(wù)器以相似的方式對待——僅僅作為掛載容器的地方。

最后，Kubernetes在不必擔(dān)心速度變慢和超時的情況下處理了集群。擁有一個完全透明的基礎(chǔ)設(shè)施，以及運行所有方面的所需服務(wù)和確切配置的能力，使DevOps團隊的生活更加輕松。與更改已經(jīng)運行的服務(wù)不同，可以創(chuàng)建新容器并終止舊容器。

從現(xiàn)代觀點來看，Capistrano的另一個問題是它是用Ruby構(gòu)建的。Ruby語言不公平地與Ruby on Rails的流行程度聯(lián)系在一起;那已經(jīng)隨著Node.js和JavaScript的興起而衰落?？傮w而言，其他語言和語言趨勢在流行度上已經(jīng)超過了它: 例如，Python已經(jīng)成為首選的腳本語言。所示的任務(wù)使用了一個DSL，它實際上是ruby Rake構(gòu)建工具。

是否損失了什么呢？可能。擁有一組自定義任務(wù)以進行快速更改確實鼓勵了黑客方法，但它也允許進行較小的臨時基于事件的更改?！笆勾烁陌l(fā)生”而不是“我總是希望服務(wù)器看起來像這樣”。

更好的說法可能是，像Capistrano這樣的工具出現(xiàn)在任何團隊的部署之旅的路徑上，作為在需要更廣闊的視野之前的一個路徑點。但即使作為一個蒙塵的遺跡，Capistrano仍然是一個偉大的模塊化工具，用于自動化Web應(yīng)用程序的部署和維護。

至于加利福尼亞州的Capistrano？恐怕是壞消息。

圖片

驚喜

整理完文章后，我發(fā)現(xiàn)原來 Capistrano 就在我身邊， vagrant 用了它：

圖片