celery vs taskflow

    运维系统有这样一个需求, 简述一下就是: 执行任务A后执行B和C.B和C都执行完毕后执行任务D.

    由于以前用celery做任务调度, 很自然的查看是不是在celery中能够通过canvas实现(http://docs.celeryproject.org/en/latest/userguide/canvas.html).同时celery支持任务重试,也可以通过flower方便的查看任务执行状态. 貌似, 一切都是好的.

    可是后来在涉及到任务链回退的时候遇到了一些麻烦, 而且有任务竞争的问题. 开始反思是不是celery在任务流这种场景下是不是不合适, 是不是有更好的实现.

    刚开始想到自己实现一个, 大概会用到python的自省, 图(有序无环图)等, 但是工作量有些大了(其实是有些胆怯, 怕写不好哈哈), 最后决定现在找一下有没有现成的轮子.

    在大致查看了一下现有的轮子后, 这篇文章( https://medium.com/@jimbobhickville/be-one-with-the-taskflow-129e05a92bd4 )说服了我.

    taskflow是openstack下的一个工作流引擎, 支持线性流, 无序流, 图流, 而且任务定义和回退方式也很灵活方便.

    这里并不是说celery和taskflow哪个更好, 而是相比下, celery在分布式队列场景是很适合的, 而任务流的场景中, taskflow看上去更胜一筹, 当然2种工具结合起来用也是可以的.

通过外部系统管理saltstack的pillar

如果你现在已经有了一套资产管理系统, 支持账号权限控制, 能很方便的存放一些key/value. 同时也在使用saltstack进行系统管理. 是不是会觉得如果pillar放在资产管理系统会是一个不错的做法?

 

下面这种方式能够让你在资产管理系统中定义pillar, 然后打通到saltstack.

 

知识点:

在saltstack中, ext_pillar的优先级要比定义在master的pillar/foo.sls中高.

 

saltstack官方提供了一个http_json接口, 但是用起来会有2个不方便的地方:

  1. 不支持账号认证(提了个issue, https://github.com/saltstack/salt/issues/36138 ,还没修)
  2. 不支持只获取某个minion的pillar.

 

这就好说了, 既然有了葫芦, 可以比着画个瓢, 支持这2特性.

1. 增加ops_http_json.py

2. 在salt master上增加配置:

  ext_pillar:
    - ops_http_json:
       url: https://ops.ops.com/assets/salt/%s/pillars/
       username: username
       password: password

ops_http_json.py代码如下:

 

# -*- coding: utf-8 -*-
'''
A module that adds data to the Pillar structure retrieved by an http request


Configuring the HTTP_JSON ext_pillar
====================================

Set the following Salt config to setup http json result as external pillar source:

.. code-block:: yaml
  ext_pillar:
    - http_json:
        url: http://example.com/api/%s
        username: basic username
        password: basic password

Module Documentation
====================
'''

# Import python libs
from __future__ import absolute_import
import logging
import re

# Import Salt libs
try:
    from salt.ext.six.moves.urllib.parse import quote as _quote

    _HAS_DEPENDENCIES = True
except ImportError:
    _HAS_DEPENDENCIES = False

# Set up logging
_LOG = logging.getLogger(__name__)


def __virtual__():
    return _HAS_DEPENDENCIES


def ext_pillar(minion_id,
               pillar,  # pylint: disable=W0613
               url,
               username=None,
               password=None):
    '''
    Read pillar data from HTTP response.

    :param str url: Url to request.
    :param str username: username for basic auth
    :param str password: password for basic auth
    :return: A dictionary of the pillar data to add.
    :rtype: dict
    '''

    url = url.replace('%s', _quote(minion_id))

    _LOG.debug('Getting url: %s', url)

    if username and password:
        data = __salt__['http.query'](url=url, username=username, password=password, decode=True, decode_type='json')
    else:
        data = __salt__['http.query'](url=url, decode=True, decode_type='json')

    if 'dict' in data:
        return data['dict']

    _LOG.error("Error on minion '%s' http query: %s\nMore Info:\n", minion_id, url)

    for key in data:
        _LOG.error('%s: %s', key, data[key])

    return {}

通过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. 时机合适放出来. 地址

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

 

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

对比了以下方案:

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

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

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

 

实施步骤:

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

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

 

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

 

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

 

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

  1. 发布代码到预发布环境.
  2. 发布代码到生产环境.
  3. 手动会退到指定版本.
  4. 可以方便查看发布频率和状态.
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可能会修复这些问题, 会更方便.

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

 

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

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

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

业务上也需要支持框架, 如权限鉴定/一套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等实现.

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

 

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

这样就能来转换啦.