介紹

持續交付是頻繁對軟件應用程序持續更新的概念.

這個想法使在大量頻繁的更新面前, 你不必等待在一個指定的特殊時間點, 并且使你的組織在響應過程中變得更好.

一些 Ansible 用戶每小時都在部署更新給他們的最終用戶甚至更加頻繁 – 每時每刻都有代碼修改的批準. 要實現這一點, 你需要工具能在零停機的時間內快速的應用這些更新.

本文檔詳細介紹了如何現實這一目標, 使用 Ansible playbooks 作為一個完整例子的模板: lamp_haproxy. 這個例子使用了大量的 Ansible 特性: roles, templates 和 group variables, 并且它還配備了一個業務流程的 playbook 可以做到零停機滾動升級 web 應用程序棧.

Note

點擊這里查看最新版本的 playbook 例子.

這個 playbooks 基于 CentOS 部署 Apache, PHP, MySQL, Nagios, 和 HAProxy 這些服務.

在這里我們不去討論如何運行這些 playbooks. 閱讀包含在 github 項目中關于這個例子的 README 信息. 相反的, 我們將進一步觀察這些 playbook 并且去解釋它們.

部署網站

讓我們首先使用?site.yml. 這是我們網站部署的 playbook. 它被用來部署我們最初的網站以及推送更新到所有的服務器:

--- # 這個 playbook 在這個網站上部署整個應用程序.# 應用通用的配置到所有的主機上 - hosts: allroles:- common# 配置和部署數據庫服務器. - hosts: dbserversroles:- db# 配置和部署 web 服務器. 注意這里我們包含了兩個 roles, 這個 'base-apache' role 用來簡單設置 Apache, 而 'web' 則包含了我們的 web 應用程序.- hosts: webserversroles:- base-apache- web# 配置和部署 load balancer(s). - hosts: lbserversroles:- haproxy# 配置和部署 Nagios 監控節點(s). - hosts: monitoringroles:- base-apache- nagios

Note

如果你不熟悉 playbooks 和 plays, 你應該回顧?Playbooks.

在這個 palybook 我們有 5 個 plays. 首先第一個目標?all?(所有)主機和適用于所有主機的?commonrole. 這是整個網站要做的事像 yum 倉庫的配置, 防火墻的配置, 和其他任何需要適用于所有服務器的配置.

接下來的這四個 plays 將運行于指定的主機組并特定的角色應用于這些服務器. 隨著對 Nagios monitoring, 數據庫角色, 和 web應用程序的應用, 我們可以通過?base-apache?角色安裝和配置一個基本的 Apache. 這是 Nagios 主機和 web 應用程序所需要的.

可重用的: Roles

關于 roles 你現在應該有一點了解以及它們是如何工作的. Roles 是組織: tasks, handlers, templates, 和 files, 到可重用的組件中的方法.

這個例子有 6 個 roles:?common,?base-apache,?db,?haproxy,?nagios, 和?web. 你如何組織你的 roles 是由你和你的應用程序所決定, 但是大部分網站都將適用一個或多個共同的 roles, 和一些列關于應用程序特定的 roles 來安裝和配置這個網站的特定部分.

Roles 可以用變量和依賴關系, 你可以通過參數來調整它們的行為. 你可以在?Playbook Roles and Include Statements?章節中關于 roles

配置: Group Variables

Group variables 是應用在服務器組上的. 通過設置和修改參數將他們應用在 templates 中來定義 playbooks 的行為. 他們被存儲在和你的 inventory 相同目錄下名為?group_vars?的目錄中. 下面是 lamp_haproxy 的?group_vars/all?文件內容. 正如你所期望的, 這些變量將會應用到 inventory 中的所有服務器上:

--- httpd_port: 80 ntpserver: 192.168.1.2

這是一個 YAML 文件, 并且你可以創建列表和字典等更加復雜的變量結構. 在這種情況下, 我們只設置了兩個變量, 一個做為 web server 的端口, 一個作為我們服務器所使用的時間同步 NTP 服務的地址.

這是另外一個 group variables 文件. 這個?group_vars/dbservers?適用于在?dbservers?組中的主機:

--- mysqlservice: mysqld mysql_port: 3306 dbuser: root dbname: foodb upassword: usersecret

如果你看了這個例子, 你會發現對于?webservers?組合?lbservers?組的 group variables 十分相似.

這些變量可以用于任何地方. 你可以在 playbooks 中使用它們, 像這樣, 在?roles/db/tasks/main.yml:

- name: Create Application Databasemysql_db: name={{ dbname }} state=present- name: Create Application DB Usermysql_user: name={{ dbuser }} password={{ upassword }}priv=*.*:ALL host='%' state=present

你也可以在 templates 中使用這些變量, 想這樣, 在?roles/common/templates/ntp.conf.j2:

driftfile /var/lib/ntp/driftrestrict 127.0.0.1 restrict -6 ::1server {{ ntpserver }}includefile /etc/ntp/crypto/pwkeys /etc/ntp/keys

你可以看到這些變量替換的語法 {{ and }} 和 templates 中的變量是相同的. 這種花括號格式是采用的jinj2語法, 你在對于內部的數據做各種操作及應用不同的過濾器. 在 templates, 你也可以使用循環和 if 語句來處理更加復雜的情況, 想這樣, 在?roles/common/templates/iptables.j2:

{% if inventory_hostname in groups['dbservers'] %} -A INPUT -p tcp --dport 3306 -j ACCEPT {% endif %}

這是用來判斷, 名為 (inventory_hostname) 的機器是否存在于組?dbservers. 如果這樣的話, 該機器將會添加一條 目標端口為 3306 的 iptables 允許規則.

這有一些其他的例子, 來自相同的模板:

{% for host in groups['monitoring'] %} -A INPUT -p tcp -s {{ hostvars[host].ansible_default_ipv4.address }} --dport 5666 -j ACCEPT {% endfor %}

這里循環了一個組名為?monitoring?中的所有主機, 并且配置了源地址為所有監控主機的 IPV4 地址目標端口為 5666 的 iptables 允許規則到當前主機上, 正因為如此 Nagios 才可以監控這些主機.

你可以學到更多關于 Jinja2 的功能?here, 并且你可以讀到更多關于 Ansible 所有的變量在這個?Variables?章節

滾動升級

現在你有了一個全面的網站包含 web servers, 一個 load balancer, 和 monitoring. 如何更新它? 這就是 Ansible 的特殊功能發揮作用. 盡管一些應用程序使用’業務流程’來編排命令執行的邏輯, Ansible將指揮編排這些機器, 并且擁有一個相當復雜的引擎.

Ansible 有能力在一次操作中協調多種應用程序, 使在進行更新升級我們的 web 應用程序時更加實現零停機時間. 這是一個單獨的 playbook, 叫做?roleing_upgrade.yml.

看這個 playbook, 你可以看到它是由兩個 plays 組成. 首先第一個看起來十分簡單像這樣:

- hosts: monitoringtasks: []

這里要做什么, 為什么沒有 tasks? 你可能知道 Ansible 在運行之前會從服務上收集 “facts”. 這些 facts 是很多種有用的信息: 網絡信息, OS/發行版本, 配置. 在我們的方案中, 在更新之前我們需要了解關于所有監控服務器的環境信息, 因此這個簡單的 paly 將會在我們的所監控的服務器上強制收集 fact 信息. 你有時會見到這種模式, 這是一個有用的技巧.

接下來的部分是更新 play. 第一部分看起來是這樣:

- hosts: webserversuser: rootserial: 1

我們僅僅是像通常一樣在?webservers?組中定義了 play. 這個?serial?關鍵字告訴 Ansible 每次操作多少服務器. 如果它沒有被指定, Ansible 默認根據配置文件中 “forks” 限制指定的值進行并發操作. 但是對于零停機時間的更新, 你可能不希望一次操作多個主機. 如果你僅僅有少數的 web 服務器, 你可能希望設置?serial?為 1, 在同一時間只執行一臺主機. 如果你有 100 臺, 你可以設置?serial?為 10, 同一時間執行 10 臺.

下面是更新 play 接下來的部分:

pre_tasks: - name: disable nagios alerts for this host webserver servicenagios: action=disable_alerts host={{ inventory_hostname }} services=webserverdelegate_to: "{{ item }}"with_items: groups.monitoring- name: disable the server in haproxyshell: echo "disable server myapplb/{{ inventory_hostname }}" | socat stdio /var/lib/haproxy/statsdelegate_to: "{{ item }}"with_items: groups.lbservers

這個?pre_tasks?關鍵字僅僅是讓在 roles 調用前列出運行的 tasks. 這段時間將十分有用. 如果你看到這些 tasks 的名稱, 你會發現我們禁用了 Nagios 的報警并且將當前更新的服務器從 HAProxy load balancing pool 中移除.

參數``delegate_to`` 和?with_items?一起來使用, 因為 Ansible 循環每一個 monitoring 服務器和 load balancer, 并且針對循環的值在 monitoring 或 load balancing 上操作(delegate 代表操作). 從編程方面來說, 外部的循環是 web 服務器列表, 內部的循環是 monitoring 服務器列表.

請注意 HAProxy 的步驟看起來有點復雜. 我們使用它作為例子是因為它是免費的, 但如果你有(例如)一個 F5 或 Netscaler 在你的基礎設施上(或者你有一個 AWS 彈性 IP 的設置?), 你可以使用 Ansible 的模塊而不是直接和他們進行交互. 你也可能希望使用其他的 monitoring 模塊來代替 nagios, 但是這僅僅是展示了在任務開始前的部分 – 把服務從監控中移除并且輪換它們.

下一步重新簡單的使正確的角色應用在 web 服務器上. 這將導致一些名為?web?和?base-apache?的配置管理角色應用到 web 服務器上, 包含一個更新 web 應用程序自身代碼. 我們不需要這樣做 – 我們僅需要將其修改為純碎的更新 web 程序, 但是這是一個很好的例子關于如何通過 roles 來重用這些任務:

roles: - common - base-apache - web

最后, 在?post_tasks?部分, 我們反向的改變 Nagios 的配置并且將 web 服務器重新添加到 load balancing pool:

post_tasks: - name: Enable the server in haproxyshell: echo "enable server myapplb/{{ inventory_hostname }}" | socat stdio /var/lib/haproxy/statsdelegate_to: "{{ item }}"with_items: groups.lbservers- name: re-enable nagios alertsnagios: action=enable_alerts host={{ inventory_hostname }} services=webserverdelegate_to: "{{ item }}"with_items: groups.monitoring

再一次說明, 如果你在使用一個 Netscaler 或 F5 或 Elastic 的負載均衡器, 你僅僅需要替換為適合的模塊對象.

管理其他的負載均衡

在這個例子中, 我們使用了簡單的 HAProxy 負載均衡到后端的 web 服務器. 它是非常容易配置和管理的. 正如我們所提到的, Ansible 已經為其他的負載均衡器像 Citrix NetScaler, F5 BigIP, Amazon Elastic Load Balancers 等提供了內建的支持.信息?模塊相關

對于其他的負載均衡器, 如果公開一個負載均衡時, 你可能需要向它們發送 shell 命令 (像上面我們對 HAProxy 一樣), 或者調用一些 API. 你可以越多更多關于 local actions 在這個?委托,滾動更新,本地動作章節中. 對于一些硬件的開發將更加有趣, 他們沒有一個核心模塊, 所以你可以使用更好的模塊將他們封裝起來!

持續交付結束

現在你有一個自動化的方式來部署更新你的應用程序, 你將如何將他們綁定在一起? 許多組織使用持續集成的工具像?Jenkins?或?Atlassian Bamboo?來完成開發, 測試, 發布, 和部署這樣的流程步驟. 你也可以使用這些工具像?Gerrit?來添加一個 code review 的步驟來審查提交的應用程序的本身或者 Ansible playbooks.

根據你的環境, 你可能會部署到一個測試環境, 在這個環境中運行一些集成測試, 然后自動部署到生產環境. 你可以保持他們的簡單性僅按需來進行滾動升級到測試或者指定的生產環境中. 這些你都隨你決定.

與持續集成工具的結合, 你可以通過?ansible-playbook?命令行工具很容易的觸發 playbook 的運行, 或者, 如果你使用?Ansible Tower,?tower-cli?或者內置的 REST API. (這個 tower-cli 命令的 ‘joblaunch’ 將通過 REST API 遠程產生一個 job 這非常棒).

Ansible 對于如何組合多層應用程序在任務編排和持續交付給客戶的最終目標上給了你很好的主意. 你可以使用滾動升級的思路來擴展一些應用程序之間的不同部分; 也許向前端 web 服務器添加后端應用服務, 例如, 使用 MongoDB 或 Riak 來替換 SQL 數據庫. Ansible 可以給你在復雜的環境中輕松完成常見的自動化操作.

See also

lamp_haproxy example

The lamp_haproxy example discussed here.

Playbooks

An introduction to playbooks

Playbook Roles and Include Statements

An introduction to playbook roles

Variables

An introduction to Ansible variables

Ansible.com: Continuous Delivery

An introduction to Continuous Delivery with Ansible

轉載于:https://www.cnblogs.com/kevinX/p/8340756.html

總結

以上是生活随笔為你收集整理的持续交付与滚动升级的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。