3.2.4. Git에서 코드베이스를 가져와 애플리케이션 생성

프로세스

1. +추가 보기에서 Git 리포지토리 타일의 Git에서 를 클릭하여 Git 에서 가져오기 양식을 확인합니다.
2. Git 섹션에서 애플리케이션을 생성하는 데 사용할 코드베이스의 Git 리포지토리 URL을 입력합니다. 예를 들어 이 샘플 Node.js 애플리케이션의 URL https://github.com/sclorg/nodejs-ex를 입력합니다. 그런 다음 URL을 검증합니다.

3. 선택 사항: 고급 Git 옵션 표시를 클릭하여 다음과 같은 세부 정보를 추가할 수 있습니다.

   • Git 참조: 애플리케이션을 빌드하는 데 사용할 특정 분기의 코드, 태그 또는 커밋을 가리킵니다.
   • 컨텍스트 디렉터리: 애플리케이션을 빌드하는 데 사용할 애플리케이션 소스 코드의 하위 디렉터리를 지정합니다.
   • 소스 시크릿: 프라이빗 리포지토리에서 소스 코드를 가져올 수 있는 자격 증명이 포함된 시크릿 이름을 생성합니다.

4. 선택 사항: Git 리포지토리를 통해 Devfile, Dockerfile,Builder Image 또는 Serverless Function 를 가져와서 배포를 추가로 사용자 지정할 수 있습니다.

   • Git 리포지토리에 Devfile, Dockerfile, Builder Image 또는 func.yaml 이 포함된 경우 해당 경로 필드에 자동으로 감지되고 채워집니다.
   • 동일한 리포지토리에서 Devfile, Dockerfile 또는 Builder Image 가 감지되면 기본적으로 Devfile 이 선택됩니다.
   • Git 리포지토리에서 func.yaml 이 감지되면 가져오기 전략이 Serverless Function 으로 변경됩니다.
   • 또는 Git 리포지토리 URL을 사용하여 +추가 보기에서 Serverless 함수 생성 을 클릭하여 서버리스 함수를 생성할 수 있습니다.
   • 파일 가져오기 유형을 편집하고 다른 전략을 선택하려면 가져오기 전략 편집 옵션을 클릭합니다.
   • 여러 Devfiles , Dockerfile 또는 Builder Images가 감지되면 특정 인스턴스를 가져오려면 컨텍스트 디렉터리를 기준으로 각 경로를 지정합니다.

5. Git URL을 검증하면 권장 빌더 이미지가 선택되고 별표가 표시됩니다. 빌더 이미지가 자동으로 탐지되지 않으면 빌더 이미지를 선택합니다. https://github.com/sclorg/nodejs-ex Git URL의 경우 기본적으로 Node.js 빌더 이미지가 선택됩니다.

   1. 선택 사항: 빌더 이미지 버전 드롭다운을 사용하여 버전을 지정합니다.
   2. 선택 사항: 가져오기 편집 전략을 사용하여 다른 전략을 선택합니다.
   3. 선택 사항: Node.js 빌더 이미지의 경우 Run command 필드를 사용하여 애플리케이션을 실행합니다.

6. 일반 섹션에서 다음을 수행합니다.

   1. 애플리케이션 필드에서 애플리케이션 그룹화에 대한 고유 이름을 입력합니다(예: myapp). 애플리케이션 이름이 네임스페이스에서 고유해야 합니다.

   2. 기존 애플리케이션이 없는 경우 이 애플리케이션에 대해 생성된 리소스를 확인하는 이름 필드는 Git 리포지토리 URL에 따라 자동으로 채워집니다. 기존 애플리케이션이 있는 경우에는 기존 애플리케이션 내에 구성 요소를 배포하거나 새 애플리케이션을 생성하거나 구성 요소를 할당하지 않은 상태로 유지하도록 선택할 수 있습니다.

      참고

      리소스 이름은 네임스페이스에서 고유해야 합니다. 오류가 발생하면 리소스 이름을 수정합니다.

7. 리소스 섹션에서 다음 옵션을 선택합니다.

   • 배포: 일반 Kubernetes 형식으로 애플리케이션을 생성합니다.
   • 배포 구성: OpenShift Container Platform 스타일 애플리케이션을 생성합니다.

   • 서버리스 배포: Knative 서비스를 생성합니다.

     참고

     애플리케이션 가져오기에 대한 기본 리소스 기본 설정을 설정하려면 사용자 환경 설정 애플리케이션 → 리소스 유형 필드로 이동합니다. 서버리스 배포 옵션은 OpenShift Serverless Operator가 클러스터에 설치된 경우에만 Git에서 가져오기 양식에 표시됩니다. 서버리스 기능을 생성하는 동안 리소스 섹션을 사용할 수 없습니다. 자세한 내용은 OpenShift Serverless 설명서를 참조하십시오.

8. 파이프라인 섹션에서 파이프라인 추가를 선택한 다음 파이프라인 시각화 표시를 클릭하여 애플리케이션의 파이프라인을 확인합니다. 기본 파이프라인이 선택되지만 애플리케이션에 사용 가능한 파이프라인 목록에서 원하는 파이프라인을 선택할 수 있습니다.

   참고

   다음 기준이 충족되면 파이프라인 추가 확인란이 선택되고 PAC 구성이 기본적으로 선택됩니다.

   • Pipeline Operator가 설치됨
   • pipelines-as-code 가 활성화됨
   • .tekton 디렉터리는 Git 리포지토리에서 감지됩니다.

9. 리포지토리에 Webhook를 추가합니다. PAC 구성이 선택되어 있고 iGitHub App이 설정된 경우 GitHub App 사용 및 webhook 설정 옵션이 표시됩니다. GitHub 앱이 설정되지 않은 경우 Webhook 설정 옵션만 볼 수 있습니다.

   1. 설정 Webhook로 이동하여 Webhook 추가를 클릭합니다.
   2. Payload URL 을 코드 컨트롤러 공용 URL로 Pipeline으로 설정합니다.
   3. 콘텐츠 유형을 application/json 으로 선택합니다.
   4. 웹 후크 시크릿을 추가하고 대체 위치에서 기록해 둡니다. 로컬 시스템에 openssl 을 설치하면 임의의 보안을 생성합니다.
   5. 개별 이벤트 선택을 클릭하고 Commit comments,Issue comments,Pull request, Pushes 이벤트를 선택합니다.
   6. Webhook 추가를 클릭합니다.

10. 선택 사항: 고급 옵션 섹션에서 대상 포트 및 애플리케이션에 대한 경로 생성 은 공개적으로 사용 가능한 URL을 사용하여 애플리케이션에 액세스할 수 있도록 기본적으로 선택됩니다.

    애플리케이션이 기본 공용 포트인 80에 데이터를 노출하지 않으면 확인란을 지우고 노출하려는 대상 포트 번호를 설정합니다.

11. 선택 사항: 다음 고급 옵션을 사용하여 애플리케이션을 추가로 사용자 지정할 수 있습니다.

    라우팅

    라우팅 링크를 클릭하면 다음 작업을 수행할 수 있습니다.

    • 경로의 호스트 이름을 사용자 지정합니다.
    • 라우터에서 감시하는 경로를 지정합니다.
    • 드롭다운 목록에서 트래픽의 대상 포트를 선택합니다.

    • Secure Route 확인란을 선택하여 경로를 보호합니다. 필요한 TLS 종료 유형을 선택하고 해당 드롭다운 목록에서 안전하지 않은 트래픽에 대한 정책을 설정합니다.

      참고

      서버리스 애플리케이션의 경우 Knative 서비스에서 위의 모든 라우팅 옵션을 관리합니다. 그러나 필요한 경우 트래픽에 대한 대상 포트를 사용자 지정할 수 있습니다. 대상 포트를 지정하지 않으면 기본 포트 8080이 사용됩니다.

    도메인 매핑

    서버리스 배포 를 생성하는 경우 생성하는 동안 Knative 서비스에 사용자 정의 도메인 매핑을 추가할 수 있습니다.

    • 고급 옵션 섹션에서 고급 라우팅 옵션 표시를 클릭합니다.

      • 서비스에 매핑하려는 도메인 매핑 CR이 이미 존재하는 경우 도메인 매핑 드롭다운 메뉴에서 선택할 수 있습니다.
      • 새 도메인 매핑 CR을 생성하려면 도메인 이름을 상자에 입력하고 만들기 옵션을 선택합니다. 예를 들어 example.com 을 입력하는 경우 만들기 옵션은 Create "example.com" 입니다.

    상태 점검

    애플리케이션에 준비 상태, 활성 상태, 시작 프로브를 추가하려면 상태 점검 링크를 클릭합니다. 모든 프로브에는 기본 데이터가 미리 채워져 있습니다. 기본 데이터가 포함된 프로브를 추가하거나 필요에 따라 사용자 지정할 수 있습니다.

    상태 프로브를 사용자 지정하려면 다음을 수행합니다.

    • 필요한 경우 준비 상태 프로브 추가를 클릭하여 컨테이너에서 요청을 처리할 준비가 되었는지 확인하도록 매개변수를 수정하고 확인 표시를 선택하여 프로브를 추가합니다.
    • 필요한 경우 활성 상태 프로브 추가를 클릭하여 컨테이너가 아직 실행되고 있는지 확인하도록 매개변수를 수정하고 확인 표시를 선택하여 프로브를 추가합니다.

    • 필요한 경우 시작 프로브 추가를 클릭하여 컨테이너 내 애플리케이션이 시작되었는지 확인하도록 매개변수를 수정하고 확인 표시를 선택하여 프로브를 추가합니다.

      각 프로브의 드롭다운 목록에서 요청 유형을 HTTP GET, 컨테이너 명령 또는 TCP 소켓으로 지정할 수 있습니다. 선택한 요청 유형에 따라 양식이 변경됩니다. 그런 다음 기타 매개변수(예: 프로브의 성공 및 실패 임계값, 컨테이너를 시작한 후 첫 번째 프로브를 수행할 때까지의 시간(초), 프로브 빈도, 시간 제한 값)에 대한 기본값을 수정할 수 있습니다.

    빌드 구성 및 배포

    빌드 구성 및 배포 링크를 클릭하여 해당 구성 옵션을 확인합니다. 일부 옵션은 기본적으로 선택되어 있습니다. 필요한 트리거 및 환경 변수를 추가하여 추가로 사용자 지정할 수 있습니다.

    서버리스 애플리케이션의 경우 Knative 구성 리소스가 DeploymentConfig 리소스 대신 배포에 필요한 상태를 유지 관리하므로 배포 옵션이 표시되지 않습니다.

    스케일링

    처음에 배포할 애플리케이션의 Pod 수 또는 인스턴스 수를 정의하려면 스케일링 링크를 클릭합니다.

    서버리스 배포를 생성하는 경우 다음 설정을 구성할 수도 있습니다.

    • min Pod 는 Knative 서비스에 대해 지정된 시간에 실행해야 하는 Pod 수의 하한값을 결정합니다. 이를 minScale 설정이라고도 합니다.
    • Max Pod 는 Knative 서비스에 대해 지정된 시간에 실행할 수 있는 Pod 수의 상한을 결정합니다. 이는 maxScale 설정이라고도 합니다.
    • 동시성 대상 에서는 지정된 시간에 애플리케이션의 각 인스턴스에 대해 원하는 동시 요청 수를 결정합니다.
    • 동시성 제한은 지정된 시간에 애플리케이션의 각 인스턴스에 허용되는 동시 요청 수에 대한 제한을 결정합니다.
    • 동시성 사용률 에 따라 Knative가 추가 트래픽을 처리하기 위해 추가 Pod를 확장하기 전에 충족해야 하는 동시 요청 제한의 백분율이 결정됩니다.
    • autoscale 창은 자동 스케일러가 패닉 모드가 아닌 경우 스케일링 결정에 대한 입력을 제공하기 위해 평균되는 시간 창을 정의합니다. 이 창에서 요청을 수신하지 않으면 서비스가 축소됩니다. 자동 스케일링 창의 기본 기간은 60s 입니다. 이를 안정적인 창이라고도 합니다.

    리소스 제한

    컨테이너 실행 시 컨테이너에서 사용하도록 보장하거나 허용하는 CPU 및 메모리 리소스의 양을 설정하려면 리소스 제한 링크를 클릭합니다.

    라벨

    라벨 링크를 클릭하여 애플리케이션에 사용자 정의 라벨을 추가합니다.

12. 생성 을 클릭하여 애플리케이션을 생성하고 성공 알림이 표시됩니다. 토폴로지 보기에서 애플리케이션의 빌드 상태를 확인할 수 있습니다.