mirror of https://github.com/woodpecker-ci/woodpecker.git synced 2025-04-28 22:44:43 +00:00

Implement registries for Kubernetes backend (#4092 )

According to [the documentation](https://woodpecker-ci.org/docs/administration/backends/kubernetes#images-from-private-registries), per-organization and per-pipeline registries are currently unsupported for the Kubernetes backend.

This patch implements this missing functionality by creating and deleting a matching secret for each pod with a matched registry, using the same name, labels, and annotations as the pod, and appending it to its `imagePullSecrets` list.

This patch adds tests for the new functionality, and has been manually end-to-end-tested in KinD by using a private image hosted in the matching gitea instance.

This will require updating the matching helm charts to add the create/delete permissions to the agent role, which **is already done**.

close  #2987

2024-09-30 01:03:05 +01:00

2.6 KiB

Raw Blame History

Registries

Woodpecker provides the ability to add container registries in the settings of your repository. Adding a registry allows you to authenticate and pull private images from a container registry when using these images as a step inside your pipeline. Using registry credentials can also help you avoid rate limiting when pulling images from public registries.

Images from private registries

You must provide registry credentials in the UI in order to pull private container images defined in your YAML configuration file.

These credentials are never exposed to your steps, which means they cannot be used to push, and are safe to use with pull requests, for example. Pushing to a registry still requires setting credentials for the appropriate plugin.

Example configuration using a private image:

 steps:
   - name: build
+    image: gcr.io/custom/golang
     commands:
       - go build
       - go test

Woodpecker matches the registry hostname to each image in your YAML. If the hostnames match, the registry credentials are used to authenticate to your registry and pull the image. Note that registry credentials are used by the Woodpecker agent and are never exposed to your build containers.

Example registry hostnames:

Image gcr.io/foo/bar has hostname gcr.io
Image foo/bar has hostname docker.io
Image qux.com:8000/foo/bar has hostname qux.com:8000

Example registry hostname matching logic:

Hostname gcr.io matches image gcr.io/foo/bar
Hostname docker.io matches golang
Hostname docker.io matches library/golang
Hostname docker.io matches bradrydzewski/golang
Hostname docker.io matches bradrydzewski/golang:latest

Global registry support

To make a private registry globally available, check the server configuration docs.

GCR registry support

For specific details on configuring access to Google Container Registry, please view the docs here.

Local Images

:::warning For this, privileged rights are needed only available to admins. In addition, this only works when using a single agent. :::

It's possible to build a local image by mounting the docker socket as a volume.

With a Dockerfile at the root of the project:

steps:
  - name: build-image
    image: docker
    commands:
      - docker build --rm -t local/project-image .
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock

  - name: build-project
    image: local/project-image
    commands:
      - ./build.sh

2.6 KiB Raw Blame History