目录
前言
目标
工具 - 最小的学习成本
方案 - 愿景
1. 持续集成 - CI
2. 持续部署 - CD
部署环境
1. 部署 GitLab-runner
2. 注册 GitLab-runner
搭建 DevOps 管道 - PipeLines
1. 创建环境 - 发布主板本
2. 滚动更新 - 迭代小版本
3. 自动伸缩
4. 回滚
5. 可扩展性 - 兼容新增微服务
运维说明
1, 分支
2, 配置文件
总结
最后
前言
2018 年既是微服务架构火爆的一年, 也是容器和 Kubernetes 收获赞誉盆满钵满的一年; 在 kubernetes 的引领下, 以容器为中心部署微服务已成为一种事实标准, 并不断加速着微服务架构模式落地, 持续地发挥着它的魔力. 企业, 特别是互联网公司, 为了快速响应前端用户的需求, 缩短产品从需求到交付的周期, 常常需要快速地, 细腻度地迭代产品, 以抢占市场先机; 在微服务模式下, 可以很好地满足这个要求, 只发布变化的服务, 从而最小化单次迭代的风险, 实现敏捷开发和部署.
当采用微服务模式后, 整个业务流程将被垂直拆分成多个小单元; 每个小单元都是一个独立开发, 独立部署和独立扩展的微处理服务, 这样的灵活性非常适合敏捷开发模式, 但也给开发和运维带来了固有的复杂性和难度. 对于开发者而言, 由于微服务应用整体作为一个分布式系统提供服务, 需要选择合适服务通讯协议, 并处理潜在的网络分化瞬时故障等情况, 除此之外, 还需要建设服务发现, 配置中心等基础设施; 对于运维人员, 需要利用容器的可移植性, 持续地集成和部署微服务到不同的集群环境, 这些都要求运维人员具有非常全面的能力, 比如: 熟悉容器及 k8s, 熟练 Nginx, 能编写 Linux Shell 运维脚本等.
综上所述, 如何搭建一条成熟稳定, 且符合微服务特色的高度自动化 DevOps 管道又成为了另一个难题.
目标
以最小的学习成本, 搭建一条成熟稳定, 且符合微服务特色的高度自动化 DevOps 管道, 按需地持续集成 / 部署微服务到 kubernetes.
工具 - 最小的学习成本
GitLab
方案 - 愿景
1. 持续集成 - CI
在 kubernetes 的 master 节点部署 GitLab-runner, 充当 GitLab 服务器的客户端; 当提交或合并代码到指定的分支时, GitLab-runner 自动从 GitLab 拉取代码, 利用 master 主机提供的边缘计算能力来执行已编排好的 DevOps CI 管道 =》编译代码, 运行单元和集成测试, 容器化微服务成镜像, 最后上传到企业镜像仓库, 这就是持续集成流程, 该阶段交付的产物为镜像.
2. 持续部署 - CD
在 kubernetes 的 master 节点部署 GitLab-runner, 充当 GitLab 服务器的客户端, 当持续集成阶段交付了新版本的镜像后, 从企业镜像仓库拉取最新版本的镜像, 利用 master 主机提供的边缘计算能力执行已编排好的 DevOps CD 管道 =》同步服务配置信息到配置中心(k8s 的 ConfigMap), 并滚动更新 kubernetes 集群镜像版本.
部署环境
安装目录:/root/gitrunner
工作目录:/home/devops/gitrunner
> mkdir -p /root/gitrunner && mkdir -p /home/devops/gitrunner;
1. 部署 GitLab-runner
在 kubernetes 的 master 节点部署 GitLab-runner, 命令如下:
- > wget -O /root/gitrunner/GitLab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64;
- > cd /root/gitrunner;
- > chmod +x GitLab-runner;
- > # 注意: 建议使用 root 用户进行安装, 以避免不必要的权限问题.
- > ./GitLab-runner install --user=root --working-directory=/home/devops/gitrunner;
- > ./GitLab-runner start;
详情请参考: Install GitLab Runner manually on GNU/Linux.
2. 注册 GitLab-runner
GitLab 支持注册两种类型的 runner:
1. Specific Runners
这是隶属于特定项目的专有工人, 不接受其他项目调遣.
2. Shared Runners
这是隶属于 GitLab-server 的工人, 可以共享给所有的项目调遣.
这两种 Runner 各有千秋, 如果为每一个项目都注册专用 Runner, 会显得比较繁琐和多余, 而使用共享 Runner 就很省事, 但是一个工人一次只能做一件事情, 当同时调遣一个工人时, 那么就会出现竞争等待, 故大家还是实际情况来注册工人吧, 只要不延误工期就行, 嘿嘿.
注册 runner
- > cd /root/gitrunner;
- > ./GitLab-runner register
- > # 回车, 根据提示填写项目地址, 注册 Token, 标签, 执行器
- > # 假如, 项目地址为: http://gitlab.justmine.cn:8002/, 项目注册 token 为: 6iS4GBCh18NR4GPoMyef.
- > ## 以开发环境为例(仅供参考)
- > Please enter the GitLab-ci coordinator URL (e.g. https://gitlab.com/):
- http://gitlab.justmine.cn:8002/
- > Please enter the GitLab-ci token for this runner:
- 6iS4GBCh18NR4GPoMyef
- > Please enter the GitLab-ci description for this runner:
- [justmine.com]: development environment
- > Please enter the GitLab-ci tags for this runner (comma separated):
- build
- > Registering runner... succeeded runner=4iS4GwCh
- > Please enter the executor: SSH, docker+machine, kubernetes, VirtualBox, docker-SSH+machine, docker, docker-SSH, parallels, shell:
- shell
- > Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!
- > # 其他环境同理
- helm install /root/AutoDevOpsPipeLinesCharts \
- --name=${
- releaseName
- } \
- --set environment.upper=${
- Environment
- } \
- --set environment.lower=${
- environment
- } \
- --set namespace=${
- namespace
- } \
- --set image.registryhost=${
- RegistryHost
- } \
- --set image.username=${
- registryUserName
- } \
- --set image.version=${
- version
- } \
- --set replicas=${
- replicas
- }
- # 001 Continuous integration image to registry.
- bash ./devops/PipeLines/Creation/001_CI.sh
- # 002 Create config information to k8s's configmap.
- bash ./devops/PipeLines/Creation/002_CreateConfig.sh
- # 003 Release major to k8s's cluster.
- bash ./devops/PipeLines/Creation/003_ReleaseMajor.sh
- # 004 Create gateway route.
- bash ./devops/PipeLines/Creation/Gateways/Kong/004_CreateGatewayRoute.sh
- <Project>
- <PropertyGroup>
- <Major>1</Major>
- <Minor>0</Minor>
- <Patch>0</Patch>
- </PropertyGroup>
- </Project>
- <Project>
- <PropertyGroup>
- <Major>1</Major>
- <Minor>0</Minor>
- <Patch>1</Patch>
- </PropertyGroup>
- </Project>
- <!-- 回滚步长 -->
- <RollBackStep>
- 1
- </RollBackStep>
- <!-- 回滚步长 -->
- <RollBackStep>
- 1
- </RollBackStep>
- <!-- k8s 命名空间前缀, 比如: microservice-autodevopspipeline-v1 -->
- <NameSpace>
- microservice-autodevopspipeline
- </NameSpace>
- <!-- 应用程序名称, 主要用于 Tips -->
- <AppName>
- MicroService.AutoDevOpsPipeLine
- </AppName>
- <!-- 解决方案名称, 用于生成项目 -->
- <SolutionName>
- MicroService.AutoDevOpsPipeLines.sln
- </SolutionName>
- <!-- 主板次, 不兼容升级 -->
- <Major>
- 1
- </Major>
- <!-- 次板次, 兼容升级 -->
- <Minor>
- 0
- </Minor>
- <!-- 补丁版次, 静默修复接口 -->
- <Patch>
- 1
- </Patch>
- <!-- Auto-scaling 实例数量 -->
- <Replicas>
- 1
- </Replicas>
- <!-- Rollback 步长 -->
- <RollBackStep>
- 1
- </RollBackStep>
- <!-- 镜像仓库用户名 -->
- <ImageUserName>
- devopspipelines
- </ImageUserName>
- <!-- 镜像仓库主机域名 -->
- <RegistryHost>
- registry.staging.com:8100
- </RegistryHost>
- <!-- k8s restful 地址 -->
- <K8sApiServer>
- https://192.168.2.110:6443
- </K8sApiServer>
- <!-- k8s 接口访问令牌 -->
- <AccessToken>
- utyeyerye.ytryeryeryyyyyyr.jhddghdhdhdhd
- </AccessToken>
- <!-- kong restful 地址 -->
- <KongApiServer>
- http://192.168.2.110:81
- </KongApiServer>
- <!-- kong 域名绑定 -->
- <KongRouteDomain>
- staging.devops.com
- </KongRouteDomain>
- <!-- 解耦, 目前用于滚动更新 -->
- <!-- key: branch name(last keyword), value: environment -->
- <staging>
- Staging
- </staging>
- <master>
- Production
- </master>
来源: https://www.cnblogs.com/justmine/p/10193965.html