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变量名