自己写的django项目用docker打包后能够通过docker-compose命令一键启动，自以为非常方便了。但是在长久使用过程中，仍然会有版本延迟，经常push代码后，懒得去docker-compose build和up了。最近了解到了持续集成的概念，发现这就是自己想要的东西，也就学习了一番，用jenkins实现了项目部署的自动化，本文记录下学习和配置的过程。

1. 基本概念

持续集成（Continuous integration，简称CI），就是频繁的将代码集成到主干，类似于一天要commit很多次代码。但是光commit代码也不知道代码在生产环境中是否存在问题，代码是否跑得起来呀。所以需要自动化构建来进行验证，尽快的发现即成错误。

网上很多地方都有这张图，可以解释持续集成的概念

每次提交后，都能通过组件自动化的构建、测试代码，能最快的发现代码中存在的问题，这就是持续集成。

持续交付（Continuous delivery）是指频繁的将软件的版本交给质量团队或者用户。

持续部署（Continuous deployment）是持续交付的下一步，代码经过评审后，自动部署到生产环境。持续交付是持续部署的基础。

综上概念，其实我的需求就是持续部署。

2. docker启动jenkins

经过一番搜索后，决定采用jenkins做持续集成和持续部署。jenkins是一个开源的软件，配置起来方便，支持docker部署。

jenkins有两种安装方式，一种是服务器直接安装，另一种是使用docker安装。在使用惯了docker后，决定采用docker安装，一来安装方便，二来不破坏服务器的本地环境，保持本地环境的干净。

jenkins的docker镜像是基于debian的，基本的python和docker命令都没有，所以需要先自行定义一个Dockerfile在官方镜像的基础上装一些软件工具。

docker in docker

还需要说明一点的是我的代码环境部署的时候是通过docker-compose命令执行的，而代码是放在服务器上的，所以要在jenkins的docker容器中去操作本地的docker容器，这就是所谓的docker in docker。docker官方也提供了解决方案，就是将本地的/var/run/docker.sock映射到docker容器中。

Dockerfile

根据以上的思路，就可以写我们的Dockerfile了。在我的需求中，我要自定义的镜像要完成以下几个步骤：

替换debian的镜像源地址；
增加python3、docker-compose命令
修改时区

具体的dockerfile如下：

FROM jenkins/jenkins:lts

USER root

RUN set -ex \
    && sed -i "s@http://deb.debian.org@http://mirrors.aliyun.com@g" /etc/apt/sources.list \
    && apt-get update \
    && apt-get install --no-install-recommends -y python3 docker-compose gnutls-bin lsb-release

RUN ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime \
    && echo "Asia/Shanghai" > /etc/timezone

docker-compose.yml

对应的docker-compose.yml文件如下：

version: '2'
services:
  jenkins:
    build: .
    privileged: true
    user: root
    ports:
      - 8080:8080
      - 50000:50000
    container_name: jenkins
    volumes:
      - /root/jenkins/jenkins_home:/var/jenkins_home
      - /var/run/docker.sock:/var/run/docker.sock
      - /usr/bin/docker:/usr/bin/docker
      - /path/to/code:/path/to/code

需要注意的是在docker容易中的相对路径和外部的相对路径是有很大差别的，所以应当保持代码的路径一致，也就是/path/to/code:/path/to/code，该映射的容器内外路径一致。

通过以上配置后，可以得到如下的几个文件，jenkins的配置文件会放在jenkins_home目录下，可以自动修改：

剩下的就是两条shell命令，就能启动jenkins了。

1 2	docker-compose build docker-compose up

3. jenkins配置

jenkins启动后，就是内部的项目配置了，网上有非常多的配置文章，就不详细介绍配置步骤了，这里只记录几个重要的点。

构建触发器

构建触发器就是通过什么去触发jenkins的构建流程，jenkins提供如下几种

触发远程构建 (例如,使用脚本)

其他工程构建后触发

定时构建

GitHub hook trigger for GITScm polling

轮询 SCM

前三种通过字面意思都很好理解怎么触发的。GitHub hook trigger for GITScm polling是通过github的action去回调jenkins的api去触发构建，这个需要将jenkins暴露在公网github能访问到的地址，这个不是我想要的。

轮询 SCM是定时去轮询git仓库是否有代码提交，可以自定义间隔时间，如果代码有更新，则触发新的构建，如果代码无更新，则不会去构建，是一种定时的主动请求，这这正是我所需要的。

构建流程

构建流程jenkins提供一系列的方式能够自定义工作流。我这里需求很简单，就是执行shell命令能够docker-compose就行，所以我选择执行shell命令的构建。

shell命令如下：

cd /path/to/code
docker-compose down
docker-compose build 
docker-compose up -d

通过以上配置后，jenkins就能自动监测github的代码更新情况，如果存在更新，就能实时的部署到服务器上，免去了中间繁琐的步骤。

全局git代理

还需要注意的一个点就是，github访问极不稳定，大部分时候会pull不下来代码，jenkins就会报git的各种奇特错误，基本都是git代理的问题。所以可以通过git全局代理的方式访问github。

配置也很简单，进入到系统管理-> 系统配置，勾选环境变量，添加键http_proxy，值socks5://10.10.10.10:1080，键https_proxy，值socks5://10.10.10.10:1080，1080端口对应到你自己的代理上面，至于代理怎么来的，可自行百度。

添加了环境变量后，git就能自动通过代理访问github了。

以上便是折腾jenkins的过程，jenkins是个很强大的工具，能够完成devops的各种自动化环节。但对于我的项目来说，jenkins就起了一个自动部署的工作，能够帮我把代码从github拉下来，然后自动build和up，免去了这些繁琐的功能。至于其他的一些高级功能，以后碰到了再去学习。