LinchPin：一个使用 Ansible 的简化的编配工具

2016 年末开始的 LinchPin，现在已经拥有一个 Python API 和一个成长中的社区。

去年，我的团队公布了 LinchPin，这是一个使用 Ansible 的混合云 编配 orchestration 工具。 配给 provision 云资源从来没有这么容易便捷过。借助 Ansible 强力支持，LinchPin 专注于简化，使云资源让用户可以触手可及。在这篇文章中，我将介绍 LinchPin，并且去看看过去的 10 个月该项目是如何逐渐成熟。

（LCTT 译注：关于 orchestration 应该翻译成惯例的“编排”还是“编配”，有个 @wffger 提出的建议 ，欢迎大家参与讨论。）

LinchPin 刚出现的时候，使用 ansible-playbook 命令去运行 LinchPin ，虽然可以完成，但是还是很复杂的，LinchPin 现在有一个前端命令行用户界面（CLI），它是用 Click 写的，而且它使 LinchPin 比以前更简化。

没有止步于 CLI，LinchPin 现在还有一个 Python API，它可以用于管理资源，比如，Amazon EC2 和 OpenStack 实例、网络、存储、安全组等等。这个 API 文档 可以在你想去尝试 LinchPin 的 Python API 时帮助你。

Playbook 是一个库

因为 LinchPin 的核心是 Ansible playbook，其角色、模块、过滤器，以及任何被称为 Ansible 模块的东西都被移进 LinchPin 库中，这意味着我们虽然可以直接调用 playbook，但它不是资源管理的首选机制。linchpin 可执行文件事实上已经成为该命令行的前端。

深入了解命令行

让我们深入了解 linchpin 命令行：

$ linchpin
Usage: linchpin [OPTIONS] COMMAND [ARGS]...

  linchpin: hybrid cloud orchestration

Options:
  -c, --config PATH       Path to config file
  -w, --workspace PATH    Use the specified workspace if the familiar Jenkins
                          $WORKSPACE environment variable is not set
  -v, --verbose           Enable verbose output
  --version               Prints the version and exits
  --creds-path PATH       Use the specified credentials path if WORKSPACE
                          environment variable is not set
  -h, --help              Show this message and exit.

Commands:
  init     Initializes a linchpin project.
  up       Provisions nodes from the given target(s) in...
  destroy  Destroys nodes from the given target(s) in...

你可以立即看到一个简单的描述，以及命令的选项和参数。这个帮助的最下面的三个命令是本文的重点内容。

配置文件

之前有个名为 linchpin_config.yml 的文件。但现在这个文件没有了，替换它的是一个 ini 形式的配置文件，称为 linchpin.conf。虽然这个文件可以被修改或放到别的地方，它可以放置在配置文件容易找到的库路径中。在多数情况下，linchpin.conf 文件是不需要去修改的。

工作空间

工作空间 workspace 是一个定义好的文件系统路径，它是一个逻辑上的资源组。一个工作空间可以认为是一个特定环境、服务组、或其它逻辑组的一个单点。它也可以是一个所有可管理资源的大的存储容器。

工作空间可以在命令行上使用 --workspace （-w） 选项去指定，随后是工作空间路径。它也可以使用环境变量指定（比如，bash 中的 $WORKSPACE）。默认工作空间是当前目录。

初始化 (linchpin init)

运行 linchpin init 将生成一个需要的目录结构，以及一个 PinFile、topology、和 layout 文件的示例：

$ export WORKSPACE=/tmp/workspace
$ linchpin init
PinFile and file structure created at /tmp/workspace
$ cd /tmp/workspace/
$ tree
.
├── credentials
├── hooks
├── inventories
├── layouts
│   └── example-layout.yml
├── PinFile
├── resources
└── topologies
    └── example-topology.yml

在这个时候，可以执行 linchpin up ，然后提供一个 libvirt 虚拟机，和一个名为 linchpin-centos71 的网络。会生成一个 库存 inventory ，并放在 inventories/libvirt.inventory 目录中。它可以通过读取 topologies/example-topology.yml 和 topology_name 的值了解它。

配给 provisioning (linchpin up)

一旦有了一个 PinFile、拓扑、和一个可选的布局，就可以 配给 provisioning 了。

我们使用 dummy （模拟）工具，因为用它来配给非常简单；它不需要任何额外的东西（认证、网络、等等）。dummy 配给程序会创建一个临时文件，它表示所配给的主机。如果临时文件没有任何数据，说明主机没有被配给，或者它已经被销毁了。

dummy 配给程序的目录树大致如下：

$ tree
.
├── hooks
├── inventories
├── layouts
│   └── dummy-layout.yml
├── PinFile
├── resources
└── topologies
    └── dummy-cluster.yml

PinFile 也很简单；它指定了它的拓扑，并且为 dummy1 目标提供一个可选的布局：

topology_name: "dummy_cluster" # topology name
resource_groups:
  -
    resource_group_name: "dummy"
    resource_group_type: "dummy"
    resource_definitions:
      -
        name: "web"
        type: "dummy_node"
        count: 3

执行命令 linchpin up 将基于上面的 topology_name（在这个案例中是 dummy_cluster）生成 resources 和 inventory 文件。

$ linchpin up
target: dummy1, action: up

$ ls {resources,inventories}/dummy*
inventories/dummy_cluster.inventory  resources/dummy_cluster.output

要验证 dummy 集群的资源，可以检查 /tmp/dummy.hosts：

$ cat /tmp/dummy.hosts
web-0.example.net
web-1.example.net
web-2.example.net

Dummy 模块为假定的（或模拟的）配给提供了一个基本工具。关于在 OpenStack、AWS EC2、Google Cloud 上和 LinchPin 的更多详细情况，可以去看示例。

库存 inventory 生成

作为上面提到的 PinFile 的一部分，可以指定一个 layout。如果这个文件被指定，并且放在一个正确的位置上，就会为配给的资源自动生成一个用于 Ansible 的静态 库存 inventory 文件：

dummy1:
  topology: dummy-cluster.yml
  layout: dummy-layout.yml
  hooks:
    postup:
      - name: ping
        type: ansible
        actions:
          - dummy_ping.yaml
      - name: database
        type: shell
        actions:
          - setup_db.sh
          - init_db.sh

基本概念是有三个 postup 动作要完成。Hook 是从上到下运行的，因此，Ansible ping 任务将首先运行，紧接着是两个 shell 任务， setup_db.sh 和 init_db.sh。假设 hook 运行成功。将发生一个系统的 ping，然后，一个数据库被安装和初始化。

认证的驱动程序

在 LinchPin 的最初设计中，开发者决定在 Ansible playbooks 中管理认证；然而，逐渐有更多的 API 和命令行驱动的工具后，意味着认证将被置于 playbooks 库之外，并且还可以根据需要去传递认证值。

配置

让用户使用驱动程序提供的认证方法去完成这个任务。举个实例，如果对于 OpenStack 调用的拓扑，标准方法是使用一个 yaml 文件，或者类似于 OS_ 前缀的环境变量。clouds.yaml 文件是一个 profile 文件的组成部分，它有一个 auth 节：

clouds:
  default:
    auth:
      auth_url: http://stack.example.com:5000/v2.0/
      project_name: factory2
      username: factory-user
      password: password-is-not-a-good-password

更多详细信息在 OpenStack documentation。

这个 clouds.yaml 或者任何其它认证文件位于 default_credentials_path （比如，~/.config/linchpin）中，并在拓扑中引用：

作者简介：

Clint Savage - 工作于 Red Hat 是一位负责原子项目（Project Atomic）的高级软件工程师。他的工作是为 Fedora、CentOS、和 Red Hat Enterprise Linux（RHEL）提供自动原子服务器构建。

---

via: <https://opensource.com/article/17/6/linchpin>

作者：[Clint Savage](https://opensource.com/users/herlo) 译者：[qhwdw](https://github.com/qhwdw) 校对：[wxy](https://github.com/wxy)

本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出