【问题标题】:Gitlab-CI (under gitlab.com) "system failure" starting container processGitlab-CI(gitlab.com下)“系统故障”启动容器进程
【发布时间】:2019-10-04 14:52:54
【问题描述】:

这是我第一次尝试在 gitlab.com 上设置基本 CI 工作流程。关注的项目是一个基本的静态网站,我想直接在gitlab上运行一些npm installgulp build

我创建了一个.gitlab-ci.yml文件,它被识别并启动。但是 firsts 实现失败了,所以我回到了更基本的 CI 脚本,如下:

image: debian:jessie

stages:
  - build

build:
  stage: build
  script: echo "Building the app"

即使在这种情况下,我也会遇到同样的错误:

ERROR: Job failed (system failure): Error response from daemon: OCI runtime create failed: container_linux.go:348: starting container process caused "exec: \"gitlab-runner-build\": executable file not found in $PATH": unknown (executor_docker.go:833:0s) 

我尝试使用以下图片:debian:jessienode:latestbusybox

请问我该如何解决这个问题?我是不是做错了什么?

提示:请注意,这是一个 Gitlab.com 托管实例。不是一个 本地的。我使用的跑步者托管在 Gitlab 服务器上。

完整的错误信息:

Running with gitlab-runner 12.3.0 (a8a019e0)
  on docker-auto-scale fa6cab46
Using Docker executor with image node:latest ...
Pulling docker image node:latest ...
Using docker image sha256:e498dabfee1c6735c9da947e0d438edd13593b7d721c989ba8ede14ab603b900 for node:latest ...

ERROR: Job failed (system failure): Error response from daemon: OCI runtime create failed: container_linux.go:348: starting container process caused "exec: \"gitlab-runner-build\": executable file not found in $PATH": unknown (executor_docker.go:833:0s)

【问题讨论】:

  • 该错误表明 GitLab 运行器将自身注入容器时出现问题,如果您使用他们的共享运行器,它可能很快就会修复,请尝试使用另一个基础镜像,例如 busybox
  • 感谢您的评论。我试过busybox,同样的错误......
  • 一位用户说使用stretch代替jessie解决了他们的问题:gitlab.com/gitlab-org/gitlab/issues/27042#note_215660995
  • 你安装了docker gitlab-runner???
  • @AlejandroTeixeiraMuñoz 在本地?我正在使用 gitlab.com,我什么都没安装。

标签: gitlab gitlab-ci


【解决方案1】:

我在 Gitlab.com 的一个全新项目中准确测试了您的模型

gitlab-ci.yml(debian)

image: debian:jessie

stages:
  - build

build:
  stage: build
  script: echo "Building the app"

我的项目是默认的 Node.js 项目,我只是更改了默认的docker gitlab-ci.yml 以匹配您的项目。

我的结果是那些:

Running with gitlab-runner 12.3.0 (a8a019e0)
  on docker-auto-scale ed2dce3a
Using Docker executor with image debian:jessie ...
Pulling docker image debian:jessie ...
Using docker image sha256:c9d6adb06e4d1092f4dae842e41ba34566481ac002ad52102389122ea6969fd4 for debian:jessie ...
Running on runner-ed2dce3a-project-14701224-concurrent-0 via runner-ed2dce3a-srm-1570489833-8fc7b7db...
Fetching changes with git depth set to 50...
Initialized empty Git repository in /builds/alejandroteixeiraconsultoria/my-awesome-response/.git/
Created fresh repository.
From https://gitlab.com/alejandroteixeiraconsultoria/my-awesome-response
 * [new branch]      master     -> origin/master
Checking out 39d7cf97 as master...

Skipping Git submodules setup
$ echo "Building the app"
Building the app
Job succeeded

如您所见,它非常完美。

我看到的区别是这样的:

我的:

在 docker-auto-scale 上使用 gitlab-runner 12.3.0 (a8a019e0) 运行 ed2dce3a

你的:

在 docker-auto-scale 上使用 gitlab-runner 12.3.0 (a8a019e0) 运行 fa6cab46

如果您转到共享跑步者部分,只需检查 ed2dce3afa6cab46 是否是我们跑步者的参考。

如果您现在仔细查看标签,您会发现它们是不同的:min 只有 dockergce,但您的标签要多得多。

shared-runners-manager-6.gitlab.com 
shared-runners-manager-3.gitlab.com 

作为第二次尝试,我尝试用这个 gitlab-yml 创建一个node:latest 图像

gitlab-ci.yml(节点)

image: node:latest

stages:
  - build

build:
  stage: build
  script: 
    - echo "Building the app"
    - echo "Calling npm "
    - npm update

结果又成功了:

Running with gitlab-runner 12.3.0 (a8a019e0)
  on docker-auto-scale fa6cab46
Using Docker executor with image node:latest ...
Pulling docker image node:latest ...
Using docker image sha256:e498dabfee1c6735c9da947e0d438edd13593b7d721c989ba8ede14ab603b900 for node:latest ...
Running on runner-fa6cab46-project-14701224-concurrent-0 via runner-fa6cab46-srm-1570491263-da01e8a0...
Fetching changes with git depth set to 50...
Initialized empty Git repository in /builds/alejandroteixeiraconsultoria/my-awesome-response/.git/
Created fresh repository.
From https://gitlab.com/alejandroteixeiraconsultoria/my-awesome-response
 * [new branch]      NodeApp    -> origin/NodeApp
Checking out e1235047 as NodeApp...

Skipping Git submodules setup
$ echo "Building the app"
Building the app
$ echo "Calling npm "
Calling npm 
**$ npm update**

> core-js@2.6.9 postinstall /builds/alejandroteixeiraconsultoria/my-awesome-response/node_modules/core-js
> node scripts/postinstall || echo "ignore"

+ http-errors@1.6.3
+ cookie-parser@1.4.4
+ express@4.16.4
+ morgan@1.9.1
+ debug@2.6.9
+ pug@2.0.0-beta11
added 165 packages from 606 contributors and audited 305 packages in 7.972s
found 1 low severity vulnerability
  run `npm audit fix` to fix them, or `npm audit` for details
Job succeeded

如您所见,我的项目与默认项目完美结合。

Here is my example project 在 gitlab.com 上创建了两个不同的分支。

如果我是你,我会尝试重新生成 runners 密钥并 禁用共享运行器并再次启用它们以检查是否 你的项目出了点问题。如果这不起作用,只需 从头开始重新创建一个新项目。这似乎是某种 某些版本中的错误。也许它只是发生了一段时间 再回来。

希望至少能帮到你

【讨论】:

  • 感谢您的帮助和宝贵的见解。事实上,“我的”跑步者是72989761,我还没有检查是否可以配置(哪个跑步者用于哪个项目),但我认为不能。顺便说一句,我已经分叉了您的项目,运行了 CI 并且它可以工作....使用相同的跑步者!所以我认为这不是一个全球性的跑步者问题,而且仅限于我的项目范围内。我将删除 repo 并创建一个新的。
  • 所以我创建了一个新的仓库并将我的项目推送到这个仓库。 CI 运行成功,使用与上述相同的运行器。
  • 我正在为您准备命令,以进行大解释。我会在几分钟内添加它。 !!!
  • 我没有检查是否可以配置(哪个项目的哪个跑步者),但我认为不能。您可以分配标签来过滤将使用哪些跑步者,如果您创建一个专用的。
  • 没有改变任何东西,现在它在我的初始项目中也能正常工作,使用“你的”跑步者(`ed2dce3a`)。奇怪的行为!
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2017-12-16
  • 2020-10-17
  • 1970-01-01
  • 2019-03-04
  • 1970-01-01
  • 2014-03-03
  • 1970-01-01
相关资源
最近更新 更多