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 변수 사용자 정의에 대해 더 읽어보세요.

빌드팩 선택 불가능

Auto 빌드 및 Auto 테스트는 언어나 프레임워크를 감지하지 못할 수 있으며 다음과 같은 오류가 발생할 수 있습니다: 

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 없이도 Ruby 앱을 작성할 수 있습니다.
  • 애플리케이션에 대한 빌드팩이 없을 수 있습니다. 사용자 정의 빌드팩을 지정해 보세요.

/ except를 사용하여 Auto DevOps를 확장하는 파이프라인 실패

파이프라인이 다음과 같은 메시지로 실패하는 경우: 

파이프라인을 만들 수 없음
  
  jobs:test config key may not be used with `rules`: only

이 오류는 포함된 작업의 rules 구성이 only 또는 except 구문으로 오버라이드되었을 때 발생합니다. 이 문제를 해결하려면 다음 작업을 수행해야 합니다:

Kubernetes 네임스페이스 생성 실패

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

기존 PostgreSQL 데이터베이스 감지

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

현재 채널을 2로 설정했지만 폐기된 채널 1에 설치된 기존 PostgreSQL 데이터베이스가 감지되었습니다. 기본 채널은 GitLab 13.0에서 2로 변경되었습니다.
[...]

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

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

이 오류를 받으면 다음 조치 중 하나를 취할 수 있습니다:

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

  • 채널 1 PostgreSQL 데이터베이스를 삭제하고 새로운 채널 2 데이터베이스를 설치하기 위해 AUTO_DEVOPS_POSTGRES_DELETE_V1에 비어 있지 않은 값을 설정한 후 다시 배포할 수 있습니다.

    caution
    채널 1 PostgreSQL 데이터베이스를 삭제하면 기존 채널 1 데이터베이스와 데이터가 영구적으로 삭제됩니다. 더 많은 정보는 PostgreSQL 업그레이드를 참조하세요.

  • 클러스터 내 데이터베이스를 사용하지 않는 경우 POSTGRES_ENABLED를 false로 설정하고 다시 배포할 수 있습니다. 이 옵션은 클러스터 내 데이터베이스 의존성이 없는 사용자 정의 차트를 사용하는 사용자에게 특히 관련이 있습니다. 데이터베이스 자동 감지는 릴리스의 postgresql.enabled Helm 값에 기반하며 해당 값은 차트가 변수를 사용하더라도 CI/CD 변수 POSTGRES_ENABLED에 따라 설정되고 Helm에 의해 유지됩니다.

caution
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+ Kubernetes에 존재하지 않는 폐기된/제거된 API로 배포되었을 때 이 오류가 발생할 수 있습니다. 예를 들어, 클러스터 내 PostgreSQL이 레거시 방식으로 설치된 경우, 리소스는 v1.16+에서 app/v1 API로 이동했지만 배포 리소스는 v1.16에서 extensions/v1beta1 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 폐기된 또는 제거된 Kubernetes API를 찾았습니다:
"apiVersion: extensions/v1beta1
kind: Deployment"
지원되는 API 등가:
"apiVersion: apps/v1
kind: Deployment"

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

  4. 일반적으로 배포를 계속합니다.

오류: 초기화하는 중 오류가 발생했습니다: "https://kubernetes-charts.storage.googleapis.com"은(는) 유효한 차트 리포지터리가 아니거나 접근할 수 없는 것으로 보입니다

공식 CNCF 블로그 포스트에서 발표된 바와 같이, stable Helm 차트 리포지터리는 2020년 11월 13일에 폐기되었습니다. 이 날짜 이후로 이 오류를 만날 수 있습니다.

일부 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. 차트 디렉터리에서 Auto DevOps와 동일한 Helm 주 버전을 사용하여 helm dep update .을 실행하세요.

  2. requirements.yaml 파일에서 repository 값을 다음과 같이 업데이트하세요: 

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

    다음과 같이: 

    repository: "https://charts.helm.sh/stable"
  3. requirements.yaml 파일을 위한 변경 사항을 커밋하세요.
  4. 이전에 requirements.lock 파일을 가지고 있었다면 해당 파일의 변경 사항을 커밋하세요. 이전에 requirements.lock 파일이 없는 경우 새로운 파일을 커밋할 필요는 없습니다. 이 파일은 선택 사항이지만 존재하는 경우 다운로드된 의존성의 무결성을 검증하는 데 사용됩니다.

추가 정보는 이슈 #263778, “폐기된 Helm 리포지터리에서 PostgreSQL을 이전”에서 찾을 수 있습니다.

오류: 릴리스 .... 실패: 조건을 기다리는 동안 시간 초과

Auto DevOps를 시작하면 응용 프로그램을 처음으로 배포할 때 이 오류를 만날 수 있습니다: 

설치 실패
차트 제거 중
오류: 릴리스 스테이징 실패: 조건을 기다리는 동안 시간 초과

대부분 이는 배포 프로세스 중 실패한 liveness(또는 readiness) 프로브로 인한 것입니다. 기본적으로 이러한 프로브는 배포된 응용 프로그램의 루트 페이지에서 포트 5000으로 실행됩니다. 응용 프로그램이 루트 페이지에서 서비스를 제공하지 않거나 특정 포트(5000이 아닌)에서 실행하도록 구성된 경우 이 확인이 실패합니다.

이 실패가 발생하면 해당 Kubernetes 네임스페이스의 이벤트에서 다음 예제와 같은 실패가 표시됩니다: 

마지막 확인 시간   유형      이유                   오브젝트                                             메시지
3분 20초       경고   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
3분 32초       경고   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

liveness checks에 사용되는 포트를 변경하려면 Auto DevOps에서 사용하는 Helm 차트에 사용자 정의 값 전달하세요:

  1. 리포지터리 루트에 .gitlab/auto-deploy-values.yaml이란 이름의 디렉터리와 파일을 생성하세요.

  2. 파일에 실제로 응용 프로그램이 사용하는 포트 번호로 포트 값을 바꿔서 다음과 같은 내용을 채워 넣으세요: 

    service:
  internalPort: <port_value>
  externalPort: <port_value>
  3. 변경 사항을 커밋하세요.

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