Auto DevOps 문제 해결

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated

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

Helm 명령 추적

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

일부 Auto DevOps 배포 문제는 Auto DevOps 고급 구성 변수를 변경하여 해결할 수 있습니다. Auto DevOps CI/CD 변수 사용자 정의에 대해 자세히 알아보세요.

빌드팩 선택 불가

자동 빌드 및 자동 테스트는 다음과 같은 오류로 인해 언어나 프레임워크를 감지하지 못할 수 있습니다. 

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

다음은 가능한 원인입니다:

  • 빌드팩이 찾고 있는 키 파일이 애플리케이션에 없을 수 있습니다. 루비 애플리케이션은 정상적으로 감지하려면 Gemfile이 필요하지만, Gemfile 없이도 루비 앱을 작성할 수 있습니다.
  • 사용 가능한 빌드팩이 없을 수 있습니다. 사용자 정의 빌드팩을 지정해 보세요.

/만 사용하거나 Auto DevOps를 확장하는 파이프라인 실패

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

Unable to create pipeline

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

이 오류는 포함된 작업의 규칙 구성이 only 또는 except 구문으로 재정의되었을 때 나타납니다. 이 문제를 해결하려면 다음 중 하나를 수행해야 합니다:

Kubernetes 네임스페이스 생성 실패

GitLab이 프로젝트를 위해 Kubernetes 네임스페이스와 서비스 계정을 생성하지 못하면 Auto Deploy가 실패합니다. 이 문제에 대한 디버깅 도움은 배포 작업 실패 문제 해결을 참조하세요.

기존 PostgreSQL 데이터베이스 감지

GitLab 13.0으로 업그레이드한 후 Auto DevOps로 배포할 때 다음 메시지를 만날 수 있습니다. 

Detected an existing PostgreSQL database installed on the
deprecated channel 1, but the current channel is set to 2. The default
channel changed to 2 in of GitLab 13.0.
[...]

기본적으로 Auto DevOps는 애플리케이션과 함께 클러스터 내부에 PostgreSQL 데이터베이스를 설치합니다. GitLab 13.0에서 기본 설치 방법이 변경되었으며, 기존 데이터베이스를 업그레이드하려면 사용자의 개입이 필요합니다. 두 가지 설치 방법은 다음과 같습니다:

  • 채널 1 (폐기 예정): 연관된 Helm 차트의 의존성으로 데이터베이스를 가져옵니다. Kubernetes 버전 1.15까지만 지원됩니다.
  • 채널 2 (현재): 데이터베이스를 독립적인 Helm 차트로 설치합니다. Kubernetes 버전 1.16 이상과 함께 클러스터 내 데이터베이스 기능을 사용하려면 필요합니다.

이 오류를 받은 경우 다음 중 하나를 수행할 수 있습니다:

  • AUTO_DEVOPS_POSTGRES_CHANNEL을 1로 설정하고 재배포하여 채널 1 PostgreSQL 데이터베이스를 계속 사용할 수 있습니다.

  • AUTO_DEVOPS_POSTGRES_DELETE_V1을 비어 있지 않은 값으로 설정하여 채널 1 PostgreSQL 데이터베이스를 삭제하고 새로운 채널 2 데이터베이스를 설치할 수 있습니다.

    경고: 채널 1 PostgreSQL 데이터베이스를 삭제하면 기존 채널 1 데이터베이스와 해당 데이터가 영구적으로 삭제됩니다. 자세한 내용은 PostgreSQL 업그레이드를 참조하세요.

  • 클러스터 내 데이터베이스를 사용하고 있지 않다면 POSTGRES_ENABLED를 false로 설정하고 다시 배포할 수 있습니다. 이 옵션은 클래스 내부 PostgreSQL 의존성 없는 사용자 지정 차트 사용자에게 특히 관련이 있습니다. 데이터베이스 자동 감지는 릴리스에 대한 postgresql.enabled Helm 값에 따라 설정되며, 차트가 해당 변수를 사용하는지 여부에 관계없이 Helm에 의해 유지됩니다.

경고: POSTGRES_ENABLED를 false로 설정하면 환경의 기존 채널 1 데이터베이스가 영구적으로 삭제됩니다.

Error: 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"

이는 현재 배포가 v1.16+에서 존재하지 않는 폐기/제거된 API로 배포되어 있다는 것을 의미합니다. 예를 들어, 클러스터 내 PostgreSQL이 레거시 방식으로 설치된 경우, 리소스는 v1.16+에서 app/v1 API로 이동되었습니다.

이러한 오래된 리소스를 복구하려면 현재 배포를 레거시 API를 새 API로 매핑해야 합니다. 이 문제에 대한 도움말 도구인 mapkubeapis가 있습니다. Auto DevOps에서 이 도구를 사용하려면 다음 단계를 따르세요:

  1. .gitlab-ci.yml을 수정하세요: 

    include:
  - template: Auto-DevOps.gitlab-ci.yml
  - remote: https://gitlab.com/shinya.maeda/ci-templates/-/raw/master/map-deprecated-api.gitlab-ci.yml

variables:
  HELM_VERSION_FOR_MAPKUBEAPIS: "v2" # 자동 배포 이미지 v2 이상을 사용하는 경우 "v3"으로 지정하세요.

  2. <environment-name>:map-deprecated-api 작업을 실행하세요. 다음 단계로 넘어가기 전에 이 작업이 성공해야 합니다. 다음 출력과 유사한 내용을 볼 수 있어야 합니다: 

    2020/10/06 07:20:49 Found deprecated or removed Kubernetes API:
"apiVersion: extensions/v1beta1
kind: Deployment"
Supported API equivalent:
"apiVersion: apps/v1
kind: Deployment"

  3. .gitlab-ci.yml을 이전 버전으로 되돌리세요. 더 이상 부가적인 템플릿 map-deprecated-api를 포함할 필요가 없습니다.

  4. 평소처럼 배포를 계속하세요.

Error: error initializing: "https://kubernetes-charts.storage.googleapis.com"은(는) 유효한 차트 저장소가 아니거나 연결할 수 없는 것으로 보입니다

공식 CNCF 블로그 글에서 발표된 대로, stable Helm 차트 저장소는 2020년 11월 13일에 deprecate되었고 제거되었습니다. 이 날짜 이후로 이 오류를 만날 수 있습니다.

일부 GitLab 기능은 stable 차트에 종속되어 있었습니다. 이 영향을 완화하기 위해 새로운 공식 저장소를 사용하거나 GitLab이 유지보수하는 Helm Stable Archive 저장소를 사용하도록 변경했습니다. Auto Deploy에는 예시 수정이 포함되어 있습니다.

Auto Deploy에서 v1.0.6+의 auto-deploy-image는 이제 더 이상 폐기된 stable 저장소를 helm 명령에 추가하지 않습니다. 사용자 지정 차트를 사용하고 폐기된 stable 저장소에 의존하는 경우 다음 예와 같이 이전 버전의 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"

이 방식은 stable 저장소가 제거되면 더 이상 작동하지 않으므로 사용자 지정 차트를 최종적으로 수정해야 합니다.

사용자 지정 차트 수정 방법:

  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, “stable Helm 저장소에서 PostgreSQL 마이그레이션”에서 찾을 수 있습니다.

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

이는 배포 프로세스 중에 실패한 라이브니스(또는 준비 상태) 프로브로 인한 것으로 추정됩니다. 기본적으로 이러한 프로브는 배포된 응용 프로그램의 루트 페이지에 대해 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. 변경 사항을 커밋하세요.

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