為什么Capistrano被Docker和Kubernetes取代了
David Eastman主持了一場技術版的古董鑒定節目，通過回顧前容器(甚至是Chef之前!)時代的軟件工具Capistrano。
譯自 Why Capistrano Got Usurped by Docker and Then Kubernetes 。
當我聽著受歡迎的知識產權和數字權利倡導者Cory Doctorow朗讀他的新書的一小部分時，我聽到他提到了加利福尼亞州的 Capistrano。但我當然還記得Capistrano，這是一種流行于2010年代初的遠程服務器自動化工具——它實際上是容器和Kubernetes之前的工具。
我有時對隨著時間流逝失去流行度的常用技術感興趣。當然，Capistrano并沒有真正死亡——即使我正在使用過去式來描述它。開源工具從未真正死亡，它們只是變得不受歡迎(并可能被儲存在閣樓中)。我記得在十多年前曾將Capistrano用作遠程服務器自動化工具。它會使用SSH按照腳本允許您將更新部署到目標服務器。更新可能是一個新的可執行文件，可能是一些代碼，可能是一些配置，可能是一些數據庫更改。很好，但為什么要回顧一個不再常用的系統呢？
首先，為了理解趨勢，回顧過去的例子很有幫助。當某樣東西的流行度下降時注意其點也很有幫助，同時檢查我們是否失去了任何東西。當前的技術只是時間線上的一個小插曲，如果你偶爾回頭看一眼，預測接下來會發生什么會容易得多。如果您需要在新站點上處理部署，除了您自己偏愛的工具之外，擁有一系列工具也很好。您甚至可能不得不在舊堆棧中使用Capistrano。因此，讓我們來評估這件古董，看看它有多大的價值。
環境
Capistrano了解您將處理的三個基本環境: 通常是生產，暫存和開發。開發環境可能是筆記本電腦;暫存環境可能是某種QA可以訪問的云服務器。使用這些定義，Capistrano可以針對特定計算機執行操作。
任務和角色
Capistrano中的基本命令是任務。這些是在部署的不同階段執行的。但是要過濾這些任務，您可以使用角色來描述您正在處理的系統的哪一部分:
role :app, "my-app-server.com"
role :web, "my-static-server.com"
role :db, "my-db-server.com"這表示應用程序服務器(生成動態內容的部分)、網頁或Web服務器以及數據庫作為單獨的部分。您當然可以創建自己的定義。
或者，您可以更多地關注環境分離，而角色在其下操作。對于生產環境的描述，我們可能會設置以下內容:
# config/deploy/production.rb
server "11.22.333.444"， user: "ubuntu"， roles: %w{app db web}默認部署任務具有代表部署階段的幾個子任務:
- deploy:starting 開始部署，確保先決條件得到滿足
- deploy:updating 使用新版本更新服務器
- deploy:publishing 發布新版本
- deploy:finishing 完成部署，開始清理
- deploy:upload 將文件復制到當前部署的版本。這對于分階段更新文件很有用
- deploy:rollback 全部回滾
這是一個自定義的部署任務的示例。這種類似ruby的代碼使用角色來過濾任務，以及部署的階段。在本例中，我們可以在完成之前更新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安裝后，您可以在命令行中使用以下命令觸發此操作:
默認部署流程及相應的回滾流程。這是一個更詳細的示例:
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"——它們對應于動作"starting"、"publishing"等。這些用于使用before和after子句將自定義任務掛鉤到流程中，就像我們上面看到的那樣。
請注意，在發布后創建或更新一個指向最新版本的"current"符號鏈接。如果在任何步驟中部署失敗，current符號鏈接仍指向舊版本。
那么發生了什么?
"先運行這個，然后運行那個"的模型并不能總是很好地預測部署后您的系統會是什么樣子。像Chef這樣的工具更擅長處理蔓延的系統，因為它們從模型開始，然后說“使這個設置為真”。Chef以收斂和冪等作為工作方式。丟失的位會被添加，但在那之后重新應用相同的步驟不會改變任何事情。因此，對相同操作的多次執行不會對狀態產生副作用。
Capistrano的靈活性會允許較少經驗的開發人員建立工作但不穩定的部署。
相比之下，單個Docker鏡像允許對OS、包、庫和代碼進行系統性控制。它還允許筆記本電腦和云服務器以相似的方式對待——僅僅作為掛載容器的地方。
最后，Kubernetes在不必擔心速度變慢和超時的情況下處理了集群。擁有一個完全透明的基礎設施，以及運行所有方面的所需服務和確切配置的能力，使DevOps團隊的生活更加輕松。與更改已經運行的服務不同，可以創建新容器并終止舊容器。
從現代觀點來看，Capistrano的另一個問題是它是用Ruby構建的。Ruby語言不公平地與Ruby on Rails的流行程度聯系在一起;那已經隨著Node.js和JavaScript的興起而衰落。總體而言，其他語言和語言趨勢在流行度上已經超過了它: 例如，Python已經成為首選的腳本語言。所示的任務使用了一個DSL，它實際上是ruby Rake構建工具。
是否損失了什么呢？可能。擁有一組自定義任務以進行快速更改確實鼓勵了黑客方法，但它也允許進行較小的臨時基于事件的更改。“使此更改發生”而不是“我總是希望服務器看起來像這樣”。
更好的說法可能是，像Capistrano這樣的工具出現在任何團隊的部署之旅的路徑上，作為在需要更廣闊的視野之前的一個路徑點。但即使作為一個蒙塵的遺跡，Capistrano仍然是一個偉大的模塊化工具，用于自動化Web應用程序的部署和維護。
至于加利福尼亞州的Capistrano？恐怕是壞消息。
圖片
驚喜
整理完文章后，我發現原來 Capistrano 就在我身邊， vagrant 用了它：
圖片
