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 命令的資料.因為這個原因,下面提供自動伸縮解決方案更好一些.

閱讀 Ansible-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 模組可以應用於雲構造模板.

當使用Ansible配合雲構造的時候,Ansible通常使用一個工具像 Packer 來構建映象,CloudFormation 執行這些映象, 或者通過使用者資料,一旦映象上線,ansible會被激發.(When using Ansible with CloudFormation, typically Ansible will be used with a tool like Packer to build images, and CloudFormation will launch those images, or ansible will be invoked through user data once the image comes online, or a combination of the two.)

請閱讀ansible雲構造的例子獲取更多的細節.

使用Ansible 構造AWS映象

Many users may want to have images boot to a more complete configuration rather than configuring them entirely after instantiation. To do this, one of many programs can be used with Ansible playbooks to define and upload a base image, which will then get its own AMI ID for usage with the ec2 module or other Ansible AWS modules such as ec2_asg or the cloudformation module. Possible tools include Packer, aminator, and Ansible’s ec2_ami module.

許多使用者想去開機啟動更完整的配置而不是安裝之後配置.為了這樣做,許多程式可以用於ansible playbook定義和上傳基本的映象,這讓他們使用 ec2 模組後得到自己的AMI ID,或者其它的Ansible AWS模組例如ec2_asg 或者cloudformation 模組.可能的工具包含 Packer,aminator,和Ansible’s ec2_ami 模組

總的來說,我們發現許多使用者使用Packer

Ansible Packer的文件可以在這裡找到 https://www.packer.io/docs/provisioners/ansible-local.html.

如果你想採用Packer這時,配置一個基本的映象使用Ansible在規則之後是可以接受的.

下一步:探索模組

Ansible附帶許多模組來配置許多EC2服務.瀏覽 模組的 “Cloud” 目錄檢視完整的列表

See also

模組相關
All the documentation for Ansible modules
Playbooks
An introduction to playbooks
委託,滾動更新,本地動作
Delegation, useful for working with loud balancers, clouds, and locally executed steps.
User Mailing List
Have a question? Stop by the google group!
irc.freenode.net
#ansible IRC chat channel