查看，总共加起来差不多10G，没有隐藏目录，那空间被谁吃了？很明显，有空间被已删除文件占用，文件删除了，但是资源没释放之前介绍过一个很好用的命令：lsof，我们可以通过以下命令去查看lsof

netns就是管理命令空间的命令，在学习之前，先了解几个命令unshare、readlink、nsenterunshare运行一些与父级不共享的某些名称空间的程序。root@node3:~#

很多小伙伴想学kubernetes，都会遇到这些问题手里没有可用的服务器打开kubernetes官方文档，看到复杂的组件学不下去今天就介绍一种省钱省时的方式来玩kubernetes准备服务器很多小伙伴电脑配置比较高，可以直接用虚拟机开两台机器，至少得确保自己的电脑16G内存以上我一个穷鬼，用着8G内存小本，没办法，我选择云服务器在阿里云平台充值100块，选择按量付费，每小时3毛钱的2c4G突发性能实例，玩一晚上也就一罐红牛的价格服务器开好就可以开始部署kubernetes了，本文采用kubeadm方式快速搭建kubernetes集群修改系统参数加载br_netfilter模块查看是否加载br_netfilterlsmod

哈喽哈喽大家好，上次初探Loki之后，就决定把ELK下掉，上次的初探文章中，只是简单的对Loki做了一个入门介绍，并且很多小伙伴对于我要把ELK换掉的想法有不同的意见所以这次我来说说我的想法运维的核心目标是保障系统的稳定性和可靠性，而监控是贯穿整个运维生命周期的，为系统的稳定和可靠提供了可观察性及历史可追溯性，可以说，没有监控，运维就是在抓瞎在整个运维生命周期中，监控覆盖硬件/系统级监控、应用服务指标监控、程序运行日志监控、业务监控、链路监控而日志监控主要就是关注程序运行状态，当然，如果涉及业务日志，日志监控也能体现业务运行情况及业务访问量等日志架构通常的做法就是：日志收集日志处理日志存储日志可视化Loki与ELK抉择而在Loki之前，你要问运维开源的日志解决方案，似乎只有ELK不可否认，ELK通过对日志全文索引及列式存储，为日志存储及分析带来极大的便利性但是从另一个角度来讲，这样的便利是通过极高的成本换来的，包括服务器成本和运维成本，而存储的日志中，高价值的日志却很少，这样的成效比是极低的而Loki则恰恰相反，Loki不会对日志数据建立全文索引，取而代之的是对非结构化日志数据进行压缩存储，并且只对日志数据的metadata(时间戳、labels等)建立索引，所以相比ELK，它的存储成本更低，查询效率也更高但是Loki也有缺点，就是如果想实现像ELK一样的复杂度比较高的查询，需要设计好Labels，如果对labels设计不合理，会使Loki对数据流的存储和查询带来极大的挑战，会使Loki崩溃，后面会专门写一篇对Loki的labels进行详细的分析的文章，今天只对Loki数据处理及功能组件进行分析Loki的功能组件Loki包含以下几个功能组件PromtailDistributorIngesterQuerierQuery

MySQL主从搭建分几种场景无业务数据，初始化搭建有业务数据，临时扩展初始化的搭建很简单，不涉及数据业务，所以锁表、停机等都不影响，但是更多时候是业务到一定阶段，才会涉及到横向扩展，需要做主从，读写分离等来提升服务性能这个时候，数据业务不能中断，又需要快速进行扩展提升性能，只能在不停机、不停服务的情况下扩展，就需要用到下面介绍的这种方法来做数据库主从当然还是有前提条件，如果你原本MySQL连binlog及server_id都这种基础配置都没做，那也谈不上不停机配置主从原理不停机实现主从搭建的关键点就是以下两个参数：--single-transaction--master-datamaster-data参数主要用来记录主库的binlog_file和pos，它有两个值，分别是：1:在mysqldump过程中，将binlogfile和pos信息记录在sql中，并且不是以注释信息的方式记录，这样在执行导入的时候自动执行这部分信息2:在mysqldump过程中，将binlogfile和pos信息以注释的方式记录在sql中single-transaction参数则是通过提交单一事务来确保数据一致性，通过在FLUSH

哈喽哈喽大家好上次聊了下关于TIME_WAIT的误区问题，总结优化的方法就是设置链接复用增加tw_bucket队列大小增加可用端口数量快速回收，由于引发的一些问题，不建议配置这些都是系统层面处理TIME_WAIT的方法，在Nginx中，有这么一条配置reset_timedout_connection官方文档这么描述说人话就是，在连接超时后，向客户端发送RST包来直接重置连接，而不是走正常的四次握手断开连接，向客户端发送RST后，不再等待客户端的应答，直接释放这个链接使用的套接字中的所有资源。这样的好处就是服务器端不会产生太多处于FIN_WAIT_1、FIN_WAIT_2、TIME_WAIT状态的TCP连接需要解释下这里说的连接超时，这个连接超时是指相对的和nginx是直连的客户端的连接，也就是一条连接四元组中的src，不是nginx后端超时，也不是客户端请求超时，这个情况存在于网络状况很差的情况，服务端发送请求后客户端不确认的情况这里又引申到另外一个配置，即send_timeout，发送响应的超时时间，因为time_wait只存在主动断开的一方，send_timeout默认时间60s，当nginx向客户端发送了响应，但是一直等不到客户端的确认，超过send_timeout的时间后，nginx将关闭这个连接，这个时候就是nginx主动断开的连接此时，如果nginx开启reset_timedout_connection，就会直接reset这个连接，而不会走正常的四次挥手去断开连接因为这个环境不太好模拟，所以我们通过另一种方式，即return

哈喽哈喽大家好，初探Loki之后，我决定把ELK下掉！Loki开源日志解决方案已经开源有一段时间了，对标EFK/ELK，由于其轻量的设计，备受欢迎Loki相比EFK/ELK，它不对原始日志进行索引，只对日志的标签进行索引，而日志通过压缩进行存储，通常是文件系统存储，所以其操作成本更低，数量级效率更高由于Loki的存储都是基于文件系统的，所以它的日志搜索时基于内容即日志行中的文本，所以它的查询支持LogQL，在搜索窗口中通过过滤标签的方式进行搜索和查询Loki分两部分，Loki是日志引擎部分，Promtail是收集日志端，然后通过Grafana进行展示Loki的官方文档很全https://grafana.com/docs/loki/latest/installationLoki·安装GENERAL

哈喽哈喽大家好，今天要说的话题是关于TCP的TIME-WAIT状态TIME-WAIT是服务器优化必然会谈到的一个话题，而我们常见的问题就是TIME-WAIT过多怎么处理？常见的解决方法就是：1、快速回收2、链接复用而这里有个误区就是到底TIME-WAIT要优化到什么程度，有的童鞋甚至看到TIME-WAIT就觉得需要优化，今天就是想聊一下这个话题要聊明白，还是要从原理来说起TIME-WAIT是TCP链接的一种状态，之前有写文章介绍过TCP的11中链接状态，有兴趣可以再去看下这张图整个展示了所有状态的转换过程，总共分为三个部分，上半部分是建立连接的过程，下面部分分成主动关闭和被动关闭的过程可以看到TIME_WAIT只在主动关闭的过程中出现，实际上TIME_WAIT是TCP为了解决复杂的网络问题提出的一种解决方案解决什么问题呢？看下面两个场景四次挥手中，A

哈喽哈喽大家好，小编今天又有新发现！今天在技术群摸鱼，有朋友问个docker的问题，替换配置文件不生效，也没有原先的Dockerfile，所以就在想，有没有什么方式可以直接从容器或镜像生成Dockerfile虽然docker

，命令全都执行不了了，开始修复这里用的是hyper-v虚拟机，所以把镜像挂载到cd/dvd之后，重启挂上去，可以在设置里面看下之后重启服务器，进修复模式进来之后，有几个选项Install

最近很多小伙伴服务器都被挖矿了，简单总结下在应急过程中，常遇到的一些被挖矿的特征，以及防护方法，工具后面会进行详细的介绍分享问题所在要防止被挖矿，首先要明白挖矿的本质挖矿本质就是快速产出，利用可以利用的资源，实现快速产出，获取收益为什么要明白这个道理，就是因为，挖矿的人，大多不会把时间花费在你的某台服务器上，大多做法是通过网络空间搜索引擎或端口扫描工具等，进行整个网段的批量扫描，根据扫描结果筛选出能够快速自动化拿到权限的机子，再去自动化跑脚本处理比如我通过fofa直接搜索redis，就可以拿到开放了redis，并且可以直接登录的服务器的列表，那我肯定直接导出列表，针对这些ip去拿权限

之前专门写过如何优化你的https，里面总结了几点Nginx下优化HTTPS的方法，最后有两点小的建议，没有详细说明，最近在群里看到朋友发的Nginx配置文件，只配置了证书和密钥部分，所以觉得有必要再把这些刨析一下上图是Nginx官网文档中，关于ssl_session_cache的介绍，ssl_session_cache，就是缓存ssl会话状态的缓存，它有4种模式可选，分别是：off：严格的禁止使用会话缓存none：宽松的禁止使用会话缓存，即虽然nginx不说不允许使用会话缓存，但实际不会将会话缓存下来builtin：openssl的内置缓存，只有一个工作进程可以使用该缓存，官方指出，内置缓存，会导致内存碎片shared：共享缓存，所有worker进程共享这条配置，能带来多大的性能提升？我们抓包看首先实验环境Nginx只配置了证书和密钥，通过wireshark抓包查看不配置ssl_session_cache的完整连接过程可以看到，三次握手完成后，开始建立TLS连接，交换证书、验证证书，详细的TLS连接过程可参考另外一篇文章《Wireshark抓包帮你理清HTTPS请求流程》，这里不多说了，总结完整建立TLS连接过程如下：接着我们在Nginx开启ssl_session_cache，重新抓包可以看到，简单的TLS握手包，完成3个TLS，就建立连接，传输数据，总结简短TLS链接过程如下：可以看到，简短的TLS链接，比完整的TLS链接少了一个完整的往返，如果按照50ms的TTL，那么一次链接就可以节省100ms，效率提升40%缓存如何实现的？在nginx中设置ssl_session_cache之后，就开启了TLS缓存复用，整个过程如下：客户端Client

最近一直在帮客户做web安全分析，每天都有大量的请求日志需要分析，主要是安全日志的分析，很是苦恼，今天发现个好用的工具，虽然比较老，但是，用起来真爽，推荐给小伙伴们——360星图工具是之前360网站卫士下的一个工具，用java开发，目前官网已经没有了，只能从第三方下载单机版本的，需要jdk环境下载后解压，目录结构如下：打开conf下面的config.ini配置文件，修改日志存放路径即可修改完成之后保存，双击start.bat即可运行在result目录下，会生成分析结果直接查看分析报告即可，再也不需要人工去分析，报告常规报告和安全分析报告，常规报告就是普通的日志分析，类似goaccess日志分析安全日志分析是主要的结果还有很多，不一一截图了，分析结果特别详细，又一目了然，可以当作报告直接发给客户了需要安装包的，可以后台回复【360星图】获取话题安全分析，你有什么神兵利器？欢迎文末留言运维技术交流群「运维研习社」建立了运维技术交流群，大家可以添加小编微信进行加群。欢迎有想法、乐于分享的朋友们一起进群交流学习。扫描添加好友邀您进运维交流群●停止维护的CentOS6，怎么使用yum？●DevOps中，你是否漏了这一环？●他清除了我的历史命令|漫画●Nginx的subfilter|漫画

Life)已经有大半年时间了，由于历史原因，还有一些项目无法迁移到7+系统，但是yum源还需要用，而官方于2020年12月2日已经正式将CentOS

现代软件开发对基础设施的管理提出了更苛刻的要求。产品要适应瞬息万变的市场，要求基础设施要有更快的响应速度。而持续交付和DevOps的推行要求产品团队对部署和运维要有更高的自主性。技术的快速进步和演化，也使得基础设施的配置不得不频繁变化。在这种快速变化的过程中，要求基础设施既要灵活，也要安全、可靠。所以衍生出基础设施即代码，通过标准化、自动化、可视化的方式实现基础设施的再生性、一致性、可见性及快速反馈除了我们业务应用、生产环境中的基础设置，开发环境也是最容易被忽视的基础设施我们都应该遇到过上面的场景，即构建本地开发环境中通常会遇到的问题：构建环境需要花费一定的时间和精力环境难以共享环境难以掌握环境难以维护所以我们需要将开发环境代码化，通过DSL的方式，将环境通过代码的方式进行管理和描述，统一项目团队成员之间的开发环境，提高环境构建效率，降低环境维护难度本篇文章主要通过Vagrant+Hyper-v来构建一个Django框架的CMDB的开发环境环境如下：CentOS

最近接到几个应急响应的需求，大多时候都是个人站长或者小企业的服务器，在安全方面都不会做，或者不注重，服务器常年被挂马或挖矿基本拿到服务器之后，如果云服务器，就先做个快照，保存下当时的情况，如果有特殊情况，可以通过快照转镜像，以模板的形式启动一台临时的服务器查看处理前的情况；如果是托管服务器，就只能是跑脚本取证，收集下日志，以备不时之需今天想要说的是关于应急响应中的历史命令的问题在应急响应过程中，首先取证，肯定是通过收集各种日志文件、历史记录等来判断服务器的状况，通常情况下历史命令是最直观的可以看到操作记录的信息，也是最有价值的信息，但这么重要的信息，当然别人是不会给你留下的，所以思考能不能把history记录存一下，大体思路思路其实很简单，总结一句话，实时备份history到其他文件在处理实时备份之前，先对history做个优化处理，我们先看下默认的history记录啥也不是，只记录了执行的命令，其他什么信息都没有，我们看下改造后的结果history中记录了命令数、执行时间、用户、终端、用户登录时间及IP以及执行的命令实现这个很简单，修改历史命令记录格式如下：HISTTIMEFORMAT="%Y-%m-%d

大周五的，马上就要下班了，接到一个需求，一个老网站，需要加SSL证书，改成全站HTTPS，没多想，不就是加个证书么certbot脚本一跑，证书自动配好certbot

文件传输是日常运维中最常见的操作，在linux系统和win/mac系统之间传输文件，我们最常用的，应该是lrzsz工具，通过rz(上传)/sz(下载)，对于平常的小文件传输实在是太方便了如果要传输大的文件，我们通常会选择winscp工具，通过ssh隧道进行传输那么除了以上这些方法，或在没有这些工具的条件下，我们如何简单方便的进行文件传输呢？下面介绍几个方法pythonpython中自带一个轻量级web服务器，在python2中是模块SimpleHTTPServer，在python3中合并到http.server中如图会在当前目录下启动一个默认8000端口的web服务，我们就可以通过浏览器直接访问该web服务，进行文件下载当然在本地通过该方式启动web服务之后，在服务器上通过wget或curl等访问可以实现变相上传文件小技巧：通常从运营商购买的服务器的带宽，是只限制出带宽而入带宽一般会比出带宽限制高或者不限制，这个时候，如果我们上传文件慢的话，我们可以改用从服务器下载的方式，而且服务器一般出端口不限制Nginx/Apache上面python的轻量web服务器，虽然很方便，但是很多时候，服务器都会设置防火墙、安全组等，不常用的端口通常不会开放，这个时候，就可以直接用web服务器了，常见的比如Nginx、Apache、IIS、Tomcat等，都可以我们指定，web访问，就是从服务器下载资源之后，渲染到浏览器的，通过MIME类型进行识别文件，加载渲染，所以，我们利用web服务器将需要下载的文件放到web服务器指定的目录下，然后我们通过服务器ip或已配置的域名，通过浏览器访问该文件，即可下载，如果文件MIME类型被识别，我们可以将文件命名为不可识别的，这样就会直接下载，下载后我们再将后缀改回去即可这样，通常80、443端口肯定是默认开放的，所以不会被防火墙拦截，这里就顺便提一下，打包的备份文件不管是压缩包，还是sql，千万别放web目录下，小心被直接打包下载同样，上传我们也可以在本地起这样的web服务，然后在服务器上进行下载操作scpscp命令通常我们使用是在两台服务器之间通过ssh进行文件传输，很少人知道，scp其实也可以在windows和linux之间进行文件传输，scp命令格式不介绍了，直接看从windows传输到linux的演示查看linux下在windows下面使用scp的前提是，windows要装有ssh类工具，现在win10自带openssh，基本不需要安装，如果是旧系统，直接升级吧nc说到端口监听，除了web服务，nc这个常用的网络瑞士军刀，必然可以做到通常用nc，要么是做网络测试，要么是做反弹shell，而nc有个输入输出指令的操作，比如nc

之前介绍过ModSecurity这款优秀的开源WAF，它是一个入侵检测与阻止的引擎，原本是Apache的一个模块，现在可作为单独模块编译添加到Nginx服务中虽然这款WAF很优秀，但是使用起来并没有那么容易，之前也整理了文章介绍它的原理和规则，然而还有一个问题，就是它的日志分析，之前介绍原理规则的时候，也介绍了它的日志规则，但是在使用过程中，纯文本的记录方式，对于入侵分析太不友好了所以今天介绍一款管理ModSecurity日志的开源项目WAF-FLEWAF-FLE是专门用来处理ModSecurity日志和事件的控制台，管理员可以通过WAF-FLE查看和搜索ModSecurity记录的日志WAF-FLE是PHP写的开源项目，搭建需要LNMP/LAMP环境环境需求：Apache/NginxPHP5.3+php-pdophp-mysqlphp-apcphp-geoipMySQL5.1+安装环境不赘述，只说一个GeoIP库的安装，这里要通过GeoIP库去展示入侵IP信息，所以需要用到这个库，安装很简单，其实就是下载一个dat数据库，从https://www.maxmind.com/en/geoip-demo下载下载后解压出dat文件即可环境准备好之后，从github下载WAF-FLE：https://github.com/klaubert/waf-fle在waf-fle的extra目录下，存放了数据库sql文件，以及Apache的配置文件，如果是用的Apache，直接将这个配置复制到apache配置目录下即可，如果用Nginx，参考下面的配置修改config.php的时候，因为我没有安装apc的缓存扩展，这扩展很老了，所以直接设置APC_ON=false，关闭这个缓存完成上面之后，通过域名访问，即可访问到安装界面这里检查php扩展的时候，如果你不是Apache的话，会有个问题，就是在setup.php的499行，它用apache_getenv检测是否用Apache运行的，如果没运行Apache，这里过不去，我这里是Nginx运行的，所以打开setup.php文件499行，把这部分代码注释掉即可接着点击运行创建数据库这里创建数据库的时候又有个问题，在setup.php代码28行的地方，执行创建函数的时候，引用一个$databaseSchema，这里修改定义了一个位置，但是我放置的是我的位置，所以这里需要根据自己情况进行修改修改完成后，继续通过页面执行创建数据库操作，创建完成如下:安装完成，默认用户名密码是admin/admin，之后，在config.php中配置$SETUP=false，关闭安装之后，重新访问默认用户密码登录之后，就需要修改用户名密码设置完新密码之后，就会跳转到主界面了目前没有数据，现在开始接入日志数据，点击菜单栏的management，添加sensor保存后，即创建好一个sensor，用来接收日志创建好之后，在这个sensor上面，开始配置事件接收器这里选着用mlog2waffle的方式接收日志，然后选着service

之前有很多朋友问关于Nginx的upstream模块中max_fails及fail_timeout，这两个指令，分别是配置关于负载均衡过程中，对于上游(后端)服务器的失败尝试次数和不可用时间，很多人不是很理解这两个参数到底怎么用，以及具体的含义先看官网文档中的描述官网文档中解释max_fails是指在fail_timeout配置的时间内，服务器通信失败的次数，默认为1，即在fail_timeout时间内，1次请求失败即不再尝试，将请求根据hash规则，转发到下一个上游服务fail_timeout有两种含义：当已经确认上游服务不可用时，是指与上游服务器通信失败次数的时间服务器不可用的时间段默认是10s文字不是很好理解，搭建个实验环境，环境如下：NginxPHP-FPM(x2)nginx通过fast-cgi将php请求转发到PHP-FPM，这里PHP-FPM服务即上游服务，设置upstream，负载PHP-FPMupstream按照默认配置，即max_fails=1，fail_timeout=10现在通过tailf分别监听两个PHP-FPM日志请求4次，因为是默认轮询的，所以可以看时间，轮询将请求分发到两个PHP-FPM上游可以从上面的日志中看到，按照轮询规则，下次请求应该落到PHP-FPM2上面，接着，关掉PHP-FPM1，继续请求可以看到，PHP-FPM1肯定是不响应了，PHP-FPM2正常响应，接着看下Nginx日志可以看到，关掉PHP-FPM1后，发起的请求，本来第二次请求(17:49:58)应该分发到PHP-FPM1的，然后从Nginx错误日志可以看到，连接PHP-FPM1失败，这里只做了一次失败尝试，然后Nginx将请求转发到PHP-FPM2处理了接着将max_fails设置为2，继续上面的请求开启PHP-FPM1，继续请求，两个负载轮询转发请求接着继续关掉PHP-FPM1，连续发起多次请求，查看日志所有请求都在PHP-FPM2上，看Nginx错误日志两次轮询到PHP-FPM1的时候，失败，之后不会再将请求分发到PHP-FPM1上游服务接着，不开启PHP-FPM1，继续发起多次请求，由于默认的fail_timeout=10，所以在上面的失败检测10s之后再次发起请求，查看日志继续分发到PHP-FPM2，接着看Nginx错误日志可以看到，过了fail_timeout的时间后，Ngxin会再次将请求发往FPM-PHP1进行尝试，尝试2次失败后，在fail_timeout时间内，不会再将请求分发，这里有几个误区：Nginx记录了连接上游失败，这个请求就返回错误请求，或这个请求丢失没处理这个理解是错误的，Nginx只是记录了失败的请求到日志，并将这个请求又转发到了可用的其他上游服务，知道所有上游都不可用时，才会返回错误状态max_fails是指连续请求失败的次数max_fails是在fail_timeout指定的时间内的失败次数，请求还是按照配置的负载均衡算法来走，并不是第一次请求失败之后，继续将这个请求在尝试一次，达到失败次数之后，标记为不可用fail_timeout越短越好当访问量大的时候，fail_timeout设置太短，会导致不断的尝试与不可用上游的连接，耗费大量的tcp资源进行连接fail_timeout越长越好当访问量大的时候，fail_timeout设置太长，会导致负载不均衡，有可能会击穿某个上游后端，达不到负载的效果如果有更多想法，欢迎关注公众号，回复进群，进群交流扫描二维码关注我们吧

最近有朋友给我发来一个漏洞扫描报告，其中有一项是“Nginx头部攻击漏洞”在绿盟的报告中，可以看到，头部攻击是指，http

2021你有一份礼物待查收往下看文章前可先点击上面文字领取礼物之前写过一篇文章，介绍Nginx如何监控各server流量，主要是通过新增第三方status模块查看所有server及upstream状态进行查看，之后总有人问有没有办法监控upstream并进行告警，所以今天介绍一下，完整的upstream监控及告警方法应用：Nginx/Tengine模块：ngx_http_upstream_check_module监控：zabbix告警：企业微信/钉钉因为默认nginx的upstream是被动式的，不会进行主动监测，所以这里直接用tengine的upstream_check模块如果你是tengine，只要是1.4以上版本，直接默认开启该模块了，如果你是nginx，需要重新编译nginx，添加该模块，编译方法这里不多说了，下载源码，用--add-module添加编译即可upstream_check模块提供主动式后端服务器健康检查功能，下面是该模块提供的一些指令checkSyntax:

最近有朋友做了个网站，网站上面放了几个视频，觉得视频播放慢、卡顿，想让我帮忙优化下，今天就介绍个零成本，操作又简单的方法优化网站上视频播放速度目前很多人网站上放视频，除了用第三方视频平台连接，比如腾讯、优酷、爱奇艺、B站等的视频连接，就是直接将mp4格式的视频放网站目录下，直接嵌入到网站内进行播放，前者缺点就是都有平台广告，后者缺点就是播放慢、卡顿特别是，如果mp4的视频文件的moov

nginx中经常会因为业务需求，需要通过location配置不同的子目录，访问不同的后端，如下这个时候，通常会遇到两种情况，如果说做了动静分离，静态资源单独location来配置，那通常没有问题另外一种情况，就是没做静态分离，这时候，如果通过location

nginx中，ngx_http_status_module(在1.13之前)或ngx_http_api_module中提供了丰富的nginx状态信息，可以作为nginx监控数据，可以更全面的监控nginx，但这两个模块都是收费版本的而在开源版本中，就只能通过stub_status模块来查看nginx状态信息，如图：这信息太少了，作为做常用的web中间件，这点信息显然不够今天介绍一个第三方模块——ninx-module-vts，仓库地址：https://github.com/vozlt/nginx-module-vts该模块是一个nginx的监控模块，能够提供json、html、prometheus格式的数据输出，虽然已经两年没有更新维护过了，但我在nginx1.16仍能编译成功首先clone源码接着在nginx源码包中添加动态模块接着安装模块安装完成，在objs目录下生成了库文件将库文件复制到nginx的modules目录下，在nginx配置文件中通过load_module加载该模块模块添加完之后，就可以享受商业版status模块(api模块)的待遇了，先来看下最基本的状态信息上图就是html格式的状态信息，动态显示，每秒刷新一次，只需要如下配置在http模块中添加vhost_traffic_status_zone接着在vhost中添加status的location如果是zabix监控采集数据，可以用json格式如果是prometheus，可以直接用prometheus的格式输出除了可以提供各种格式的数据输出，它最香的就是可以监控各vhost的流量通常一个nginx的web服务中，会包含多个server，但是通常监控的流量都是服务器总的流量，目前我只能通过分析日志来进行访问量统计，找到流量大的server(如果有其他方式，请留言指教)那么有这个nginx监控模块之后，各个server的流量，一览无余复制一份刚才的配置，添加一个server访问一下之后，查看状态页面可以看到server

之前文章写了用zabbix自动发现功能，自动监控服务器上所有域名的SSL证书到期时间，文章分别是简单脚本监控SSL证书到期时间和配置zabbix自动发现实现自动监控服务器所有域名SSL证书到期时间，有兴趣的可以看下然后有小伙伴说它用的过程中，获取证书到期时间的脚本执行报错如图，报错结果很明显，就是ssl握手失败，协议是sslv3获取ssl证书信息的脚本中，是通过SSL.Context构建上下文对象的，指定使用TLSv1，但是报错是sslv3于是我在本地测试，我本地是没有问题的，我在脚本中添加输出链接协议版本然后输出协议确实是使用了TLSv1，这里get_protocol_version返回就是int型，769是tlsv1于是，我让小伙伴把域名发我，我用脚本执行，报同样的错误在执行do_handshake，握手的时候就报错了，所以也没有输出建立连接的协议版本，没办法，只能抓包看了抓到包，wireshark分析，客户端client

本来想写运维过程中，nginx服务器中time_wait的相关测试及解决方法的，然后发现TCP的状态需要先铺垫一下，于是就整理了这篇文章网上很多大佬整理TCP三次握手、四次挥手，看到过很多人写，但其实从运维角度来说，我们分析TCP链接状态的时候，首先是用netstat或ss来查看之后才会根据TCP状态的情况进行抓包分析，进一步确认一些问题，所以我们首先看到的会是TCP的状态，那么就需要很清楚的了解TCP的11种状态代表着什么TCP的11种状态分别对应TCP三次握手过程的5种状态和TCP四次挥手断开过程中的6种状态如上图，就是11种状态，在整个TCP建立连接和断开连接的整个过程下面我用tcpdump抓了个完整的客户端和服务端的三次握手和四次挥手的包，可以对应上面的状态图下面分开来详细看，首先是三次握手上面这个图就是完整的三次握手过程首先由client发出请求连接，即SYN=1

上面截图的这块日志，是CentOS7系统，messages中的一段日志，很多人在排查问题的时候，看到messages里面大量的这种类型的日志，都是一脸懵逼，搜索引擎一搜，也没有上面结果，大多说这是正常的日志，不用担心，如果需要关闭，redhat官网有提示如何关闭还有一些说这是有用户登录系统，当然，redhat在其官网solutions关于这个问题的回答中，也表明，这些消息是正常的，是用户每次登录都可以看到的消息，要禁止这些日志显示在messages中，可以使用rsyslog中的过滤器进行丢弃看到是用户登录产生的日志，很多人就会说，是不是我的服务器被暴力破解了，这么多登录日志上面的说法，不能说错，但不全面，所以，整理了这篇文章这部分日志，记录了大概以下几个信息为用户创建slice启动用户会话启动了用户会话删除用户会话删除用户slice停止用户slice总体就是这几个部分，但是这几个部分不一定会每次都按照这个顺序出现，后面慢慢来讲，接着往下看首先来说这个slice，我们都知道，CentOS7上，是用systemd进行资源管理的，而slice是systemd下面的控制组单元我们从上面的图可以看到，首先就是为用户创建了一个slice文件，这个以".slice"为后缀的单元文件，是用于封装管理一组进程资源占用的控制组的slice单元这类单元，是通过在cgroup树中创建一个节点实现资源控制的，对slice单元施加的资源限制，将会作用于这个slice单元所包含的全部进程的集合，全部的slice单元按照树形层次结构组成一棵资源控制树，干巴巴的文字，你可能不太好理解，上图看这个就是系统中的slice我们这里关心的是用户的slice，所以我们看用户的slice，通常用户的slice，中间那个数值是用户的uid，我这个虚拟机只有root用户，看下root用户的slice看一下，是不是对于一个用户资源进行了控制，以组管理，以CGroup树型层次结构这里顺便说下，为什么上面说，日志中这几个部分不一定会同时出现，通常一个用户第一次创建了slice，没有删除之前，后面这个用户再开启会话的时候，不会再创建slice，只会开启会话，所以日志只有开启会话和，开启了会话root用户第一次登录的时候，创建了slice下面是后面用户登录的时候，messages记录的日志，启动会话用户退出的时候，就会删除用户会话如果想看slice文件的话，可以在/sys/fs/cgroup下面，对应各个资源组下面，看相应的slice的资源限制接着往下看，什么时候会删除slice，我们先创建个用户，我这里用nginx用户，设置允许远程登录，接着登录，看下messages日志看下这个slice接着，退出nginx登录，可以看到，nginx的slice被删除了通过上面这部分，最起码应该了解了这部分日志的意思了，接着继续上面说的都是用户登录的时候，产生的这些日志，为什么我在文章开头，说这个说法不全面呢，上面nginx退出的截图中，我故意截取了中间有一个root用户的Started

在nginx中，经常需要因为各种原因，修改header，所以今天整理下nginx中header的一些指令header是http中的消息头，里面包含很多信息，通常又分为request

上篇文章"简单脚本监控SSL证书，到期告警提醒"发布之后，不少朋友说项目少的情况还好，在zabbix中手动添加监控项和触发器就可以，但项目多的时候，一条一条添加，就有点不合适了所以今天再介绍个方法，不用手动添加，不管你有多少项目，自动收集这里用到的就是zabbix的自动发现规则，操作很简单，流程如下：从web配置文件中获取域名编写监控脚本，输出json格式创建zabbix模板添加自动发现规则主机绑定模板验证结果1获取域名获取域名思路很简单，通常情况下，有证书的web配置，都监听443端口，所以可以通过python脚本，从web配置文件中，将监听了443端口的vhost中的ServerName字段拿到就可以了，当然，如果你监听的是其他端口，就通过其他端口去匹配，这里肯定是用正则去匹配比如我要读取apache中配置了证书的vhost，我写的正则模型如下：通过以上简单的一个脚本，我就拿到了配置文件下所有配置了证书的域名的一个列表，如果你是nginx，一样的方法，读取配置文件，获取listen是443端口的配置，拿到域名，至于怎么拿要具体看你nginx配置文件的写法，这里就不多说了2输出json格式zabbix编写的脚本，要用于自动发现，输出格式必须为json格式，而且键一定要是data，所以通过python脚本，将第一步得到的ServerName格式化输出为json，脚本如下这样经过格式化后输出的json，zabbix才能识别，在zabbix_server端通过zabbix_get获取数据测试当然，能在server端获取到数据的前提是，将上面写好的脚本，添加到zabbix_agent配置中，添加为UserParameter3创建zabbix模板上面添加玩玩脚本，从server端可以获取到数据之后，就可以在zabbix的web端添加模板了，配置——模板——创建模板创建一个模板，模板名称自己定，其他的选项没有需要特别说明的，按自己的情况来然后这个模板中，不需要创建任何东西，只需要创建自动发现规则创建自动发现规则的时候，名称同样看自己(我比较土，就这么随意)，类型要选zabbix客户端，键值比较重要，键值就是你在zabbix_agent中配置的UserParameter的key，也就是这个自动发现规则的数据，需要通过这个key来返回数据，或者说获取数据添加完成后，就要开始添加监控项原型了自动发现规则中，可以用自定义宏，从上面的脚本中可以看到，我把ServerName自定义为{#SERVERNAME}，所以在添加监控项原型中可以使用该宏，名称和键值中通过使用该宏，动态获取要监控SSL的域名这里名称也是自己定，用这种宏的方式，在告警的时候，可以更方便直观，键值这里用到的就是之前文章中的脚本，通过传{#SERVERNAME}获取到的域名给脚本，脚本返回证书到期时间监控项原型添加完，就可以添加触发器类型了这里是小于30天警告提醒到这里zabbix模板就创建好了4主机绑定模板主机绑定模板简单说下，上面模板配置好之后，选择要添加该模板的主机，在主机的模板中，链接刚才创建的模板就可以了5查看数据，验证结果模板链接好之后，就可以通过监测中的最新数据查看返回结果了当然，这个数据返回的时间，要根据你配置的模板中，更新间隔来定，开始测试，可以将时间设置短一点，测试没问题后，因为是SSL检测，不需要那么频繁检测，所以可以按天来设置更新间隔，减轻zabbix压力上面模板链接后，如果数据没有返回，可以通过主机中的监控项中的状态和信息提示进行相应的调整通过zabbix模板及自动发现，就可以很方便的自动监控添加的域名，不需要一个一个添加，也不用担心web中配置后，忘记在zabbix中添加如果觉得有用，请关注、转发、在看三连！！！扫描二维码关注我们吧

随着https的普及，或者说被强制使用，需要维护的SSL证书越来越多，而且由于各种原因吧，需要在各种不同的平台申请维护证书，时间长了，总有证书忘记续签有些使用了letsencrypt自动续签，但是某些原因，并不稳定，经常续签失败，letsencrypt的邮件通知有时候又会被忽略掉所以写了个简单的证书监控的脚本，结合zabbix进行监控，到期提醒续签脚本很简单，就三个方法，获取证书、获取证书时间，获取到期天数网上有人用load_cerrtificate，结合ssl.get_server_certificate(url,port)来获取证书，其实这个获取到的证书是不对的，这里获取到的证书是解析完url，解析到对应服务器，获取服务器上443端口访问到的第一个证书，并不是传入url的域名的证书所以这里通过socket的方式，建立连接，获取对应域名的证书，再获取证书的信息脚本放zabbix_agent里面，配置key在zabbix_server用zabbix_get验证在zabbix中添加监控项，ssl监控频率不需要设置太密，按天，或者按周检查都可以接着添加触发器，检测到SSL剩余一个月提醒续签到期企业微信告警脚本很简单，不用zabbix的话，通过添加定时任务的方式也可以做，如果项目多的话，手动添加不合适，可以通过脚本获取web下面的server_name作为参数进行监控关于pyopenssl包更多信息可查看文档https://www.pyopenssl.org/en/stable/introduction.html推荐阅读Filebeat自定义pipeline，完美处理自定义日志字段

之前介绍过Harbor，从安装部署到简单使用，今天这里就不再重复介绍了，有需要的可以跳转到'Harbor

filebeat是本地文件日志数据采集器，通常用作ELK中的日志采集，将采集的日志数据传输到elasticsearch，当需要进行数据处理时，先传入logstash，经过logstash处理后再存入elasticsearch当filebeat收集的日志量大，传输到elasticsearch来不及处理时，需要先传到kafka或redis队列，再存入elasticsearch这是目前很多ELK的架构，但现在的filebeat，已经不在只是日志收集工具，它内置了很多模块，可以做到日志收集、解析整个过程，目前支持的日志模块已经覆盖很全了基本流行的中间件、应用日志，都有覆盖到所以对于基础日志，现在完全可以用filebeat进行数据解析，而不需要自己再去logstash写匹配filebeat可以将数据进行预处理，然后输出到elasticsearch。filebeat对数据的解析，都是通过ingest节点进行预处理，filebeat中默认定义了ingest的pipeline这些pipeline，都在filebeat安装后的/usr/share/filebeat/modules各个模块下进行定义如果你的日志格式是默认的，没有进行自定义，那么filebeat自带的pipeline解析完全够用，并且处理的很好，比如nginx日志处理后的字段截图中只是很少一部分，在filebeat的nginx模块中包括了http、host、agent、source等所有字段的解析，如果使用的是默认的日志格式，完全不需要你手动解析，可以通过filebeat的解析，组合出一套炫酷的Dashboard但是，很多时候默认的模板无法满足我们的需求，我们需要添加一些字段，或者一些自定义的字段，这个时候，我们需要去手动修改pipeline，或者手动写一个pipeline，添加对应的procesors来处理对应的日志字段举例来说，通常nginx前面我们会添加CDN，这样在nginx日志中，通过remote

在linux中，我们通常用time命令来计算某个程序或某个命令、脚本的运行耗时，比如我需要查看ps命令执行时间通常会在命令执行结束后，输出统计结果，统计结果中有三个统计时间，分别是real、user、sys，详细解释如下：real：从进程

最近有朋友说，查看nginx访问日志，发现大量的恶意扫描，分析发现比正常业务访问量都大，且IP大部分来自国外，服务器用的按量付费，这刷的都是白花花的银子，想问下有没有解决方案今天就介绍几种方法，来屏蔽这些脚本小子的恶意扫描GeoDNSGeoDNS是基于地域的DNS解析，可以将DNS的解析，根据地域划分，解析到不同的IP地址，现在很多免费的运营商都支持GeoDNS，比如google的Route53、阿里云的智能dns、腾讯的DNSpod、华为云等，都有这种服务，通常我们是用来做地域访问控制的，不同的地区用户，访问就近地区部署的服务对于上面提到的恶意请求，大多来源于国外，而业务根本不可能有国外用户的情况下，可以直接将国外的dns解析到随便找个国外的IP上面，可以是一些DNS节点IP或者其他，也就是将恶意请求的IP引入黑洞这种方法不需要技术、不需要配置服务器，从根源上直接解决防火墙屏蔽这里说的防火墙是服务器内置防火墙，防火墙本身就是起屏蔽、拦截作用的，我们可以通过配置防火墙来进行屏蔽国外的IP，或恶意IP在linux中我们通常都是通过iptables来封IP，首先我们需要获取所有的IP地址段，才能进行封IP的操作IP地址段，我们可以通过APNIC获取，APNIC是全球5个地区级的Internet注册机构之一，主要负责亚太地区，而且每日更新，信息列表地址：http://ftp.apnic.net/apnic/stats/apnic/delegated-apnic-late思路就是使用Iptables添加CN部分的IP到ACCEPT规则中，其余的全部DROP，这里有个问题就是，即便只是添加CN部分的IP段，量也比较大，这样逐条添加和加载IPtables规则的时候，很影响并发性能在iptables中，包含几个表，每个表由链组成，默认是filter表，最常用的也是filter表，另外一个比较常用的是nat表，封IP就是在filter表的INPOUT链添加规则在进行规则匹配的时候，是从规则列表中从头到尾一条一条进行匹配，所以当规则太多的时候，加载就会影响性能，所以这里推荐用ipset的方式，ipset能把这种O(n)的操作变成O(1)，就是把要处理的IP放进一个集合，对这个集合设置一条iptables规则ipset可以直接通过yum安装，安装完成之后可以创建ip集合通过创建一个ip集合，然后再通过iptables将来源为这个集合中的IP允许，其他的全部DROP掉集合有了，内容还需要添加，ipset通过ipset

今天就介绍个工具——lazydocker，玩docker的懒人必备，不多说，直接看图lazydocker具体特性如下：全视野查看

之前介绍了多种nginx调试工具，今天介绍nginx性能分析工具——gperftoolsgperftools是google_perftools，google开发的一款非常使用的工具集，主要包括性能优异的malloc

之前介绍过Nginx通过cookie做灰度发布，通过判断cookie，将不同的请求根据需求分流到不同的后端，如图上面的方法是通过判断cookie来进行分流的，其实在Nginx中专门有个模块是做客户端分流的——split_clients在nginx官网文档中，定义split_clients是可以用来构建适用于A/B测试的变量它这句话，如果你没使用split_clients的话，比较难理解，其实它就是定义了一组变量，通过使用变量来进行分流如果你读了上面通过cookie做灰度发布的话，里面有关于nginx中map的介绍，你会发现split_clients和map定义变量是一样的，只不过，它这里还有一个hash算法的配置比例split_clients是通过MurmurHash2算法对原始字符串进行哈希处理，源码在http/modules/ngx_http_split_clients_module.cMurmurHash算法在core/ngx_murmurhash.c就这么一段，murmurhash是一种非加密型哈希函数，由Austin

之前介绍了Nginx的两种开源waf，Naxsi和ModSecurity，有人担心直接上生产会不会有问题，拦截正常请求，我想说——那是必然会影响的现在大多WAF都是通过规则匹配请求特征，有规则，肯定就不会那么智能的避开所有正常请求，只拦截恶意请求，虽然现在有百度的openrasp等不依赖于请求特征的运行时攻击检测工具，但是也不能做到完全准确的拦截攻击或恶意请求怎么才能比较友好的在线上接入Naxsi或ModSecurity开源waf？这里就要参考网络防火墙，或者入侵检测系统的方法，通过流量镜像的方式，在网络故障处理中，为了更好的分析定位网络问题，我们通常会做流量镜像或者端口镜像，来保存镜像流量，用于分析恶意请求、或抓包故障定位等，我们web上也可以通过这种方式来做怎么做呢，有很多开源的流量复制/镜像工具，比如gor、tcpcopy等，都可以用来做流量镜像但是在Nginx下面，你就没必要这么麻烦了，Nginx早在1.13版本的时候就添加了ngx_http_mirror_module模块，就是用来做流量镜像的Nginx的流量镜像模块，很简单，就两个指令mirror用来指定请求将被镜像到哪个uri，可以指定多个镜像，uri也可以用相同的，相同的uri就表示将流量放大了一倍，也就是多复制了一份流量到uri，这个也是可以用来测试流量放大的情况下，后端的负载情况，简单演示先看下不放大的情况下，请求看下可以看到，是镜像一份请求，接着配置放大一倍，继续监听日志，查看效果镜像两份请求，所以这个情况就能达到放大流量的效果这里有个小的问题需要说一下，就是mirror是不支持access_log记录的，所以我这里是通过代理到另外一个server，通过另外一个server记录日志进行查看的，这个是一个需要注意的地方流量镜像的另外一个指令就是mirror_request_body该参数是指定是否镜像request_body部分，默认是开启的，官方文档中说，这个指令和proxy_request_bufferingfastcgi_request_bufferingscgi_request_bufferinguwsgi_request_buffering指令冲突，开启之后会禁用以上指令使用该指令一定要保证mirror_request_body、proxy_pass_request_body和Content-Length配置一直，比如mirror_request_body或proxy_pass_request_body设置为off，则Content-Length必须设置为“”，因为nginx(mirror_request_body)或tomcat(mirror_request_body)处理post请求时，会根据Content-Length获取请求体，如果Content-Length不为空，而由于mirror_request_body或者proxy_pass_request_body设置为off，处理方以为post有内容，当request_body中没有，处理方会一直等待至超时，则前者为off，nginx会报upstream请求超时nginx的流量镜像配置就是这么简单，它的流量镜像是只复制镜像，发送到配置好的后端，但是后端响应返回到nginx之后，nginx是自动丢弃掉的，这个在官方文档介绍中就有，这个特性就保证了，镜像后端的不管任何处理都不会影响到正常客户端的请求结合这个特性，我们就可以把waf配置在镜像流量下之前介绍waf的文章中有waf配置的方式，这里就不多介绍了，想看的，可以看文章开头，也可以看文章后面推荐通常waf中，拦截掉之后会返回403给客户端，当然也可以自定义，完后会记录拦截日志，利用这种机制，将waf配置在流量镜像下使用一段时间后，就可以从日志中分析出哪些正常请求会被拦截掉，从而修改waf规则，然后接入到生产数据中，这样可以有效的避免waf的FRRNginx的流量镜像当然不只这种用法，反正流量都给你复制出来了，玩法就比较多了，可以用于预生产环境的测试、利用流量放大进行压力测试等推荐阅读Nginx的WAF——Naxsi

最近HackerOne公布的Nginx内存内容泄露问题以及目录穿越漏洞，复现看下具体情况按照公布的消息，这次的漏洞主要是存在于两种情况下nginx下主要是空字节在rewrite的时候未处理，在内部rewrite的时候，如果response的location部分内容超过实际的长度，结尾部分就会读取到内存里面的内容openresty下面是在rewrite的时候，使用set_uri进行重写处理的时候，没有处理空字节，导致内存内容泄露，以及在rewrite的时候，如果rewrite目标地址，用变量获取的方式，会导致目录遍历目前受影响的版本：nginx

通常情况下，不管是使用云服务器，还是物理服务器，根目录不会设置太大，很多docker使用者会遇到一个问题，就是默认所有的资源存储在/var/lib/docker下面，使用一段时间后，就会发现磁盘空间不足，主要是容器的日志文件、下载的镜像等所以在必须将docker的默认存储位置改成比较大的盘，才能满足日常使用场景，下面介绍几种方法来修改docker默认存储位置配置文件修改首先第一种，也是最推荐的一种，就是修改配置文件，这里分两种情况，一种是你首次安装docker，还没启动的情况下，可以直接在配置文件中指定存储位置，我这里用的docker-ce

那么对于nginx，对于php-fpm，backlog应该设置多大，是越大越好吗？backlog怎么设置合适？这是上篇文章中遗留的几个问题接着上篇文章Nginx高并发调优中常被忽略的参数中，最后部分，通过查看nginx源码发现nginx源码中定义backlog为511，其实在php-fpm配置文件中，同样默认backlog是511包括redis，在默认配置文件中也有backlog配置，默认也是511其实在redis注释中已经解释很清楚了，当你需要处理高并发得场景时，需要较大得backlog来处理堆积得请求，上篇文章对原理已经做了较全面的解释，网上也有很多大牛关于tcp全连接、半连接的文章讲解，今天主要想测试下，backlog在优化设置时，应该怎么设置为了尽量排除带宽影响，我这里直接用两台内网的机子，一台作为客户端用ab去请求，另外一台作为服务端，服务端是一台centos7，没有优化过的系统首先说一下ss的Recv-Q和Send-Q在ss命令的结果中，如果该条记录为监听端口，则Recv-Q表示accept队列中元素的个数，Send-Q表示accept队列中队列的容量，所以从监听端口这行正好可以看到队列的情况接着开始测试，第一步，先就默认backlog为128的情况下，用ab进行测试直接开了两个窗口，用watch执行ss命令，0.1s刷新，在客户端用ab

在nginx或php-fpm优化的时候，经常会碰到一个参数：backlogbacklog是什么？在nginx官方文档中定义如下：在php-fpm中解释如下：从上面的解释来看，就是定义了一个队列，并设置了队列长度，那么这个队列是做什么的，接着往下看不管是nginx还是php-fpm中backlog配置的地方都是在listen指令的位置，为什么是在listen指令的位置配置，通过一张图来看下我们知道，listen是用来创建一个监听，打开一个端口、文件描述符，用于等待客户端请求，上面这张图是TCP内核的请求过程client发送SYN到server，将状态修改为SYN_SEND，如果server收到请求，则将状态修改为SYN_RCVD，并把该请求放到syns

HTTP协议经过发展，目前HTTP2.0作为主流HTTP协议，已经得到一定普及，虽然国内仍然有很多连HTTPS都没上的网站，但不影响HTTP协议的发展。HTTP2.0我们知道相较于HTTP1.1版本的协议，进行了很多的优化，可以参考之前公众号的一篇文章《如何优化你的HTTPS》，里面有关于HTTP2.0的优化方面的所有介绍，现在HTTP-over-QUIC出了也有一段时间了，虽然还是实验性协议，但是IETF

很早就关注serverless了，刚开始关注serverless，不是因为它是新技术，也不是有什么特性吸引我，只是因为他们宣传serverless是“无服务器”，作为一个运维，服务器都没了，还搞毛线冲着无服务器，就开始了解和接触serverless，serverless总得来说，它不是一种编程框架、类库或者工具，也不是不需要服务器。它是一种软件系统架构思想和方法，它的核心思想是用户无须关注技术支持应用服务运行的底层服务器，我认为它的出现是继docker之后又一个颠覆性的思想和架构serverless所谓的无服务器，并不是说基于serverless架构的软件应用不需要服务器就能运行，这里指的无服务器，是指不需要开发者关注有关底层服务器等基础设施，开发者开发的应用所需要的计算资源由底层的云平台提供，即便是私有的serverless也是由底层提供计算资源，不需要开发者过多的考虑传统的应用部署场景里面，当用户完成了应用开发后，软件应用将被部署到指定的运行环境，这个运行环境一般是以服务器的方式体现，可以是物理机、虚拟机、容器。用户需要根据业务规模来申请一定数量、一定规格的服务器以满足应用的需要，应用上线后，根据实际的运营情况、负载情况，用户需要不断的扩缩容以应对高峰、低估的访问量。上面这些都是运维需要去日常做的事情那么到了serverless架构下，开发完成应用开发后，软件应用将被部署到指定的运行环境，这个运行环境不再是具体的多少台服务器，而是支持serverless的云计算平台，当有客户端请求到达或特定时间发生时，serverless平台负责将应用部署到平台的某台服务器或主机中，由serverless平台提供保证应用正常运行的计算资源，高访问量时自动增加实例，空闲后自动卸载应用，并回收资源，运维需要干的事情全干了而且serverless架构中部署和运行不再是一个整体的jar包，或是一整套业务代码，而是以函数作为部署和运行的基本单位为了防止文字太多，看个阿里云云函数的入门案例，或许对serverless会有更明确的理解图上是阿里云云函数中的hello

上篇文章中介绍了nginx的一种waf——naxsi，其中说到Nginx的执行阶段，这篇文章接上在了解nginx的执行阶段前，先看一个例子对echo不熟悉的，可以先看文章Nginx调试必备了解下echo扩展回到上面这个例子，在server块中配置这样的location，你觉得输出是什么样子？按照正常的逻辑，输出应该是32

之前的文章中介绍了nginx的一种waf，是添加modsecurity模块来作为nginx的waf，功能很强大，nginx官方plus版本中其实也是用modsecurity作为waf的，但是modsecurity对于普通用户来说配置相对复杂，特别是它的规则，所以，今天推荐一个开源、高性能、低规则维护的waf——NaxsiNaxsi用于防护XSS和SQL注入以及RFI、文件上传、CSRF，这些都是web安全中最常见的攻击方式，它是一个第三方的nginx模块，依赖于libpcre，与任何nginx版本都兼容为了验证它的功能，我先通过docker，起一个dvwa，用没有安装Naxsi的nginx反代这个dvwa，先用sqlmap跑一下。然后在nginx上安装Naxsi，之后同样用工具跑一下，看下两次结果对比，这个就是整体的一个思路，废话不多说，开搞！未安装前测试先docker

Nginx作为一个流行、轻量、高性能、稳定的web服务器，是应用运维日常最常接触的web服务器，更多的时候它是用于web代理服务，今天要说的是日常维护Nginx中最常遇到的两个HTTP状态码502和504502

Devops和k8s的火热，越来越多的企业将docker运用到自动化运维中，不管是为了保证开发、测试、生产环境的环境一致性，还是和CI/CD工具的集成度，比如jenkins对docker或k8s的自动构建部署等，亦或利用docker进行自动化测试等那么，在现在这种随随便便一天动辄几十次的快速构建迭代中，镜像作为一个贯穿整个自动化过程中的一个关键，怎么保证自动化构建部署的效率？就是镜像尽可能的小要保证镜像尽可能小，可以从五个方面基础镜像小层级尽量少去除不必要复用镜像层分阶段构建基础镜像小基础镜像小，主要是保证镜像层底层或者说From的镜像本身小每个企业或个人使用容器，都是应对不同的业务场景，没有完全一致的业务场景，所以你最好不要直接用别人的第三方镜像，除非你了解该镜像的所有层级内容，而且从安全角度考虑，也尽量使用官方镜像，它没有太多第三方的，你不需要的东西，你可以在此基础上增加你的业务部分内容选择Alpine镜像代替Ubuntu、CentOS、Debian等镜像虽然Alpine没有其他系统完备的库、依赖，但是基本的应用它都是支持的，都可以通过apk去安装(apk包管理)

docker在实际使用中，让运维人员诟病的，除了安全问题外，大概就是数据的问题了很多人在初用docker的时候，很多时候都忘记或不知道docker中需要保留的数据需要挂载到宿主机文件夹到容器内部对应目录（当然除了挂载宿主机目录，还有其他解决方案，我们后面会有文章介绍）当容器因为某些原因挂掉、无法重新启动的时候，他们就认为数据丢失了，找不回了，这也是很多人对docker的一个认识误区，网上没有一篇文章说docker数据的问题，今天详细解释下，docker数据在哪里首先说一下这边以docker-ce