이 문서 페이지의 정보는 Auto DevOps를 사용할 때 발생하는 일반적인 오류와 사용 가능한 해결 방법을 설명합니다.

Helm 명령 추적#

CI/CD 변수 TRACE를 임의의 값으로 설정하면 Helm 명령이 자세한 출력을 생성합니다. 이 출력을 사용하여 Auto DevOps 배포 문제를 진단할 수 있습니다.

고급 Auto DevOps 구성 변수를 변경하여 Auto DevOps 배포 문제를 해결할 수 있습니다. Auto DevOps CI/CD 변수 커스터마이징에 대해 자세히 알아보세요.

빌드팩을 선택할 수 없음#

Auto Test가 다음 오류와 함께 언어나 프레임워크를 감지하지 못할 수 있습니다:

Step 5/11 : RUN /bin/herokuish buildpack build
 ---> Running in eb468cd46085
    -----> Unable to select a buildpack
The command '/bin/sh -c /bin/herokuish buildpack build' returned a non-zero code: 1

가능한 원인은 다음과 같습니다:

• 애플리케이션에 빌드팩이 찾고 있는 핵심 파일이 없을 수 있습니다. Ruby 애플리케이션은 Gemfile 없이도 작성할 수 있지만, 올바르게 감지되려면 Gemfile이 필요합니다.
• 애플리케이션에 맞는 빌드팩이 없을 수 있습니다. 커스텀 빌드팩을 지정해 보세요.

빌더 지원 종료 오류#

이 Heroku 업데이트로 인해 레거시 심드(shimmed) heroku/buildpacks:20 및 heroku/builder-classic:22 이미지가 이제 경고 대신 오류를 생성합니다.

이 문제를 해결하려면 heroku/builder:* 빌더 이미지로 마이그레이션해야 합니다. 임시 해결책으로, 환경 변수를 설정하여 오류를 건너뛸 수도 있습니다.

heroku/builder:*로 마이그레이션#

마이그레이션하기 전에 잠재적인 주요 변경 사항을 파악하기 위해 각 스펙 릴리스의 릴리스 노트를 읽어야 합니다. 이 경우 관련 빌드팩 API 버전은 0.6 및 0.7입니다. 이러한 주요 변경 사항은 특히 빌드팩 유지관리자에게 중요합니다.

변경 사항에 대한 자세한 내용은 스펙 자체의 diff를 확인할 수도 있습니다.

오류 건너뛰기#

임시 해결책으로 ALLOW_EOL_SHIMMED_BUILDER 환경 변수를 설정하고 전달하여 오류를 건너뛸 수 있습니다:

  variables:
    ALLOW_EOL_SHIMMED_BUILDER: "1"
    AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES: ALLOW_EOL_SHIMMED_BUILDER

only / except로 Auto DevOps를 확장하는 파이프라인 실패#

파이프라인이 다음 메시지와 함께 실패하는 경우:

Unable to run pipeline

  jobs:test config key may not be used with `rules`: only

이 오류는 포함된 작업의 규칙 구성이 only 또는 except 구문으로 재정의될 때 나타납니다. 이 문제를 해결하려면 only/except 구문을 rules로 전환해야 합니다.

Kubernetes 네임스페이스 생성 실패#

GitLab이 프로젝트의 Kubernetes 네임스페이스와 서비스 계정을 생성할 수 없는 경우 Auto Deploy가 실패합니다. 이 문제를 디버깅하는 데 도움이 필요하면 배포 작업 실패 트러블슈팅을 참조하세요.

프로젝트에서 Auto DevOps가 자동으로 비활성화됨#

프로젝트에서 Auto DevOps가 자동으로 비활성화되는 경우 다음과 같은 이유일 수 있습니다:

• 프로젝트 자체에서 Auto DevOps 설정이 명시적으로 활성화되지 않았습니다. 상위 그룹 또는 해당 인스턴스에서만 활성화되어 있습니다.
• 프로젝트에 Auto DevOps 파이프라인이 성공한 기록이 없습니다.
• Auto DevOps 파이프라인이 실패했습니다.

이 문제를 해결하려면:

• 프로젝트에서 Auto DevOps 설정을 활성화합니다.
• 파이프라인이 다시 실행될 수 있도록 파이프라인을 망가뜨리는 오류를 수정합니다.

오류: unable to recognize "": no matches for kind "Deployment" in version "extensions/v1beta1"#

Kubernetes 클러스터를 v1.16+로 업그레이드한 후 Auto DevOps로 배포할 때 이 메시지가 나타날 수 있습니다:

UPGRADE FAILED
Error: failed decoding reader into objects: unable to recognize "": no matches for kind "Deployment" in version "extensions/v1beta1"

이는 환경 네임스페이스의 현재 배포가 Kubernetes v1.16+에 존재하지 않는 더 이상 사용되지 않거나 제거된 API로 배포된 경우에 발생할 수 있습니다.

이러한 구식 리소스를 복구하려면 레거시 API를 최신 API에 매핑하여 현재 배포를 변환해야 합니다.

Error: not a valid chart repository or cannot be reached#

공식 CNCF 블로그 게시물에 발표된 것처럼, 안정적인 Helm 차트 저장소가 2020년 11월 13일에 더 이상 사용되지 않고 제거되었습니다. 해당 날짜 이후에 이 오류가 발생할 수 있습니다:

Error: error initializing: Looks like "https://kubernetes-charts.storage.googleapis.com"
is not a valid chart repository or cannot be reached

일부 GitLab 기능은 안정적인 차트에 의존성이 있었습니다. 영향을 완화하기 위해 의존성은 새로운 공식 저장소 또는 GitLab이 유지 관리하는 Helm Stable 아카이브 저장소를 사용합니다. Auto Deploy에는 수정 예시가 있습니다.

Auto Deploy에서 auto-deploy-image의 v1.0.6+은 더 이상 helm 명령에 더 이상 사용되지 않는 안정적인 저장소를 추가하지 않습니다. 커스텀 차트를 사용하고 더 이상 사용되지 않는 안정적인 저장소에 의존하는 경우, 다음 예시와 같이 이전 auto-deploy-image를 지정하세요:

include:
  - template: Auto-DevOps.gitlab-ci.yml

.auto-deploy:
  image: "registry.gitlab.com/gitlab-org/cluster-integration/auto-deploy-image:v1.0.5"

이 접근 방식은 안정적인 저장소가 제거되면 작동을 멈추므로 최종적으로 커스텀 차트를 수정해야 합니다.

커스텀 차트를 수정하려면:

1. 차트 디렉토리에서 requirements.yaml 파일의 repository 값을 다음에서 업데이트합니다:

   repository: "https://kubernetes-charts.storage.googleapis.com/"
   

   다음으로:

   repository: "https://charts.helm.sh/stable"
   

2. 차트 디렉토리에서 Auto DevOps와 동일한 Helm 주요 버전을 사용하여 helm dep update .를 실행합니다.

3. requirements.yaml 파일의 변경 사항을 커밋합니다.

4. 이전에 requirements.lock 파일이 있었던 경우 파일 변경 사항을 커밋합니다. 이전에 차트에 requirements.lock 파일이 없었다면 새 파일을 커밋할 필요가 없습니다. 이 파일은 선택 사항이지만 존재할 경우 다운로드한 의존성의 무결성을 확인하는 데 사용됩니다.

자세한 내용은 이슈 #263778, "PostgreSQL을 안정적인 Helm 저장소에서 마이그레이션"에서 확인할 수 있습니다.

Error: release .... failed: timed out waiting for the condition#

Auto DevOps를 시작할 때 처음 애플리케이션을 배포할 때 이 오류가 발생할 수 있습니다:

INSTALL FAILED
PURGING CHART
Error: release staging failed: timed out waiting for the condition

이는 배포 프로세스 중에 실패한 활성(liveness) 또는 준비(readiness) 프로브로 인해 발생할 가능성이 높습니다. 기본적으로 이러한 프로브는 포트 5000에서 배포된 애플리케이션의 루트 페이지에 대해 실행됩니다. 애플리케이션이 루트 페이지에서 아무것도 서비스하지 않도록 구성되었거나 5000 이외의 특정 포트에서 실행되도록 구성된 경우 이 검사가 실패합니다.

실패하면 관련 Kubernetes 네임스페이스의 이벤트에서 다음 예시와 같은 실패를 확인할 수 있습니다:

LAST SEEN   TYPE      REASON                   OBJECT                                            MESSAGE
3m20s       Warning   Unhealthy                pod/staging-85db88dcb6-rxd6g                      Readiness probe failed: Get http://10.192.0.6:5000/: dial tcp 10.192.0.6:5000: connect: connection refused
3m32s       Warning   Unhealthy                pod/staging-85db88dcb6-rxd6g                      Liveness probe failed: Get http://10.192.0.6:5000/: dial tcp 10.192.0.6:5000: connect: connection refused

활성 검사에 사용되는 포트를 변경하려면 Auto DevOps가 사용하는 Helm 차트에 커스텀 값을 전달하세요:

1. 저장소 루트에 .gitlab/auto-deploy-values.yaml이라는 디렉토리와 파일을 만듭니다.

2. 포트 값을 애플리케이션이 사용하도록 구성된 실제 포트 번호로 대체하여 다음 내용으로 파일을 채웁니다:

   service:
     internalPort: <port_value>
     externalPort: <port_value>
   

3. 변경 사항을 커밋합니다.

변경 사항을 커밋한 후 이후 프로브는 새로 정의된 포트를 사용해야 합니다. 프로브된 페이지는 동일한 방식으로 기본 values.yaml 파일에 표시된 livenessProbe.path 및 readinessProbe.path 값을 재정의하여 변경할 수도 있습니다.