1

The situation

I'm currently working on a project where I migrate the CI environment from Jenkins to GitLab CI. To get everything working I've built a few docker containers that should serve as base images for the CI pipeline. These containers cannot be stored in the GitLab internal container registry and should be pushed to a Artifactory instance.

What I already did/tried

So far I got everything going by using Kaniko for the Docker builds and the resulting images are correctly pushed to the artifactory registry - so far, so good.

However I've now reached a point where I have CI-Jobs that should make use of previously built container-images as their base image, so they should be pulled from the artifactory instance, which serves as private registry.

example config

.docker-build-abstract:
  image: custom.kaniko.fork.from.internal.gitlab-registry:<tag>
  script:
    - |>
      echo "build container with image tag: ${IMAGE_TAG}"
      # kaniko default build..

# This job builds an image that is pushed to private registry.
docker-build-1:
  stage: "build"
  variables:
    IMAGE_TAG: some.nice.tag
    BUILD_ARGS: --build-arg foo=bar --build-arg bar=baz
  extends:
    - .docker-build-abstract

# This job should make use of the previously built image
other-job-1:
  stage: "build"
  image: docker.from.docker-build-1:<tag>
  script: #...

The Problem with this is that I cannot make use of DOCKER_AUTH_CONFIG variable in the CI-Settings that is proposed in the official docs. This is because (my understanding) when providing this variable in the project settings this would overwrite the default registry-settings (CI_REGISTRY, CI_REGISTRY_USER, CI_REGISTRY_PASSWORD) but I need to preserve the values behind these internal variables because some of the first jobs make use of Container-images that are only present within this private gitlab instance.

Is it possible to provide multiple auth-configs in the CI/CD Variable settings? And how would I reference the predefined variables in here since this important to keep the internal registry known?

I would imagine something like below (which is part of the kaniko pre-configuration), but cannot come up with a possible solution for this scenario.

{
  "auths": {
    "$PRIVATE_REGISTRY": {
      "username": "$PRIV_REGISTRY_USER",
      "password": "$PRIV_REGISTRY_API_KEY",
      "email": "$PRIV_REGISTRY_USER_EMAIL"
    },
    "$CI_REGISTRY": {
      "username": "$CI_REGISTRY_USER",
      "password": "$CI_REGISTRY_PASSWORD"
    }
  }
}

In my understanding the variables can be overwritten in the ci-configuration, but this did not work for me. Would this require advanced configuration of the ci-runner to achieve the desired behavior, like outlined here in the docs?

Really appreciate your help or hints!

SPMSE
  • 478
  • 3
  • 14
  • Does this answer your question? [Using a private Docker Image from Gitlab Registry as the base image for CI](https://stackoverflow.com/questions/38269701/using-a-private-docker-image-from-gitlab-registry-as-the-base-image-for-ci) – stackprotector Jul 13 '23 at 16:16

2 Answers2

1

You can use DOCKER_AUTH_CONFIG for this. The config can support multiple registries. So it's possible to have this set for both your GitLab internal registry as well as your JFrog Artifactory instance. See: credential helpers in the docker documentation, which supports multiple registries.

Alternatively, you can use docker login as-needed in your job, which will apply auth information to your (docker) config dynamically.

my_job:
  before_script:
    # authenticate to pull from GitLab registry
    # https://docs.gitlab.com/ee/ci/variables/predefined_variables.html
    - docker login $CI_REGISTRY -u $CI_REGISTRY_USER -p $CI_JOB_TOKEN
 
    # authenticate to pull from Artifactory
    # you must define these variables
    - docker login $ARTIFACTORY_REGISTRY -u $ARTIFACTORY_USER -p $ARTIFACTORY_PASSWORD

You could also use a combination of the two -- DOCKER_AUTH_CONFIG for artifactory and docker login for GitLab registry, as an example.

Alternatively still, you can also configure JFrog Artifactory virtual repos that will serve images from your GitLab registry. That way you only need to configure one registry on the job side. However, this requires setup in advance and can have authorization implications.

sytech
  • 29,298
  • 3
  • 45
  • 86
  • How would I use `DOCKER_AUTH_CONFIG` for this? I configured the variable in the project settings since this seemed to be the only way to achieve this, but how would I reference the predefined variables in the project settings? Or could you maybe point out how to set this in ci-configuration (`.gitlab-ci.yml`), is this even possible? – SPMSE Feb 08 '22 at 12:47
0

You can in fact configure multiple credentials in the "auths" section above. That does work fine for us. But I don't think it will work via setting DOCKER_AUTH_CONFIG in the CI pipeline. I think we tried that once and it did not work. We configure it in the Runner configuration by setting the environment variable.

If you can't do that, another solution would be to run the docker login command in your CI pipeline, e.g. in the before_script section.

  • Running docker login is not an option as the referenced image which is the base image comes from private registry. DOCKER_AUTH_CONFIG seems to be the only way except from configuring the runner (which also is no option in this case) – SPMSE Feb 04 '22 at 14:15
  • @SPMSE can you elaborate on why a docker login does not work for the private registry? I feel that I am not getting the whole picture here. Something similar to this should do the trick: docker login -p $PRIV_REGISTRY_API_KEY -u $PRIV_REGISTRY_USER $PRIVATE_REGISTRY – Stephan Hochdoerfer Feb 05 '22 at 15:59
  • This is not an option because the image where the step will be executed in already is from the private registry, so I can’t add `before_script` or `script` that does the `docker login` step. See the `other-job-1` example mentioned above. The base image for this step is built in previous stage and also is pushed to the private registry. The push is done via kaniko which makes it possible to authenticate with kaniko in the `before_script`, but this does not apply for the other job – SPMSE Feb 06 '22 at 10:57