標題中提到 Vagrant 可能會讓您相信這是另一篇關于共享應用程序環境的力量的文章。就像代碼一樣，或者 Vagrant 如何成為該方法的重要推動者。但是，關于該主題的內容很多，現在它的好處已廣為人知。相反，我們將描述我們以一種不尋常的方式使用 Vagrant 的經驗。

一個新穎的想法

這個想法是擴展運行 Windows 的開發人員工作站，以支持在 VM 中運行 Linux 內核，并使兩者之間的橋梁盡可能無縫。我們的動機是消除開發中的某些痛點或限制。這是由開發人員本地工作站的操作系統選擇所帶來的。無論是組織級別的要求、監管執行還是任何其他可能或可能不在開發人員控制之下的事情。

這種方法并不是唯一評估過的方法，因為我們還考慮過將工作完全轉移到 VM 上的客戶操作系統上，使用 Docker 容器，利用 Cygwin。是的，更換主機操作系統的可能性也受到了挑戰。然而，我們發現在這種方法中技術結合的方式可能非常強大。我們將借此機會交流一些經驗教訓和該方法的局限性，并分享一些關于如何解決某些問題的想法。

為什么是流浪者？

我們試圖解決的問題以及我們如何嘗試解決的概念不一定取決于 Vagrant。事實上，這個想法是基于在本地管理程序上部署虛擬機 (VM)。乍一看，在本地運行 VM 似乎有些可疑。但是，正如我們發現的那樣，這為我們提供了某些優勢，使我們能夠通過創建工作站擴展來為開發人員創造更好的體驗。

我們選擇 VirtualBox 作為虛擬化 提供商 主要是因為我們熟悉該工具，而這正是 Vagrant 發揮作用的地方。 Vagrant 是構成開源 HashiCorp Suite 的工具之一，旨在解決自動化基礎設施配置方面的不同挑戰。

特別是，Vagrant 關注在開發階段管理 VM 環境注意，對于生產環境，同一套件中還有其他工具更適合該工作。更具體地說，基于配置即代碼的 Terraform 和 Packer。這意味著可以在團隊成員之間輕松共享環境，并且更改受版本控制并且可以輕松跟蹤。使最終產品（環境）始終可重復。Vagrant 是固執己見的，因此聲明一個環境，它的配置變得簡潔，這使得它易于編寫和理解。

在我們的博文DevOps 和虛擬化中閱讀更多關于 VM 對開發的影響 。

為什么選擇 Ansible？

在決定使用 Vagrant 作為我們的解決方案并享受 VM 的自動化生產之后；下一步是找到一種與 Vagrant 所宣傳的原則相結合的方式來配置該 VM。

我們不建議讓 Vagrant 在環境中啟動虛擬機，然后為您的系統手動安裝和配置依賴項。在 Vagrant 中， 供應 商是核心，您可以從中選擇很多。在我們的例子中，只要我們的配置保持簡單，我們就堅持使用 Shell（Vagrant 只需將腳本上傳到客戶操作系統并執行它們）。

不久之后，很明顯這種方法無法很好地擴展，而且腳本過于冗長。最大的痛點是開發人員需要以有利于冪等性的方式編寫。這是由于需要向配置添加步驟的常見情況。一直以來都是矯枉過正，不得不從頭開始重新配置所有內容。

此時，我們決定使用 Ansible。RedHat 的 Ansible 是另一個開源自動化工具，它圍繞管理播放執行的理念而構建。使用劇本，其中劇本可以被認為是映射到環境中一組主機的任務列表。

理想情況下，這些游戲應該是冪等的，但這并不總是可能的。再次，將編寫的整個配置聲明 為 YAML 中的代碼。這一策略取得的最大勝利是社區完成了繁重的工作。它提供了 Ansible 模塊，即執行特定任務的可配置 Python 腳本，幾乎可以用于任何人可能想做的事情。根據行業標準安裝依賴項和配置來賓變得非常簡單和簡潔。由于模塊通常是高度自以為是的，因此無需開發人員深入了解細節。所有這些概念都與 Vagrant 的原則完美結合，并將兩部作品融合在一起，就像一種魅力。

在讓兩者一起工作時，有一個重大挑戰需要克服。我們的主機運行 Windows，盡管 Ansible 隨著時間的推移增加了對管理 Windows 目標的更多支持，但它根本無法從 Windows 控制機器上運行。這給我們留下了兩個選擇：擁??有一個可以充當 Ansible 控制器的更進一步的環境，或者讓來賓 VM 運行 Ansible 來配置自己的更簡單的方法。

這種方法的缺點是會污染目標環境。我們愿意為此妥協，因為替代方案很麻煩。Vagrant 允許您通過簡單地替換供應商標識符來實現這一點。從 ansible 更改為 ansible_local，它會自動在客戶機上安裝所需的 Ansible 二進制文件和依賴項以供您使用。

文件共享

我們想要實現的基石之一是使本地工作空間在來賓操作系統中可用的可能性。這樣您就可以隨時使用構成工作環境的工具來輕松地在來賓內部運行構建。解決此問題的選項很多，并且根據用例而有所不同。最簡單的方法是依靠 VirtualBox 的文件共享功能，它提供近乎即時的雙向同步。設置它是 VagrantFile 中的一條線。

這里的主要目標是與來賓共享代碼存儲庫。它還可以方便地復制其他一些工具的配置。例如，可能會發現為 Maven 的用戶設置文件、整個本地存儲庫、用于身份驗證的本地證書等配置文件共享很有用。

轉發端口

VirtualBox 的網絡選項對我們來說是一個強大的盟友。有許多選項可用于創建專用網絡（當您有多個 VM 時）或將 VM 暴露在與主機相同的網絡上。對我們來說，僅依賴主機網絡就足夠了（即虛擬機只能從主機訪問）。然后將多個端口配置為通過簡單的 NAT 進行轉發。

這樣做的主要好處是您不需要不斷更改軟件的配置，無論它是在本地執行還是在來賓內部執行。這一切都可以在 Vagrant 中通過編寫一行配置代碼來實現。可以在任一方向（主機到訪客或訪客到主機）配置此 NAT。

把它放在一起

為我們的解決方案定義了基礎之后，現在讓我們簡要介紹一下實現所有這些所需的內容。您會看到，在大多數情況下，它只需要最少的配置即可達到我們的目標。

難題的第一部分是 Vagrantfile，我們在其中定義來賓操作系統的基本映像（我們使用 CentOS 7）。我們要分配的資源（內存、vcpus、存儲）、文件共享、網絡詳細信息和配置。

請注意，vagrant 插件“vagrant-vbguest”對于自動確定指定來賓操作系統的 VirtualBox 來賓添加二進制文件的適當版本并安裝它們很有用。我們還選擇將 Vagrant 配置為更喜歡使用捆綁在自身內部的二進制文件來實現 SSH 等功能（VAGRANT_PREFER_SYSTEM_BIN 設置為 0），而不是依賴主機上已經安裝的軟件。我們發現這樣可以實現更簡單、更可重復的設置過程。

工作的第二個主要部分是集成 Ansible 來配置 VM。為此，我們選擇利用 Vagrant 的 ansible_local，它通過在客戶機中即時安裝 Ansible 并在本地運行配置來工作。

現在，所需要做的就是提供一個 Ansible playbook.yml 文件，在這里可以定義需要在來賓操作系統上設置的任何特定配置或軟件。

我們更進一步，利用了第三方 Ansible 角色，而不是重新發明輪子并不得不處理開發和持續維護成本。

Ansible Galaxy 是社區提供的此類角色的在線存儲庫。你可以通過 ansible-galaxy 命令安裝這些。

由于 Vagrant 正在抽象出 Ansible 的安裝和調用，因此我們需要依賴 Vagrant。為什么？確保在執行 playbook 時這些角色已安裝并可用。這是通過galaxy_command 參數實現的。實現這一點的最優雅的方法是提供一個 requirements.yml 文件，其中包含所需角色的列表，并將其傳遞給 ansible-galaxy 命令。最后，我們需要確保 通過文件共享（默認情況下 VagrantFile 的目錄是共享的）將Ansible 文件提供給來賓操作系統，并且它們的路徑是相對于 /vagrant 的。

打造無縫體驗...... BAT 助您一臂之力

我們正在尋求一種解決方案，使從本地工作跳轉到在 VM 內部工作盡可能容易。如果可能的話，我們還希望能夠進行此切換，而無需通過不同的窗口移動。

出于這個原因，我們編寫了幾個實用程序批處理腳本，使該過程變得更加容易。我們想利用我們的整個工作區目錄與來賓 VM 同步的事實。這使我們能夠從主機中的當前位置推斷來賓工作區中的路徑。例如，如果在我們的主機上，我們位于 C:WorkspaceProjectX 并且工作空間映射到 vagrantworkspace，那么我們希望能夠輕松地在 vagrantworkspaceprojectx 中運行命令，而無需跳過障礙。

為此，我們在路徑上放置了一個腳本，該腳本將接受一個命令并使用 Vagrant 的命令標志在適當的目錄中執行它。這個技巧的偉大之處在于，它允許我們通過指定自定義構建命令，通過 IDE 使用 Maven 在客戶機上觸發構建。

我們還為同一腳本添加了直接在與主機上當前位置對應的路徑中通過 SSH 連接到 VM 的功能。為此，在 VM 配置中，我們設置了一個文件共享，允許我們同步 vagrant 用戶主文件夾中的 bashrc 目錄。這使我們可以在登錄時在來賓上以所需的路徑（即時派生）cd。

最后，由于優秀的開發人員是高效的開發人員，我們還希望能夠從任何地方管理 VM。因此，例如，如果我們還沒有啟動 VM，我們就不需要繼續導航到托管 VagrantFile 的目錄。

這是通過設置 %VAGRANT_CWD% 變量實現的標準 Vagrant 功能。我們在頂部添加的是在專用用戶變量中永久定義它的能力。并且僅在我們想要管理此特定環境時才進行設置。

文件 I/O 性能

在測試解決方案的過程中，我們遇到了一些我們認為相關的限制。

問題圍繞文件共享機制展開。盡管有許多可用選項，但該方法可能不適合需要密集文件 I/O 的某些情況。我們首先嘗試設置一個普通的 VirtualBox 文件共享，這是一個很好的起點，因為它可以工作。而且不需要很多配置，它可以瞬間同步 2 路，這在大多數情況下都很棒。

當我們嘗試使用 NPM 運行 FrontEnd 構建時，第一面墻就被擊中了，該構建依賴于為常見的依賴包創建軟鏈接。軟鏈接需要在 Windows 主機上授予特定權限，但它仍然不能很好地工作。我們嘗試通過使用 RSync 來解決這個問題，默認情況下它只同步一個方向的變化并按需運行。同樣，有一些方法可以讓它輪詢變化，理論上可以通過分別配置每個方向來設置雙向性。

但是，這會產生競爭條件，可能會導致更改被逆轉或數據丟失。另一種選擇，SMB 共享，需要更多的工作來設置，最終性能不足以滿足我們的需求。

最后，我們找到了一個解決方案，讓 NPM 構建在不使用軟鏈接的情況下運行，這使我們能夠恢復使用原生 VirtualBox 文件共享。第一個警告是，這需要在我們的源代碼存儲庫中進行更改，這并不理想。此外，由于我們典型的基于 NPM 的前端構建之一涉及大量依賴項，文件 I/O 的大量使用導致文件共享鎖定，從而降低性能。

結論

其目的是通過運行 Linux 內核來擴展運行 Windows 的工作站，以盡可能輕松地在任一環境中管理和切換工作。我們努力的最終結果證明在某些情況下是一個非常方便的解決方案。

當您需要在類似于生產的環境中運行應用程序時，我們的設置特別有用。或者當您想要運行某些工具進行開發時，這更容易在 Linux 主機上安裝和配置。我們已經向您展示了如何在 Vagrant 和 Ansible 等工具的幫助下，以一種可以一致共享和重新創建的方式輕松創建設置。同時保持配置簡潔。從性能的角度來看，該解決方案非常適合從計算角度來看要求很高的任務。但是，對于由于同步開銷而需要大量文件 I/O 的情況，情況就不一樣了。