动态 Inventory

    Ansible 本身通过基于文本的方式来记录 inventory 配置信息,这在前面已介绍过（详见 Inventory文件 ）.

    除此之外,Ansible 也支持用其他方式保存配置信息.

    在其他软件系统保存配置信息的例子有:

    对于这些需求,Ansible 可通过一个外部 inventory 系统来支持.在 ansible 的 “/plugins” 插件目录下已经含有一些选项 – 包括 EC2/Eucalyptus, Rackspace Cloud,and OpenStack,我们稍后会详细介绍它们.

    Ansible 提供了一个数据库来存储 inventory 配置信息, 这个数据库可以通过 web 访问,或通过 REST 访问.Tower 与所有你使用的 Ansible 动态 inventory 源保持同步,并提供了一个图形化的 inventory 编辑器.有了这个数据库,便可以很容易的关联过去的事件历史,可以看到在上一次 playbook 运行时,哪里出现了运行失败的情况.

    关于如何编写你自己的动态 inventory 源,请参见 开发动态的Inventory数据源.

    当管理的物理机器到达了一定数量的时,很多使用 Ansible 的用户可能同时也会使用到 .（注: Cobbler 最初由 Michael DeHaan 编写,现在项目主导人是 James Cammarata, 他目前在 Ansible 公司工作）.

    Cobbler 主要用于操作系统的 kickoff 安装,以及管理 DHCP 和 DNS,除此之外,它有一个通用层,可为多种配置管理系统（甚至是同时的）提供数据.所以 Cobbler 也被一些管理员称为是轻量级的 CMDB.

    如何将 Ansible 的 inventory 与 Cobbler 联系起来呢？方法是:将脚本 script 拷贝到 /etc/ansible,通过 chmod +x 赋予可执行权限.

    在使用 Ansible 之前,先启动 cobblerd 进程.

    现在使用 Ansible 要加上 选项 （ 例如:-i /etc/ansible/cobbler.py）.cobbler.py这个脚本使用 Cobbler 的 XMLRPC API 与 Cobbler 通信.

    执行脚本 /etc/ansible/cobbler.py ,应该能看到一些 JSON 格式的数据输出（也许还没有具体的内容）.

    在 cobbler 中,假设有一个如下的场景:

    1. cobbler profile add --name=webserver --distro=CentOS6-x86_64
    2. cobbler profile edit --name=webserver --mgmt-classes="webserver" --ksmeta="a=2 b=3"
    3. cobbler system edit --name=foo --dns-name="foo.example.com" --mgmt-classes="atlanta" --ksmeta="c=4"
    4. cobbler system edit --name=bar --dns-name="bar.example.com" --mgmt-classes="atlanta" --ksmeta="c=5"

    ‘foo.example.com’ 是一个域名,Ansible 可以通过这个域名寻址找到对应的主机foo,对其进行操作.也可以通过组名 ‘webserver’ 或者 ‘atlanta’ 寻址找到这个主机,只要这个主机是属于这两个组的.直接使用 foo 是不行的.例如执行命令 “ansible foo” ,无法找到该主机,但使用 “ansible ‘foo*’” 却可以,因为域名 ‘foo.example.com’ 以foo开头.

    1. # file: /srv/motd.j2
    2. Welcome, I am templated with a value of a={{ a }}, b={{ b }}, and c={{ c }}

    模板的使用如下:

    1. ansible webserver -m setup
    2. ansible webserver -m template -a "src=/tmp/motd.j2 dest=/etc/motd"

    Note

    组名 ‘webserver’ 是 cobbler 中定义的.你仍然可以在 Ansible 的配置文件中定义变量.但要注意,变量名相同时,外部 inventory 脚本中定义的变量会覆盖 Ansible 中的变量.

    执行上面命令后,主机 foo 的/etc/motd文件被写入如下的内容:

    主机 ‘bar’ (bar.example.com)的 /etc/motd 中写入如下内容:

    1. Welcome, I am templated with a value of a=2, b=3, and c=5

    你也可以通过下面这个命令测试变量的替换:

    1. ansible webserver -m shell -a "echo {{ a }}"

    也就是说,你可以在参数或命令操作中使用变量的替换.

    使用 AWC EC2时,维护一份 inventory 文件有时不是最好的方法.因为主机的数量有可能发生变动,或者主机是由外部的应用管理的,或者使用了 AWS autoscaling.这时,使用 脚本是更好的选择.

    脚本的使用方式有两种,最简单的是直接使用 Ansible 的命令行选项 -i ,指定脚本的路径（脚本要有可执行权限）:

    1. ansible -i ec2.py -u ubuntu us-east-1d -m ping

    第二种方式,把脚本拷贝为 /etc/ansible/hosts ,并赋予可执行权限.还需把 ec2.ini 文件拷贝到 /etc/ansible/ec2.ini,然后运行 ansible.

    要成功的调用 API 访问 AWS,需要配置 Boto （Boto 是 AWS 的 Python 接口）.可用的方法有多种,请参见: .

    最简单的方法是定义两个环境变量:

    如何知道配置是否正确,执行脚本来测试:

    1. cd plugins/inventory
    2. ./ec2.py --list

    你可以看到以 JSON 格式表示的覆盖所有 regions 的 inventory 信息.

    inventory 文件的核心部分,是一些名字到目的地址的映射.默认的 ec2.ini 设置适用于在 EC2 之外运行 Ansible（比如一台笔记本电脑）,但这不是最有效的方式.

    在 EC2 内部运行 Ansible 时,内部的 DNS 名和 IP 地址比公共 DNS 名更容易理解.你可以在 ec2.ini 文件中修改 destinationvariable 变量,改为一个实例的私有 DNS 名.对于在私有子网的 VPC 上运行 Ansible ,这种设置很重要,使得我们可以使用内部IP地址之外的方式访问到一个VPC.在 ec2.ini 文件中,_vpc_destination_variable 可以命名为任意一个 boto.ec2.instance 变量.

    EC2 外部 inventory 提供了一种从多个组到实例的映射:

    全局实例都属于 这个组.

    • 实例ID
    • 例如:i-00112233i-a1b1c1d1
    • Region
    • 属于一个 AWS region 的所有实例构成的一个组.例如:us-east-1us-west-2
    • 可用性区域
    • 所有属于 availability zone 的实例构成一个组.例如:us-east-1aus-east-1b
    • 实例可属于一个或多个安全组.每一个组的前缀都是 securitygroup ,符号(-) 已被转换为(_). with all characters except alphanumerics (这句没明白)

    例如:security_group_defaultsecurity_group_webservers

    • 标签
    • 每一个实例可有多个不同的 key/value 键值对,这些键值对被称为标签.标签名可以随意定义,最常见的标签是 ‘Name’.每一个键值对是这个实例自己的组.特殊字符已转换为下划线,格式为 tag_KEY_VALUE例如:tag_Name_Webtag_Name_redis-master-001tag_aws_cloudformation_logical-id_WebServerGroup

    使用 Ansible 与指定的服务器进行交互时,EC2 inventory 脚本被再次调用（调用时加上了命令行选项 —host HOST ）,这个调用会在索引缓存中进行查找,获取实例 ID,然后调用 API 访问 AWS,获取指定实例的所有信息.这些信息被转换为 playbooks 中的变量,可以进行访问.每一个变量的前缀为 ec2_,下面是一些变量的示例:

    • ec2_architecture
    • ec2_description
    • ec2_dns_name
    • ec2_id
    • ec2_image_id
    • ec2_instance_type
    • ec2_ip_address
    • ec2_kernel
    • ec2_key_name
    • ec2_launch_time
    • ec2_monitored
    • ec2_ownerId
    • ec2_placement
    • ec2_platform
    • ec2_previous_state
    • ec2_private_dns_name
    • ec2_private_ip_address
    • ec2_public_dns_name
    • ec2_ramdisk
    • ec2_region
    • ec2_root_device_name
    • ec2_root_device_type
    • ec2_security_group_names
    • ec2_spot_instance_request_id
    • ec2_state
    • ec2_state_code
    • ec2_state_reason
    • ec2_status
    • ec2_subnet_id
    • ec2_tag_Name
    • ec2_tenancy
    • ec2_virtualization_type
    • ec2_vpc_id

    其中 ec2_security_group_ids 和 ec2_security_group_names 变量的值为所有安全组的列表,使用逗号分隔.每一个 EC2 标签是一个格式为 ec2_tag_KEY 的变量.

    要查看一个实例的完整的可用变量的列表,执行脚本:

    1. cd plugins/inventory
    2. ./ec2.py --host ec2-12-12-12-12.compute-1.amazonaws.com

    注意,AWS inventory 脚本会将结果进行缓存,以避免重复的 API 调用,这个缓存的设置可在 ec2.ini 文件中配置.要显式地清空缓存,你可以加上 选项,执行脚本如下:

    1. # ./ec2.py --refresh-cache

    除了 Cobbler 和 EC2 之外,还有以下的系统可以使用 inventory 脚本:

    关于这些系统还没有专门的章节讲述如何操作,但步骤与上面所讲述的 AWS 一样,具体可看看Ansible checkout 的 “plugins/” 目录.

    如果你开发了一个通用的 inventory 脚本,请提交一个 pull request,我们可能会把它放入项目中.

    如果 -i 选项后给出的地址是一个目录 （or as so configured in ansible.cfg）,Ansible 可以同一时间使用多个 inventory 源.这样在同一个 ansible 运行操作中,可混合的使用动态和静态的 inventory 源.

    在静态 inventory 文件中,如果定义一个由一些组作为子成员的组,这些子组也需要定义（译者注:即包含具体的 host）,否则执行时 ansible 会返回一个错误.如果定义一些动态组作为一个静态组的子组,也需在静态 inventory 文件中定义动态组,但是动态组定义为一个空的组即可:

    1. [tag_Name_staging_foo]
    2.  
    3. [tag_Name_staging_bar]
    4.  
    5. [staging:children]
    6. tag_Name_staging_foo
    7. tag_Name_staging_bar
    • All about static inventory files
    • Mailing List
    • Questions? Help? Ideas? Stop by the list on Google Groups

    • ansible IRC chat channel