4.5. Bastion 에서 빌드·배포
어떨 때 쓰는가
- 빌드 옵션을 세밀하게 지정해야 할 때
- 자동화 스크립트에 빌드를 넣을 때
- Console 이나 Jenkins 로 안 되는 예외 상황을 처리할 때
서버 접속 권한이 필요하므로 보통 개발·운영 담당자가 씁니다.
Bastion 이란
클러스터를 다루는 도구가 설치된 관리용 서버 입니다. 클러스터에 직접 접속하지 않고 이 서버를 거쳐 작업합니다.
여기에는 다음이 준비되어 있습니다.
| 도구 | 하는 일 |
|---|---|
| kubectl | 클러스터를 다루는 명령어 도구 |
| 접속 설정(kubeconfig) | 어느 클러스터에 어떤 권한으로 접속할지 |
| S2I 빌드 도구 | 소스에서 이미지를 만듭니다 |
| 빌드·배포 스크립트 | 위 도구들을 순서대로 실행합니다 |
왜 별도 서버를 두는가
클러스터 API 는 아무 곳에서나 접근할 수 있으면 안 됩니다. Bastion 하나만 접근을 허용하고 나머지는 막으면 관리 범위가 좁아집니다.
| 있으면 | 없으면 |
|---|---|
| 접근 경로가 하나라 통제가 쉽습니다 | 여러 PC 에서 클러스터에 직접 접근합니다 |
| 접속 기록이 한곳에 남습니다 | 누가 무엇을 했는지 흩어집니다 |
| 도구 버전이 통일됩니다 | 사람마다 버전이 달라 결과가 다릅니다 |
접속
접속 주소와 계정은 설치 담당자에게 확인하십시오. SSH 로 접속합니다.
접속한 뒤 클러스터에 연결되는지 먼저 확인하십시오. 노드 목록이 나오면 정상입니다.
디렉터리 구조
애플리케이션 빌드·배포 스크립트는 정해진 위치에 있습니다.
정확한 경로는 설치 구성에 따라 다릅니다. 접속한 뒤 목록을 확인하십시오.
스크립트가 하는 일
설정은 두 층으로 나뉩니다. 위층 build-env.sh 는 레지스트리 주소처럼 모든 애플리케이션에
공통인 값, 아래층 env.sh 는 그 애플리케이션에만 해당하는 값을 갖습니다.
| 파일 | 담는 것 |
|---|---|
build-env.sh | 레지스트리 주소·계정, 이미지가 들어갈 저장소 이름. 소스에서 이미지 태그를 만드는 공통 함수도 여기 있습니다 |
env.sh | 배포할 네임스페이스, Deployment 이름, Git 주소, 빌더 이미지, 라이브러리 저장소 주소 |
나머지 다섯은 실행 스크립트입니다.
| 스크립트 | 하는 일 |
|---|---|
build-app.sh | 소스를 내려받고 S2I 로 빌드해 이미지를 만듭니다 |
build-push.sh | 만든 이미지를 레지스트리에 올립니다 |
build-deploy.sh | 클러스터의 Deployment 이미지를 바꾸고 롤아웃이 끝날 때까지 기다립니다 |
build-history.sh | 그 Deployment 의 배포 이력을 출력합니다 |
build-rollback.sh | 직전 배포로 되돌리고 완료를 기다립니다 |
이미지 태그는 사람이 정하지 않고 소스에서 자동으로 만들어집니다. build-env.sh 의
공통 함수가 Git 태그와 커밋 번호를 읽어 <Git 태그>-<커밋 앞 7자리> 형식으로 만듭니다.
빌드와 배포가 같은 함수를 쓰므로 두 값이 어긋나지 않고, 배포된 이미지만 보고 어느 커밋인지
바로 알 수 있습니 다.
설정값은
build-env.sh와env.sh에서만 고칩니다. 각 실행 스크립트에 직접 적으면 빌드한 태그와 배포하는 태그가 어긋나 엉뚱한 이미지가 배포됩니다.
빌드와 배포 실행
차례로 실행합니다. 소스 최신화는 build-app.sh 안에 들어 있어 따로 하지 않아도 됩니다.
cd <설치 경로>/workspaces/apps/<네임스페이스>/<앱 이름>
# 1. S2I 빌드 (소스 최신화 포함)
./build-app.sh
# 2. 이미지를 레지스트리에 올리기
./build-push.sh
# 3. 클러스터에 배포
./build-deploy.sh
배포한 뒤 문제가 생기면 같은 자리에서 되돌립니다.
./build-history.sh # 어떤 이력이 있는지 확인
./build-rollback.sh # 직전 배포로 되돌리기
build-rollback.sh 는 직전 배포로만 되돌립니다. 더 이전으로 가려면 Console 의 배포
히스토리에서 리비전을 골라야 합니다(3.2 장).
각 단계가 성공했는지 확인하고 다음으로 넘어가십시오. 빌드가 실패했는데 배포를 실행하면 이전 이미지가 그대로 배포되어, 고친 내용이 반영되지 않은 채 "배포는 성공" 으로 끝납니다.
단계별로 확인할 것
| 단계 | 실패하면 볼 것 |
|---|---|
build-app.sh — 소스 내려받기 | 저장소 접근 권한, 브랜치 이름 |
build-app.sh — 빌드 | 컴파일 오류, 의존 라이브러리 내려받기 실패 |
build-push.sh | 레지스트리 로그인 상태, 프로젝트 권한 |
build-deploy.sh | 네임스페이스 존재 여부, Deployment 이름, 자원 한도 (8.1 장) |
빌드 결과는 화면에 그대로 출력됩니다. 오류가 나면 마지막 부분을 먼저 보십시오.
Console 에서 결과 확인
명령어로 배포해도 결과는 Console 에서 확인 합니다.
| 확인할 것 | 어디에서 |
|---|---|
| 파드가 떴는지, 로그 | 워크로드 > Pod (3.1 장) |
| 배포된 이미지 태그 | 워크로드 > 배포 상세 (3.2 장) |
| 외부 접속 주소 | 네트워킹 > 인그레스 (5.1 장) |
| 자원 연결 관계 | 토폴로지 (2.2 장) |
배포한 이미지 태그가 방금 올린 것과 같은지 Deployment 상세에서 확인하십시오. 태그가
latest 면 어떤 이미지가 떠 있는지 알 수 없습니다.
주의할 것
- 여러 사람이 같은 Bastion 을 씁니다. 다른 사람의 작업 중에 스크립트를 실행하면 서로 영향을 줄 수 있습니다.
- 소스 디렉터리에서 직접 코드를 고치지 마십시오. Git 저장소에 반영되지 않은 변경으로 이미지를 만들면 다음 빌드에서 사라집니다.
- 배포에 문제가 생기면 Console 에서 이전 버전으로 되돌릴 수 있습니다(3.2 장).