Bitbucket + Kubernetes로 CI / CD 설정하면서 마주친 문제들

콜트·2021년 12월 27일

CI/CD TIL

1. bitbucket-pipelines.yml을 이용한 CI 구동시 테스트 실패

CI가 시작하자마자 아래처럼 실패했는데, 원인은 Java 버전이 맞지 않는 것이었다. bitbcket-pipelines.yml의 image 속성의 값을 변경해서 해결했다.

변경전
변경후

변경후에 테스트가 성공한 모습

2. bitbucket-pipelines.yml 작성시 anchor 문법 에러

문제 상황
문제 상황의 bitbucket-pipelines.yml 설정 파일
Bitbucket pipeline reuse of code
YAML anchors | Bitbucket Cloud | Atlassian Support

위의 두 링크를 살펴보면, 공통으로 사용되는 step(script를 정의한)들에 대해서는 다른 문법을 적용해야 한다고 한다.

위와 같이 변경 이후에 다시 저장소에 반영하니 CI가 잘 되는 모습을 확인할 수 있었다. 나중에 자세히 살펴보니 공식 문서에도 언급이 되어있었다. ~~공식 문서를 잘 살펴보자.~~

추가로, anchor로 선언해준 작업의 경우, script를 내부에 바로 사용하면 아래와 같이 에러가 발생한다. 참고하도록 하자.

3. Bitbucket variables에서 gcloud key-file 사용하기

gcloud에서 key-file을 만들었지만 bitbucket에서는 해당 key-file을 저장소의 변수로 사용하려면 약간의 작업을 거쳐야 한다.

위 사진 속의 Steps 항목의 4번을 살펴보면, base64 형태로 변환한 다음, 해당 값을 Bitbucket 저장소의 환경 변수로 설정해주어야 한다.

현재 bitbucket은 개행문자를 비롯한 줄 바꿈을 환경 변수에서 지원하지 않기 때문이다.

Bitbucket cannot load google cloud key file 참고.

4. Kubernetes namespace not found

Kubernetes를 이용할 때 deployment.yml을 정의해서 리소스를 생성하도록 했는데, deploy 도중 아래와 같은 에러가 발생하면서 실패했다.

Lab 1 - Error from server (NotFound): deployments.apps "hello-world" not found 참고.

namespace를 찾지 못해서 발생한 에러로, namespace는 아래와 같이 직접 만들어주어야 한다.

kubectl을 이용해서 직접 namespace를 만들어주니 아래와 같이 deploy가 잘 동작하는 것을 볼 수 있었다.

5. Kubernetes EXTERNAL-IP is `<pending>`

kubectl로 service를 조회했을 때 EXTERNAL-IP가 <pending>인 경우가 있다. 이 경우 약간의 시간이 걸리는 경우가 있다고 했지만, 내 경우에는 계속해서 변화가 없었다. 구글링을 통해 여러 방법을 시도해보았는데 결국 해결하지 못하고 새로 만들었다. ~~해결 방법을 알고 계신분은 제보해주시면 감사드리겠습니다.~~

6. Kubernetes run -> deployment는 생성되지 않는다.

처음에 hello-world를 만들때, kubectl expose … 명령어를 사용해서 deployment를 노출하는 service를 생성하려는데 계속 deployments.apps “hello-world” not found 라는 에러만 발생했다.

이유는 kubectl run 명령어는 deployment를 생성하지 않고, pod만 생성하기 때문이다. 이걸 몰라서 한참을 헤맸다.

7. Kubernetes get `<resource>` -n

Kubernetes는 kubectl get <resource>를 이용해서 여러 자원들을 조회할 수 있다.

이때, -n 옵션을 이용해서 namespace를 지정해주지 않으면 default namespace에서 자원들을 조회한다.

따라서 본인이 어떤 namespace에 자원을 생성했는지 확인하고 정확하게 해당 namespace에 대해 자원들을 조회해야 한다. 이것도 문법을 잘 몰라서 한참을 헤맸다..

이외에도 모든 resource에 작업을 진행하려면 -n 옵션으로 namespace를 지정해주어야 한다. 그렇지 않으면 동작하지 않는다!

# hello-world 라는 namespace에서 deployment들을 조회한다.
kubectl get deployment -n hello-world

8. bitbucket-pipelines.yml의 branches 하위 작업 정의시 문법 에러

step의 하위작업을 정의할 때 anchor를 사용하려면 bitbucket-pipelines.yml에서 pipelines 속의 step의 구조, 하이픈(-)의 의미 등에 대해서 이해해야 한다. 그렇지 않고 그냥 사용하면 아래와 같이 에러가 발생한다(test 브랜치를 볼 것).

anchor로 정의한 build-project의 내용
1번 에러
2번 에러
1번 에러 발생 bitbucket-pipelines.yml
2번 에러 발생 bitbucket-pipelines.yml
에러 해결한 bitbucket-pipelines.yml

pipelines 구조 해석

step은 Collection의 원소이다(각각의 브랜치에는 보이진 않지만 steps라는 Collection이 있다고 보면 될 것 같다. 이는 List이다).
steps에 추가될 각각의 step 원소는 하이픈(-)과 함께 정의된다.
step또한 여러개의 원소(스크립트 등)를 가질 수 있는 Collection 이다.
즉, 하이픈(-)과 함께 정의되는 것들은 Collection 중에서 List의 원소라는 뜻이다.
>>의 의미는 override 한다는 뜻이라고 한다.

에러 원인

1번 에러는 step이 정의되어 있지 않았기 때문에 에러가 발생했다.
2번 에러는 Collection의 첫 번째 원소인 step에 anchor로 정의한 *build-project를 또 다시 컬렉션의 원소로써 정의하고 넣었기 때문에 에러가 발생한 것.

9. bitbucket-pipelines.yml을 작성할 때, 하나의 step에는 하나의 anchor 작업만 실행된다.

아래와 같이 test 브랜치의 parallel 속 첫 번째 step 처럼 작성할 경우, build-docker만 실행되고 deploy-project는 실행되지 않는다. 즉, 첫번째 anchor 작업만 실행된다(~~이유는 아직 찾지 못했다. 공식문서에 있으리라 추측된다~~). 따라서 각각의 step으로 anchor를 분리해서 위치시켜야 한다.