8장. 빌드 트리거 및 수정
다음 섹션에서는 빌드 후크를 사용하여 빌드를 트리거하고 수정하는 방법을 간략하게 설명합니다.
8.1. 빌드 트리거
BuildConfig
를 정의할 때 BuildConfig
를 실행해야 하는 상황을 제어하기 위해 트리거를 정의할 수 있습니다. 다음과 같은 빌드 트리거를 사용할 수 있습니다.
- Webhook
- 이미지 변경
- 구성 변경
8.1.1. Webhook 트리거
Webhook 트리거를 사용하면 OpenShift Container Platform API 끝점에 요청을 전송하여 새 빌드를 트리거할 수 있습니다. 이러한 트리거는 GitHub, GitLab, Bitbucket 또는 Generic Webhook를 사용하여 정의할 수 있습니다.
현재는 OpenShift Container Platform Webhook에서 Git 기반 SCM(소스 코드 관리) 시스템 각각에 대해 유사한 버전의 내보내기 이벤트만 지원합니다. 기타 모든 이벤트 유형은 무시됩니다.
내보내기 이벤트가 처리되면 OpenShift Container Platform 컨트롤 플레인 호스트 (마스터 호스트라고도 함)에서 이벤트 내부의 분기 참조가 해당 BuildConfig
의 분기 참조와 일치하는지 확인합니다. 일치하는 경우 OpenShift Container Platform 빌드의 Webhook 이벤트에 언급된 커밋 참조가 정확한지 확인합니다. 일치하지 않는 경우에는 빌드가 트리거되지 않습니다.
oc new-app
및 oc new-build
는 GitHub 및 Generic Webhook 트리거를 자동으로 생성하지만 필요한 다른 Webhook 트리거는 수동으로 추가해야 합니다. 트리거 설정을 통해 트리거를 수동으로 추가할 수 있습니다.
모든 Webhook에 대해 WebHookSecretKey
라는 키와 Webhook를 호출할 때 제공할 값이 되는 값을 사용하여 보안을 정의해야 합니다. 그런 다음 Webhook 정의에서 보안을 참조해야 합니다. 보안을 사용하면 URL의 고유성이 보장되어 다른 사용자가 빌드를 트리거할 수 없습니다. 키 값은 Webhook 호출 중 제공되는 보안과 비교됩니다.
예를 들면 아래 예제에는 mysecret
이라는 보안에 대한 참조가 포함된 GitHub Webhook가 있습니다.
type: "GitHub" github: secretReference: name: "mysecret"
그런 다음 보안이 다음과 같이 정의됩니다. 보안 값은 Secret
오브젝트의 data
필드에 필요하므로 base64로 인코딩됩니다.
- kind: Secret apiVersion: v1 metadata: name: mysecret creationTimestamp: data: WebHookSecretKey: c2VjcmV0dmFsdWUx
8.1.1.1. GitHub Webhook 사용
GitHub Webhook는 리포지토리를 업데이트할 때 GitHub에서 생성하는 호출을 처리합니다. 트리거를 정의할 때는 보안을 지정해야 하는데, 보안은 Webhook를 구성할 때 GitHub에 제공하는 URL의 일부입니다.
GitHub Webhook 정의의 예:
type: "GitHub" github: secretReference: name: "mysecret"
Webhook 트리거 구성에 사용되는 보안은 GitHub UI에서 Webhook를 구성할 때 표시되는 secret
필드와 동일하지 않습니다. 전자는 Webhook URL을 고유하고 예측하기 어렵게 만들고, 후자는 X-Hub-Signature
헤더로 전송되는 본문의 HMAC 16진수 다이제스트를 생성하는 데 사용되는 선택적 문자열 필드입니다.
페이로드 URL은 oc describe
명령에 의해 GitHub Webhook URL로 반환되고(Webhook URL 표시 참조) 다음과 같이 구성됩니다.
출력 예
https://<openshift_api_host:port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/github
사전 요구 사항
-
GitHub 리포지토리에서
BuildConfig
를 생성합니다.
프로세스
GitHub Webhook를 구성하려면 다음을 수행합니다.
GitHub 리포지토리에서
BuildConfig
를 생성한 후 다음을 실행합니다.$ oc describe bc/<name-of-your-BuildConfig>
그러면 다음과 같은 Webhook GitHub URL이 생성됩니다.
출력 예
<https://api.starter-us-east-1.openshift.com:443/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/github
- GitHub 웹 콘솔에서 이 URL을 잘라내어 GitHub에 붙여넣습니다.
-
GitHub 리포지토리의 설정
Webhook에서 Webhook 추가를 선택합니다. - URL 출력을 페이로드 URL 필드에 붙여넣습니다.
-
GitHub의 기본
application/x-www-form-urlencoded
에서 콘텐츠 유형을application/json
으로 변경합니다. Webhook 추가를 클릭합니다.
GitHub에서 Webhook가 성공적으로 구성되었음을 알리는 메시지가 표시됩니다.
이제 GitHub 리포지토리에 변경 사항을 내보내면 새 빌드가 자동으로 시작되고 빌드가 성공하면 새 배포가 시작됩니다.
참고Gogs는 GitHub와 동일한 Webhook 페이로드 형식을 지원합니다. 따라서 Gogs 서버를 사용하는 경우
BuildConfig
에 GitHub Webhook 트리거를 정의하고 Gogs 서버에서도 트리거할 수 있습니다.
payload.json
과 같이 유효한 JSON 페이로드가 포함된 파일의 경우curl
을 사용하여 Webhook를 수동으로 트리거할 수 있습니다.$ curl -H "X-GitHub-Event: push" -H "Content-Type: application/json" -k -X POST --data-binary @payload.json https://<openshift_api_host:port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/github
-k
인수는 API 서버에 올바르게 서명된 인증서가 없는 경우에만 필요합니다.
추가 리소스
8.1.1.2. GitLab Webhook 사용
GitLab Webhook는 리포지토리를 업데이트할 때 GitLab에서 생성하는 호출을 처리합니다. GitHub 트리거와 마찬가지로 보안을 지정해야 합니다. 다음 예제는 BuildConfig
내의 트리거 정의 YAML입니다.
type: "GitLab" gitlab: secretReference: name: "mysecret"
페이로드 URL은 oc describe
명령을 통해 GitLab Webhook URL로 반환되고 다음과 같이 구조화됩니다.
출력 예
https://<openshift_api_host:port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/gitlab
프로세스
GitLab Webhook를 구성하려면 다음을 수행합니다.
Webhook URL을 가져오도록
BuildConfig
를 지정합니다.$ oc describe bc <name>
-
Webhook URL을 복사하여
<secret>
을 보안 값으로 교체합니다. - GitLab 설정 지침에 따라 Webhook URL을 GitLab 리포지토리 설정에 붙여넣습니다.
payload.json
과 같이 유효한 JSON 페이로드가 포함된 파일의 경우curl
을 사용하여 Webhook를 수동으로 트리거할 수 있습니다.$ curl -H "X-GitLab-Event: Push Hook" -H "Content-Type: application/json" -k -X POST --data-binary @payload.json https://<openshift_api_host:port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/gitlab
-k
인수는 API 서버에 올바르게 서명된 인증서가 없는 경우에만 필요합니다.
8.1.1.3. Bitbucket Webhook 사용
Bitbucket Webhook는 리포지토리가 업데이트될 때 Bitbucket에서 만든 호출을 처리합니다. 이전 트리거와 유사하게 보안을 지정해야 합니다. 다음 예제는 BuildConfig
내의 트리거 정의 YAML입니다.
type: "Bitbucket" bitbucket: secretReference: name: "mysecret"
페이로드 URL은 oc describe
명령을 통해 Bitbucket Webhook URL로 반환되고 다음과 같이 구조화됩니다.
출력 예
https://<openshift_api_host:port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/bitbucket
프로세스
Bitbucket Webhook를 구성하려면 다음을 수행합니다.
Webhook URL을 가져오도록 'BuildConfig'를 지정합니다.
$ oc describe bc <name>
-
Webhook URL을 복사하여
<secret>
을 보안 값으로 교체합니다. - Bitbucket 설정 지침에 따라 Webhook URL을 Bitbucket 리포지토리 설정에 붙여넣습니다.
payload.json
과 같이 유효한 JSON 페이로드가 포함된 파일의 경우curl
을 사용하여 Webhook를 수동으로 트리거할 수 있습니다.$ curl -H "X-Event-Key: repo:push" -H "Content-Type: application/json" -k -X POST --data-binary @payload.json https://<openshift_api_host:port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/bitbucket
-k
인수는 API 서버에 올바르게 서명된 인증서가 없는 경우에만 필요합니다.
8.1.1.4. 일반 Webhook 사용
일반 Webhook는 웹 요청을 수행할 수 있는 모든 시스템에서 호출합니다. 다른 Webhook와 마찬가지로 보안을 지정해야 하는데 보안은 호출자가 빌드를 트리거하는 데 사용해야 하는 URL의 일부입니다. 보안을 사용하면 URL의 고유성이 보장되어 다른 사용자가 빌드를 트리거할 수 없습니다. 다음은 BuildConfig
내 트리거 정의 YAML의 예입니다.
type: "Generic"
generic:
secretReference:
name: "mysecret"
allowEnv: true 1
- 1
- 일반 Webhook에서 환경 변수를 전달하도록 허용하려면
true
로 설정합니다.
프로세스
호출자를 설정하기 위해 빌드에 대한 일반 Webhook 끝점의 URL을 호출 시스템에 제공합니다.
출력 예
https://<openshift_api_host:port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/generic
호출자는 Webhook를
POST
작업으로 호출해야 합니다.Webhook를 수동으로 호출하려면
curl
을 사용하면 됩니다.$ curl -X POST -k https://<openshift_api_host:port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/generic
HTTP 동사를
POST
로 설정해야 합니다. 비보안-k
플래그는 인증서 검증을 무시하도록 지정됩니다. 클러스터에 올바르게 서명된 인증서가 있는 경우 이 두 번째 플래그는 필요하지 않습니다.끝점은 다음 형식을 사용하여 선택적 페이로드를 허용할 수 있습니다.
git: uri: "<url to git repository>" ref: "<optional git reference>" commit: "<commit hash identifying a specific git commit>" author: name: "<author name>" email: "<author e-mail>" committer: name: "<committer name>" email: "<committer e-mail>" message: "<commit message>" env: 1 - name: "<variable name>" value: "<variable value>"
- 1
BuildConfig
환경 변수와 유사하게 여기에 정의된 환경 변수도 빌드에 사용할 수 있습니다. 이러한 변수가BuildConfig
환경 변수와 충돌하는 경우 해당 변수가 우선합니다. 기본적으로 Webhook에서 전달하는 환경 변수는 무시됩니다. 이 동작을 활성화하려면 Webhook 정의에서allowEnv
필드를true
로 설정합니다.
curl
을 사용하여 이 페이로드를 전달하려면payload_file.yaml
이라는 파일에 페이로드를 정의하고 다음을 실행합니다.$ curl -H "Content-Type: application/yaml" --data-binary @payload_file.yaml -X POST -k https://<openshift_api_host:port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/generic
인수는 위 예제와 동일하고 헤더와 페이로드가 추가되었습니다.
-H
인수는 페이로드 형식에 따라Content-Type
헤더를application/yaml
또는application/json
으로 설정합니다.--data-binary
인수는POST
요청을 사용하여 온전한 새 줄로 바이너리 페이로드를 보내는 데 사용됩니다.
OpenShift Container Platform에서는 유효하지 않은 요청 페이로드(예: 유효하지 않은 콘텐츠 유형, 구문 분석할 수 없거나 유효하지 않은 콘텐츠 등)가 제공되는 경우에도 일반 Webhook에서 빌드를 트리거할 수 있습니다. 이 동작은 이전 버전과의 호환성을 위해 유지됩니다. 유효하지 않은 요청 페이로드가 제공되면 OpenShift Container Platform에서 HTTP 200 OK
응답의 일부로 JSON 형식의 알림을 반환합니다.
8.1.1.5. Webhook URL 표시
다음 명령을 사용하여 빌드 구성과 관련된 Webhook URL을 표시할 수 있습니다. 이 명령에서 Webhook URL을 표시하지 않으면 해당 빌드 구성에 Webhook 트리거가 정의되지 않습니다.
프로세스
-
BuildConfig
와 관련된 Webhook URL을 표시하려면 다음을 실행합니다.
$ oc describe bc <name>
8.1.2. 이미지 변경 트리거 사용
이미지 변경 트리거를 사용하면 새 버전의 업스트림 이미지가 준비될 때 빌드가 자동으로 호출됩니다. 예를 들어 빌드가 RHEL 이미지를 기반으로 하는 경우 RHEL 이미지가 변경될 때마다 해당 빌드를 트리거하여 실행할 수 있습니다. 결과적으로 애플리케이션 이미지는 항상 최신 RHEL 기본 이미지에서 실행됩니다.
v1 컨테이너 레지스트리의 컨테이너 이미지를 가리키는 이미지 스트림은 이미지 스트림 태그를 사용할 수 있을 때 빌드를 한 번만 트리거하고 후속 이미지 업데이트에서는 빌드를 트리거하지 않습니다. 이는 v1 컨테이너 레지스트리에서 고유하게 확인할 수 있는 이미지가 없기 때문입니다.
프로세스
이미지 변경 트리거를 구성하려면 다음 작업을 수행해야 합니다.
트리거하려는 업스트림 이미지를 가리키는
ImageStream
을 정의합니다.kind: "ImageStream" apiVersion: "v1" metadata: name: "ruby-20-centos7"
이는
<system-registry>_/<namespace>/ruby-20-centos7
에 있는 컨테이너 이미지 리포지토리에 연결된 이미지 스트림을 정의합니다.<system-registry>
는 OpenShift Container Platform에서 실행 중인docker-registry
라는 이름을 사용하여 서비스로 정의됩니다.이미지 스트림이 빌드의 기본 이미지인 경우 빌드 전략의 from 필드를
ImageStream
을 가리키도록 설정합니다.strategy: sourceStrategy: from: kind: "ImageStreamTag" name: "ruby-20-centos7:latest"
이 경우
sourceStrategy
정의에서는 이 네임스페이스 내에 있는ruby-20-centos7
이라는 이미지 스트림의latest
태그를 사용합니다.ImageStreams
를 가리키는 하나 이상의 트리거를 사용하여 빌드를 정의합니다.type: "ImageChange" 1 imageChange: {} type: "ImageChange" 2 imageChange: from: kind: "ImageStreamTag" name: "custom-image:latest"
전략 이미지 스트림에 이미지 변경 트리거를 사용하는 경우 생성된 빌드에 해당 태그와 일치하는 최신 이미지를 가리키는 변경 불가능한 Docker 태그가 제공됩니다. 이 새 이미지 참조는 빌드에 대해 실행할 때 전략에서 사용합니다.
전략 이미지 스트림을 참조하지 않는 다른 이미지 변경 트리거의 경우 새 빌드가 시작되지만 빌드 전략은 고유 이미지 참조로 업데이트되지 않습니다.
이 예제에는 전략에 대한 이미지 변경 트리거가 있으므로 결과 빌드는 다음과 같습니다.
strategy: sourceStrategy: from: kind: "DockerImage" name: "172.30.17.3:5001/mynamespace/ruby-20-centos7:<immutableid>"
그 결과 트리거된 빌드는 리포지토리로 방금 푸시된 새 이미지를 사용하고 동일한 입력을 사용하여 빌드를 다시 실행할 수 있습니다.
이미지 변경 트리거를 일시 정지하여 빌드를 시작하기 전에 참조 이미지 스트림에 대한 다양한 변경 사항을 허용할 수 있습니다. 처음에 ImageChangeTrigger
를 BuildConfig
에 추가할 때 빌드가 즉시 트리거되지 않도록 paused
특성을 true로 설정할 수도 있습니다.
type: "ImageChange" imageChange: from: kind: "ImageStreamTag" name: "custom-image:latest" paused: true
모든 Strategy
유형의 이미지 필드를 설정하는 것 외에 사용자 지정 빌드의 경우 OPENSHIFT_CUSTOM_BUILD_BASE_IMAGE
환경 변수도 확인합니다. 존재하지 않는 경우 변경 불가능한 이미지 참조를 사용하여 생성됩니다. 존재하는 경우 변경 불가능한 이미지 참조를 사용하여 업데이트됩니다.
Webhook 트리거 또는 수동 요청으로 인해 빌드가 트리거되는 경우 생성된 빌드는 Strategy
에서 참조한 ImageStream
의 확인된 <immutableid>
를 사용합니다. 그러면 쉽게 재현할 수 있도록 일관된 이미지 태그를 사용하여 빌드를 수행할 수 있습니다.
추가 리소스
8.1.3. 구성 변경 트리거
구성 변경 트리거를 사용하면 새 BuildConfig
가 생성되는 즉시 빌드가 자동으로 호출됩니다.
다음은 BuildConfig
내 트리거 정의 YAML의 예입니다.
type: "ConfigChange"
구성 변경 트리거는 현재 새 BuildConfig
를 생성할 때만 작동합니다. 향후 릴리스에서는 BuildConfig
가 업데이트될 때마다 구성 변경 트리거도 빌드를 시작할 수 있습니다.
8.1.3.1. 트리거 수동 설정
oc set triggers
를 사용하여 빌드 구성에서 트리거를 추가 및 제거할 수 있습니다.
프로세스
빌드 구성에 GitHub Webhook 트리거를 설정하려면 다음을 사용합니다.
$ oc set triggers bc <name> --from-github
이미지 변경 트리거를 설정하려면 다음을 사용합니다.
$ oc set triggers bc <name> --from-image='<image>'
트리거를 제거하려면
--remove
를 추가합니다.$ oc set triggers bc <name> --from-bitbucket --remove
Webhook 트리거가 이미 있는 경우 해당 트리거를 다시 추가하면 Webhook 보안이 다시 생성됩니다.
자세한 내용은 다음을 실행하여 도움말 문서를 참조하십시오.
$ oc set triggers --help