3.4. Git 소스


지정하는 경우 입력한 위치에서 소스 코드를 가져옵니다.

인라인 Dockerfile을 제공하는 경우 Git 리포지토리의 contextDir에 Dockerfile을 덮어씁니다.

소스 정의는 BuildConfig에 있는 spec 섹션의 일부입니다.

source:
  git: 1
    uri: "https://github.com/openshift/ruby-hello-world"
    ref: "master"
  contextDir: "app/dir" 2
  dockerfile: "FROM openshift/ruby-22-centos7\nUSER example" 3
1
git 필드에는 소스 코드의 원격 Git 리포지토리에 대한 URI(Uniform Resource Identifier)가 포함되어 있습니다. 특정 Git 참조를 확인하려면 ref 필드의 값을 지정해야 합니다. 유효한 ref는 SHA1 태그 또는 분기 이름이 될 수 있습니다. ref 필드의 기본값은 master 입니다.
2
contextDir 필드를 사용하면 빌드에서 애플리케이션 소스 코드를 찾는 소스 코드 리포지토리 내부의 기본 위치를 덮어쓸 수 있습니다. 애플리케이션이 하위 디렉터리에 있는 경우 이 필드를 사용하여 기본 위치(루트 폴더)를 덮어쓸 수 있습니다.
3
선택적 dockerfile 필드를 제공하는 경우 소스 리포지토리에 있을 수 있는 모든 Dockerfile을 덮어쓰는 Dockerfile이 문자열에 포함되어야 합니다.

ref 필드가 가져오기 요청을 나타내는 경우 시스템은 git fetch 작업을 사용한 후 FETCH_HEAD를 점검합니다.

ref 값을 제공하지 않으면 OpenShift Container Platform에서 부분 복제(--depth=1)를 수행합니다. 이 경우 기본 분기(일반적으로 master)의 최근 커밋과 관련된 파일만 다운로드됩니다. 그러면 리포지토리는 더 빠르게 다운로드되지만 전체 커밋 내역은 다운로드되지 않습니다. 지정된 리포지토리의 기본 분기의 전체 git clone 을 수행하려면 기본 분기 이름(예: main)으로 ref 를 설정합니다.

주의

MITM(Man in the middle) TLS 하이재킹을 수행하거나 프록시 연결을 재암호화하고 있는 프록시를 통과하는 Git 복제 작업이 작동하지 않습니다.

3.4.1. 프록시 사용

프록시를 사용하는 경우에만 Git 리포지토리에 액세스할 수 있는 경우 빌드 구성의 source 섹션에 사용할 프록시를 정의할 수 있습니다. 사용할 HTTP 및 HTTPS 프록시를 둘 다 구성할 수 있습니다. 두 필드 모두 선택 사항입니다. 프록시를 사용할 수 없는 도메인도 NoProxy 필드에 지정할 수 있습니다.

참고

이를 위해서는 소스 URI에서 HTTP 또는 HTTPS 프로토콜을 사용해야 합니다.

source:
  git:
    uri: "https://github.com/openshift/ruby-hello-world"
    ref: "master"
    httpProxy: http://proxy.example.com
    httpsProxy: https://proxy.example.com
    noProxy: somedomain.com, otherdomain.com
참고

파이프라인 전략 빌드의 경우 Jenkins에 대한 Git 플러그인의 현재 제한 사항을 고려할 때 Git 플러그인을 통한 모든 Git 작업은 BuildConfig 에 정의된 HTTP 또는 HTTPS 프록시를 활용하지 않습니다. Git 플러그인은 플러그인 관리자 패널에서 Jenkins UI에 구성된 프록시만 사용합니다. 그런 다음 이 프록시는 모든 작업에서 Jenkins 내의 모든 Git 상호 작용에 사용됩니다.

추가 리소스

  • JenkinsBehindProxy에서 Jenkins UI를 통해 프록시를 구성하는 방법에 대한 지침을 확인할 수 있습니다.

3.4.2. 소스 복제 보안

빌더 Pod는 빌드의 소스로 정의된 모든 Git 리포지토리에 액세스해야 합니다. 소스 복제 보안은 자체 서명되거나 신뢰할 수 없는 SSL 인증서가 있는 프라이빗 리포지토리 또는 리포지토리와 같이 일반적으로 액세스할 수 없는 리포지토리에 대한 액세스 권한을 제공하는 데 사용됩니다.

다음과 같은 소스 복제 보안 구성이 지원됩니다.

  • .gitconfig 파일
  • 기본 인증
  • SSH 키 인증
  • 신뢰할 수 있는 인증 기관
참고

이러한 구성의 조합을 사용하여 특정 요구 사항을 충족할 수도 있습니다.

3.4.2.1. 빌드 구성에 소스 복제 보안 자동 추가

BuildConfig가 생성되면 OpenShift Container Platform에서 소스 복제 보안 참조를 자동으로 채울 수 있습니다. 이 동작을 사용하면 생성된 빌드에서 참조된 보안에 저장된 자격 증명을 자동으로 사용하여 추가 구성없이 원격 Git 리포지토리에 인증할 수 있습니다.

이 기능을 사용하려면 Git 리포지토리 자격 증명이 포함된 보안이 나중에 BuildConfig가 생성되는 네임스페이스에 있어야 합니다. 이 보안에는 build.openshift.io/source-secret-match-uri- 접두사가 있는 주석이 하나 이상 포함되어야 합니다. 이러한 주석의 각 값은 다음과 같이 정의되는 URI(Uniform Resource Identifier) 패턴입니다. 소스 복제 보안 참조 없이 BuildConfig를 생성하고 해당 Git 소스 URI가 보안 주석의 URI 패턴과 일치하는 경우 OpenShift Container Platform은 BuildConfig에 해당 보안에 대한 참조를 자동으로 삽입합니다.

사전 요구 사항

URI 패턴은 다음으로 구성되어야 합니다.

  • 유효 스키마: *://, git://, http://, https:// 또는 ssh://
  • 호스트: *' 또는 유효한 호스트 이름이나 필요한 경우 앞에 *.가 있는 IP 주소
  • 경로: /* 또는 / 뒤에 * 문자를 선택적으로 포함하는 모든 문자

위의 모든 항목에서 * 문자는 와일드카드로 해석됩니다.

중요

URI 패턴은 RFC3986을 준수하는 Git 소스 URI와 일치해야 합니다. URI 패턴에 사용자 이름(또는 암호) 구성 요소를 포함하지 마십시오.

예를 들어 Git 리포지토리 URL에 ssh://git@bitbucket.atlassian.com:7999/ATLASSIAN jira.git을 사용하는 경우 소스 보안을 ssh://bitbucket.atlassian.com:7999/*(ssh://git@bitbucket.atlassian.com:7999/* 아님)로 지정해야 합니다.

$ oc annotate secret mysecret \
    'build.openshift.io/source-secret-match-uri-1=ssh://bitbucket.atlassian.com:7999/*'

프로세스

특정 BuildConfig의 Git URI와 일치하는 보안이 여러 개인 경우 OpenShift Container Platform은 가장 긴 일치 항목이 있는 보안을 선택합니다. 이렇게 하면 다음 예와 같이 기본 덮어쓰기가 가능합니다.

다음 조각은 두 개의 부분적인 소스 복제 보안을 보여줍니다. 첫 번째는 HTTPS를 통해 액세스하는 도메인 mycorp.com의 모든 서버와 일치하고, 두 번째는 서버 mydev1.mycorp.commydev2.mycorp.com에 대한 액세스 권한을 덮어씁니다.

kind: Secret
apiVersion: v1
metadata:
  name: matches-all-corporate-servers-https-only
  annotations:
    build.openshift.io/source-secret-match-uri-1: https://*.mycorp.com/*
data:
  ...
---
kind: Secret
apiVersion: v1
metadata:
  name: override-for-my-dev-servers-https-only
  annotations:
    build.openshift.io/source-secret-match-uri-1: https://mydev1.mycorp.com/*
    build.openshift.io/source-secret-match-uri-2: https://mydev2.mycorp.com/*
data:
  ...
  • 다음을 사용하여 기존 보안에 build.openshift.io/source-secret-match-uri- 주석을 추가합니다.

    $ oc annotate secret mysecret \
        'build.openshift.io/source-secret-match-uri-1=https://*.mycorp.com/*'

3.4.2.2. 수동으로 소스 복제 보안 추가

소스 복제 보안은 BuildConfig 내부의 source 필드에 sourceSecret 필드를 추가한 후 사용자가 생성한 보안의 이름으로 설정하는 방식으로 빌드 구성에 수동으로 추가할 수 있습니다. 다음 예에서는 basicsecret입니다.

apiVersion: "build.openshift.io/v1"
kind: "BuildConfig"
metadata:
  name: "sample-build"
spec:
  output:
    to:
      kind: "ImageStreamTag"
      name: "sample-image:latest"
  source:
    git:
      uri: "https://github.com/user/app.git"
    sourceSecret:
      name: "basicsecret"
  strategy:
    sourceStrategy:
      from:
        kind: "ImageStreamTag"
        name: "python-33-centos7:latest"

프로세스

oc set build-secret 명령을 사용하여 기존 빌드 구성에 소스 복제 보안을 설정할 수도 있습니다.

  • 기존 빌드 구성에 소스 복제 보안을 설정하려면 다음 명령을 입력합니다.

    $ oc set build-secret --source bc/sample-build basicsecret

3.4.2.3. .gitconfig 파일에서 보안 생성

애플리케이션 복제에서 .gitconfig 파일을 사용하는 경우 이 파일을 포함하는 보안을 생성할 수 있습니다. 빌더 서비스 계정에 추가한 다음 BuildConfig에 추가합니다.

프로세스

  • .gitconfig 파일에서 보안을 생성하려면 다음을 수행합니다.
$ oc create secret generic <secret_name> --from-file=<path/to/.gitconfig>
참고

.gitconfig 파일의 http 섹션에 sslVerify=false가 설정되어 있는 경우 SSL 확인을 해제할 수 있습니다.

[http]
        sslVerify=false

3.4.2.4. 보안 Git의 .gitconfig 파일에서 보안 생성

Git 서버가 양방향 SSL과 사용자 이름 및 암호로 보호되는 경우 소스 빌드에 인증서 파일을 추가하고 .gitconfig 파일의 인증서 파일에 참조를 추가해야 합니다.

사전 요구 사항

  • Git 자격 증명이 있어야 합니다.

프로세스

소스 빌드에 인증서 파일을 추가하고 .gitconfig 파일의 인증서 파일에 대한 참조를 추가합니다.

  1. 애플리케이션 소스 코드의 /var/run/secrets/openshift.io/source/ 폴더에 client.crt, cacert.crt, client.key 파일을 추가합니다.
  2. 서버의 .gitconfig 파일에서 다음 예에 표시된 [http] 섹션을 추가합니다.

    # cat .gitconfig

    출력 예

    [user]
            name = <name>
            email = <email>
    [http]
            sslVerify = false
            sslCert = /var/run/secrets/openshift.io/source/client.crt
            sslKey = /var/run/secrets/openshift.io/source/client.key
            sslCaInfo = /var/run/secrets/openshift.io/source/cacert.crt

  3. 보안을 생성합니다.

    $ oc create secret generic <secret_name> \
    --from-literal=username=<user_name> \ 1
    --from-literal=password=<password> \ 2
    --from-file=.gitconfig=.gitconfig \
    --from-file=client.crt=/var/run/secrets/openshift.io/source/client.crt \
    --from-file=cacert.crt=/var/run/secrets/openshift.io/source/cacert.crt \
    --from-file=client.key=/var/run/secrets/openshift.io/source/client.key
    1
    사용자의 Git 사용자 이름입니다.
    2
    이 사용자의 암호입니다.
중요

암호를 다시 입력하지 않으려면 빌드에서 S2I(Source-to-Image) 이미지를 지정해야 합니다. 그러나 리포지토리를 복제할 수 없는 경우 빌드를 승격하려면 사용자 이름과 암호를 계속 지정해야 합니다.

추가 리소스

  • 애플리케이션 소스 코드의 /var/run/secrets/openshift.io/source/ 폴더입니다.

3.4.2.5. 소스 코드 기본 인증에서 보안 생성

기본 인증에는 --username--password의 조합 또는 SCM(소프트웨어 구성 관리) 서버에 대해 인증하는 토큰이 필요합니다.

사전 요구 사항

  • 개인 리포지토리에 액세스할 수 있는 사용자 이름 및 암호입니다.

프로세스

  1. 먼저 보안을 생성한 후 --username--password를 사용하여 개인 리포지토리에 액세스합니다.

    $ oc create secret generic <secret_name> \
        --from-literal=username=<user_name> \
        --from-literal=password=<password> \
        --type=kubernetes.io/basic-auth
  2. 토큰을 사용하여 기본 인증 보안을 생성합니다.

    $ oc create secret generic <secret_name> \
        --from-literal=password=<token> \
        --type=kubernetes.io/basic-auth

3.4.2.6. 소스 코드 SSH 키 인증에서 보안 생성

SSH 키 기반 인증에는 개인 SSH 키가 필요합니다.

리포지토리 키는 일반적으로 $HOME/.ssh/ 디렉터리에 있으며 기본적으로 이름이 id_dsa.pub, id_ecdsa.pub, id_ed25519.pub 또는 id_rsa.pub입니다.

프로세스

  1. SSH 키 자격 증명을 생성합니다.

    $ ssh-keygen -t ed25519 -C "your_email@example.com"
    참고

    SSH 키의 암호를 생성하면 OpenShift Container Platform이 빌드되지 않습니다. 암호를 입력하라는 메시지가 표시되면 비워 두십시오.

    두 파일(공개 키 및 해당 개인 키(id_dsa, id_ecdsa, id_ed25519 또는 id_rsa))이 생성됩니다. 두 파일이 모두 있는 상태에서 공개 키를 업로드하는 방법에 대한 SCM(소스 제어 관리) 시스템의 설명서를 참조하십시오. 개인 키는 개인 리포지토리에 액세스하는 데 사용됩니다.

  2. SSH 키를 사용하여 개인 리포지토리에 액세스하기 전에 보안을 생성합니다.

    $ oc create secret generic <secret_name> \
        --from-file=ssh-privatekey=<path/to/ssh/private/key> \
        --from-file=<path/to/known_hosts> \ 1
        --type=kubernetes.io/ssh-auth
    1
    선택 사항: 이 필드를 추가하면 엄격한 서버 호스트 키 확인이 가능합니다.
    주의

    시크릿을 생성하는 동안 known_hosts 파일을 건너뛰면 잠재적인 MIT(man-in-the-middle) 공격에 빌드가 취약해집니다.

    참고

    known_hosts 파일에 소스 코드 호스트의 항목이 포함되어 있는지 확인합니다.

3.4.2.7. 신뢰할 수 있는 소스 코드 인증 기관에서 보안 생성

Git 복제 작업 중 신뢰할 수 있는 일련의 TLS(Transport Layer Security) CA(인증 기관)가 OpenShift Container Platform 인프라 이미지로 빌드됩니다. Git 서버에서 자체 서명된 인증서 또는 이미지에서 신뢰할 수 없는 인증 기관에서 서명한 인증서를 사용하는 경우 인증서가 포함된 보안을 생성하거나 TLS 확인을 비활성화할 수 있습니다.

CA 인증서에 대한 보안을 생성하는 경우 OpenShift Container Platform에서는 Git 복제 작업 중 Git 서버에 액세스합니다. 이 방법을 사용하면 제공되는 모든 TLS 인증서를 허용하는 Git SSL 확인을 비활성화하는 것보다 더 안전합니다.

프로세스

CA 인증서 파일을 사용하여 보안을 생성합니다.

  1. CA에서 중간 인증 기관을 사용하는 경우 ca.crt 파일의 모든 CA 인증서를 결합합니다. 다음 명령을 실행합니다.

    $ cat intermediateCA.crt intermediateCA.crt rootCA.crt > ca.crt
    1. 보안을 생성합니다.

      $ oc create secret generic mycert --from-file=ca.crt=</path/to/file> 1
      1
      키 이름으로 ca.crt를 사용해야 합니다.

3.4.2.8. 소스 보안 조합

특정 요구 사항에 맞는 소스 복제 보안을 생성하기 위해 다양한 방법을 결합할 수 있습니다.

3.4.2.8.1. .gitconfig 파일을 사용하여 SSH 기반 인증 보안 생성

다양한 방법을 결합하여 특정 요구 사항에 맞는 소스 복제 보안을 생성할 수 있습니다(예: .gitconfig 파일을 사용하는 SSH 기반 인증 보안).

사전 요구 사항

  • SSH 인증
  • .gitconfig 파일

프로세스

  • .gitconfig 파일을 사용하여 SSH 기반 인증 보안을 생성하려면 다음을 실행합니다.

    $ oc create secret generic <secret_name> \
        --from-file=ssh-privatekey=<path/to/ssh/private/key> \
        --from-file=<path/to/.gitconfig> \
        --type=kubernetes.io/ssh-auth
3.4.2.8.2. .gitconfig 파일 및 CA 인증서를 결합하는 보안 생성

다양한 방법을 결합하여 특정 요구 사항에 맞는 소스 복제 보안을 생성할 수 있습니다(예: .gitconfig 파일 및 CA(인증 기관) 인증서를 결합하는 보안).

사전 요구 사항

  • .gitconfig 파일
  • CA 인증서

프로세스

  • .gitconfig 파일 및 CA 인증서를 결합하는 보안을 생성하려면 다음을 실행합니다.

    $ oc create secret generic <secret_name> \
        --from-file=ca.crt=<path/to/certificate> \
        --from-file=<path/to/.gitconfig>
3.4.2.8.3. CA 인증서를 사용하여 기본 인증 보안 생성

다양한 방법을 결합하여 특정 요구 사항에 맞는 소스 복제 보안을 생성할 수 있습니다(예: 기본 인증 및 CA(인증 기관) 인증서를 결합하는 보안).

사전 요구 사항

  • 기본 인증 자격 증명
  • CA 인증서

프로세스

  • CA 인증서로 기본 인증 보안을 생성하려면 다음을 실행합니다.

    $ oc create secret generic <secret_name> \
        --from-literal=username=<user_name> \
        --from-literal=password=<password> \
        --from-file=ca-cert=</path/to/file> \
        --type=kubernetes.io/basic-auth
3.4.2.8.4. .gitconfig 파일을 사용하여 기본 인증 보안 생성

다양한 방법을 결합하여 특정 요구 사항에 맞는 소스 복제 보안을 생성할 수 있습니다(예: 기본 인증 및 .gitconfig 파일을 결합하는 보안 ).

사전 요구 사항

  • 기본 인증 자격 증명
  • .gitconfig 파일

프로세스

  • .gitconfig 파일을 사용하여 기본 인증 보안을 생성하려면 다음을 실행합니다.

    $ oc create secret generic <secret_name> \
        --from-literal=username=<user_name> \
        --from-literal=password=<password> \
        --from-file=</path/to/.gitconfig> \
        --type=kubernetes.io/basic-auth
3.4.2.8.5. .gitconfig 파일 및 CA 인증서를 사용하여 기본 인증 보안 생성

다양한 방법을 결합하여 특정 요구 사항에 맞는 소스 복제 보안을 생성할 수 있습니다(예: 기본 인증, .gitconfig 파일, CA(인증 기관) 인증서를 결합하는 보안).

사전 요구 사항

  • 기본 인증 자격 증명
  • .gitconfig 파일
  • CA 인증서

프로세스

  • .gitconfig 파일 및 CA 인증서를 사용하여 기본 인증 보안을 생성하려면 다음을 실행합니다.

    $ oc create secret generic <secret_name> \
        --from-literal=username=<user_name> \
        --from-literal=password=<password> \
        --from-file=</path/to/.gitconfig> \
        --from-file=ca-cert=</path/to/file> \
        --type=kubernetes.io/basic-auth
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.