转发层规范

转发层(composition layer)模块实际上是对第二部分所介绍的模块的调用。 官方社区曾经有一个转发层模块称为puppet-openstack,在Juno版本时被标记为弃用。 为什么社区不推荐转发层模块呢?因为这玩意和自家业务结合得非常紧密。比如,Fuel有自己的转发层模块cluster,ctask有自己的转发层sunfire。

那么关于它的最佳实践是什么?

2016年1月份,我们刚完成了对转发层sunfire的重构,甩掉了许多的历史包袱。关于转发层,我们有以下几点原则需要严格遵守:

逻辑清晰

概括来讲就是在转发层中,不允许出现对resource的直接调用,所有转发层的类抑或定义,只能直接调用基础模块,Openstack模块中的类或定义。

打个不是非常恰当的比方:

class sunfire::api(){
  # 这块代码就应该被移除,使用include ::nova::client来替换
  package {'python-novaclient':
    ensure => present,
  }
  include ::nova
  include ::nova::api
}

数据和逻辑分离

我们在早期使用Puppet时并没有使用到Hiera,因此转发层承载了大量参数的默认值设置。这样做的好处是,我们需要使用到的参数都赋有一个合理默认值,但是坏处是数据和逻辑没有完全分离开。 比如说,我想查询一下目前线上集群$keystone_user_password的值,可能是在转发层的代码中,也可能是记录在hieradata中。另外一个不好的地方就是代码会变得非常冗余。

打个比方:

  class sunfire::api(
    $nova_db_password = 'nova',     #先定义一个参数
  ){
   class {'nova::db::mysql':
     db_password => $nova_db_password, #把该参数值传给真正需要赋值的参数
   }
  }

完全分离的写法:

  class sunfire::api(){
   include ::nova::db::mysql
  }

角色松耦合

我们习惯把转发层中的每个class称之为角色,这样比较形象,例如:

  • sunfire::api 表示API节点
  • sunfire::mq 表示MQ节点
  • sunfire::loadbalancer::l7 表示7层负载均衡

那么API角色中,又包含了nova/cinder/neutron/glance/... api,keystone等大量的服务。同时我们又要满足某些情况下,某些服务不启用的需求。例如,某用户表示,他们不需要使用neutron server而启用nova-network。 有两种方式来满足这种要求:

  • 在sunfire::api添加开关:

    class sunfire::api(
      $enable_neutron = true,
    ){
      if $enable_neutron {
        include ::neutron::server
      }
    }
    
  • 在main manifests文件中声明:

    'xxx api node' {
    include ::neutron::server
    }