kdevops_vagrant

kdevops_vagrant 是一个 Ansible 角色，用于将一个社区共享的 kdevops Vagrant 文件部署到你的项目中。这个 Ansible 角色会复制 Vagrantfile 到项目命名空间目录，并且可以选择为你运行 vagrant。

这个 Ansible 角色的目标是让不同项目之间能够轻松地共享同一个可扩展的 Vagrantfile，并为该 Vagrantfile 提供一个归宿，从而允许贡献者对其进行改进和文档化。

项目命名空间目录

项目命名空间目录是你的项目的顶层目录，它定义了你的项目。例如，假设你有一个叫 kdevops 的开发项目，所有文件存放在：

/home/user/devel/kdevops/

在这种情况下，项目命名空间目录就是 kdevops。默认情况下，这个 Ansible 角色通过使用存储调用此角色的 playbook 文件的目录的基本名称来推断你的项目命名空间目录。例如，假设你的 playbook 文件存放在：

/home/user/devel/kdevops/playbooks/kdevops_vagrant_nodes.yml

你可以在另一个文件中覆盖数据：

/home/user/devel/kdevops/playbooks/kdevops_vagrant_nodes_override.yaml

你的 playbook 文件所在的目录是：

/home/user/devel/kdevops/playbooks/

该目录的基本名称是：

/home/user/devel/kdevops/

这将是该项目推断出的项目命名空间目录。你可以使用下面描述的 force_project_dir 角色变量来覆盖它。

项目命名空间

项目命名空间用于本角色携带的 Vagrantfile 中，允许你通过环境变量覆盖 vagrant 使用的默认值。项目命名空间是从上述项目命名空间目录推断来的。例如，在上面的案例中，项目目录命名空间是：

/home/user/devel/kdevops/

项目命名空间被推断为 kdevops。该名称的大写版本将作为环境变量的前缀，所以为 KDEVOPS。破折号将被下划线替换，因为 shell 变量不能包含破折号。因此，如果项目目录命名空间是：

/home/user/devel/some-cool-project/

项目命名空间将是： SOME_COOL_PROJECT

要求

必须安装 vagrant。

Vagrant 用于轻松部署非云虚拟机。支持的提供程序列表如下：

• Virtualbox
• libvirt (KVM)

支持的操作系统包括：

• OS X
• Linux

以普通用户身份运行 libvirt

我们使用 https://github.com/mcgrof/libvirt-user Ansible 角色来启用普通用户。有关该逻辑的更多信息，请阅读那里的文档。

通过不同文件覆盖节点配置

支持在 vagrant 中覆盖变量的更好方法是使用 $(project)_node_override.yaml 文件。因此，例如，对于 [https://github.com/mcgrof/kdevops](kdevops 项目)，你可以在 Git 之外的另一个可选文件中覆盖数据：

/home/user/devel/kdevops/playbooks/kdevops_vagrant_nodes_override.yaml

环境变量

只有在使用覆盖文件无效的情况下，你可以使用环境变量。但是，使用环境变量是逐个情况来决定的，因为我们必须为每个新添加的变量实现支持。使用覆盖文件后，只需添加新功能即可覆盖任何内容。

环境变量以项目命名空间的大写版本为前缀，如上所述。我们称其为 ${PN_U}。考虑到这个前缀，以下环境变量可以修改 Vagrantfile 的功能：

• ${PN_U}_VAGRANT_NODE_CONFIG：允许你覆盖使用的默认配置文件
• ${PN_U}_VAGRANT_PROVIDER：允许你覆盖 vagrant 使用的提供程序
• ${PN_U}_VAGRANT_LIMIT_BOXES：允许你启用盒子限制
• ${PN_U}_VAGRANT_LIMIT_NUM_BOXES：限制的盒子数量
• ${PN_U}_VAGRANT_QEMU_GROUP：覆盖使用的 qemu 用户

限制 vagrant 的盒子数量

默认情况下，vagrant 将尝试创建在你的节点配置文件中指定的所有节点。默认情况下，这是 ${PN_L}_nodes.yml，其中 $PN_L 是上述项目命名空间的小写版本。例如，对于 kdevops 项目，这将是 kdevops_nodes.yml。

例如，如果你希望 vagrant 只创建 kdevops 项目的一个盒子，你可以使用：

export KDEVOPS_VAGRANT_LIMIT_BOXES="yes"
export KDEVOPS_VAGRANT_LIMIT_NUM_BOXES=1

显然，你会为不同命名的项目使用不同的前缀。

这将确保仅创建和配置第一个主机，例如。如果你在笔记本电脑上进行开发，并且希望限制使用的资源，这可能会很有用。

Ansible 的使用范围

kdevops 整体设计为对你如何设置系统保持中立，无论是使用 libvirt / Virtualbox 虚拟化的本地系统，裸机系统，还是云环境。

因此，启动过程分为 3 个阶段：

• 启动：虚拟 / 云 / 裸金属
• 配置和安装依赖：将系统添加到 ~/.ssh/config，并安装用户的首选 bash 脚本、.gitconfig 以及通用开发包。这通过 http://github.com/mcgrof/update_ssh_config_vagrant 和 http://github.com/mcgrof/devconfig Ansible 角色处理。
• 开始工作：进行你的工作，通常现在推荐使用 ansible 进行。

我们使用 Ansible 进行 vagrant 的操作仅限于上述的前两个部分。因此，我们使用 Ansible 仅 针对两个 Ansible 角色：

• http://github.com/mcgrof/update_ssh_config_vagrant
• http://github.com/mcgrof/devconfig

我们特意不想扩展这个做法，原因是希望用户直接使用 ansible 来完成后续目标。启动和配置、安装开发依赖的工作必须由 vagrant、terraform 或手动设置裸金属系统的用户来处理。

因此，我们并不鼓励为 vagrant 的使用添加更多 Ansible 角色。这两个角色对于典型的设置应该足够，其他 Ansible 的使用应该手动完成。

Ansible Python 解释器

Ansible 依赖于远程系统中的 python。应使用哪个版本的 python 可能会有所不同，但默认情况下 Ansible 会尝试使用旧版本的 python 解释器，以帮助支持更旧的系统。这个选择对新系统来说并不是最佳的，因此我们鼓励你指定解释器。这最好在清单文件中设置。Vagrantfile 假设你有一个名为 ../hosts 的清单文件，但你可以通过以下方式在 Ansible 配置中覆盖它：

ansible_playbooks:
  # 如果这个文件存在，你可以覆盖其中的任何 Ansible 变量。
  # 此文件是可选的。
  extra_vars: "../extra_vars.yml"
  inventory: "../hosts"
  playbooks:
    - name: "../playbooks/update_ssh_config_vagrant.yml"
    - name: "../playbooks/devconfig.yml"

你的主机文件可能看起来像这样：

[all]
newsystem1
oldsystem1
[all:vars]
ansible_python_interpreter =  "/usr/bin/python3"

[new]
newsystem1
[new:vars]
ansible_python_interpreter =  "/usr/bin/python3"

[old]
oldsystem1
[dev:vars]
ansible_python_interpreter =  "/usr/bin/python2"

在这种情况下，[all] 组将所有的 python 解释器设置为 python3，但最后一条目将确保老系统使用 python2。

Ansible 额外变量与 vagrant 的使用

Ansible 有自己的一套变量优先级层次结构，通过命令行或角色文件等，而这在 [https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html](ansible playbooks variable documentation page) 中有详细文档。

虽然这适合大多数用途，但对想要让用户在不使用版本控制的文件中指定其自定义变体的项目并不完全有利，也无需在命令行上扩展。

由于 kdevops 由一组统一的 Ansible 角色组成，我们支持一种统一的方法来定义对 Ansible 的覆盖。我们通过允许用户在项目根目录中的名为 extra_vars.yml 的文件中覆盖 Ansible 变量来实现这一点。

在 kdevops 项目示例中，这将是：

/home/user/devel/kdevops/extra_vars.yml

当这个文件被设置时，Vagrant Ansible 插件将确保此文件通过 --extra-vars=@file 直接传递给 Ansible。指定文件时，前缀 @ 是必需的。你不必提供 @，我们会为你处理。

所有与 kdevops 一起使用的 Ansible 角色都支持查找这个 extra_vars 文件。

Ansible 角色变量

• run_vagrant: 默认值为 False，设置为 True 时，我们会为你运行 Vagrant
• force_project_dir: 如果设置，这将用作查找 Vagrant 目录并最终复制 Vagrantfile 的目录。默认情况下，这被设置为空，我们推测你的项目目录为 playbook 文件所在目录的父目录。

依赖

无。

示例 Playbook

以下是一个示例 playbook，用于 kdevops 项目，即 kdevops/playbooks/kdevops_vagrant.yml 文件：

---
- hosts: localhost
  roles:
    - role: kdevops_vagrant

在这个特定案例中，注意使用了 localhost。这是因为我们正在将 Vagrantfile 本地提供给 kdevops/vagrant/ 目录。你当然可以使用其他主机。

进一步信息

有关更多示例，请参考该角色的用户之一， https://github.com/mcgrof/kdevops 项目或 https://github.com/mcgrof/oscheck 项目，该代码最初来自于此。

许可证

GPLv2