이 콘텐츠는 선택한 언어로 제공되지 않습니다.
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
- Open the Config Tool for your Red Hat Quay cluster.
Scroll down to the section entitled Dockerfile Build Support.
- Check the Enable Dockerfile Build box. You are prompted to Enable different types of build triggers.
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.
- Click "Save Configuration Changes"
- Restart the container (you will be prompted)
6.2. Setting 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:
Security | Websocket 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.