一、docker中的php定时任务用法及docker不重启容器平滑加载nginx和php
之前在一篇文章中提到写docker的定时任务，最后的方案是使用ps命令查找到php端口来实现找到唯一的PHP容器，后来想想不好，因为只是要找唯一PHP容器，通过docker的NAMES过滤就可以了。因为这个容器名称NAMES字段在启动的时候就要求是唯一的，而实际在执行docker的时候完全可以使用names字段（注意不是grep匹配，而通过这个字段精确执行任务）
#之前的方法
docker exec `docker ps -a | grep '9000/tcp' |awk '{print $1}'` /usr/bin/php php_command
#实际完全可以使用容器名称
docker exec -it PHP_CONTAINER_NAME /usr/bin/php php_command在docker中对容器进行了修改之后，经常需要对容器进行操作，可能方便的命令就是对容器进行重新restart，但是这样实际上就造成了业务中断。在docker中对nginx和php容器都有平滑重启的办法，使用如下：
docker exec -it PHP_CONTAINER_NAME kill -USR2 1
docker exec -it NGINX_CONTAINER_NAME service nginx reload
二、docker中搭建的nginx+php中php代码不解析执行
使用docker搭建的nginx+php的测试环境，但在执行的时候发现PHP文件文件竟然没有解析，php源码输出，之前解决过同样的问题，但今天的问题进行了配置修改排查竟然都没有行得通，配置文件如下：
location ~ / {#add_header yes "ttttt";try_files $uri /index.php$is_args$args;
}location ~ \.php$ {include fastcgi_params;fastcgi_pass 172.17.0.1:9000;root /var/www;fastcgi_param SCRIPT_FILENAME /var/www$fastcgi_script_name;fastcgi_split_path_info ^(.+\.php)(/.*)$;
}php文件源码输出，且在php的日志中未看到有nginx请求过来，且我在php容器中执行文件能正常解析，所有从结果导向来看，nginx未正确向php转发请求，我在nginx的日志中进行添加输出$upstream_addr $upstream_statu字段信息从而确定是否向php转发请求，发现确实未转发。另外此处的另一个检查方式是直接在向php转发的location块中添加：
return 200 /var/www$fastcgi_script_name;
这类内容，如果转发到此处，则会直接在浏览器显示上面的内容。nginx为什么没有向php转发请求呢？在其它各种调试未成功的情况下我将location ~ /中的~去除，发现能正常解析了。但我在location ~ /中执行add_header不管有没有~都会执行下面的try_files,~表示执行一个正则匹配，区分大小写, 不管有没有~都匹配到了这里，而如果有~则不会匹配后面的php匹配，从这个结果导向来看， ~/匹配会终止后面的location匹配。但也许有其它我未了解的原因吧。做个记录。
三、nginx服务器上出现400错误的原因
服务器上出现一些请求失败，但排查nginx日志却也没有看到有新的错误日志，很是奇怪。然后通过URL定位找到了请求日志，发现在nginx的访问日志中看到有返回状态值为400的请求，HTTP/1.1对400 Bad Request的定义是语义有误或者请求参数有误，其中语义有误指当前请求无法被服务器理解。
一般导致400异常的场景主要有两类情况：请求头过大和无效的请求。无效的请求我们可以不用去理会，比较重要的就是请求头过大。我这边报400的请求是文件上传接口的问题，我初步估计是请求头过大的原因。请求头过大导致的nginx 400 Bad request指的是request header过大所引起，request过大，通常是由于cookie中写入了较大的值所引起。在nginx.conf中，可以通过调整client_header_buffer_size和large_client_header_buffer参数大小可以解决, client_header_buffer_size设置项用于读取客户端请求头的缓冲区大小，对于多数请求缓冲1K字节是足够的，然而如果一个请求包括Cookie，或来自一个WAP客户端，它可能远不止1K。如果request line或者request header超过1K，则由large_client_header_buffers指令配置分配。
语法: client_header_buffer_size size;
默认: client_header_buffer_size 1k;语法: large_client_header_buffers number size;
默认: large_client_header_buffers 4 8k;
两配置项配置位置: http, server
large_client_header_buffers设置读取大型客户端请求头的缓冲区的最大数量和大小。request line不能超过一个缓冲区的大小，否则将返回414（请求URI太大）错误给客户端。request header不能超过一个缓冲区的大小，否则将返回400（错误请求）错误给客户端。缓冲区只能按需分配。默认情况下，缓冲区的大小为8K字节。如果一个连接请求处理结束后转变为保持状态，这些缓冲区被释放。
请求处理的时候nginx先处理请求的request_line，之后才是request_header。这两者的buffer分配策略相同。先根据client_header_buffer_size配置的值分配一个buffer，如果分配的buffer无法容纳 request_line/request_header，那么就会再次根据large_client_header_buffers配置的参数分配large_buffer，如果large_buffer还是无法容纳，那么就会返回414（处理request_line）/400（处理request_header）错误。
client_header_buffer_size不用设置过大，能满足90%的情况即可。剩下的10%的请求头过大的话就由large_client_header_buffers处理即可。不过有一个比较蛋痛的问题是nginx默认会将400返回状态的请求放到access日志，而不会记录error日志。error日志有如下级别：[ debug | info | notice | warn | error | crit | alert | emerg ]我试着将nginx的error日志层级调整为debug级别，继续看看情况吧。