使用Vagrant和Ansible扩展您的开发工作站

标题中提到 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 的情况，情况就不一样了。