document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2025-02-03 23:40:14 +08:00
Code Issues Packages Projects Releases Wiki Activity

PRF:20170630 LinchPin A simplified cloud orchestration tool using Ansible.md

Browse Source 
@qhwdw
This commit is contained in:
wxy 2017-12-21 22:47:14 +08:00
parent 749872a08e
commit 44dc9fe45a
1 changed files with 70 additions and 89 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

159
translated/tech/20170630 LinchPin A simplified cloud orchestration tool using Ansible.md
View File

@ -1,37 +1,27 @@
LinchPin：一个使用 Ansible 的简化的编排工具
LinchPin：一个使用 Ansible 的简化的编配工具
============================================================
### 2016年开始的 LinchPin，现在已经拥有一个 Python API 和一个成长中的社区。
> 2016 年末开始的 LinchPin，现在已经拥有一个 Python API 和一个成长中的社区。
![LinchPin 1.0：一个使用 Ansible 的成熟的混合云编排工具](https://opensource.com/sites/default/files/styles/image-full-size/public/images/business/toolbox-learn-draw-container-yearbook.png?itok=2XFy0htN "LinchPin 1.0: A maturing hybrid cloud orchestration tool using Ansible")
![LinchPin 1.0：一个使用 Ansible 的成熟的混合云编配工具](https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/toolbox-learn-draw-container-yearbook.png?itok=xDbwz1pP "LinchPin 1.0: A maturing hybrid cloud orchestration tool using Ansible")
>Image by : [Internet Archive Book Images][10]. Modified by Opensource.com. CC BY-SA 4.0
过去的一年里，[我的团队公布了][11] [LinchPin][12]，一个使用 Ansible 的混合[云][13]编排工具。准备云资源从来没有这么容易或更快。Ansible 强力支持的 LinchPin，专注于简化，在用户指尖下，将有更多的可用云资源。在这篇文章中，我将介绍 LinchPin，并且去看看过去的 10 个月，有多少成熟的项目。
去年，[我的团队公布了][11] [LinchPin][12]，这是一个使用 Ansible 的混合云<ruby>编配<rt>orchestration</rt></ruby>工具。<ruby>配给<rt>provision</rt></ruby>云资源从来没有这么容易便捷过。借助 Ansible 强力支持，LinchPin 专注于简化，使云资源让用户可以触手可及。在这篇文章中，我将介绍 LinchPin，并且去看看过去的 10 个月该项目是如何逐渐成熟。
（LCTT 译注：关于 orchestration 应该翻译成惯例的“编排”还是“编配”，有个 @wffger 提出的[建议](https://github.com/LCTT/TranslateProject/issues/6715) ，欢迎大家参与讨论。）
LinchPin 刚被引入的时候，使用 **ansible-playbook** 命令去运行 LinchPin ，虽然可以完成，但是还是很复杂的，LinchPin 现在有一个前端命令行用户界面（CLI），它是在 [Click][14] 中写的，而且它使 LinchPin 比以前更简单。
LinchPin 刚出现的时候，使用 `ansible-playbook` 命令去运行 LinchPin ，虽然可以完成，但是还是很复杂的，LinchPin 现在有一个前端命令行用户界面（CLI），它是用 [Click][14] 写的，而且它使 LinchPin 比以前更简化。
探索开源云
没有止步于 CLI，LinchPin 现在还有一个 [Python][15] API，它可以用于管理资源，比如，Amazon EC2 和 OpenStack 实例、网络、存储、安全组等等。这个 API [文档][16] 可以在你想去尝试 LinchPin 的 Python API 时帮助你。
* [云是什么？][1]
### Playbook 是一个库
* [OpenStack 是什么？][2]
* [Kubernetes 是什么？][3]
* [为什么操作系统对容器很重要？][4]
* [保持 Linux 容器的安全][5]
为了不落后于 CLI，LinchPin 现在也有一个 [Python][15] API，它可以被用于管理资源，比如，Amazon EC2 和 OpenStack 实例、网络、存储、安全组、等等。这个 API [文档][16] 可以在你想去尝试 LinchPin 的 Python API 时帮助你。
### Playbooks 作为一个库
因为 LinchPin 的核心 bits 是 [Ansible playbooks][17]、角色、模块、过滤器，以及任何被称为 Ansible 模块的东西都被移进 LinchPin 库中，这意味着我们可以直接调用 playbooks，但它不是资源管理的首选机制。**linchpin** 可执行文件已经成为命令行的事实上的前端。
因为 LinchPin 的核心是 [Ansible playbook][17]，其角色、模块、过滤器，以及任何被称为 Ansible 模块的东西都被移进 LinchPin 库中，这意味着我们虽然可以直接调用 playbook，但它不是资源管理的首选机制。`linchpin` 可执行文件事实上已经成为该命令行的前端。
### 深入了解命令行
让我们深入了解**linchpin**命令行：
让我们深入了解 `linchpin` 命令行：
```
$ linchpin
@ -57,19 +47,19 @@ Commands:
你可以立即看到一个简单的描述，以及命令的选项和参数。这个帮助的最下面的三个命令是本文的重点内容。
### 配置
#### 配置文件
以前，有个名为 **linchpin_config.yml** 的文件。现在这个文件没有了，替换它的是一个 ini 形式的配置文件，称为 **linchpin.conf**。虽然这个文件可以被修改或放到别的地方，它可以放置在配置文件容易找到的库的路径中。在多数情况下，**linchpin.conf** 文件是不需要去修改的。
之前有个名为 `linchpin_config.yml` 的文件。但现在这个文件没有了，替换它的是一个 ini 形式的配置文件，称为 `linchpin.conf`。虽然这个文件可以被修改或放到别的地方，它可以放置在配置文件容易找到的库路径中。在多数情况下，`linchpin.conf` 文件是不需要去修改的。
### 工作空间
#### 工作空间
工作空间是一个定义的文件系统路径，它是一个逻辑上的资源组。一个工作空间可以认为是一个特定环境、服务组、或其它逻辑组的一个单个点。它也可以是一个所有可管理资源的大的存储容器。
<ruby>工作空间<rt>workspace</rt></ruby>是一个定义好的文件系统路径，它是一个逻辑上的资源组。一个工作空间可以认为是一个特定环境、服务组、或其它逻辑组的一个单点。它也可以是一个所有可管理资源的大的存储容器。
工作空间在命令行上使用 **--workspace (-w)** 选项去指定，随后是工作空间路径。它也可以使用环境变量（比如，bash 中的 **$WORKSPACE**）指定。默认工作空间是当前目录。
工作空间可以在命令行上使用 `--workspace` （`-w`） 选项去指定，随后是工作空间路径。它也可以使用环境变量指定（比如，bash 中的 `$WORKSPACE`）。默认工作空间是当前目录。
### 初始化 (init)
#### 初始化 (`linchpin init`)
运行 **linchpin init** 将生成一个需要的目录结构，以及一个 **PinFile**、**topology**、和 **layout** 文件的示例：
运行 `linchpin init` 将生成一个需要的目录结构，以及一个 `PinFile`、`topology`、和 `layout` 文件的示例：
```
$ export WORKSPACE=/tmp/workspace
@ -89,15 +79,15 @@ $ tree
└── example-topology.yml
```
在这个时候，一个可执行的 **linchpin up** 并且提供一个 **libvirt** 虚拟机，和一个名为 **linchpin-centos71** 的网络。一个库存（inventory）将被生成，并被放在 **inventories/libvirt.inventory** 目录中。它可以通过读取 **topologies/example-topology.yml** 和收集 **topology_name** 的值了解它。
在这个时候，可以执行 `linchpin up` ，然后提供一个 `libvirt` 虚拟机，和一个名为 `linchpin-centos71` 的网络。会生成一个<ruby>库存<rt>inventory</rt></ruby>，并放在 `inventories/libvirt.inventory` 目录中。它可以通过读取 `topologies/example-topology.yml` 和 `topology_name` 的值了解它。
### 做好准备 (linchpin up)
#### <ruby>配给<rt>provisioning</rt></ruby> (`linchpin up`)
一旦有了一个 PinFile、拓扑、和一个可选的布局，它已经做好了准备。
一旦有了一个 PinFile、拓扑、和一个可选的布局，就可以<ruby>配给<rt>provisioning</rt></ruby>了。
我们使用 dummy 工具，因为用它去配置非常简单；它不需要任何额外的东西（认证、网络、等等）。dummy 提供创建一个临时文件，它表示配置的主机。如果临时文件没有任何数据，说明主机没有被配置，或者它已经被销毁了。
我们使用 dummy （模拟）工具，因为用它来配给非常简单；它不需要任何额外的东西（认证、网络、等等）。dummy 配给程序会创建一个临时文件，它表示所配给的主机。如果临时文件没有任何数据，说明主机没有被配给，或者它已经被销毁了。
dummy 提供的树像这样：
dummy 配给程序的目录树大致如下：
```
$ tree
@ -112,7 +102,7 @@ $ tree
└── dummy-cluster.yml
```
PinFile 也很简单；它指定了它的拓扑，并且可以为 **dummy1** 目标提供一个可选的布局：
PinFile 也很简单；它指定了它的拓扑，并且为 `dummy1` 目标提供一个可选的布局：
```
---
@ -121,7 +111,7 @@ dummy1:
layout: dummy-layout.yml
```
**dummy-cluster.yml** 拓扑文件是一个引用到提供的三个 **dummy_node** 类型的资源：
`dummy-cluster.yml` 拓扑文件是一个引用，指向到配给的三个 `dummy_node` 类型的资源：
```
---
@ -137,7 +127,7 @@ resource_groups:
count: 3
```
执行命令 **linchpin up** 将基于上面的 **topology_name**（在这个案例中是 **dummy_cluster**）生成 **resources** 和 **inventory** 文件。
执行命令 `linchpin up` 将基于上面的 `topology_name`（在这个案例中是 `dummy_cluster`）生成 `resources` 和 `inventory` 文件。
```
$ linchpin up
@ -147,7 +137,7 @@ $ ls {resources,inventories}/dummy*
inventories/dummy_cluster.inventory resources/dummy_cluster.output
```
去验证 dummy 集群的资源，检查 **/tmp/dummy.hosts**：
要验证 dummy 集群的资源，可以检查 `/tmp/dummy.hosts`：
```
$ cat /tmp/dummy.hosts
@ -156,11 +146,11 @@ web-1.example.net
web-2.example.net
```
Dummy 模块为假定的（或 dummy）供应提供了一个基本工具。OpenStack、AWS EC2、Google Cloud、和更多的关于 LinchPin 的详细情况，可以去看[示例][18]。
Dummy 模块为假定的（或模拟的）配给提供了一个基本工具。关于在 OpenStack、AWS EC2、Google Cloud 上和 LinchPin 的更多详细情况，可以去看[示例][18]。
### 库存（Inventory）生成
#### <ruby>库存<rt>inventory</rt></ruby>生成
作为上面提到的 PinFile 的一部分，可以指定一个 **layout**。如果这个文件被指定，并且放在一个正确的位置上，一个用于提供资源的 Ansible 的静态库存（inventory）文件将被自动生成：
作为上面提到的 PinFile 的一部分，可以指定一个 `layout`。如果这个文件被指定，并且放在一个正确的位置上，就会为配给的资源自动生成一个用于 Ansible 的静态<ruby>库存<rt>inventory</rt></ruby>文件：
```
---
@ -174,7 +164,7 @@ inventory_layout:
- example
```
当 **linchpin up** 运行完成，资源文件将提供一个很有用的详细信息。特别是，插入到静态库存（inventory）的 IP 地址或主机名：
当 `linchpin up` 运行完成，资源文件将提供一个很有用的详细信息。特别是，插入到静态库存的 IP 地址或主机名：
```
[example]
@ -188,13 +178,13 @@ web-1.example.net hostname=web-1.example.net
web-0.example.net hostname=web-0.example.net
```
### 卸载 (linchpin destroy)
#### 卸载 （`linchpin destroy`）
LinchPin 也可以执行一个资源卸载。一个卸载动作一般认为资源是已经配置好的；然而，因为 Ansible 是幂等的（idempotent），**linchpin destroy** 将仅去检查确认资源是启用的。如果这个资源已经是启用的，它将去卸载它。
LinchPin 也可以执行资源卸载。卸载动作一般认为该资源是已经配给好的；然而，因为 Ansible 是<ruby>幂等的<rt>idempotent</rt></ruby>，`linchpin destroy` 将仅检查确认该资源是启用的。如果这个资源已经是启用的，它将去卸载它。
命令 **linchpin destroy** 也将使用资源和/或拓扑文件去决定合适的卸载过程。
命令 `linchpin destroy` 也将使用资源和/或拓扑文件去决定合适的卸载过程。
**dummy** Ansible 角色不使用资源，卸载期间仅有拓扑：
Ansible `dummy` 角色不使用资源，卸载期间仅有拓扑：
```
$ linchpin destroy
@ -204,55 +194,46 @@ $ cat /tmp/dummy.hosts
-- EMPTY FILE --
```
在暂时的资源上，卸载功能有一些限制，像网络、存储、等等。网络资源被用于多个云实例是可能的。在这种情况下，执行一个 **linchpin destroy** 不能卸载某些资源。这取决于每个供应商的实现。查看每个[供应商][19]的具体实现。
针对暂时的资源，卸载功能有一些限制，像网络、存储、等等。网络资源可以被用于多个云实例。在这种情况下，执行一个 `linchpin destroy` 某些资源就不能卸载。这取决于每个供应商的实现。查看每个[供应商][19]的具体实现。
### LinchPin 的 Python API
在 **linchpin** 命令行中实现的功能大多数已经被写成了 Python API。这个 API，虽然不完整，但它已经成为 LinchPin 工具的至关重要的组件。
在 `linchpin` 命令行中实现的功能大多数都是用 Python API 写的。这个 API，虽然不完整，但它已经成为 LinchPin 工具的至关重要的组件。
这个 API 由下面的三个包组成：
* **linchpin**
* **linchpin.cli**
* **linchpin.api**
这个命令行工具是基于 **linchpin** 包来管理的。它导入了 **linchpin.cli** 模块和类，它是 **linchpin.api** 的子类。它的目的是为了允许使用 **linchpin.api** 的 LinchPin 的可能的其它实现，比如像计划的 RESTful API。
* `linchpin`
* `linchpin.cli`
* `linchpin.api`
该命令行工具是基于 `linchpin` 包来管理的。它导入了 `linchpin.cli` 模块和类，该类是 `linchpin.api` 的子类。这样做的目的是为了允许使用 `linchpin.api` 来做其它的 LinchPin 实现，比如像计划中的 RESTful API。
更多信息，去查看 [Python API library documentation on Read the Docs][20]。
### Hooks
### Hook
LinchPin 1.0 的其中一个大的变化是转向 hooks。hooks 的目标是在 **linchpin** 运行期间，允许配置使用外部资源。目前情况如下：
LinchPin 1.0 的其中一个大的变化是转向 hook。hook 的目标是在 `linchpin` 运行期间的特定状态下，允许配置使用更多外部资源。目前的状态有：
* **preup**: 在准备拓扑资源之前运行
* `preup`: 在配给拓扑资源之前运行
* `postup`: 在配给拓扑资源之后运行，并且生成可选的<ruby>库存<rt>inventory</rt></ruby>
* `predestroy`: 卸载拓扑资源之前运行
* `postdestroy`: 卸载拓扑资源之后运行
* **postup**: 在准备拓扑资源之后运行，并且生成可选的库存（inventory）
在每种状态下，这些 hooks 允许运行外部脚本。存在几种类型的 hook，包括一个定制的叫做 _Action Managers_。这是一个内置的 Action Manager 的列表：
* **predestroy**: 卸载拓扑资源之前运行
* `shell`: 允许任何的<ruby>内联<rt>inline</rt></ruby>的 shell 命令，或者一个可运行的 shell 脚本
* `python`: 运行一个 Python 脚本
* `ansible`: 运行一个 Ansible playbook，允许传递一个 `vars_file` 和 `extra_vars` 作为 Python 字典
* `nodejs`: 运行一个 Node.js 脚本
* `ruby`: 运行一个 Ruby 脚本
* **postdestroy**: 卸载拓扑资源之后运行
hook 被绑定到一个特定的目标，并且每个目标使用时必须重新声明。将来，hook 将可能是全局的，然后它们在每个目标的 `hooks` 节下命名会更简单。
在每种情况下，这些 hooks 允许去运行外部脚本。存在几种类型的 hooks，包括一个定制的叫做 _Action Managers_。这是一个内置的动作管理的列表：
#### 使用 hook
* **shell**: 允许任何的内联（inline）shell 命令，或者一个可运行的 shell 脚本
hook 描述起来非常简单，但理解它们强大的功能却并不简单。这个特性的存在是为了给用户灵活提供那些 LinchPin 开发者所没有考虑到的功能。这个概念可能会带来 ping 一套系统的简单方式，举个实例，比如在运行另一个 hook 之前。
* **python**: 运行一个 Python 脚本
* **ansible**: 运行一个 Ansible playbook，允许通过一个 **vars_file** 和 **extra_vars** 表示为一个 Python 字典
* **nodejs**: 运行一个 Node.js 脚本
* **ruby**: 运行一个 Ruby 脚本
一个 hook 是绑定到一个特定的目标，并且每个目标使用时必须重新声明。将来，hooks 将可能是全局的，然后它们在每个目标的 **hooks** 节更简单地进行命名。
### 使用 hooks
描述 hooks 是非常简单的，理解它们强大的功能却并不简单。这个特性的存在是为了给用户提供灵活的功能，而这些功能开发着可能并不会去考虑。对于实例，在运行其它的 hook 之前，这个概念可能会带来一个简单的方式去 ping 一套系统。
更仔细地去研究  _工作空间_ ，你可能会注意到 **hooks** 目录，让我们看一下这个目录的结构：
更仔细地去研究 _工作空间_ ，你可能会注意到 `hooks` 目录，让我们看一下这个目录的结构：
```
$ tree hooks/
@ -266,7 +247,7 @@ hooks/
   └── setup_db.sh
```
在任何情况下，hooks 都可以在 **PinFile** 中使用，展示如下：
在任何情况下，hook 都可以用在 `PinFile` 中，展示如下：
```
---
@ -286,15 +267,15 @@ dummy1:
- init_db.sh
```
那是基本概念，这里有三个 postup 动作去完成。Hooks 是从上到下运行的，因此，Ansible **ping** 任务将首先运行，紧接着是两个 shell 任务， **setup_db.sh** 和 **init_db.sh**。假设 hooks 运行成功。将发生一个系统的 ping，然后，一个数据库被安装和初始化。
基本概念是有三个 postup 动作要完成。Hook 是从上到下运行的，因此，Ansible `ping` 任务将首先运行，紧接着是两个 shell 任务， `setup_db.sh` 和 `init_db.sh`。假设 hook 运行成功。将发生一个系统的 ping，然后，一个数据库被安装和初始化。
### 认证的驱动程序
在 LinchPin 的最初设计中，开发者决定去在 Ansible playbooks 中管理认证；然而，移到更多的 API 和命令行驱动的工具后，意味着认证将被置于 playbooks 库之外，并且还可以根据需要去传递认证值。
在 LinchPin 的最初设计中，开发者决定在 Ansible playbooks 中管理认证；然而，逐渐有更多的 API 和命令行驱动的工具后，意味着认证将被置于 playbooks 库之外，并且还可以根据需要去传递认证值。
### 配置
#### 配置
让用户使用驱动程序提供的认证方法去完成这个任务。对于实例，如果对于 OpenStack 调用的拓扑，标准方法是可以使用一个 yaml 文件，或者类似于 **OS_** 前缀的环境变量。一个 clouds.yaml 文件是一个 profile 文件的组成部分，它有一个 **auth** 节：
让用户使用驱动程序提供的认证方法去完成这个任务。举个实例，如果对于 OpenStack 调用的拓扑，标准方法是使用一个 yaml 文件，或者类似于 `OS_` 前缀的环境变量。`clouds.yaml` 文件是一个 profile 文件的组成部分，它有一个 `auth` 节：
```
clouds:
@ -308,7 +289,7 @@ clouds:
更多详细信息在 [OpenStack documentation][21]。
这个 clouds.yaml 或者在位于 **default_credentials_path** （比如，~/.config/linchpin）中和拓扑中引用的任何其它认证文件：
这个 `clouds.yaml` 或者任何其它认证文件位于 `default_credentials_path` （比如，`~/.config/linchpin`）中，并在拓扑中引用：
```
---
@ -332,11 +313,11 @@ resource_groups:
profile: default
```
**default_credentials_path** 可以通过修改 **linchpin.conf** 被改变。
`default_credentials_path` 可以通过修改 `linchpin.conf` 改变。
拓扑在底部包含一个新的 **credentials** 节。使用 **openstack**、**ec2**、和 **gcloud** 模块，也可以去指定类似的凭据。认证驱动程序将查看给定的  _名为_ **clouds.yaml** 的文件，并搜索名为 **default** 的 _配置_。
拓扑在底部包含一个新的 `credentials` 节。使用 `openstack`、`ec2`、和 `gcloud` 模块，也可以去指定类似的凭据。认证驱动程序将查看给定的名为 `clouds.yaml` 的文件，并搜索名为 `default` 的 _配置_。
假设认证被找到并被加载，准备将正常继续。
假设认证被找到并被加载，配给将正常继续。
### 简化
@ -348,7 +329,7 @@ resource_groups:
在过去的一年里，社区成员已经从 2 位核心开发者增加到大约 10 位贡献者。更多的人持续参与到项目中。如果你对 LinchPin 感兴趣，可以给我们写信、在 GitHub 上提问，加入 IRC，或者给我们发邮件。
_这篇文章是基于 Clint Savage 在 OpenWest 上的演讲 [Introducing LinchPin: Hybrid cloud provisioning using Ansible][7] 整理的。[OpenWest][8] 将在 2017 年 7 月 12-15 日在盐城湖市举行。_
_这篇文章是基于 Clint Savage 在 OpenWest 上的演讲 [Introducing LinchPin: Hybrid cloud provisioning using Ansible][7] 整理的。[OpenWest][8] 将在 2017 年 7 月 12-15 日在盐城湖市举行。_
--------------------------------------------------------------------------------
@ -362,7 +343,7 @@ via: https://opensource.com/article/17/6/linchpin
作者：[Clint Savage][a]
译者：[qhwdw](https://github.com/qhwdw)
校对：[校对者ID](https://github.com/校对者ID)
校对：[wxy](https://github.com/wxy)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出