分类：信息技术

GitLab Runners
GitLab Runners

Original URL: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/ci/runners/README.md

GitLab CI 中，Runners 运行你的 yaml。Runner 是一个独立/隔离的（虚拟）机器，它通过 GitLab CI 的协调器（coordinator） API 拾取作业。

Runner 可以服务特定的项目，或为 GitLab CI 的任何项目提供服务。为所有项目提供服务的 Runner 称为

Shared Runner。

理想情况下，GitLab Runner 不应与 GitLab 安装在相同机器上。阅读需求文档以获取更多信息。

Shared vs. Specific Runners

具体的 Runner 仅针对指定的项目运行。共享的 Runner 可以为启用了

Allow shared Runners 的项目运行作业。

Shared Runners 对多个项目间需求类似的作业很有用。您可以使用一个或多个 Runner 来处理多个项目，而不是让多个 Runner 闲置等待多个项目。这样可以更容易维护和更新 Runner。

Specific Runners 对于要求特殊的作业，或有特定需求的项目很有用。如果一个作业有一定的要求，你可以设置一个 Specific Runner 来搞，而不必为所有 Runner 这样做。例如，如果要部署某个项目，可以设置 Specific Runner 以获取正确的凭据。

CI 活动频繁旺盛的项目也可以从使用 Specific Runner 中受益。通过 Specific Runners 可确保 Runner 不被其他项目的作业阻塞。

您可以设置 Specific Runner 供多个项目使用。与 Shared Runner 的区别在于，必须为 Runner 显式地启用上述每个项目，才能运行这些项目的作业。

Specific Runner 不会自动与 fork 出去的项目共享。fork 将复制所克隆的代码仓库 CI 设置（

jobs、allow shared 等）。

创建并注册 Runner

有几种方法可以创建 Runner。只有创建后，注册才能确定其为

Shared或Specific状态。

安装 Runner 实例的不同方法，请参阅文档。

安装 Runner 后，可将其注册为

Shared或Specific。如果您有 GitLab 实例的管理员访问权限，则只能注册一个Shared Runner。

注册Shared Runner

如果您是链接的 GitLab 实例上的管理员，则只能注册一个

Shared Runner。（You can only register a shared Runner if you are an admin on the linked GitLab instance.）

在 GitLab CI 实例的

admin/runners页面上获取shared-Runner令牌。

现在只需注册 Runner 即可：
```
sudo gitlab-ci-multi-runner register
```
从 GitLab 8.2 起，Shared Runners 默认启用，但可以使用

DISABLE SHARED RUNNERS按钮禁用。以前版本的 GitLab 中，Shared Runners 默认为禁用。

注册Specific Runner

Registering a specific can be done in two ways:
1. Creating a Runner with the project registration token
2. Converting a shared Runner into a specific Runner (one-way, admin only)
There are several ways to create a Runner instance. The steps below only concern registering the Runner on GitLab CI.

Registering a Specific Runner with a Project Registration token

To create a specific Runner without having admin rights to the GitLab instance, visit the project you want to make the Runner work for in GitLab CI.

Click on the Runner tab and use the registration token you find there to setup a specific Runner for this project.

To register the Runner, run the command below and follow instructions:
```
sudo gitlab-ci-multi-runner register
```
Lock a specific Runner from being enabled for other projects

You can configure a Runner to assign it exclusively to a project. When a Runner is locked this way, it can no longer be enabled for other projects. This setting is available on each Runner in

Project Settings > Runners.

Making an existing Shared Runner Specific

If you are an admin on your GitLab instance, you can make any shared Runner a specific Runner,

but you can not make a specific Runner a shared Runner.

To make a shared Runner specific, go to the Runner page (

/admin/runners) and find your Runner. Add any projects on the left to make this Runner run exclusively for these projects, therefore making it a specific Runner.

Using Shared Runners Effectively

If you are planning to use shared Runners, there are several things you should keep in mind.

Use Tags

You must setup a Runner to be able to run all the different types of jobs that it may encounter on the projects it’s shared over. This would be problematic for large amounts of projects, if it wasn’t for tags.

By tagging a Runner for the types of jobs it can handle, you can make sure shared Runners will only run the jobs they are equipped to run.

For instance, at GitLab we have Runners tagged with “rails” if they contain the appropriate dependencies to run Rails test suites.

Prevent Runner with tags from picking jobs without tags

You can configure a Runner to prevent it from picking jobs with tags when the Runner does not have tags assigned. This setting is available on each Runner in

Project Settings > Runners.

Be careful with sensitive information

If you can run a job on a Runner, you can get access to any code it runs and get the token of the Runner. With shared Runners, this means that anyone that runs jobs on the Runner, can access anyone else’s code that runs on the Runner.

In addition, because you can get access to the Runner token, it is possible to create a clone of a Runner and submit false jobs, for example.

The above is easily avoided by restricting the usage of shared Runners on large public GitLab instances and controlling access to your GitLab instance.

Forks

Whenever a project is forked, it copies the settings of the jobs that relate to it. This means that if you have shared Runners setup for a project and someone forks that project, the shared Runners will also serve jobs of this project.

Attack vectors in Runners

Mentioned briefly earlier, but the following things of Runners can be exploited. We’re always looking for contributions that can mitigate these Security Considerations.
2017-05-26
在容器内运行 GitLab Runner
这描述如何在 Docker 容器中运行 GitLab Runner。

Docker 镜像安装及配置

首先安装 Docker：
```
curl -sSL https://get.docker.com/ | sh
```
需要在

gitlab-runner容器中装载一个用于配置和其他资源的配置存储卷，：
```
docker run -d --name gitlab-runner --restart always \
  -v /srv/gitlab-runner/config:/etc/gitlab-runner \
  -v /var/run/docker.sock:/var/run/docker.sock \
  gitlab/gitlab-runner:latest
```
或者，你可以使用配置容器来装载自定义数据卷：
```
docker run -d --name gitlab-runner-config \
    -v /etc/gitlab-runner \
    busybox:latest \
    /bin/true

docker run -d --name gitlab-runner --restart always \
    --volumes-from gitlab-runner-config \
    gitlab/gitlab-runner:latest
```
如果打算使用 Docker 作为产生 Runners 的方法，则要这样装载 docker socket：
```
docker run -d --name gitlab-runner --restart always \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v /srv/gitlab-runner/config:/etc/gitlab-runner \
  gitlab/gitlab-runner:latest
```
注册 runner （查看 Runner 文档了解如何获取令牌）:
```
docker exec -it gitlab-runner gitlab-runner register

Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com )
https://gitlab.com
Please enter the gitlab-ci token for this runner
xxx
Please enter the gitlab-ci description for this runner
my-runner
INFO[0034] fcf5c619 Registering runner... succeeded
Please enter the executor: shell, docker, docker-ssh, ssh?
docker
Please enter the Docker image (eg. ruby:2.1):
ruby:2.1
INFO[0037] Runner registered successfully. Feel free to start it, but if it's
running already the config should be automatically reloaded!
```
Runner 应该已经启动了，已准备好构建项目！

请确保阅读了有关 GitLab Runner 最常见问题的 FAQ。

更新

拉取最新的（latest）版本：
```
docker pull gitlab/gitlab-runner:latest
```
停止并删除现有容器：
```
docker stop gitlab-runner && docker rm gitlab-runner
```
像原来一样启动容器：
```
docker run -d --name gitlab-runner --restart always \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v /srv/gitlab-runner/config:/etc/gitlab-runner \
  gitlab/gitlab-runner:latest
```
注意：您需要使用与原来装载数据卷相同的方法（-v /srv/gitlab-runner/config:/etc/gitlab-runner 或 --volumes-from gitlab-runner）

安装受信的 SSL 服务器证书

如果你的 GitLab CI 服务器在使用自签名 SSL 证书，那应确保 GitLab CI 服务器证书被 gitlab-ci-multi-runner 容器信任，以便它们能够相互通信。

The

gitlab/gitlab-runner image is configured to look for the trusted SSL certificates at /etc/gitlab-runner/certs/ca.crt, this can however be changed using the -e "CA_CERTIFICATES_PATH=/DIR/CERT" configuration option.

Copy the

ca.crt file into the certs directory on the data volume (or container). The

ca.crt file should contain the root certificates of all the servers you want gitlab-ci-multi-runner to trust. The gitlab-ci-multi-runner container will import the ca.crt file on startup so if your container is already running you may need to restart it for the changes to take effect.

gitlab/gitlab-runner镜像被配置为在/etc/gitlab-runner/certs/ca.crt上查找受信的 SSL 证书，但可以使用-e "CA_CERTIFICATES_PATH=/DIR/CERT"来配置。

将

ca.crt文件复制到数据卷（或容器）上的certs目录中。 ca.crt文件应包含所有需要 gitlab-ci-multi-runner 信任的服务器根证书。启动时，gitlab-ci-multi-runner 容器将导入ca.crt文件，因此如果你的容器已经运行，则需重启生效。

Alpine Linux

你还可以使用替代的基于 Alpine Linux 的镜像，文件体积更小：
```
gitlab/gitlab-runner    latest              3e8077e209f5        13 hours ago        304.3 MB
gitlab/gitlab-runner    alpine              7c431ac8f30f        13 hours ago        25.98 MB
```
Alpine Linux image is designed to use only Docker as the method of spawning runners.

原本的

gitlab/gitlab-runner:latest 基于 Ubuntu 14.04 LTS。

SELinux

某些发行版（CentOS，RedHat，Fedora）默认使用 SELinux 来增强底层系统的安全性。

处理这种配置时必须特别小心。
1. If you want to use Docker executor to run builds in containers you need to access the /var/run/docker.sock. However, if you have a SELinux in enforcing mode, you will see the Permission denied when accessing the /var/run/docker.sock. Install the selinux-dockersock and to resolve the issue: https://github.com/dpw/selinux-dockersock.
2. Make sure that persistent directory is created on host: mkdir -p /srv/gitlab-runner/config.
3. Run docker with :Z on volumes:
```
docker run -d --name gitlab-runner --restart always \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v /srv/gitlab-runner/config:/etc/gitlab-runner:Z \
  gitlab/gitlab-runner:latest
```
More information about the cause and resolution can be found here: http://www.projectatomic.io/blog/2015/06/using-volumes-with-docker-can-cause-problems-with-selinux/
2017-05-26
GitLab Runner Docker Executor
GitLab Runner

执行器（Executor ）的比较

Shell 是最易于配置的执行器。构建中所需的依赖得你手工装在 Runner 所在机器上。

更好的方式是使用 Docker，它让你拥有干净的构建环境，以及简易的依赖管理——所有的编译项目所需的依赖都可以放进 Docker 镜像中。Docker 执行器很容易就能创建带有依赖服务的编译环境，比如 MySQL。

通常不建议使用 Docker-SSH，这是 Docker 执行器的特殊版本。该执行器可以连接到 Docker 容器，其中运行 SSH 守护进程。如果你的 Docker 镜像要复制一个完整的工作系统，这会很有用：使用进程管理系统（init），暴露 SSH 进程，并含有系列安装好的服务。这类镜像是肥镜像，Docker 社区通常也不建议使用。

以下原文：https://docs.gitlab.com/runner/executors/docker.html

Docker 执行器

GitLab Runner 能在用户提供的镜像上，使用 Docker 来执行编译。这通过

Docker 执行器完成。

Docker 执行器与 GitLab CI 一起使用时，它连到 Docker Engine，并在独立且隔离的容器中运行每个构建。它会使用在 .gitlab-ci.yml中预设好的镜像，并按照 config.toml 所定来执行。

这样可以拥有一个简单可重复的构建环境，这也可以在你的工作站上运行。附加的好处是可以测试我们将在以后从 Shell 中探索的所有命令，而不必在专用的 CI 服务器上进行测试。

工作流程

Docker 执行器将构建分为多个步骤：
1. Prepare：创建并启动服务。
2. Pre-build：克隆，恢复 Cache 并从以前的阶段下载工件（Artifacts）。这是在特殊的 Docker 镜像上运行的。
3. Build：用户构建。这是在用户提供的 Docker 镜像上运行的。
4. Post-build：创建缓存，将工件上传到 GitLab。这是在特殊的 Docker 镜像上运行的。
此特殊的 Docker 镜像基于 Alpine Linux，并包含运行 prepare 步骤所需的所有工具：Git 二进制文件和用于支持 Cache 和工件（Artifacts）的 Runner 二进制文件。您可以在官方的 Runner 仓库中找到此特殊镜像的定义。

image 关键字

image 关键字是本地 Docker Engine 中存在的 Docker 镜像的名称（docker image 可列出所有docker 镜像），或是可在 Docker Hub 中找到的任何镜像。有关镜像和 Docker Hub 的更多信息，请阅读 Docker Fundamentals文档。

简言之，使用

image引用 docker 镜像来创建容器，构建将在此容器上运行。

如果不指定命名空间，Docker 默认命名空间为包含所有官方镜像的library。这就是为什么你会看到很多次.gitlab-ci.yml和config.toml中省略的library部分。例如，可以定义像image: ruby:2.1这样的镜像，它是image: library/ruby:2.1的快捷方式。

然后，每个 Docker 镜像都有标签（tag），表示镜像版本。这些在镜像名称后面用冒号（

:）定义。例如，对于Ruby，可以在 https://hub.docker.com/_/ruby/ 上看到支持的标签。如果没有指定标签（如image:ruby），则表示latest。

services 关键词

services关键字定义了在构建期间运行的另一个 Docker 镜像，并链接到image关键字所定义的 Docker 镜像。这允许你在构建时访问服务镜像。

服务镜像可以运行任何应用程序，但最常见的使用场景是运行数据库容器，例如

mysql。用已有的镜像来运行额外容器会更加容易快速，而不是每次构建项目时都安装mysql。

你可以在 CI 服务示例的相关文档中看到一些广泛使用的服务示例。

服务如何链接到构建

要更好地了解容器链接的工作原理，请阅读 Linking containers together。

总而言之，如果你将

mysql作为服务添加到应用程序中，则该镜像将用于创建一个链接到构建容器的容器。根据工作流程，这是运行实际构建之前执行的第一步。

MySQL 的服务容器可使用主机名

mysql访问。因此，为了访问你的数据库服务，您必须连接到名为mysql的主机而不是套接字（socket）或localhost。

从.gitlab-ci.yml定义image和services

你可以简单地定义将用于所有作业的镜像，和要在构建时使用的服务列表。
```
image: ruby:2.2

services:
  - postgres:9.3

before_script:
  - bundle install

test:
  script:
  - bundle exec rake spec
```
也可以为每个作业定义不同的镜像和服务：
```
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
```
Define image and services in config.toml

查找

[runners.docker]部分：
```
[runners.docker]
  image = "ruby:2.1"
  services = ["mysql:latest", "postgres:latest"]
```
这里定义的镜像和服务将添加到 Runner 运行的所有构建中，因此即使在

.gitlab-ci.yml内没有定义image，config.toml中定义的将被使用。

从私有 Docker Registry 中定义镜像

从 GitLab Runner 0.6.0 开始，你可以定义位于私有 Registry 的镜像，这可能需要身份验证。

在

.gitlab-ci.yml的镜像定义中显式声明即可。
```
image: my.registry.tld:5000/namepace/image:tag
```
上例中，GitLab Runner 到

my.registry.tld:5000寻找namespace/image:tag镜像。

如果存储库是私有的，则需要提供 GitLab Runner 的身份验证凭据。更多内容参见：使用私有 Docker Registry。

访问服务

假设需要一个 WordPress 实例，来测试它和你应用的 API 集成。

你可以在

.gitlab-ci.yml中使用如tutum/wordpress作为服务镜像：
```
services:
  - tutum/wordpress:latest
```
当构建运行时，

tutum/wordpress将首先启动，你可以用主机名为tutum__wordpress和tutum-wordpress的构建容器来访问它。

GitLab Runner 为你可以使用的服务创建两个主机名别名。别名取自镜像名称，遵循以下规则：

  1.

:后的一切都被舍弃   2. 第一个别名，斜杠（

/）替换为双下划线（__）   3. 第二个别名，斜杠（

/）替换为单破折号（-）

使用私有镜像服务将剥离给出的任何端口，并应用上述规则。服务

registry.gitlab-wp.com:4999/tutum/wordpress将生成主机名registry.gitlabwp.comtutum__wordpress和registry.gitlab-wp.com-tutum-wordpress。

配置服务

许多服务接受环境变量，允许你根据环境来轻松更改数据库名或设置帐户名。

GitLab Runner 0.5.0 及以上版本将所有 YAML 定义的变量传递给创建的服务容器。

对于所有可能的配置变量，请检查其对应Docker集线器页面中提供的每个映像的文档。

注：所有变量将被传递到所有服务容器。没有某服务专用的变量。安全变量（Secure Variables）只传递给构建容器。

服务中的构建目录

从 1.5 版本开始，GitLab Runner 将一个

/build目录装载到所有的共享服务中。

参见这个 issue：https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues/1520

PostgreSQL 服务示例

请参阅具体文档使用 PostgreSQL 作为服务。

MySQL 服务示例

请参阅具体文档使用 MySQL 作为服务。

服务健康检查

服务启动后，GitLab Runner 等待一段时间的服务响应。当前，Docker 执行程序会尝试打开与服务容器中第一个暴露服务的 TCP 连接。

你可以看到它在这个 Dockerfile 中是如何实现的。

构建和缓存存储

Docker 执行器默认将所有构建存储在

/builds//中，所有缓存在/cache（在容器内）中。

您可以在

config.toml文件的[[runners]]部分下，定义builds_dir和cache_dir选项，来覆盖/builds和/cache目录。这将修改数据存储在容器内的位置。

如果你修改

/cache存储路径，你还需要更改config.toml中[runners.docker]部分的volumes = ["/my/cache/"]，确保把上述目录标记为 persistent。

要了解更多信息，请阅读下一部分持久存储。

持久存储

Docker执行器可以在运行容器时提供持久存储。在

volumes =下定义的所有目录将在构建之间持久化。

volumes指令支持2种类型的存储：
1. – 动态存储。在该项目的同一并发作业的后续运行中持续存在。数据附加到自定义缓存容器：runner--project--concurrent--cache-。
2. : [: ] – 主机绑定存储。绑定到主机系统上的。可选的可以指定该存储是只读或读写（默认）。
构建的持久存储

如果你将

/builds作为主机绑定的存储，你的构建将被存储在：/builds////，其中：
- 是 Runner Token 的缩写版（前 8 个字母）
- 是个唯一数字，用于标识项目上下文中特定 Runner 的本地作业 ID
特权（privileged）模式

Docker 执行器支持许多选项来微调构建容器。其中之一是privileged模式。

使用具有特权模式的 docker-in-docker

配置的

privileged标志被传递给构建容器和所有服务，从而允许轻松使用 docker-in-docker 方法。

首先，将您的 Runner（

config.toml）配置为以privileged模式运行：
```
[[runners]]
  executor = "docker"
  [runners.docker]
    privileged = true
```
然后，使你的构建脚本（

.gitlab-ci.yml）使用 docker-in-docker 容器：
```
image: docker:git
services:
  - docker:dind

build:
  script:
    - docker build -t my-image .
    - docker push my-image
```
ENTRYPOINT

Docker 执行器不会覆盖 Docker 镜像的ENTRYPOINT。

这意味着，如果你的镜像定义了

ENTRYPOINT，并且不允许使用CMD来运行脚本，那么该镜像将不能与 Docker 执行器一起使用。

使用

ENTRYPOINT可以创建在自定义环境或安全模式下运行构建脚本的特殊 Docker 镜像。

您可能会想到创建一个使用不执行构建脚本的

ENTRYPOINT的 Docker 镜像，但执行一组预定义的命令，例如从你的目录里构建 Docker 镜像。在这种情况下，您可以以特权模式运行构建容器，并使 Runner 的构建环境安全。

请考虑以下例子：
1. 创建一个新的 Dockerfile：
```
FROM docker:dind
ADD / /entrypoint.sh
ENTRYPOINT ["/bin/sh", "/entrypoint.sh"]
```
2. 创建一个用作ENTRYPOINT的 bash 脚本（entrypoint.sh）：
```
#!/bin/sh

dind docker daemon
    --host=unix:///var/run/docker.sock \
    --host=tcp://0.0.0.0:2375 \
    --storage-driver=vf &

docker build -t "$BUILD_IMAGE" .
docker push "$BUILD_IMAGE"
```
3. 推送镜像到 Docker Registry。
4. 在 privileged模式下运行 Docker 执行器。在config.toml中定义：
```
[[runners]]
  executor = "docker"
  [runners.docker]
    privileged = true
```
5. 在你的项目中使用以下.gitlab-ci.yml：
```
variables:
  BUILD_IMAGE: my.image
build:
  image: my/docker-build:image
  script:
  - Dummy Script
```
这只是一个例子。通过这种方法，是有无限可能的。

镜像拉取策略如何工作

当使用

docker、docker-ssh、docker+machine或docker-ssh+machine执行器时，可以设置pull_policy参数来定义 Runner 在拉取 Docker 镜像时的工作方式（image和services关键字）。

注：如果没有为 pull_policy参数设置任何值，则 Runner 将默认使用always拉取策略。

现在看看这些策略如何工作。

使用拉取策略never

never策略完全禁止镜像拉取。如果 Runner 的pull_policy参数设为never，那用户只能使用 Runner 运行的 docker 主机上已经手工拉取的镜像。

如果在本地找不到指定的镜像，则 Runner 将会使构建失败，错误类似于：
```
Pulling docker image local_image:latest ...
ERROR: Build failed: Error: image local_image:latest not found
```
何时使用此拉取策略？

如果您希望或需要完全控制 Runner 用户使用哪些镜像，则应使用此拉取策略。对于专用于只能使用特定镜像（在任何 registry 上都不公开）的项目的私有 Runner 来说，这是一个不错的选择。

何时不使用此拉取策略？

大部分 auto-scaled 的 Docker 执行器使用场景下，该拉取策略无法正常工作。由于自动伸缩的工作原理，只有在为特定云服务提供商使用预定义的云实例镜像时，never拉取策略才可用。镜像需要包含预装的 Docker Engine 和已使用镜像的本地副本。

使用拉取策略if-not-present

使用

if-not-present拉取策略时，Runner 首先检查本地是否有该镜像。如果有则使用本地版本的镜像。否则 Runner 将尝试拉取镜像。

何时使用此拉取策略？

如果想使用远程 Registry 拉取的镜像，但当使用重型和很少更新的镜像时，又希望减少分析镜像层差异费时，这种拉取策略是一个不错的选择。在这种情况下，您需要一段时间才能从本地 Docker Engine 存储区手动删除镜像以强制更新镜像。

如果您需要只在本地构建和本地可用的镜像，那么这也是一个不错的选择，但另一方面，还需要允许从远程 Registry 中拉取镜像。

何时不使用此拉取策略？

如果你的构建使用经常更新并需要在最新版本中使用的镜像，则不应使用此拉取策略。在此情况下，策略所减少的网络负载，与非常频繁地删除本地镜像副本的必要性相比，可能不太值得。（In such situation, the network load reduction created by this policy may be less worthy than the necessity of the very frequent deletion of local copies of images.）

如果 Runner 可以被不同用户使用，而这些用户又不能访问彼此使用的私有镜像，那么此拉取策略也不应该被使用。特别不要为共享 Runner 使用这个拉取策略。

要了解为什么

if-not-present拉取策略在与私有镜像一起使用时会产生安全问题，请阅读安全注意事项文档。

使用拉取策略always

always拉取策略确保镜像始终被拉取。当使用always时，即使本地副本可用，Runner 也会尝试拉取镜像。如果未找到镜像，则构建将失败，并显示类似以下错误：
```
Pulling docker image registry.tld/my/image:latest ...
ERROR: Build failed: Error: image registry.tld/my/image:latest not found
```
注：对于 v1.8之前的版本，当使用always拉取策略时，可能会返回（fall back）到镜像的本地副本并警告：
```
Pulling docker image registry.tld/my/image:latest ...
WARNING: Cannot pull the latest version of image registry.tld/my/image:latest : Error: image registry.tld/my/image:latest not found
WARNING: Locally found image will be used instead.
```
这在 v1.8版本中已更改。To understand why we changed this and how incorrect usage of may be revealed please look into issue #1905。
何时使用此拉取策略？

如果您的 Runner 公开可用，并将其配置为 GitLab 实例中的共享 Runner，则应使用此拉策略。当 Runner 将与私有镜像一起使用时，它是唯一可以被视为安全的拉取策略。

如果要强制用户始终使用最新的镜像，这也是一个不错的选择。

此外，这将是 Runner 自动伸缩（auto-scaled）配置的最佳解决方案。

何时不使用此拉取策略？

如果你需要使用本地存储的镜像，则此拉取策略将无法正常工作。在这种情况下，Runner 将跳过镜像的本地副本，并尝试将其从远程 Registry 中拉出。如果镜像是本地构建的，并且不存在于任何公共 Registry 中（尤其是在默认的 Docker Registry 中），则构建将会失败：
```
Pulling docker image local_image:latest ...
ERROR: Build failed: Error: image local_image:latest not found
```
Docker vs Docker-SSH

注意： docker-ssh 执行器已被弃用，并且不会添加任何新功能。

我们提供一种特殊类型的 Docker 执行器的支持，即 Docker-SSH。Docker-SSH 使用与 Docker 执行器相同的逻辑，但不是直接执行脚本，它使用 SSH 客户端连接到构建容器。

然后，Docker-ssh 使用其内部 IP 连接到容器内部运行的 SSH 服务器。
2017-05-26
GitLab Flow 的 11 条规则

使用 Git 进行版本管理，是对 Git 出现前所有方法的改进。然而，很多组织最终会出现凌乱的工作流程，或过于复杂的流程。这种问题对从其他版本控制系统转过来的组织来说尤为突出。

本文为 GitLab 工作流程制定了11条规则，以帮助简化和清晰该流程。规则的主要好处（或说希望的好处）是它简化过程，并产生更加有效和更清晰的结果。

改善空间永存，一切皆为草稿。一如既往，

人人皆可贡献！欢迎反馈！

1. 使用功能分支，不直接提交（commit）到 master 分支

如果从 SVN 转过来，举例来说，你会习惯基于主干（trunk）的工作流。而使用 Git 时，任何正进行的操作，都应为之创建一个分支（branch），以便在最终合并（merge）之前进行代码审查（code review）。

2. 测试所有提交，而不仅只在 master 分支上

有些人将 CI 系统设置为只测试合并到

master 分支的东西。这太迟了！总是拥有绿色的 master 测试（译者注：绿色在 CI 里通常意味着测试通过，而红色意味着测试失败），人们会觉得有信心。例如，在开始开发新功能之前，人们不得不测试 master 分支那是没有意义和荒谬的。CI 并不昂贵，所以这样做是最好的。

3. 在所有的提交上，运行所有的测试（如果你的测试时间长于 5 分钟则使其并行）

如果功能分支有新的提交（commit），请随之运行测试。如果测试需要很长时间，请尝试并行运行。合并请求（merge requests）时，在服务器端来执行此操作以运行完整的测试套件。如果有一个用于开发的测试套件，而另一个测试套件只是为新版本运行，那么设置并行测试并运行全部测试套件是值得的。

4. 在合并到 master 之前执行代码审查，而不是事后审查

不要在一周结束时测试，应该当场就搞！这样更有可能抓住可能导致问题的东西，而其他人也会努力提出解决方案。

5. 部署是自动的，并基于分支或标签（tag）。

如果不想每次都部署

master 分支，那可以创建一个 production 分支；但没理由用脚本（script）或登录到某个地方去手动操作。请自动化一切，或用特定的分支来触发生产部署。

6. 由用户创建标签（tag），而不应由 CI 创建

由用户来打

标签（tag），并基于此，CI 将执行一个动作。不应让 CI 去更改代码库。如需非常详细的指标，那应该有一个服务器报告来详细说明新版本。

7. 发布（release）是基于标签（tag）的

如果打了 tag，则意味着创建了一个新版本。

8. 永不对已推送的提交（pushed commits）进行变基（rebase）

当推送（push）到公共分支后，就不该对其变基，因为这样会很难跟进你正在改进的内容，很难跟进测试结果，而且这样打破了 cherry-picking。有时我们在审查流程的后期要求代码贡献者合并及变基（

git merge --squash），以使一些东西容易还原时，我们也会违背这一规则。但一般而言，准则是：代码应干净，修改历史应真实。

9. 每个人都从 master 分支开始工作，目标也是 master 分支

这意味着没有任何长期分支。你可以检出

master 分支，构建功能，创建合并请求，并再次指向到 master 分支。在合并之前要做完整的代码审查，不应在代码审查和合并间搞任何的中间阶段。

10. 在 master 分支中修正错误，其次再到发布分支

如果发现了 bug，最

糟糕的事莫过于在刚发布的版本里修复了它，但却没在 master 里修复。为避免这种情况，应总是向前修复（fix forward）。在 master 中修复，然后 cherry-pick 到其他补丁发布分支（比如 production 分支）。

11. 提交信息（commit message）应体现意图

不仅要说清楚做了什么，还要说明为什么这么做。如果解释一下为什么用这种方式，而不是其他方式，则会更加有用。

更多内容请移步 GitLab Flow 文档。

原文：https://about.gitlab.com/2016/07/27/the-11-rules-of-gitlab-flow/

2017-05-19
run xware on 64bit Ubuntu system
```
file portal
```
portal: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.36, not stripped

Install some i386 libaries on 64bit system.
```
apt-get install libc6:i386 libncurses5:i386 libstdc++6:i386 zlib1g:i386
```
2015-05-03
[已过时] 部署 Docker Registry 服务
```
本文所述已经过时，已无参考价值。
```
本文阐释了怎样部署私有的 Docker Registry 服务 —— 或为公司私用，或公开给其他用户使用。例如，你公司可能需要私人的 Registry 来支持持续集成（CI）。又或，你的公司可能有大量镜像方式的产品或服务，你想以公司品牌的方式来整体提供和呈现。

（更多…）
2015-04-17
在 VMware ESXi 中安装 OmniOS
〇、获取安装文件

第〇步，当然是搞一个安装文件回来

到 http://omnios.omniti.com/wiki.php/Installation ，弄一个当前稳定版或者 LTS 版本。

截至发稿，当前 LTS/Stable 版本为 r151014，相应的 ISO 文件链接为： http://omnios.omniti.com/media/OmniOS_Text_r151014.iso

记得校验一下：

md5 (OmniOS_Text_r151014.iso) = 796fbfe1305f0e4922e9cf627d3e67c2 sha1 (OmniOS_Text_r151014.iso) = ff91fbfa2b01ca9ac61d5812570109c640c1ddd1

下载回来之后，用 ssh/scp 或者 vSphere Client 等将光盘镜像文件上传到 ESXi 的 datastore 中。

一、创建 ESXi 虚拟机

以下以 ESXi 5.5 为例。

选择自定义创建。

OS 类型选择

Oracle Solaris 10 (64-bit)：

网卡类型选择

VMXNET3：

SCSI 控制器选择

LSI Logic Parallel：

新建磁盘。如果只需要 OmniOS，那么新建一个 5GB 的磁盘就够了。OmniOS 官方建议 4.1 GB，最小 2.1 GB。为了升级及临时文件等需要，还是适当放宽一些。如果后续需要安装 Napp-it 作为上层的存储应用系统，那么建议的磁盘大小是 25GB。

在启动前，对虚拟机配置最后做一下编辑。首先是挂载 OmniOS 系统安装光盘镜像，并选择

Connect at power on：

虚拟机的创建即告完成。

二、安装 OmniOS

乏善可陈，基本上 F2（下一步）、F2、F2 … 就完成了。好吧，我们的重点在于后续的 VMXNet3 万兆网卡的配置。

OmniOS 安装完成后，root 密码默认为空，需要你设置密码，及创建新普通用户用于 SSH 登录，或者修改 SSHd 配置文件允许 root 登录之类 balabala….

三、安装 VMware Tools 及 VMXNet3 网卡

OmniOS 没有自带 VMXNet3 网卡驱动，因此到了当前这步时，咱们是没有网络可用的，需要安装相关驱动。

首先，断开安装 OS 时为虚拟机挂接上的光驱设备。

VM -> Edit Settings

取消光驱设备的

Connected 及 Connect at power on 选项。如果提示锁定之类的，直接点选 Yes 强制解除锁定即可。

随后在控制台用以下命令开启 OmniOS 的即插即用服务。
```
svcadm enable hotplug
```
VM -> Guest -> Install/Upgrade VMware Tools

安装 VMware Tools 这个过程，VMware 是以向虚拟机挂载软件光盘，并尝试自动启动安装进程来进行的，遗憾的是，Solaris 类型的客户机并不能自动挂载光驱，还得手动操作一下。

先找出光驱设备名
```
ls –l /dev/dsk | grep ide | grep c\*s2
```
上图中的设备节点 c1t0d0s2，就是我们要找的东西，下面的命令则需要根据你的实际情况来调整。挂载光驱设备：
```
mount –F hsfs –o ro /dev/dsk/c1t0d0s2 /media
```
解压展开 VMware Tools 安装文件：
```
cd /tmp
tar zxvf /media/vmware-solaris-tools.tar.gz
cd vmware-tools-distrib
./vmware-install.pl
```
提示的所有问题，都用默认值回答，也就是一路狂按 Enter 键。

VMware Tools 安装完成之后，网卡驱动也随之就绪，我们可以开始配置网卡了。
```
dladm show-link
```
网卡设备 vmxnet3s0 state unknow，为不可用状态。我们为其添加 IP interface
```
ipadm create-if vmxnet3s0
```
接下来为该 Interface 添加 IP 地址等参数：
```
ipadm create-addr –T static –a /24 vmxnet3s0/v4
```
这时，你再使用 dladm show-link 及 dladm show-phys，应该会得到以下输出：

设置默认网关路由：
```
route –p add default 
```
指定 DNS 解析服务器并激活：
```
echo 'nameserver ' >> /etc/resolv.conf
cp /etc/nsswitch.dns /etc/nsswitch.conf
```
大功告成，OmniOS 安装告一段落。

对了，建议参照 OmniOS Shell Env Check List 所述，对 OS 环境进行设置以改善操作体验。
2015-04-09
VMware 下 CoreOS OVA 镜像的安装与配置
此文提供了在 VMware ESXi/Workstation/Fusion 上安装 CoreOS ova 镜像及其基本配置的有关信息，并以 CoreOS release 557 为例。

CoreOS 是一个新的 Linux 分发版本，它设计用来为集群部署提供基础架构。

本文包含以下主题：
- 安装介绍
- 集成 Open VM Tools
安装介绍

从版本 540.0.0 开始，CoreOS 引入了对虚拟机 OVA 格式的支持。作为推荐的方式，以下安装指引也只面向 OVA 镜像。

前置需求

检验是否完成以下步骤：
- Read General Installation Instructions for All VMware Products.
- Read General Knowledge for CoreOS at https://coreos.com/docs/quickstart/.
注：
- 浏览 http://stable.release.core-os.net/amd64-usr/ 以获取最新稳定版本的 OVA 镜像。当前，你可以找到的镜像文件是 coreos_production_vmware_ova.ova。
- 浏览至 http://stable.release.core-os.net/amd64-usr/557.2.0/ ，下载 coreos_production_vmware_ova.ova 文件。
安装步骤

1、将文件 coreos_production_vmware_ova.ova 上传到 Workstation/Fusion/ESXi 的 Datastore。

2、部署 CoreOS 虚拟机到 VMware。

在 VMware Workstation 或 Fusion 上部署 CoreOS 虚拟机：

1、打开文件 coreos_production_vmware_ova.ova 所处位置，并用 VMware Workstation 或 Fusion 打开。 2、编辑其名称及存储路径，然后点击导入/Import 按钮。 3、当遇到以下警告信息时，点击重试/Retry 按钮。

在 VMware vSphere 上部署 CoreOS 虚拟机：

1、打开 vShere C# 客户端，或使用任何能连接到 vCenter Server 的 vSphere C# Client 或 vSphere Web Client，并连接至你的 ESXi 实例。 2、浏览至文件/File -> 部署 OVF 模板/Deploy OVF Template，并点击浏览并定位到 coreos_production_vmware_ova.ova 所处的路径。 3、继续余下的步骤以完成虚拟机创建。

3、CoreOS 虚拟机的自动登录。

执行以下步骤以访问 CoreOS 虚拟机：

1、打开 CoreOS 虚拟机电源，并打开控制台。 2、当 Boot Loader 提示出现的时候，按下 e 键来编辑 GRUB 菜单。 3、添加 coreos.autologin 作为启动参数，并 Ctrl-x 或 F10 重启。这将使控制台跳过登录提示并直接进入用户 core 的 shell。 4、给用户 core 设置密码用以 SSH 访问。

4、Cloud-Config 文件

注：Cloud-config 文件位于 /usr/share/oem/cloud-config.yml 。访问 Cloud-Config Validator ，或者运行 coreos-cloudinit -validate 以验证 cloud-config 在该 CoreOS 虚拟机中可用。

1、为用户 core 设置 SSH 公钥。 2、从你的客户端生成一个新的 SSH key。 ssh-keygen -t rsa 3、输入一个 passphrase，并检查 id_rsa 和 id_rsa.pub 是否已经生成。 4、检查 CoreOS 虚拟机的 IP 地址。 5、登录到 CoreOS 虚拟机并编辑 /usr/share/oem/cloud-config.yml 文件。 6、拷贝 RSA 公钥 id_rsa.pub 的内容到 ssh_authorized_keys 里。 ssh-rsa [id_rsa.pub.content.here] 7、重启 CoreOS 虚拟机并用 RSA 私钥校验是否能登录。 [root@localhost .ssh]# ssh -i id_rsa core@[your.ip.address.here]

更多关于cloud-config自定义的信息，请参考 cloud-config 指南。

完成首台虚拟机 user_data 自定义之后，你就可以部署更多的 CoreOS 虚拟机来设置 CoreOS 集群。

Open VM Tools

CoreOS 490.0.0 及其后版本已包含 open-vm-tools —— VMware Tools 的开源实现。更多信息，参考 VMware support of open-vm-tools (2073803)。
2015-04-02

OmniOS Shell Env Check List

bash Shell

~/.profile

#!/bin/bash
# Solaris 衍生的 OS，默认都将 GNU 路径放在前面
# 而支持 ACLs 的 ls/chmod ，是在 /usr/bin 目录中的
export PATH=/usr/bin:/usr/sbin:/sbin:/usr/gnu/bin

export TERM=xterm-color

# Enable color support of ls and also add handy aliases
if [ -x /usr/bin/dircolors ]; then
    test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval "$(dircolors -b)"
    alias ls='/usr/bin/ls --color=auto'
    #alias dir='dir --color=auto'
    #alias vdir='vdir --color=auto'

    alias grep='grep --color=auto'
    alias fgrep='fgrep --color=auto'
    alias egrep='egrep --color=auto'
fi

# Some more ls aliases
alias ll='ls -alF'
alias la='ls -A'
alias l='ls -CF'

~/.vimrc

set nocp
set bs=2
syntax on

./.inputrc

"\e[1~": beginning-of-line     # Home
"\e[4~": end-of-line           # End
"\e[5~": beginning-of-history  # PageUp
"\e[6~": end-of-history        # PageDown
"\e[3~": delete-char           # Delete
"\e[2~": quoted-insert         # Insert
"\eOD": backward-word          # Ctrl+Left
"\eOC": forward-word           # Ctrl+Right

/etc/default/init

TZ="Asia/Shanghai"
CMASK=022
LANG=en_US.UTF-8

2015-03-31

VMware ESXi 5.5 下 Solaris 11.2 紫屏



2015-03-28

分类： 信息技术

GitLab Runners

Shared vs. Specific Runners

创建并注册 Runner

注册Shared Runner

注册Specific Runner

Registering a Specific Runner with a Project Registration token

Lock a specific Runner from being enabled for other projects

Making an existing Shared Runner Specific

Using Shared Runners Effectively

Use Tags

Prevent Runner with tags from picking jobs without tags

Be careful with sensitive information

Forks

Attack vectors in Runners

Docker 镜像安装及配置

更新

安装受信的 SSL 服务器证书

Alpine Linux

SELinux

GitLab Runner

执行器（Executor ）的比较

Docker 执行器

工作流程

image 关键字

services 关键词

服务如何链接到构建

从.gitlab-ci.yml定义image和services

Define image and services in config.toml

从私有 Docker Registry 中定义镜像

访问服务

配置服务

服务中的构建目录

PostgreSQL 服务示例

MySQL 服务示例

服务健康检查

构建和缓存存储

持久存储

构建的持久存储

特权（privileged）模式

使用具有特权模式的 docker-in-docker

ENTRYPOINT

镜像拉取策略如何工作

使用拉取策略never

使用拉取策略if-not-present

使用拉取策略always

Docker vs Docker-SSH

〇、获取安装文件

一、创建 ESXi 虚拟机

二、安装 OmniOS

三、安装 VMware Tools 及 VMXNet3 网卡

安装介绍

前置需求

安装步骤

Open VM Tools

bash Shell

分类：信息技术

注册`Shared Runner`

注册`Specific Runner`

`image` 关键字

`services` 关键词

从`.gitlab-ci.yml`定义`image`和`services`

Define image and services in `config.toml`

特权（`privileged`）模式

使用拉取策略`never`

使用拉取策略`if-not-present`

使用拉取策略`always`