GitLab基础概念与DevOps平台

一、常见的开发版本管理工具

1、VSS -- Visual Source Safe 

此工具是Microsoft提供的,是使用的相当普遍的工具之一,他可以与VS.net进行无缝集成,成为了独立开发人员和小型开发团队所适合的工具,基本上Window平台上开发的中小型企业,当规模较大后,其性能通常是无法忍受的,对分支与并行开发支持的比较有限.

2、CVS--Concurrent Versions System

此工具是一个开源工具,与后面提到的SVN是同一个厂家Collab.Net提供的.CVS是源于unix的版本控制工具,对于CVS的安装和使用最好对unix的系统有所了解能更容易学习,CVS的服务器管理需要进行各种命令行操作.目前,CVS的客户端有winCVS的图形化界面,服务器端也有CVSNT的版本,易用性正在提高.此工具是相当著名,使用得相当广泛的版本控制工具之一,使用成熟的“Copy-Modify-Merge"开发模型,可以大大的提高开发效率,适合于项目比较大,产品发布频繁,分支活动频繁的中大型项目.

3、SVN --CollabNet Subversion

此工具是在CVS的基础上,由CollabNet提供开发的,也是开源工具,应用比较广泛.他修正cvs的一些局限性,适用范围同cvs,目前有一些基于SVN的第三方工具,如TortoiseSVN,是其客户端程序,使用的也相当广泛.在权限管理,分支合并等方面做的很出色,他可以与Apache集成在一起进行用户认证.

不过在权限管理方面目前还没有个很好用的界面化工具,SVNManger对于已经使用SVN进行配置的项目来说,基本上是无法应用的,但对于从头开始的项目是可以的,功能比较强大,但是搭建svnManger比较麻烦.是一个跨平台的软件,支持大多数常见的操作系统.作为一个开源的版本控制系统,Subversion管理着随时间改变的数据.
这些数据放置在一个中央资料档案库中.这个档案库很像一个普通的文件服务器,不过它会记住每一次文件的变动.这样你就可以把档案恢复到旧的版本,或是浏览文件的变动历史.Subversion是一个通用的系统,可用来管理任何类型的文件,其中包括了程序源码.

4、GIT

因为最初是从Linux起家的,非常依赖文件系统的一些特性,这些在Linux下表现的很好,而Windows下特别糟糕.Git是一个开源的分布式版本控制系统,用以有效、高速的处理从很小到非常大的项目版本管理.
Git是Linus Torvalds为了帮助管理Linux内核开发而开发的一个开放源码的版本控制软件.Torvalds开始着手开发Git是为了作为一种过渡方案来替代BitKeeper,后者之前一直是Linux内核开发人员在全球使用的主要源代码工具.
开放源码社区中的有些人觉得BitKeeper的许可证并不适合开放源码社区的工作,因此Torvalds决定着手研究许可证更为灵活的版本控制系统.尽管最初Git的开发是为了辅助Linux内核开发的过程,但是我们已经发现在很多其他自由软件项目中也使用了Git.

5、BitKeeper 

是由BitMover公司提供的,BitKeeper自称是“分布式”可扩缩SCM系统.不是采用C/S结构,而是采用P2P结构来实现的,同样支持变更任务,所有变更集的操作都是原子的,与svn,cvs一致.

在开发过程中大多数企业对GIt的青睐度比较高，基于Git的图形界面工具也有很多如SourceTree等，各大开发工具都对Git做出了集成，相对与SVN来说，SVN适合项目管理，Git仅适用于代码管理，如果只为了对代码进行管理，建议适用Git。

二、GIt、GitHub、GitLab区别

从上面的信息可以看出,Git是常见的版本控制工具，GitHub和GitLab是啥呢：

GitHub 和  GitLab 都是基于 web 的 Git 仓库，使用起来二者差不多，它们都提供了分享开源项目的平台，

为开发团队提供了存储、分享、发布和合作开发项目的中心化云存储的场所。

GitHub 作为开源代码库，拥有超过 900 万的开发者用户，目前仍然是最火的开源项目托管平台，GitHub 同时

提供公共仓库和私有仓库，但如果使用私有仓库，是需要付费的。

GitLab 解决了这个问题，你可以在上面创建私人的免费仓库。

(1) 允许免费设置仓库权限；

(2) 允许用户选择分享一个 project 的部分代码；

(3) 允许用户设置 project 的获取权限，进一步提升安全性；

(4) 可以设置获取到团队整体的改进进度；

(5) 通过 innersourcing 让不在权限范围内的人访问不到该资源；

GitLab 让开发团队对他们的代码仓库拥有更多的控制，相比较 GitHub , 它有不少特色：
所以，从代码的私有性上来看，GitLab 是一个更好的选择。但是对于开源项目而言，GitHub 依然是代码托管的首选。

三、基于GitLab的DevOps平台

GItLab对项目管理的支持，是一套完整的DevOps平台，一种具有无限可能性的应用程序。DevOps 是一个完整的面向IT运维的工作流，以 IT 自动化以及持续集成（CI）、持续部署（CD）为基础，来优化程式开发、测试、系统运维等所有环节。

重点

1. 一定要设置好邮箱，能发送邮件
2. gitlab用户注册、密码重置、使用手册等等一定做成wiki免密内网公开访问，开发、测试人员可以自助解决gitlab使用中的各类问题。
3. 有统一账户注册自动流程，审批后，自动注册各类账户，gitlab的账户属性设置为unblock。
4. 有统一账户注销自动流程，审批后，自动可以自动将离职人员的各类账户设置被blocked或者disable。

邮件设置

重点：gitlab默认配置也可以发邮件，但是有可能会被识别为垃圾邮件

vi /etc/gitlab/gitlab.rb
### Email Settings
gitlab_rails['gitlab_email_enabled'] = true
gitlab_rails['gitlab_email_from'] = '邮箱地址'
gitlab_rails['smtp_enable'] = true
gitlab_rails['smtp_address'] = "smtp.exmail.qq.com"
gitlab_rails['smtp_port'] = 25
gitlab_rails['smtp_user_name'] = "邮箱地址"
gitlab_rails['smtp_password'] = "password"
gitlab_rails['smtp_domain'] = "exmail.qq.com"
gitlab_rails['smtp_authentication'] = "login"

端口号实际测试是465，gitlab给出的是587

2.更新配置 gitlab-ctl reconfigure 
3.重启服务 gitlab-ctl restart

4.非必需步骤进入控制台gitlab-rails console （测试邮件服务是否正常）

Notify.test_email("XXX@XXX.XX","title","gitlab").deliver_now 

权限

每个项目组新建一个group，每个group的开发leader设置成 group master，新的开发成语由group master进行自助授权到相应项目组中。

监控

admin area --> settings 可以通过调取gitlab状态报告的方式监控

持续交付/持续部署

在持续集成中，我们完成了从代码到镜像的制作。最终将生成的镜像交付到私有镜像库中。在持续交付持续部署中，要将完成的镜像发布到部署环境中。

部署也是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

备份

gitlab-ctl stop unicorn
gitlab-ctl stop sidekiq
gitlab-rake gitlab:backup:create
gitlab-ctl start unicorn 
gitlab-ctl start sidekiq

总结

通过以上的内容，我们可以构建起一个简单的devops体系闭环，要达到一个完善的平台，还有很多事情要做。如，自动化测试，配置中心，发布流程，敏捷开发等等。在这个蓝本的基础上根据需求和痛点驱动逐步的完善。