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 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

다음과 같은 이유가 있을 수 있습니다:

  • 응용 프로그램에 빌드팩이 찾고 있는 필수 파일이 누락될 수 있습니다. 루비 응용 프로그램의 경우 Gemfile이 필요하지만, Gemfile 없이도 루비 응용 프로그램을 작성할 수 있습니다.
  • 응용 프로그램에 대한 빌드팩이 없을 수 있습니다. 사용자 정의 빌드팩을 지정해 보세요.

빌더 sunset 오류

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

이 문제를 해결하려면 heroku/builder:* 빌더 이미지로 이전해야 합니다. 임시 방편으로 오류를 건너뛰기 위해 환경 변수를 설정할 수도 있습니다.

heroku/builder:* 로의 이전

이전하기 전에 각 spec 릴리스의 릴리스 노트를 읽어 잠재적인 호환성 문제를 확인해야 합니다. 이 경우 해당 빌드팩 API 버전은 0.6 및 0.7입니다. 이러한 호환성 문제는 빌드팩 관리자에게 특히 중요합니다.

변경 사항에 대한 자세한 정보는 스펙 자체를 비교하면 확인할 수 있습니다.

오류 건너뛰기

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

  variables:
    ALLOW_EOL_SHIMMED_BUILDER: "1"
    AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES: ALLOW_EOL_SHIMMED_BUILDER

/ 또는 except만 있는 Auto DevOps를 확장하는 파이프라인 실패

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

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

이 오류는 포함된 작업의 규칙 구성이 only 또는 except 구문으로 덮어씌워졌을 때 발생합니다. 이 문제를 해결하려면 다음 중 하나를 수행해야 합니다:

Kubernetes 네임스페이스 생성 실패

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

기존 PostgreSQL 데이터베이스 감지

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

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

기본적으로 Auto DevOps는 응용 프로그램 옆에 클러스터 내 PostgreSQL 데이터베이스를 설치합니다. GitLab 13.0에서 기본 설치 방법이 변경되었으며, 기존 데이터베이스를 업그레이드하려면 사용자의 개입이 필요합니다. 채널 1(폐기됨) 및 채널 2(현재 버전) 설치 방법은 다음과 같습니다:

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

이 오류를 해결하려면 다음 작업 중 하나를 수행할 수 있습니다:

  • 채널 1 PostgreSQL 데이터베이스 계속 사용을 위해 AUTO_DEVOPS_POSTGRES_CHANNEL를 1로 설정하고 다시 배포합니다.

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

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

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

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

" ": "extensions/v1beta1" 버전에서 "Kind "Deployment"에 대한 일치 항목을 인식할 수 없음"

Kubernetes 클러스터를 v1.16+로 업그레이드한 후 Auto DevOps로 배포하는 도중 다음과 같은 메시지가 표시될 수 있습니다: 

업그레이드 실패
Error: failed decoding reader into objects: unable to recognize "": no matches for kind "Deployment" in version "extensions/v1beta1"

현재 배포된 리소스가 v1.16+의 Kubernetes에 존재하지 않는 폐기/제거된 API를 사용하여 생성된 경우 발생할 수 있습니다. 예를 들어, 클러스터 내 PostgreSQL이 레거시 방식으로 설치된 경우와 같이 extensions/v1beta1 API를 사용하여 해당 리소스가 생성된 경우입니다. 그러나 v1.16에서 배포 리소스가 app/v1 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" # Auto-depoy-image 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. 이제 이 보조 템플릿 map-deprecated-api를 더이상 포함할 필요가 없으므로 .gitlab-ci.yml을 이전 버전으로 되돌릴 수 있습니다.

  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. 차트 디렉터리에서 다음과 같이 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, “Migrate PostgreSQL from stable Helm repository”에서 찾을 수 있습니다.

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

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

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

이는 배포 프로세스 중에 시도된 라이브니스(또는 준비 상태) 프로브가 실패한 것으로 과도한 확률이 높습니다. 기본적으로 이러한 프로브는 배포된 응용 프로그램의 루트 페이지에서 5000번 포트로 실행됩니다. 응용 프로그램이 루트 페이지에서 무언가를 제공하도록 구성되어 있지 않거나, 5000번 포트가 아닌 다른 특정 포트에서 실행되도록 구성되어 있다면, 이 확인은 실패합니다.

이 확인이 실패하면, 해당하는 쿠버네티스 네임스페이스의 이벤트에서 다음과 같은 실패를 확인할 수 있습니다: 

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 값을 덮어쓰여져 변경될 수 있습니다.