Amazon Web Services Guide

简介

Ansible包含了大量的控制Amazon web service(AWS)模块.这个章节的目的是为了说明如何在AWS环境下组合ansible的模块使用ansible(The purpose of this section is to explain how to put Ansible modules together (and use inventory scripts) to use Ansible in AWS context)

AWS模块的需求(requiement)是很少的

所有需要的模块以及被最近的 boto 版本测试过了.你需要这个模块安装在你的控制机器上面.boto 可以从linux发行版或者使用python的pip安装

然而典型的ansible执行任务,对多个主机进行循环(Whereas classically ansible will execute tasks in its host loop against multiple remote machines),大部分的云控制步骤发生在你的本地机器所关联的区域

在你的 playbook 步骤里,我们会使用下面的样式演示步骤:

- hosts: localhost connection: local gather_facts: False tasks: - ...

认证

AWS 认证相关的模块通过指定访问密钥作为 ENV 的变量或者模块参数.

对于环境变量:

export AWS_ACCESS_KEY_ID='AK123' export AWS_SECRET_ACCESS_KEY='abc123'

存储变量在一个 vars_file ,最好使用ansible-vault:

--- ec2_access_key: "--REMOVED--" ec2_secret_key: "--REMOVED--"

供给(Provisioning)

在EC2中提供和取消实例的ec2模块

一个确保只有5个实例标签为“Demo”的例子

在下面的例子里,”exact_count”实例被设置为了5,这意味着如果0个实例存在,将会创建5个.如果两个实例创建,将会创建三个,如果8个实例存在,将会终止3个.

指定”count_tag”参数的将被计数, “instance_tags” 参数用于给新创建的实例应用标签:

# demo_setup.yml - hosts: localhost connection: local gather_facts: False tasks: - name: Provision a set of instances ec2: key_name: my_key group: test instance_type: t2.micro image: "{{ ami_id }}" wait: true exact_count: 5 count_tag: Name: Demo instance_tags: Name: Demo register: ec2

有关实例被常见的数据被保存在通过 “register” 关键字设置的”ec2”变量

我们将会使用 add_host 模块动态的创建主机组组成新的实例.这将会在后来的任务里面立即执行这些配置文件:

# demo_setup.yml - hosts: localhost connection: local gather_facts: False tasks: - name: Provision a set of instances ec2: key_name: my_key group: test instance_type: t2.micro image: "{{ ami_id }}" wait: true exact_count: 5 count_tag: Name: Demo instance_tags: Name: Demo register: ec2 - name: Add all instance public IPs to host group add_host: hostname={{ item.public_ip }} groups=ec2hosts with_items: ec2.instances

在主机组添加之后,规则剧本底部的第二个演出将会开始一些配置步骤:

# demo_setup.yml - name: Provision a set of instances hosts: localhost # ... AS ABOVE ... - hosts: ec2hosts name: configuration play user: ec2-user gather_facts: true tasks: - name: Check NTP service service: name=ntpd state=started

主机清单

一旦你的节点开始运转起来了,你可能想去和它们通信.在云的配置下,最好不要维护静态的云主机名.最好的方式是使用ec2动态清单脚本来处理.

这将会动态的挑选节点甚至不是由Ansible创建的,同样允许Ansible管理它们.

阅读 doc:aws_example 查看如何使用,然后继续回到这个章节.

标签,组和变量

当使用ec2清单脚本的时候,主机基于它们如何在EC2里面的标签动态的出现在组里面

例如,如果一个主机给了 “class” 标签,同时给它”webserver”作为值,它会自动被动态组发现,就像这样:

- hosts: tag_class_webserver tasks: - ping

这是很好的根据他们的性能划分系统的方式.

在这个例子里,如果我们想去定义自动应用每台机器上面的变量,同时 “webserver” 带有标签 “class” , 在ansible里面可以使用的”group_vars”, 阅读:ref:splitting_out_vars.

对于区域和其它分类,相似的组是可用的,可以使用同一种机制分配相似的变量.(Similar groups are available for regions and other classifications, and can be similarly assigned variables using the same mechanism.)

使用Ansible Pull自动伸缩

Amazon有基于负载自动的增加和减少容量的特性. 在 cloud 文档里,也有一些 Ansible 模块可以配置自动伸缩策略.

当节点在线的时候,可能没有足够的时间等待下一个周期来临,让ansible命令配置那个节点.

为了这么做,(To do this, pre-bake machine images which contain the necessary ansible-pull invocation.).Ansible-pull 是从git服务器上面抓取playbook在本地运行的一个命令行工具.

这种方式的一个挑战在于在自动伸缩的环境里面需要一个中心化的方式存取 pull 命令的数据.因为这个原因,下面提供自动伸缩解决方案更好一些.

阅读 在pull-node playbook 获取更多的信息

使用Asnible Tower自动伸缩

Ansible Tower 同样包含了一个非常好的特性来自动伸缩.在这种方式下,简单的curl脚本可以调用定义的URL,服务器也会对请求”dial out”和配置正在运行的实例.这是一个很好的方式重新配置生存周期短暂的节点.阅读Tower安装和产品文档获取更多的信息.

在Tower使用回收机制有个好处是,任务结果仍然是中心化的,但是和远程主机分享更少的信息(A benefit of using the callback in Tower over pull mode is that job results are still centrally recorded and less information has to be shared with remote hosts.)

Ansible云构造

云构造是一个Amazon的技术,让云栈作为JSON文档

Ansible摸块提供了一个比云构造更容易的接口,不需要定义复杂的JSON文档.这是推荐用户使用的.

然而,当用户决定使用云构造,也有 Ansible 模块可以应用于云构造模板.