輕鬆使用SaltStack管理成千上萬臺服務器（入門教程）

目錄樹 引言：一個」非專職運維人員「的煩惱 Salt快速入門 1. 安裝配置 2. 安裝管理端(master) 3. 安裝被管理端(minion) 4. 接受minion的託管請求 5. 測試 Salt的強大功能 1. 批量操做(targeting) 2. 節點分組（nodegroups） 3. 命令執行（execution） 4. 節點信息(grains) 5. 配置管理（state) 6. 小結 Salt state實例解析 1. 目錄結構 2. apache/init.sls 3. ssh/init.sls 4. ssh/server.sls 5. ssh/custom-server.sls 引言：一個」非專職運維人員「的煩惱加入到某證券公司的IT部門，儘管所在的部門掛了一個「研發部」的名字，可是我發現有大概40%的時間是在作運維工做。 這來自兩種狀況： 1. 自主開發的應用，須要持續的改進，不斷的更新、發佈、部署、調整配置，這不是運維部門喜歡的狀態。 2. 軟件商提供的「產品」沒法知足運維部門的要求：沒法經過簡單的 Q&A 文檔保證系統的正常運行，常常須要有必定技術能力的人員解決系統運行過程當中各類稀奇古怪的問題。 這種狀況下只能本身作一個「非專職運維人員」，須要頻繁的登陸各類服務器，執行一些命令來查看狀態或者更改配置（包括配置文件的變動和軟件包的安裝部署）。不少操做都是不斷的重複，日復一日，讓人厭煩。 」重複的工做應該交給程序去作「，因此我本身寫過一些腳本。爲了不將腳本上傳到幾十臺服務器而且不時進行更改，我使用Fabric來進行服務器的批量操做。 儘管避免了」批量的人工操做「，但我仍是在進行」人工的批量操做「。遠遠沒有實現自動管理。將有限的生命解放出來，投入到更有意義的編碼工做是一個奔四程序員應有的追求，因此我又睜大紅腫的眼睛，迷茫的搜索這個世界。 我發現了Puppet，Chef和CFEngine，可是並不滿意。直到我發現了Salt,個人眼前一亮：這正是我所須要的東西。 若是說Salt有什麼獨特之處打動了我，那就是： 簡單：多是源於python的簡約精神，Salt的安裝配置和使用簡單到了使人髮指的地步。任何稍有經驗的linux使用者能夠在10分鐘以內搭建一個測試環境並跑通一個例子（相比之下，puppet可能須要30--60分鐘）。 高性能：Salt使用大名鼎鼎的ZeroMQ做爲通信協議，性能極高。能夠在數秒鐘以內完成數據的傳遞 可伸縮：基於ZeroMQ通訊，具有很強的擴展性；能夠進行分級管理，可以管理分佈在廣域網的上萬臺服務器。 儘管twitter、豆瓣、oracle、等著名網站的運維團隊都在使用puppet，可是我相信，他們切換到salt只是一個時間問題。畢竟不是全部的人都喜歡操縱傀儡(puppet)，可是誰又能離開鹽(salt)呢？ 關於Salt和Puppet的對比，能夠參考這裏，或者看看中文版。 Salt快速入門Salt的體系結構中將節點區分爲: master, minion, syndic。 1. master: 老大，管理端 2. minion: 馬仔，被管理端 3. syndic: 頭目，對於老大來講是馬仔，對於馬仔來講是老大 在入門階段，先不考慮syndic。 1. 安裝配置若是將操做系統區分爲： *NIX Linux Solaris HP Unix FreeBSD OS X windows 理論上來講，Salt能夠安裝在任何*NIX系統上，包括master和minion。除了源代碼以外， 還能夠經過Salt提供的安裝腳本，或者PyPI進行安裝。 對於Linux，尤爲是企業環境中經常使用的RHEL,CentOS,Ubuntu，能夠經過包管理器很是容易的安裝master 和/或 minion。 好比: yum(須要先配置EPEL), apt(須要增長http://debian.madduck.net/repo/庫)，yaourt，ports。 Mac OS X 先使用HomeBrew解決依賴包：brew install swig zmq，而後用PyPI安裝：pip install salt。 對於windows，只能安裝minion（windows只適合作馬仔）。從官方網站下載合適的安裝包。安裝過程當中能夠指定master地址和本機名稱。 安裝後須要本身啓動Salt服務。配置文件在C:\salt\conf\minion。 具體的各操做系統下的安裝能夠參考官方文檔。這裏爲了簡單，只考慮經常使用的RHEL/CentOS 和 windows。 在下面的例子中，使用一臺RHEL/CentOS做爲master， 另一臺RHEL/CentOS和一臺windows 2003 Server做爲 minion。 2. 安裝管理端(master)# 安裝EPEL,注意選擇合適的版本 rpm -ivh http://mirrors.sohu.com/fedora-e ... ease-6-8.noarch.rpm yum update  # 安裝master yum install salt-master        # 修改配置 vim /etc/salt/master  # 最基本的設定服務端監聽的IP(好比使用VIP作master的高可用時)： # interface: 服務端監聽IP # 其餘配置參考[官方文檔](http://docs.saltstack.com/ref/configuration/master.html)  # 啓動服務(如下命令等效) salt-master -d /etc/init.d/salt-master start service salt-master start3. 安裝被管理端(minion)# 安裝EPEL,注意選擇合適的版本 rpm -ivh http://mirrors.sohu.com/fedora-e ... ease-6-8.noarch.rpm yum update  # 安裝minion yum install salt-minion     # 修改配置 vim /etc/salt/minion  # 最基本的設定是指定master地址，以及本機標識符： # master: master的主機名或IP地址 # id: 本機標識符 # 其餘配置參考[官方文檔](http://docs.saltstack.com/ref/configuration/minion.html)   # 啓動服務(如下命令等效) salt-minion -d /etc/init.d/salt-minion start service salt-minion start4. 接受minion的託管請求minion向master投誠後，還須要master接受才行。這個過程叫作「授信」。 Salt底層使用公鑰-私鑰證書來保證通訊信道的安全。具體的機制能夠參考ZeroMQ的相關內容。Salt已經屏蔽了底層的細節，只須要使用封裝好的命令： # 在master上運行 # 查看全部minion salt-key -L  Accepted Keys: windows bond_app_server_main mac_os_vm salt-master Unaccepted Keys: minion1 minion2 Rejected Keys:  #其中Unaccepted Keys是未許可的minion。可使用下面的命令經過認證： salt-key -a minion15. 測試安裝配置好以後，首先要測試一下聯通性：salt '*' test.ping。salt會列出每一個認證過的minion的聯通狀態(true 或 false)。 再舉一些例子： # 查詢主機運行了多長時間 sudo salt '*' cmd.run "uptime"   # 批量重啓服務 salt '*' cmd.run "service httpd restart"  # 讓多臺機器一塊兒，使用Apache Bench進行壓力測試 salt '*' cmd.run "ab -n 10 -c 2 http://www.google.com/"注意，默認狀況下master和minion之間使用如下端口進行通訊： 1. 4505(publish_port): salt的消息發佈系統 2. 4506(ret_port):salt客戶端與服務端通訊的端口 網絡的設置須要保證這些端口能夠訪問。 Salt的強大功能上面的例子都是用Salt進行批量操做。可是Salt的功能不只如此。 認真分析一下個人「非專職運維工做」的內容，發現能夠分爲如下三個方面： 1. 變動操做：根據須要對節點中某個資源的某種狀態進行調整，並檢驗變動的結果 2. 配置管理：讓上述行爲變得「可管理」，支持「有關人士」對上述行爲的標記、控制、識別、報告、跟蹤和歸檔甚至審批和審計 3. 狀態監控：隨時掌握狀態，發現異常。儘可能在系統用戶發現問題以前解決麻煩 Salt對上述三個方面提供了完美的支持，事實上，Salt提供的功能比我須要的還要多。下圖是Salt的主要功能：     若是想對Salt的功能和使用有一個初步的瞭解，最好參考官方文檔：Salt Stack Walkthrough。 1. 批量操做(targeting)再回顧一下上文中的例子: # 測試連通性 salt '*' test.ping  # 查詢主機運行了多長時間 sudo salt '*' cmd.run "uptime"   # 批量重啓服務 salt '*' cmd.run "service httpd restart"  # 讓多臺機器一塊兒，使用Apache Bench進行壓力測試 salt '*' cmd.run "ab -n 10 -c 2 http://www.google.com/"上面的例子都是對多個節點進行批量操做：使用通配符"'*'"對全部註冊的節點進行操做。Salt支持多種方式對節點id(minion id)進行匹配。包括： 默認：通配符(globbing)) * E：正則表達式(Regular Expression) * L：列表 * N: 分組(group) * C：複合匹配 先看一下通配符、正則表達式和列表的例子： # 通配符是最經常使用的匹配方式。Salt使用[linux風格的通配符](http://docs.python.org/2/library/fnmatch.html) salt '*' test.ping salt '*.example.net' test.ping salt '*.example.*' test.ping salt 'web?.example.net' test.ping salt 'web[1-5]' test.ping salt 'web-[x-z]' test.ping  # 正則表達式能夠適應更復雜的狀況。使用[python的re模塊](http://docs.python.org/2/library/re.html#module-re)進行匹配 salt -E 'web1-(prod|devel)' test.ping  # 最直接的方式是本身指定多個minion，即列表 salt -L 'web1,web2,web3' test.ping複合匹配(Compound matchers)有點複雜，後續會在其餘文章中專門介紹。 2. 節點分組（nodegroups）好吧，批量操做確實很爽。可是每次都輸入匹配規則有點麻煩，對於複雜的匹配規則更是如此。 salt的 nodegroups功能能夠將經常使用的匹配規則保存下來（稱之爲minion的分組）。批量操做是，只須要使用L標記指定要操做的group名字便可。 groups定義在master的配置文件/etc/salt/master中。 group 的定義可使用各類匹配規則，好比： group1: 'L@foo.domain.com, bar.domain.com,baz.domain.com or bl*.domain.com'group2: 'G@os:Debian and foo.domain.com'3. 命令執行（execution）Salt生來就有命令編排的功能。聽說，Salt最早實現的是遠程執行技術，而後才添加的配置管理功能。Salt使用ZeroMQ來處理命令執行的請求和響應消息，安裝配置簡單，而且性能很是高。 Salt便可以批量執行命令，也能夠單機執行。一般單機執行用於測試： 1. 單機（當即）執行。 使用salt-call命令單機執行操做 2. 批量(當即)執行。最經常使用的操做。使用salt命令，對匹配的minion節點執行操做 Salt能夠執行的命令也能夠分爲兩種： 1. 系統命令，使用cmd.run執行 2. Salt模塊，將經常使用的命令/批處理封裝到內置的Salt模塊(module)，使用模塊名.功能名的方式執行。 好比： # 執行系統命令 salt '*' cmd.run 'hostname'  # 執行Salt模塊 salt '*' disk.usage使用Salt模塊的好處是可以作到一致。好比一樣是查看磁盤使用狀況，salt '*' cmd.run "df -h"只能用於NIX節點，而salt '*' disk.usage對NIX和Windows都適用，而且採用相同結構返回數據，便於批量處理。 Salt已經內置了大量的模塊，這些模塊涵蓋了平常管理任務的主要任務，包括： 1. 通用的管理任務，好比apt, at, cp, cron, disk, extfs, file, grains, hosts, iptables, mount, network, pam, parted, pkg, ps, selinux, shadow, ssh, test等 2. 針對特定軟件的任務，好比apache, cassandra, djangomod, git, mongodb, mysql, nginx, nova, postgres, solr, sqlite3, 和tomcat 並且，本身開發Salt模塊也很是簡單，很容易將實際管理操做中的一些經驗經過自定義的模塊固化下來，並方便分享。 在開發和調試模塊的時候，可使用test=True參數進行模擬執行(Dry run)。好比： salt 'minion1.example.com' state.highstate -v test=True4. 節點信息(grains)grains是Salt內置的一個很是有用的模塊。在用salt進行管理客戶端的時候或者寫state的時候均可以引用grains的變量。 grains的基本使用舉例以下： # 查看grains分類 salt '*' grains.ls    # 查看grains全部信息 salt '*' grains.items  # 查看grains某個信息 salt '*' grains.item osrelease5. 配置管理（state)配置管理是Salt中很是重要的內容之一。Salt經過內置的state模塊支持配置管理所需的功能。關於這部份內容，官方文檔有很詳細的描述，能夠參考 part 1，part 2和 part 3。 Salt中能夠定義節點的目標狀態，稱之爲state。state對應配置管理中的配置，能夠對其進行標識、變動控制、變動識別、狀態報告、跟蹤和歸檔以及審計等一些的管理行爲。 狀態描述 Salt使用SLS文件（SaLt State file）描述狀態。SLS使用YAML格式進行數據序列化，所以簡單明瞭，可讀性也很高。 基本描述(yaml) 下邊是一個簡單的SLS文件例子: apache:   pkg:     - installed   service:     - running     - require:       - pkg: apache 該文件描述一個ID爲apache的配置狀態： 1. 軟件包（pkg)已經安裝 2. 服務應該處於運行中 3. 服務的運行依賴於apache軟件包的安裝 state文件中的全部YAML變量名來自Salt的state模塊。 Salt內置了大量的state模塊，好比cron, cmd, file, group, host, mount, pkg, service, ssh_auth，user等。 詳細清單參考這裏。 還能夠開發本身的state模塊。 擴展描述(jinja) state可使用jinja模板引擎進行擴展，其語法能夠參考這裏。 下面是一個更復雜的例子： vim:  pkg:        { % if grains['os_family'] == 'RedHat' % }     - name: vim-enhanced        { % elif grains['os'] == 'Debian' % }    - name: vim-nox        { % elif grains['os'] == 'Ubuntu' % }    - name: vim-nox        { % endif % }    - installed     該state增長了判斷邏輯：若是是redhard系列的就安裝 vim-enhanced，若是系統是Debian或者Ubuntu就安裝vim-nox。 邏輯關係 state之間能夠有邏輯關係。常見的關係舉例以下： 1. require：依賴某個state，在運行此state前，先運行依賴的state，依賴能夠有多個 httpd:   pkg:     - installed   file.managed:     - name: /etc/httpd/conf/httpd.conf     - source: salt://httpd/httpd.conf     - require:       - pkg: httpd watch：在某個state變化時運行此模塊 redis:  pkg:    - latest  file.managed:    - source: salt://redis/redis.conf    - name: /etc/redis.conf    - require:      - pkg: redis    service.running:      - enable: True      - watch:      - file: /etc/redis.conf      - pkg: redis watch除具有require功能外，還增了關注狀態的功能 3. order：優先級比require和watch低，有order指定的state比沒有order指定的優先級高 vim:  pkg.installed:    - order: 1 想讓某個state最後一個運行，能夠用last 保存狀態 狀態描述文件(SLS)要保存在master節點中，並經過指令分發到minion節點。 1. 路徑設置 Salt master的配置文件(/etc/salt/master)中能夠經過file_roots參數指定狀態文件的保存路徑。能夠爲不一樣的環境（如開發環境、UAT環境、生產環境、災備環境等）分別指定路徑，以下所示： file_roots:  base:    - /srv/salt/  dev:    - /srv/salt/dev/services    - /srv/salt/dev/states  prod:    - /srv/salt/prod/services    - /srv/salt/prod/states 其中,base環境是必須的。 2. 入口文件 file_roots中必須指定「base」環境的路徑，由於該路徑中存在Salt state的入口文件: top.sls。 Top文件創建配置環境、節點和狀態配置之間的映射關係。好比一個簡單的top.sls文件： base:  '*':    - serversdev:  '*nodb*':    - mongodb 該文件指定了： - 全部節點使用base環境的servers配置 - nodb節點使用dev環境的mongodb配置 結合第一部分的file_roots配置，該top配置意味存在如下的配置文件： /srv/salt/servers.sls/srv/salt/dev/mongodb.sls 注：這裏也可使用文件夾/srv/salt/servers/和/srv/salt/dev/mongodb/，在文件夾中放置一組狀態文件和配置文件，便於創建複雜的狀態配置。 top.sls中的可配置內容很是豐富，具體內容能夠參考官方文檔。 狀態生效（State Enforcement） master上對狀態進行定義，最終這些狀態要傳遞到minion節點上。在本節的例子中，若是定義好了狀態文件/srv/salt/dev/mongodb.sls： mongodb:  pkg:    - installed 可使用命令salt "minion1" state.highstate -v使得全部針對"minion1"的state生效； 在執行狀態以前先進行測試是個好主意，須要指定參數test=True。好比，salt "minion1" state.highstate -v test=True。 關於state模塊的更多用法，能夠參考state模塊說明，或官方文檔。 更多 Salt的state模塊的功能不只如此，還可使用模板和變量，以及定義狀態的定時自動生效。 6. 小結本文介紹Salt的主要功能和基本使用，包括minion節點的管理，批量操做，以及很是重要的配置管理。 掌握了這些內容，可使用Salt極大提升運維的效率（事實上，Salt對於開發階段也能提供很大的幫助，開發和運維的界限正在逐漸模糊）。 後續會介紹一些使用案例以及Salt的高級功能。 Salt state實例解析在Salt的官方教程中，以apache和sshd的state配置做爲例子。掌握這兩個例子，就可以舉一反三，處理平常工做中大部分的配置管理問題。 本文對這兩個例子進行詳細的分析和註釋。 1. 目錄結構文檔 中的例子包含了多個文件。這些文件之間互相引用和關聯。目錄結構及文件清單以下：   apache/init.sls apache/httpd.conf   ssh/init.sls   ssh/server.sls ssh/banner ssh/ssh_config ssh/sshd_config ssh/custom-server.sls   兩個配置分別放在了apache和ssh文件夾。一個Salt狀態可使用單個的SLS文件，或者使用一個文件夾。後者更加靈活方便。 2. apache/init.sls apache:    pkg:      - installed    service:      - running      - watch:        - pkg: apache        - file: /etc/httpd/conf/httpd.conf        - user: apache    user.present:      - uid: 87      - gid: 87      - home: /var/www/html      - shell: /bin/nologin      - require:        - group: apache    group.present:      - gid: 87      - require:        - pkg: apache   /etc/httpd/conf/httpd.conf:    file.managed:      - source: salt://apache/httpd.conf      - user: root      - group: root      - mode: 644      - template: jinja      - context:        custom_var: "override"      - defaults:        custom_var: "default value"        other_var: 123說明： 1. sls文件使用YAML格式定義，最外面的層級定義配置項。 2. 一個sls文件中能夠有多個配置項，配置項的ID能夠起任意的名字。本例中包含ID爲apache和/etc/httpd/conf/httpd.conf兩個配置項。 3. 配置項內是一系列的狀態聲明。全部的狀態項來自Salt狀態模塊。便可以使用Salt內置的狀態模塊，也能夠編寫自定義的狀態模塊 4. 狀態聲明內部指定狀態函數的調用。狀態函數是每一個Salt狀態模塊中定義的函數。 5. apache配置項 1) pkg模塊，使用操做系統的包管理器(如yum, apt-get)安裝軟件包 salt.states.pkg.installed函數, 驗證軟件包是否安裝以及是否爲指定的版本 2) service模塊管理服務/守護進程(daemon)的啓動或中止     salt.states.service.running函數檢查服務是否已經啓動     service模塊定義了salt.states.service.mod_watch函數，可使用watch要素監控其餘的模塊是否知足。這裏監控如下狀況：         apache軟件包(pkg)是否已安裝         /etc/httpd/conf/httpd.conf文件(file)是否存在         apache用戶(user)是否存在     user.present是簡寫形式，直接調用user模塊的present函數檢查是否存在以下屬性的apache用戶：         uid=87         gid=87         home目錄爲/var/www/html         登陸腳本爲/bin/nologin         檢查依賴項：apache用戶組     group.present是簡寫形式，直接調用group模塊的present函數檢查是否存在以下屬性的apache用戶組：         gid=87         檢查依賴項：apache軟件包 6. /etc/httpd/conf/httpd.conf配置項 file.managed是簡寫形式，直接調用file模塊的managed方法根據須要從master獲取文件並可能會經過模板系統(templating system)進行渲染。文件要知足以下要求：   使用master上面的apache/httpd.conf文件 user=root group=root mode=644 使用jinja模板渲染 上下文變量： custom_var="override" 默認值: custom_var="default value" other_var=123   3. ssh/init.slsopenssh-client:    pkg.installed   /etc/ssh/ssh_config:    file.managed:      - user: root      - group: root      - mode: 644      - source: salt://ssh/ssh_config      - require:        - pkg: openssh-client4. ssh/server.sls include:    - ssh  openssh-server:   pkg.installed  sshd:   service.running:     - require:       - pkg: openssh-client       - pkg: openssh-server       - file: /etc/ssh/banner       - file: /etc/ssh/sshd_config  /etc/ssh/sshd_config:   file.managed:     - user: root     - group: root     - mode: 644     - source: salt://ssh/sshd_config     - require:       - pkg: openssh-server  /etc/ssh/banner:   file:     - managed     - user: root     - group: root     - mode: 644     - source: salt://ssh/banner     - require:       - pkg: openssh-server說明： 1. include語句將別的state添加到當前文件中，使得state能夠跨文件引用。 使用include至關於把被引用的內容文件添加到自身，能夠require、watch或extend被引用的SLS中定義的內容。 這裏引用了sshstate。 2. openssh-server配置項 3. sshd 4. /etc/ssh/sshd_config配置項 5. /etc/ssh/banner配置項 5. ssh/custom-server.slsinclude:   - ssh.server  extend:   /etc/ssh/banner:     file:       - source: salt://ssh/custom-banner說明： 1. 引用sshstate的server配置項 2. extend能夠複用已有的state，在原來的基礎上進行擴展，增長新的配置或修改已有的配置。     將/etc/ssh/banner配置項的文件修改成salt://ssh/custom-banner