1、lamp其实就是一组通常一起使用来运行动态网站或者服务器的自由软件,包括Linux(操作系统)、Apache(HTTP服务器)、MySQL(也指MariaDB,数据库软件)和PHP(有时也是指Perl或Python)的第一个字母,一般用来建立web应用平台;
2、除Linux外其它各部件本身都是各自独立的程序,但是因为经常被放在一起使用,拥有了越来越高的兼容度,共同组成了一个强大的Web应用程序平台。本次实验我们使用Nginx替代Apache, nginx相比较apache最明显的优势是轻量级、高并发,配置也较apache更简洁。
为了便于后续实验,给server1添加一个172.25.0网段的ip
真机(172.25.254.36)打开火墙,开启地址伪装功能,使得虚拟机能够上网
真机添加一条iptables规则;
MASQUERADE的作用:从服务器的网卡上,自动获取当前ip地址来做NAT,这样不用指定SNAT的目标ip,不管现在eth0的出口获得了怎样的动态ip,MASQUERADE会自动读取eth0现在的ip地址然后做SNAT出去,这样就实现了很好的动态SNAT地址转换。
查看nat表所有链及所有规则,可以看到添加成功
此时server1就可以直接从服务器上获取所需文件
server1从服务器上下载nginx的源码压缩包nginx-1.20.1.tar.gz,解压后进入到nginx源码目录;
src/core存放着nginx的主干部分、基础数据结构和基础设施的源码
conf目录下由nginx的主配置文件nginx.conf
源码编译三部曲:配置(configure)、编译(make)、安装(make install);
配置:通过./configure --help查看配置选项
nginx源码文件,需要gcc等依赖文件进行编译
设置安装的路径为/usr/local/nginx,加上需要的功能模块;
运行后可以看到提示缺少PCRE
开发包以devel结尾
提示缺少openssl
再次配置,显示成功
在configure执行完后,它会生成一些中间文件,中间文件会放在objs目录下;
Makefile是一种配置文件,定义了一系列的规则来指定,哪些文件需要先编译,哪些文件需要后编译,哪些文件需要重新编译,甚至于进行更复杂的功能操作
执行编译(静态编译)
编译成功
将编译好的文件安装到指定路径
此时objs目录下可以看到 nginx文件
在我们指定的路径下也能看到编译好的nginx文件
为方便nginx启动,设定软链接到/usr/local/sbin/(这样在开启nginx服务的时候就不需要进到目录下开启,软连接的方式可以方便开启全局nginx);
nginx -t:检查配置脚本是否运行正常
nginx:启动nginx,并查看端口
测试:成功访问到nginx的默认发布目录
客户端访问测试
注意当nginx进程已经启动时,再次启动就会出现以下提示
停止nginx
当需要二次编译nginx时,必须先执行make clean(清除上次的make命令所产生的object文件(后缀为“.o”的文件)及可执行文件);
最后执行make install(因为文件已经复制过去,不需要再次复制)
关闭c语言编译debug(轻量化编译文件)
在此Debug模式模式会插入许多追踪和ASSERT之类的信息,在正常编译过程中结束,会产生几兆大小的包,我们可以在编译之前关闭debug模式,这样在编译结束,只会产生几百K左右的包大小。
#CFLAGS=“$CFLAGS -g” ##本行注释掉,关闭debug日志模式,
显示 http response 的头信息,可以看到当前nginx版本
修改解压目录中的src/core/nginx.h
修改#define NGINX_VER(去掉版本)
重新进行配置、编译
执行编译,为了构建更加纯净的nginx脚本,不需要执行make install;
编译完成后,此时nginx大小为928k;
出现以下问题是因为没有关闭nginx
alias,则可列出目前所有的别名设置,在cp指令前面加反斜杠可以不弹出是否覆盖的询问而直接覆盖;
关闭nginx后,将新生成的文件更换安装目录中的文件;
再次启动nginx,并查看头信息,可以看到头信息已经更改(看不到当前nginx版本号)
如果想要使用systemctl来控制nginx
首先需要在服务器上获取nginx.service文件
首先确保nginx没启动,如果启动,需要关闭nginx;
刷新服务列表
启动nginx并设置服务开机自启,此时就可以通过systemctl来控制nginx
网页访问成功
为了便于实验效果,首先修改server1的cpu的个数为2,内存为2048;
用cpu的个数控制nginx的work进程个数;
增加一个nginx用户
修改nginx主配置文件nginx.conf,设定用户为nginx,worker进程数为1
nginx -s reload :平滑重启,不会强制结束正在工作的连接,需要等所有连接都结束才会重启
可以看到nginx的一个主控制端和被控制的一个worker
nginx并发优化:继续修改主配置文件,设定工作进程数为2
重启nginx后,查看nginx的worker进程;
当我们kill掉其中一个worker进程后,由于配置文件设定的worker进程数为2 ,因此会自动再运行一个新的worker进程
当设定worker进程数为auto后,会自动根据系统cpu的数量管理worker进程数
查看server1 cpu的详细信息
Nginx默认没有开启利用多核cpu,我们可以通过增加worker_cpu_affinity配置参数来充分利用多核cpu的性能;
cpu是任务处理,计算最关键的资源,cpu核越多,性能就越好;
2核cpu,开启2个进程 设定worker_cpu_affinity 01 10(将cpu和worker数目绑定);
4个cpu,开启4个进程 设定worker_cpu_affinity 0001 0010 0100 1000;
worker_connections:设定每一个worker进程能并发处理(发起)的最大连接数为65535(包含所有连接数),不能超过最大文件打开数;
要求内核支持最大文件打开数>系统支持最大文件打开数>Worker支持最大文件打开数
查看server1内核支持的最大文件打开数
查看真机内核支持的最大文件打开数
显示系统目前资源限制的设定,可以看到系统支持的最大文件打开数为1024
修改系统的最大文件打开数
*: 表示所有的用户,也可以指定指定的用户或用户组
soft: 表示应用软件级别限制的最大可打开的文件数的限制
hard: 表示操作系统级别限制的最大可打开的文件数的限制
使用nginx1.21进行版本升级,为避免升级时掉线,采用平滑升级;
首先server1连接服务器,下载nginx1.21.1版本的源代码编译包
同样的关闭gcc的debug
进行源代码安装第一步,同样的对即将安装的软件进行配置
编译,不执行make install
此时objs目录就会生成新的nginx二进制文件
将nginx旧版本文件进行备份
将新生成的nginx文件覆盖安装目录下的旧的nginx
此时curl查看发现仍然是旧版本的nginx
需要用kill -USR2 老版本的进程号 ,升级新程序,从而产生新版本的master和worker
kill -WINCH 老版本的进程号,可以关闭旧版本的worker进程但保留主进程:为了回退;
测试,已经升级到1.20版本
版本回退:
还原nginx程序:# cp -f nginx.old nginx
唤醒原进程:# kill -HUP 旧版本id
回收新版本的worker进程: kill -WINCH 新版本id
关闭新版本主进程: kill -QUIT 29761
首先将备份的旧版本nginx文件覆盖执行目录的nginx;
kill -HUP 旧版本id:唤醒原进程;
kill -WINCH 新版本id:回收新版本的worker进程;
curl测试,成功完成平滑回退
最后关闭新版本主进程
server1对server2/3进行免密认证,便于后续操作
将server1的nginx目录传输给server2/3
将server1的nginx.service文件传输给server2/3,使得server2/3也可以使用systemctl 命令来方便操作nginx的启动、停止和重启命令
server2/3分别执行:创建nginx用户、刷新服务列表、启动并设置nginx服务开机自启
server2/3修改默认发布页面
server1测试访问server2/3成功;
server1编辑nginx主配置文件,将均衡负载模块加入
在http加入upstream模块,设定反向代理负载均衡器westos;
upstream表示负载服务器池
location 指令的作用:根据用户请求的URI来执行不同的应用,URI就是根据用户请求到的网址URL进行匹配;
server_name :代理的服务域名;
location:设定当外部访问www.westos.org这个域名时,nginx会把所有请求都发送到upstream定义的服务器节点池(westos)
检测语法无误后,刷新服务使设定生效
在真机进行地址解析
测试,可以看到访问可以实现负载均衡
查看nginx日志
继续编辑nginx主配置文件
设定服务器server2的权重为2
可以看到,访问时server2出现的次数大概是server3的两倍
继续修改配置文件,设定server1为backup。只有当其他节点全部无法连接的时候,nginx才会启用这个节点。一旦有可用的节点恢复服务,该节点则不再使用,又进入后备状态。
server1测试访问
更改server1默认发布页面
测试访问
关闭server2的nginx服务
关闭server3的nginx服务
可以看到备用机server1启动成功
当server2的nginx服务开启后
备用节点server1将不再提供服务
ip_hash:通过客户端请求ip进行hash,再通过hash值选择后端server;
当你服务端的一个特定url路径会被同一个用户连续访问时,如果负载均衡策略还是轮询的话,那该用户的多次访问会被打到各台服务器上,这显然并不高效(会建立多次http链接等问题)。所以,此类场景可以考虑采用nginx提供的ip_hash策略。既能满足每个用户请求到同一台服务器,又能满足不同用户之间负载均衡。
语法检测出错,这是因为ip_hash不能与backup一起用
可以看到当客户端对指定域名进行多次服务请求时, 只有server3对该客户端提供服务
Cookie是某些网站为了辨别用户身份,进行Session跟踪而储存在用户本地终端上的数据(通常经过加密),由用户客户端计算机暂时或永久保存的信息;
在多台后台服务器的环境下,为了确保一个客户只和一台服务器通信,势必使用长连接。常见的有使用nginx自带的ip_hash来做,,但如果前端是CDN,或者说一个局域网的客户同时访问服务器,导致出现服务器分配不均衡,以及不能保证每次访问都粘滞在同一台服务器。因此可以采用基于cookie负载均衡,能保证每次都锁定同一台服务器;
server1从服务器下载额外的压缩包辅助cookie算法;
下载unzip压缩工具
解压文件
修改配置文件
语法检测失败,因为此时并没有cookie软件模块
所以先将sticky注释
停止nginx服务
重新配置,加上所需模块
make编译,将新的nginx覆盖旧的nginx
打开sticky设定
刷新服务
网页访问www.westos.org,按F12,即可查看到cookie访问记录,且采用cookie的方式访问时会锁定服务器
再按F5刷新页面,或者手动删除当前session,即可看到server2的cookie访问记录