GitLab+Rancher实践DevOps

摘要

本文描述使用自建GitLab和Rancher实践持续集成/持续交付流水线的过程，并用Rancher实现容器编排和蓝绿发布。

GitLab持续集成

GitLab持续集成/持续交付流程图：

部署GitLab服务器不是本文重点，暂且略过。GitLab内置持续集成/持续交付，支持测试、构建、部署流水线。使用GitLab持续集成需要在GitLab项目路径下添加.gitlab-ci.yml文件，这个配置文件是YAML格式，用于配置流水线的各阶段任务，详细说明参考官方.gitlab-ci.yml配置文件说明文档。这里给一个Go语言开发的项目并用容器部署的示例：

# 容器镜像地址
image: [镜像仓库地址]/library/[镜像名称]

# 设置变量如果有私密变量，可以在GitLab项目流水线设置中配置。
variables:
  DOCKER_DRIVER: overlay2
  IMAGE_NAME: [镜像名称]
  INTRANET_DC_REGISTRY: [镜像仓库地址]
  INTRANET_DC_REGISTRY_REPO: $INTRANET_DC_REGISTRY/library

before_script:
  - echo $GOPATH
  - ln -s "$PWD" $GOPATH/src/$CI_PROJECT_NAME
  - cd $GOPATH/src/$CI_PROJECT_NAME
  - apk update
  - apk add --no-cache gcc pkgconfig zeromq-dev git musl-dev
  - export CGO_ENABLED=1

stages:
  - test
  - build
  - deploy

test:
  stage: test
  script:
    - govendor test +local
  tags:
    - rancher_docker

build:
  stage: build
  script:
    - govendor build -v
    # 服务镜像版本号
    - export BUILD_TAG=$(cat Version)
    # 登录内网镜像仓库
    - docker login -u $INTRANET_DC_REGISTRY_USER -p $INTRANET_DC_REGISTRY_PASS $INTRANET_DC_REGISTRY
    # 生成服务镜像
    - docker build -t $INTRANET_DC_REGISTRY_REPO/$IMAGE_NAME:$BUILD_TAG .
    - docker push $INTRANET_DC_REGISTRY_REPO/$IMAGE_NAME:$BUILD_TAG
    - docker tag $INTRANET_DC_REGISTRY_REPO/$IMAGE_NAME:$BUILD_TAG $INTRANET_DC_REGISTRY_REPO/$IMAGE_NAME:latest
    - docker push $INTRANET_DC_REGISTRY_REPO/$IMAGE_NAME:latest
  tags:
    - rancher_docker

deploy:
   stage: deploy
   script:
     - export DEPLOY_URL="http://[Rancher服务器地址和端口号]/v1-webhooks/endpoint?key=vUMszIPObLRYtojrASlyRVBTvn5nc7DsqK0POrhy&projectId=1a46"
     - export IMAGE=$INTRANET_DC_REGISTRY_REPO/$IMAGE_NAME
     - curl -X POST $DEPLOY_URL -H 'content-type:application/json' -d '{"push_data":{"tag":"latest"},"repository":{"repo_name":"'"$IMAGE"'"}}'
   tags:
     - rancher_docker
   only:
     - master

需要说明的是INTRANET_DC_REGISTRY_USER和INTRANET_DC_REGISTRY_PASS参数是在GitLab项目“设置”->“流水线”->“保密变量”中配置，而没有直接写在配置文件中。在上述配置文件的部署阶段使用了Rancher默认容器编排工具Cattle的Webhooks功能实现自动发布，其它的编排工具也有相应的方法。上述配置中有一个配置项tags，这里就是用于配置Runner。Runner是用来执行流水线任务的计算资源，可以是虚拟机、物理机或容器。首先要安装Runner，然后配置Runner。既然使用容器就要有Dockerfile，这个文件也是在项目路径下，在上述配置中的镜像构建阶段（docker build）需要使用这个文件的配置信息，这里给一个示例:

# This file is a template, and might need editing before it works on your project.
FROM [镜像仓库地址]/library/alpine:latest

RUN sed -i -e 's/v3\.6/edge/g' /etc/apk/repositories
RUN apk add --no-cache libzmq
WORKDIR /service

# 设置环境变量
ENV ZK_HOSTS=192.168.5.30:2181,192.168.5.30:2182,192.168.5.30:2183\
    ZK_PATH=/dtask\
    LOG_LEVEL=INFO

# 复制项目
RUN mkdir -p /service/lua_scripts
# 复制Lua脚本到容器环境
COPY lua_scripts [项目目录名称] ./
COPY lua_scripts/*.lua lua_scripts/

RUN chmod +x [项目目录名称]
EXPOSE 7080 5560 5561 5556
CMD ["./[可执行程序名]"]

这是一个Go语言编写的项目Dockerfile文件，Go语言编译器将项目编译成可执行程序，所以这个Dockerfile比较简单，如果是Python这种解释型脚本语言要安装各种依赖会稍微麻烦一些。

Rancher使用简介

架构

Rancher系统架构图：

从这个图上可以清晰地看出Rancher五层架构：

1. 最底层（第一层）是各种云计算虚拟化环境，这些环境是以插件的形式提供。
2. 第二层是在云平台上建立的虚拟主机。
3. 第三层是各种基础服务，如存储、网络、负载均衡、DNS等。
4. 第四层是容器编排、用户管理、运维管理，容器编排包含了各种主流的容器编排工具Cattle、Docker Swarm、Kubernetes、Mesos。
5. 第五层是各种容器应用。

功能

Rancher官方文档内容很多，但是常用的功能其实并不多，所以这里只介绍最常用的几个功能。

概念

• 环境：Rancher 支持将资源分组归属到多个环境。每个环境具有自己独立的基础设施资源及服务，并由一个或多个用户、团队或组织管理。例如，你可以创建独立的“开发”、“测试”及“生产”环境以确保环境之间的安全隔离，将“开发”环境的访问权限赋予全部人员，但限制“生产”环境的访问权限给一个小的团队。所有主机和Rahcner资源, 比如容器, 基础设施服务等, 都在环境中被创建, 并且属于一个环境。
• 主机：在Rancher中，主机是调度资源的基本单位（直观的理解就是所发生的操作最终都会落到某台主机上），它可以是虚拟的或者物理的Linux服务器。
• 镜像仓库：你可以在Rancher配置镜像仓库的认证信息，使Rancher可以访问你的私有镜像仓库（DockerHub, Quay.io和其他私有镜像库）。
  在每个环境中，你可以给每个私有仓库地址配置一个认证信息，从而使Rancher可以拉取私有镜像。如果你给同一个镜像仓库配置了多个认证信息，那么Rancher只会使用最近添加的一个认证信息。Rancher支持在Cattle和Kubernetes环境中使用多种镜像仓库。
• 应用商店：Rancher提供了一个应用商店，通过商店中的应用程序模版的可以简化部署复杂应用的过程。进入应用商店页面，你可以看到所有的应用的应用模版。
• 应用栈：应用栈可以部署多个容器服务，是一组容器服务的集合。一个应用栈对应一个业务群或者一个系统，用来确定系统边界。
• 服务：服务分为两种：基础设施服务和用户服务。基础设施服务位于应用商店中，每个环境创建时需要配置环境模板，环境模板中选择需要启动的基础设置服务。用户服务是用户自定义的服务，由用户构建推送到镜像仓库再部署到应用栈。

基本使用

Rancher如何部署参考官方文档快速开始，这里不作赘述，这里假设Rancher已经有管理员部署完毕并建立用户账号，现在介绍如何将自建的镜像部署到Rancher应用栈。

1. 首先要有主机，添加主机的过程参考快速开始。
2. 用环境模板创建环境(Environments)，已创建的环境显示在环境管理界面的环境列表中，环境列表中有一个是登录Rancher后的默认环境，列表右边有一列“Switch to this Environment”按钮，点击这个按钮即可切换到该环境。
3. 一个环境下包含多个应用栈(Stacks)，基础设置服务应用栈可以从应用商店中添加，用户服务应用栈可以自定义也可以从应用商店中添加，添加一个应用栈就相当于建立一个容器服务集合。
4. 一个应用栈包含多个服务(Services)，用户自定义服务就建立在自定义应用栈上，也就是我们通过“添加服务”(Add Service)将镜像部署在应用栈，一个服务由多个容器组成。

5. 创建服务(Add Service)：创建服务时选项比较多，以Cattle服务为例介绍几个最重要的参数。

   1. 选择镜像(Select Image)：这个应该比较好理解，不用多解释。
   2. 端口映射(Port Map)：外部访问端口和容器内部端口对应关系。

   3. 服务链接(Service Links)：这个选项参数比较多，这里只介绍几个常用的。

      1. 命令(Command) ：这里面大部分配置都可以写到Dockerfile里面，用的多的是环境变量，环境变量用于服务初始化参数。
      2. 网络(Networking)：Network有四种参数：None——容器除了回环不配置任何网络信息；Host——容器使用宿主机的网络信息；Bridge——容器通过虚拟网桥接入网络，使用虚拟子网的网络信息；Container-已存在的一个共享网络信息。
      3. 调度(Scheduling)：这里可以设置调度规则(Add Scheduling Rule)，不管是通过服务或者负载均衡来创建容器时，Rancher都提供了为容器创建标签的选项，并且可以安排你想要放置容器的主机，调度规则提供了让Rancher选择要使用哪个主机的灵活性。在Rancher中使用标签来帮助定义调度规则。你可以根据需要在容器上创建任意数量的标签。通过多个调度规则，你可以完全控制容器在哪些主机上创建。你可以要求在具有特定主机标签、容器标签或名称、特定服务的主机上启动该容器。这些调度规则可以帮助你创建容器对主机的黑名单和白名单。

容器服务的管理比较简单，主要就是启停、升级，升级也就是蓝绿发布。

总结

使用GitLab可以实现DevOps的开发、测试、构建的过程管理，Rancher则负责DevOps部署和运维的过程管理，这两个工具结合就可以完整的实现DevOps全过程，当然还需要依赖一个云计算平台建立云主机，公司内部如果需要自建虚拟化服务器可以使用XenServer。