基于Jenkins和Docker的CI/CD优化

Nancy ·
更新时间:2024-11-13
· 617 次阅读

  此次优化的原因在于作为一家服务Global用户的公司,在多个region部署了服务,而目前阿里云容器服务针对有海外部署需要的公司,有几个待改进之处:   1、构建速度,海外构建需要在海外构建后将镜像推回国内   2、香港可用区没有提供镜像仓库   针对上述问题,我们优化从两个方面下手:   1、搭建镜像仓库   2、自主搭建构建集群   3、构建集群的缓存优化   一,镜像仓库   镜像仓库这里,为了兼容旧项目,我们搭建两个仓库,一个是阿里云镜像仓库杭州区的Mirror,另一个是内部访问的私有仓库,不对外   编排文件: registry-push: restart: always image: "registry:2.6" ports: - 5050:5000 environment: - REGISTRY_STORAGE=oss - REGISTRY_STORAGE_OSS_ACCESSKEYID={ak} - REGISTRY_STORAGE_OSS_ACCESSKEYSECRET={sk} - REGISTRY_STORAGE_OSS_REGION=oss-cn-hongkong - REGISTRY_STORAGE_OSS_BUCKET={hk_bucket} - REGISTRY_STORAGE_OSS_INTERNAL=true - REGISTRY_STORAGE_OSS_SECURE=false registry: restart: always image: "registry:2.6" environment: - REGISTRY_STORAGE=oss - REGISTRY_STORAGE_OSS_ACCESSKEYID={ak} - REGISTRY_STORAGE_OSS_ACCESSKEYSECRET={sk} - REGISTRY_STORAGE_OSS_REGION=oss-cn-hongkong - REGISTRY_STORAGE_OSS_BUCKET={hk_bucket} - REGISTRY_STORAGE_OSS_INTERNAL=true - REGISTRY_STORAGE_OSS_SECURE=false - REGISTRY_PROXY_REMOTEURL=https://registry.cn-hangzhou.aliyuncs.com - REGISTRY_PROXY_USERNAME={username} - REGISTRY_PROXY_PASSWORD={password} nginx: image: "nginx:1.9" ports: - 443:443 links: - registry:registry volumes: - ./auth:/etc/nginx/conf.d - ./auth/nginx.conf:/etc/nginx/nginx.conf:ro 目录结构: . ├── auth │   ├── insta360.com.chained.crt │   ├── insta360.com.key │   ├── nginx.conf │   └── nginx.htpasswd └── docker-compose.yml 1 directory, 5 files   这样一个镜像仓库的Mirror搭建好了,oss的bucket里有的镜像,从本地拉取,没有的,则从杭州区拉取,并存储到香港,加速二次使用的速度,对于集群部署,这样已经可以加速上线的过程了。而Push的那个仓库呢,主要是给我们自己用的,务必记得iptables设置规则,仅允许本机访问,他是我们用来推本地构建的镜像用的   这样呢,这个仓库,既能访问到杭州的镜像,又能访问到我们自己的镜像   二,jenkins以及缓存加速   这里我们直接用阿里云提供的编码模板稍作修改: version: '2' services: slave-java: image: registry.aliyuncs.com/acs-sample/jenkins-slave-dind-java volumes: - /var/run/docker.sock:/var/run/docker.sock - ./data/slave_java/.m2:/home/jenkins/.m2/ - ./conf/insta360_maven_settings.xml:/usr/share/maven/conf/settings.xml:ro restart: always slave-nodejs: image: registry.aliyuncs.com/acs-sample/jenkins-slave-dind-nodejs volumes: - /var/run/docker.sock:/var/run/docker.sock - ./data/slave_nodejs/.npm:/home/jenkins/.npm/ restart: always app: image: jenkins:2.46.2-alpine volumes: - ./data/jenkins_home:/var/jenkins_home ports: - 8080:8080 # - 50000:50000 privileged: true restart: always depends_on: - slave-nodejs - slave-java 目录结构如下: . ├── conf │   └── insta360_maven_settings.xml ├── data │   ├── jenkins_home │   ├── slave_java │   └── slave_nodejs └── docker-compose.yml 5 directories, 2 files   注意配置里的几个变化:   slave-java,挂载了一个私有的mavan的配置文件,有需要的记得加在这里,同时呢,我们把/home/jenkins/.m2/挂载了,这样重启应用不会删除已经下载的pkg   slave-nodejs,同样挂载了/home/jenkins/.npm/目录,效果一样,是为了缓存node的包   slave没有暴露端口,仅内部访问   三,jenkins使用   这里的配置访问我们不废话了,可以参考这里:   使用阿里云容器服务Jenkins 2.0实现持续集成之the tag you want篇   看看以前的构建时间:

  再看看现在的时间,包过了构建时间+部署时间

  这里注意一下,阿里云的jenkins插件在提交部署后,有一个一分钟的等待时间(轮训去查看是否更新完毕),实际上呢,几次测试,整个时间是在20s左右,基本在一分钟完成,容器服务更新应用是滚动更新,不会一次更新所有的应用实例,从而保证不停机,自然的,也带来了一定的延时。   下次出了bug,一分钟可以搞定线上的修复,想想也是很开心吧!



cd ci jenkins Docker

需要 登录 后方可回复, 如果你还没有账号请 注册新账号