docker部署devops

使用docker部署devops;

  • 基础环境搭建
    • rabbitmq 集群 –> 完成
    • zookeeper 集群 –> 完成
    • jenkins 集群  –> 完成
    • redis 集群(3主3从)  –> 完成
    • nginx+keepalive –> 完成
    • github 版本管理
    • 配置中心 集群
    • nexus 私服
    • 注册管理中心搭建
    • 任务管理器
  • 数据层环境搭建
    • mysql 数据库 集群
    • fastdfs 数据存储层 集群
  • 监控环境搭建
    • elk 搭建
    • pinpoint 搭建
    • portainer 监控
    • zabbix 搭建
    • zikpin 监控
  • 基础服务搭建
    • 用户服务 集群
    • 日志服务 集群
    • 内容服务 集群
    • CAS 认证 集群
    • 微信服务 集群
    • 管理平台 集群
    • 通知服务 集群
  • 业务服务搭建
    • 业务服务集群
  • 前端服务搭建
    • 前端服务集群

使用 Docker搭建 ZooKeeper 集群

镜像下载

hub.docker.com 上有不少 ZK 镜像, 不过为了稳定起见, 我们就使用官方的 ZK 镜像吧.
首先执行如下命令:

docker pull zookeeper

当出现如下结果时, 表示镜像已经下载完成了:

>>> docker pull zookeeper
Using default tag: latest
latest: Pulling from library/zookeeper

e110a4a17941: Pull complete
a696cba1f6e8: Pull complete
bc427bd93e95: Pull complete
c72391ae24f6: Pull complete
40ab409b6b34: Pull complete
d4bb8183b85d: Pull complete
0600755f1470: Pull complete
Digest: sha256:12458234bb9f01336df718b7470cabaf5c357052cbcb91f8e80be07635994464
Status: Downloaded newer image for zookeeper:latest

ZK 镜像的基本使用

启动 ZK 镜像

>>> docker run --name my_zookeeper -d zookeeper:latest

这个命令会在后台运行一个 zookeeper 容器, 名字是 my_zookeeper, 并且它默认会导出 2181 端口.
接着我们使用:

docker logs -f my_zookeeper

这个命令查看 ZK 的运行情况, 输出类似如下内容时, 表示 ZK 已经成功启动了:

>>> docker logs -f my_zookeeper
ZooKeeper JMX enabled by default
Using config: /conf/zoo.cfg
...
2016-09-14 06:40:03,445 [myid:] - INFO  [main:NIOServerCnxnFactory@89] - binding to port 0.0.0.0/0.0.0.0:2181

使用 ZK 命令行客户端连接 ZK

因为刚才我们启动的那个 ZK 容器并没有绑定宿主机的端口, 因此我们不能直接访问它. 但是我们可以通过 Docker 的 link 机制来对这个 ZK 容器进行访问. 执行如下命令:

docker run -it --rm --link my_zookeeper:zookeeper zookeeper zkCli.sh -server zookeeper

如果对 Docker 有过了解的话, 那么对上面的命令一定不会陌生了.
这个命令的含义是:

  1. 启动一个 zookeeper 镜像, 并运行这个镜像内的 zkCli.sh 命令, 命令参数是 “-server zookeeper”
  2. 将我们先前启动的名为 my_zookeeper 的容器连接(link) 到我们新建的这个容器上, 并将其主机名命名为 zookeeper

当我们执行了这个命令后, 就可以像正常使用 ZK 命令行客户端一样操作 ZK 服务了.

ZK 集群的搭建

因为一个一个地启动 ZK 太麻烦了, 所以为了方便起见, 我直接使用 docker-compose 来启动 ZK 集群.
首先创建一个名为 docker-compose.yml 的文件, 其内容如下:

version: '2'
services:
    zoo1:
        image: zookeeper
        restart: always
        container_name: zoo1
        ports:
            - "2181:2181"
        environment:
            ZOO_MY_ID: 1
            ZOO_SERVERS: server.1=zoo1:2888:3888 server.2=zoo2:2888:3888 server.3=zoo3:2888:3888

    zoo2:
        image: zookeeper
        restart: always
        container_name: zoo2
        ports:
            - "2182:2181"
        environment:
            ZOO_MY_ID: 2
            ZOO_SERVERS: server.1=zoo1:2888:3888 server.2=zoo2:2888:3888 server.3=zoo3:2888:3888

    zoo3:
        image: zookeeper
        restart: always
        container_name: zoo3
        ports:
            - "2183:2181"
        environment:
            ZOO_MY_ID: 3
            ZOO_SERVERS: server.1=zoo1:2888:3888 server.2=zoo2:2888:3888 server.3=zoo3:2888:3888

这个配置文件会告诉 Docker 分别运行三个 zookeeper 镜像, 并分别将本地的 2181, 2182, 2183 端口绑定到对应的容器的2181端口上.
ZOO_MY_ID 和 ZOO_SERVERS 是搭建 ZK 集群需要设置的两个环境变量, 其中 ZOO_MY_ID 表示 ZK 服务的 id, 它是1-255 之间的整数, 必须在集群中唯一. ZOO_SERVERS 是ZK 集群的主机列表.

接着我们在 docker-compose.yml 当前目录下运行:

COMPOSE_PROJECT_NAME=zk_test docker-compose up

即可启动 ZK 集群了.
执行上述命令成功后, 接着在另一个终端中运行 docker-compose ps 命令可以查看启动的 ZK 容器:

>>> COMPOSE_PROJECT_NAME=zk_test docker-compose ps
Name              Command               State           Ports
----------------------------------------------------------------------
zoo1   /docker-entrypoint.sh zkSe ...   Up      0.0.0.0:2181->2181/tcp
zoo2   /docker-entrypoint.sh zkSe ...   Up      0.0.0.0:2182->2181/tcp
zoo3   /docker-entrypoint.sh zkSe ...   Up      0.0.0.0:2183->2181/tcp

注意, 我们在 “docker-compose up” 和 “docker-compose ps” 前都添加了 COMPOSE_PROJECT_NAME=zk_test 这个环境变量, 这是为我们的 compose 工程起一个名字, 以免与其他的 compose 混淆.

使用 Docker 命令行客户端连接 ZK 集群

通过 docker-compose ps 命令, 我们知道启动的 ZK 集群的三个主机名分别是 zoo1, zoo2, zoo3, 因此我们分别 link 它们即可:

docker run -it --rm \
        --link zoo1:zk1 \
        --link zoo2:zk2 \
        --link zoo3:zk3 \
        --net zktest_default \
        zookeeper zkCli.sh -server zk1:2181,zk2:2181,zk3:2181

通过本地主机连接 ZK 集群

因为我们分别将 zoo1, zoo2, zoo3 的 2181 端口映射到了 本地主机的2181, 2182, 2183 端口上, 因此我们使用如下命令即可连接 ZK 集群了:

zkCli.sh -server localhost:2181,localhost:2182,localhost:2183

查看集群

我们可以通过 nc 命令连接到指定的 ZK 服务器, 然后发送 stat 可以查看 ZK 服务的状态, 例如:

>>> echo stat | nc 127.0.0.1 2181
Zookeeper version: 3.4.9-1757313, built on 08/23/2016 06:50 GMT
Clients:
 /172.18.0.1:49810[0](queued=0,recved=1,sent=0)

Latency min/avg/max: 5/39/74
Received: 4
Sent: 3
Connections: 1
Outstanding: 0
Zxid: 0x200000002
Mode: follower
Node count: 4
>>> echo stat | nc 127.0.0.1 2182
Zookeeper version: 3.4.9-1757313, built on 08/23/2016 06:50 GMT
Clients:
 /172.18.0.1:50870[0](queued=0,recved=1,sent=0)

Latency min/avg/max: 0/0/0
Received: 2
Sent: 1
Connections: 1
Outstanding: 0
Zxid: 0x200000002
Mode: follower
Node count: 4
>>> echo stat | nc 127.0.0.1 2183
Zookeeper version: 3.4.9-1757313, built on 08/23/2016 06:50 GMT
Clients:
 /172.18.0.1:51820[0](queued=0,recved=1,sent=0)

Latency min/avg/max: 0/0/0
Received: 2
Sent: 1
Connections: 1
Outstanding: 0
Zxid: 0x200000002
Mode: leader
Node count: 4

通过上面的输出, 我们可以看到, zoo1, zoo2 都是 follower, 而 zoo3 是 leader, 因此证明了我们的 ZK 集群确实是搭建起来了.

因为docker-compose.yml的格式比较蛋疼,如果你按照上述文件手写起不来,报错.yml文件报错。那就复制粘贴然后启动。亲自试用,绝对可行。

svn分支管理的使用与经验

最近项目用上了svn分支管理,因为项目太过庞杂,版本迭代也过于频繁,致使多个版本的代码交杂在一起,难以维护,无法保证其中某个版本的稳定性。当然,我们也用过很土的办法,代码复制一份出来,但是,这个副本也需要加上新开发的功能。

所以,我们决定使用svn分支管理。当然,这有代价,svn版本管理对二进制文件不友好,可能文件分支合并时二进制文件会难以处理。(这里说的二进制文件,泛指所有非文本文件,比如说美术资源,策划文档)

svn分支简述

使用分支最主要的目的是,多个分支可以并行,相互不干扰,而且任何时候都可以合并。其次,容易保证主干的稳定性。

没有分支的时候,你的svn可能是这样的:

就一份代码存在主干(trunk),当然也不会有主干这个说法。开发完1.0,继续开发2.0,版本一个一个迭代。

有了分支后,你的svn可能就是这样的了:

主干用来存放稳定的代码,每个版本都会开一个分支,等版本完成后再合并到主干。版本一个一个迭代,但可以并行开发。

svn分支管理

接下来,简单讲解下 如何使用svn做分支管理。

第一步,建立主干分支目录结构

第二步,创建分支

在主干目录 trunk 右键,在svn菜单选择 Branch/tag…

步骤①是分支地址,这里直接以 /branches/1

步骤②是取trunk版本,HEAD revision表示最新版本,其他可通过 show log选择

执行 OK 后,到 branches 目录 svn update 就可以看到最新的分支了。

第三步,合并分支到主干

分支就是开发目录了,现在分支提交一个文件做测试。

然后,合并这个文件分支到主干。

现在到主干目录,右键svn菜单选 Merge…

这个是将分支或主干的修改合并到当前工作目录,继续如下。

接下来点完成,如果没冲突的话,分支文件就合到主干了。

但这里还要一个操作,就是在主干提交分支合过来的文件。

题外话,之所以要有这一步,除了对分支内容进一步修改,还可以同时合并多个分支。选择权交给用户。

另外,主干内容合到分支,也是使用 Merge 命令。

svn分支应用

根据项目的不同,实际上的分支架构也会不同。以我们项目为例,我们是做游戏的,项目过于庞杂,版本迭代非常频繁。在版本1.1还没完成时,我们可能就要开发2.0版本,这样,版本1.1和版本2.0就要并行开发。而且,我们对稳定性有非常高的要求。

为此,我们设计了这样的svn架构。

测试分支

为了保证主干稳定,我们加了测试分支(如 rel_1.1的测试分支为 rel1.1_test )。测试分支1.1是在分支1.1开发结束后开的,等待测试修复bug完成后,就会把测试分支1.1合入主干及分支1.1。合并完成后,这个测试分支将会关闭。

多分支并行

因为项目需求较多,版本迭代繁杂,所以在版本1.1还没结束时,就开了版本2.0的分支。当分支2.0需要测试合并到主干时,就会从主干合并最新的文件到2.0测试分支,测试通过后,再合并到主干。

分支合并的时机

对我们而言,不同分支的最大区别是功能上线的时间点。我们根据上线周期划分功能,拆分到不同分支。因为开发需求多,迭代过于频繁,所以靠后的分支对比之前的分支通常只是多了某些新功能。这样,分支的出现,避免了未开发完成的功能影响了已开发完的功能,导致当前版本的不稳定。所以,合并分支的时机就是这个分支的功能要不要上线。

这样,主干永远是稳定的,也只有经过测试的内容,才会合入主干。同时,多个版本也可以并行。

大型分布式团队的代码版本管理

介绍这个话题,有两个原因:

  1. 从开始工作到现在,我经历过没有代码版本管理、代码集中式管理,以及现在的分布式管理,我深刻体会到它在软件开发过程中的重要性;
  2. 我在工作中遇到的很多客户都存在对于代码版本管理的各种问题、困惑和不同的需求。

所以我希望将我在这个方面的经验分享给更多人,希望能帮助更多的团队解决在代码版本控制方面的问题和疑惑。

(图片来自:http://t.cn/RSPnA5t)

一、代码版本管理系统的历史

代码版本管理系统大致可以分为三个时代:

第一代:本地式

这代主要的特点提供本地代码版本控制,比如SCCS(1972)、 PVCS(1985)等。

这代主要实现了基本的代码版本管理,但缺点是无法让多人同时对一个版本库进行修改。这个也和当时软件规模不够大有关,也没有这样的需求。

第二代:客户端-服务器式

这代主要的特点是提供集中式服务器端代码版本控制,比如 CVS(1986), ClearCase(1992), Visual SourceSafe(1994), Perforce(1995), Subversion(2000) 等。

这代主要是实现了中心服务器端的代码版本管理,特点是可以让多人同时对一个代码版本库进行同步和修改,但缺点也相当明显:

  1. 在无法连接服务器的情况下,无法查看日志以及提交和比较代码版本(慢速网络和远程异地工作的程序员的痛),以及当服务或者网络出现问题的时候很多人员就会无法工作。
  2. 不支持local branch,导致branch创建管理复杂,并且一旦创建就很难修改(快速迭代开发中的程序员的痛)
  3. 由于只有一个中心端服务器,一旦发生灾难性问题,那么所有日志都会丢失,所以需要经常做备份(备份需要不小的成本)
  4. 如果软件代码量过于庞大,一般会出现速度缓慢的情况,因为每次的日志查询、不同版本之间的代码比较和代码提交等操作都需要和服务器通信,造成服务器端的负载过大。

第三代:分布式

这代主要的特点是提供分布式代码版本控制,比如Git(2005), Mercurial(2005)等。

这代结合了第一代和第二代的优点并实现了分布式的代码版本管理。

这代的优点:分布式管理,在没有和服务器有连接的情况下仍然可以查看日志,提交代码,创建分支;支持local branch,可以快速方便的实现各种分支管理;支持分布式,从而可以实现分块管理,以及负载分流管理。

缺点是有一定的学习曲线,比如分布方式下的代码同步,local branch的理解与运用,分布式代码管理的理解与运用等。详细的比较可以参考:这里

二、大型分布式团队

曾经有这样一个分布式团队,他们在多个城市都有小分队,并且正在开发一个大型项目,见下图

他们使用的代码版本管理工具是第二代代码管理工具SVN,管理方案如下:

但是他们在使用的过程中却遇到了下面这些问题与痛点。

由于是分布式团队,所以:

  • 基于团队的代码模块分离困难

当服务器不可用时:

  • 不能查看提交记录
  • 不能比较文件
  • 不能提交代码

创建代码分支时:

  • 分支创建速度慢
  • 多分支管理困难

在提交代码时:

  • 希望有Code Review
  • 希望有CI Review

因为代码庞大:

  • 查看日志慢

备份代码库的时候:

  • 需要停机备份
  • 备份成本高

针对以上问题,可以使用新一代的分布式的代码版本管理系统来解决,见下图:

其中每一个团队都有自己独立的代码库,有一个中心库用于同步这些独立的代码库,并且每个库都由团队自己管理和维护。而且代码版本管理系统需要支持轻量分支,代码评审,离线提交,离线查看日志等功能。

但是由于当前没有一个单一的代码版本管理工具能同时满足以上所有需求,所以很多公司都基于它们开发集成管理系统,比如Gerrit,GitLab,GitHub,BitBucket等。其中的Gerrit由于其开源,免费,以及由Google开发和维护,并管理着Android,OpenStack等大型项目源代码的特点,成为了大型分布式团队优先选择的系统。

三、Gerrit

Gerrit是由Google开发的,用于管理Google Android项目源代码的一个系统。它是基于Java和Prolog等开发的,支持Git,权限管理,代码评审等综合的一个管理系统。它与GitLab和GitHub最大的不同是它隐藏了代码分库管理的细节,使得开发人员不需要进行fork这样的手工分库和同步操作就可以进行代码开发和提交,节省了开发人员的时间,见下图。

由于Android本身是一个开源项目,所以贡献者非常多,开发团队也遍布多个地方(存在时差),导致“如何保证代码质量”成为一个很大的问题。为此Google在Gerrit中加入了功能强大并且十分严格的代码评审系统。

首先当代码提交以后并不会直接merge到中心库里面,它会暂时存在一个临时库里面,同时生成一个代码评审记录,并向特定的评审人员发送请求评审的邮件。当评审者在评审代码之后,如果通过就需要在Gerrit系统里面对代码进行打分,如果通过了就可以将代码merge到中心库里面去,如果没有通过,那么这个代码提交就需要被返还给开发者进行修改。

与此同时它还可以自动触发一次包含本次代码提交的CI构建(前提需要手工预先配置),如果CI自动构建和测试通过,也可以自动在Gerrit系统里面进行打分,可以给最终进行merge的人员进行参考。示意流程见下图。

由于Android源代码由上百个独立的代码库组成,并且编译一个Android系统需要大部分代码库里面的代码,所以如何管理如此多的代码库也是一个难题,比如如何一次性同步需要编译一个需要支持特定设备的代码库组合。为此Google基于Python语言开发一个工具叫Repo ,这个工具可以自定义你需要的代码库的组合,并且一次性对这些代码库进行同步,比如pull和push,见下图。

四、SVN到Git的迁移

对于想从集中式代码管理系统迁移到分布式代码管理系统的团队来讲,如果团队规模小,那么问题一般都不大,但是对于大型分布式团队却是困难重重。最主要的两个困难:

  1. 代码量太大,很难一次性将所有的代码和日志等在短时间内迁移成功。
  2. 由于下属团队太多,很难同一时间让所有团队都切换至新的代码管理工具。

为了解决这些难题,一般都会首先选用1个团队来使用新的代码版本管理工具。如果这个团队转换成功,再将其作为标杆向其他团队推广,从而逐步的将所有团队切换到新的工具上去。

SVN到Git的迁移方案一般主要会使用两种工具:

  1. 开源免费的git-svn;
  2. 商业收费的Subgit。

其中使用Subgit的迁移方案如下图:

如果团队组资源充足,还可以使用Gerrit搭建一个独立的Git服务器,从而以分布式的方式进行代码迁移,如下图:

五、多产品线的管理

使用同一个中心代码库管理多产品线一直是大型项目的一个困难点,特别是使用SVN这样的工具更是难以管理,因为SVN这种工具的Branch本质上是一个目录拷贝,并且速度慢,而且代码回迁也需要手动进行。但是如果使用Git的特性来管理多产品线,比起SVN是事半功倍。具体方案见下图:

总结:

分布式代码版本管理系统并不一定适合所有团队,比如中小团队可能更关心的只是成本更低,简单易用,那么SVN等这类集中式版本管理工具还是更为适合。但是不管团队最终选用什么代码版本管理工具,只要适合自己的团队的开发流程和工作方式,并且代码管理顺畅就可以了。

maven的scm插件介绍及使用示例

Maven中为我们集成了软件配置管理的(SCM:Software Configuration Management)功能,他可以支持我们常用SVN、CVS等,到现在我使用的1.8.1版本,共支持18个命令:

scm:branch - branch the project(创建项目的分支)
scm:validate - validate the scm information in the pom(校验SCM的配置信息)
scm:add - command to add file(增加一个文件)
scm:unedit - command to stop editing the working copy(停止编辑当前COPY)
scm:export - command to get a fresh exported copy(拉一个全新的分支)
scm:bootstrap - command to checkout and build a project(checkout并编译工程)
scm:changelog - command to show the source code revisions(显示源码版本)
scm:list - command for get the list of project files(列出工程的文件)
scm:checkin - command for commiting changes(提交变更)
scm:checkout - command for getting the source code(获取源码)
scm:status - command for showing the scm status of the working copy(获取本地项目的状态)
scm:update - command for updating the working copy with the latest changes(从服务器获取最新的版本)
scm:diff - command for showing the difference of the working copy with the remote one(比较本地与远程服务器的差异)
scm:update-subprojects - command for updating all projects in a multi project build(更新子项目)
scm:edit - command for starting edit on the working copy(编辑)
scm:tag - command for tagging a certain revision(打标签)

常用命令介绍

而我们常用只有以下这两个命令:
Usage
The SCM Plugin maps a lot of commands to a variety of scm implementations. But there are only 2 frequently used commands:

checkin - 提交变更
update - 从服务器上获取最新的版本

配置及使用

其它的SCM都有自己独特的命令来操作提交变更、或从服务器上获取最新的源吗,如SVN及CVS的操作就很不相同,使用Maven担任的SCM机制,就可以使得SCM的操作变得统一,以下是一个SVN配置示例,将以下的示例配置到pom.xml文件中

<project>
  ...
  <packaging>jar</packaging>
  <version>1.0-SNAPSHOT</version>
  <name>SCM Sample Project</name>
  <url>http://somecompany.com</url>
  <scm>
    <connection>scm:svn:http://somerepository.com/svn_repo/trunk</connection>
    <developerConnection>scm:svn:https://somerepository.com/svn_repo/trunk</developerConnection>
    <url>http://somerepository.com/view.cvs</url>
  </scm>
  ...
</project>

照这样配置好的,现在我们要做提交或者更新,就按如下按行命令
提交:

mvn -Dmessage="<commit_log_here>" scm:checkin

获取最新版本:

mvn scm:update

SCM支持的连接类型

SCM支持两种连接类型:connection 及 developerConnection。
以下是一个连接类型为connection的配置示例:

<project>
  ...
  <build>
    [...]
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-scm-plugin</artifactId>
        <version>1.8.1</version>
        <configuration>
          <connectionType>connection</connectionType>
        </configuration>
      </plugin>
      ...
    </plugins
    ...
  </build>
  ...
</project>

以下是一个连接类型为developerConnection的配置示例:

<project>
  ...
  <build>
    ...
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-scm-plugin</artifactId>
        <version>1.8.1</version>
        <configuration>
          <connectionType>developerConnection</connectionType>
        </configuration>
      </plugin>
      ...
    </plugins
    ...
  </build>
  ...
</project>