nginx搭建文件分享 nginx环境搭建

Nginx搭建和配置案例

1.Nginx搭建

1.1 Centos上提前准备的环境

• 关闭防火墙（为了保证端口可以访问）
• 或者是开放指定端口

关闭防火墙命令 $ systemctl stop firewalld
开放指定端口   $ firewalld-cmd --add-port=8088/tcp --permanent
查看开放的端口 $ firewalld-cmd --list-ports

• 安装(需要准备编译和安装的环境)
• 主要是c环境

一. gcc 安装
安装 nginx 需要先将官网下载的源码进行编译，编译依赖 gcc 环境，如果没有 gcc 环境，则需要安装：

$ yum install -y gcc-c++

二. PCRE pcre-devel 安装
PCRE(Perl Compatible Regular Expressions) 是一个Perl库，包括 perl 兼容的正则表达式库。nginx 的 http 模块使用 pcre 来解析正则表达式，所以需要在 linux 上安装 pcre 库，pcre-devel 是使用 pcre 开发的一个二次开发库。nginx也需要此库。命令：

$ yum install -y pcre pcre-devel

三. zlib 安装
zlib 库提供了很多种压缩和解压缩的方式， nginx 使用 zlib 对 http 包的内容进行 gzip ，所以需要在 Centos 上安装 zlib 库。

$ yum install -y zlib zlib-devel

四. OpenSSL 安装
OpenSSL 是一个强大的安全套接字层密码库，囊括主要的密码算法、常用的密钥和证书封装管理功能及 SSL 协议，并提供丰富的应用程序供测试或其它目的使用。
nginx 不仅支持 http 协议，还支持 https（即在ssl协议上传输http），所以需要在 Centos 安装 OpenSSL 库。

$ yum install -y openssl openssl-devel

1.2 解压安装Nginx

• 解压(直接解压到当前目录下即可)

$ tar -zxvf nginx-1.18.0.tar.gz

• 配置(首先进入到解压目录中)

$ cd nginx-1.18.0
$ ./configure

• 编译安装（同样是在解压目录下）
• 安装完成之后在/usr/local/下会生成 nginx目录，这就是安装的目录

$ make
$ make install

1.3 启动验证Nginx安装成功

• 进入到nginx安装目录下 /usr/local/nginx/sbin
• 执行 ./nginx 命令启动

$ cd /usr/local/nginx/sbin
$ ./nginx

• 浏览器访问目标主机ip验证nginx启动成功

2.Nginx常用的命令

• 启动

$ cd /usr/local/nginx/sbin
$ ./nginx

• 停止

$ cd /usr/local/nginx/sbin
$ ./nginx -s stop 此方式相当于先查出nginx进程id再使用kill命令强制杀掉进程。
$ ./nginx -s quit 此方式停止步骤是待nginx进程处理任务完毕进行停止。

• 重启
• 当 ngin x的配置文件 nginx.conf 修改后，要想让配置生效需要重启 nginx，使用-s reload不用先停止 nginx再启动 nginx 即可将配置信息在 nginx 中生效

$ cd /usr/local/nginx/sbin
$ ./nginx -s reload

3.案例一：反向代理

3.1 需求描述

1. 本地浏览器访问 www.123.com
2. 通过nginx的反向代理，实现对服务端的tomcat8081的访问

3.2 流程图

开始

浏览器访问www.123.com

nginx代理到tomcat8081

响应8081界面

结束

3.3 配置文件修改

• 修改本地host文件，可以解析 www.123.com域名
• host文件位置 ： C:\Windows\System32\drivers\etc\host

文件中添加如下内容：
192.168.152.136     www.123.com

• 修改nginx配置文件，配置代理
• 配置文件位置 ： /usr/local/nginx/conf/nginx.conf
• 修改完成后，重启nginx

3.4 访问测试

• 本地浏览器访问 www.123.com
• 结果为 tomcat8081 的界面

4.案例二：反向代理

4.1 需求描述

• 访问http://192.168.152.136:9001/edu/ 跳转到 http://192.168.152.136:8081
• 访问http://192.168.152.136:9001/vod/ 跳转到 http://192.168.152.136:8082

4.2 流程图

开始

访问http://192.168.152.136:9001/edu/a.html

响应8081

结束

访问http://192.168.152.136:9001/vod/a.html

响应8082

4.3 准备两个html

• tomcat8081 的webapps 下新建 /edu/a.html

<h1>I am 8081</h1>

• tomcat8082 的webapps 下新建 /vod/a.html

<h1>I am 8082</h1>

4.4 配置文件修改与proxy_pass（*）

• 修改配置文件，进行代理配置
• 修改完成后重新启动nginx
• location指令说明：

• 该指令用于匹配URL。
• 语法如下 ：

location [= | ~ | ~* | ^~] uri { ...... } 1. = : 用于不含正则表达式的uri前，要求请求字符串与uri严格匹配，如果匹配成功，就停止向下搜索并立即处理该请求。 2. ~ : 用于表示 uri 包含正则表达式，并且区分大小写。【!~ : 区分大小写不匹配。】 3. ~* : 用于表示 uri 包含正则表达式，并且不区分大小写。【!~* : 不区分大小写不匹配。】 4. ^~ : 用于不含正则表达式的 uri 前，要求nginx服务器找到标识uri和请求字符串匹配度最高的location后，立即使用此location处理请求，而不再使用location块中的正则uri和请求字符串做匹配。（ 如果把这个前缀用于一个常规字符串,那么告诉nginx 如果路径匹配那么不测试正则表达式。）

• proxy_pass 详解：
  在nginx中配置proxy_pass代理转发时，如果在proxy_pass后面的url加/，表示绝对根路径，把匹配的路径给代理走；
  如果没有/，表示相对路径，不会把匹配的路径部分也给代理走。
• 假设下面四种情况分别用 http://192.168.1.1/proxy/test.html 进行访问。

第一种：
location /proxy/ {
proxy_pass http://127.0.0.1/;
}
代理到URL：http://127.0.0.1/test.html

第二种（相对于第一种，最后少一个 / ）
location /proxy/ {
proxy_pass http://127.0.0.1;
}
代理到URL：http://127.0.0.1/proxy/test.html

第三种：
location /proxy/ {
proxy_pass http://127.0.0.1/aaa/;
}
代理到URL：http://127.0.0.1/aaa/test.html

第四种（相对于第三种，最后少一个 / ）
location /proxy/ {
proxy_pass http://127.0.0.1/aaa;
}
代理到URL：http://127.0.0.1/aaatest.html

【第四种没有错误，就是这样拼接起来的！】

4.5 访问测试

• 本地浏览器访问 http://192.168.152.136:9001/edu/
• 本地浏览器访问 http://192.168.152.136:9001/vod/

|

|

5.案例三：负载均衡

5.1 需求描述

• 两台tomcat服务器 ： 192.168.152.136：8081 和 192.168.152.136：8082
• 本地访问 192.168.152.136:80
• 第一次访问 8081；第二次访问8082

5.2 流程图

开始

浏览器访问192.18.152.136:80

响应8081

结束

响应8082

5.3 配置文件修改

• 配置upstream，要负载的服务端
• 此配置的位置 ： 在http块中，与server块同级

• 配置server ，添加代理

5.4 访问测试

第一次访问	第二次访问

5.5 负载均衡策略

随着互联互联网信息的爆炸性增长，负载均衡（load balance）已经不再是一个很陌生的话题，顾名思义，负载均衡就是将负载分摊到不同的服务单元，既保证不服的可用性，又保证相应足够快，给用户很好的体验。快速增长的访问量和数据流量催生了各式各样的负载均衡产品，很多专业的负载均衡硬件提供了很好的功能，但却价格不菲，这使得负载均衡软件大受欢迎，nginx就是其中的一个，在Linux下有nginx,LVS,Haproxy等等服务可以提供负载均衡服务，而且，nginx提供了负载均衡策略 :

1.轮询（默认）

每个请求按照时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。

2.weight

weight代表权重，默认为1，权重越高被分配的客户端越多。

upstream myservers {

server 192.168.152.136:8081 weight=1;

server 192.168.152.136:8082 weight=2;

}

3.ip_hash

每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。

upstream myservers {

ip_hash;

server 192.168.152.136:8081 weight=1;

server 192.168.152.136:8082 weight=2;

}

4.fair(第三方)

按后端服务器的响应时间来分配请求，响应时间短的优先分配。

upstream myservers {

server 192.168.152.136:8081 weight=1;

server 192.168.152.136:8082 weight=2;

fair;

}

6.案例四：动静分离

6.1 动静分离介绍

Nginx动静分离简单来说就是把动态跟静态请求分开，不能理解成只是单纯的把动态页面和静态页面物理分离。严格意义上说应该是动态请求跟静态请求分开，可以理解成使用Nginx处理静态页面，Tomcat处理动态页面。动静分离从实现角度来讲大致分为两种：

一种是纯粹把静态文件独立成单独的域名，放在独立的服务器上，也是目前主流推崇的方案；

另一种是动态文件跟静态文件混合在一起发布，通过nginx来分开。

通过location指定不同的后缀名实现不同的请求转发。通过expires参数设置，可以使浏览器缓存过期时间，减少与服务器之间的请求和流量。具体Expires定义：是给一个资源设定一个过期时间，也就是说无需去服务端验证，直接通过浏览器自身确认是否过期即可，所以不会产生额外的流量。此种方案非常适合不经常变动的资源。（如果经常更新的文件，不建议使用Expires来缓存）我这里设置3d,标识这3天之内访问这个URL，发送一个请求，比对服务器该文件最后更新时间没有变化，则不会从服务器抓取，返回状态码304，如果有修改，则直接从服务器重新下载，返回状态码200。

6.2 需求描述

• 访问 192.168.152.136/www/a.html 访问到 a.html的内容
• 访问 192.168.152.136/images/ 访问到images下的所有图片文件信息

6.3 流程图

开始

访问192.168.152.136/www/a.html

响应a.html内容

结束

访问192.168.152.136/images

响应image下的内容

6.4 资源准备

1. home 下新增一个data目录
2. data目录路中新增 www目录，并在www中添加一个a.html文件
3. data目录中新增 images目录，并在images中添加一张图片

6.5 修改配置文件与root（*）

• autoindex on 表示打开目录下的文件索引
• 配置完成，重启nginx

$ ./nginx -s reload

nginx指定文件路径有两种方式root和alias，这两者的用法区别，使用方法总结了下，方便大家在应用过程中，快速响应。root与alias主要区别在于nginx如何解释location后面的uri，这会使两者分别以不同的方式将请求映射到服务器文件上。

[root]
语法：root path
默认值：root html
配置段：http、server、location、if

root实例：

location ^~ /t/ { root /www/root/html/; }

如果一个请求的URI是/t/a.html时，web服务器将会返回服务器上的/www/root/html/t/a.html的文件。

[alias]
语法：alias path
配置段：location

alias实例：

location ^~ /t/ {alias /www/root/html/new_t/; }

如果一个请求的URI是/t/a.html时，web服务器将会返回服务器上的/www/root/html/new_t/a.html的文件。注意这里是new_t，因为alias会把location后面配置的路径丢弃掉，把当前匹配到的目录指向到指定的目录。

注意：

1. 使用alias时，目录名后面一定要加"/"。
2. alias在使用正则匹配时，必须捕捉要匹配的内容并在指定的内容处使用。
3. alias只能位于location块中。（root可以不放在location中）

6.6 访问测试

访问静态界面	访问静态图片

7.案例五：nginx高可用（集群）

7.1 高可用原理简图

7.2 准备工作

7.2.1 两台虚拟机

1. 192.168.152.136
2. 192.168.152.137
   两台机器上都安装 nginx 和 keepalived

192.168.152.136	192.168.152.137

7.2.2 nginx的配置

nginx在这个地方直接使用你默认配置即可

7.2.3 keepalived的安装与配置

• 两台主机上都要安装 keepalived
• 安装命令 ：

$ yum install -y keepalived

• 安装位置：

$ cd /etc/keepalived

• 配置文件： 【安装目录下的keepalived.conf文件】
• 修改配置文件内容：【两台机器上都要有配置文件的信息，注意修改ip 和 主备机MASTER/BACKUP】

! Configuration File for keepalivedglobal_defs { notification_email { [e-mail] [e-mail] [e-mail] } notification_email_from [e-mail] smtp_server 192.168.152.136 smtp_connect_timeout 30 router_id LVS_DEVEL # 此处的router_id 与 /etc/hosts中的配置一致 } vrrp_script chk_http_port { script "/usr/local/src/nginx_check.sh" interval 2 # 检测脚本执行的时间间隔 weight 2 } vrrp_instance VI_1 { state MASTER # 备份服务器上将MASTER改为BACKUP interface ens33 # 网卡名称，可以通过ifconfig命令查看 virtual_router_id 51 # 主、备机的virtual_router_id 必须相同 priority 100 # 主、备机取不同的优先级，主机值较大，备份机值较小 advert_int 1 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { 192.168.152.100 # 虚拟地址 } }

7.2.4 script脚本

• 脚本文件的位置 ： /usr/local/src/nginx_check.sh【根据keepalived配置文件中的内容确定的】
• 文件内容：

#!/bin/bashA=`ps -C nginx --no-header | wc -l` # 这个位置是 小写字母l,不是数字1，下同 if [ $A -eq 0 ];then /usr/local/nginx/sbin/nginx sleep 2 if [ `ps -C nginx --no-header | wc -l` -eq 0];then killall keepalived fi fi

7.2.5 /etc/host文件修改

• 添加 内容 【127.0.0.1 LVS_DEVEL】
• 目的 ： 配合 keepalived的配置文件中的 router_id

7.2.6 启动nginx和keepalived

• nginx启动 ： 进入到nginx的安装目录下的sbin中 ./nginx
• keepalived启动 ： systemctl start keepalived

7.3 测试效果

在浏览器中访问 192.168.152.100 这个虚拟ip也是可以正常访问到 nginx的

停止 192.168.152.136 上的keepalived,则会转移到 192.168.152.137上去

但是，如果是下线 192.168.152.136 上的nginx,则会出现无法访问的情况【这个感觉不对啊】

查看虚拟ip的绑定 ： ip addr

8.Nginx原理

一个master和多个worker的好处：

• 可以使用nginx - s reload 进行热部署
• 对于每个worker进程来说，独立的继承，不需要枷锁，所以省掉了锁带来的开销，同时在编程以及问题查找时，也会方便很多。
• 采用独立的进程，可以让互相之间不会影响，一个进程退出后，其他进程还在工作，服务不会中断，master进程则很快启动新的worker进程。
• 当然，worker进程的异常退出，肯定是程序有bug了，异常退出，会导致当前worker上的所有请求失败，不过不会影响到所有请求，所以降低了风险。

设置多少个worker才合适：

• nginx同redis类似，都采用了io多路复用机制，每个worker都是一个独立的进程，但每个进程 里只有一个主线程，通过异步非阻塞的方式来处理请求，即使是成千上万个请求也不在话下。每个worker的线程可以把一个CPU的性能发挥到极致。所以worker数和服务器的CPU数相等是最为适宜的。设置少了会浪费CPU，设置多了会造成CPU频繁切换上下文带来的损耗。

连接数 worker_connection

• 这个值是表示每个worker进程所能建立连接的最大值，所以，一个nginx能建立的最大连接数，应该是worker_connections* worker_processes。当然，这里说的是最大连接数，对于HTTP请求本地资源来说，能够支持的最大并发数量是worker_connectionsworker_processes,如果是支持http1.1的浏览器每次访问要占两个连接，所以普通的静态访问最大并发数是 ： worker_connectionsworker_processes/2，
• 而如果是HTTP作为反向代理来说，最大并发数量应该是 worker_connections*worker_processes/4。因为作为反向代理服务器，每个并发会建立于客户端的连接和后端服务的连接，会占用两个连接。
• 第一问 ： 发送请求，占用了worker的几个连接数？

答案 ： 2 或者 4

• 第二问： nginx有一个master，有四个worker，每个worker支持最大的连接数是1024，则支持的最大并发数是多少？

答案： 4**1024/2 or 4*1024/4