朱金贺 – 第 2 页 – 朱金贺的博客

PHP服务器降低10%-15%CPU资源占用

业务请求稳步上升, PHP接口服务器资源又吃紧了, 在巡检时发现了一个有趣的现象引起了我的注意. 其中一台的CPU资源占用相对其他相同配置服务器小10-15%左右, 预计有比较可观的深挖价值.

(标题先卖个关子, 通过这个关子引出下面的3种解决问题的思路), 下面请看3种排查思路.

首先先看"错误"示范:

既然负载表现有差别, 第一思路就是该"大家来找茬"了, 在这个思路下分别排查了:

1.负载均衡分配规则.

2.负载均衡中配置权重相同, 业务请求量日志也大致相同.

3.服务器内核版本和参数.

4.PHP的编译参数, gcc版本.

5.PHP报错日志.

查看系统的message日志,其中中会有一些redis插件相关的段错误. 由于以前处理过redis插件的内存泄露问题,所以重新编译最新版本的redis.so库,检查没有了段错误.但是对性能并没有任何提升

6.服务器防火墙配置.

性能好的服务器防火墙取消了TCP请求跟踪, 其他服务器上也取消TCP请求跟踪后后性能差异也没有明显提高.

7.外部请求速度差异.

在链路监控日志中对比, 2台服务器请求数据库/缓存等接口速度无差异. 网络消耗也无差异.

8.系统内核调用差异.类调用差异.

通过strace追踪系统内核调用差异,和ltrace跟踪so文件时间调用差异. 内核调用差异.这种差距可以对比出,但是分析这种差异太过复杂,不直观.

走到这里, 这条思路基本上是走到死胡同了.虽然发现了一些可以优化的地方, 但是并没有找到差异真正原因. 所以需要转变思路, 通过判断推理而不是假设验证来定位.

下面请看"能解决问题"的示范:

1.进程分组汇总后,观察某类进程占用资源的对比.

watch -d -n 1 "ps aux | awk '{S[\$11]+=\$3} END { for (i in S) print S[i], i}' | sort -nr"

发现确实根本原因还是在php-fpm的差异上,与其他的应用无关.

2.内核态CPU差距不大,用户态CPU有15%左右的差距.load值会有1-2倍的差异.这个比例就比较蹊跷了.通过vmstat -n 1发现,CPU等待队列数基本保持在3-5附近,偶尔会突然增高到20-30附近,并迅速下降,这种情况会导致CPU的用户态差距不大,而系统load差距非常大.平时正常,但是波峰过大.

3.这种情况需要查找CPU任务堆积的分配, 通过观察CPU时钟来推断产生问题的原因.

通过perf top对比发现.性能差的服务器中会有大量的mutex_spin_on_owner和_spin_unlock_irqrestore时间占用.

关于这个的解释:

It's bad reporting by perf, not cycles consumed by _spin_unlock_irqrestore.

When IRQs are disabled, perf's interrupts are not processed. Instead, they're processed when interrupts are re-enabled. When perf's interrupt handler looks at the instruction pointer, to see what code was running, it finds the function that enabled interrupts - quite often it's _spin_unlock_irqrestore.

So all you know is that the cycles were consumed by code that had interrupts disabled, and enabled them using _spin_unlock_irqrestore.

If you can get perf to use NMI (non maskable interrupt), it could solve this problem.

I know that it can be done with oprofile (perf's predecessor) by changing the makefile, but don't know about perf.

大意是:这个问题是在处理多核CPU均衡相关的内容,但这个问题只是表现症状,并不是根本原因.这个内容和CPU抢占,自旋锁等锁,和多核CPU均衡相关的内容.进一步分析发现这些内容是由php-fpm发起的.

对比性能较好的服务器:

性能差的API服务器中libgomp.so.1.0.0 gomp_barrier_wait_end的调用占据了大量的CPU时钟.

调查发现openmp是和多核CPU并行相关的.软件编译的过程中,可以利用这个动态库,达到充分利用多核CPU的目的. 关闭openmp的多核功能后, 性能得到提升, 问题得到解决.

以上是调查过程中的思路和方法, 问题虽然得到解决, 但是还是有一些推理盲点存在, 仍然有些运气成分, 不能让人完全信服.

下面请看"正确"的示范:

思路是通过查找出这个动态库的上游调用,来找到有问题的点.通过perf工具查出,这个库的最上游调用时php-fpm.(果然,最终还回到了php-fpm).具体是php-fpm的哪个步骤出了问题需要进一步推断.

1: 查找任意一个php-fpm的文件调用.

lsof -p `ps aux | grep "[p]hp-fpm: pool"| head -n 1 | awk '{print $2}'`

2: 查看php-fpm的动态库调用树.比较取巧的方式是从文件调用中查到so文件,只需要查下一级的ldd调用即可.

lsof -p `ps aux | grep "[p]hp-fpm: pool"| head -n 1 | awk '{print $2}'`

| awk '{print $NF}'| sort |uniq | grep so | xargs ldd

搜索这些调用树:

/usr/lib64/libMagickCore.so.5.0.0

/usr/lib64/libMagickWand.so.5.0.0

/usr/local/php7/lib/php/extensions/debug-non-zts-20151012/imagick.so

只有这几个so用到了那个libgomp.so.1

rpm -qf /usr/lib64/libMagickWand.so.5.0.0

ImageMagick-6.7.2.7-4.el6_7.x86_64

到此为止,真正的问题找到了.就是ImageMagick这个文件产生了CPU多核调用,从而导致的出现频繁的波峰.

然后调查这个软件和多核CPU相关的部分:

identify -list Configure

返回的结果中:

FEATURES OpenMP

发现默认是启用了OpenMP.

性能好的服务器当时为了修复ImageMagick的一个软件安全隐患, 除了有yum安装的多核版本, 还有一个关闭掉多核功能的版本, 编译参数中有一项CONFIGURE ./configure '--disable-openmp'.关闭多核功能. imagic.so编译的时候使用了无多核版本的库文件.

所以,问题就非常明了了. 在有和图片处理相关的请求中,理论上这个请求能占用所有的CPU资源.这会导致后续的PHP请求堆积,有个比较大的高峰.

开启多核功能在有些场景下使用,但作为PHP的库时,并不一定是最佳实践.

解决方法:

1.重新编译其余服务器的ImageMagick软件,关闭多核心功能.并重新编译so解决.

2.在PHP调用的时候手动制定最多使用1颗CPU.但是这种方式需要修改的PHP文件调用可能比较多,所以并不采用.

最终结果:重新编译后,perf top观察没有多核CPU相关/锁相关CPU时钟占用.系统性能也区域稳定,理论上会多支持20%-30%左右的请求量..

关于这次调查中总结的非技术问题.下篇再接着总结吧.

--------------------

参考文章:

https://www.google.com/#q=linux++disable+OpenMP+

https://www.google.com/#q=gomp_barrier_wait_end

https://www.google.com/#q=gomp_barrier_wait_end+php

http://stackoverflow.com/questions/14703328/spin-unlock-irqrestore-has-very-high-sampling-rate-in-my-kvm-why

https://www.google.com/#q=spin_unlock_irqrestore+high

https://www.google.com/#q=php+7++imagemagick+libgomp

ImageMagick这个插件

http://stackoverflow.com/questions/14703328/spin-unlock-irqrestore-has-very-high-sampling-rate-in-my-kvm-why

http://stackoverflow.com/questions/7847900/disable-openmp-in-nice-way

http://stackoverflow.com/questions/1357604/turn-off-openmp

http://stackoverflow.com/questions/5697824/openmp-gcc-gomp-wasteful-barrier

http://stackoverflow.com/questions/39116329/enable-disable-openmp-locally-at-runtime/39119009

http://stackoverflow.com/questions/1357604/turn-off-openmp

http://boomshadow.net/tech/installs/installing-imagemagick-php-imagick/

http://www.daniloaz.com/en/high-cpu-load-when-converting-images-with-imagemagick/

通过ELK快速分析PHP slow_log栈

分析PHP慢的原因有很多种:

比如通过xhprof.

有些通过sort/uniq的组合操作分析.

其实如果已经有了ELK(现在叫elastic stack)的话, 甚至可以更直观, 更方便前后对比.

今天来说一说如何通过分析php_slow_log快速"定位(估计)"慢的环节.

思路来源自这篇文章: http://chenlinux.com/2015/03/06/kibana4-for-slowlog/

效果图:

最外圈是调用栈最一层的比例, 第二层是调用栈第二层.

这种图可以在PHP变慢的时候可以快速查看是哪个调用栈的问题. 比如数据库调用变慢, 还是内部逻辑问题.

可惜参考文章不是通过logstash实现, 看了一下logstash, 没有比较简单的原生实现. 这又何妨, 世上无难事只怕有心人, 索性拆分方式直接改为写ruby代码:

配置文件如下: 有这样需求的同学, 拿走, 不谢.

filter {
  if [type] == "php_fpm_slow" {
    grok {
      match => {
        message => "(?m)\[(?<timestamp>\d{2}-\w{3}-\d{4} \d{2}:\d{2}:\d{2})\]\s+\[(?<pool_name>\w+\s\w+)\]\spid\s%{NUMBER:php_pid:int}\nscript_filename = %{UNIXPATH:slow_script}\n(?<php_slow_stack>\[\w{18}\] (?<slow_func>[^\[]*?:\d+).*\[\w{18}\](?<begin_func>[^\[]*?:\d+))$"
      }
    }
    mutate {
      gsub => ["php_slow_stack", "\[\w{18}\] ", ""]
    }
    ruby {
      code => "php_slow_stack_hash = Hash.new; if event.get('php_slow_stack'); event.get('php_slow_stack').split(/\r?\n/).each_with_index {|item, index| php_slow_stack_hash[index] = item }; end; event.set('php_slow_stack', php_slow_stack_hash)"
    }
    mutate {
        merge => ["php_slow_stack", "php_slow_stack"]
    }

  }
}

output {
  if [type] == "php_fpm_slow" {
    elasticsearch {
      hosts => ["10.24.252.67:9200"]
      index => "php-fpm-slow-log-%{+YYYY.MM.dd}"
      document_type => "%{type}"
      flush_size => 2000
      idle_flush_time => 5
    }
  }
}

运维管理系统的组成

一套运维管理系统需要什么?

资产管理cmdb, 这会是整个系统的核心之一.

权限管理系统, 支持RABC(role-based access control)或者ABAC(Attribute-based access control)

任务管理系统, 支持定义/调用任务流.

可以调用发布系统.

可以执行服务器命令.

可选的审计模块.

可选的故障管理模块.

最近写了一个demo. 时机合适放出来. 地址

说说Elasticsearch内存分配

问题终于解决了, 本来想总结一下, joshua已经总结完了, 还比我自己总结的更好.

索性偷个懒(偷懒也需要找理由啊)

链接: Elasticsearch 内存那点事

那我就说一下ELK中其他的性能提升方式吧.

如果要实现业务系统日志汇总分析, 直接推动业务系统直接输出json格式的日志吧.

如果输出了plain 格式, 还需要耗费CPU去分析正则, 性能耗费不是一般地说.

grek在线debug，需要翻墙

http://grokdebug.herokuapp.com/

grok的解析式

https://github.com/logstash-plugins/logstash-patterns-core/blob/master/patterns/grok-patterns

利用gitlab的ci/cd发布PHP代码

公司某个PHP项目发布一直手动执行shell(基本逻辑是备份,指定php文件名并scp, reload php-fpm).用起来相当麻烦而且容易出错, 开发人员提出能不能协助简化操作.

对比了以下方案:

改写shell为rsync, 实现自动差异对比, 省去输入文件名的麻烦.
使用国内比较流行的jenkins搭建一套发布系统.
最新的gitlab(9.x)支持内置的ci/cd功能.

通过详细的功能性和便捷性考察, 最终选择使用gitlab内置的ci功能. 原因有:

一步到位, 用shell不方便查询发布历史和发布结果.
现在有一个低版本的源码编译的gitlab, 再引入jenkins还需要引入账号权限设置, 成本有些高.
gitlab ci功能满足, 方便管理. BTW, gitlab的产品理念和公司理念都很不错.

实施步骤:

升级gitlab(源码编译改为同版本号的Omnibus版, 然后升级Omnibus版本到最新版)

安装gitlab-runner, 并考察几种发布方式的优缺点.

刚开始出于安全性考虑, gitlab-runner选用的是docker模式, 后来发现性能比shell模式差比较多.由于系统边界管理做的还不错, 为了追求性能改为了shell模式. 各位看各自的实际情况进行选择.

安装步骤官网描述的很清晰, 就不再赘述. 只列出了.gitlab-ci.yml的例子.

这个例子能用gitlab的账号系统, 登录后一键点击实现:

发布代码到预发布环境.
发布代码到生产环境.
手动会退到指定版本.
可以方便查看发布频率和状态.

before_script:
  - JOB_NAME=( $CI_BUILD_NAME ) && export SSH_HOST=${JOB_NAME[1]} && echo $SSH_HOST
  - RUN_MODE_SETTING=production
  - date
  - git status
  - git show && echo $?

stages:
  - deploy_staging
  - deploy_production
  - re_trigger_deploy

.rsync_artifacts:
  script: &rsync_artifacts |
    rsync -rtlpvz --delete $CI_PROJECT_DIR/ $SSH_USER@$SSH_HOST:$PROD_BASE_DIR/ --exclude='.git' --exclude='.gitlab-ci.yml' --exclude='.gitignore' --exclude='some/folder/'
    date

.reload_php7_fpm:
  script: &reload_php7_fpm |
    ssh $SSH_USER@$SSH_HOST "sudo /bin/bash -c 'date >> /tmp/ci.log; /etc/init.d/php7-fpm reload >>/tmp/ci.log 2>&1' &"

.do_other_command:
  script: &do_other_command |
    ssh $SSH_USER@$SSH_HOST "sudo /bin/bash -c 'date >> /tmp/ci.log;/bin/bash other_shell.sh arg >>/tmp/ci.log 2>&1' &"

.deploy_production: &deploy_production
  stage: deploy_production
  environment: production
  only:
    - master
    - triggers

.deploy_staging: &deploy_staging
  stage: deploy_staging
  environment: staging
  when: manual

.deploy_staging_template: &deploy_staging_template
  <<: *deploy_staging
  script:
    - '[ "${DEPLOY_PRODUCTION}" != "true" ] || exit 0'
    - *rsync_artifacts
    - *reload_php7_fpm
    - export RUN_MODE_SETTING=beta
    - *do_other_command
    - date

.deploy_production_template: &deploy_production_template
  <<: *deploy_production
  script:
    - '[ "${DEPLOY_PRODUCTION}" != "true" ] && exit 0'
    - *rsync_artifacts
    - *reload_php7_fpm

# ################上面是模板，下面是调用配置################
# 发布到服务器1
deploy_production 1.1.1.1: *deploy_production_template
# 发布到服务器2
deploy_production 2.2.2.2: *deploy_production_template
# 发布到预发布环境3
deploy_staging 3.3.3.3: *deploy_staging_template
# 发布到服务器4, 并执行其他命令
deploy_production 4.4.4.4:
  <<: *deploy_production
  script:
    - '[ "${DEPLOY_PRODUCTION}" != "true" ] && exit 0'
    - *rsync_artifacts
    - *reload_php7_fpm
    - *do_other_command
    - date

trigger_build:
  stage: re_trigger_deploy
  environment: production
  script:
    - echo ${CI_PROJECT_ID}
    - "curl -X POST -F token=${CI_TRIGGER_TOKEN} -F ref=master -F variables[DEPLOY_PRODUCTION]=true https://gitlab.yourcompany.com/api/v3/projects/${CI_PROJECT_ID}/trigger/builds"
  when: manual
  tags:
    - api
# 手工回退的方法:
# 1. 回退的SHA-1点打tag.例如: revert-20170322, 并把tag推送到服务器.
# 2. 模拟curl -X POST -F token=${CI_TRIGGER_TOKEN} -F "ref=revert-20170322" -F "variables[DEPLOY_PRODUCTION]=true" https://gitlab.yourcompany.com/api/v3/projects/${CI_PROJECT_ID}/trigger/builds

不足: 由于这个版本的gitlab ci在工作流下一步判断的时候逻辑有问题, shell的function功能支持也不是很好, 有了这么一个workaround的方式. 后续版本的gitlab可能会修复这些问题, 会更方便.

搭建第三方开发者代码/服务托管系统

公司新业务, 希望支持第三方开发者开发插件, 并实现插件代码的托管. 开发者可以上传代码, 审核通过后自动做资源分配, 代码发布等.

支撑公司内部开发人员和第三方开发者也需要关注更多的内容.

安全风险, 对于未知的第三方开发者. 要做好资源隔离并避免污染.
保证业务连续性.
自动实现代码发布, 支持回退/指定tag发布, 减少人工成本.
方便查看第三方应用产生的日志.
支持区分测试环境/生产环境.

业务上也需要支持框架, 如权限鉴定/一套k/v存储接口等.

运维的架构, 从来都应该是面向需求, 要满足业务需求, 但是又不能过早引入复杂的设计, 一步一步进行演变.

每个应用会分配给开发者一个仓库地址. 开发人员提交代码后, 在运维平台提交发布请求(仓库地址, 生成/测试环境), 管理员审核通过/拒绝, 自动发布代码到指定环境., 采用的实现方案如下:

通过docker来实现环境隔离.

通过nginx upstream机制做故障转移.

通过gitlab ci/cd实现代码发布接口.

通过运维平台提供资源分配, 生成配置文件, 调用发布接口, 提供日志接口, 修改子域名dns.

以第三方开发者的插件是nginx/php实现, 平台提供一个标准模板.

docker资源隔离:

提供Dockerfile

[nginx Dockerfile]

FROM alpine:3.3

MAINTAINER NGINX Docker Maintainers "docker-maint@nginx.com"

ENV NGINX_VERSION 1.10.1

ENV GPG_KEYS B0F4253373F8F6F510D42178520A9993A1C052F8
ENV CONFIG "\
  --prefix=/etc/nginx \
  --sbin-path=/usr/sbin/nginx \
  --modules-path=/usr/lib/nginx/modules \
  --conf-path=/etc/nginx/nginx.conf \
  --error-log-path=/var/log/nginx/error.log \
  --http-log-path=/var/log/nginx/access.log \
  --pid-path=/var/run/nginx.pid \
  --lock-path=/var/run/nginx.lock \
  --http-client-body-temp-path=/var/cache/nginx/client_temp \
  --http-proxy-temp-path=/var/cache/nginx/proxy_temp \
  --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp \
  --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp \
  --http-scgi-temp-path=/var/cache/nginx/scgi_temp \
  --user=nobody \
  --group=nobody \
  --with-http_ssl_module \
  --with-http_realip_module \
  --with-http_addition_module \
  --with-http_sub_module \
  --with-http_dav_module \
  --with-http_flv_module \
  --with-http_mp4_module \
  --with-http_gunzip_module \
  --with-http_gzip_static_module \
  --with-http_random_index_module \
  --with-http_secure_link_module \
  --with-http_stub_status_module \
  --with-http_auth_request_module \
  --with-http_xslt_module=dynamic \
  --with-http_image_filter_module=dynamic \
  --with-http_geoip_module=dynamic \
  --with-http_perl_module=dynamic \
  --with-threads \
  --with-stream \
  --with-stream_ssl_module \
  --with-http_slice_module \
  --with-mail \
  --with-mail_ssl_module \
  --with-file-aio \
  --with-http_v2_module \
  --with-ipv6 \
  "

RUN \
  apk add --no-cache --virtual .build-deps \
    gcc \
    libc-dev \
    make \
    openssl-dev \
    pcre-dev \
    zlib-dev \
    linux-headers \
    curl \
    gnupg \
    libxslt-dev \
    gd-dev \
    geoip-dev \
    perl-dev \
  && curl -fSL http://nginx.org/download/nginx-$NGINX_VERSION.tar.gz -o nginx.tar.gz \
  && curl -fSL http://nginx.org/download/nginx-$NGINX_VERSION.tar.gz.asc  -o nginx.tar.gz.asc \
  && export GNUPGHOME="$(mktemp -d)" \
  && gpg --keyserver ha.pool.sks-keyservers.net --recv-keys "$GPG_KEYS" \
  && gpg --batch --verify nginx.tar.gz.asc nginx.tar.gz \
  && rm -r "$GNUPGHOME" nginx.tar.gz.asc \
  && mkdir -p /usr/src \
  && mkdir -p /var/log/nginx \
  && mkdir -p /var/cache/nginx/client_temp \
  && mkdir -p /var/cache/nginx/proxy_temp \
  && mkdir -p /var/cache/nginx/fastcgi_temp \
  && mkdir -p /var/cache/nginx/uwsgi_temp \
  && mkdir -p /var/cache/nginx/scgi_temp \
  && tar -zxC /usr/src -f nginx.tar.gz \
  && rm nginx.tar.gz \
  && cd /usr/src/nginx-$NGINX_VERSION \
  && ./configure $CONFIG --with-debug \
  && make \
  && mv objs/nginx objs/nginx-debug \
  && mv objs/ngx_http_xslt_filter_module.so objs/ngx_http_xslt_filter_module-debug.so \
  && mv objs/ngx_http_image_filter_module.so objs/ngx_http_image_filter_module-debug.so \
  && mv objs/ngx_http_geoip_module.so objs/ngx_http_geoip_module-debug.so \
  && mv objs/ngx_http_perl_module.so objs/ngx_http_perl_module-debug.so \
  && ./configure $CONFIG \
  && make \
  && make install \
  && rm -rf /etc/nginx/html/ \
  && mkdir /etc/nginx/conf.d/ \
  && mkdir -p /usr/share/nginx/html/ \
  && install -m644 html/index.html /usr/share/nginx/html/ \
  && install -m644 html/50x.html /usr/share/nginx/html/ \
  && install -m755 objs/nginx-debug /usr/sbin/nginx-debug \
  && install -m755 objs/ngx_http_xslt_filter_module-debug.so /usr/lib/nginx/modules/ngx_http_xslt_filter_module-debug.so \
  && install -m755 objs/ngx_http_image_filter_module-debug.so /usr/lib/nginx/modules/ngx_http_image_filter_module-debug.so \
  && install -m755 objs/ngx_http_geoip_module-debug.so /usr/lib/nginx/modules/ngx_http_geoip_module-debug.so \
  && install -m755 objs/ngx_http_perl_module-debug.so /usr/lib/nginx/modules/ngx_http_perl_module-debug.so \
  && ln -s ../../usr/lib/nginx/modules /etc/nginx/modules \
  && strip /usr/sbin/nginx* \
  && strip /usr/lib/nginx/modules/*.so \
  && runDeps="$( \
    scanelf --needed --nobanner /usr/sbin/nginx /usr/lib/nginx/modules/*.so \
      | awk '{ gsub(/,/, "\nso:", $2); print "so:" $2 }' \
      | sort -u \
      | xargs -r apk info --installed \
      | sort -u \
  )" \
  && apk add --virtual .nginx-rundeps $runDeps \
  && apk del .build-deps \
  && rm -rf /usr/src/nginx-$NGINX_VERSION \
  && apk add --no-cache gettext \
  \
  # forward request and error logs to docker log collector
  && ln -sf /dev/stdout /var/log/nginx/access.log \
  && ln -sf /dev/stderr /var/log/nginx/error.log

COPY nginx.conf /etc/nginx/nginx.conf
COPY nginx.vh.default.conf /etc/nginx/conf.d/default.conf

EXPOSE 80 443

CMD ["nginx", "-g", "daemon off;"]

docker用到的nginx配置文件:

user  nobody;
worker_processes  4;

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;


events {
    use epoll;
    worker_connections  10240;
}


http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    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;

    sendfile        on;
    #tcp_nopush     on;

    keepalive_timeout  65;

    #gzip  on;

    include /etc/nginx/conf.d/*.conf;
}

nginx.vh.default.conf:

server {
    listen       80;
    server_name  localhost;

    #charset koi8-r;
    #access_log  /var/log/nginx/log/host.access.log  main;

    location / {
        root   /usr/share/nginx/html;
        index  index.html index.htm;
    }

    #error_page  404              /404.html;

    # redirect server error pages to the static page /50x.html
    #
    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   /usr/share/nginx/html;
    }

    # proxy the PHP scripts to Apache listening on 127.0.0.1:80
    #
    #location ~ \.php$ {
    #    proxy_pass   http://127.0.0.1;
    #}

    # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
    #
    #location ~ \.php$ {
    #    root           html;
    #    fastcgi_pass   127.0.0.1:9000;
    #    fastcgi_index  index.php;
    #    fastcgi_param  SCRIPT_FILENAME  /scripts$fastcgi_script_name;
    #    include        fastcgi_params;
    #}

    # deny access to .htaccess files, if Apache's document root
    # concurs with nginx's one
    #
    #location ~ /\.ht {
    #    deny  all;
    #}
}

[php Dockerfile]

FROM php:7-fpm-alpine

MAINTAINER foobar Docker Maintainers "docker@foobar.com"
# install php-core-extensions
RUN apk add --no-cache freetype libpng libjpeg-turbo freetype-dev libpng-dev libjpeg-turbo-dev libmcrypt-dev && \
  docker-php-ext-configure gd \
    --with-gd \
    --with-freetype-dir=/usr/include/ \
    --with-png-dir=/usr/include/ \
    --with-jpeg-dir=/usr/include/ && \
  NPROC=$(grep -c ^processor /proc/cpuinfo 2>/dev/null || 1) && \
  docker-php-ext-install -j${NPROC} gd mcrypt && \
  apk del --no-cache freetype-dev libpng-dev libjpeg-turbo-dev

生成环境nginx故障转移的实现方式:

默认使用docker环境处理请求, 当docker挂掉后, 可以切换到宿主机进行处理(宿主机处理有安全风险),用这个方式实施简单,不需要引入docker集群相关的内容.

upstream app1000239 {

     server 10.47.49.233:11239;

     server 127.0.0.1:10239 backup;

}

server {

    listen 443 ssl;

    server_name app1000239.foobar.com;

    server_tokens off;

    proxy_set_header           Host $host;

    proxy_set_header           X-Real-IP $remote_addr;

    proxy_set_header           X-Forwarded-For $proxy_add_x_forwarded_for;

    location / {

        proxy_pass      http://app1000239;

    }

    access_log /data/logs/nginx/${host}_access.log combined;

}

server {

        listen 127.0.0.1:10239;

        root   /data/web/app1000239/web/;

        index  index.html index.htm index.php;

        location ~* \.php$ {

                fastcgi_pass   127.0.0.1:9000;

                fastcgi_index  index.php;

                fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name;

                include        fastcgi_params;

               

        }

        location / {

            index index.php;

            try_files $uri $uri/ /index.php$is_args$args;

        }

        access_log /data/logs/nginx/app1000239_vm_access.log combined;

    }

gitlab 实现ci/cd

gitlab支持通过在代码仓库中放置.gitlab-ci.yml来实现, 但是如果开发者直接支持管理.gitlab-ci.yml会有学习成本和较大的安全风险, 因此可以通过2个仓库来达到目的.

开发者可以上传代码到仓库A. 然后在运维平台提交发布申请.

仓库A对应的管理仓库AA. AA可以存放.gitlab-ci.yml, php/nginx的配置文件等. 运维平台可以调用仓库AA的代码发布来完成发布.

AA仓库的目录结构:

.gitlab-ci.yml (存放发布相关)

codes/ (这里是用的gitlab的子模块功能, 把仓库A当做子模块)

conf/ 这里存放渲染好的nginx/php配置文件, docker-compose文件

仓库AA可以设置一些默认参数, 并开启一个webhooks监听pipline event, 向运维平台发送发布成功/失败的结果.

附录:

[docker-compose.yaml文件]

version: '2'
services:
  app-nginx:
    image: registry.foobar.com/images/foobar-nginx
    volumes_from:
      - app-php
    ports:
     - "1.1.1.1:11038:80"
    command: nginx -g 'daemon off;'
    links:
      - app-php
    extra_hosts:
      - "api.foobar.com:2.3.4.5"
  app-php:
    image: registry.foobar.com/images/foobar-php-fpm-gd
    extra_hosts:
      - "api.foobar.com:2.3.4.5"
    volumes:
     - /data/web/foobar_app1000038:/usr/share/nginx/html
     - ./app-php.conf:/usr/local/etc/php-fpm.d/www.conf
     - ./app-nginx.conf:/etc/nginx/conf.d/default.conf
     - /etc/localtime:/etc/localtime:ro
     - /etc/resolv.conf:/etc/resolv.conf:ro

[app-php.conf]

[www]
user = www-data
group = www-data
listen = 127.0.0.1:9000
pm = dynamic
pm.max_children = 100
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 20

[app-nginx.conf]

server {
    listen      80;
    server_tokens  off;

    root /usr/share/nginx/html/web/;
    index  index.html index.htm;
    location ~* \.php$ {
            fastcgi_pass   app-php:9000;
            fastcgi_index  index.php;
            fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name;
            include        fastcgi_params;
    }
    location / {
        index index.php;
        try_files $uri $uri/ /index.php$is_args$args;
    }
    location = /50x.html {
        root   /usr/share/nginx/html;
    }
    error_page   500 502 503 504  /50x.html;
    access_log  /var/log/nginx/access.log  main;
}

[.gitlab-ci.yml]

image: foobar/open_docs_php:latest
before_script:
  - ping git.foobar.com -w 2
  - eval $(ssh-agent -s)
  - ssh-add <(echo "$SSH_PRIVATE_KEY")
  - ssh-add <(echo "$GIT_CLONE_PRIVATE_KEY")
  - mkdir -p ~/.ssh
  - '[[ -f /.dockerenv ]] && echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config'
  - cd $CI_PROJECT_DIR && git checkout . && git submodule update --init --force
  - cd $CI_PROJECT_DIR/codes && echo ${commit_ref} && git fetch --all && git checkout ${commit_ref} .
stages:
  - test
  - build
  - deploy
deploy_stage:
  stage: deploy
  script:
    - if [ "${deploy_to}" == "development" ]; then echo "development" && rsync -vzrtog --delete $CI_PROJECT_DIR/codes/ $SSH_USER@$SSH_HOST:$DEV_BASE_DIR/ --exclude=.git; elif [ "${deploy_to}" == "production" ]; then echo "production" && rsync -vzrtog --delete $CI_PROJECT_DIR/codes/ $SSH_USER@$SSH_HOST:$DEV_BASE_DIR/ --exclude=.git; else echo "no variable provided"; exit 1; fi

运维平台实现:

开发者创建新应用后分配一个仓库账号,地址

分配域名:

创建针对测试/正式环境用的域名.

调用域名商接口配置对应的A记录.

创建对应的管理仓库.

初始化管理仓库:

创建.gitlab-ci.yml

创建子模块并放在codes/目录

渲染出的配置文件放到conf目录

创建仓库的变量(.gitlab-ci.yml里面会用到)

创建webhooks

调用gitlab ci发布代码, 推送conf里配置文件到宿主服务器, 使用docker-compose启动docker镜像, 并启动/重启外部nginx服务.

运维平台用的flask + sqlalchemy配合一些模块如python-gitlab, GitPython等实现.

整个代码/服务托管的运维方案这样就转起来了.

分享给大家一些zabbix监控模板

做监控的时候收集或者自己写的一些模板和笔记。大概有40多个常用模板.

在这里 , 总有一款能帮到你.

推荐一个cmdb工具: itop

如果哪天你想实现/使用一套配置管理工具, itop值得尝试.

这个工具还是比较贴合ITIL那一套理论的实现.

SQL schema 转为 orm class

在使用flask-sqlalchemy的时候, 可以通过定义class来生成数据库schema.
今天做cmdb的时候却碰到个另外一个需求, 想参考itop的sql schema, 并转为orm class.
在网上搜索了一下, 看到这篇博客里写,用的是 SqlAutoCode
http://blog.sina.com.cn/s/blog_537f224501013jk6.html
但测试SqlAutoCode有一些bug，更推荐pip install sqlacodegen
针对flask的是https://github.com/ksindi/sqlacodegen

这样就能来转换啦.

利用keepalived做redis的双机热备

应用场景：
服务压力不大，但是对可靠性要求极其高
特性：
至少需要两台服务器，其中一台为master始终提供服务，另外一台只有在主服务器挂掉的才提供服务。
优点：数据同步非常简单，不像负载均衡对数据一致性要求非常高
缺点：服务器有点浪费，始终有一台处于空闲状态

说明：
操作系统：CentOS 6.3 64位
redis服务器：172.27.4.38、172.27.4.39

架构规划：
需要在Master与Slave上均安装Keepalived和Redis，并且redis开启本地化策略。
master:172.27.4.38
slave:172.27.4.39
Virtural IP Address (VIP): 172.27.4.250

当 Master 与 Slave 均运作正常时, Master负责服务，Slave负责Standby；
当 Master 挂掉，Slave 正常时, Slave接管服务，同时关闭主从复制功能；
当 Master 恢复正常，则从Slave同步数据，同步数据之后关闭主从复制功能，恢复Master身份。与此同时Slave等待Master同步数据完成之后，恢复Slave身份。

redis安装步骤：
wget http://download.redis.io/releases/redis-2.4.15.tar.gz
tar zxvf redis-2.4.15.tar.gz
mkdir -p /usr/local/redis2.4.15/etc
mkdir -p /usr/local/redis2.4.15/data
mkdir -p /usr/local/redis2.4.15/logs

mv redis.conf /usr/local/redis2.4.15/etc
cd redis-2.4.15
make PREFIX=/usr/local/redis2.4.15 install
cd src/
make install

安装完毕
tree /usr/local/redis2.4.15/
/usr/local/redis2.4.15/
├── bin
│   ├── redis-benchmark
│   ├── redis-check-aof
│   ├── redis-check-dump
│   ├── redis-cli
│   └── redis-server
├── etc
└── redis.conf
2 directories, 6 files

修改redis配置文件

vim /usr/local/redis2.4.15/redis.conf
daemonize yes #当为yes时redis回后台运行，关闭命令为redis-cli shutdown
logfile /usr/local/redis2.4.15/logs/redis.log #指定日志文件目录
dbfilename dump.rdb #指定数据文件名称
dir /usr/local/redis2.4.15/data/ #指定数据文件文件夹未知

开启redis的命令为：
/usr/local/redis2.4.15/bin/redis-server /usr/local/redis2.4.15/etc/redis.conf
至此redis安装完毕

然后用客户端测试一下是否启动成功。

redis-cli
redis> set foo bar
OK
redis> get foo
"bar"

Keepalived安装
官方地址：http://www.keepalived.org/download.html 大家可以到这里下载最新版本。
环境配置：安装make 和 gcc openssl openssl-devel popt ipvsadm 等
yum -y install gcc make openssl openssl-devel wget kernel-devel
cd /usr/local/src/
wget http://www.keepalived.org/software/keepalived-1.2.13.tar.gz
tar zxvf keepalived-1.2.13.tar.gz
cd keepalived-1.2.13
预编译如果指定目录的话
./configure --prefix=/usr/local/keepalived
也可以直接使用默认
./configure
预编译后出现：
Keepalived configuration
------------------------
Keepalived version : 1.2.13
Compiler : gcc
Compiler flags : -g -O2
Extra Lib : -lssl -lcrypto -lcrypt
Use IPVS Framework : Yes
IPVS sync daemon support : Yes
IPVS use libnl : No
fwmark socket support : Yes
Use VRRP Framework : Yes
Use VRRP VMAC : Yes
SNMP support : No
SHA1 support : No
Use Debug flags : No

make && make install

整理管理文件：
ln -s /usr/local/keepalived/sbin/keepalived /usr/sbin/
ln -s /usr/local/keepalived/etc/sysconfig/keepalived /etc/sysconfig/
ln -s /usr/local/keepalived/etc/rc.d/init.d/keepalived /etc/init.d/
至此keepalived安装完毕
注册为服务并设置开机启动
chkconfig --add keepalived
chkconfig keepalived on
service keepalived start

ps -ef | grep keepalived
root 1332 1908 0 09:32 pts/0 00:00:00 grep keepalived
root 1977 1 0 Nov20 ? 00:00:02 keepalived -D
root 1978 1977 0 Nov20 ? 00:00:02 keepalived -D
root 1979 1977 0 Nov20 ? 00:00:17 keepalived -D
redis服务启动后会有3个进程。

首先，在Master上创建如下配置文件：
mkdir -p /etc/keepalived/scripts/
vim /etc/keepalived/keepalived.conf

vrrp_script chk_redis {
script "/etc/keepalived/scripts/redis_check.sh" ###监控脚本
interval 2 ###监控时间
}
vrrp_instance VI_1 {
state MASTER ###设置为MASTER
interface eth0 ###监控网卡
virtual_router_id 51
priority 101 ###权重值
authentication {
auth_type PASS ###加密
auth_pass redis ###密码
}
track_script {
chk_redis ###执行上面定义的chk_redis
}
virtual_ipaddress {
172.27.4.250 ###VIP
}
notify_master /etc/keepalived/scripts/redis_master.sh
notify_backup /etc/keepalived/scripts/redis_backup.sh
notify_fault /etc/keepalived/scripts/redis_fault.sh
notify_stop /etc/keepalived/scripts/redis_stop.sh

然后，在Slave上创建如下配置文件:

mkdir -p /etc/keepalived/scripts/
vim /etc/keepalived/keepalived.conf

vrrp_script chk_redis {
script "/etc/keepalived/scripts/redis_check.sh" ###监控脚本
interval 2 ###监控时间
}
vrrp_instance VI_1 {
state BACKUP ###设置为BACKUP
interface eth0 ###监控网卡
virtual_router_id 51
priority 100 ###比MASTRE权重值低
authentication {
auth_type PASS
auth_pass redis ###密码与MASTRE相同
}
track_script {
chk_redis ###执行上面定义的chk_redis
}
virtual_ipaddress {
172.27.4.250 ###VIP
}
notify_master /etc/keepalived/scripts/redis_master.sh
notify_backup /etc/keepalived/scripts/redis_backup.sh
notify_fault /etc/keepalived/scripts/redis_fault.sh
notify_stop /etc/keepalived/scripts/redis_stop.sh
}

在Master和Slave上创建监控Redis的脚本:
vim /etc/keepalived/scripts/redis_check.sh
#!/bin/bash

ALIVE=`/opt/redis/bin/redis-cli PING`
if [ "$ALIVE" == "PONG" ]; then
echo $ALIVE
exit 0
else
echo $ALIVE
exit 1
fi

编写以下负责运作的关键脚本：
notify_master /etc/keepalived/scripts/redis_master.sh
notify_backup /etc/keepalived/scripts/redis_backup.sh
notify_fault /etc/keepalived/scripts/redis_fault.sh
notify_stop /etc/keepalived/scripts/redis_stop.sh

因为Keepalived在转换状态时会依照状态来呼叫：
当进入Master状态时会呼叫notify_master
当进入Backup状态时会呼叫notify_backup
当发现异常情况时进入Fault状态呼叫notify_fault
当Keepalived程序终止时则呼叫notify_stop

首先，在Redis Master上创建notity_master与notify_backup脚本：

vim /etc/keepalived/scripts/redis_master.sh
#!/bin/bash

REDISCLI="/usr/local/redis2.8.9/bin/redis-cli"
LOGFILE="/var/log/keepalived-redis-state.log"

echo "[master]" >> $LOGFILE
date >> $LOGFILE
echo "Being master...." >> $LOGFILE 2>&1

echo "Run SLAVEOF cmd ..." >> $LOGFILE
$REDISCLI SLAVEOF 172.27.4.39 6379 >> $LOGFILE 2>&1
sleep 10
#延迟10秒以后待数据同步完成后再取消同步状态

echo "Run SLAVEOF NO ONE cmd ..." >> $LOGFILE
$REDISCLI SLAVEOF NO ONE >> $LOGFILE 2>&1

vim /etc/keepalived/scripts/redis_backup.sh

#!/bin/bash

REDISCLI="/usr/local/redis2.8.9/bin/redis-cli"
LOGFILE="/var/log/keepalived-redis-state.log"

echo "[backup]" >> $LOGFILE
date >> $LOGFILE
echo "Being slave...." >> $LOGFILE 2>&1

sleep 15
#延迟15秒待数据被对方同步完成之后再切换主从角色
echo "Run SLAVEOF cmd ..." >> $LOGFILE
$REDISCLI SLAVEOF 172.27.4.39 6379 >> $LOGFILE 2>&1

接着，在Redis Slave上创建notity_master与notify_backup脚本：

vim /etc/keepalived/scripts/redis_master.sh

#!/bin/bash

REDISCLI="/usr/local/redis2.8.9/bin/redis-cli"
LOGFILE="/var/log/keepalived-redis-state.log"

echo "[master]" >> $LOGFILE
date >> $LOGFILE
echo "Being master...." >> $LOGFILE 2>&1

echo "Run SLAVEOF cmd ..." >> $LOGFILE
$REDISCLI SLAVEOF 172.27.4.38 6379 >> $LOGFILE 2>&1
sleep 10
#延迟10秒以后待数据同步完成后再取消同步状态

echo "Run SLAVEOF NO ONE cmd ..." >> $LOGFILE
$REDISCLI SLAVEOF NO ONE >> $LOGFILE 2>&1

vim /etc/keepalived/scripts/redis_backup.sh

#!/bin/bash

REDISCLI="/usr/local/redis2.8.9/bin/redis-cli"
LOGFILE="/var/log/keepalived-redis-state.log"

echo "[backup]" >> $LOGFILE
date >> $LOGFILE
echo "Being slave...." >> $LOGFILE 2>&1

sleep 15
#延迟15秒待数据被对方同步完成之后再切换主从角色
echo "Run SLAVEOF cmd ..." >> $LOGFILE
$REDISCLI SLAVEOF 172.27.4.38 6379 >> $LOGFILE 2>&1

然后在Master与Slave创建如下相同的脚本：

vim /etc/keepalived/scripts/redis_fault.sh
#!/bin/bash

LOGFILE=/var/log/keepalived-redis-state.log

echo "[fault]" >> $LOGFILE
date >> $LOGFILE

vim /etc/keepalived/scripts/redis_stop.sh
#!/bin/bash

LOGFILE=/var/log/keepalived-redis-state.log

echo "[stop]" >> $LOGFILE
date >> $LOGFILE

给脚本都加上可执行权限：
chmod +x /etc/keepalived/scripts/*.sh

脚本创建完成以后，我们开始按照如下流程进行测试：
1.启动Master上的Redis
/etc/init.d/redis restart

2.启动Slave上的Redis
/etc/init.d/redis restart

3.启动Master上的Keepalived
/etc/init.d/keepalived restart

4.启动Slave上的Keepalived
/etc/init.d/keepalived restart

5.尝试通过VIP连接Redis:
redis-cli -h 172.27.4.250 INFO

连接成功，Slave也连接上来了。
role:master
slave0:172.27.4.39,6379,online

6.尝试插入一些数据：
redis-cli -h 172.27.4.250 SET Hello Redis
OK

从VIP读取数据
redis-cli -h 172.27.4.250GET Hello
“Redis”

从Master读取数据
redis-cli -h 172.27.4.38 GET Hello
“Redis”

从Slave读取数据
redis-cli -h 172.27.4.39 GET Hello
“Redis”

下面，模拟故障产生：
将Master上的Redis进程杀死：
killall -9 redis-server
或者redis-cli shutdown

查看Master上的Keepalived日志
tail -f /var/log/keepalived-redis-state.log
[fault]
Thu Sep 27 08:29:01 CST 2012

同时Slave上的日志显示：
tailf /var/log/keepalived-redis-state.log
[master]
Fri Sep 28 14:14:09 CST 2012
Being master….
Run SLAVEOF cmd …
OK
Run SLAVEOF NO ONE cmd …
OK

然后我们可以发现，Slave已经接管服务，并且担任Master的角色了。
redis-cli -h 172.27.4.250 INFO
redis-cli -h 172.27.4.39 INFO
role:master

然后我们恢复Master的Redis进程
/etc/init.d/redis start

查看Master上的Keepalived日志
tailf /var/log/keepalived-redis-state.log
[master]
Thu Sep 27 08:31:33 CST 2012
Being master….
Run SLAVEOF cmd …
OK
Run SLAVEOF NO ONE cmd …
OK

同时Slave上的日志显示：
tailf /var/log/keepalived-redis-state.log
[backup]
Fri Sep 28 14:16:37 CST 2012
Being slave….
Run SLAVEOF cmd …
OK

可以发现目前的Master已经再次恢复了Master的角色，故障切换以及自动恢复都成功了