背景
我们是一个10人小团队，因为本人之前接触过Docker和Drone，所有项目开发阶段开始的时候就确定使用CICD和Docker的方式进行开发与部署。前期为了方便我们直接使用Gitlab.com（不是私有部署）进行代码仓库的存储于Gitlab CI进行构建，然后通过Gitlab Runner部署到阿里云的开发服务器上。
没有自己部署Gitlab的原因是不想去管理Gitlab，比如保证Gitlab的可用，数据安全等，对于我们这样的小团队减少自己部署产品可以节省不少时间和精力，而且Gitlab.com也基本是免费的。
前期因为产品开发阶段所以我们只考虑了直接在服务器上通过Gitlab Runner部署开发环境和测试环境。但近期在准备产品的上线，我们需要将镜像推送到阿里云的Kubernetes（我们是使用托管版）上进行部署。在准备使用Gitlab CI部署时发现阿里云K8s（托管版）不支持token连接。
后来与阿里云相关工作人员联系后告知可以通过service和endpoint间接通过token访问k8s api。这种方式kubectl可以使用，但是配置
到Gitlab.com上依然无效。
评估后我们得出两种方案：
- 使用自定义的镜像（Gitlab CI支持使用任意镜像进行扩展）封装kubectl进行部署，这样的方式需要将kubeconfig配置到变量中，并使用脚本生成kubeconfig文件。然后再执行service和deployment文件进行部署。（Drone上的K8s插件不太靠谱，最好不要使用)
- 寻找其他的CICD平台（其实想寻找其他平台的还有一个重要的原因是Gitlab.com在17点-03点这段时间速度特变，我们团队又经常要
加班，所以晚上很痛苦。猜测应该和美国人上班时间有关系）。也有看了下CodePipeline，但是纯GUI一步配置的方式真心不方便，没有效率，所以放弃。
后来找到了一个CICD的SaaS平台：CodeRun
经过一段时间的研究和试用后我们目前所有的CICD都迁移到了CodeRun上（代码仓库也顺便迁移到Gitee上)
下面具体介绍下两个平台
Gitlab（包括私有部署）应该是国内使用量最大的代码仓库，Gitlab因为发展不断加入新功能，最亮眼的应该就是CICD和Kubernetes的
支持了。
所以理论上一套Gitlab就可以搞定你的代码仓库和CICD还是很方便的。
Gitlab的代码仓库功能就不讨论了。对于Gitlab CI这个新功能就比较有意思。大家都知道国内使用最多的CICD应该是Jenkins（应该是全球最多的）。我觉得其中最重要的一个原因是Jenkins是一个比较老的产品，在新的CICD方式没有出来的时候他就已经有非常大了的用户了。
但Jenkins有几个比较明显的缺点：
- 需要自行部署
- 插件和配置还是有一定学习难度
- 配置相对来说比较复杂
- Jenkins一般都需要专人进行维护
所以后来出现了一些仅通过一个Yaml文件就可以配置整个Pipeline的产品，最有名的应该是Drone。Drone因为部署方便，配置简单，同时还是开源产品所以得到了大量的用户。目前Drone也支持SaaS模式。但对于中国很悲剧的是他服务器也在国外，性能是个问题。
Gitlab CI是另一个支持一个Yaml文件配置的CI产品，他和Drone模式非常类似，基于 Docker 镜像作为 Stage 来执行。使用镜像作为Stage的好处就是你可以自定义镜像来进行扩展需求。比如前面提到的自行扩展对K8s的支持。
Gitlab Yaml配置样子如下：
image: docker:latest
stages:
- build
- deploy
variables:
APP_NAME: api
REGISTRY_IMAGE: "${DOUWA_REGISTRY_URL}/image/${APP_NAME}"
before_script:
- docker login -u $REGISTRY_USER -p $REGISTRY_PASSWORD $REGISTRY_URL
build:
stage: build
retry: 2
tags:
- dev
script:
- docker build -t $REGISTRY_IMAGE:${CI_COMMIT_REF_NAME} .
- docker push $REGISTRY_IMAGE:${CI_COMMIT_REF_NAME}
deploy-dev:
stage: deploy
tags:
- dev
script:
- docker stack deploy ${APP_NAME}_${CI_COMMIT_REF_NAME} -c deploy/${CI_COMMIT_REF_NAME}/docker-compose.yml --with-registry-auth
environment:
name: develop
only:
- dev
yaml这个配置应该挺好懂的。这里再简单介绍下：
- image: 定义了所有下面的步骤默认使用docker镜像
- variables: 定义了方便后续使用的变量
-
两个步骤:
- build: 构建镜像
- deploy-dev: 部署开发环境，其中
only限制了只有dev分支才执行
- stages部分进行了说明
因为gitlab没有整合资源，所有docker的操作和部署都是需要自己写脚本完成。当然这对于高级用户肯定是没有难度的，但对于新手就需要一定学习。
代码迁移到Gitee，国内一般叫码云。主要原因就是Gitlab.com太慢了。另外码云的项目管理功能也是相当强大的。
那么CodeRun应该是一个比较新的产品，好像也没什么知名度。但试用了下感觉还不错，而且国内好像也没有
类似的独立平台。
我个人认为CodeRun的优点有：
- 整合常见的Git平台：Github、Bitbucket、Gitee、Coding、Gitlab（私有部署好像也能支持）
- 有独立的镜像仓库，当然也可以配置第三方镜像仓库
- 可以配置token或者证书验证的Kubernetes（阿里云Kubernetes默认使用证书的验证方式）
- 有独立的Helm仓库
- 同样是Yaml配置，有一个简单的GUI
- Yaml的易用性比Gitlab要好
下面是之前Gitlab那个项目的CodeRun版本：
steps:
build:
image: crun/docker
repo_name: ${APP_NAME}
registry_name: coderun
dockerfile: Dockerfile
context: .
tags: ${CI_COMMIT_BRANCH}
deploy:
image: crun/kube
cluster_name: myk8s
template: deploy/deployment.yml
namespace: default
when:
branch: dev
简单说明下：
- build: 使用
crun/docker步骤，代码仓库中的Dockerfile构建镜像，并上传到CodeRun提供的镜像仓库
- deploy: 使用
crun/kube步骤，和代码仓库中的deploy/deployment.yml配置直接将镜像部署到在CodeRun上配置好的myk8s的Kubernetes集群上
和Gitlab的差异：
- 没有任何脚本操作
- 不需要定义一堆变量和参数
Kubernetes集群myK8s的配置：
![kubernetes_conf]( "kubernetes_conf")
