开始GitLab CI/CD

发布在 devops

GitLabCI/CD流程

gitlab如果没有和Docker很好的结合。那么它会是一个很平凡的产品。但是有了CI对比其他产品Gogs、github等它还算可堪一用。上一篇文章写了gitlab_ci.yml配置文件的一些参数的含义。本篇文章记录一下如何从零在Gitlab上完成简单的CI/CD流程。基础流程如下Build流程构建我们需要的镜像上传到镜像仓库。部署的时候从镜像仓库直接拉取重启容器
GitlabCI

阅读全文

gitlabci yml 笔记

发布在 devops

以下内容来自GitlabCI官方文档

最基础的

  • jobs作为最顶级的元素。每个job至少包含一个script

    1
    2
    job1:
    script1: pwd

    每个job的执行都是完全独立于其他的job

阅读全文

influxdb配置文件

发布在 database

开始一个软件,从读懂它的配置文件开始。以下是读取3.1配置文档的笔记
总结来说,influxdb的配置文件可配置的地方几乎没有。参数性能调优貌似不存在,其中是否开启,是否记录日志都占据了好多部分。额外需要关注的是data章节有一些关于fsync的设置默认是0,还有默认的max-series-per-database和max-value-per-tag默认都存在限制。暂时不太清楚原理是什么(更新:因为influxdb最大的软肋就在series的数量上。tag的数据都保存在内存。所以有极大的限制。可以看到官方硬件要求,100万的series需要4-6核心CPU,8-32GB内存,iops要求1000+。对比一下influxdb提供的云服务,100万的series需要每月1500刀!!!)。当保存大量数据的时候肯定会报错,另外默认的慢查询日志是没有打开的。对于请求。默认没有限制最大的返回内容数。以及限制单个查询响应的时间

阅读全文

遇到有人反映可能是内网环境。无法访问外部网络。安装初始化环境的时候好像颇为不便。其实只要能ssh上去。这一切都不是问题。就是各种转发,以下以内网使用pip安装第三方依赖包为例说明该如何操作

1.本机开启一个临时的http代理

1
pip install mitmproxy           # 安装
1
mitmproxy -p 8899 --ignore .+               #  使用

mitmproxy是一个python编写的http/https中间人框架。这里我们单独的使用它的http proxy功能。
参数p当然是port端口的意思了。监听8899端口
加上ignore是因为中间人https连接需要客户端安装信任证书才可以。此处我们只是单纯的使用一下proxy不需要中间人。所以所有流量使用HTTP Connection隧道方式就达成目的了。使用正则表达式.+忽略所有域名。至于为什么使用http不是用socks。因为http使用更广泛

2.ssh使用远程端口转发(参考ssh端口映射)

1
ssh -R 8899:localhost:8899 remote_server

将远程主机上的8899端口映射到本机的8899端口

3.远程主机使用本地的http代理进行环境初始化

可以使用如下命令进行测验

1
curl -x http://localhost:8899 ip.cn

比如使用pypi安装tornado执行如下命令即可

1
pip install -i https://pypi.tuna.tsinghua.edu.cn/simple --proxy http://localhost:8899 tornado

思路是这样。其它同理~

评论和共享

开发中总会遇到一些测试需要回滚数据库。常规的单元测试的做法是在单个会话中不真正的写入到数据库。而是测试完成后进行数据库回滚。大多数情况下这样都是满足要求的。只是有的时候需要数据库真正的写入到数据库。此时rollback回滚就有些乏力了。此时给数据库做一个备份,测试完成后回滚是一种不错的主意。Postgresql数据库的常规备份我们会使用pg_dump和pg_restore进行导出和恢复。此时如何快速的进行这个操作是我们关注的话题

很幸运。很顺利的搜到了答案。6年前有人在stackexchange上提问同样的问题。得到了一些有用的回复。大概有这些

  • 使用文件系统级快照LVM
  • 使用CREATE DATABASE … TEMPLATE语法
  • 将数据库放在虚拟机里面。使用虚拟机快照

其中最有效的方案是二。因为LVM在个人笔记本上难以实施。虚拟机恢复时间较慢。依据方案二于是乎有人写了一个工具 stellar。粗略读了一下源码。其具体原理大概如下图
backup_and_restore_flow

备份的时候使用create database … template创建2个备份。恢复的时候删掉原有的数据库。将一个备份重命名为原有的名称。另外的一个备份再生成一个备份就完成了。另外删除新建数据库操作均会关闭所有已连接的数据库会话。

因为类似文件系统级快照,所以方法极快。我本机2G的数据库文件,创建一个快照大概十秒钟左右,恢复就更快了。当然缺点也是有的,你每创建一个快照都会新增2个一样大小的副本,相当的占据硬盘空间,可是为了速度这点缺陷也就微不足道了┑( ̄Д  ̄)┍

另外一个小缺点。因为它定位于测试环境下的数据库备份恢复。所以只连接一台机器。比如你一个数据库在机器A,一个数据库在机器B.赛高~~,那你只能在2个目录下使用2个配置文件来完成了。如果同一个机器上的多个数据库是可以直接备份的。再就是此工具比较专注于Postgresql。对于Mysql就不那么友好了。或许是Mysql的备份方案不一样

使用方法

  1. stellar init 按照提示输入本机数据库访问路径生成配置文件
  2. stellar snapshot 生成一个快照
  3. stellar restore <snap1> 恢复
  4. 其他请看 stellar --help

( ⊙ o ⊙ )啊! 多么爽快,世界真美妙

参考

Is it possible to quickly create/restore database snapshots with PostgreSQL?
github stellar

评论和共享

Docker CD初探-Drone

发布在 Docker

最近有个小需求,我们公司写文档是通过slate来的。每一次文档编写完成之后都需要执行bundle exec middleman build --clean生成静态文件。然后再使用rsync来进行上传操作。虽然只有2步。但是做的次数多了难免也让人觉得厌烦。萌生了自动化处理的想法。比较粗暴的方式有。每隔几分钟去检测一次git版本库是否有更新(以前本人真这样实现过),自己写个小web程序。设置webhook。接收到webhook再拉取进行操作(我也实现过,目前一切运行良好)。现在尝试下使用可持续集成的套路去实现。

阅读全文

理解metaclass

发布在 python

metaclass一直被归类为比较高深的内容,写代码也很少会使用到metaclass。然而如果你看某些项目的源代码,还是会被绕到metaclass里面去。花一些时间理解下metaclass很有用的,因为它真的能把一条线串起来,环环相扣,所以有扎实的基础是掌握metaclass的前提,本文代码基于python3.5

阅读全文

ficapy

author.bio


author.job