如無書面授權，請勿轉載
第四章 大型項目中Ansible的使用
New features in 1.3
There are two features in Ansible 1.3 that were alluded to previously in the chapter.
The first feature is the metadata roles. They allow you to specify that your role
depends on other roles. For example, if the application that you are deploying needs
to send mail, your role could depend on a Postfix role. This would mean that
before the application is set up and installed, Postfix will be installed and set up.
The meta/main.yml file would look similar to the following code:
---
allow_duplicates: no
dependencies:
- apache
The allow_duplicates line is set to no , which is the default. If you set this to no ,
Ansible will not run a role the second time, if it is included twice with the same
arguments. If you set it to yes , it will repeat the role even if it has run before. You can
leave it off instead of setting it to no .
Dependencies are specified in the same format as roles. This means, you can pass
variables here; either static values or variables that are passed to the current role.
The second feature included with Ansible 1.3 is variable default values. If you place
a main.yml file in the defaults directory for the role, these variables will be read into
the role; however they can be overridden by variables in the vars/main.yml file, or
the variables that are passed to the role when it is included. This allows you to make
passing variables to the role optional. These files look exactly like other variable
files. For example, if you used a variable named port in your role, and you wanted
to default it to port 80 , your defaults/main.yml file would look similar to the
following code:
---
port: 80
1.3版本中的新特性
第一個特性是Metadata角色，它可以讓我們指定一個角色依賴另外一個角色。比如，如果你現在部署的應用程式需要使用sendmail服務，那麼你的角色可能要以來postfix角色。你需要在部署應用程式之前先安裝和配置postfix。下面是代碼:
---
allow_duplicates: no
dependencies:
- apache
allow_duplicates的預設值是no，如果設定成no，表示他不會在角色中運作的次數不會超過1次，如果是yes則會在運作過一次之後重複運作，你可以不設定這個關鍵字，那麼它的預設值是no。
在角色中指定依賴關系也一樣，你可以傳遞變量、靜态值、動态的值給現在的角色。
第二個特性是變量可以有預設值，如果你把main.yml檔案放到defult目錄下面，那麼變量會傳遞給角色，但是它們會被／vars/main.yml檔案覆寫，還可以傳遞到包含他們的角色，這意味着你可以傳遞可選的變量到角色裡面。這些檔案和其他變量檔案類似，比如你使用一個包含port變量的角色，你希望它的預設值是80，那麼你的／defaults/main.yml檔案應該像下面的代碼這樣：
---
port: 80
Speeding things up
As you add more and more machines and services to your Ansible configuration,
you will find things getting slower and slower. Fortunately, there are several tricks
you can use to make Ansible work on a bigger scale.
Tags
Ansible tags are features that allow you to select which parts of a playbook you need
to run, and which should be skipped. While Ansible modules are idempotent and
will automatically skip if there are no changes, this often requires a connection to the
remote hosts. The yum module is often quite slow in determining if a module is the
latest, as it will need to refresh all the repositories.
If you know you don't need certain actions to be run, you can select only run
modules that have been tagged with a particular tag. This doesn't even try to run the
module, it simply skips over it. This will save time on almost all the modules even if
there is nothing to be done.
Let's say you have a machine which has a large number of shell accounts, but also
several services set up to run on it. Now, imagine that a single user's SSH key has
been compromised and needs to be removed immediately. Instead of running the
entire playbook, or rewriting the playbooks to only include the steps necessary to
remove that key, you could simply run the existing playbooks with the SSH keys
tag, and it would only run the steps necessary to copy out the new keys, instantly
skipping anything else.
This is particularly useful if you have a playbook with playbook includes in it that
covers your whole infrastructure. With this setup, you can quickly deploy security
patches, change passwords, and revoke keys across your entire infrastructure as
quickly as possible.
Tagging tasks is really easy; simply add a key named tag , and set its value to a list of
the tags you want to give it. The following code shows us how to do this:
給paly加速
當你的Ansible配置中的機器和服務越來越多，你會發現運作速度會變得越來越慢。幸運的是，這有幾個技巧可以讓我們改善性能。
Tags
tags标記可以讓你選擇運作playbook中哪些部分，跳過哪些。While Ansible modules are idempotent and will automatically skip if there are no changes, this often requires a connection to the remote hosts.如果yum子產品制定lastest的話通常運作很慢，因為他要重新整理所有資料庫repositories.
如果你可以确定那些操作不是必須的，你可以标記那些你希望運作的子產品。沒有被标記的會被跳過，而這可以節約大量時間。
假設你有一台機器上面有很多的shell使用者，還運作了很多服務。如果有一個使用者的 ssh key有點弱，需要馬上被移除。比起運作整個play，或者重新寫一個編寫一個playbook，對現存的playbook對相應的ssh key的操作打個tags标記顯然更加有效率，這樣你隻需要執行必要的步驟來複制新的密鑰，跳過其他的步驟。當你的劇本包含所有機器的設施的時候很有用，讓你可以快速對所有裝置部署安全更新、更改密碼、撤銷密鑰。
使用tag非常簡單，隻需要添加tag關鍵字，然後設定你希望的值，下面是示例代碼：
這個play定義了patch , deploy , config這些标記，你自定義執行你希望的标記選項，隻需要簡單的提供标記參數就可以了。
如果你不在指令行裡運作，預設是執行所有的操作。比如你想運作标記deploy，在指令行中輸入以下指令：
$ ansible-playbook webservers.yml --tags deploy
除了離散的任務，角色也可以使用tags，在指令行中，Ansible可以選擇打了标記的角色來運作，操作方式跟任務差不多，代碼如下：
---
- hosts: website1
roles:
- common
- { role: apache, tags: ["patch"] }
- { role: website2, tags: ["deploy", "patch"] }
common角色中沒有打任何标記，當其他标記被應用的時候common角色不會被運作；如果path标記被應用，那麼apache和website2角色會被執行，common不會；如果deploy标記，則隻有website2角色會被執行。
這樣在部署或者打更新檔的時候，通過使用标記來選擇我們制定的角色，我們可以大大縮短play的運作時間。
Ansible's pull mode
Ansible includes a pull mode which can drastically improve the scalability of your
playbooks. So far we have only covered using Ansible to configure another machine
over SSH. This is a contrast to Ansible's pull mode, which runs on the host that you
wish to configure. Since ansible-pull runs on the machine that it is configuring,
it doesn't need to make connections to other machines and runs much faster. In this
mode, you provide your configuration in a git repository which Ansible downloads
and uses to configure your machine.
You should use Ansible's pull mode in the following situations:
• Your node might not be available when configuring them, such as members
of auto-scaling server farms
• You have a large amount of machines to configure and even with large
values of forks , it would take a long time to configure them all
• You want machines to update their configuration automatically when the
repository changes
• You want to run Ansible on a machine that may not have network access yet,
such as in a kick start post install
However, pull mode does have the following disadvantages that make it unsuitable
for certain circumstances:
• To connect to other machines and gather variables, or copy a file you need to
have credentials on the managed nodes
• You need to co-ordinate the running of the playbook across a server farm; for
example, if you could only take three servers offline at a time
• The servers are behind strict firewalls that don't allow incoming SSH
connections from the nodes you use to configure them for Ansible
Ansible的pull模式
Ansible有一個pull（push 推送是它的反義詞）可以大大提高你playbooks的伸縮性。目前為止，我們都是使用Ansible通過ssh來配置另外一台機器，這跟pull模式剛好相反，pull模式在被配置的機器上運作，速度很快。在這種模式下，你需要提供一個git資料來供Ansible下載下傳來配置你的機器。
在以下場景你可以使用pull模式：
- 你的節點在你配置的時候還不可用，比如自動伸縮的服務池
- 你有數量巨大的機器需要配置，即使使用非常高的線程還是要花費很多時間
- 你要在一個沒有網絡連接配接的機器上運作Anisble，比如在啟動之後安裝
以下的場景不适合pull模式
- 需要連接配接到其他機器來收集變量，或則在控制主機上複制檔案時需要憑證
- 你的playbook需要跨越所有裝置，比如在同一時間你隻能有3台伺服器離線
- 你配置Ansible的機器所在的網絡不允許穿透ssh協定
Pull mode doesn't require anything special in your playbooks, but it does require
some setup on the nodes you want configured. In some circumstances, you could do
this using Ansible's normal push mode. Here is a small play to setup play mode on a
machine:
pull模式不需要在playbooks做任何特殊的設定，但是它需要在你配置的機器上做一些設定。有時候，你可以使用普通的推送模式，下面是一個小的play用來在機器上設定play模式：
In this example, we performed the following steps:
• First, we( )installed and set up EPEL. This is a repository with extra software
for CentOS. Ansible is available in the EPEL repository.
• Next, we installed Ansible, making sure to enable the EPEL repository.
• Then, we created a directory for Ansible's pull mode to put the playbooks in.
Keeping these files around means you don't need to download the whole git
repository the whole time; only updates are required.
• Finally, we set up a cron job that will try to run the ansible-pull mode
config every five minutes.
在這個例子中，執行的步驟如下：
- 設定RPEL，他是centos系列作業系統的軟體資料庫
- 确認啟用了EPEL 資料庫，并安裝Ansible
- 為Ansible建立一個目錄用來存放playbooks，儲存這些檔案可以讓你隻在需要的時候更新git資料庫，而不是每次都下載下傳所有的資料庫
- 最後我們添加了一個新的cron任務來運作ansible-pull模式，每5分鐘運作一次
The preceding code downloads the repository off an internal HTTPS
git server. If you want to download the repository instead of SSH, you
will need to add a step to install SSH keys, or generate keys and copy
them to the git machine.
注意：上述代碼從一個内部的https git伺服器中下載下傳資料庫，如果你想使用ssh，你需要設定安裝ssh，生成密鑰并複制到git的機器。
Summary
In this chapter, we have covered the techniques required when moving from a
simple setup to a larger deployment. We discussed how to separate your playbook
into multiple parts using includes. We then looked at how we can package up related
includes and automatically include them all at once using roles. Finally we discussed
pull mode, which allows you to automate the deployment of playbooks on the
remote node itself.
In the next chapter, we will cover writing your own modules. We start this by
building a simple module using bash scripting. We then look at how Ansible
searches for modules, and how to make it find your own custom ones. Then, we take
a look at how you can use Python to write more advanced modules using features
that Ansible provides. Finally, we will write a script that configures Ansible to pull
its inventory from an external source.
本章小結
在本章中，我們學習了如何從一個簡單的設定到一個複雜的部署任務。介紹了如何使用包含來分割playbook，如何使用角色來自動實作包含，最後我們介紹了Anisble的pull模式，它可以讓遠端受管主機自己運作playbook。
下一章，我們将介紹如何自己來建立自定義的子產品。我們将先介紹在bash中建立簡單子產品，如何介紹Ansible如何搜尋子產品，如何自定義自己的子產品。然後我們将介紹如何使用python利用Anisble提供的特性來編寫進階子產品，最後，我們将寫一個腳本來配置Ansible從外部的資料源來引用它自己的清單inventory。