标题中提到Vagrant可能会让您相信这是另一篇关于共享应用程序环境的力量的文章。就像代码一样，或者Vagrant如何成为该方法的重要推动者。关于该主题的内容很多，现在它的好处已广为人知。相反，我们将描述我们以一种不寻常的方式使用Vagrant的经验。

一个新颖的想法

这个想法是扩展运行Windows的开发人员工作站，以支持在VM中运行Linux内核，并使两者之间的桥梁尽可能无缝。我们的动机是消除开发中的某些痛点或限制。这是由开发人员本地工作站的操作系统选择所带来的。无论是组织级别的要求、监管执行还是任何其他可能或可能不在开发人员控制之下的事情。

这种方法并不是唯一评估过的方法，因为我们还考虑过将工作完全转移到VM上的客户操作系统上，使用Docker容器，利用Cygwin。是的，更换主机操作系统的可能性也受到了挑战。我们发现在这种方法中技术结合的方式可能非常强大。我们将借此机会交流一些经验教训和该方法的局限性，并分享一些关于如何解决某些问题的想法。

为什么是流浪者？

我们试图解决的问题以及我们如何尝试解决的概念不一定取决于Vagrant。事实上，这个想法是基于在本地管理程序上部署虚拟机(VM)。乍一看，在本地运行VM似乎有些可疑。正如我们发现的那样，这为我们提供了某些优势，使我们能够通过创建工作站扩展来为开发人员创造更好的体验。

我们选择VirtualBox作为虚拟化提供商主要是因为我们熟悉该工具，而这正是Vagrant发挥作用的地方。Vagrant是构成开源HashiCorpSuite的工具之一，旨在解决自动化基础设施配置方面的不同挑战。

特别是，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进行转发。

把它放在一起

为我们的解决方案定义了基础之后，现在让我们简要介绍一下实现所有这些所需的内容。您会看到，在大多数情况下，它只需要最少的配置即可达到我们的目标。

难题的第一部分是Vagrantfile，我们在其中定义来宾操作系统的基本映像（我们使用CentOS7）。我们要分配的资源（内存、vcpus、存储）、文件共享、网络详细信息和配置。

请注意，vagrant插件“vagrant-vbguest”对于自动确定指定来宾操作系统的VirtualBox来宾添加二进制文件的适当版本并安装它们很有用。我们还选择将Vagrant配置为更喜欢使用捆绑在自身内部的二进制文件来实现SSH等功能（VAGRANT_PREFER_SYSTEM_BIN设置为0），而不是依赖主机上已经安装的软件。我们发现这样可以实现更简单、更可重复的设置过程。

工作的第二个主要部分是集成Ansible来配置VM。为此，我们选择利用Vagrant的ansible_local，它通过在客户机中即时安装Ansible并在本地运行配置来工作。

现在，所需要做的就是提供一个Ansibleplaybook.yml文件，在这里可以定义需要在来宾操作系统上设置的任何特定配置或软件。

我们更进一步，利用了第三方Ansible角色，而不是重新发明轮子并不得不处理开发和持续维护成本。

AnsibleGalaxy是社区提供的此类角色的在线存储库。你可以通过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的情况，情况就不一样了。