GoogleContainerTools / kaniko

Build Container Images In Kubernetes
Apache License 2.0
14.67k stars 1.42k forks source link

kaniko should only be run inside of a container #1542

Open valador opened 3 years ago

valador commented 3 years ago

Actual behavior Try to build example and fail "kaniko should only be run inside of a container, run with the --force flag if you are sure you want to continue" Tested with git context, same error. I start example vith k3s in lxc container, unprevileged - error, previleged - vork fine.

Expected behavior Build and "hello"

To Reproduce k3s kubernetes

Additional Information

debdolph commented 3 years ago

Any progress? Running into this error after updating to debian bullseye with docker 20.10.5.

qalinn commented 3 years ago

Any update on this ?

rawyler commented 3 years ago

I've encountered the same issue when running a kaniko job on a docker based gitlab-runner. But for me it was failing with privileged = true.

I guess I started to have those since the change of https://github.com/GoogleContainerTools/kaniko/commit/c2a919a801ae0a530d2a99f74810144c3f904b1c#diff-cb441f1bc0f59b82d3fec60db5a4e6924c446fce5d868e14f0e2ad4a88d987ed which detects in what containered environment it runs.

So as a hack I've added environment = ["container=docker"] to my gitlab-runner config.toml and I'm able to build docker images with kaniko again. This environment variable is read by the container detection script https://github.com/GoogleContainerTools/kaniko/blame/57ea150cade8689a311a1db4bba23ee705b06728/vendor/github.com/genuinetools/bpfd/proc/proc.go#L138

davinkevin commented 3 years ago

I have the same problem. I can't identify "what" change precisely (kubernetes version, gitlab runner…) but since I fully reinstall k3s, I encounter the same problem.

nickbroon commented 2 years ago

Might this be related to #1592 ?

JonasGroeger commented 2 years ago

We have 2 runners (Debian 10 and Debian 11) with otherwise identical configuration. The Debian 10 runner worked fine but the Debian 11 runner had this issue. The cgroups version was identical (v2).

The workaround of @rawyler worked. Here a little more context:

$ cat /etc/gitlab-runner/config.toml
[[runners]]
  url = "..."
  environment = ["container=docker"]
Floppy012 commented 2 years ago

We have 2 runners (Debian 10 and Debian 11) with otherwise identical configuration.

I have exactly the same issue (also using Gitlab Runner). I just want to provide a little more information:

Node A ``` root@***:~# uname -a Linux *** 4.19.0-18-amd64 #1 SMP Debian 4.19.208-1 (2021-09-29) x86_64 GNU/Linux root@***:~# lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 10 (buster) Release: 10 Codename: buster root@***:~# docker -v Docker version 20.10.11, build dea9396 root@***:~# grep cgroup /proc/filesystems nodev cgroup nodev cgroup2 ```
Node B ``` root@***:~# uname -a Linux *** 5.10.0-11-amd64 #1 SMP Debian 5.10.92-1 (2022-01-18) x86_64 GNU/Linux root@***:~# lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 11 (bullseye) Release: 11 Codename: bullseye root@***:~# docker -v Docker version 20.10.12, build e91ed57 root@***:~# grep cgroup /proc/filesystems nodev cgroup nodev cgroup2 ```
imjasonh commented 2 years ago

Might this be related to #1592 ?

This sounds like a likely culprit. If anybody has experience or interest or time to investigate, it would be much appreciated.

int128 commented 2 years ago

I got the same error when trying docker run on GitHub Actions.

Here is my script and result.

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - run: |
          docker run --rm \
            -v $(pwd)/helloworld:/workspace:ro \
            gcr.io/kaniko-project/executor:v1.8.0 \
            --context dir:///workspace/ \
            --no-push \
            --verbosity debug
$ docker run --rm \
    -v $(pwd)/helloworld:/workspace:ro \
    gcr.io/kaniko-project/executor:v1.8.0 \
    --context dir:///workspace/ \
    --no-push \
    --verbosity debug
Unable to find image 'gcr.io/kaniko-project/executor:v1.8.0' locally
v1.8.0: Pulling from kaniko-project/executor
...
Digest: sha256:ff98af876169a488df4d70418f2a60e68f9e304b2e68d5d3db4c59e7fdc3da3c
Status: Downloaded newer image for gcr.io/kaniko-project/executor:v1.8.0
DEBU[0000] Getting source context from dir:///workspace/ 
DEBU[0000] Build context located at /workspace/         
DEBU[0000] Copying file /workspace/Dockerfile to /kaniko/Dockerfile 
kaniko should only be run inside of a container, run with the --force flag if you are sure you want to continue
Error: Process completed with exit code 1.
int128 commented 2 years ago

I found the workaround at https://github.com/GoogleContainerTools/kaniko/issues/1542#issuecomment-999545027.

I added -e container=docker to the docker args and finally it works!

      - run: |
          docker run --rm \
            -v $(pwd)/helloworld:/workspace:ro \
            -e container=docker \
            gcr.io/kaniko-project/executor:v1.8.0 \
            --context dir:///workspace/ \
            --no-push \
            --verbosity debug
superherointj commented 2 years ago

For running in a Kubernetes cluster, you have to declare an environment variable named container with value kube.

To configure gitlab-runner that runs on Kubernetes use: $ cat /etc/gitlab-runner/config.toml

[[runners]]
executor = "kubernetes"
environment = [ "container=kube" ]

For other runtimes, see options.

stanhu commented 1 year ago

We ran into this error with Kaniko v1.3.0 and Google COS cos-105-17412-101-24.

Updating to Kaniko v1.11.0 fixed the problem.