GitLab-CI快速开始

发表于 2017-04-26 | 更新于 2020-06-08 | 阅读次数：

假定已经安装好了GitLab-Runners

Hello World !

在仓库根目录创建 `.gitlab-ci.yml` 文件, 内容如下

1
2
3

job-1:
  script:
    - echo "Hello World"

这样, 在每次提交代码后, 都会自动执行以上脚本. 其中`job-1`是任务名称, 可以定义多个任务,

script下面是 shell 命令, 只要命令执行成功, 就代表本次构建通过(出现passed标记)

如图

这样, 一次简单的持续集成已经搞定了.

远程拉取代码

使用ssh远程登录服务器, 然后执行`git pull` 拉取代码, 实现代码热更新

由于ssh无密码登录需要用到密钥, 所以首先需要注入私钥

如

release-doc:
    stage: deploy
    script:
        - ssh root@$DEPLOY_SERVER "cd /mnt/data/docker-gollum/wiki && git pull origin master"

`

一个更详细的例子 [[通过gitlab-ci实现文件的自动部署]]

通过Docker镜像实现自动部署

见文章 [[GitLab-CI使用Docker进行持续部署]]

参考资料

GitLab-CI简介

发表于 2017-04-26 | 更新于 2020-06-08 | 阅读次数：

概述

持续集成（CI）和持续交付(CD) 是一种流行的软件开发实践，每次提交都通过自动化的构建（测试、编译、发布）来验证，从而尽早的发现错误。

持续集成实现了DevOps, 使开发人员和运维人员从繁琐的工作中解放出来。另外，这种形式极大地提高了开发者的开发效率和开发质量。
持续集成有多种工具，如Jenkins. GitLab内置了GitLab-CI，通过配置一段YAML脚本来实现持续集成.

功能

持续集成可以实现的功能:

代码审核: 自动化代码规范审查, 甚至代码质量检查
自动化测试: 单元测试, 功能测试和验收测试
编译发布: 将源代码编译成可执行程序, 并将程序上传到托管发布平台实现自动发布
构建部署: 通过构建Docker镜像, 或登录远程服务器执行相关部署命令和脚本, 实现自动化部署

原理

GitLab-CI 检测每次代码变动, 通过.gitlab-ci.yml脚本执行构建命令, 将命令发布到GitLab-Runners(运行机)上, 进而执行命令.

GitLab-Runners 基于Docker执行持续集成的每项任务, 这样就解决了环境依赖问题.

GitLab-Runners把实时将执行结果输出到GitLab网页上, 任务执行完后, 通过徽章标记和邮箱告知执行结果.

下一章: [[GitLab 快速开始]]

GitLab-CI使用Docker进行持续部署

发表于 2017-04-22 | 更新于 2020-06-08 | 阅读次数：

Docker镜像通过私有仓库进行发布(如阿里云), 发布命令为:

1
2
3

docker login -u username -p password registry.demo.com
docker build -t registry.demo.com/repos/$CI_PROJECT_NAME:latest .
docker push registry.demo.com/repos/$CI_PROJECT_NAME:latest

其中 username是用户名, password是密码, registry.demo.com是私有镜像库地址,

$CI_PROJECT_NAME 是GitLab-CI内置变量, 会自动替换为项目的名称, 这里也可以直接写死, 如

docker build -t registry.demo.com/repos/image-name:latest .

image-name, 就是要构建的镜像名称, latest是TAG标签, repos是仓库的空间名称

在下面的例子中, 首先通过composer安装依赖库, 然后通过artifacts传递给构建任务, 构建完镜像将镜像发布到私有库,
部署时通过拉取最新的镜像库, 进行部署

项目的deploy目录中, 放置一些配置文件, 如Dockerfile, docker-compose.yml等, 通过rsync同步到部署服务器上, 用于部署所需

image: zacksleo/docker-composer:1.1

before_script:
    - 'which ssh-agent || ( apk update && apk add openssh-client)'
    - apk add rsync
    - eval $(ssh-agent -s)
    - echo "$SSH_PRIVATE_KEY" > ~/deploy.key
    - chmod 0600 ~/deploy.key
    - ssh-add ~/deploy.key
    - mkdir -p ~/.ssh
    - '[[ -f /.dockerenv ]] && echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config'
    - export APP_ENV=testing

stages:
    - prepare    
    - build
    - deploy

variables:
    COMPOSER_CACHE_DIR: "/cache/composer"
    DOCKER_DRIVER: overlay

installing-dependencies:
    stage: prepare
    script:
        - composer install --prefer-dist -n --no-interaction -v --no-suggest
    artifacts:
        name: "vendor"
        untracked: true
        expire_in: 60 mins
        paths:
            - $CI_PROJECT_DIR/vendor    
test-image:
    stage: build
    image: docker:latest
    services:
        - docker:dind
    dependencies:
        - installing-dependencies
    script:
        - docker login -u username -p password registry.demo.com
        - docker build -t registry.demo.com/repos/$CI_PROJECT_NAME:latest .
        - docker push registry.demo.com/repos/$CI_PROJECT_NAME:latest
testing-server:
    stage: deploy
    image: alpine
    variables:
        DEPLOY_SERVER: "server-host"
    script:
        - cd deploy
        - rsync -rtvhze ssh . root@$DEPLOY_SERVER:/data/$CI_PROJECT_NAME --stats        
        - ssh root@$DEPLOY_SERVER "docker login -u username -p password registry.demo.com"
        - ssh root@$DEPLOY_SERVER "cd /data/$CI_PROJECT_NAME && docker-compose stop && docker-compose rm -f && docker-compose pull && docker-compose up -d"
        - ssh root@$DEPLOY_SERVER "docker exec -i $CI_PROJECT_NAME chown www-data:www-data web/assets"
        - ssh root@$DEPLOY_SERVER "docker exec -i $CI_PROJECT_NAME ./yii migrate/up --interactive=0"

GitLab-CI中的artifacts使用研究

发表于 2017-04-18 | 更新于 2020-06-08 | 阅读次数：

在GitLab-CI中, cache与artifacts比较容易混淆.

其中 cache 指的是缓存, 常用于依赖安装中, 如几个jobs都需要安装相同的依赖, 可以使用依赖, 此时可以加快依赖的安装进度;
对于artifacts则是将某个工件上传到GitLab提供下载或后续操作使用, 由于每个job启动时, 都会自动删除.gitignore中指定的文件, 因此对于依赖安装目录, 即可以使用cache, 也可以使用artifacts.

两个主要有以下几个区别:

cache不一定命中，artifacts肯定命中, 能否使用cache取决当当前机器是否生成过cache, artifacts则每次都会从GitLab下载
重新安装时因为使用的是缓存, 所以很有可能不是最新的
特别是开发环境, 如果每次都希望使用最新的更新, 应当删除cache, 使用artifacts, 这样可以保证确定的更新
4.artifacts中定义的部分, 会自动生成, 并可以传到下面的job中解压使用, 避免了重复依赖安装等工作
如果使用Docker运行Gitlab-Runner, cache会生成一些临时容器, 不容易清理
artifacts可以设置自动过期时间, 过期自动删除，cache不会自动清理
artifacts会先传到GitLab服务器, 然后需要时再重新下载, 所以这部分也可以在GitLab下载和浏览

`artifacts` 的依赖使用

下面是一个使用artifacts的例子, 首先有一个安装依赖的工作, 然后工作完成后, 会将安装文件转移到后续的工作时

installing-dependencies:
    stage: prepare
    script:
        - composer install --prefer-dist --optimize-autoloader -n --no-interaction -v --no-suggest
        - composer dump-autoload --optimize
    artifacts:
        name: "vendor"
        untracked: true
        expire_in: 60 mins
        paths:
            - $CI_PROJECT_DIR/vendor    
code-review:
    stage: testing
    dependencies:
        - installing-dependencies
    script:
        - php vendor/bin/phpcs --config-set ignore_warnings_on_exit 1
        - php vendor/bin/phpcs --standard=PSR2 -w --colors ./
test-image:
    stage: build
    image: docker:latest
    services:
        - docker:dind
    dependencies:
        - installing-dependencies
    script:        
        - docker build -t $CI_PROJECT_NAME:latest .
        - docker push domain.com/repos/$CI_PROJECT_NAME:latest
    only:
        - develop

如果上述过程使用cache, 则会变成下面这样子, 注意, 此时每次都要执行composer install这样的依赖安装工作, 即before_script

cache:
    paths:
        - vendor
before_scritp:    
    - composer install --prefer-dist --optimize-autoloader -n --no-interaction -v --no-suggest
    - composer dump-autoload --optimize    
code-review:
    stage: testing    
    script:
        - php vendor/bin/phpcs --config-set ignore_warnings_on_exit 1
        - php vendor/bin/phpcs --standard=PSR2 -w --colors ./
test-image:
    stage: build
    image: docker:latest
    services:
        - docker:dind    
    script:        
        - docker build -t $CI_PROJECT_NAME:latest .
        - docker push domain.com/repos/$CI_PROJECT_NAME:latest
    only:
        - develop

或

cache:
    paths:
        - vendor
code-review:
    stage: testing    
    script:    
        - composer install --prefer-dist --optimize-autoloader -n --no-interaction -v --no-suggest
        - composer dump-autoload --optimize     
        - php vendor/bin/phpcs --config-set ignore_warnings_on_exit 1
        - php vendor/bin/phpcs --standard=PSR2 -w --colors ./
test-image:
    stage: build
    image: docker:latest
    services:
        - docker:dind    
    script:        
        - composer install --prefer-dist --optimize-autoloader -n --no-interaction -v --no-suggest
        - composer dump-autoload --optimize      
        - docker build -t $CI_PROJECT_NAME:latest .
        - docker push domain.com/repos/$CI_PROJECT_NAME:latest
    only:
        - develop

否则, 会出现类似 vendor not found的问题

禁用artifacts

默认artifacts会自动在不同的stage中传输, 如果该stage中的job不需要artifacts, 则可以禁用artifacts, 以加速构建速度

1	dependencies: []

注意

使用cache会出现一个问题, 就是缓存有可能使用上次执行该job时的缓存, 不能保证某些文件最新

GitLab-CI通过ssh进行自动部署

发表于 2017-04-14 | 更新于 2020-06-08 | 阅读次数：

需求

通过gitlab-ci实现文件的自动部署

实现过程

文档托管在gitlab上, 每次代码更新, 会自动出发gitlab-ci构建
在构建脚本中, 通过ssh 登录远程服务器执行git拉取文档的命令

过程

首先需要在服务器上生成ssh证书

注意该证书的用户必须与ssh远程登录的用户一样, 例如我们的用户名是root

将公钥添加到gitlab上, 以便于该用于可以拉取代码

在 `CI/CD Piplines`中设置 `Secret Variables`, 包括 `DEPLOY_SERVER` 和 `SSH_PRIVATE_KEY`

其中 SSH_PRIVATE_KEY 的内容是服务器上的私钥, DEPLOY_SERVER 是服务器地址

编写 `.gitlab-ci.yml` 文件, 注入密钥, 通过`ssh`执行远程命令

完整代码

# 使用alpine镜像, 该镜像很少,只有几兆
image: alpine
stages:
    - deploy
before_script:
    # 预先装 ssh-agent
    - 'which ssh-agent || ( apk update && apk add openssh-client)'
    # 启动服务
    - eval $(ssh-agent -s)
    # 将私钥写入deploy.key 文件
    - echo "$SSH_PRIVATE_KEY" > deploy.key
    # 配置较低权限
    - chmod 0600 deploy.key
    # 注入密钥
    - ssh-add deploy.key
    - mkdir -p ~/.ssh    
    - '[[ -f /.dockerenv ]] && echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config'
 
release-doc:
    stage: deploy
    script:
        # 连接远程服务器并执行拉取代码的命令
        - ssh root@$DEPLOY_SERVER "cd /path/to/wiki && git pull origin master"
    only:
        - master
    environment:
        name: production
        url: http://$DEPLOY_SERVER

使用Git和Gollum搭建Wiki系统

发表于 2017-03-13 | 更新于 2020-06-08 | 阅读次数：

Gollum是一个开源的Wiki系统, 该系统基于Git, 支持 Markdown, RDoc 等多种排版格式.

下面是在搭建的过程中经常会遇到一些问题

UTF-8 问题

安装 gollum-rugged_adapter
通过参数 --adapter rugged 启动gollum

1
2
3

sudo apt-get install cmake
sudo gem install gollum-rugged_adapter
gollum --adapter rugged

如何设置只读

启动Gollum时, 设置 --no-edit 来禁止编辑

使用 Docker

使用Docker 安装gullum的内容见 gollum

参考文档

Docker Goolum

gollum

发表于 2017-03-11 | 更新于 2020-06-08 | 阅读次数：

incompatible character encodings: UTF-8 and ASCII-8BIT

When use gollum , you may be got this error, below can helps you solves the problem.

install gollum-rugged_adapter
start gullom with --adapter rugged

1
2
3

sudo apt-get install cmake
sudo gem install gollum-rugged_adapter
gollum --adapter rugged

Here is a detailed demo for Dockerfile


FROM ruby
RUN apt-get -y update && apt-get -y install libicu-dev
RUN gem install gollum
RUN gem install github-markdown org-ruby 
# RUN gem install --pre gollum-rugged_adapter
RUN apt-get -y install cmake
RUN gem install gollum-rugged_adapter
VOLUME /docs
WORKDIR /docs
CMD ["gollum", "--port", "80", "--adapter", "rugged"]
#CMD ["gollum", "--port", "80"]

EXPOSE 80

More Infomation

Docker Goolum

OAuth2中的Token

发表于 2017-03-09 | 更新于 2020-06-08 | 阅读次数：

两个不同的Token

OAuth2 中主要有两个不同的Token, 其中的区别为是否与用户相关联, 即与用户相关的用户Token, 和与客户端相关的客户端Token,
可以通过用户Token, 查询到用户的相关信息, 客户端Token与用户无关, 一般只用于客户端认证

用户Token

获取用户Token一般有两个方式, 授权码模式和密码模式

授权码模式

授权码模式通过跳转到授权中心来获取token

跳转到认证服务器
认证服务器需要用户登录
用户选择是否授权
授权同意后, 自动跳转回原来的页面, 客户端拿到授权码
客户端凭借授权码, 在服务器上通过接口向认证服务器申请令牌

密码模式

密码模式通过接口直接申请到Token

该接口需要几个参数, client_id, client_secret, grant_type, username, password

{
    "client_id": "客户端ID",
    "client_secret": "客户端密码",
    "grant_type": "授权模式, 此外为 password",
    "username": "用户名",
    "password": "用户密码"
}

客户端Token

通过客户端ID和客户端密码来获取Token

该Token与客户端相关, 与用于无关, 只用于客户端认证, 避免了接口泄露和滥用

Git工作流程及使用规范

发表于 2017-03-07 | 更新于 2020-06-08 | 阅读次数：

Git工作流程

分支

tags: 用于于生产环境
master: 用于测试环境/预演环境, 一般只接受合并请求, 不直接提交
testing: 用于测试环境测试（可选）
develop: 用于日常开发主线, 其他分支只能合并到 develop 分支（可选）
feature-xxx: 用于增加一个新功能
hotfix-xxx: 用于修复一个紧急bug
refact-xxx: 代码重构
docs-xxx: 文档修改
每次开发新功能，都应该新建一个单独的分支

工作流

贡献代码时,如果项目存在贡献指南，需阅读并遵守贡献指南
Fork对应的项目, 然后基于develop/master分支, 新建一个分支, 在这个分支上进行开发
开发时应遵守相应的编码规范和Git日志规范, 提交日志应当给出完整扼要的提交信息
开发完毕后, 先在本项目库上合并到develop/master分支, 合并完成之后再PR到原项目库

Commit message 和 Change log 编写指南

Git 每次提交代码，都要写 Commit message（提交说明），否则就不允许提交
+Commit message 遵从 Angular 规范

安装 Commitizen 来格式化 commit , 使其遵循以上规范

首先注意将package.json和node_modules加入.gitignore文件
全局安装commitizen: npm install -g commitizen
在项目根目录初始化package.json: npm init --yes
项目根目录运行 commitizen init cz-conventional-changelog --save --save-exact
每次提交代码时, 用 git cz 代替 git commit

参考资料

HTML-CSS编码规范

发表于 2017-03-07 | 更新于 2020-06-08 | 阅读次数：

Google HTML/CSS代码风格指南

遵循 Google HTML/CSS 代码风格指南编码规范

参考资料

http://iischajn.github.io/trans/htmlcss-guide/

zacksleo

Full Stack Web Developer

53 日志

80 标签

GitHub

Hello World !

在仓库根目录创建 .gitlab-ci.yml 文件, 内容如下

这样, 在每次提交代码后, 都会自动执行以上脚本. 其中job-1是任务名称, 可以定义多个任务,

这样, 一次简单的持续集成已经搞定了.

远程拉取代码

使用ssh远程登录服务器, 然后执行git pull 拉取代码, 实现代码热更新

通过Docker镜像实现自动部署

参考资料

概述

功能

原理

相关文档

artifacts 的依赖使用

禁用artifacts

注意

相关文档

需求

实现过程

过程

首先需要在服务器上生成ssh证书

将公钥添加到gitlab上, 以便于该用于可以拉取代码

在 CI/CD Piplines中设置 Secret Variables, 包括 DEPLOY_SERVER 和 SSH_PRIVATE_KEY

编写 .gitlab-ci.yml 文件, 注入密钥, 通过ssh执行远程命令

完整代码

相关文档

UTF-8 问题

如何设置只读

使用 Docker

参考文档

More Infomation

两个不同的Token

用户Token

授权码模式

密码模式

客户端Token

Git工作流程

分支

工作流

Commit message 和 Change log 编写指南

安装 Commitizen 来格式化 commit , 使其遵循以上规范

Tag

参考资料

Google HTML/CSS代码风格指南

参考资料

在仓库根目录创建 `.gitlab-ci.yml` 文件, 内容如下

这样, 在每次提交代码后, 都会自动执行以上脚本. 其中`job-1`是任务名称, 可以定义多个任务,

使用ssh远程登录服务器, 然后执行`git pull` 拉取代码, 实现代码热更新

`artifacts` 的依赖使用

在 `CI/CD Piplines`中设置 `Secret Variables`, 包括 `DEPLOY_SERVER` 和 `SSH_PRIVATE_KEY`

编写 `.gitlab-ci.yml` 文件, 注入密钥, 通过`ssh`执行远程命令