在Centos7下源代码安装配置Nginx

保存nginx.conf文件，输入cd ..，回到/usr/local/nginx/sbin目录下输入./nginx启动nginx服务。输入ps –ef |grep nginx查看运行的进程。

运行nginx：./nginx

重启nginx：./nginx -s reload

停止nginx：./nginx -s stop

输入netstat –ntlp | grep nginx查看nginx的通信端口。

输入wget htt:\\10.190.130.78:8007就测试到配置是否成功。

2.6.在Firewall启动状态下运行Nginx

在Firewall启动的情况下，其他客户端无法访问到htt:\\10.190.130.78:8007。

在Firewall中添加8007端口，firewall-cmd –permanent–add-port=8007/tcp，然后在输入firewall-cmd –reload，重载成功过后，

在输入firewall-cmd –list-all，可显示添加的8007端口。

输入netstat -ntlp | grep nginx查看nginx的占用端口

在其他客户端中输入wget http://10.190.130.78:8007就可以访问成功。

3.设置自定义开机系统服务

CentOS 7 使用systemd替换了SysV。Systemd目的是要取代Unix时代以来一直在使用的init系统，兼容SysV和LSB的启动脚本，而且够在进程启动过程中

更有效地引导加载服务。

systemd的特性有：

支持并行化任务

同时采用socket式与D-Bus总线式激活服务；

按需启动守护进程（daemon）；

利用 Linux 的 cgroups 监视进程；

支持快照和系统恢复；

维护挂载点和自动挂载点；

各服务间基于依赖关系进行精密控制。

 

检视和控制systemd的主要命令是systemctl。该命令可用于查看系统状态和管理系统及服务。详见man 1 systemctl。

输入vim /usr/lib/systemd/system/nginx.service进入文件编辑。

将以下内容拷贝到nginx.service文件中，然后保存。

 

[Unit]

Description=nginx servicedaemon

After=network.target

 

[Service]

Type=forking

PIDFile=/usr/local/nginx/logs/nginx.pid  #nginx安装路径下的nginx.pid文件

ExecStart=/usr/local/nginx/sbin/nginx

ExecReload=/usr/local/nginx/sbin/nginx-s reload

ExecStop=/usr/local/nginx/sbin/nginx-s stop

PrivateTep=true

 

[Install]

WantedBy=multi-user.target

保存文件后，启动nginx服务器会出现错误。必须要输入systemctl daemon-reload，重载后台服务。

输入systemctl daemon-reload，重载后台服务。可以使用systemctl命令对nginx进行操作

如果需要更详细的配置，请参考：

https://www./software/systemd/man/systemd.service.html

使用单元

一个单元配置文件可以描述如下内容之一：系统服务（.service）、挂载点（.mount）、sockets（.sockets）、系统设备（.device）、交换分区（.swap）、文件路径（.path）、启动目标（.target）、由 systemd 管理的计时器（.timer）。详情参阅 man 5 systemd.unit。

使用 systemctl 控制单元时，通常需要使用单元文件的全名，包括扩展名（例如 sshd.service）。但是有些单元可以在systemctl中使用简写方式。

如果无扩展名，systemctl 默认把扩展名当作 .service。例如 netcfg 和 netcfg.service 是等价的。

挂载点会自动转化为相应的 .mount 单元。例如 /home 等价于 home.mount。

设备会自动转化为相应的 .device 单元，所以 /dev/sda2 等价于 dev-sda2.device。

注: 有一些单元的名称包含一个 @ 标记， (e.g. [e-mail]): 这意味着它是模板单元name@.service 的一个实例。 string 被称作实例标识符, 在 systemctl 调用模板单元时，会将其当作一个参数传给模板单元，模板单元会使用这个传入的参数代替模板中的 %I 指示符。在实例化之前，systemd 会先检查 [e-mail] 文件是否存在（如果存在，应该就是直接使用这个文件，而不是模板实例化了）。大多数情况下，包换 @ 标记都意味着这个文件是模板。如果一个模板单元没有实例化就调用，该调用会返回失败，因为模板单元中的 %I 指示符没有被替换。

例如：systemctl start <单元>

 

编写单元文件

systemd单元文件的语法来源于 XDG桌面入口配置文件.desktop文件，最初的源头则是MicrosoftWindows的.ini文件。单元文件可以从两个地方加载，优先级从低到高分别是：

/usr/lib/systemd/system/: 软件包安装的单元

/etc/systemd/system/: 系统管理员安装的单元

注意: 当systemd运行在用户模式下时，使用的加载路径是完全不同的。

 

处理依赖关系

使用systemd时，可通过正确编写单元配置文件来解决其依赖关系。典型的情况是，单元A要求单元B在A启动之前运行。在此情况下，向单元A配置文件中的 [Unit] 段添加 Requires=B 和 After=B 即可。若此依赖关系是可选的，可添加 Wants=B 和 After=B。请注意 Wants= 和 Requires= 并不意味着 After=，即如果 After= 选项没有制定，这两个单元将被并行启动。

依赖关系通常被用在服务（service）而不是目标（target）上。例如， network.target 一般会被某个配置网络接口的服务引入，所以，将自定义的单元排在该服务之后即可，因为 network.target 已经启动。

服务类型

编写自定义的 service 文件时，可以选择几种不同的服务启动方式。启动方式可通过配置文件 [Service] 段中的 Type= 参数进行设置。

Type=simple（默认值）：systemd认为该服务将立即启动。服务进程不会fork。如果该服务要启动其他服务，不要使用此类型启动，除非该服务是socket激活型。

Type=forking：systemd认为当该服务进程fork，且父进程退出后服务启动成功。对于常规的守护进程（daemon），除非你确定此启动方式无法满足需求，使用此类型启动即可。使用此启动类型应同时指定 PIDFile=，以便systemd能够跟踪服务的主进程。

Type=oneshot：这一选项适用于只执行一项任务、随后立即退出的服务。可能需要同时设置 RemainAfterExit=yes 使得 systemd 在服务进程退出之后仍然认为服务处于激活状态。

Type=notify：与 Type=simple 相同，但约定服务会在就绪后向 systemd 发送一个信号。这一通知的实现由 libsystemd-daemon.so 提供。

Type=dbus：若以此方式启动，当指定的 BusName出现在DBus系统总线上时，systemd认为服务就绪。

Type=idle: systemd会等待所有任务(Jobs)处理完成后，才开始执行idle类型的单元。除此之外，其他行为和Type=simple 类似。

type的更多解释可以参考systemd.service(5)。

3.1.设置开机服务

输入systemctl start nginx启动nginx服务，在输入systemctl enable nginx 设置nginx服务为开机启动服务，最后，输入systemctl status nginx查看nginx的运行状态。

3.2.停止开机服务

输入systemctl disable nginx停止开机启动nginx服务，输入systemctlstop nginx停止nginx服务，输入systemctl status nginx查看nginx的运行状态。

4.负载均衡策略

在nginx中支持的负载均衡策略如下：

轮询加权策略（Round-Robin）：在轮询模策略中，要求应用服务器是分布式的

最少连接策略（Least-Connected）：下一个请求是分配给最少的活动连接数服务器。

IP哈希策略（IP-Hash）：一个哈希函数用来决定那个服务器被选择作为下一个请求处理的服务器（基于客户端的IP地址）。

4.1.轮询策略

http {

   upstream myapp1 {           #服务器组，组名：myapp1

       server srv1.example.com;  #web应用服务器1

       server srv2.example.com;  #web应用服务器2

       server srv3.example.com;  #web应用服务器3

    }

 

   server {

       listen 80;

 

       location / {

           proxy_pass http://myapp1;          #客户端访问的URL

       }

    }

}

以上是最简单的Nginx负载均衡配置。在upstream myapp1中有3个应用服务器实例，当负载均衡中没有指定配置负载策略时，默认是使用轮询权重策略。所有请求都是代理给服务器组myapp1，Nginx应用http负载均衡到分布式请求中。

在Nginx反向代理负载均衡的扩展包括：http，https，FastCGI，uwsgi，SCGI和缓存。

配置负载均衡

配置https负载均衡代替http，只使用“https”作为协议就可以了。

当设置负载均衡为FastCGI，uwsgi，SCGI，或缓存，指令分别使用fastcgi_pass，uwsgi_pass，scgi_pass，和memcached_pass。

如果可以把加权轮询算法分为先深搜索和先广搜索，那么nginx采用的是先深搜索算法，即将首先将请求都分给高权重的机器，直到该机器的权值降到了比其他机器低，才开始将请求分给下一个高权重的机器；第二，当所有后端机器都down掉时，nginx会立即将所有机器的标志位清成初始状态，以避免造成所有的机器都处在timeout的状态，从而导致整个前端被夯住。

4.2.最少连接策略

upstream myapp1 {                     #服务器组，组名：myapp1

       least_conn;                  #least_conn;最少连接策略

       server srv1.example.com;       #web应用服务器1

       server srv2.example.com;       #web应用服务器2

       server srv3.example.com;       #web应用服务器3

}

最少连接允许控制加载应用实例，更多适合在一些花费比较长时间去完成请求的一个场景中。

用最少连接负载均衡，Nginx会尽量不要求过载繁忙的应用服务器去执行请求，分配新的请求给一个不太忙碌的服务器代替执行。

最少连接负载均衡在Nginx中被激活时，least_conn指令被用来作为服务器群组配置的一个部分。

4.3.IP哈希策略

配置IP哈希负载均衡，只需要添加ip_hash指令指向服务器(uptream) 组配置：

upstream myapp1 {

   ip_hash;

   server srv1.example.com;

   server srv2.example.com;

   server srv3.example.com;

}

每个客户端请求都有可能发送到不同的服务器，不能保证同一个客户端总是指向同一个服务器。如果一个客户端必须要跟服务器的会话关联在一起的时候，可以使用IP哈希负载均衡缓存策略。

通过获取客户端额IP地址，经过哈希函数的计算得到一个值，利用该值对服务器的列表大小进行取模运算，得到的值就是处理客户端请求的服务器序号。采用IP哈希负载均衡策略，的优点是，同一个客户端的IP地址，每次发送的请求都是指向同一台服务器进行处理。这种方式确保来自同一个客户端请求总是指向同一个服务器除非这个服务是无效的。

举例子说明：

例如一个系统的会话存储用户信息，每次将请求发送到服务器，服务器都会从会话中获取数据。但在负载均衡环境中，每次客户端的每次请求都可能由不同的服务器处理，所以可能出现无法获取的到客户端的会话数据（由于会话数据是保存在服务器的内存中）。

4.4.权重策略

使用服务器权重策略，它也有可能影响到Nginx负载均衡算法。

在上面的例子中，服务器权重没有配置，意味着所有指定的服务器都被视为同等资格的一个特定负载均衡策略。尤其是轮询策略，它也意味着差不多平等地分配请求给服务器，并且快速平均地处理请求。

 

当权重参数被指定在一个服务器时，权重作为负载均衡决策的部分。

upstream myapp1 {

       server srv1.example.com weight=3;

       server srv2.example.com;

       server srv3.example.com;

}

在这个配置中，每5个请求都分配给应用服务器实例如下：

3个请求将分配到serv1中，1个请求分配给srv2中，而另外1个请求则分配个srv3中。

在最近的Nginx版本中，它同样可以与最少连接和IP哈希策略一样去使用权重策略。

4.5.总结

轮询策略：

优点：如果希望每个服务器都能平均处理客户端请求可使用轮询策略。

缺点：不支持会话管理，另外，假设有5个客户端请求，有2台服务器处理请求，某一台服务器处理请求时消耗资源比较大，每次都接到消耗资源比较大的请求，那么该服务器处理能力就会下降。

 

IP哈希策略：

缺点：使用该策略，服务器可能不会平均处理每个请求。假设有5个客户端请求，那么通过计算出哈希值后，可能都是由一台服务器处理。其它的服务器可能没有请求需要处理。

优点：支持会话管理，如果系统中使用会话处理数据，该策略比较适合。

 

最少连接策略：

优点：系统把新连接分配给当前连接数目最少的服务器。该算法在各个服务器运算能力基本相似的环境中非常有效。此负载均衡策略适合请求处理时间长短不一造成服务器过载的情况。

缺点：虽然某个服务器的连接数较少，但处理请求时间较长，这时候再接受请求处理，可能影响到时间效率的问题。

 

权重策略：

优点：如果服务器的硬件等级差别比较大，那么配置高的服务器可分配较高权重，以便处理更多的请求。而配置低的服务器可接受少量请求。

缺点：如果服务器的硬件等级一样不太适合使用该策略。

5.健康检查

在Nginx反向代理中实现主动或被动健康检查，如果指定的响应服务器出现错误，Nginx将标记该服务器为失败，将尽量去避免为后续的请求选择该服务器。

设置发生在超时失败期间连续不成功的服务器通信的max_fails指令。默认max_fails设置是1，当设置为0次时，这台服务器的检查检查不启用。Fail_timeout参数定义服务器多长时间将被标记为失败。在服务器fail_timeout期间，Nginx不会马上将该服务器标记为失败的服务器，而是模拟想客户端请求去侦查服务器，如果侦查成功，该服务器标记为在线服务器。

关于健康检查的的插件需要花钱购买，更多的信息请参考：

https://www./products/application-health-checks/

https://www./resources/admin-guide/installing-nginx-plus/

6.附录

6.1.systemctl命令指南

Systemctl是一个systemd工具，主要负责控制systemd系统和服务管理器。

Systemd是一个系统管理守护进程、工具和库的集合，用于取代System V初始进程。Systemd的功能是用于集中管理和配置类UNIX系统。

在Linux生态系统中，Systemd被部署到了大多数的标准Linux发行版中，只有为数不多的几个发行版尚未部署。Systemd通常是所有其它守护进程的父进程，

但并非总是如此。使用Systemctl管理Linux服务

6.1.1.Systemd初体验和Systemctl基础

6.1.1.1.1.检查systemd安装版本

1. 首先检查你的系统中是否安装有systemd并确定当前安装的版本

# systemd –version

6.1.1.1.2.检查systemd和systemctl的二进制文件和库文件的安装位置

# whereis system

# whereis systemctl

6.1.1.1.3检查systemd是否运行

# ps -eaf | grep system

6.1.1.4.分析systemd启动进程

# systemd-analyze

6.1.1.5.分析启动时各个进程花费的时间

#systemd-analyze blame

6.1.1.6.分析启动时的关键链

# systemd-analyze critical-chain

重要：Systemctl接受服务（.service），挂载点（.mount），套接口（.socket）和设备（.device）作为单元。

Systemctl是一个systemd工具，主要负责控制systemd系统和服务管理器。

Systemd是一个系统管理守护进程、工具和库的集合，用于取代System V初始进程。Systemd的功能是用于集中管理和配置类UNIX系统。

在Linux生态系统中，Systemd被部署到了大多数的标准Linux发行版中，只有为数不多的几个发行版尚未部署。Systemd通常是所有其它守护进程的父进程，

但并非总是如此。

使用Systemctl管理Linux服务

本文旨在阐明在运行systemd的系统上“如何控制系统和服务”。

Systemd初体验和Systemctl基础

1. 首先检查你的系统中是否安装有systemd并确定当前安装的版本

# systemd--version
systemd 215
+PAM +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ -SECCOMP-APPARMOR

上例中很清楚地表明，我们安装了215版本的systemd。

2. 检查systemd和systemctl的二进制文件和库文件的安装位置

# whereissystemd
systemd:/usr/lib/systemd /etc/systemd /usr/share/systemd/usr/share/man/man1/systemd.1.gz
# whereis systemctl
systemctl:/usr/bin/systemctl /usr/share/man/man1/systemctl.1.gz

3. 检查systemd是否运行

# ps -eaf | grep[s]ystemd
root 10016:27?00:00:00/usr/lib/systemd/systemd --switched-root --system--deserialize 23
root 4441016:27?00:00:00/usr/lib/systemd/systemd-journald
root 4691016:27?00:00:00/usr/lib/systemd/systemd-udevd
root 5551016:27?00:00:00/usr/lib/systemd/systemd-logind
dbus 5561016:27?00:00:00/bin/dbus-daemon --system --address=systemd:--nofork--nopidfile --systemd-activation

注意：systemd是作为父进程（PID=1）运行的。在上面带（-e）参数的ps命令输出中，选择所有进程，（-a）选择除会话前导外的所有进程，并使用（-f）参数输出完整格式列表（即 -eaf）。

也请注意上例中后随的方括号和例子中剩余部分。方括号表达式是grep的字符类表达式的一部分。

4. 分析systemd启动进程

#systemd-analyze
Startup finished in487ms(kernel)+2.776s(initrd)+20.229s(userspace)=23.493s

5. 分析启动时各个进程花费的时间

#systemd-analyze blame
8.565s mariadb.service
7.991s webmin.service
6.095s postfix.service
4.311s httpd.service
3.926s firewalld.service
3.780s kdump.service
3.238s tuned.service
1.712s network.service
1.394s lvm2-monitor.service
1.126s systemd-logind.service
....

6. 分析启动时的关键链

#systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@"character.
The time the unit takes to start is printed after the "+" character.
multi-user.target @20.222s
└─mariadb.service @11.657s+8.565s
└─network.target @11.168s
└─network.service @9.456s+1.712s
└─NetworkManager.service @8.858s+596ms
└─firewalld.service @4.931s+3.926s
└─basic.target @4.916s
└─sockets.target @4.916s
└─dbus.socket @4.916s
└─sysinit.target @4.905s
└─systemd-update-utmp.service @4.864s+39ms
└─auditd.service @4.563s+301ms
└─systemd-tmpfiles-setup.service @4.485s+69ms
└─rhel-import-state.service @4.342s+142ms
└─local-fs.target @4.324s
└─boot.mount @4.286s+31ms
└─systemd-fsck@dev-disk-by\x2duuid-79f594ad\x2da332\x2d4730\x2dbb5f\x2d85d19608096
└─dev-disk-by\x2duuid-79f594ad\x2da332\x2d4730\x2dbb5f\x2d85d196080964.device@4

重要：Systemctl接受服务（.service），挂载点（.mount），套接口（.socket）和设备（.device）作为单元。

6.1.1.7.列出所有可用单元

# systemctl list-unit-files

6.1.1.8.列出所有运行中单元

# systemctl list-units

6.1.1.9.列出所有失败单元

# systemctl –failed

6.1.1.10.检查某个单元是否启用

# systemctl is-enabled nginx.service 

6.1.1.11.检查某个单元或服务是否运行

# systemctl status nginx.service