Nginx(二)
Nginx (二)
0.前言
前面我们对nginx已经有了初步的认识,接下来就是最重要的部分,也就是Nginx的配置文件内容,首先我们对于Nginx 的设置与配置需要清楚三个文件的位置,启动脚本(我这里设置的是/opt/project/nginx-1.14/sbin/nginx)、主配置脚本(我这里设置的是conf-path=/opt/project/nginx-1.14/config/nginx.conf)以及副配置文件default.conf
这里需要注意的是default.conf作为一个示例配置文件,它包含了一些常见的Nginx配置选项和示例站点配置。在安装Nginx时,通常会将该文件包含在默认的配置目录中,但这并不是必需的。如果在安装Nginx时选择了自定义的配置选项,或者使用了第三方的Nginx安装脚本,可能会导致缺少default.conf文件。在这种情况下,我们可以手动创建一个新的default.conf文件,并根据需要添加配置信息,由于本人是使用编译自定义安装,所以没有该文件
有了对三个文件的基础认识后,接下来是对Nginx配置文件的学习,在Nginx的配置文件中主要由三大块构成:全局块、events块以及http块,其中http块是配置文件的核心模块,具体细分情况为:
1 |
|
之后了解nginx的静态内容设置、location的内容以及php和mysql的编译搭建学习等内容
1.配置文件
全局块作用域为文件开始到events块之前的部分,这里的配置影响的是nginx服务器整体的运行,常见的内容有以下这些指令
指令 | 作用 |
---|---|
User | 指定Nginx进程运行的用户和组 |
Worker_processes | 指定Nginx使用的工作进程数 |
Error_log | 指定Nginx错误日志的路径和级别 |
pid | 指定Nginx主进程的PID文件路径 |
user nginx nginx;这个指令指定了Nginx进程运行的用户和组都为nginx。这意味着Nginx将以nginx用户的身份运行,从而限制了Nginx进程的权限。worker_processes auto;: 这个指令使用自动模式来确定Nginx使用的工作进程数。在这种模式下,Nginx会根据系统的CPU核心数来自动设置工作进程数,以充分利用系统资源,当然我们亦可以设置数字。
error_log /var/log/nginx/error.log warn;这个指令指定了Nginx错误日志的路径和级别。在这个例子中,错误日志将被写入到/var/log/nginx/error.log文件中,并且只记录警告级别及以上的错误信息。pid /run/nginx.pid;: 这个指令指定了Nginx主进程的PID文件路径。在这个例子中,PID文件将被写入到/run/nginx.pid文件中。
Events块的配置影响的是Nginx服务器和用户之间的网络连接,用于配置Ninx的时间模型和相关参数,常用的命令
指令 | 作用 |
---|---|
worker_connections | 用于设置每个worker进程可以同时处理的最大连接数 |
use | 用于指定Nginx使用哪种事件模型。常见的事件模型包括epoll、kqueue、select等 |
multi-accept | 用于设置是否开启多个连接的接受 |
accept_mutex | 用于设置是否开启accept互斥锁 |
accept_mutex_delay | 用于设置accept互斥锁的延迟时间 |
实际例子:
1 |
|
worker_connections 4096;这个指令是将每个worker进程的同时处理最大连接数量设置为了4096个连接,而use epoll则是设置了Nginx的时间模型为epoll事件模型,也就是事件驱动的i/o模型,mulyi_accept on则表示开启了多连接接受功能。
http块是配置的主要内容,用与定义全局配置和服务器配置项,其包含了http全局块和server块,其中一般nginx默认是将server块单独迁移到了另一个配置文件中,http全局块包括了引入文件(如引入server所在的配置文件),MIME-TYPE定义,日志自定义,连接超时时间,单链请求数上等内容、
一个http块可以包含多个server块,每一个server块都相当于一个虚拟主机,而每个server块又分为全局server块和一个活多个location块
http的常见参数:
指令 | 作用 |
---|---|
keepalive_timeout | 指定客户端与服务器之间的keep-alive超时时间 |
client_max_body_size | 指定客户端上传文件的最大大小 |
server_tokens | 控制nginx是否向客户端发送服务器版本信息 |
access_log | 用于记录访问日志 |
error_log | 用于记录错误日志 |
gzip | 用于开启或关闭gzip压缩功能 |
proxy_cache_path | 用于配置反向代理缓存路径和相关参数 |
server块可以定义该虚拟主机或者监听端口的相关配置项,和虚拟主机有密切的联系,从客户的角度而言,虚拟主机和独立主机并没有分别,其主要是为了节省互联网服务器的硬件成本。我的理解是通过不同端口或者域名的限制将多个请求进行了分流的操作,我以两个实际演示从端口和域名的问题作为例子:
1 |
|
1 |
|
这里需要注意,我使用了本机进行域名的解析和使用所以要在对应的/etc/hosts文件中修改一下本地地址的内容如下:
这里遇到一个问题暂时还没想通,就是前面由于自己的失误,导致了第二个服务器名称的监听端口忘记修改,还是8080,但是输入librarian域名后输出的结果是80端口library的对应结果,也梳理清楚了,这是当我们在浏览器或其他客户端中输入域名而不指定端口号时,默认情况下会使用80端口。这是因为HTTP协议默认使用80端口进行通信。如果我们的Nginx服务器配置为监听80端口,那么在访问域名时不需要额外指定端口号。例如,当访问http://example1.com时,实际上是在访问http://example1.com:80。如果我们的Nginx服务器监听了其他端口,例如8080,那么需要在URL中明确指定端口号,如http://example1.com:8080才能访问指定内容,而如果是连个不同域名对应一个相同ip地址时,例如使用http://example1.com对应80端口,http://example2.com对应8080端口,当我们访问http://example2.com:80时,其指向的内容去http://example1.com的相关内容,所以端口号的作用会大一些
2.静态内容
前面已经使用server模块进行了文本内容的响应和内容展示,接下来就是静态内容的使用和配置,为了提供静态内容,就必须把这些文件放置在服务器的某个位置,以nginx 的默认而言,其所提供的初始网页文件在其html文件夹中:
在server的使用中,其默认的index.html前文也提及过
1 |
|
root html;: 这一行指定了请求资源的根目录。在这个例子中,根目录被设置为html。实际上,这通常是相对于Nginx安装目录的相对路径,例如/usr/share/nginx/html或/var/www/html。我们可以需要根据我们的系统和Nginx安装来确定实际路径。index index.html index.htm;: 这一行定义了当请求一个目录时,默认使用哪些文件作为索引文件。在这个例子中,如果请求的是一个目录(如http://example.com/),Nginx会首先尝试返回index.html文件,如果不存在,则尝试返回index.htm文件
前文提到为了提供静态内容,首先必须将它们存储在服务器上的某个位置。如果我们使用 ls 列出服务器根目录下的文件和目录,会在那里找到一个名为 /srv 的目录
1 |
|
这里我们需要涉及到git进行clone几个静态文件内容进行调试首先下载git指令的安装包:
1 |
|
这里的/srv目录旨在包含由该系统提供的特定与站点的数据,现在cd进入目录并克隆寻找的代码库
1 |
|
在 nginx-handbook-projects 目录中应该有一个名为 static-demo 的目录,总共包含四个文件
现在有了要提供的静态内容,只需要进行如下方式更新配置
1 |
|
与纯文本文件代码几乎相同,除了return指令不过是替换了root指令,该指令用于声明站点的根目录,我们通过编写 root /srv/nginx-handbook-projects/static-demo 告诉 NGINX 在有任何请求时在这个服务器的 /srv/nginx-handbook-projects/static-demo 目录中查找要提供的文件。查看效果:
这里需要注意,为有效的测试,设置了三个导航链接进行反馈,查看css代码的作用是否有效
Content-Type 并查看展示是 text/css。这意味着 NGINX 将此文件作为样式表提供没这事由于我们提前在http块中设置了include mime.types,因此是能够成功显示的。mime.types 正是Ngnix为解决大项目上下文中映射文件类型提供的解决方案。
该文件包含一长串文件类型及其扩展名,可以进行查看和使用。
3.匹配方式
前文提到了在上一节中编写配置是一个基础的静态内容服务器配置,它究竟是匹配来自于于客户端发文档URL相对应的站点目录的文件并进行相应,所以当我们请求对应根目录,例如 index.html、about.html 或 mini.min.css,NGINX 将返回该文件。但是,如果访问诸如 http://nginx-handbook.test/nothing 之类的路由,它将以默认的 404 页面响应:
在Nginx配置文件中,location指令用于定义一个特定的URI(Uniform Resource Identifier)或URI模式,并为其指定相应的处理规则。当客户端发起请求时,Nginx会根据请求的URI与配置文件中的location指令进行匹配,然后按照匹配到的location块中的规则来处理请求。location指令可以包含多种匹配模式,例如精确匹配、前缀匹配、正则表达式匹配等。这使得你可以针对不同的URI或URI模式设置不同的处理规则,例如代理转发、静态文件服务、访问控制等。那么接下来就是了解location的三种匹配了。
作为位置匹配模块,我们将在本节中讨论的第一个内容是location上下文,首先设置如下内容进行前缀匹配的设置:
1 |
|
我们已经用新的 location 上下文替换了 root 指令。这个上下文通常嵌套在 server 块中。server 上下文中可以有多个 location 上下文。如果向 http://nginx-handbook.test/lhy发送请求,将获得 200 响应代码和建的good good study day day up 创字符列表。
这里需要注意的是,如果向 http://nginx-handbook.test/lhy-shuai 发送请求,将得到相同的响应,这是由于通过编写 location /lhy,告诉 NGINX 匹配任何以“lhy”开头的 URI。这种匹配就是上述的前缀匹配
当然,我们也能够使用生成执行完全匹配的效果。在位置 URI 之前添加一个 = 符号将指示 NGINX 只有在 URL 完全匹配时才响应。现在,如果向除 /agatha 之外的任何内容发送请求,都将收到 404 响应。
1 |
|
使用此匹配,可以根据复杂的正则表达式检查 URL location,通过将之前使用的 = 符号替换为 ~ 符号,来告诉 NGINX 执行正则表达式匹配。将 location 设置为 ~ /lhy[0-9] 意味着 NIGINX 只有在单词“lhy”后面有数字时才会响应
1 |
|
默认情况下,正则表达式匹配区分大小写,这意味着如果将任何字母大写,则该 location 将不起作用,要将其转换为不区分大小写,必须在 ~ 符号后添加一个 *。
在nginx中,location指令用于定义处理特定URI请求的规则。当有多个location块匹配同一个请求时,nginx会根据一定的优先级选择一个来处理该请求。通常来说location匹配的优先级顺序为:
优先级从上到下 | 语法 |
---|---|
完全匹配 | = / |
前缀匹配 | ^~ / |
正则匹配 | |
通用前缀匹配 | / |
1 |
|
从输出结果可以看到,当我们输入lhy8时,对应的是完全匹配表达式的结果,输入lhy9时则是正则表达式的结果。这与我们所讲的理论一致,那么匹配的介绍与学习就到此为止了。
4.日志内容
默认情况下,Nginx的日志文件是位于/var/log/nginx中,本人在安装的时候就通过配置–error-log-path=/opt/project/nginx-1.14/logs/error.log 设置错误,警告,和诊断文件的位置和名称,通过罗列可以看到:
1 |
|
在nginx中,日志文件主要分为两类:访问日志(access log)和错误日志(error log):
访问日志(access log):记录了所有客户端发起的请求。默认情况下,访问日志存储在/var/log/nginx/access.log文件中。你可以通过access_log指令自定义日志文件的位置和格式,
如图片所示,access.log文件在默认情况下,对服务器的任何请求都会记录到该文件当中,我们可以通过acccess——log指令来改变这种情况
1 |
|
可以看到,当我们访问两个域名下的文件都成功时,仅有accesss是记录在了日志当中,而no_logging则并没有相关的访问记录、
错误日志(error log):记录了nginx服务器遇到的错误和警告信息。默认情况下,错误日志存储在/var/log/nginx/error.log文件中。可以通过error_log指令自定义日志文件的位置和日志级别
现在假设我们认为创建一个错误的文件保存失败日志消息,比如:
1 |
|
如图所示,return规定只接受两个参数,当我们给出三个参数时,系统就会进行报错并提示错误位置,最后将错误位置记录在error的日志消息中。正如图片所显示的那样,在error的报错中,错误消息存在级别划分,目前共有八个级别的错误消息类型
错误类型 | 对应级别 |
---|---|
debug | 有助于确定问题所在的有用调试信息 |
info | 不需要阅读但可能很好了解的信息性消息 |
notice | 发生了一些值得注意的正常现象 |
warn | 发生意外,但不必担心 |
error | 某些事情不成功 |
crit | 存在急需解决的问题 |
alert | 需要迅速采取行动 |
emerg | 系统处于无法使用的状态,需要立即关注 |
默认情况下,Nginx记录所有级别的消息,可以使用error_log指令覆盖该行为,如果要将消息的最低级别设置为warn,参考下列指令即可
1 |
|
首先在nginx的sbin文件夹下创建相关脚本,取名为cut_log,sh,输入如下内容:
1 |
|
接下来设置crontab,进行定时任务的编写
1 |
|
crontab -e是一个命令,用于编辑当前用户的Cron表。Cron是Linux系统中的定时任务调度程序,允许在特定时间执行脚本或命令。当输入crontab -e并按回车后,系统会打开一个文本编辑器(如nano、vim等),让我们编辑当前用户的Cron表。在这个文件中,我们可以添加、修改或删除定时任务,接下来就是设置定时任务
1 |
|
这是一个Cron表达式,用于定时执行任务。这个具体的表达式表示每天凌晨00:00(午夜)执行/opt/project/nginx-1.24/sbin/cut_nginx_log.sh脚本。
no crontab for root - using an empty one crontab: installing new crontab这些消息表明我以root用户身份编辑了Cron表,但在此之前,root用户没有任何已配置的Cron任务。因此,系统为root用户创建了一个空的Cron表,当看到”crontab: installing new crontab”这个提示时,表示已经成功地保存并安装了新的Cron表。现在,Cron将按照我们在Cron表中指定的时间和频率执行任务。