Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
李少辉-开发者
gitlab-foss
提交
c7a55170
G
gitlab-foss
项目概览
李少辉-开发者
/
gitlab-foss
通知
15
Star
0
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
G
gitlab-foss
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
提交
Issue看板
前往新版Gitcode,体验更适合开发者的 AI 搜索 >>
未验证
提交
c7a55170
编写于
3月 19, 2018
作者:
A
Achilleas Pipinellis
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
Copyedit CI services docs
上级
af6c16a8
变更
1
隐藏空白更改
内联
并排
Showing
1 changed file
with
33 addition
and
56 deletion
+33
-56
doc/ci/docker/using_docker_images.md
doc/ci/docker/using_docker_images.md
+33
-56
未找到文件。
doc/ci/docker/using_docker_images.md
浏览文件 @
c7a55170
...
...
@@ -58,7 +58,7 @@ your job and is linked to the Docker image that the `image` keyword defines.
This allows you to access the service image during build time.
The service image can run any application, but the most common use case is to
run a database container, e
g.
`mysql`
. It's easier and faster to use an
run a database container, e
.g.,
`mysql`
. It's easier and faster to use an
existing image and run it as an additional container than install
`mysql`
every
time the project is built.
...
...
@@ -83,42 +83,46 @@ So, in order to access your database service you have to connect to the host
named
`mysql`
instead of a socket or
`localhost`
. Read more in
[
accessing the
services
](
#accessing-the-services
)
.
### How
service health check
works
### How
the health check of services
works
Services are designed to provide additional functionality which is
**network accessible**
.
It may be a database
(like mysql, but also like redis), this may be docker:dind (
which
allows you to use Docker
). This may be anything else that is required for the CI/CD job
to proceed and what
is accessed by network.
It may be a database
like MySQL, or Redis, and even
`docker:dind`
which
allows you to use Docker
in Docker. It can be practically anything that is
required for the CI/CD job to proceed and
is accessed by network.
To make sure this works,
Runner is
:
To make sure this works,
the Runner
:
1.
check
ing which ports are exposed from the container by default,
1.
starts a special container that waits for these ports to be accessible
.
1.
check
s which ports are exposed from the container by default
1.
starts a special container that waits for these ports to be accessible
When the second stage of the check fails
(
either because there is no opened port in the
service, or service was not started properly before the timeout and the port is not
responding
)
, it prints the warning:
`*** WARNING: Service XYZ probably didn't start properly`
.
When the second stage of the check fails
,
either because there is no opened port in the
service, or
the
service was not started properly before the timeout and the port is not
responding, it prints the warning:
`*** WARNING: Service XYZ probably didn't start properly`
.
In most cases it will affect the job, but there may be situations when
job still succeeds
even if such warning was printed, e.g.
:
In most cases it will affect the job, but there may be situations when
the job
will still succeed even if that warning was printed. For example
:
-
service was started a little after the warning was raised, and the job is using it not
from the very beginning - in that case when the job (e.g. tests) needed to access the
service, it may be already there waiting for connections,
-
service container is not providing any networking service, but doing something with job's
directory (all services have the job directory mounted as a volume under
`/builds`
) - in
that case the service will do its job, and since tje job is not trying to connect to it,
it doesn't fail.
-
The service was started a little after the warning was raised, and the job is
not using the linked service from the very beginning. In that case, when the
job needed to access the service, it may have been already there waiting for
connections.
-
The service container is not providing any networking service, but it's doing
something with the job's directory (all services have the job directory mounted
as a volume under
`/builds`
). In that case, the service will do its job, and
since the job is not trying to connect to it, it won't fail.
### What services are not for
As it was mentioned before, this feature is designed to provide
**network accessible**
services. A database is the
easiest example of such
service.
services. A database is the
simplest example of such a
service.
**
Services feature is not designed to, and will not add any software from defined
service image to job's container.
**
NOTE:
**Note:**
The services feature is not designed to, and will not add any software from the
defined
`services`
image(s) to the job's container.
For example, such definition:
For example, if you have the following
`services`
defined in your job, the
`php`
,
`node`
or
`go`
commands will
**not**
be available for your script, and thus
the job will fail:
```
yaml
job
:
...
...
@@ -133,39 +137,12 @@ job:
-
go version
```
will not make
`php`
,
`node`
or
`go`
commands available for your script. So each of the
commands defined in
`script:`
section will fail.
If you need to have
`php`
,
`node`
and
`go`
available for your script, you should
either:
If you need to have
`php`
,
`node`
and
`go`
available for your script, you should either:
-
choose existing Docker image that contain all required tools, or
-
choose the best existing Docker image that fits into your requirements and create
your own one, adding all missing tools on top of it.
Looking at the example above, to make the job working as expected we should first
create an image, let's call it
`my-php-node-go-image`
, basing on Dockerfile like:
```
Dockerfile
FROM
alpine:3.7
RUN
command-to-install-php
RUN
command-to-install-node
RUN
command-to-install-golang
```
and then change the definition in
`.gitlab-ci.yml`
file to:
```
yaml
job
:
image
:
my-php-node-go-image
script
:
-
php -v
-
node -v
-
go version
```
This time all required tools are available in job's container, so each of the
commands defined in
`script:`
section will eventualy succeed.
-
choose an existing Docker image that contains all required tools, or
-
create your own Docker image, which will have all the required tools included
and use that in your job
### Accessing the services
...
...
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录