빌드 중 메모리 한계에 대한 해결 방법

해결 정보는 메모리 한계가 초과되면 빌드 실패를 참조하십시오.

빌드 중 컨테이너 레지스트리 문제점에 대한 해결 방법

이 시나리오에서는 컨테이너 레지스트리에 액세스할 수 있는 레지스트리 암호가 존재하지 않거나 암호가 올바르지 않습니다.

1. 사용된 시크릿을 판별하십시오. 명령을 사용하여 ibmcloud ce build get 명령을 사용하여 사용된 레지스트리 암호를 표시합니다.

2. .dockerconfigjson 키가 있는지 여부를 판별하십시오. 레지스트리 시크릿에 대해 ibmcloud ce secret get 명령을 사용하십시오. 시크릿 데이터는 base64로 인코딩되며 직접 볼 수는 없습니다. 그러나 시크릿에는 인증 정보가 포함되어 있습니다. 명령 출력에서 Data 섹션을 확인하십시오. .dockerconfigjson 키가 포함되어 있어야 합니다. .dockerconfigjson 키가 표시되지 않은 경우 컨테이너 레지스트리로 인증하는 데 이 시크릿이 적합하지 않으므로 올바른 시크릿을 작성하고 빌드에서 참조해야 합니다. 자세한 정보는 개인용 컨테이너 레지스트리에 대한 액세스 권한 추가를 참조하십시오.

   출력 예

   $ ibmcloud code-engine secret get -n <REGISTRY_SECRET>
   Getting secret <REGISTRY_SECRET>...
   OK
   
   Name:        <REGISTRY_SECRET>
   ID:          <REGISTRY_SECRET_ID>
   Project:     <PROJECT_NAME>
   Project ID:  <PROJECT_NAMESPACE>
   Age:         8s
   Created:     2021-02-12T10:26:59-06:00
   
   Data:
   ---
   .dockerconfigjson: <BASE64_STRING>
   

3. .dockerconfigjson 키가 있는 경우 다음 명령을 사용하여 base64 인코딩 문자열인 키를 디코딩하십시오.

   echo "<BASE64_STRING>" | base64 -d
   {"auths":{"<REGISTRY>":{"username":"<USERNAME>","password":"<PASSWORD>","auth":"<AUTH>"}}}
   

   이 명령의 출력에는 일반적으로 <REGISTRY> 키가 한 개 포함되어 있습니다.

4. 키에 대한 다음 정보를 확인하십시오.

   a. <REGISTRY> 값을 확인하십시오. 이 값은 빌드 이미지와 일치해야 합니다.

   • 이미지 이름이 IBM Cloud Container Registry에 있는 경우(예: us.icr.io/aNamespace/anImage), <REGISTRY>는 us.icr.io여야 합니다.

   • 이미지 이름이 호스트 이름 없이 docker.io/aNamespace/aRepository 또는 /aNamespace/aRepository인 경우 빌드가 Docker Hub를 사용하는 것입니다. 이 경우 <REGISTRY>는 https://index.docker.io/v1/여야 합니다.

   b. <USERNAME> 값을 확인하십시오. 레지스트리가 IBM Cloud Container Registry인 경우 인증에 API 키를 사용해야 합니다. <USERNAME>은 iamapikey이고 비밀번호는 API 키여야 합니다. API 키 작성을 위한 단계는 IBM Cloud Container Registry에 대한 액세스 자동화를 참조하십시오.

   c. 인증 정보의 유효성을 검증해야 합니다. IBM Cloud® Identity and Access Management(IAM)를 사용하면 권한을 세분화된 방식으로 지정할 수 있습니다. 예를 들어 IBM Cloud Container Registry 네임스페이스에 대한 액세스 권한과 이미지 가져오기 권한이 있는 서비스 ID는 이미지를 푸시할 수 없습니다. 그러나 이 경우에는 이 권한이 필요합니다.

5. 필요한 변경사항을 판별한 후 수정된 값을 사용하는 컨테이너 레지스트리 시크릿을 작성하십시오. ibmcloud ce secret create --format 명령을 사용하십시오. 예를 들면, 다음과 같습니다.

   ibmcloud ce secret create --format registry --name <REGISTRY_SECRET> --server <REGISTRY_SERVER> --username <USERNAME> --password <PASSWORD>
   

6. 레지스트리 시크릿의 이름을 참조하도록 빌드를 업데이트하십시오.

   a. ibmcloud ce build update 명령을 사용하여 레지스트리 시크릿의 이름을 사용하도록 빌드 구성을 업데이트하십시오. 예를 들면 다음과 같습니다.

   ibmcloud ce build update --name <BUILD_NAME> --registry-secret <REGISTRY_SECRET>
   

   b. ibmcloud ce buildrun submit 명령을 사용하여 새 빌드 실행을 제출하십시오. buildrun submit 명령의 경우 빌드 구성의 이름을 제공하려면 --build 옵션을 지정해야 합니다. 선택적으로 --name 옵션을 지정하여 이 빌드 실행의 이름을 제공할 수 있습니다. --name 옵션을 지정하는 경우 실패한 빌드 실행과 다른 빌드 실행 이름을 사용하거나, ibmcloud ce buildrun delete 명령을 사용하여 실패한 빌드 실행을 삭제해야 합니다. 예를 들면 다음과 같습니다.

   ibmcloud ce buildrun submit --build <BUILD_NAME> --name <BUILDRUN_NAME>
   

빌드 중 찾을 수 없는 Dockerfile에 대한 해결 방법

Docker 빌드에는 컨테이너 이미지를 빌드하는 방법을 지정하는 Dockerfile이 필요합니다. 소스 저장소에 해당 파일이 없는 경우 이 파일을 제공하거나 빌드팩을 빌드 전략으로 고려해야 합니다. 자세한 정보는 빌드 계획을 참조하십시오.

1. Dockerfile 파일이 있지만 이름이 다르거나 루트 디렉토리에 없는 경우 빌드에 추가 설정을 지정해야 합니다.

   • Dockerfile이 소스 저장소의 루트 디렉토리에 없는 경우, --context-dir 인수를 지정하고 Dockerfile이 포함된 디렉토리의 경로를 제공해야 합니다.
   • Dockerfile의 이름이 Dockerfile 이외의 다른 이름일 경우, --dockerfile 인수를 지정하고 Dockerfile의 이름을 제공해야 합니다.

2. 필요에 따라 --context-dir 또는 --dockerfile 옵션을 사용하도록 빌드를 업데이트하십시오.

   a. ibmcloud ce build update 명령을 사용하여 필요에 따라 --context-dir 또는 --dockerfile 옵션을 사용하도록 빌드 구성을 업데이트하십시오. 예를 들면 다음과 같습니다.

   ibmcloud ce build update --name <BUILD_NAME> [--context-dir <CONTEXT_DIR>] [--dockerfile <DOCKERFILE_NAME>]
   

   b. ibmcloud ce buildrun submit 명령을 사용하여 새 빌드 실행을 제출하십시오. buildrun submit 명령의 경우 빌드 구성의 이름을 제공하려면 --build 옵션을 지정해야 합니다. 선택적으로 --name 옵션을 지정하여 이 빌드 실행의 이름을 제공할 수 있습니다. --name 옵션을 지정하는 경우 실패한 빌드 실행과 다른 빌드 실행 이름을 사용하거나, ibmcloud ce buildrun delete 명령을 사용하여 실패한 빌드 실행을 삭제해야 합니다. 예를 들면 다음과 같습니다.

   ibmcloud ce buildrun submit --build <BUILD_NAME> --name <BUILDRUN_NAME>
   

빌드 중 IBM Cloud Container Registry 할당량 한계 도달에 대한 해결 방법

IBM Cloud Container Registry는 무료 플랜과 표준 플랜이라는 두 가지 서비스 플랜을 제공합니다. 무료 플랜의 경우 IBM Cloud Container Registry에서는 특히 저장할 수 있는 총 이미지 크기(500MB)에 엄격한 제한을 적용합니다. 표준 플랜의 경우 할당량을 구성할 수 있습니다. 자세한 정보는 IBM Cloud Container Registry 정보를 참조하십시오.

1. 다음 조치 중 하나를 수행하십시오.

   • IBM Cloud Container Registry 네임스페이스에서 사용하지 않는 이미지를 삭제하여 사용 가능한 공간을 늘리십시오.
   • 무료 플랜에서 표준 플랜으로 업그레이드하십시오.
   • IBM Cloud Container Registry 네임스페이스의 할당량을 늘리십시오.

   영향을 받는 IBM Cloud Container Registry 네임스페이스를 식별하는 데 도움이 되도록 오류 메시지에는 이미지 URL이 포함되어 있습니다. IBM Cloud 프로젝트와 다른 IBM Cloud Code Engine 계정에 네임스페이스가 있을 수 있습니다.

2. 정정 조치를 완료한 후 ibmcloud ce buildrun submit 명령을 사용하여 새 빌드 실행을 제출하십시오. buildrun submit 명령의 경우 빌드 구성의 이름을 제공하려면 --build 옵션을 지정해야 합니다. 선택적으로 --name 옵션을 지정하여 이 빌드 실행의 이름을 제공할 수 있습니다. --name 옵션을 지정하는 경우 실패한 빌드 실행과 다른 빌드 실행 이름을 사용하거나, ibmcloud ce buildrun delete 명령을 사용하여 실패한 빌드 실행을 삭제해야 합니다. 예를 들면 다음과 같습니다.

   ibmcloud ce buildrun submit --build <BUILD_NAME> --name <BUILDRUN_NAME>
   

빌드 소스가 올바르게 지정되지 않은 경우에 대한 해결 방법

이 오류가 발생하는 일반적인 이유는 빌드 소스가 Git 저장소의 루트 디렉토리가 아니라 하위 디렉토리에 있기 때문입니다. 빌드 소스가 루트 디렉토리 내에 있지 않을 경우 빌드에 위치를 지정하십시오.

1. ibmcloud ce build update 명령을 사용하여 Git 저장소에 있는 소스의 경로를 지정하는 --context-dir 옵션을 사용하도록 빌드 구성을 업데이트하십시오. 예를 들면 다음과 같습니다.

   ibmcloud ce build update --name <BUILD_NAME> --context-dir <CONTEXT_DIR>
   

2. ibmcloud ce buildrun submit 명령을 사용하여 새 빌드 실행을 제출하십시오. buildrun submit 명령의 경우 빌드 구성의 이름을 제공하려면 --build 옵션을 지정해야 합니다. 선택적으로 --name 옵션을 지정하여 이 빌드 실행의 이름을 제공할 수 있습니다. --name 옵션을 지정하는 경우 실패한 빌드 실행과 다른 빌드 실행 이름을 사용하거나, ibmcloud ce buildrun delete 명령을 사용하여 실패한 빌드 실행을 삭제해야 합니다. 예를 들면 다음과 같습니다.

   ibmcloud ce buildrun submit --build <BUILD_NAME> --name <BUILDRUN_NAME>
   

Docker 허브 속도 한계로 인한 문제점 해결

Docker 허브에서 이미지를 가져와 Code Engine 에서 앱 또는 작업에 사용할 경우 무료 요금제(인증되지 않은) 사용자의 경우 Docker 요금 제한에 유의하세요. 가져오기 속도 한계에 도달했음을 표시하는 429 오류를 수신한 경우 가져오기 한계에 도달했을 수 있습니다. 이 오류를 수신하면 다음 솔루션 중 하나를 시도하십시오.

• 비율 한계 증가. 필요한 경우 Docker 허브를 사용하여 인증하거나 Docker Pro 또는 Team 구독으로 계정을 업그레이드할 수 있습니다.

• Docker 허브에서 빌드된 이미지를 가져와서 다른 레지스트리 (예: IBM Cloud® Container Registry) 에 이미지를 공개하십시오. 그런 다음 새 위치에서 이미지를 가져오십시오. Code Engine 는 단일 시크릿 참조를 지원합니다. Dockerfile 빌드의 기본 이미지를 결과 빌드 이미지가 공개되고 두 레지스트리 모두에 인증이 필요한 다른 레지스트리에서 가져오는 경우 kubectl 를 사용하여 두 레지스트리에 대한 신임 정보를 포함하는 kubernetes.io/dockerconfigjson 유형의 Kubernetes 시크릿을 작성할 수 있습니다. 두 레지스트리 모두에 대한 액세스 신임 정보 작업에 대한 정보는 개인용 저장소에서 이미지 가져오기에 대한Kubernetes 문서를 참조하십시오.

빌드팩에서 빌드 소스를 지원하지 않는 경우에 대한 해결 방법

빌드 소스 저장소가 Code Engine에서 지원되는지 확인하려면 지원되는 런타임에 대한 빌드 전략 선택을 참조하십시오. 해당 언어가 목록에 있을 경우 링크된 샘플을 확인한 후 빌드팩이 소스를 성공적으로 발견하고 빌드할 수 있도록 소스를 올바르게 구조화했는지 확인하십시오. 소스에 적합한 빌드팩을 찾을 수 없거나 빌드팩이 빌드를 실행하는 방법에 대한 표준화된 방식이 요구사항을 충족하지 않을 경우, Dockerfile을 지정하고 Dockerfile에서 컨테이너 빌드를 수동으로 설명한 다음 빌드 구성에서 dockerfile 빌드 전략을 사용하도록 전환할 수 있습니다.

Docker 빌드 문제점에 대한 해결 방법

빌드 및 푸시 단계 실패 문제점이 메모리, 컨테이너 레지스트리 시크릿 또는 Dockerfile과 관련된 문제점이 아닌 경우 Docker 빌드와 관련된 문제점일 수 있습니다. 구문 오류와 같이 Dockerfile 자체의 오류 또는 수행하는 오퍼레이션의 정확성이 문제일 수 있습니다. 소스 코드에도 문제가 있을 수 있으며, 예를 들어 Java® 코드가 포함된 경우 컴파일에 실패할 수 있습니다.

로컬에서 프로젝트를 성공적으로 빌드했지만 동일한 소스 코드가 Code Engine에서 빌드되지 않는다면 Git 저장소에 없는 로컬로 사용 가능한 파일이 있을 수 있습니다. 예를 들어, Node.js 프로젝트의 경우에는 npm install 명령을 로컬에서 실행하여 프로젝트 종속 항목을 다운로드하고 프로젝트 디렉토리 내의 node_modules 디렉토리에 배치하는 것이 일반적입니다. Git 리포지토리를 작게 유지하려면 .gitignore 파일에 node_modules 디렉터리를 포함하는 것이 좋습니다. 일반적인 실수는 Dockerfile에서도 npm install(또는 npm ci)을 실행하는 것을 잊어버리는 것입니다. 로컬에서 실행하는 Docker 빌드는 전체 프로젝트를 컨테이너에 복사하는 경우, 예를 들어 Docker파일에서 COPY . /app 명령을 사용하여 로컬 node_modules 디렉터리에 액세스할 수 있습니다. 그러나 Code Engine은 새로 체크아웃된 Git 장소에서 실행되며 node_modules 디렉토리에 액세스할 수 없습니다. 따라서 빌드의 일부로 Dockerfile에서 npm install(또는 npm ci)을 실행해야 합니다.

로컬에서 실행하는 Docker 빌드가 Code Engine 빌드와 동일하게 작동하도록 node_modules 같은 디렉터리도 .dockerignore 파일에 포함시키는 것이 좋습니다.

프로젝트가 로컬에서는 빌드되지만 Code Engine 빌드는 실패하는 또 다른 이유는 보안 제한사항입니다. 애플리케이션 및 일괄처리 작업과 마찬가지로, Code Engine은 Code Engine 클러스터 내에서 임의적인 시스템 오퍼레이션을 허용하지 않습니다. 이러한 시스템 오퍼레이션의 대부분은 Docker 빌드와 관련이 없습니다. 그러나 Code Engine은 권한 있는 포트에 대한 서버 소켓 열기를 허용하지 않습니다. 범위는 0 to 1023입니다. 예를 들어 웹 애플리케이션을 빌드하고 빌드에 웹 애플리케이션 서버를 불러오는 테스트 단계가 포함된 경우 이 서버에 대해 더 높은 번호의 포트를 사용해야 합니다.