记一次被迫参加开源的经历
date
Nov 25, 2020
slug
记一次被迫参加开源的经历
status
Published
tags
Go
summary
公司的CI目前是在固定的几台机器上跑，有几个问题，一个是没有伸缩性，高峰期时甚至有CI等到过期了都没排到机器；另一个是空闲时又要浪费不小的运营成本，毕竟机器开在那里就扣费的。出于节省公司运营成本的考虑，决定把跑CI的机器由固定配置改成可伸缩的
type
Post
公司的CI目前是在固定的几台机器上跑，有几个问题，一个是没有伸缩性，高峰期时甚至有CI等到过期了都没排到机器；另一个是空闲时又要浪费不小的运营成本，毕竟机器开在那里就扣费的。
出于节省公司运营成本的考虑，决定把跑CI的机器由固定配置改成可伸缩的，由于代码管理是在自建的gitlab上面，云服务使用的是AWS，所以调研了几个方案
- 利用AWS Fargate实现（官方文档），但Fargate有自己的限制，即不支持Docker-in-Docker，所以只能跑一些简单的CI。我们的发版操作也是用CI跑的，所以官方的方式不行。
- Fargate的变种，参考这里。简单的说就是把容器相关的操作放到了别的地方，这里是利用AWS CodeBuild。整体流程如下图：但这个也有问题，一方面是比较复杂，另一方面，我们的项目前端项目居多，每个项目包含大量的小文件，如果要先传到S3，效率肯定高不了。
- 利用AWS EC2（参考这里），虽然不如Fargate省心，但支持Docker-in-Docker，至少比我们目前用固定几台机器来跑要更好。
在实际操作中，发现AWS EC2的方案是跑不通的，会报类似这样的错误
看了gitlab-runner的代码，发现报错不是runner报的，而是调用docker-machine了，由docker-machine报出来的。
docker-machine的项目上一次更新是18年了，翻了翻issue没有什么有价值的东西，不得已又得看代码。通过代码看到docker-machine依赖了AWS官方的sdk。这个错是官方sdk的问题。
找到了问题，剩下就是分析解决，其实就是因为AWS CN的部分域名跟普通的是不同的（参考），需要特殊处理，而官方sdk没考虑到这种情况。好在通过issue看到官方提供了一些hack的方式。
所以改掉对应的代码，重新编译了一份自己的docker-machine，使用自己编译的这份进行部署，问题解决。
给aws-sdk-go提PR的过程略去不表，比较麻烦的是docker-machine的依赖管理用的是dep，不得已又去学了dep的用法，主要是要通过override配置来使用forked的项目，如下
对比之下，使用go mod来管理依赖要方便很多，不知道go为什么这么晚才有了官方的依赖管理方案