搜索到
45
篇与
的结果
-
Linux 命令之crontab Linux 命令之crontab命令简介在服务器安装好系统及相关服务之后，对于系统的配置、服务的配置、数据的管理以及服务器的操作权限管理就变的尤为重要。因为，涉及到服务器的各项安全（如：登录、操作）。crontab 命令用来打开 cron 表进行编辑。定时任务：顾名思义，就是定期执行某项操作或者某种行为。像Windows系统同样它也有定时任务服务。在Linux系统中，crond是Linux系统中用来定期执行命令、脚本或指定程序的一种服务。定时任务一般有以下两种用途：1、系统自身定期执行的操作或任务（如：日志轮询）。2、用户定期执行的操作或任务（如：定时更新同步数据、重要数据备份等）。Linux下的任务调度分为两类：系统任务调度和用户任务调度系统任务调度：系统周期性所要执行的工作，比如写缓存数据到硬盘、日志清理等。在/etc/目录下有一个crontab文件，这个就是系统任务调度的配置文件。/etc/crontab 文件内容如下[root@centos7 ~]# cat /etc/crontab SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root # For details see man 4 crontabs # Example of job definition: # .---------------- minute (0 - 59) # | .------------- hour (0 - 23) # | | .---------- day of month (1 - 31) # | | | .------- month (1 - 12) OR jan,feb,mar,apr ... # | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat # | | | | | # * * * * * user-name command to be executed从上机的配置文件，可以看出系统定时任务格式/etc/crontab分为6段，以空格分隔。前5段为时间格式，第6段是所需执行的命令。详细的说明:minute #分钟，可以是从0到59之间的任何整数hour #小时，可以是从0到23之间的任何整数day #日期，可以是从1到31之间的任何整数month #月份，可以是从1到12之间的任何整数week #星期，可以是从0到7之间的任何整数，这里的0或7代表星期日command #执行的命令，可以是系统命令，也可以是自己编写的脚本文件在上述的配置字段中，还会使用到下面的特殊字符*（星号） #表示所有值。比如在第一段中如果使用*，则表示在满足其他条件的同时每分钟都执行后面的命令操作。，（逗号） #用逗号分隔的值表示指定的一个范围。比如在第四段使用1，3，5，7，则表示在第1，3，5，7月的含义。—（中杠） #表示一个范围。比如在第二段使用0-8，则表示0点到8点这一区间范围。/(正斜线) #表示一个时间的间隔频率。比如在第一段使用*/5,则表示每间隔5分钟的含义。语法格式crontab [-u user] file crontab [-u user] [-l | -r | -e] [-i] [-s]选项说明-e #编辑该用户的计时器-l #列出该用户的计时器-r #删除该用户的计时器-u<用户名称> #指定要设定计时器的用户名称-i：在删除定时任务列表时进行确认提示-s：显示该用户的下一个定时任务执行时间定时任务书写与配置书写定任务规范在日常实际生产、测试环境中，书写定时任务是需要遵守一定的规范、规则的。笔者根据自己实际生产环境书写经验，总结如下：1、书写定时任务时必须对每一行或一段加上注释信息。2、如里是以shell脚本执行的任务，在最前面加上解释/bin/sh。3、对于执行脚本的定时任务，需在其结尾加上>/dev/null 2>&1将一些不必要的输出信息重定向到空，也就是不输出不需要的信息。4、使用系统或服务命令要使用绝对路径，再写到脚本，最后将脚本写进定时任务中。5、规范使用目录（如定时任务执行的脚本目录设置成/server/cron_scripts）。2）定时任务配置实际生产、测试环境，对于定时任务的配置也是需要有一定操作规范的，具体如下：1、对于执行命令的形式的定时任务，需要先测试命令执行情况，确认无误后将执行的命令写进脚本。2、对于脚本形式的定时任务，首先就是需要调试脚本的整体执行情况，然后使用规范目录路径写进定时任务。3、对于生产环境的定时任务操作，必须在测试环境进行反复测试，确认无误后再应用到实际生产环境中，然后在定时任务执行后人工进行检查执行情况。对于定时任务的具体实例及各类操作，可参考官方文档说明。读者也可在自己的实验环境进行书写、配置，本章节就不做过多赘述。应用举例查看当前登录用户下的定时任务情况[root@centos7 ~]# crontab -l no crontab for root每小时的第5和第15分钟执行5,15 * * * * command_name在上午9点到11点的第5和第15分钟执行5,15 9-11 * * * command_name每隔3天的上午9点到11点的第5和第15分钟执行5,15 9-11 */3 * * command_name每个星期一的上午9点到11点的第5和第15分钟执行5,15 9-11 * * 1 command_name每月1、11、21日的14:45重启httpd45 14 1,11,21 * * /etc/init.d/httpd restart每周六、周日的1:10重启smb10 1 * * 6,0 /etc/init.d/httpd restart每小时执行/etc/scripts/test.sh这个脚本01 * * * * /etc/scripts/test.sh拓展在Linux中，设置定时任务的方法有多种。以下是常见的几种方法及其使用说明：使用crontab命令：使用crontab -e命令编辑当前用户的cron表。在打开的文件中，每一行代表一个定时任务，使用cron表达式来指定任务执行的时间。例如，以下示例将在每天的上午9点运行脚本/path/to/script.sh：0 9 * * * /path/to/script.sh保存并关闭文件后，cron会自动加载更新后的cron表。使用crontab -l命令查看当前用户的cron表。编辑系统级的/etc/crontab文件：使用文本编辑器打开/etc/crontab文件。每一行代表一个定时任务，使用cron表达式来指定任务执行的时间和要执行的命令。例如，以下示例将在每天的上午9点运行脚本/path/to/script.sh：0 9 * * * root /path/to/script.sh保存并关闭文件后，cron会自动加载更新后的cron表。使用crontab -l命令查看当前用户的cron表。使用/etc/cron.d/目录：在/etc/cron.d/目录中创建一个文件，文件名可以自定义，但不要包含.或/字符。文件内容格式与crontab相同，使用cron表达式来指定任务执行的时间和要执行的命令。例如，创建一个名为mytask的文件，内容如下：0 9 * * * root /path/to/script.sh保存文件后，cron会自动加载更新后的cron表。使用crontab -l命令查看当前用户的cron表。使用systemd的定时器：创建一个.timer文件，用于配置定时器的触发条件和要执行的任务。创建一个.service文件，用于定义要执行的任务的具体命令和其他设置。将这两个文件放置在/etc/systemd/system/目录中。运行systemctl daemon-reload命令，以重新加载systemd配置。使用systemctl start mytimer.timer命令启动定时器。使用systemctl enable mytimer.timer命令将定时器设置为开机启动。使用systemctl status mytimer.timer命令查看定时器的状态。这些方法之间的区别主要在于使用的工具和配置方式。crontab命令和/etc/crontab文件是传统的cron工具，适用于简单的定时任务。/etc/cron.d/目录允许将定时任务分散到多个文件中，更灵活。使用systemd的定时器提供了更精确的时间控制和更高级的功能，适用于需要更复杂任务调度的场景。选择最好的方法取决于您的具体需求和使用场景。如果只需要为当前用户设置定时任务，使用crontab命令是最简单和常见的方法。如果需要为整个系统或其他用户设置定时任务，可以选择编辑/etc/crontab文件或使用/etc/cron.d/目录。如果您使用的是systemd作为初始化系统，并且需要更高级的功能和集成，可以考虑使用systemd的定时器。请根据您的具体需求和系统配置选择最适合您的方式，并参考相关文档以获取更详细的使用说明。systemd进程管理工具详细教程请看这：Linux 命令之systemd -
审计 Linux 系统的操作行为的 5 种方案对比 审计 Linux 系统的操作行为的 5 种方案对比概述很多时候我们为了安全审计或者故障跟踪排错，可能会记录分析主机系统的操作行为。比如在系统中新增了一个用户，修改了一个文件名，或者执行了一些命令等等，理论上记录的越详细, 越有利于审计和排错的目的。不过过剩的记录也会为分析带来不少麻烦， 尤其是将很多主机的记录行为发送到固定的远程主机中，数据越多，分析的成本便越大。实际上，绝大多数的系统行为都是重复多余的，比如 cron 任务计划，我们信任的程序等, 这些都会产生大量的记录，但很少用于审计分析。基于这个需求，我们在审计系统操作行为的时候，至少应该添加一些过滤规则，避免记录过多的无用信息，比如重复的 cron 任务操作，同时也要避免记录一些敏感信息，比如带密码的命令行操作。满足这些需求后，我们在审计系统操作行为的时候应该遵照以下准则：忽略 cron，daemon 产生的记录；忽略带密码的敏感命令行或脚本操作记录；忽略监控用户（比如 nagios，zabbix，promethus 等）产生的记录；忽略频繁产生日志的操作行为；第二点为可选项，在以明文方式传输到远程日志服务器的时候，我们建议忽略记录。第四点则需要着重强调，比如我们记录一台 web 主机中的所有 connect，accept 网络系统调用操作，虽然可以据此分析该主机所有的网络访问请求，达到安全或者故障定位的目的，但是这两个系统调用可能在短时间内产生大量的日志，对 kernel 和网络日志传输都会产生不小的压力，这种大海捞针似的审计方式我们不推荐直接在线上主机中使用，建议仅在需要定位问题的时候启用。5 种方案下面我们主要介绍有哪几种方式可以实现系统操作的审计：history 记录方式定制 bash 记录方式snoopy 记录方式auditd 记录方式eBPF 记录方式history 记录方式history 方式很传统也很简单，本质上是将历史的命令发送到 syslog 日志中，可以用来简单记录用户的命令操作历史。但是这种方式有几个重要的缺点，并不适合审计的目的：容易被修改，被绕过；记录太简单，没有上下文信息(比如 pid, uid, sid 等)；无法记录 shell 脚本内的操作；无法记录非登录的操作；难以实现过滤规则；定制 bash 记录方式定制 bash 方式 比较冷门，本质上是为 bash 源程序增加审计日志的功能，开发者可以据此添加一些操作命令的上下文信息，不过很难记录子进程的信息，其缺点和上述的 history 方式类似:容易被绕过，用户可以使用 csh，zsh 等；无法记录 shell 脚本内的操作；过滤规则可能单一；可能需要不停的更新 bash 版本，工作量大，否则容易被发行版替换；snoopy 记录方式snoopy 方式相对新颖，本质上是封装了 execv，execve 系统调用，以系统预加载（preload）的方式实现记录所有的命令操作。更多介绍可以参考以前的文章 snoopy 如何记录系统执行过的命令。目前大部分系统执行命令时都通过 execv，execve 系统调用执行，这点就和会话无关，几乎所有的情况下，只要通过这两个系统调用执行命令，就会将操作行为记录下来，从目前的最新版本（2.4.8）来看，snoopy 有几个优点：难以绕过，只要设置了 PRELOAD，就肯定会记录；无论是否存在 tty 会话，都会记录 execv，execve 相关的命令行操作，包含详细的进程上下文信息；可以记录 shell 脚本内部的操作行为，脚本内的命令行操作大部分都会调用 execv，execve；可以记录操作行为的参数， 比如指定了用户名，密码等；过滤规则丰富，可以忽略指定 daemon，uid，也可以仅记录指定的 uid；如下日志示例：Oct 27 11:34:31 cz-t1 snoopy[24814]: [time_ms:778 login:cz uid:0 pid:24814 ppid:24676 sid:24579 tty:/dev/pts/0 cwd:/root filename:/bin/uptime username:root]: uptime -p上述日志显示 root 用户执行了uptime命令，参数包含 -p对应的进程上下文信息都比较全，不过 snoopy 的缺点 也比较明显，主要包含以下几点：仅支持 execv，execve 相关系统调用的操作；不设置规则可能产生的日志过多，对日志搜集系统造成很大的负担；暂不支持过滤敏感信息规则；在实际的使用中，snoopy 记录方式可以很详细的记录所有的命令操作信息，帮助我们定位很多疑难问题。不过我们也需要通过过滤规则来避免产生过多的信息，snoopy 的过滤规则可以满足以下需求：忽略 cron，daemon 产生的记录；忽略监控用户（比如 nagios，zabbix，promethus 等） 产生的记录；比如以下配置，即可忽略 crond，my-daemon 守护进程，忽略 zabbix 用户：# zabbix uid 为 992 filter_chain = exclude_uid:992;exclude_spawns_of:crond,my-daemon备注：过滤规则在（filtering.c - snoopy_filtering_check_chain）函数实现，由 log.c - snoopy_log_syscall_exec 函数调用，过滤规则为事后行为，即在打印日志的时候判断是否满足过滤规则，并非事前行为。另外，我们在 snoopy 的基础上增加了 exclude_comm 过滤规则，我们可以忽略记录指定的命令，比如以下：filter_chain = exclude_uid:992;exclude_comm:mysql,mongo,redis-cliexclude_comm 指定忽略以 mysql，mongo 和 redis-cli 工具执行的命令，很多管理员或者脚本在使用这些工具的时候常常会加上用户密码信息，这在明文环境中是很危险的行为，exclude_comm 规则简单的避免了常用工具泄漏敏感信息的隐患。auditd 记录方式auditd 记录方式 本身存在内核层面(kauditd 进程)的支持，它实现了一个大而全的框架，几乎能监控所有想监控的指标，不管是按照访问模式，系统调用还是事件类型触发，都能满足监控需求。因为其提供了内核层面的支持，所以本质上比起 snoopy(仅封装 execv，execve 系统调用)要更加强大和健全。生成的日志也容易查看，进程的上下文信息，参数信息都很全面，如下所示：type=SYSCALL msg=audit(1603800704.305:5304075): arch=c000003e syscall=59 success=yes exit=0 a0=1c79fd0 a1=1bf51a0 a2=1bd4450 a3=7ffe7270d320 items=2 ppid=95264 pid=99702 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=571973 comm="mysql" exe="/usr/bin/mysq l" key="command" type=EXECVE msg=audit(1603800704.305:5304075): argc=5 a0="/usr/bin/mysql" a1="-h" a2="127.0.0.1" a3="-P" a4="3301"auditd 整体上为分离的架构，auditctl 可以控制 kauditd 生成记录的策略，kauditd 生成的记录事件会发送到 auditd 守护程序，audisp 可以消费 auditd 的记录到其它地方。其主要的几个工具包含如下:auditd 的策略规则主要根据 -a 或 -w 参数设置，可以将策略规则保存到默认的 /etc/audit/rules.d/audit.rules 配置，也可以通过 auditctl 动态的调整。值得注意的是策略规则的加载是按照顺序生效的，我们在配置例外情况的时候就需要注意将例外情况添加到合适的位置，比如参考 auditd-best-practice 中给出的示例，如果需要忽略 mysql，mongo 等命令工具，就需要将以下策略加到合适的位置（-a always，exit 规则之前）：### ignore common tools -a never,exit -F arch=b64 -F exe=/usr/bin/redis-cli -a never,exit -F arch=b64 -F exe=/usr/bin/mysql -a never,exit -F arch=b64 -F exe=/usr/bin/mongo .... ## Kernel module loading and unloading -a always,exit -F perm=x -F auid!=-1 -F path=/sbin/insmod -k modules ....never 和 always 所能支持的 -F 过滤字段不尽相同, 如果要按照 exe 忽略指定的工具路径, 只能通过 never 实现, exe 为执行工具的路径, 需要设置其绝对值, 这点没有 snoopy 的 exclude_comm 方便.eBPF 记录方式eBPF 在较新版本的 Linux 内核中实现，提供了动态追踪的机制，可以阅读之前的文章 Linux 系统动态追踪技术介绍了解更多动态追踪相关的知识。bpftrace 和 bcc 是基于 eBPF 机制实现的工具，方便大家对系统的调试和排错，bcc 提供了很多工具集，从应用到内核，不同层面的工具应有尽有，比如 execsnoop 即可记录系统中所有的 execv，execve 相关的命令执行：# ./execsnoop PCOMM PID PPID RET ARGS bash 32647 32302 0 /bin/bash id 32649 32648 0 /usr/bin/id -un hostname 32651 32650 0 /usr/bin/hostname uptime 410 32744 0 /bin/uptime其它更细致的记录可以参考 bcc 工具说明。值得注意的是，eBPF 仅适用于 Linux 4.1+ 的版本，以 eBPF 开发的进度的来看，eBPF 在 kernel-4.10 之后的支持才相对全面，线上在使用的时候尽量选择较高内核版本的发行版（比如 Centos 8，Debian 10 等）。另外 Readhat/Centos 7 从 7.6（3.10.0-940.el7.x86_64）版本开始支持 eBPF 特性，不过内核版本较低，并没有支持所有的特性，其主要目的在于试用此技术：总结从上述介绍可以看到，审计系统的操作行为其实就是为了更方便的追溯和排查问题，审计所产生的日志记录本身也可以作为取证的材料。 一些对安全敏感的企业可以通过 auditd 方式来实现不同级别的审计标准。 在实际的使用中，我们建议通过 snoopy 或 auditd 来实现系统操作的审计需求，一些细致的记录追踪可以通过 eBPF 方式实现。 另外也可以将审计的日志发送到 ELK 等日志平台做一些策略方面的告警，不过在具体的实践中，我们需要做好详细的过滤规则避免产生大量重复且收效甚微的数据。
-
-
《从菜鸟到大师之路 Nginx 篇》 《从菜鸟到大师之路 Nginx 篇》Nginx 简介Nginx 是开源、高性能、高可靠的 Web 和反向代理服务器，而且支持热部署，几乎可以做到 7 * 24 小时不间断运行，即使运行几个月也不需要重新启动，还能在不间断服务的情况下对软件版本进行热更新。性能是 Nginx 最重要的考量，其占用内存少、并发能力强、能支持高达 5w 个并发连接数，最重要的是， Nginx 是免费的并可以商业化，配置使用也比较简单。官方网站：http://www.nginx.orgNginx 特点Web服务器高性能的WEB服务器软件，与Apache相比，它支持更多的并发连接且占用服务器资源少，效率高反向代理或负载均衡服务器作为负载均衡服务器，它可以作为HTTP SERVER或DB等服务的代理服务器，类似Haproxy代理软件的功能，Nginx的代理功能相对简单，效率也不及Haproxy，同时它也是一个优秀的邮件代理服务软件缓存服务器Nginx还可以作缓存服务器，类似于专业的缓存软件功能Nginx 优缺点Nginx 优点高并发：能支持1-2万甚至更多的并发连接（静态小文件）内存消耗少可以做HTTP反向代理——负载均衡的功能内置对集群节点服务器的健康性查功能，不过功能相对较弱通过cache插件可以实现缓存软件能够实现的功能Nginx 的缺点Nginx 仅能支持http、https和Email协议，这样就在适用范围上面小些，这个是它的缺点对后端服务器的健康检查，只支持通过端口来检测，不支持通过 url来检测。不支持 Session 的直接保持，但能通过 ip_hash 来解决Nginx 应用场景Nginx 的最重要的几个使用场景：静态资源服务，通过本地文件系统提供服务；反向代理服务，延伸出包括缓存、负载均衡等；API 服务， OpenResty ；对于前端来说 Node.js 并不陌生， Nginx 和 Node.js 的很多理念类似， HTTP 服务器、事件驱动、异步非阻塞等，且 Nginx 的大部分功能使用 Node.js 也可以实现，但 Nginx 和 Node.js 并不冲突，都有自己擅长的领域。Nginx 擅长于底层服务器端资源的处理（静态资源处理转发、反向代理，负载均衡等）， Node.js 更擅长上层具体业务逻辑的处理，两者可以完美组合。用一张图表示：Nginx 到底可以做什么？看完这篇你就懂了！更多关于Nginx常用场景应用配置可参考：请务必收藏！Nginx 五大常见应用场景彻底搞懂 Nginx 五大应用场景！出去吹牛逼再也不担心了Apache VS NginxApache和Nginx都属于Web服务器，两者都实现了HTTP 1.1协议。无论是选择哪个，都是根据应用场景来决定的，所以些文件仅从应用场景出发，来对比两者之间的各自特点。要让正确的工具，做出正确的事。功能对比Nginx和Apache一样，都是HTTP服务器软件，在功能实现上都采用模块化结构设计，都支持通用的语言接口，如PHP、Perl、Python等，同时还支持正向和反向代理、虚拟主机、URL重写、压缩传输、SSL加密传输等。在功能实现上，Apache的所有模块都支持动、静态编译，而Nginx模块都是静态编译的，对FastCGI的支持，Apache对Fcgi的支持不好，而Nginx对Fcgi的支持非常好；在处理连接方式上，Nginx支持epoll，而Apache却不支持；在空间使用上，Nginx安装包仅仅只有几百K，和Nginx比起来Apache绝对是庞然大物。Nginx相对apache的优点轻量级，同样起web 服务，比apache 占用更少的内存及资源静态处理，Nginx 静态处理性能比 Apache 高 3倍以上抗并发，nginx 处理请求是异步非阻塞的，而apache则是阻塞型的，在高并发下nginx 能保持低资源低消耗高性能。在- - Apache+PHP（prefork）模式下，如果PHP处理慢或者前端压力很大的情况下，很容易出现Apache进程数飙升，从而拒绝服务的现象。高度模块化的设计，编写模块相对简单社区活跃，各种高性能模块出品迅速啊apache相对nginx的优点rewrite，比nginx 的rewrite 强大模块超多，基本想到的都可以找到少bug，nginx的bug相对较多超稳定Apache对PHP支持比较简单，Nginx需要配合其他后端用更多更详细的比较说明请参考：Apache VS Nginx，你选对了吗？Nginx 安装本文以CentOS 7.x 系统为例，使用 yum 安装 Nginx。yum install nginx -y安装完成后，通过 rpm -ql nginx 命令查看 Nginx 的安装信息。# Nginx配置文件 /etc/nginx/nginx.conf # nginx 主配置文件 /etc/nginx/nginx.conf.default# 可执行程序文件 /usr/bin/nginx-upgrade /usr/sbin/nginx# nginx库文件 /usr/lib/systemd/system/nginx.service # 用于配置系统守护进程 /usr/lib64/nginx/modules # Nginx模块目录 # 帮助文档 /usr/share/doc/nginx-1.16.1 /usr/share/doc/nginx-1.16.1/CHANGES /usr/share/doc/nginx-1.16.1/README /usr/share/doc/nginx-1.16.1/README.dynamic /usr/share/doc/nginx-1.16.1/UPGRADE-NOTES-1.6-to-1.10 # 静态资源目录 /usr/share/nginx/html/404.html /usr/share/nginx/html/50x.html /usr/share/nginx/html/index.html # 存放Nginx日志文件 /var/log/nginx主要关注的文件夹有两个：/etc/nginx/conf.d/是子配置项存放处，/etc/nginx/nginx.conf 主配置文件会默认把这个文件夹中所有子配置项都引入；/usr/share/nginx/html/静态文件都放在这个文件夹，也可以根据你自己的习惯放在其他地方；Nginx 常用命令systemctl 系统命令：# 开机配置 systemctl enable nginx # 开机自动启动 systemctl disable nginx # 关闭开机自动启动 # 启动Nginx systemctl start nginx # 启动Nginx成功后，可以直接访问主机IP，此时会展示Nginx默认页面 # 停止Nginx systemctl stop nginx # 重启Nginx systemctl restart nginx # 重新加载Nginx systemctl reload nginx # 查看 Nginx 运行状态 systemctl status nginx # 查看Nginx进程 ps -ef | grep nginx # 杀死Nginx进程 kill -9 pid # 根据上面查看到的Nginx进程号，杀死Nginx进程，-9 表示强制结束进程Nginx 应用程序命令：nginx -s reload # 向主进程发送信号，重新加载配置文件，热重启 nginx -s reopen # 重启 nginx -s stop # 快速关闭 nginx -s quit # 等待工作进程处理完成后关闭 nginx -T # 查看当前 Nginx 最终的配置 nginx -t # 检查配置是否有问题Nginx 配置文件Nginx 的配置文件结构如下：# main段配置信息 user nginx; # 运行用户，默认即是nginx，可以不进行设置 worker_processes auto; # Nginx 进程数，一般设置为和 CPU 核数一样 error_log /var/log/nginx/error.log warn; # Nginx 的错误日志存放目录pid /var/run/nginx.pid; # Nginx 服务启动时的 pid 存放位置 # events段配置信息 events { use epoll; # 使用epoll的I/O模型(如果你不知道Nginx该使用哪种轮询方法，会自动选择一个最适合你操作系统的) worker_connections 1024; # 每个进程允许最大并发数 } # http段配置信息 # 配置使用最频繁的部分，代理、缓存、日志定义等绝大多数功能和第三方模块的配置都在这里设置 http { # 设置日志模式 log_format main '$remote_addr - $remote_user \[$time_local\] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; access_log /var/log/nginx/access.log main; # Nginx访问日志存放位置 sendfile on; # 开启高效传输模式 tcp_nopush on; # 减少网络报文段的数量 tcp_nodelay on; keepalive_timeout 65; # 保持连接的时间，也叫超时时间，单位秒 types_hash_max_size 2048; include /etc/nginx/mime.types; # 文件扩展名与类型映射表 default_type application/octet-stream; # 默认文件类型 include /etc/nginx/conf.d/*.conf; # 加载子配置项 # server段配置信息 server { listen 80; # 配置监听的端口 server_name localhost; # 配置的域名 # location段配置信息 location / { root /usr/share/nginx/html; # 网站根目录 index index.html index.htm; # 默认首页文件 deny 172.168.22.11; # 禁止访问的ip地址，可以为all allow 172.168.33.44；# 允许访问的ip地址，可以为all } error_page 500 502 503 504 /50x.html; # 默认50x对应的访问页面 error_page 400 404 error.html; # 同上 } }main 全局配置，对全局生效；events 配置影响 Nginx 服务器与用户的网络连接；http 配置代理，缓存，日志定义等绝大多数功能和第三方模块的配置；server 配置虚拟主机的相关参数，一个 http 块中可以有多个 server 块；location 用于配置匹配的 uri ；upstream 配置后端服务器具体地址，负载均衡配置不可或缺的部分；更多关于Nginx配置文件的介绍可以参考下列文章：史上最全的Nginx配置参数中文说明Nginx 常用配置汇总！从入门到干活足矣Nginx 实践：location 路径匹配如果你平时配置Nginx比较频繁，我推荐你使用这个神器：强大！Nginx 配置在线一键生成“神器”Nginx常用的内置变量Nginx 的进程模型Nginx 服务器，正常运行过程中：多进程：一个 Master 进程、多个 Worker 进程Master 进程：管理 Worker 进程对外接口：接收外部的操作（信号）对内转发：根据外部的操作的不同，通过信号管理 Worker监控：监控 worker 进程的运行状态，worker 进程异常终止后，自动重启 worker 进程Worker 进程：所有 Worker 进程都是平等的实际处理：网络请求，由 Worker 进程处理；Worker 进程数量：在 nginx.conf 中配置，一般设置为核心数，充分利用 CPU 资源，同时，避免进程数量过多，避免进程竞争 CPU 资源，增加上下文切换的损耗。为什么Nginx功能如此强大，可以参考：Nginx为什么高效？一文搞明白Nginx核心原理从 Nginx 优秀的核心架构设计，揭秘其为何能支持高并发？Nginx优化配置其实核心内容主要是通过修改 Nginx 配置文件来进行调优的！Nginx优化配置详解加速 Nginx 响应的 5 个措施！在我们的日常工作学习中，我们会该如何去优化自己的Nginx服务器？遇到以下问题我们该如何处理呢？如何自定义返回给客户端的404错误页面如何查看服务器状态信息如何优化Nginx并发量.......这些问题都可以参考这篇文章的解决方案：Nginx 高性能优化配置实战总结Nginx 是如何实现并发的？为什么 Nginx 不使用多线程？Nginx常见的优化手段有哪些？502错误可能原因有哪些？这种面试问题你肯定是经常被问到。所以，Nginx 如何实现高并发？常见的优化手段有哪些？对于Nginx服务器的安全，在日常使用中也是非常重要的，这里给大家分享一点实践经验：如何构建高效安全的Nginx Web服务器最后给大家分享2个基于HTTPS优化案例：基于 Nginx 的 HTTPS 性能优化实践高性能 Nginx HTTPS 调优！为 HTTPS 提速 30%Nginx 日志相关介绍完了安装、配置、优化这些常用的场景之后，日志这块也是非常重要的，大家都知道日常排错，日志起着举足轻重的作用。Nginx日志主要分为两种：access_log(访问日志)和error_log(错误日志)。通过访问日志我们可以得到用户的IP地址、浏览器的信息，请求的处理时间等信息。错误日志记录了访问出错的信息，可以帮助我们定位错误的原因。error_log /var/log/nginx/error.log warn; #配置错误日志的级别及存储目录 events { worker_connections 1024; } http { .................. log_format main '$remote_addr - $remote_user \[$time_local\] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; #配置日志的模式 access_log /var/log/nginx/access.log main; #配置访问日志存储目 }关于Nginx日志的配置实践看这篇：Nginx 日志配置实践！超详细由于nginx功能强大，性能突出，越来越多的web应用采用nginx作为http和反向代理的web服务器。而nginx的访问日志不管是做用户行为分析还是安全分析都是非常重要的数据源之一。如何有效便捷的采集nginx的日志进行有效的分析成为大家关注的问题。通过几个实例来介绍如何通过filebeat、logstash、rsyslog采集nginx的访问日志和错误日志，我也可以：利用ELK分析Nginx日志。Nginx版本升级这里我们来聊一聊，在企业实际生产环境中经常遇到的一个情况，如何升级Nginx到新的版本和如何回滚至旧版本。版本升级其实就是针对二进制文件的升级，过程如下：[root@nginx ~]# /usr/local/nginx-1.12.2/sbin/nginx -v nginx version: nginx/1.12.2 [root@nginx ~]# cd /usr/local/nginx-1.12.2/sbin/ [root@nginx sbin]# mv nginx nginx-1.12.2 #首先备份原来的旧版本nginx二进制文件 [root@nginx sbin]# cp /usr/local/nginx-1.14.2/sbin/nginx ./ #拷贝新版本的二进制文件到当前目录注：其实升级新版本，最重要的就是平滑升级，让前端用户无感知（也就是不中断服务，这个其实不难，生产中多台依次灰度升级）。对于升级来说，最难的不是升级，而是回滚，因为在实际生产环境回滚的机率是存在，比如：新版本由于某些未知bug导致与现有应用不兼容、或出现运行不稳定的情况等等。所以，对于我们来说，故障回滚是重点。这里给大家推荐我总结的：1分钟搞定 Nginx 版本的平滑升级与回滚Nginx 反向代理与负载均衡反向代理简介反向代理（Reverse Proxy）方式是指以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个反向代理服务器。反向代理是为服务端服务的，反向代理可以帮助服务器接收来自客户端的请求，帮助服务器做请求转发，负载均衡等。反向代理对服务端是透明的，对我们是非透明的，即我们并不知道自己访问的是代理服务器，而服务器知道反向代理在为他服务。配置实例http { upstream product_server{ 127.0.0.1:8081; } upstream admin_server{ 127.0.0.1:8082; } upstream test_server{ 127.0.0.1:8083; } server { #默认指向product的server location / { proxy_pass http://product_server; } location /product/{ proxy_pass http://product_server; } location /admin/ { proxy_pass http://admin_server; } location /test/ { proxy_pass http://test_server; } } }如果你对Nginx 配置中location 的规则不太熟悉，推荐你看看这篇文章：Nginx 实践：location 路径匹配。nginx 每个location都是一个匹配目录，nginx的策略是：访问请求来时，会对访问地址进行解析，从上到下逐个匹配，匹配上就执行对应location大括号中的策略，并根据策略对请求作出相应。所以，有时候就因为在配置时，少些了一个字符“/”，就造成访问不通报错，这种问题是非常觉的故障原因之一，正所谓：Nginx配置中一个不起眼字符"/"的巨大作用，失之毫厘谬以千里，这篇文章详细进了相关的说明与举例验证。反向代理的优势：隐藏真实服务器；负载均衡便于横向扩充后端动态服务；动静分离，提升系统健壮性；Nginx 负载均衡nginx能实现负载均衡，什么是负载均衡呢？就是说应用部署在不同的服务器上，但是通过统一的域名进入，nginx则对请求进行分发，将请求分发到不同的服务器上去处理，这样就可以有效的减轻了单台服务器的压力。配置实例upstream server_pools { server 192.168.1.11:8880 weight=5; server 192.168.1.12:9990 weight=1; server 192.168.1.13:8989 weight=6; #weigth参数表示权值，权值越高被分配到的几率越大 } server { listen 80; server_name mingongge.com; location / { proxy_pass http://server_pools; } }Nginx 实现负载均衡的策略轮询策略：默认情况下采用的策略，将所有客户端请求轮询分配给服务端。这种策略是可以正常工作的，但是如果其中某一台服务器压力太大，出现延迟，会影响所有分配在这台服务器下的用户。最小连接数策略：将请求优先分配给压力较小的服务器，它可以平衡每个队列的长度，并避免向压力大的服务器添加更多的请求。最快响应时间策略：优先分配给响应时间最短的服务器。客户端 ip 绑定策略：来自同一个 ip 的请求永远只分配一台服务器，有效解决了动态网页存在的 session 共享问题。想要高可用？搞定负载均衡架构是关键，关于负载均衡和反向代理的区别可以参考：一文详解负载均衡和反向代理的真实区别，关于 nginx 反向代理和负载均衡策略 实战案例。Nginx 动静分离Nginx动静分离是让动态网站里的动态网页根据一定规则把不变的资源和经常变的资源区分开来，动静资源做好了拆分以后，我们就可以根据静态资源的特点将其做缓存操作，这就是网站静态化处理的核心思路。推荐：CentOS 7.3：LAMP 动静分离部署可以了解一下Apache的配置，然后再回过头理解Nginx的动静分离可更直观。server { listen 80; server_name mingongge.com; location /static { root /wwww/web/web_static_site; } }也可以使用下面的方法location /image { alias /web/nginx/static/image/; }注意:使用alias末尾一定要添加/,并且它只能位于location中使用前后端分离后，可以很大程度提升静态资源的访问速度，即使动态服务不可用，静态资源的访问也不会受到影响。小试牛刀！Nginx 搭建静态资源服务器，这篇文章是给大家介绍整个搭建过程，非常详细。Nginx 高级功能除了负载均衡，Nginx还可以做很多，限流、缓存、黑白名单等重定向配置location / { return 404; #直接返回状态码 } location / { return 404 "pages not found"; #返回状态码 + 一段文本 } location / { return 302 /blog ; #返回状态码 + 重定向地址 } location / { return https://www.mingongge.com ; #返回重定向地址 }示例如下server { listen 80; server_name www.mingongge.com;return 301 http://mingongge.com$request_uri; } server { listen 80; server_name www.mingongge.com; location /cn-url { return 301 http://mingongge.com.cn; } } server{ listen 80; server_name mingongge.com; # 要在本地hosts文件进行配置 root html; location /search { rewrite ^/(.*) https://www.mingongge.com redirect; } location /images { rewrite /images/(.*) /pics/$1; } location /pics { rewrite /pics/(.*) /photos/$1; } location /photos { } }流量拷贝需求：将生产环境的流量拷贝到预上线环境或测试环境，这样做有很多好处，比如：可以验证功能是否正常，以及服务的性能；用真实有效的流量请求去验证，又不用造数据，不影响线上正常访问；这跟灰度发布还不太一样，镜像流量不会影响真实流量；可以用来排查线上问题；重构，假如服务做了重构，这也是一种测试方式；为了实现流量拷贝，Nginx提供了ngx_http_mirror_module模块，这就是 Nginx 又一牛X的功能！流量拷贝限流Nginx按请求速率限速模块使用的是漏桶算法，即能够强行保证请求的实时处理速度不会超过设置的阈值。Nginx官方版本限制IP的连接和并发分别有两个模块：limit_req_zone 用来限制单位时间内的请求数，即速率限制,采用的漏桶算法 "leaky bucket"。limit_req_conn 用来限制同一时间连接数，即并发限制。葵花宝典！一文搞定 Nginx 限流配置缓存Nginx 缓存作为性能优化的一个重要手段，可以极大减轻后端服务器的负载。下面我们将介绍 Nginx 缓存配置的相关指令以及 http 缓存机制，以及 Nginx 缓存实践案例分析。可参考：Nginx 缓存机制详解！灰度发布执行过程：当用户请求到达前端代理服务Nginx，内嵌的lua模块解析Nginx配置文件中的lua脚本代码；Lua变量获得客户端IP地址，去查询memcached缓存内是否有该键值，如果有返回值执行@client_test，否则执行@client。Location @client_test把请求转发给部署了new版代码的服务器，location @client把请求转发给部署了normal版代码的服务器，服务器返回结果。整个过程完成。下面是安装配置过程详细过程：基于 Nginx+lua+Memcache 实现灰度发布这里还给大家推荐一篇文章：基于 Nginx 实现灰度发布与 AB 测试封杀恶意访问看了 nginx 的访问日志，发现每天有好多国外的 IP 地址来访问我的网站，并且访问的内容基本上都是恶意的。因此我决定禁止国外 IP 来访问我的网站想要实现这个功能有很多方法，下面我就来介绍基于 NGINX 的 ngx_http_geoip2 模块 来禁止国外 IP 访问网站。详细的解决方案配置如：通过 Nginx 来实现封杀恶意访问Nginx+keepalived 实现高可用Keepalived软件起初是专为LVS负载均衡软件设计的，用来管理并监控LVS集群系统中各个服务节点的状态，后来又加入了可以实现高可用的VRRP (Virtual Router Redundancy Protocol ,虚拟路由器冗余协议）功能。因此，Keepalived除了能够管理LVS软件外，还可以作为其他服务（例如：Nginx、Haproxy、MySQL等）的高可用解决方案软件。keepalived高可用集群服务安装及配置过程请参考：Nginx+keepalived 实现高可用，防盗链及动静分离配置，写得太好了！Nginx 终极指南介绍用来提高Nginx服务器的安全性，稳定性和性能的12种操作。保持Nginx的及时升级去掉不用的Nginx模块禁用server_tokens项禁止非法的HTTP User Agents禁掉不需要的 HTTP 方法设置缓冲区容量上限限制最大连接数设置日志监控阻止图片外链禁止 SSL 并且只打开 TLS证书加密（HTTPS）重定向HTTP请求到HTTPS以上12个具体的配置过程可参考：提高Nginx服务器硬度的12个技巧Nginx 监控监控Web服务器对于查看网站上发生的情况至关重要。关注最多的便是日志变动，查看实时日志文件变动大家第一反应应该是'tail -f /path/to/log'命令吧，但是如果每个网站的访问日志都是使用这种方式查看也是相当崩溃的，今天小编就跟大家分享一个强大的Nginx日志监控工具。一个小工具帮你搞定实时监控Nginx服务器日常生产环境搭建了Nginx集群后，就需要继续深入研究的就是日常Nginx监控。Nginx如何监控？相信百度就可以找到：nginx-status通过Nginx-status，实时获取到Nginx监控数据后，如何和现有监控系统集成？一个很好的解决方案：Nginx+Telegraf+Influxdb+Grafana即通过Telegraf监控插件定时收集Nginx的监控状态，存储到时序数据库Influxdb中，然后通过Grafana展现即可。这是我发现的又一款管理神器，可以实现配置管理，和性能监控。具体的安装与配置过程，在这篇文章：又一款 Nginx 管理可视化神器！配置、监控一条龙 中介绍过了。
-
