티스토리 뷰
개요
Bamboo Plan은 Jenkins의 파이프라인과 같이 여러 Stage를 하나로 묶어 서로 다른 컴포넌트의 동작을 하나처럼 움직이도록 하는 빌드/배포 방식이다.
Jenkins의 경우 Pipeline → Stage → Step → Script로 단계를 관리한다. 이와 마찬가지로 Bamboo는 Plan → Stage → Job → Task로 단계를 관리한다. 지금부터는 이 관계도를 기반으로 어떻게 Bamboo Plan을 구성하고 실행하는지 살펴보도록 하자.
Bamboo 빌드/배포
이제 본격적으로 Bamboo를 구축해 보도록 하자. 모든 Bamboo의 배포 체계를 Plan을 생성함으로써 시작되며, 이미 생성되어 있는 Plan에 Stage를 추가하여 배포를 변경할 수 있다.
Bamboo Plan
> Create - Create plan
먼저 Bamboo Plan을 생성한다.
Bamboo Plan을 생성하면, 함께 Project를 생성한다. 만약 기존에 생성해둔 Project가 존재한다면, 해당 프로젝트를 선택할 수 있으며, New Project를 생성할 수도 있다.
- Project name : 신규 프로젝트 이름
- Plan name : 신규 Plan 이름
- Plan access : 생성한 Plan에 대한 사용자 View 권한 부여 여부 (체크 시 모든 사용자 View 권한 부여)
- Link repository to new build plan - Repository host
Previously linked repository : Link Repository에 기 등록해 둔 형상관리 Repository 선택
Link new repository : 신규 Link Repository 등록
None : 형상관리 등록 안함
Bamboo Job
Configure Job에서는 Plan의 Default Job에 대해 정의한다. 추가 Job은 계속해서 더할 수 있다.
- Isolate build - Run this job in : Agent environment (Bamboo Server 자체적으로 실행할지 또는 Docker Container를 기동하여 별도의 환경에서 Job을 기동할지 선택)
- [Add task] 클릭
> Task 선택
Job의 실제 업무를 정의하는 Task를 선택한다. Builder, Tests, Deployment, Source Control, Variables로 구분해서 원하는 Task를 선택할 수 있다.
> Source Code Checkout
예를 들어 Source Code를 Checkout 받기 위한 Task를 정의한다면, Source Control - Source Code Checkout을 선택하고
Source Code Checkout Task 설정 정보를 구성한 후, Task를 Final Tasks로 드레그 앤 & 드랍하여 이동시킨다. 구성이 완료되면, [Create]를 선택한다.
Plan 확인
생성이 완료된 Plan을 위와 같이 확인할 수 있다. Plan을 관리하는 3개의 구성 Plan이 존재하며, 이는 다음과 같다.
> Disable plan
Plan Run을 비활성화 한다. 활성화를 위해 Enable plan을 선택할 수 있다.
> Favourite plan
해당 Plan을 Favourite으로 지정한다. 한번 더 선택시 해제된다.
> Configure plan
Plan에 대한 구성을 변경할 수 있다. Stage/Job을 구성하거나, Repository 추가, Permission 관리 등을 구성할 수 있으며, Variables를 사용하여 Task에서 사용하는 변수를 구성할 수 있다.
이 Config plan 중 Variables를 구성해 보도록 하자.
해당 Variable은 Plan 내 모든 Task가 공유할 수 있다. (Jenkins의 Environment와 같다.)
Plan 실행
Plan은 다음과 같이 실행할 수 있다.
Bamboo 대시보드 홈에는 실행 가능한 Plan을 확인할 수 있다. 직접 오른쪽 Run 화살표 버튼으로 Plan을 실행하거나, 상단의 Projects → Bamboo-K8S-Project →k8s-plan으로 이동하여 오른쪽 상단의 Run 버튼으로 실행할 수도 있다.
실행 결과는 Build 넘버(#n)을 클릭하여 확인할 수 있다.
Summary, Tests, Commits, Artifacts, Logs, Metadata, Webhooks 등을 확인할 수 있으며, 특히 Logs를 통해 전체 상태를 상세하게 확인할 수 있다. (Jenkins의 Console로그와 같다.)
위와 같이 로그를 확인할 수 있으며, Source Code Checkout Task가 포함되어 있는 해당 Plan에서 정상적으로 소스코드가 체크아웃 되었는지 확인할 수 있다.
몇몇 로그를 통해 확인할 수 있으며,
[Starting task 'Checkout K8S Bitbucket' of type 'com.atlassian.bamboo.plugins.vcs:task.vcs.checkout']
[Cloning into '/root/atlassian/bamboo-home/xml-data/build-dir/BAM-K8SPLAN-JOB1'...]
위 두 로그를 통해 해당 위치에 소스코드가 Checkout 되었는지 확인해 보도록 하자.
[root@ip-192-168-123-141 BAM-K8SPLAN-JOB1]# pwd
/root/atlassian/bamboo-home/xml-data/build-dir/BAM-K8SPLAN-JOB1
[root@ip-192-168-123-141 BAM-K8SPLAN-JOB1]# ls -la
total 36
drwxr-x--- 6 root root 154 Jan 24 14:49 .
drwxr-x--- 5 root root 83 Jan 24 14:45 ..
drwxr-x--- 4 root root 131 Jan 24 14:49 bin
-rw-r----- 1 root root 1378 Jan 24 14:49 deployment.yaml
-rw-r----- 1 root root 185 Jan 24 14:49 Dockerfile
drwxr-x--- 8 root root 163 Jan 24 14:49 .git
-rw-r----- 1 root root 395 Jan 24 14:49 .gitignore
drwxr-x--- 3 root root 21 Jan 24 14:49 .mvn
-rw-r----- 1 root root 10070 Jan 24 14:49 mvnw
-rw-r----- 1 root root 6608 Jan 24 14:49 mvnw.cmd
-rw-r----- 1 root root 1682 Jan 24 14:49 pom.xml
drwxr-x--- 4 root root 30 Jan 24 14:49 src
[root@ip-192-168-123-141 BAM-K8SPLAN-JOB1]#
다음과 같이 소스코드가 정상적으로 Checkout 된 것을 확인할 수 있다. 이는 Jenkins Checkou Stage와 동일하다고 볼 수 있으며, 체크아웃 위치는 $BAMBOO_HOME/xml-data/build-dir/[JOB]으로 Jenkins의 workspace 위치라고 볼 수 있다.
Bamboo EKS 배포
자 이제 본격적으로 Amazon EKS에 배포를 해보도록 하자. Amazon EKS에 배포하는 과정은 다음과 같은 Job으로 구성된다.
(Bitbucket Checkout - Maven Build & Package - Docker Build - K8S Deploy)
Bamboo Variables
앞서 살펴본데로 Plan 내 공통 변수를 다음과 같이 추가한다.
DOCKER_USERNAME/DOCKER_PASSWORD : Nexus Docker Repository Credential
IMAGE_REGISTRY/SVC_CODE/SYSTEM_CODE/IMAGE_REPO : Docker Image Info
Bamboo Job
a. Source Code Checkout (Source Checkout Bitbucket Repository)
Bitbucket 소스를 Checkout하는 Source Code Checkout Task를 생성한다.
- Repository : Linked Repository로 연동된 소스 형상관리 도구의 Repository를 선택한다.
- Checkout Directory : Checkout 받을 경로를 지정한다. 지정하지 않을 경우 Default Job 경로에 Checkout을 받는다.
- Force Clean Build : 기존 Repository를 삭제하고 다시 전체 체크아웃을 받을지 여부를 선택한다.
- Add repository : Repository를 추가로 체크아웃 받도록 구성한다.
b. Maven Build & Package
Checkout 받은 소스를 Maven Build & Package한다.
- Executable : Executable에 등록된 컴포넌트를 선택한다. 빌드 방식 중 Maven, Gradle, Ant 등을 선택할 수 있으며, 현 Task에서는 Maven Build를 적용한다.
- Goal : build & package (option - properties) -Pdev
- Build JDK : 빌드 시 사용할 JDK를 선택한다.
- The build will produce test results : JUnit XML 형식의 테스크 결과가 없을 경우 빌드를 실패하도록 한다. Test Code를 생성하지 않고 빌드를 실행할 경우 해당 부분의 체크를 해제하고 Task를 생성해야 한다. 해제 하지 않을 경우, "no failed test found. a possible compilation error occurred."와 함께 Task 빌드 실패가 발생할 수 있다.
c. Docker Build
Docker Build Script를 통해 Docker login - Docker build - Docker push를 수행한다.
- Interpreter : Shell & Windows PowerShell & /bin/sh or cmd.exe
- Script location : Inline & File
- Script body
echo "Docker Build Start"
docker login -u ${bamboo.DOCKER_USERNAME} -p ${bamboo.DOCKER_PASSWORD} ${bamboo.IMAGE_REGISTRY}
docker build -t ${bamboo.IMAGE_REPO}:dev --rm --force-rm --pull --network host -f Dockerfile-dev .
docker push ${bamboo.IMAGE_REPO}:dev
echo "Docker Build End"
d. K8S Deploy
Docker Build로 생성한 이미지를 Kubernetes에 배포한다. K8S에 배포하기 위해서는 .kube/config 즉 kubeconfig 파일이 사전에 구성되어 있어야 한다.
여기서는 Amazon EKS에 배포하도록 한다. Script Task를 추가하고, 다음과 같이 Script Body를 작성한다.
echo "Deploy k8s-deploy Start"
kubectl apply -f deployment-dev.yaml
kubectl get all -n dev
kubectl get ingress -n dev
echo "Rollout k8s-deploy"
kubectl --kubeconfig=/root/.kube/config rollout restart deployment/k8s-configmap-deployment -n dev
kubectl get all -n dev
kubectl get ingress -n dev
echo "Deploy k8s-deploy End"
e. Build 실행
위와 같이 작성된 Task를 기반으로 빌드를 실행해 보자.
위와 같이 빌드가 정상 수행되는 것을 확인할 수 있다. 빌드 결과를 기반으로 다음과 같은 정보를 확인할 수 있다.
- Summary : Label 구성, 소스 형상관리 Revision, Tests Result
- Tests : Test Detail 정보
- Commits : 변경된 소스 형상관리 Commit 정보
- Logs : 로그파일 다운로드 또는 웹 페이지 View
f. Plan Summary
전체 Job 실행 결과에 대한 Plan Summary 정보와 최근 History, Statics 등을 확인할 수 있다.
이번 포스팅에서는 Bamboo의 Plan을 직접 구성하여 EKS에 배포해 보았다. 본 포스팅에서는 단순한 Plan과 Job의 구성으로 이루어져 있었지만, 이를 보다 다양하게 활용해 나갈 수 있다. 예를 들어 배포 방식의 다양화 단순히 Kubernetes의 Rolling Update가 아닌 Blue-Green / Canary 배포 등을 여러 Plan으로 구분하여 적용할 수 있으며, 승인 프로세스를 구성하거나, 환경별로 구분하여 Stage를 관리하는 등 다양한 방법으로 Bamboo Plan을 활용할 수 있다. 또한 Bitbucket 역시 Branch & Tag 기반 이외에 시점 기반 Commit을 관리할 수도 있다.
이와 같은 다양한 활용 방법에 대해서는 추가적인 포스팅으로 다루도록 하자.
'⑤ 개발, 데이터베이스 > ⓒ CI CD' 카테고리의 다른 글
Tekton Pipeline 설계 (0) | 2021.07.05 |
---|---|
Tekton pipeline 작성 (0) | 2021.07.03 |
Bitbucket/Bamboo 구축하기 (0) | 2021.01.24 |
[VueJS] CI/CD 배포 프로세스 수립하기 (0) | 2020.11.30 |
Git Branch & Tag를 활용한 프로젝트 배포 전략 마련하기 (2) | 2020.11.20 |
- Total
- Today
- Yesterday
- wildfly
- JEUS7
- webtob
- 아키텍처
- aa
- aws
- SA
- OpenStack
- Docker
- apache
- kubernetes
- Da
- 쿠버네티스
- k8s
- 마이크로서비스 아키텍처
- 오픈스택
- SWA
- git
- API Gateway
- node.js
- jeus
- MSA
- openstack tenant
- JBoss
- nodejs
- Architecture
- JEUS6
- 마이크로서비스
- openstack token issue
- TA
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |