GitLabCI/CD流程
gitlab如果没有和Docker很好的结合。那么它会是一个很平凡的产品。但是有了CI对比其他产品Gogs、github等它还算可堪一用。上一篇文章写了gitlab_ci.yml配置文件的一些参数的含义。本篇文章记录一下如何从零在Gitlab上完成简单的CI/CD流程。基础流程如下Build流程构建我们需要的镜像上传到镜像仓库。部署的时候从镜像仓库直接拉取重启容器
gitlab如果没有和Docker很好的结合。那么它会是一个很平凡的产品。但是有了CI对比其他产品Gogs、github等它还算可堪一用。上一篇文章写了gitlab_ci.yml配置文件的一些参数的含义。本篇文章记录一下如何从零在Gitlab上完成简单的CI/CD流程。基础流程如下Build流程构建我们需要的镜像上传到镜像仓库。部署的时候从镜像仓库直接拉取重启容器
以下内容来自GitlabCI官方文档
jobs作为最顶级的元素。每个job至少包含一个script
1 | job1: |
每个job的执行都是完全独立于其他的job
以下内容基本全篇摘抄自v1.3的官方文档,先从理解下面这张两张图开始
以下是看udemy的Elasticsearch入门教程做的简短笔记
阅读全文开始一个软件,从读懂它的配置文件开始。以下是读取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刀!!!)。当保存大量数据的时候肯定会报错,另外默认的慢查询日志是没有打开的。对于请求。默认没有限制最大的返回内容数。以及限制单个查询响应的时间
以下为观看Ansible-Configuration Management的笔记。不适合初学者查看。可以作为温习使用
阅读全文遇到有人反映可能是内网环境。无法访问外部网络。安装初始化环境的时候好像颇为不便。其实只要能ssh上去。这一切都不是问题。就是各种转发,以下以内网使用pip安装第三方依赖包为例说明该如何操作
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使用更广泛
1 | ssh -R 8899:localhost:8899 remote_server |
将远程主机上的8899端口映射到本机的8899端口
可以使用如下命令进行测验
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在个人笔记本上难以实施。虚拟机恢复时间较慢。依据方案二于是乎有人写了一个工具 stellar。粗略读了一下源码。其具体原理大概如下图
备份的时候使用create database … template创建2个备份。恢复的时候删掉原有的数据库。将一个备份重命名为原有的名称。另外的一个备份再生成一个备份就完成了。另外删除新建数据库操作均会关闭所有已连接的数据库会话。
因为类似文件系统级快照,所以方法极快。我本机2G的数据库文件,创建一个快照大概十秒钟左右,恢复就更快了。当然缺点也是有的,你每创建一个快照都会新增2个一样大小的副本,相当的占据硬盘空间,可是为了速度这点缺陷也就微不足道了┑( ̄Д  ̄)┍
另外一个小缺点。因为它定位于测试环境下的数据库备份恢复。所以只连接一台机器。比如你一个数据库在机器A,一个数据库在机器B.赛高~~,那你只能在2个目录下使用2个配置文件来完成了。如果同一个机器上的多个数据库是可以直接备份的。再就是此工具比较专注于Postgresql。对于Mysql就不那么友好了。或许是Mysql的备份方案不一样
stellar init
按照提示输入本机数据库访问路径生成配置文件stellar snapshot
生成一个快照stellar restore <snap1>
恢复stellar --help
( ⊙ o ⊙ )啊! 多么爽快,世界真美妙
Is it possible to quickly create/restore database snapshots with PostgreSQL?
github stellar
metaclass一直被归类为比较高深的内容,写代码也很少会使用到metaclass。然而如果你看某些项目的源代码,还是会被绕到metaclass里面去。花一些时间理解下metaclass很有用的,因为它真的能把一条线串起来,环环相扣,所以有扎实的基础是掌握metaclass的前提,本文代码基于python3.5
阅读全文author.bio
author.job