LinchPin：使用Ansible的简化的云编排工具

最新推荐文章于 2021-10-23 14:53:25 发布

cumo3681

最新推荐文章于 2021-10-23 14:53:25 发布

阅读量239

点赞数

文章标签： python java linux 编程语言大数据

原文链接：https://opensource.com/article/17/6/linchpin

版权

去年底，我的团队宣布了 LinchPin ，这是一种使用Ansible的混合云编排工具。部署云资源从未如此简单或快速。凭借LinchPin背后的Ansible功能以及对简单性的关注，许多云资源可供用户使用。在本文中，我将介绍LinchPin，并查看该项目在过去10个月中如何成熟。

在引入LinchPin时，使用ansible -playbook命令运行LinchPin很复杂。尽管仍然可以实现，但是LinchPin现在具有一个新的前端命令行用户界面（CLI），该界面使用Click编写，使LinchPin变得比以前更加简单。

LinchPin现在不被CLI淘汰，现在还具有Python API，该API可用于管理资源，例如Amazon EC2和OpenStack实例，网络，存储，安全组等。当您尝试使用LinchPin的Python API时，API 文档可能会有所帮助。

剧本作为图书馆

由于LinchPin的核心部分是Ansible手册，因此角色，模块，过滤器以及与调用Ansible模块有关的所有其他事项均已移至LinchPin库中。这意味着，尽管仍然可以直接调用这些剧本，但这不是管理资源的首选机制。 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（-w）选项指定工作空间，然后是工作空间路径。也可以使用环境变量（例如，bash中的$ WORKSPACE ）指定它。默认工作空间是当前目录。

初始化（init）

运行linchpin init将生成所需的目录结构，以及示例PinFile ，拓扑和布局文件：



   
   
    
    
     
     $ 
     
     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并配置一个名为linchpin-centos71的网络的单个libvirt虚拟机。将生成清单，并将其放置在清单/libvirt.inventory中 。可以通过阅读topology / example-topology.yml并收集topology_name值来知道。

置备（固定）

一旦设置了PinFile，拓扑和可选的布局，就可以进行配置。

我们使用虚拟工具，因为它易于配置。它不需要任何额外的东西（身份验证，网络等）。虚拟提供程序将创建一个临时文件，该文件代表已配置的主机。如果临时文件中没有任何数据，则说明尚未配置主机，或者它们最近已被破坏。

虚拟提供者的树很简单：



   
   
    
    
     
     $ 
     
     tree 
     
     

.
     
     

├── hooks
     
     

├── inventories
     
     

├── layouts
     
     

│   └── dummy-layout.yml
     
     

├── PinFile
     
     

├── resources
     
     

└── topologies
     
     

    └── dummy-cluster.yml

PinFile也很简单。它指定用于dummy1目标的拓扑和可选布局：



   
   
    
     
     
     --- 
     
     

dummy1 : 
     
     

  topology 
     
     :  dummy-cluster.yml 
     
     

  layout 
     
     :  dummy-layout.yml

dummy-cluster.yml拓扑文件是对类型为dummy_node的三（3）个资源的引用：



   
   
    
     
     
     --- 
     
     

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 ）生成资源和清单文件：



   
   
    
    
     
     $ linchpin up
     
     

target: dummy1, action: up
     
     


     
     

$ 
     
     ls 
     
     { resources,inventories 
     
     } 
     
     / dummy 
     
     * 
     
     

inventories 
     
     / dummy_cluster.inventory  resources 
     
     / dummy_cluster.output

要验证虚拟集群的资源，请检查/tmp/dummy.hosts ：



   
   
    
    
     
     $ 
     
     cat 
     
     / tmp 
     
     / dummy.hosts
     
     

web- 
     
     0 .example.net
     
     

web- 
     
     1 .example.net
     
     

web- 
     
     2 .example.net

虚拟模块提供了用于伪装（或虚拟）配置的基本工具。在LinchPin 示例中查看有关OpenStack，AWS EC2，Google Cloud等的详细信息。

库存产生

作为上述PinFile的一部分，可以指定布局。如果指定了此文件并将其存在于正确的位置，则将为配置的资源自动生成Ansible静态清单文件：



   
   
    
     
     
     --- 
     
     

inventory_layout : 
     
     

  vars : 
     
     

    hostname 
     
     :  __IP__ 
     
     

  hosts : 
     
     

    example-node : 
     
     

      count 
     
     :  3 
     
     

      host_groups 
     
     :

        - example

完成关键的执行后，资源文件将提供有用的详细信息。具体而言，将IP地址或主机名插入到静态清单中：



   
   
    
     
     
     [ example 
     
     ] 
     
     

web- 
     
     2 .example.net 
     
     hostname =web- 
     
     2 .example.net
     
     

web- 
     
     1 .example.net 
     
     hostname =web- 
     
     1 .example.net
     
     

web- 
     
     0 .example.net 
     
     hostname =web- 
     
     0 .example.net
     
     


     
     


     
     [ all 
     
     ] 
     
     

web- 
     
     2 .example.net 
     
     hostname =web- 
     
     2 .example.net
     
     

web- 
     
     1 .example.net 
     
     hostname =web- 
     
     1 .example.net
     
     

web- 
     
     0 .example.net 
     
     hostname =web- 
     
     0 .example.net

拆解（Linchpin销毁）

LinchPin还可以执行资源拆解。拆除行动通常期望已经配置了资源；但是，由于Ansible是幂等的，因此linchpin 销毁只会检查以确保资源已用完。只有在资源已经用完的情况下，拆卸才会发生。

linchpin destroy命令将使用资源和/或拓扑文件来确定正确的拆卸程序。

虚拟 Ansible角色不使用资源，仅在拆卸期间使用拓扑：



   
   
    
    
     
     $ linchpin destroy
     
     

target: dummy1, action: destroy
     
     


     
     

$ 
     
     cat 
     
     / tmp 
     
     / dummy.hosts
     
     


     
     -- EMPTY FILE 
     
     --

拆解功能在临时资源（如网络，存储等）方面受到了更多限制。网络资源有可能与多个云实例一起使用。这样，执行关键销毁不会破坏某些资源。这取决于每个提供程序的实现。请参阅每个提供程序的特定实现。

LinchPin Python API

linchpin命令行工具中实现的大部分内容都是使用Python API编写的。该API尽管不完整，但已成为LinchPin工具的重要组成部分。

该API包含三个软件包：

关键
linchpin.cli
linchpin.api

命令行工具在基本的linchpin软件包中进行管理。它导入linchpin.cli模块和类，这是linchpin.api的子类。这样做的目的是使用linchpin.api，像计划的RESTful API，允许对关键的其他可能的实现。

有关更多信息，请参阅阅读文档上的Python API库文档。

钩子

LinchPin 1.0的重大改进之一是钩子。带钩子的目标是允许在关键执行期间使用处于特定特定状态的外部资源进行其他配置。当前的状态如下：

preup ：在配置拓扑资源之前执行
postup ：在供应拓扑资源并生成可选清单后执行
predestroy ：在拆除拓扑资源之前执行
postdestroy ：拆除拓扑资源后执行

在每种情况下，这些挂钩都允许运行外部脚本。存在几种类型的挂钩，包括称为Action Managers的自定义挂钩。以下是内置动作管理器的列表：

shell ：允许嵌入式shell命令或可执行的shell脚本
python ：执行一个Python脚本
ansible ：执行Ansible剧本，允许传递以python dict表示的vars_file和extra_vars
nodejs ：执行Node.js脚本
ruby ：执行一个Ruby脚本

挂钩绑定到特定目标，并且必须为每个使用的目标重新定义。将来，钩子将成为全局钩子，然后在钩子部分为每个目标更简单地命名。

使用挂钩

描述钩子很简单，了解钩子的功能可能不是那么简单。存在此功能可以为LinchPin开发人员可能不会考虑的事情向用户提供灵活的功能。例如，在运行另一个挂钩之前，此概念可能会导致一种简单的方法来对一组系统执行ping操作。

仔细观察工作空间 ，可能已经注意到了hooks目录。让我们看一下该目录以查看结构：



   
   
    
    
     
     $ 
     
     tree hooks 
     
     / 
     
     

hooks 
     
     / 
     
     

├── ansible
     
     

│   ├── 
     
     ping 
     
     

│   │   └── dummy_ping.yaml
     
     

└── shell
     
     

    └── database
     
     

        ├── init_db.sh
     
     

        └── setup_db.sh

在每种情况下，都可以在PinFile中使用钩子，如下所示：



   
   
    
     
     
     --- 
     
     

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

基本概念是要完成三个发布操作。挂钩按自上而下的顺序执行。因此，Ansible ping任务将首先运行，然后是两个Shell任务setup_db.sh ，然后是init_db.sh 。假设挂钩成功执行，将对系统执行ping操作，然后将建立并初始化数据库。

验证驱动

在LinchPin的最初设计中，开发人员决定在Ansible剧本中管理身份验证。但是，转而使用更多的API和命令行驱动的工具意味着，身份验证应该在剧本现在所在的库的外部，并且仍根据需要传递身份验证值。

组态

让用户使用所用驱动程序提供的身份验证方法可以完成此任务。例如，如果拓扑要求使用OpenStack，则标准方法是使用yaml文件或类似的OS_前缀环境变量。一个clouds.yaml文件由一个配置文件和一个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文档。

这个clouds.yaml或任何其他身份验证文件位于default_credentials_path （例如〜/ .config / linchpin）中，并在拓扑中引用：



   
   
    
     
     
     --- 
     
     

topology_name 
     
     :  openstack-test 
     
     

resource_groups 
     
     :

  - 
     
     

    resource_group_name 
     
     :  linchpin 
     
     

    resource_group_type 
     
     :  openstack 
     
     

    resource_definitions : 
     
     

      - name 
     
     :  resource 
     
     

        type 
     
     :  os_server 
     
     

        flavor 
     
     :  m1.small 
     
     

        image 
     
     :  rhel-7.2-server-x86_64-released 
     
     

        count 
     
     :  1 
     
     

        keypair 
     
     :  test-key 
     
     

        networks 
     
     :

          - test-net2 
     
     

        fip_pool 
     
     :  10.0.72.0/24 
     
     

    credentials : 
     
     

      filename 
     
     :  clouds.yaml 
     
     

      profile 
     
     :  default

可以通过修改linchpin.conf来更改default_credentials_path 。

拓扑在底部包括一个新的凭据部分。使用openstack ， ec2和gcloud模块，可以类似地指定凭据。然后，身份验证驱动程序将查找给定的文件名 clouds.yaml ，并搜索名为default的配置文件 。

假设找到并加载了身份验证，设置将照常继续。

简单

尽管LinchPin在拓扑，清单布局，挂钩和身份验证管理方面可能很复杂，但最终目标是简化。通过使用命令行界面进行简化，以及改善1.0版以后的开发人员体验的目标，LinchPin继续表明可以通过简单的方式管理复杂的配置。

社区成长

在过去的一年中，LinchPin的社区已经发展到现在拥有一个邮件列表，一个IRC频道（在chat.freenode.net上为#linchpin），甚至可以通过GitHub公开管理我们的sprint。

社区成员的数量已大大增加，在过去的一年中，社区成员从2位核心开发人员增加到大约10位贡献者。更多的人继续从事该项目。如果您对LinchPin感兴趣，请给我们留言，在GitHub上提交问题，加入IRC或向我们发送电子邮件。

本文基于Clint Savage的OpenWest演讲“ LinchPin简介：使用Ansible进行混合云配置” 。 OpenWest将于2017年7月12日至15日在犹他州盐湖城举行。

翻译自: https://opensource.com/article/17/6/linchpin

cumo3681

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
LinchPin：使用Ansible的简化的云编排工具

去年底，我的团队宣布了 LinchPin ，这是一种使用Ansible的混合云编排工具。部署云资源从未如此简单或快速。凭借LinchPin背后的Ansible功能以及对简单性的关注，许多云资源可供用户使用。在本文中，我将介绍LinchPin，并查看该项目在过去10个月中如何成熟。在引入LinchPin时，使用ansible -playbook命令运行LinchPin很复杂。尽管...
复制链接

扫一扫