Proxy question

[mpcref]

I'm trying to use the Kaniko executor behind a proxy. I'm using apk add in my Dockerfile. It works fine when I supply http_proxy as a --build-arg but I would expect that this shouldn't be necessary when there's already a proxy configured in ~/.docker/config.json. I know kaniko executor looks for credentials in this file so therefore is seems logical that this should also be supported.
Is this simply not supported or am I missing something?

Configure Docker to use a proxy server

[priyawadhwa]

Hey @cref, we don't currently support this -- right now we use a library which looks at the config.json and handles authentication and pulling/pushing images for us.

[bobcatfish]

@cref would you be able to provide the commands you are using to reproduce this? One issue could be that you need to mount the ~/.docker/config.json into the kaniko executor container in order for it to parse this (to /kaniko/.docker/config.json).

If that's not working for you then it could be a bug with go-containerregistry which we are using to parse the config.json 🤔

[Caligatio]

Just to add some more detail here:

Good News - It appears that go-containerregistry is respecting the proxy settings when pulling in base image(s)

Bad News - When the proxy is specified in the config.json, "normal" Docker essentially sets the HTTP_PROXY variable(s) temporarily within in the build container/context; kaniko does not. For instance if your Dockerfile has a RUN curl... command, that cURL will listen to the proxy settings specified in the host's config.json

This is a super helpful feature to have for those of us that are stuck with HTTP proxies as it allows the build to transparently handle needing a proxy without stamping any of that information into the end-product image.

[tequilarista]

triage - collapsing 'waiting for response' category into 'blocked'

[kfox1111]

We just hit this issue too

[giovanism]

My team hit this issue too. We would really like to see more discussion on this.

[leolb-aphp]

Also meeting that issue. Currently trying to figure out the best way to solve this as-is, will report back if I find a good workaround in the mean time to do it.

[ralph089]

We hit this issue too!

[pdefreitas]

For this one, it would be helpful if the executor had a flag to import all or specific environment variables (e.g. proxy settings) into the build-time variables. Setting up --build-arg with the necessary settings works as a workaround, kudos for the reporter for saving me some time.

[teedee22]

Here to second @pdefreitas suggestion!

[PMExtra]

Just to add some more detail here:

Good News - It appears that go-containerregistry is respecting the proxy settings when pulling in base image(s)

Bad News - When the proxy is specified in the config.json, "normal" Docker essentially sets the HTTP_PROXY variable(s) temporarily within in the build container/context; kaniko does not. For instance if your Dockerfile has a RUN curl... command, that cURL will listen to the proxy settings specified in the host's config.json

This is a super helpful feature to have for those of us that are stuck with HTTP proxies as it allows the build to transparently handle needing a proxy without stamping any of that information into the end-product image.

@donmccasland I think this is not area/registry, it's about build-time. Would you change the labels?

[PMExtra]

For now, I wrote the duplicate and cumbersome CI codes in every project:

    - /kaniko/executor
        ${DOCKER_HUB_MIRROR:+"--registry-mirror=$DOCKER_HUB_MIRROR"}
        --build-arg "ftp_proxy=${ftp_proxy}"
        --build-arg "FTP_PROXY=${ftp_proxy}"
        --build-arg "http_proxy=${http_proxy}"
        --build-arg "HTTP_PROXY=${http_proxy}"
        --build-arg "https_proxy=${https_proxy}"
        --build-arg "HTTPS_PROXY=${https_proxy}"
        --build-arg "no_proxy=${no_proxy}"
        --build-arg "NO_PROXY=${no_proxy}"

But in docker, I can do the same thing without any duplicate codes, I only need to change the config file once.
So I want someone to pay attention to this, it's a really useful and commonly feature.

Hint: there is no standard for these environments, most of applications work with the lower-case environments, but some others work with upper-case. So it's a more compatible solution to define both of them, just like the docker implementation.

[doublespaces]

For now, I wrote the duplicate and cumbersome CI codes in every project:

    - /kaniko/executor
        $([ -n "${DOCKER_HUB_MIRROR}" ] && echo "--registry-mirror=${DOCKER_HUB_MIRROR}")
        --build-arg "ftp_proxy=${ftp_proxy}"
        --build-arg "FTP_PROXY=${ftp_proxy}"
        --build-arg "http_proxy=${http_proxy}"
        --build-arg "HTTP_PROXY=${http_proxy}"
        --build-arg "https_proxy=${https_proxy}"
        --build-arg "HTTPS_PROXY=${https_proxy}"
        --build-arg "no_proxy=${no_proxy}"
        --build-arg "NO_PROXY=${no_proxy}"

But in docker, I can do the same thing without any duplicate codes, I only need to change the config file once. So I want someone to pay attention to this, it's a really useful and commonly feature.

Hint: there is no standard for these environments, most of applications work with the lower-case environments, but some others work with upper-case. So it's a more compatible solution to define both of them, just like the docker implementation.

Thanks, this worked for me.

[zepag]

Hello, this is indeed a regression when coming from Docker to Kaniko.

Would it be possible to implement an equivalent mechanism, as described above?
This indeed makes Dockerfile configuration non-portable, and very quickly cumbersome.

[Trolldemorted]

For now, I wrote the duplicate and cumbersome CI codes in every project:

    - /kaniko/executor
        ${DOCKER_HUB_MIRROR:+"--registry-mirror=$DOCKER_HUB_MIRROR"}
        --build-arg "ftp_proxy=${ftp_proxy}"
        --build-arg "FTP_PROXY=${ftp_proxy}"
        --build-arg "http_proxy=${http_proxy}"
        --build-arg "HTTP_PROXY=${http_proxy}"
        --build-arg "https_proxy=${https_proxy}"
        --build-arg "HTTPS_PROXY=${https_proxy}"
        --build-arg "no_proxy=${no_proxy}"
        --build-arg "NO_PROXY=${no_proxy}"

But in docker, I can do the same thing without any duplicate codes, I only need to change the config file once. So I want someone to pay attention to this, it's a really useful and commonly feature.

Hint: there is no standard for these environments, most of applications work with the lower-case environments, but some others work with upper-case. So it's a more compatible solution to define both of them, just like the docker implementation.

This is not enough, you also need to ENV HTTP*_PROXY=... in your Dockerfile, which you can omit if you use docker. I am now changing the Dockerfile in my CI scripts with sed:

  - sed -i '1 s#.*#FROM python as backend\nENV HTTP_PROXY=http://proxy.foo.bar\nENV http_proxy=http://proxy.foo.bar:8080\nENV HTTPS_PROXY=http://proxy.foo.bar\nENV https_proxy=http://proxy.foo.bar#' Dockerfile

[AndrewTsao]

Smuggle proxy environment variables into the Kanoki builder environment by adding special comments in /etc/hosts. In .gitlab-ci.yml, add this.

script:
    - echo "#export PIP_INDEX_URL=${PIP_INDEX_URL}" >> /etc/hosts
    - echo "#export PIP_TRUSTED_HOST=${PIP_TRUSTED_HOST}" >> /etc/hosts
    - echo "#export HTTP_PROXY=${HTTP_PROXY}" >> /etc/hosts
    - echo "#export HTTPS_PROXY=${HTTPS_PROXY}" >> /etc/hosts
    - echo "#export NO_PROXY=${NO_PROXY}" >> /etc/hosts

then, change dockerfile like this,

SHELL ["/bin/bash", "-c", "eval $(sed -n 's/^#export/export/p' /etc/hosts) && eval $@", "-"]
RUN sed -e 's|^mirrorlist=|#mirrorlist=|g' \
         -e 's|^#baseurl=http://mirror.centos.org/centos|baseurl=https://mirrors.tuna.tsinghua.edu.cn/centos|g' \
         -i /etc/yum.repos.d/CentOS-*.repo && \
    yum install -y epel-release