devops 介绍
DevOps 是一个完整的面向 IT 运维的工作流, 以 IT 自动化以及持续集成 (CI), 持续部署(CD) 为基础, 来优化程式开发, 测试, 系统运维等所有环节
devops 的概念很多, 理解也很多. 我的理解, 它属于软件工程范畴. 它定义了一种理念, 基于这种理念, 能够快速的开发, 交付软件及成果物. 各个团队直接在这个体系中, 高效的沟通, 协作等.
这种理念, 首先以持续集成 (CI) 和持续交付 (CD) 为蓝本进行构建. 在这篇文章中, 对 devops 的理论内容不做展开, 主要介绍怎么快速的构建一套 devops 基础体系, 主要适用于初创团队, 没有历史包袱的项目.
方案架构图
devops 架构图
体系组成
代码版本管理
企业开发中常使用 GitLab 搭建代码版本库, 可以将其看作 devops 体系中的起始点.
在构建 CI 流程时, 需要对代码分支管理做一定规范. 因为后边的构建过程就是基于该分支展开的.
在此简单的展开一种管理模式, 将 GitLab 划分三个分支, dev,test,master. 将三种分支分属开发, 测试, 运维三个角色进行管理.
开发
开发人员将功能分支代码合并到 dev 分支后, 触发构建过程, 代码打包, 镜像构建等, 完成构建后, 通过容器管理平台将新构建的镜像进行发布.
测试
当开发人员将代码交付测试部门时, 测试人员, 将代码 merge 到 test 分支中, 此时触发测试分支的构建的流程, 完成构建后, 通过管理平台进行测试环境的发布.
运维
测试验收通过后, 交付运维团队进行上线升级, 将代码合并到 master 分支中, 构建 release 版本信息, 构建完成后, 发布应用.
以上就是基于 GitLab 的分支管理, 所做的三种构建分支, 当然, 实际操作环境下, 绝非这么简单, 不能的项目可以会涉及到不同的问题. 如, 环境配置信息的切换, 回滚等, 以及配置文件的管理, 数据库 sql 的管理等等.
持续构建
持续集成是一种软件开发实践, 即团队开发成员经常集成他们的工作, 通常每个成员每天至少集成一次, 也就意味着每天可能会发生多次集成. 每次集成都通过自动化的构建 (包括编译, 发布, 自动化测试) 来验证, 从而尽快地发现集成错误. 许多团队发现这个过程可以大大减少集成的问题, 让团队能够更快的开发内聚的软件.
这个定义有些学术化, 看起来让人很懵逼, 通俗的说, 就是用机器自动化代替以前的新代码运行靠人工去集成, 管理, 发布, 升级的这一过程. 按照一定规范, 我们将这一过程实现自动化.
实现这样过程的工具有很多, 其中的佼佼者要数 jenkins, 但 jenkins 是 java 写的, 部署时需要安装 JDK8.0 以上, 功能也过于复杂. 在此选用一种简单的持续集成工具 GitLab ci 进行介绍.
在 gitlab8.0 以后的版本默认集成了 GitLab ci 工具.
在使用 GitLab ci 时, 需要借助一个叫作 GitLab runner 的工具来完成这一流程. 关系图如下:
GitLab ci 就像一个业务调度器, 将需要工作的业务分发到 runner 中去执行. 在构建中, 需要一个 .GitLab-ci.YAML 编写构建任务. 它定义了 Pipeline 的工作流程.
Pipeline
在 GitLab 中定义的三个流程分支, 在其代码发生变化时, 通过钩子程序触发 pipeline 流程.
Stages
job
来一个. GitLab-ci.YAML 的基本模版
- # 定义 stages
- stages:
- - build
- - test
- # 定义 job
- job1:
- stage: test
- script:
- - echo "I am job1"
- - echo "I am in test stage"
- # 定义 job
- job2:
- stage: build
- script:
- - echo "I am job2"
- - echo "I am in build stage"
基于以上的构建流程, 这里提供一个 pipline 的模版
- variables:
- REPOSITORY: "xxxx/xxxxxx"
- stages:
- - deploy
- build:
- stage: deploy
- only:
- - master
- script:
- - docker build -t $REPOSITORY:prod .
- - docker tag $REPOSITORY:prod "私有镜像库地址"/$REPOSITORY:prod
- - docker push "私有镜像库地址"/$REPOSITORY:prod
- tags:
- - lable
- test:
- stage: deploy
- only:
- - test
- script:
- - docker build -t $REPOSITORY:testing .
- - docker tag $REPOSITORY:testing "私有镜像库地址"/$REPOSITORY:testing
- - docker push "私有镜像库地址"/$REPOSITORY:testing
- tags:
- - lable
- dev:
- stage: deploy
- only:
- - dev
- script:
- - docker build -t $REPOSITORY:dev .
- - docker tag $REPOSITORY:testing "私有镜像库地址"/$REPOSITORY:dev
- - docker push "私有镜像库地址"/$REPOSITORY:dev
- tags:
- - lable
现在持续即成多结合容器技术一起使用, 在这一步中, 最终状态是将要部署的代码打包成一个镜像, 发布到镜像库.
私有镜像库作为持续集成的一个重要平台, 最终存储着构建好的镜像.
在这一平台构建中, 现在多选择明星项目 harbor 作为私有镜像库. 具体在此不做展开, 后续会有专门针对该内容的文章进行展开.
持续交付 / 持续部署
在持续集成中, 我们完成了从代码到镜像的制作. 最终将生成的镜像交付到私有镜像库中. 在持续交付持续部署中, 要将完成的镜像发布到部署环境中.
部署也是 devops 环境中非常重要的一环. 简单的说, 这一步, 要实现的一个目标就是 docker run image. 将静态的镜像文件变成动态的 docker 运行环境.
最简单的应用就是 docker run 构建完成的镜像. 但往往系统常由多个组件构成, 如, Redis,nginx,MySQL, 以及其它一些子系统集成在一起组成一个完成的项目. 在这种情况下, 就需要做容器编排.
编排的目的, 使容器安装我们定义的规范来运行.
目前一统江湖的要数谷歌的 kubernetes 技术. 如果, 项目简单的话, 也可以直接使用 docker-compose 进行编排.
这里来一个 docker-compose 的模版. 就以 harbor 为例.
- version: '2'
- services:
- log:
- image: vmware/harbor-log:v1.1.2
- container_name: harbor-log
- restart: always
- volumes:
- - /var/log/harbor/:/var/log/docker/:z
- ports:
- - 127.0.0.1:1514:514
- networks:
- - harbor
- registry:
- image: vmware/registry:2.6.1-photon
- container_name: registry
- restart: always
- volumes:
- - /data/registry:/storage:z
- - ./common/config/registry/:/etc/registry/:z
- networks:
- - harbor
- environment:
- - GODEBUG=netdns=cgo
- command:
- ["serve", "/etc/registry/config.yml"]
- depends_on:
- - log
- logging:
- driver: "syslog"
- options:
- syslog-address: "tcp://127.0.0.1:1514"
- tag: "registry"
- MySQL:
- image: vmware/harbor-db:v1.1.2
- container_name: harbor-db
- restart: always
- volumes:
- - /data/database:/var/lib/MySQL:z
- networks:
- - harbor
- env_file:
- - ./common/config/db/env
- depends_on:
- - log
- logging:
- driver: "syslog"
- options:
- syslog-address: "tcp://127.0.0.1:1514"
- tag: "mysql"
- adminserver:
- image: vmware/harbor-adminserver:v1.1.2
- container_name: harbor-adminserver
- env_file:
- - ./common/config/adminserver/env
- restart: always
- volumes:
- - /data/config/:/etc/adminserver/config/:z
- - /data/secretkey:/etc/adminserver/key:z
- - /data/:/data/:z
- networks:
- - harbor
- depends_on:
- - log
- logging:
- driver: "syslog"
- options:
- syslog-address: "tcp://127.0.0.1:1514"
- tag: "adminserver"
- ui:
- image: vmware/harbor-ui:v1.1.2
- container_name: harbor-ui
- env_file:
- - ./common/config/ui/env
- restart: always
- volumes:
- - ./common/config/ui/App.conf:/etc/ui/App.conf:z
- - ./common/config/ui/private_key.pem:/etc/ui/private_key.pem:z
- - /data/secretkey:/etc/ui/key:z
- - /data/ca_download/:/etc/ui/ca/:z
- networks:
- - harbor
- depends_on:
- - log
- - adminserver
- - registry
- logging:
- driver: "syslog"
- options:
- syslog-address: "tcp://127.0.0.1:1514"
- tag: "ui"
- jobservice:
- image: vmware/harbor-jobservice:v1.1.2
- container_name: harbor-jobservice
- env_file:
- - ./common/config/jobservice/env
- restart: always
- volumes:
- - /data/job_logs:/var/log/jobs:z
- - ./common/config/jobservice/App.conf:/etc/jobservice/App.conf:z
- - /data/secretkey:/etc/jobservice/key:z
- networks:
- - harbor
- depends_on:
- - ui
- - adminserver
- logging:
- driver: "syslog"
- options:
- syslog-address: "tcp://127.0.0.1:1514"
- tag: "jobservice"
- proxy:
- image: vmware/nginx:1.11.5-patched
- container_name: nginx
- restart: always
- volumes:
- - ./common/config/nginx:/etc/nginx:z
- networks:
- - harbor
- ports:
- - 80:80
- - 443:443
- - 4443:4443
- depends_on:
- - MySQL
- - registry
- - ui
- - log
- logging:
- driver: "syslog"
- options:
- syslog-address: "tcp://127.0.0.1:1514"
- tag: "proxy"
- networks:
- harbor:
- external: false
对于 k8s 的内容, 后续会有专题对该内容做展开.
总结
通过以上的内容, 我们可以构建起一个简单的 devops 体系闭环, 要达到一个完善的平台, 还有很多事情要做. 如, 自动化测试, 配置中心, 发布流程, 敏捷开发等等. 在这个蓝本的基础上根据需求和痛点驱动逐步的完善.
来源: https://www.qcloud.com/developer/article/1353747