이 콘텐츠는 선택한 언어로 제공되지 않습니다.

Chapter 6. Automatically building Dockerfiles with build workers


Red Hat Quay supports building Dockerfiles using a set of worker nodes. Build triggers, such as GitHub webhooks can be configured to automatically build new versions of your repositories when new code is committed. This document will walk you through enabling the feature flag and setting up multiple build workers to enable this feature.

6.1. Enabling builds

  1. Open the Config Tool for your Red Hat Quay cluster.
  2. Scroll down to the section entitled Dockerfile Build Support.

    Select Enable Dockerfile Build

  3. Check the Enable Dockerfile Build box. You are prompted to Enable different types of build triggers.
  4. Select the type of build triggers you want to enable: GitHub Build Triggers, BitBucket Build Triggers, or GitLab Build Triggers. Depending on which you enable, you are prompted to further configure those triggers:

    • Enable GitHub Triggers: For the GitHub box, select GitHub Enterprise or GitHub.io. For GitHub Endpoint, provide the http:// or https:// address for the GitHub endpoint. For OAuth Client ID, enter the client ID for your OAuth client. For OAuth Client Secret, enter the secret needed to access the OAuth client.
    • Enable BitBucket Triggers: To use BitBucket triggers to start registry builds, you need a registered BitBucket OAuth application. Then you must enter the OAuth consumer key and OAuth consumer secret here.
    • Enable GitLab Triggers: For GitLab, select GitLab CE/EE or GitLab.com. For GitLab Endpoint, provide the http:// or https:// address for the GitLab endpoint. For Application id, provide the ID for the registered GitLab OAuth application. For Secret, enter the secret associated with the Application id. The callback URL for your Red Hat Quay cluster is provided.
  5. Click "Save Configuration Changes"
  6. Restart the container (you will be prompted)

6.2. Setting up build workers

Set up build workers

One or more build workers will communicate with Red Hat Quay to build new containers when triggered. The machines must have Docker installed and must not be used for any other work. The following procedure needs to be done every time a new worker needs to be added, but it can be automated fairly easily.

6.2.1. Pull the build worker image

Pull down the latest copy of the image. Make sure to pull the version tagged matching your Red Hat Quay version.

# docker pull quay.io/redhat/quay-builder:v3.3.4

6.2.2. Run the build worker image

Run this container on each build worker. Since the worker will be orchestrating docker builds, we need to mount in the docker socket. This orchestration will use a large amount of CPU and need to manipulate the docker images on disk — we recommend that dedicated machines be used for this task.

Use the environment variable SERVER to tell the worker the hostname at which Red Hat Quay is accessible:

SecurityWebsocket Address

Using SSL

wss://your.quayenterprise.dnsname

Without SSL

ws://your.quayenterprise.dnsname

Here’s what the full command looks like:

# docker run --restart on-failure \
  -e SERVER=ws://myquayenterprise \
  --privileged=true \
  -v /var/run/docker.sock:/var/run/docker.sock:Z \
  quay.io/redhat/quay-builder:v3.3.4

When the container starts, each build worker will auto-register and start building containers once a job is triggered and it is assigned to a worker.

If Red Hat Quay is setup to use a SSL certificate that is not globally trusted, for example a self-signed certificate, Red Hat Quay’s public SSL certificates must be mounted onto the quay-builder container’s SSL trust store. An example command to mount a certificate found at the host’s /path/to/ssl/rootCA.pem looks like:

# docker run --restart on-failure \
  -e SERVER=wss://myquayenterprise \
  --privileged=true \
  -v /path/to/ssl/rootCA.pem:/etc/pki/ca-trust/source/anchors/rootCA.pem \
  -v /var/run/docker.sock:/var/run/docker.sock:Z \
  quay.io/redhat/quay-builder:v3.3.4

6.3. Setting up GitHub builds (optional)

If your organization plans to have builds be conducted via pushes to GitHub (or GitHub Enterprise), continue with Creating an OAuth application in GitHub.

Red Hat logoGithubRedditYoutube

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.