haproxyftp
① HAProxy 的 ACLs 詳解
編譯自：
using ACLs and pattern extraction
文檔版本：HAProxy version 1.4.27
目錄：
使用 ACLs，可以基於請求和響應的任何部分，進行服務內容的切換。總的原則如下：
acl 關鍵字用於定義一條新的測試准則，或者對一條已經存在的測試准則進行重新定義：
<criterion>：
指定對請求判掘型或者響應的某個部分進行測試
[flags]：
對測試進行調整
[operator]：
<value>：
注，ACL名稱只能使用大寫字母、小寫字母散銀、數字、-(中線)、_(下劃線)、.(點號)和:(冒號)。此外，ACL名稱會區分字母大小寫。my_acl 和 My_Acl 是兩個不同的 ACLs。
對 ACLs 的數量沒有限制，它們只佔用少量內存。
整數匹配的規則：
1. 允許范圍匹配
例如：
1024:65535
1024:
0:1023
:1023
這是指准確的字元串匹配，有一些規則如下：
基本規則同上
匹配某個IP地址：
192.168.0.110
www.guli.com （支持使用主機名，但不推薦這樣做，因為對配置來講，會造成閱讀和調試上的困難）
如果使用主機名，需掘猜確保 /etc/hosts 中有對應的解析條目，不要依賴 DNS 解析。
匹配某個網路：
192.168.0.0/24
這是第一部分的測試區域，不需要對請求或響應的內容進行分析。其中包含 TCP/IP 地址和埠，以及一些與流量無關的內部信息。
always_false
這個永遠不會匹配。所有的 values 和 flags 被忽略。可在調整配置時使用。
always_true
這個永遠匹配。所有的 values 和 flags 被忽略。可在調整配置時使用。
avg_queue <integer>
avg_queue(backend) <integer>
某個指定 backend 的等待隊列長度的平均數，如果在指定范圍內，返回 ture。
返回值為：某個 backend 的等待連接總數 / 該 backend 活動的後端伺服器總數。
根據該值，可大致判斷一個新的連接需要等待多久才會被處理。
其主要使用場景是，當某個新的用戶確定只能得到降級的服務，返回一個 sorry page 給該用戶。
應注意的是，當 backend 中沒有活動的伺服器了，我們會把等待隊列的連接數x2，作為測量值。這是一個公平的預測，因為我們期望有一台伺服器能快速歸位。但這種情況下，更好的方法是將流量轉發給另一個後端。
be_conn <integer>
be_conn(backend) <integer>
返回指定 backend 中當前已建立的連接數（possibly including the connection being evaluated），如果在指定范圍內，返回 ture。
如果沒有特別指定是那個 backend，則表示使用當前的 backend。
可用於這樣的場景，如果被測試的 backend 中連接數已經滿負荷，將其流量轉發給另一個 backend。
be_id <integer>
返回 backend 的 id。可在 frontend 中使用，用於檢測是被哪一個 backend 所調用。
be_sess_rate <integer>
be_sess_rate(backend) <integer>
返回「會話創建速率」：new sessions/s，如果在指定范圍內，返回 true。
使用場景：
示例：
connslots <integer>
connslots(backend) <integer>
connslots = backend 伺服器剩餘的可容納的連接數 + backend 的等待隊列中剩餘的可容納的連接數，在指定范圍內時返回 true。
簡單來說，就是衡量一個 backend 當前還能接收多少新建連接。基於這個值，可以做更好的負載均衡。一般配合 fe_conn（frontend 當前已經接收的連接數） 一起做判斷。
dst <ip_address>
返回當前客戶端所連接的本地的 IPv4 地址。It can be used to
switch to a different backend for some alternative addresses.
dst_conn <integer>
返回一個socket 上已經建立的連接數（including the one being evaluated）。如果當前接收的連接數已經到達滿負荷，可用於在 hard-blocking 之前返回 sorry 頁面；或者，使用某個指定的 backend 接收新的請求。
我們可以使用它對不同的監聽地址設置不同的限制。
dst_port <integer>
返回當前客戶端所連接的本地的埠地址。It can be used to switch
to a different backend for some alternative ports.
fe_conn <integer>
fe_conn(frontend) <integer>
返回某個 frontend 中已經建立的連接數（possibly including the connection being evaluated），如果在指定范圍內，返回 true。
如果未指定是哪個 frontend，使用當前的 frontend。
如果所關聯的 backend 接收的連接數被認為已經到達滿負荷，可用於在 hard-blocking 之前返回 sorry 頁面；或者，使用某個指定的 backend 接收新的請求。
fe_id <integer>
返回 frontend 的 id。在 backend 中可使用它判斷自己是被哪個 frontend 所調用。
fe_sess_rate <integer>
fe_sess_rate(frontend) <integer>
返回 frontend 的 「新建會話速率」。單位為：新建會話數/秒。如果在指定范圍內，返回 true。
一般使用場景：限制新建連接的速率為一個可接受的范圍內。在第一時間防止服務濫用。防止 ddos 攻擊等。
結合 4層 ACLs，可強制讓一個客戶端等待少許時間，等待新建會話率降至合理范圍內。
示例：
nbsrv <integer>
nbsrv(backend) <integer>
返回當前 backend 或某個指定的 backend 的可用伺服器數。當可用伺服器數過低時，可切換到其他 backend。
一般和 monitor fail 配合使用。
queue <integer>
queue(backend) <integer>
返回當前 backend 或某個指定的 backend 的等待隊列中的連接數。
當隊列長度超過警戒值，一般意味著遇到訪問高峰，或者大量的伺服器失效。一種可行的措施是拒絕新的用戶，並且維持舊的連接。
so_id <integer>
返回 socket 的 id。
用於 frontend，當有多個 bind 關鍵字時，也就是監聽了多個地址時，是有用的。
src <ip_address>
返回客戶端的 IPv4 地址。
一般用於對某些資源進行訪問限制，比如統計數據資源。
src_port <integer>
返回客戶端的 TCP source port。用處較少。
srv_id <integer>
返回 server 的 id。
可用於 frontend 和 backend
srv_is_up(<server>)
srv_is_up(<backend>/<server>)
當指定 backend 或當前 backend 中的 server 正在運行，返回 true，否則返回 false。
不接受參數。
當健康檢查報告了一個外部狀態時（eg: a geographical site's availability），採取一定的動作。
第二部分的測試區域，基於緩存中找到的數據，它們在分析的過程可能就會發生變化。
要求有數據被緩存，常用於 「TCP 請求內容檢查」：
req_len <integer>
如果在 request buffer 中的數據長度匹配了指定的范圍，返回 true。
如果 buffer is changing，那麼就不會返回 false。在一個會話剛開始的時候，req_len eq 0 是肯定匹配的。
對於 req_len ge 大於0的整數，會等待數據進入 buffer，如果 haproxy 確定沒有數據進來時，才會返回 false。
用於 「TCP 請求內容檢查」
req_proto_http
如果在 請求buffer 中的數據看起來像是 HTTP 或者能被當做 HTTP 進行正確解析，返回 true。
通過 「TCP 請求內容檢查」 的規則，可用於調度 HTTP 流量和 HTTPS 流量到不同的埠地址。
req_rdp_cookie <string>
req_rdp_cookie(name) <string>
遠程桌面協議相關
req_rdp_cookie_cnt <integer>
req_rdp_cookie_cnt(name) <integer>
遠程桌面協議相關
req_ssl_ver <decimal>
如果在請求緩存中的數據，看起來像 SSL 協議數據，而且協議版本在指定的范圍內，返回 ture。
支持 SSLv2 hello messages 和 SSLv3 messages。
此測試意在進行嚴格限制，盡量避免被輕易地欺騙。
In particular, it waits for as many bytes as announced in the
message header if this header looks valid (bound to the buffer size)
注意，TLSv1 協議將被稱為 SSL version 3.1。
用於 「TCP 請求內容檢查」
wait_end
等待分析周期結束，返回 true。
一般與內容分析聯合使用，避免過早返回一個錯誤的結論。
也可用於延遲某些動作，比如拒絕某些指定的IP地址的動作。
因為它要麼停止規則檢查，要麼立即返回 true，所以建議在一條規則的最後使用這個 acl。
注意，默認的 ACL "WAIT_END" 總是可用的，不需要預先聲明。
本測試用於 「TCP 請求內容檢查」
示例：
第三部分的測試區域，是七層測試。要求對 HTTP 請求進行完全的解析之後進行。
因為請求和響應都被建立了索引，所以雖然相比四層匹配要求更多的 CPU 資源，但也不會太多。
hdr <string>
hdr(header) <string>
hdr* 匹配所有 headers，hdr*(header) 匹配指定的 header，注意括弧裡面不能有空格。
指定首部時，其名稱不區分大小寫；
The header matching complies with RFC2616, and treats all values delimited by commas as separate headers.
對於響應首部，使用 shdr()；
示例，檢查是否設置了 "connection: close" ：
hdr_beg <string>
hdr_beg(header) <string>
任何一個 header 的值是以 string 起始的，返回 true
對於響應首部，使用 shdr_beg()；
hdr_cnt <integer>
hdr_cnt(header) <integer>
如果指定的 header 出現的次數在指定范圍內，或匹配指定的值，返回 true；
一行 header 語句如果包含多個值，將被多次計數；
用於檢查指定 header 的是否存在，是否被濫用；
通過拒絕含有多個指定 header 的請求，可阻擋 request smuggling attacks；
對於響應首部，使用 shdr_cnt()；
hdr_dir <string>
hdr_dir(header) <string>
用於文件名或目錄名匹配，當某個 header 包含被 / 分隔的 string，返回 true；
可與 Referer 聯合使用；
對於響應首部，使用 shdr_dir()；
hdr_dom <string>
hdr_dom(header) <string>
用於域名匹配，可與 Host header 一起使用；當某個 header 包含被 . 分隔的 string，返回 true；
對於響應首部，使用 shdr_dom()；
hdr_end <string>
hdr_end(header) <string>
當任何一個 header 的值是以 string 結束的，返回 true
對於響應首部，使用 shdr_end()；
hdr_ip <ip_address>
hdr_ip(header) <ip_address>
當某個 header 的值包含匹配 <ip_address> 的值，返回 true；
通常與 X-Forwarded-For or X-Client-IP 一起使用；
對於響應首部，使用 shdr_ip()；
hdr_len <integer>
hdr_len(<header>) <integer>
至少有一個 header 的 length 與指定的值或者范圍匹配時，返回 true；
對於響應首部，使用 shdr_len()；
hdr_reg <regex>
hdr_reg(header) <regex>
有一個 header 與正則表達式匹配時，返回 true，可在任何時候使用；
注意，正則匹配比其他匹配更慢；
對於響應首部，使用 shdr_reg()；
hdr_sub <string>
hdr_sub(header) <string>
有一個 header 包含其中一個 string 時，返回 true；
對於響應首部，使用 shdr_sub()；
hdr_val <integer>
hdr_val(header) <integer>
有一個 header 起始的數字，與指定值或范圍匹配；可用於限制 content-length，只接受合理長度的請求；
對於響應首部，使用 shdr_val()；
http_auth(userlist)
http_auth_group(userlist) <group> [<group>]*
從客戶端收到的認證信息與 userlist 中記錄的匹配時，返回 true；
目前只支持 http basic auth；
http_first_req
如果處理的請求是連接的第一個請求，返回 true；
method <string>
用於檢查 HTTP 請求的方法，匹配時，返回 true；
path <string>
請求中的 path 部分（以 / 起始，到 ? 為止的部分），與某個 string 相等時，返回 true；
可用於匹配某個文件，比如：/favicon.ico
path_beg <string>
當 path 以某個 string 為起始，返回 true；可用於發送某些目錄名到 alternative backend；
path_dir <string>
當 path 中包含以 / 分隔的 string 時，返回 true；可用於匹配文件名或目錄名；
path_dom <string>
當 path 中包含以 . 分隔的 string 時，返回 true；可用於域名匹配；
path_end <string>
當 path 以某個 string 為結束時，返回 true；可用於控制文件擴展名；
path_len <integer>
當 path 的長度與指定值或范圍匹配時，返回 true；可用於檢測 abusive requests；
path_reg <regex>
當 path 與正則表達式匹配時，返回 true；
path_sub <string>
當 path 包含某個 string 時，返回 true；可用於檢測 path 中的指定模式，比如 「../」；
req_ver <string>
用於檢查 HTTP 請求的版本，比如 1.0；
status <integer>
用於檢查 HTTP response 的狀態碼，比如 302；
可根據狀態碼做一定的動作，比如，如果 response 的狀態碼不是 3xx，則刪除 Location header；
url <string>
應用於請求中的整個 URL；真正的用處是匹配 *，已有一個預定義的 ACL： HTTP_URL_STAR；
url_beg <string>
當 URL 以某個 string 起始時，返回 true；可用於檢查是否以 / 或者某個協議的 scheme 起始；
url_dir <string>
如果 URL 中包含以 / 分隔的 string，返回 true；用於文件名和目錄名匹配；
url_dom <string>
如果 URL 中包含以 . 分隔的 string，返回 true；用於域名匹配；
url_end <string>
當 URL 以某個 string 結束時，返回 true；用處很少；
url_ip <ip_address>
用於檢查 HTTP 請求中，絕對 URI 中所指定的 IP 地址；可用於根據 IP 地址做資源的訪問限制；
跟 http_proxy 一起用時可發揮作用；
url_len <integer>
當 URL 的長度與指定值或范圍匹配時，返回 true；可用於檢測 abusive requests；
url_port <integer>
用於檢查 HTTP 請求中，絕對 URI 中所指定的 PORT 地址；可用於根據 PORT 地址做資源的訪問限制；
跟 http_proxy 一起用時可發揮作用；
注意，如果請求中沒有指定埠，則表示埠為 80；
url_reg <regex>
當 URL 與正則表達式匹配時，返回 true；
url_sub <string>
當 URL 包含某個 string 時，返回 true；可用於檢查 query string 中的某些 pattern；
預定義的 ACLs 不需要聲明，可以直接使用。它們的命名都是大寫字母。
有些 actions 只在滿足了有效的條件時才能執行；條件是 ACLs 的邏輯組合；
有三個可用的邏輯運算符：
一個條件的構成：
actions 配合條件：
例如，構造一個條件，希望阻擋滿足條件 HTTP 請求，滿足如下條件之一時，拒絕該請求：
規則是：
例2.
建立 url_static 測試，當 path 以 /static、/images、/img、/css 起始，或者以 .gif、.png、.jpg、.css、.js 結尾，返回 true；
建立 host_www 測試，當請求的 Host 首部欄位以 www 起始，返回 true，忽略大小寫；
建立 host_static 測試，當請求的 Host 首部欄位以 img. video. download. ftp. 之一為起始，返回 true，忽略大小寫；
滿足 host_static 測試，或者 host_www AND url_static 測試的請求，轉發給 static backend；
只滿足 host_www 測試的請求，轉發 www backend；
HAProxy 支持使用匿名的 ACLs；不需要事先聲明；它們必須被 { ACLs } 括起來，注意空格；例如：
一般而言，不建議使用匿名的 ACL，因為更容易出現錯誤；
只有對於簡單 ACLs，比如匹配一個 src IP地址，這時使用匿名更容易閱讀：
The stickiness features relies on pattern extraction in the request and
response. Sometimes the data needs to be converted first before being stored,
for instance converted from ASCII to IP or upper case to lower case.
All these operations of data extraction and conversion are defined as
"pattern extraction rules". A pattern rule always has the same format. It
begins with a single pattern fetch word, potentially followed by a list of
arguments within parenthesis then an optional list of transformations. As
much as possible, the pattern fetch functions use the same name as their
equivalent used in ACLs.
The list of currently supported pattern fetch functions is the following :
src This is the source IPv4 address of the client of the session.
It is of type IP and only works with such tables.
dst This is the destination IPv4 address of the session on the
client side, which is the address the client connected to.
It can be useful when running in transparent mode. It is of
type IP and only works with such tables.
dst_port This is the destination TCP port of the session on the client
side, which is the port the client connected to. This might be
used when running in transparent mode or when assigning dynamic
ports to some clients for a whole application session. It is of
type integer and only works with such tables.
hdr(name) This extracts the last occurrence of header <name> in an HTTP
request and converts it to an IP address. This IP address is
then used to match the table. A typical use is with the
x-forwarded-for header.
The currently available list of transformations include :
lower Convert a string pattern to lower case. This can only be placed
after a string pattern fetch function or after a conversion
function returning a string type. The result is of type string.
upper Convert a string pattern to upper case. This can only be placed
after a string pattern fetch function or after a conversion
function returning a string type. The result is of type string.
ipmask(mask) Apply a mask to an IPv4 address, and use the result for lookups
and storage. This can be used to make all hosts within a
certain mask to share the same table entries and as such use
the same server. The mask can be passed in dotted form (eg:
255.255.255.0) or in CIDR form (eg: 24).
② 四層負載均衡和七層負載均衡的區別
負載均衡四層和七層主要是根據網路的結構來的。一般來說，四層主坦滑攜要是網路層，也就是TCP和UDP的負載均衡（主要是TCP的）。七層是應用層，主要是指HTTP、FTP、HTTPS等的負載均衡。
四層負載均衡的典型軟體如LVS，七層負載均衡讓伏的比較典讓困型軟體如haproxy，nginx等。
③ 運維和DBA具體有什麼區別呀
有區別。
1.DBA是面向資料庫的（資料庫管理員，或者資料庫架構師），專門搞資料庫方面的。
比如搭建資料庫架構，優化表、存儲過程、等等這些的性能，會細化到某個語句或者節點上
2.影響資料庫性能檢測和日常維護
3.資料庫安全性，尤其是注入攻擊，死鎖這些，DBA必須都得會
4.資料庫熱備，還原，資料庫遷移
5.mysql，sqlserver。。。一大堆資料庫的研究部署工作
DBA是個細化具體的職業，在中國的大企業很牛逼，小企業不重視，一般企業也用不到，對技術的要求非常高，他們一般都是讓程序員或者運維去搞定資料庫的事情，不願意花錢養一個DBA。。。
運維。。。（面向「大中小型企業」的全能「人才」，我說的是廣義的「運維「）
資料庫日常監測和維護
linux，windows伺服器監測和維護，包括熱備，故障處理，磁碟陣列，性能調優，負載均衡等等。。。。。。
部署網站，應用
Nginx、Tomcat、LVS、Keepalived、Haproxy安裝、配置、維護及調優。。等等一大堆
要精通Linux系統如centos、ubuntu精通Apache、Redis、MySQL、FTP、DNS、Squid等常用服務的安裝、配置和維護
網路維護，網路設備故障檢修
打雜，修燈泡，修Pc，通廁所
陪老闆喝酒。。。。。。
等等
運維和DBA都挺偉大的，運維在中國的中小企業已經完全淪為打雜的職業，敲得了代碼，修得通網路，弄的了伺服器，搞的了電腦。。。雜碎事一大堆。
大企業運維就很專業了，泡在機房裡面，一般只是和伺服器，資料庫相關的打交道，及時處理故障，沒有小企業那種亂七八糟的事情
真正的運維和中國中小企業的傳統運維完全不是一碼事，這個職業在中國已經被垃圾的互聯網公司損毀了
④ Haproxy實現web的頁面的動靜分離
一、Haproxy概述；
概述：Haproxy是一個開源的高性能的反向代理或者說是負載均衡服務軟體之一，由C語言編寫而成，支持會話保持、七層處理、健康檢查、故障修復後自動載入、動靜分離。HAProxy運行在當前的硬體上，完全可以支持數以萬計的並發連接；
Haproxy軟體引入了frontend，backend的功能，frontend（acl規則匹配）可以運維管理人員根據任意HTTP請求頭做規則匹配，然後把請求定向到相關的backend（server pools等待前端把請求轉過來的伺服器組）。
二、Haproxy原理實現；
代理模式：
1.四層tcp代理：例如：可用於郵件服務內部協議通信伺服器、Mysql服務等；
2.七層應用代理：例如：HTTP代理或https代理。在4層tcp代理模式下，Haproxy僅在客戶端和伺服器之間雙向轉發流量。但是在7層模式下Haproxy會分旁棚遲析應用層協議，並且能通過運行、拒絕、交換、增加、修改或者刪除請求（request）或者回應（reponse）里指定內容來控制協議。
四層代理：
ISO參考模型中的第四層傳輸層。四層負載均衡也稱為四層交換機，它主要是通過分析IP層及TCP/UDP層的流量實現的基於IP加埠的負載均衡。常見的基於四層的負載均衡器有LVS、F5等。以常見的TCP應用為例，負載均衡器在接收到第一個來自客戶端的SYN請求時，會通過設定的負載均衡演算法選擇一個最佳的後端伺服器，同時將報文中目標IP地址修改為後端伺服器IP，然後直接轉發給該後端伺服器，這樣一個負載均衡請求就完成了。從這個過程來看，一個TCP連接是客戶端和伺服器直接建立的，而負載均衡器只不過完成了一個類似路由器的轉發動作。在某些負載和賀均衡策略中，為保證後端伺服器返回的報文可以正確傳遞給負載均衡器，在轉發報文的同時可能還會對報文原來的源地址進行修改。整個過程下圖所示。
七層代理：
ISO參考模型中的最高層第七層應用層。七層負載均衡也稱為七層交換機，此時負載均衡器支持多種應用協議，常見的有HTTP、FTP、SMTP等。七層負載均衡器可以根據報文內容，再配合負載均衡演算法來選擇後端伺服器，因此也稱為「內容交換器」。比如，對於Web伺服器的負載均衡，七層負載均衡器不但可以根據「IP+埠」的方式進行負載分流，還可以根據網站的URL、訪問域名、瀏覽器類別、語言等決定負載均衡的策略。例如，有兩台Web伺服器分別對應中英文兩個網站，兩個域名分別是A、B，要實現訪問A域名時進入中文網站，訪問B域名時進入英文網站，這在四層負載均衡器中幾乎是無法實現的，而七層負載均衡可以根據客戶端訪問域名的不同選擇對應的網頁進行負載均衡處理。常見的七層負載均衡器有HAproxy、Nginx等。
這里仍以常見的TCP應用為例，由於負載均衡器要獲取到報文的內容，因此只能先代替後端伺服器和客戶端建立連接，接著，才能收到客戶端發送過運李來的報文內容，然後再根據該報文中特定欄位加上負載均衡器中設置的負載均衡演算法來決定最終選擇的內部伺服器。縱觀整個過程，七層負載均衡器在這種情況下類似於一個代理伺服器。整個過程如下圖所示。
三、常見的代理了解
1、lvs和硬體F5，是基於IP的三層負載，硬體適配性能好，處理性能強。
2、haproxy，可以適配三層負載均衡，同樣可以適配七層。對於頁面明確有請求分離的時候，可以使用haproxy。
3、nginx，對於日PV小於500萬，對於需要進行高並發的站點，可以使用nginx代理
四、haproxy配置文件講解
五、案例：Haproxy+Nginx+Tomcat搭建高可用集群
實例步驟
1、配置tomcat伺服器
2、安裝haproxy
3、配置haproxy服務：
4、測試集群
5、配置haproxy的日誌文件分離（查看haproxy日誌）
6、配置haproxy伺服器的日誌管理web界面
測試
看到以上界面實驗就做完了
END
⑤ 哪項不是常用的負載均衡技術
四層負責均衡：主要是指通過判斷報文的IP地址和埠並通過一定的負載均衡演算法來決定轉發到哪個指定目標，主要工作在OSI模型的第四層。四層負載均衡對數據包只是起一個數據轉發的作用，並不會干預客戶端與伺服器之間應用層的通信（如：三次握手等）。所以能對數據所進行的操作也就很少，但相對於七層負載均衡來講效率會高上很多七層負載均衡：也被稱為「內容交換」，指的是負載均衡設備通過報文中的應用層信息(URL、HTTP頭部等信息)和負載均衡演算法，選擇到達目的的內部伺服器。七層負載均衡可以「智能化」地篩選報文中 應用層信息，然後根據不同的信息進行特定的負載均衡調度。這種方式提升了應用系統在網路層上的靈活性，另外也在一定程度上提升了後端系統的安全性。因為像網路常見的DoS攻擊，這些攻擊在七層負載均衡的環境下通常都在負載均衡設備上就截止了，不會影響到後台伺服器的正常運行。前網路中常見的負載均衡主要分為硬體負載均衡和軟體負載均衡。硬體負載均衡比較知名的產品有F5 Big-IP、Cirtix Netscaler等等。而軟體負載均衡就有著眾多的開源項目，常見的有Haproxy、nginx、lvs等。Haproxy：lvs:nginx:Haproxy可以做代理服務相對於nginx而言有很多相同之處，統一可以基於mode tcp進行四層代理也可以基於mode http進行七層代理，但不同的是其無法使用location和if等進行匹配判斷。突出優勢在於有會話綁定，web管理界面銀汪，狀態統計非常詳細。官方推薦只啟用一個進程，相對於nginx多進程架構工作並不理想，更多的線程可能會受到系統內存的一些限制。程序環境：主程序：/usr/sbin/haproxy主配置文件：/etc/haproxy/haproxy.cfgUnit file：鋒賀仔/usr/lib/systemd/system/haproxy.service查看配置文件重要的幾個參數，及性能調優，多數無需修改發現日誌發送給本機rsyslog的local2的facility，而本機的rsyslog里並沒有定義，需要我們自己去配置所以vim /etc/rsyslog.conf添加一段將local2的所有信息記錄在對應日誌文件中由於HAProxy可以工作在七層模型下，因此，要實現HAProxy的強大功能，一定要使用強大靈活的ACL規則，通過ACL規則可以實現基於HAProxy的智能負載均衡系統。HAProxy通過ACL規則完成兩種主要的功能，分別是：1）通過設置的ACL規則檢查客戶端請求是否合法。如果符合ACL規則要求，那麼將放行；如果不符合規則，則直接中斷請求。2）符合ACL規則要求的請求將被提交到後端的backend伺服器集群，進而實現基於ACL規則的負載均衡。HAProxy中的ACL規則經常使用在frontend段中，使用方法如下：acl 自定義的acl 名稱 acl 方法 -i [ 匹配的路徑或文件] 其中：·acl：是一個關鍵字，表示定義ACL規則的開始。後面需要跟上自定義的ACL名稱。拍禪·acl方法：這個欄位用來定義實現ACL的方法，HAProxy定義了很多ACL方法，經常使用的方法有hdr_reg（host）、hdr_dom（host）、hdr_beg（host）、url_sub、url_dir、path_beg、path_end等。·-i：表示不區分大小寫，後面需要跟上匹配的路徑或文件或正則表達式。與ACL規則一起使用的HAProxy參數還有use_backend，use_backend後面需要跟上一個backend實例名，表示在滿足ACL規則後去請求哪個backend實例，與use_backend對應的還有default_backend參數，它表示在沒有滿足ACL條件的時候默認使用哪個後端這些例子定義了www_policy、bbs_policy、url_policy三個ACL規則，第一條規則表示如果客戶端以www.z.cn或 z.cn 開頭的域名發送請求時，則此規則返回true，同理第二條規則表示如果客戶端通過 bbs.z.cn 域名發送請求時，則此規則返回true，而第三條規則表示如果客戶端在請求的URL中包含「buy_sid=」字元串時，則此規則返回true。第四、第五、第六條規則定義了當www_policy、bbs_policy、url_policy三個ACL規則返回true時要調度到哪個後端backend，例如，當用戶的請求滿足www_policy規則時，那麼HAProxy會將用戶的請求直接發往名為server_www的後端backend，其他以此類推。而當用戶的請求不滿足任何一個ACL規則時，HAProxy就會把請求發往由default_backend選項指定的server_cache這個後端backend。與上面的例子類似，本例中也定義了url_static、host_www和host_static三個ACL規則，其中，第一條規則通過path_end參數定義了如果客戶端在請求的URL中以.gif、.png、.jpg、.css或.js結尾時返回true，第二條規則通過hdr_beg（host）參數定義了如果客戶端以www開頭的域名發送請求時則返回true，同理，第三條規則也是通過hdr_beg（host）參數定義了如果客戶端以img.、video.、download.或ftp.開頭的域名發送請求時則返回true。第四、第五條規則定義了當滿足ACL規則後要調度到哪個後端backend，例如，當用戶的請求同時滿足host_static規則與url_static規則，或同時滿足host_www和url_static規則時，那麼會將用戶請求直接發往名為static的後端backend，如果用戶請求滿足host_www規則，那麼請求將被調度到名為www的後端backend，如果不滿足所有規則，那麼將用戶請求默認調度到名為server_cache的這個後端backend。log：全局的日誌配置，local0是日誌設備，info表示日誌級別。其中日誌級別有err、warning、info、debug4種可選。這個配置表示使用127.0.0.1上的rsyslog服務中的local0日誌設備，記錄日誌等級為info。maxconn：設定每個HAProxy進程可接受的最大並發連接數，此選項等同於Linux命令行選項「ulimit -n」。user/group：設置運行HAProxy進程的用戶和組，也可使用用戶和組的uid和gid值來替代。daemon：設置HAProxy進程進入後台運行。這是推薦的運行模式。nbproc：設置HAProxy啟動時可創建的進程數，此參數要求將HAProxy運行模式設置為daemon，默認只啟動一個進程。該值的設置應該小於伺服器的CPU核數。創建多個進程，能夠減少每個進程的任務隊列，但是過多的進程可能會導致進程崩潰。pidfile：指定HAProxy進程的pid文件。啟動進程的用戶必須有訪問此文件的許可權。mode：設置HAProxy實例默認的運行模式，有tcp、http、health三個可選值。retries：設置連接後端伺服器的失敗重試次數，如果連接失敗的次數超過這里設置的值，HAProxy會將對應的後端伺服器標記為不可用。此參數也可在後面部分進行設置。timeout connect：設置成功連接到一台伺服器的最長等待時間，默認單位是毫秒，但也可以使用其他的時間單位後綴。timeout client：設置連接客戶端發送數據時最長等待時間，默認單位是毫秒，也可以使用其他的時間單位後綴。timeout server：設置伺服器端回應客戶端數據發送的最長等待時間，默認單位是毫秒，也可以使用其他的時間單位後綴。timeout check：設置對後端伺服器的檢測超時時間，默認單位是毫秒，也可以使用其他的時間單位後綴。bind：此選項只能在frontend和listen部分進行定義，用於定義一個或幾個監聽的套接字。bind的使用格式為： bind [<address>:<port_range>] interface <interface>其可以為主機名或IP地址，如果將其設置為「*」或「0.0.0.0」，將監聽當前系統的所有IPv4地址。port_range可以是一個特定的TCP埠，也可是一個埠范圍，小於1024的埠需要有特定許可權的用戶才能使用。interface為可選選項，用來指定網路介面的名稱，只能在Linux系統上使用。option httplog：在默認情況下，HAProxy日誌是不記錄HTTP請求的，這樣很不方便HAProxy問題的排查與監控。通過此選項可以啟用日誌記錄HTTP請求。option forwardfor：如果後端伺服器需要獲得客戶端的真實IP，就需要配置此參數。由於HAProxy工作於反向代理模式，因此發往後端真實伺服器的請求中的客戶端IP均為HAProxy主機的IP，而非真正訪問客戶端的地址，這就導致真實伺服器端無法記錄客戶端真正請求來源的IP，而X-Forwarded-For則可用於解決此問題。通過使用forwardfor選項，HAProxy就可以向每個發往後端真實伺服器的請求添加X-Forwarded-For記錄，這樣後端真實伺服器日誌可以通過「X-Forwarded-For」信息來記錄客戶端來源IP。option httpclose：此選項表示在客戶端和伺服器端完成一次連接請求後，HAProxy將主動關閉此TCP連接。這是對性能非常有幫助的一個參數。log global：表示使用全局的日誌配置，這里的global表示引用在HAProxy配置文件global部分中定義的log選項配置格式。default_backend：指定默認的後端伺服器池，也就是指定一組後端真實伺服器，而這些真實伺服器組將在backend段進行定義。這里的htmpool就是一個後端伺服器組。option redispatch：此參數用於cookie保持的環境中。在默認情況下，HAProxy會將其請求的後端伺服器的serverID插入cookie中，以保證會話的session持久性。而如果後端的伺服器出現故障，客戶端的cookie是不會刷新的，這就會出現問題。此時，如果設置此參數，就會將客戶的請求強制定向到另外一台健康的後端伺服器上，以保證服務正常。option abortonclose：如果設置了此參數，可以在伺服器負載很高的情況下，自動結束當前隊列中處理時間比較長的連接。-balance：此關鍵字用來定義負載均衡演算法。目前HAProxy支持多種負載均衡演算法，常用的有如下幾種：cookie：表示允許向cookie插入SERVERID，每台伺服器的SERVERID可在下面的server關鍵字中使用cookie關鍵字定義。option httpchk：此選項表示啟用HTTP的服務狀態檢測功能。HAProxy作為一個專業的負載均衡器，它支持對backend部分指定的後端服務節點的健康檢查，以保證在後端backend中某個節點不能服務時，把從frotend端進來的客戶端請求分配至backend中其他健康節點上，從而保證整體服務的可用性。option httpchk的用法如下： option httpchk <method> <uri> <version> 其中，各個參數的含義如下：check：表示啟用對此後端伺服器執行健康狀態檢查。inter：設置健康狀態檢查的時間間隔，單位為毫秒。rise：設置從故障狀態轉換至正常狀態需要成功檢查的次數，例如，「rise 2」表示2次檢查正確就認為此伺服器可用。fall：設置後端伺服器從正常狀態轉換為不可用狀態需要檢查的次數，例如，「fall 3」表示3次檢查失敗就認為此伺服器不可用。cookie：為指定的後端伺服器設定cookie值，此處指定的值將在請求入站時被檢查，第一次為此值挑選的後端伺服器將在後續的請求中一直被選中，其目的在於實現持久連接的功能。上面的「cookie server1」表示web1的serverid為server1。同理，「cookie server2」表示web2的serverid為server2。weight：設置後端真實伺服器的權重，默認為1，最大值為256。設置為0表示不參與負載均衡。backup：設置後端真實伺服器的備份伺服器，僅僅在後端所有真實伺服器均不可用的情況下才啟用。用nginx反代後端的兩台tomcat主機，做動靜分離，如果是jsp結尾的就發往後端，否則就交給nginx處理。在兩台tomcat主機上創建應用nginx配置則動靜分離就實現了，並且我們還基於uri實現了會話粘性
⑥ 黑馬程序員Linux運維培訓怎麼樣
1、什麼是運維工程師？
運維工程師，伺服器與系統安全穩定的掌舵者！當一個產品（如Web網站、APP軟體、網路游戲等）正式上線後，產品、開發、測試類的工作就正式結束了，接下來的維護和管理工作就會全部移交給運維工程師。
運維工程師的主要工作職責就是負責伺服器的架構設計以及雲計算平台管理，保障軟體的穩定運行。沒有開發以及測試類工作復雜且工作解決方案相對固定。更重要的是沒有年齡以及學歷的限制，隨著工作年限和工作經驗地增長，也會越老越吃香。
2、運維工程師工作場景
運維學科2019全年所有班級就業率93.5%，平均薪資8.7k起，最高薪資25k* 14薪
三、運維課程
1、第一階段：Linux運維基礎功
運維基礎：運維發展史、計算機概述、計算機組成、操作系統學完此階段可掌握的核心能力：熟練掌握Linux操作系統的安裝(CentOS7.6)、配置、基礎命令、VIM編輯器、用戶管理、許可權管理、自有服務、進程檢測與控制、阿里雲平台管理、開源CMS項目上線部署實戰。
Linux操作系統：Linux系統概述、虛擬機、CentOS7.6系統安裝，Linux基礎命令
Linux下文件管理（上）：文件命名規則、目錄管理、文件管理、文件復制與剪切、重命名、Linux文件打包與壓縮、文件處理命令
Linux下文件管理（下）：VIM編輯器介紹、VI與VIM的區別、VIM安裝與配置、四種工作模式（命令模式，編輯模式，末行模式，可視化模式）、相關VIM指令、VIM擴展功能、VIM總結
Linux下用戶管理：用戶和組的相關概念、用戶組管理、用戶管理、用戶密碼設置、切換用戶、Linux用戶管理實戰
Linux下許可權管理：許可權的基本概念、許可權在生產環境中的作用、Linux許可權類別（rwx）、Linux文件所有者類別（ugo）、普通許可權設置（字母+數字）、文件屬主與屬組設置、高級許可權、ACL許可權控制、umask
Linux下自有服務+軟體包管理：自由服務概述、systemctl管理服務命令、ntp時間同步服務、firewalld防火牆、crond計劃任務、設備掛載與解掛、rpm包管理工具
Linux進程檢測與控制：進程與程序的概念、進程管理命令（top命令，free命令，df命令，ps命令，netstat命令，kill命令與killall命令）、進程優先順序設置
阿里雲平台管理與開發CMS項目上線部署實戰：雲計算平台概述、阿里雲平台注冊、登錄與管理、項目背景、LAMP環境概述、YUM指令、LAMP環境搭建、開源CMS項目上線部署實戰
學完此階段可解決的現實問題：能夠根據企業實際項目需求實現伺服器部署與架構。
學完此階段可擁有的市場價值：熟練掌握之後，可以滿足市場對初級運維工程師的需求，但是市場就業工資相對較低，還是建議繼續學習就業班課程。
2、第二階段：Linux系統服務篇
Linux高級指令：基礎命令回顧、find命令之高級搜索、tree命令、scp文件上傳與下載、計劃任務crontab + tar實現定時備份、用戶管理高級、文件許可權管理高級
Linux下軟體包管理：軟體包管理任務背景、Linux下軟體包概述、RPM包管理工具、YUM包管理工具、YUM源配置（公網YUM源，本地YUM源、自建YUM源倉庫）、源碼安裝概述、源碼安裝三步走、源碼安裝實戰
Linux遠程管理服務SSH：SSH任務背景、SSH服務概述，yum源配置，SSH服務安裝與配置實戰，公私鑰概念，SSH免密碼登錄
Linux數據同步RSYNC：RSYNC任務背景、RSYNC介紹、RSYNC基本語法、本機同步與遠程同步、把RSYNC作為系統服務、RSYNC結合INOTIFY實現實時同步、RSYNC託管XINETD
Linux下文件共享服務FTP、NFS、SAMBA：文件共享任務背景、FTP服務介紹、FTP工作模式（主動模式+被動模式）、FTP服務搭建、客戶端工具（ftp、lftp使用）、FTP訪問控制、NFS服務介紹、NFS服務搭建、配置文件詳解、NFS任務背景及解決方案、SAMBA服務介紹、SAMBA服務搭建、配置文件詳解、文件共享服務總結
DNS域名管理服務：DNS服務介紹、DNS的作用、DNS服務搭建、正向解析、反向解析、多域搭建、NTP時間伺服器、主從DNS架構
源碼構建LAMP環境及部署業務應用：LAMP任務背景、Web伺服器環境准備、軟體編譯回顧、編譯安裝MySQL、編譯安裝Apache、編譯安裝PHP、後期配置、Web應用系統部署實戰
Linux下日誌管理服務RSYSLOG：日誌管理任務背景、查看日誌、日誌管理服務（RSYSLOG概述，日誌列表，日誌級別，相關符號，配置文件）、RSYSLOG本地日誌管理、RSYSLOG遠程日誌管理、日誌管理應用實踐
Linux 磁碟管理：磁碟管理任務背景、磁碟管理概述、fdisk命令詳解、Linux分區概述、Linux分區實戰、邏輯卷介紹、邏輯卷基本概念（PV、VG、PE、LV）、邏輯卷LVM應用操作實戰、RAID介紹、RAID常見級別、軟硬RAID、軟RAID應用實踐
Shell腳本編程：Shell概述、變數、Shell流程式控制制、Shell數組、Shell函數、Shell特殊用法、正則表達式、Shell編程實戰
資料庫DBA：MySQL概述，MySQL5.7安裝，MySQL配置，MySQL基本操作、SQL語句詳解、MySQL索引、MySQL備份與還原、MySQL主從復制、MHA高可用架構、MySQL企業級應用實戰
學完此階段課掌握的核心能力：
1、了解Linux系統運行原理，實現Linux伺服器的維護與管理；
2、了解Linux系統相關服務，能根據企業需求實現企業運維工作。
學完此階段可解決的現實問題：能實現企業Linux伺服器的日常維護與管理，搭建SSH、文件共享、DNS、Apache等服務、能獨立完成系統日誌分析、Shell腳本編程、資料庫DBA等相關工作。
學完此階段可擁有的市場價值：熟練學習和掌握後，可滿足企業運維的初中級需求。
3、第三階段：千萬級商城系統架構設計
源碼構建企業級LNMP架構及電商系統上線部署：千萬級商城系統架構設計任務背景、Web項目開發流程、Linux伺服器環境准備、LNMP環境概述、MySQL資料庫服務搭建、Nginx軟體服務搭建、PHP軟體服務搭建、Web商城項目部署上線
大型WEB服務軟體Nginx部署介紹使用：Nginx軟體概述、Nginx平滑升級、nginx.conf配置文件詳解、虛擬主機配置、Nginx默認官方模塊詳解（GZIP壓縮，客戶端緩存，反向代理，基於IP/用戶的訪問控制，目錄顯示）、日誌管理、日誌輪轉、第三方日誌管理軟體GoAccess、Location區塊、URL重寫、第三方模塊安裝與配置、Nginx安全管理、Nginx其他衍生版本（Tengine，OpenResty）
WEB高可用集群架構設計及實現（keepalived）：WEB高可用集群架構設計任務背景、單點資料庫遷移、HA高可用集群概述、Keepalived軟體介紹、Keepalived組成和原理、VRRP協議、安裝與配置Keepalived、Nginx服務高可用實踐、Keepalived擴展內容（非搶占模式、VIP腦裂、單播模式）
WEB負載均衡伺服器集群架構設計及實現LB(Nginx/LVS/HAProxy)：WEB負載均衡伺服器集群架構設計任務背景、為什麼需要LB負載均衡技術、LB負載均衡架構圖、負載均衡分類、常見負載均衡實現方式、LB負載均衡環境准備、Nginx負載均衡實現、負載均衡演算法、Session共享解決方案、高可用負載實踐; LVS概述、LVS工作原理、LVS核心組件、LVS三種工作模式（NAT模式、DR模式、TUN隧道模式）、LVS/NAT原理和特點、LVS/DR原理和特點、LVS/TUN原理和特點、LVS的十種調度演算法、LVS/NAT模式部署實踐、LVS/DR模式部署實踐; HAProxy概述、HAProxy安裝與部署、haproxy.cfg配置文件詳解、常見問題分析、HAProxy調度演算法、HAProxy負載均衡應用實踐
MyCAT讀寫分離：MySQL讀寫分離任務背景、讀寫分離的目的、讀寫分離常見的實現方式、搭建M-S主從復制、代碼實現讀寫分離、MyCAT實現讀寫分離實戰（JDK配置、MyCAT配置文件詳解、讀寫分離實踐、高可用實踐、分庫分表、MyCAT企業級案例實踐）
非關系型資料庫NoSQL(Memcache/Redis/MongoDB)：非關系型資料庫任務背景、Web項目訪問流程、優化方案、緩存技術引入、memcached介紹、memcached安裝與部署、telnet客戶端使用、memcached指令詳解、memcached tools工具使用、LRU失效機制、PHP memcached擴展安裝、Session入memcached、緩存項目的熱點數據; Redis介紹、Redis應用場景、Redis源碼安裝、客戶端工具使用、Redis數據結構詳解、數據持久化操作（快照+AOF）、企業級案例（主從，安全限制，PHP Redis擴展，Session入Redis）;MongoDB任務背景、MongoDB安裝和配置、數據結構類型操作CURD、MongoDB安全設置、PHP擴展、桌面管理軟體、企業級日誌統計實踐
JAVA項目架構設計實戰（LNTM架構）：Java項目任務背景、Tomcat概述、Tomcat安裝與部署、Tomcat企業級管理、Host虛擬主機配置、Server Status伺服器狀態、應用管理、Nginx動靜分離、Nginx+Tomcat負載均衡、Maven概述、Maven項目打包、Maven項目部署
存儲（NAS/SAN/GlusterFS/Ceph)：存儲概述、Linux存儲分層、存儲的分類（DAS，NAS，SAN）、存儲類型的分類（文件存儲、塊存儲、對象存儲）、SAN的分類、IP-SAN之iscsi實現; 分布式存儲、Glusterfs介紹、raid級別回顧、常見卷的模式、Glusterfs集群、環境准備、集群部署、創建glusterfs存儲卷、客戶端使用、卷的刪除、常見卷類型（stripe模式、distributed模式、distributed-replica模式、dispersed模式、distributed-dispersed模式）、其它卷類型、glusterfs分部署存儲應用實戰; 認識Ceph、Ceph架構原理圖、Ceph集群、Ceph集群組件、Ceph集群環境准備、Ceph集群部署實踐、RADOS原生數據存取、Ceph文件存儲、Ceph塊存儲、Ceph對象存儲、Ceph對象存儲+owncloud打造雲盤系統、Ceph Dashboard(拓展)
配置自動化（Ansible/SaltStack）：自動化運維任務背景、認識ansible、ansible安裝與配置、伺服器分組、ansible模塊（hostname模塊，file模塊，模塊，yum模塊，service模塊，command和shell模塊，scriYAML格式pt模塊）、playbook介紹、playbook實例、playbook編排應用、roles介紹、roles的目錄結構、roles應用案例; saltstack介紹、saltstack安裝與配置、saltstack遠程執行命令、grains、pillar、配置管理文件、配置管理目錄、配置管理命令、配置管理計劃任務、其他命令、salt-ssh使用
企業級監控平台（Zabbix/Prometheus）：企業級監控任務背景、監控的目的、主流的開源監控平台、Zabbix概述、Zabbix伺服器安裝、Zabbix監控本機與遠程主機、模板、監控項與應用集、圖形、觸發器、報警、Zabbix代理、主動監控與被動監控、Zabbix應用部署實戰; 認識Prometheus、Prometheus原理架構圖、Prometheus監控安裝部署、Prometheus監控遠程主機、遠程MySQL、Grafana介紹、Grafana安裝與登錄、Prometheus結合Grafana實現Linux系統監控、CPU監控、MySQL監控等等、Grafana報警系統實踐
企業級日誌分析（ELK/Kafka)：ELK任務背景、ELK概述、elasticsearch部署、elasticsearch基礎概念、elaticsearch基礎API操作、ES查詢語句、elasticsearch-head、logstash簡介、logstash部署、日誌採集、採集messages日誌、採集多日誌源、kibana介紹、kibana部署、kibana漢化、通過kibana查看集群信息、通過kibana查看logstash收集的日誌索引、通過kibana做可視化圖形、filebeat介紹、filebeat收集日誌、filebeat傳輸給logstash、filebeat收集nginx日誌、filebeat日誌過濾
CI/CD（Git、Gitlab、Jenkins）：CI/CD任務背景、版本控制概念、Git安裝、Git身份設置、Git創建本地倉庫、Git暫存區、Git版本控制、Git分支管理、擴展：Windows版Git; Github概述、GitHub注冊、創建項目、遠程倉庫、免密push、分支、多人協作; GitLab介紹、GitLab下載、安裝與配置、GitLab配置、倉庫管理、持續集成（CI）、持續交付（CD）、藍綠部署、滾動更新、灰度發布
運維安全（SSL與CA認證/防火牆/ VPN/JumpServer與Teleport跳板機）：運維安全任務背景、運維安全概述、硬碟分區加密（擴展）、對稱加密、非對稱加密、數字簽名、SSL與CA認證、SSL介紹、CA認證介紹、https應用實踐; 防火牆概述、iptables的應用、iptables防火牆結構、iptables基本語法、iptables四表五鏈、企業級防火牆規則設置、firewalld包過濾、firewalld與iptables的區別、firewalld防火牆規則設置、firewall-config圖形模式; VPN任務背景、隧道介紹、net-to-net隧道通訊、VPN介紹、IPSec協議、libreswan實現net-to-netVPN、三網路VPN互聯、roadwarrior VPN（libreswan實現點對網VPN，openvpn實現點對網vpn，使用pptpd實現VPN），PAM認證，LDAP，開源堡壘機jumpserver，輕量級開源堡壘機teleport(拓展)
學完此階段可掌握的核心能力：
1、 具備Linux伺服器架構設計能力，保證應用架構合理可控；
2、具備監控檢查系統軟硬體運行狀態，保證系統安全穩定運行的能力；
3、具備CI/CD持續集成/持續支付能力；
4、具備配置自動化以及日誌分析能力；
5、具備解決復雜問題和技術難點的能力。
學完此階段可解決的現實問題：
1、掌握Java、PHP伺服器架構能力；
2、能夠獨立搭建企業級高可用伺服器（集群、高可用、負載均衡、緩存、存儲）；
3、掌握阿里雲/華為雲產品實戰；
4、能使用Zabbix/Prometheus搭建企業級監控；
5、能夠熟練掌握CI/CD持續集成/持續支付工具；
6、能夠使用Ansible/SaltStack實現運維自動化；
7、能使用ELK實現企業級日誌分析；
8、能夠掌握常見運維安全防護手段。
學完此階段可擁有的市場價值：熟練掌握和學習後，可滿足Linux運維行業中高級需求。
4、第四階段：Linux雲計算運維
KVM虛擬化：KVM任務背景、計算機工作原理、虛擬化概述與分類、KVM環境准備、KVM安裝、使用KVM安裝虛擬機、KVM基礎管理命令、KVM配置文件、KVM克隆、KVM網路管理、快照、設備管理、存儲池管理、磁碟鏡像管理、虛擬機快速創建腳本
公有雲運維（阿里雲[ECS/RDS/SLB/CDN/OSS/NFS]）：公有雲任務背景、阿里雲概述、VPC專有網路、阿里雲安全組、雲伺服器ECS、自定義鏡像、阿里雲SLB、阿里雲RDS、阿里雲存儲（NAS與OSS）、CDN、域名與域名解析、SSL證書、數據傳輸DTS、雲監控、DDOS高防、容器服務、公有雲企業級案例應用實踐
私有雲運維之OpenStack平台：私有雲任務背景、OpenStack概述、OpenStack組件及其作用（Compute 計算服務、Networking 網路服務、Object Storage 對象存儲、Block Storage 塊存儲服務、Identity 身份認證、Image Service 鏡像服務、Dashboard UI頁面、Metering 測量服務、Orchestration 編排部署、Database Service 雲資料庫）、OpenStack自動部署、OpenStack手工部署、OpenStack雲平台應用實踐
Docker容器技術：Docker容器技術任務背景、PAAS平台介紹、認識容器、Docker介紹、Docker內核技術（NameSpace，Control Group，LXC與docker區別）、Docker環境准備、Docker軟體安裝、Docker Daemon管理、鏡像、容器、倉庫、Docker存儲驅動、Docker應用實踐、Dockerfile概述、使用Dockerfile構建鏡像、單宿主機容器互聯方式、Docker網路、Docker的Web管理平台、Docker三劍客（Docker machine、Docker compose、Docker swarm）、Docker容器應用部署實踐
Kubernetes(K8S)容器編排工具：Kubernetes(K8S)容器編排任務背景、認識容器編排、Kubernetes概述、Kubernetes架構、集群部署方式、Kubeadm部署Kubernetes集群、集群與節點信息、節點標簽、namespace命名空間、工作負載(workloads)、pod概述、pod分類、pod的YAML格式、pod資源限制、pod調度、pod生命周期、pod控制器、service、ingress controller、kubernetes存儲卷、ceph集群部署、ConfigMap、Secret、PV與PVC、API網關 kong、包管理方案 helm2、存儲解決方案 GlusterFS、服務網格 istio、監控解決方案 heapster、應用實踐 gitlab-ce、應用實踐 jenkins、應用實踐 kafka、應用實踐 zookeeper應用實踐 配置中心Apollo
綜合案例：Docker+K8S企業級項目應用實踐
學完此階段可掌握的核心能力：
1、熟練掌握虛擬化技術；
2、掌握公有雲與私有雲架構實戰；
3、熟練使用容器與容器編排工具；
4、熟練掌握企業級雲計算技術應用實踐。
學完此階段可解決的現實問題：
1、能夠使用KVM實現虛擬化；
2、能夠掌握公有雲與私有雲伺服器架構實戰；
3、能夠熟練使用Docker容器；
4、能夠熟練使用Kubernetes（K8S）容器編排工具；
5、能夠熟練掌握Docker+Kubernetes（K8S）項目架構設計
學完此階段可擁有的市場價值：熟練掌握和學習後，可滿足Linux雲計算架構工程師的高級需求。
5、第五階段：Python CMDB運維開發（DevOps）
HTML5：HTML簡介、HTML標簽詳解、字元編碼的奧秘、HTML5新特性與常用標簽
CSS3：CSS簡介、CSS的引入方式、CSS基本選擇器、CSS屬性、盒子模型、CSS浮動、CSS3新特性與常用屬性、CSS應用案例
Bootstrap：Bootstrap環境搭建、全局樣式、網頁排版、表單、圖片及輔助類、網頁布局、Bootstrap組件、CMDB後檯布局實戰
JavaScript/Ajax/jQuery：JavaScript簡介、Javascipt語法基礎、BOM模型、DOM模型、Ajax概述、Ajax中的get與post請求、Ajax案例、jQuery框架概述、jQuery選擇器、jQuery事件、jQuery與Ajax、JavaScript應用實踐
Python基礎：Python概述、Python環境部署、變數、標識符和關鍵字、輸入和輸出、數據類型轉換、條件控制語句和循環語句、容器類型、函數、文件操作
Python高級：面向對象、異常處理、模塊和包、Python與MySQL應用實踐
Django框架：Django框架介紹、Django模型、ORM及資料庫操作、視圖及模板、Django中間件
綜合項目：Python+Django實現CMDB企業自動化運維平台
學完此階段可掌握的核心能力：
1、掌握Web前端開發相關技術如HTML5/CSS3/JavaScript；
2、掌握Python運維相關模塊；
3、掌握Python Django框架；
4、具備一定的Python運維開發能力。
學完此階段可解決的現實問題：
1、具備一定的編程思維，為未來系統架構師鋪路搭橋；
2、能夠熟練掌握Python運維相關模塊實現運維管理；
3、能夠使用Python+Django開發企業自動化運維平台。
學完此階段可擁有的市場價值：熟練掌握和學習後，可滿足Linux運維行業的高級需求。
⑦ 如何查看haproxy是否支持ssl
使用ldd命令查團睜彎看haproxy的依塌悶賴庫
ldd haproxy | grep ssl
如果早凳有類似於libssl.so.10 => /lib64/libssl.so.10 (0x00007fad4d072000)
表示支持
⑧ linux haproxy 重新啟動還需要先停止嗎
要設置http代理：搭扮侍攔設置http_proxy變數名
要設置https代知談灶理：設置https_proxy變數名
要設置ftp代理：設置ftp_proxy變數名
不使用莫個代理：設置no_proxy變數名