- Helm 명령 추적
- 빌드팩 선택 불가능
- 빌더 sunset 오류
/
또는except
만 있는 Auto DevOps를 확장하는 파이프라인 실패- Kubernetes 네임스페이스 생성 실패
- 기존 PostgreSQL 데이터베이스 감지
" ": "extensions/v1beta1" 버전에서 "Kind "Deployment"에 대한 일치 항목을 인식할 수 없음"
오류: 오류 초기화 중: "https://kubernetes-charts.storage.googleapis.com"은(는) 유효한 차트 리포지터리가 아니거나 연결할 수 없는 것으로 보입니다
오류: 릴리스 .... 실패: 조건을 기다리는 동안 시간 초과
Auto DevOps 문제 해결
이 문서 페이지에서 제공하는 정보는 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
구문으로 덮어씌워졌을 때 발생합니다.
이 문제를 해결하려면 다음 중 하나를 수행해야 합니다:
-
only/except
구문을rules
로 전환합니다. - (일시적으로) 템플릿을 GitLab 12.10 기반 템플릿에 고정합니다.
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
을 비어 있지 않은 값으로 설정하고 다시 배포합니다.채널 1 PostgreSQL 데이터베이스를 삭제하면 기존의 채널 1 데이터베이스와 해당 데이터가 영구적으로 삭제됩니다. 데이터베이스를 백업하고 업그레이드하는 방법에 대한 자세한 내용은 PostgreSQL 업그레이드를 참조하세요. -
클러스터 내 데이터베이스를 사용하지 않는 경우
POSTGRES_ENABLED
를false
로 설정하고 다시 배포할 수 있습니다. 이 옵션은 클러스터 내 PostgreSQL 의존성이 없는 사용자 지정 차트를 사용하는 사용자에게 특히 관련됩니다. 데이터베이스의 자동 감지는 배포를 위해postgresql.enabled
Helm 값에 기반하며, 해당 값은 CI/CD 변수POSTGRES_ENABLED
에 따라 설정되며 차트가 해당 변수를 사용하든 사용하지 않든 Helm에서 유지됩니다.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에서 도구를 사용하려면 다음 단계를 따르세요:
-
.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"으로 지정하세요.
-
<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"
-
이제 이 보조 템플릿
map-deprecated-api
를 더이상 포함할 필요가 없으므로.gitlab-ci.yml
을 이전 버전으로 되돌릴 수 있습니다. -
계속해서 배포를 진행하세요.
오류: 오류 초기화 중: "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 리포지터리가 제거되면 작동을 중지하므로, 최종적으로는 사용자 정의 차트를 수정해야 합니다.
사용자 정의 차트를 수정하려면:
-
차트 디렉터리에서 다음과 같이
requirements.yaml
파일의repository
값을 업데이트하세요:repository: "https://kubernetes-charts.storage.googleapis.com/"
다음과 같이:
repository: "https://charts.helm.sh/stable"
- 차트 디렉터리에서 Auto DevOps와 동일한 Helm 주 버전을 사용하여
helm dep update .
를 실행하세요. -
requirements.yaml
파일의 변경 사항을 커밋하세요. - 이전에
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 차트에 사용자 정의 값을 전달하세요:
-
리포지터리의 루트에
.gitlab/auto-deploy-values.yaml
이라는 디렉터리와 파일을 생성하세요. -
실제 응용 프로그램이 사용하는 포트 번호로 포트 값을 바꿔 파일을 채우세요:
service: internalPort: <port_value> externalPort: <port_value>
-
변경 사항을 커밋하세요.
변경 사항을 커밋한 후, 후속 프로브는 새로 정의된 포트를 사용해야 합니다.
또한, 프로브할 페이지는 기본 values.yaml
파일에 표시된 것과 같은 방식으로 livenessProbe.path
와 readinessProbe.path
값을 덮어쓰여져 변경될 수 있습니다.