Gitlab-CI(在gitlab.com下)“系统故障"开始容器处理 [英] Gitlab-CI (under gitlab.com) "system failure" starting container process

查看:377
本文介绍了Gitlab-CI(在gitlab.com下)“系统故障"开始容器处理的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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

This is my 1st try to set up a basic CI workflow on gitlab.com. The concerned project is a basic static website, and I wanted to run some npm install and gulp build directly on gitlab.

我创建了一个.gitlab-ci.yml文件,该文件可以识别并启动.但是最初的实现失败了,所以我回到了有史以来最基本的CI脚本,如下所示:

I created a .gitlab-ci.ymlfile, which is recognized and launched. But firsts implementations failed, so I came back to the more basic CI script ever, as follows:

image: debian:jessie

stages:
  - build

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

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

Even in this case I encounter the same error:

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:latest& busybox.

I tried with the following images: debian:jessie, node:latest & busybox.

请问如何解决此问题?我在做错什么吗?

How could I fix this issue please? Am I doing something wrong?

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

HINT: Please, note that this is a Gitlab.com hosted instance. Not a local one. The runner I'm using is hosted on Gitlab servers.

完整错误消息:

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.com

gitlab-ci.yml(debian)

image: debian:jessie

stages:
  - build

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

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

My project is a default Node.js project on base, and I just changed the default docker gitlab-ci.yml in order to match yours.

我的结果就是那些:

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

如您所见,它非常完美.

As you will see, it went perfect.

我看到的区别是:

矿山:

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

Running with gitlab-runner 12.3.0 (a8a019e0) on docker-auto-scale ed2dce3a

您的用户:

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

Running with gitlab-runner 12.3.0 (a8a019e0) on docker-auto-scale fa6cab46

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

If you go to shared runners section, just check that ed2dce3a and fa6cab46 are the references for our runners.

如果现在仔细看一下标签,您会发现它们是不同的:min仅是dockergce,但是您的标签却更多.

If you now look carefully at the tags, you will see they are different: min is only docker and gce but yours has much more tags.

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

第二次尝试,我尝试使用此gitlab-yml创建node:latest图像

As a second attempt, I tried to create a node:latest image with this gitlab-yml

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

如您所见,我的项目与默认项目完美配合.

As you see, my projects went perfectly with a default project.

这是我的示例项目 ,其中有两个不同的项目在gitlab.com上创建的分支.

Here is my example project with two different branches created on gitlab.com.

如果我是你,我将尝试重新生成跑步者密钥并 禁用共享跑步者,然后再次启用它们,以检查是否 您的项目出了点问题.如果这不起作用,请 从头开始重新创建一个新项目.这似乎是某种 在某些版本中的错误.也许它发生了一段时间, 再次回来.

If I were you, I would try to re-generate the runners key and to disable shared runners and enable them again in order to check if something went wrong in your project. If this does not work, just re-creating a new project from scratch. This seems to be some kind of bug in some of the versions. Maybe it just happened for some time and get back again.

我希望至少这对您有帮助

I hope at least this helps you

这篇关于Gitlab-CI(在gitlab.com下)“系统故障"开始容器处理的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆