IT码农

gitlab-ci

2017/01/15 gitlab

runner 拉取docker image策略设置

docker exec -it gitlab-runner /bin/bash

vim /etc/gitlab-runner/config.toml
通过设置 pull_policy 参数【never if-not-present always】，决定runner如何拉取docker

never - docker image必须在本地存在，不存在image，则出错
if-not-present - 先检查本地是否存在，不存在则拉取线上image
always - [默认值]不管image是否已经pull过，都会从线上拉取image

[[runners]]
  name = "shared,publishcode"
  url = "http://192.168.110.128:8000/"
  token = "e521e0c3c374ac6edbf5125c189285"
  executor = "docker"
  [runners.docker]
    tls_verify = false
    image = "alpine:latest"
    privileged = false
    disable_cache = false
    volumes = ["/cache"]
    shm_size = 0
    pull_policy = "if-not-present"
  [runners.cache]

https://docs.gitlab.com/runner/executors/docker.html#how-pull-policies-work

services

service必须以link方式连接到image所定义的容器中 service可以指定别名,否则会根据一定规则，按image来命名

The default aliases for the service's hostname are created from its image name following these rules:

Everything after the colon (:) is stripped
Slash (/) is replaced with double underscores (__) and the primary alias is created
Slash (/) is replaced with a single dash (-) and the secondary alias is created (requires GitLab Runner v1.1.0 or higher)

指定别名

services:
- name: mysql:latest
  alias: mysql-1
- name: mysql:latest
  alias: mysql-2

在相应的应用程序代码中指定mysql redis的host为别名host,连接到各service

https://docs.gitlab.com/ce/ci/docker/using_docker_images.html#accessing-the-services

关于image和service一些详细的用法

给每个job定义image 和 service

before_script:
  - bundle install

test:2.1:
  image: ruby:2.1
  services:
  - postgres:9.3
  script:
  - bundle exec rake spec

test:2.2:
  image: ruby:2.2
  services:
  - postgres:9.4
  script:
  - bundle exec rake spec

更详细的用法

image:
  name: ruby:2.2
  entrypoint: ["/bin/bash"]

services:
- name: my-postgres:9.4
  alias: db-postgres
  entrypoint: ["/usr/local/bin/db-postgres"]
  command: ["start"]

before_script:
- bundle install

test:
  script:
  - bundle exec rake spec

Introduced in GitLab and GitLab Runner 9.4. 可以如下使用，以下2种方式等效

1.使用字符串方式指定image Using a string as an option to image and services:

image: "registry.example.com/my/image:latest"

services:
- postgresql:9.4
- redis:latest

2.map映射方式 Using a map as an option to image and services. The use of image:name is required:

image:
  name: "registry.example.com/my/image:latest"

services:
- name: postgresql:9.4
- name: redis:latest

service 启动多个相同的名称的image

services:
- name: mysql:latest
  alias: mysql-1
- name: mysql:latest
  alias: mysql-2

在runner的config.toml配置文件 中配置image和services

[runners.docker]
  image = "ruby:2.1"
  services = ["mysql:latest", "postgres:latest"]

Docker是如何集成工作的在runner运行期间

1.创建services容器:如mysql,redis等
2.创建缓存容器，用来保存在config.toml 和Dockerfile配置文件中定义的volumes 值
3.创建构建容器,并且把各services容器link到构建容器中
4.启动构建容器，并且发送各jobs script到构建容器中
5.Run job script 
6.git 检出代码到相应的目录/builds/group-name/project-name/
7.运行在.gitlab-ci.yml配置文件中定义的各项步骤
8.检查build script的 exit status
9.移除构建容器和所有的service容器

1.Create any service container: mysql, postgresql, mongodb, redis.
2.Create cache container to store all volumes as defined in config.toml and Dockerfile of build image (ruby:2.1 as in above example).
3.Create build container and link any service container to build container.
4.Start build container and send job script to the container.
5.Run job script.
6.Checkout code in: /builds/group-name/project-name/.
7.Run any step defined in .gitlab-ci.yml.
8.Check exit status of build script.
9.Remove build container and all created service containers.

如何在本地调试job

关于stages

stages:
  - build
  - test
  - deploy

1.所有的job的build是并行执行的 
2.如果所有job的build都成功，则所有test job将并行执行
3.如果所有job的test都成功，则所有的deploy job将并行执行
4.如果所有deploy 都成功，则commit将标记为success
5.如果任何一个job失败,则commit标记为failed并且所有jobs停止执行

另外需要注意的2点

1.如果.gitlab-ci.yml没有定义stages，则允许job的stage设置为任意一个值作为默认值：build, test and deploy
2.如果job没有设置stage，则默认设置stage为test

First, all jobs of build are executed in parallel.
If all jobs of build succeed, the test jobs are executed in parallel.
If all jobs of test succeed, the deploy jobs are executed in parallel.
If all jobs of deploy succeed, the commit is marked as success.
If any of the previous jobs fails, the commit is marked as failed and no jobs of further stage are executed.

There are also two edge cases worth mentioning:

If no stages are defined in .gitlab-ci.yml, then the build, test and deploy are allowed to be used as job's stage by default.
If a job doesn't specify a stage, the job is assigned the test stages

ref

https://docs.gitlab.com/ce/ci/yaml/README.html
https://docs.gitlab.com/ce/ci/docker/using_docker_images.html

https://docs.gitlab.com/ce/ci/environments.html#manually-deploying-to-environments
https://docs.gitlab.com/ce/ci/examples/deployment/composer-npm-deploy.html


## review apps
https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/.gitlab-ci.yml#L33-70

Search

    Table of Contents