4.1. 빌드 방식 선택
어떨 때 읽는 장인가
빌드를 처음 시작하기 전에 읽습니다. 세 가지 경로 중 무엇을 쓸지 여기서 정하고, 정한 경로의 장으로 넘어갑니다.
컨테이너 이미지란
애플리케이션과 그것을 실행하는 데 필요한 것(런타임, 라이브러리, 설정)을 하나로 묶은 파일 입니다.
이미지가 있으면 어느 서버에서든 같은 방식으로 실행됩니다. "내 PC 에서는 되는데 서버에서는 안 된다" 는 문제가 줄어듭니다. 실행 환경이 이미지 안에 함께 들어 있기 때문입니다.
파드는 이미지에서 컨테이너를 만들어 실행합니다(3.1 장). 그래서 배포하려면 먼저 이미지가 있어야 합니다.
이미지를 만드는 두 방법
| 방법 | 설명 | 필요 한 것 |
|---|---|---|
| Dockerfile | 어떤 파일을 넣고 어떤 명령을 실행할지 직접 적습니다 | Dockerfile 작성 지식 |
| S2I | 소스 코드만 주면 알아서 만듭니다 | 없음 |
Dockerfile 은 자유도가 높지만 언어·빌드 도구마다 다시 써야 하고, 잘못 쓰면 이미지가 커지거나 보안 문제가 생깁니다.
S2I 는 그 부분을 이미 만들어 둔 것을 씁니다.
S2I 란
S2I(Source-to-Image)는 소스 코드에서 컨테이너 이미지를 바로 만드는 방식 입니다.
Dockerfile 을 쓰지 않아도 언어와 빌드 도구에 맞는 빌더 이미지 가 컴파일과 이미지 생성을 대신합니다.
| Dockerfile | S2I | |
|---|---|---|
| 준비할 것 | Dockerfile 을 씁니다 | 빌더 이미지를 고릅니다 |
| 빌드 방식이 팀마다 | 제각각입니다 | 통일됩니다 |
| 보안 기준 반영 | 각자 챙겨야 합니다 | 빌더 이미지에 이미 반영되어 있습니다 |
| 자유도 | 높습니다 | 빌더가 지원하는 범위 안에서 |
S2I 가 하는 일
동작 순서는 이렇습니다.
| 순서 | 하는 일 |
|---|---|
| 1 | Git 저장소에서 소스를 가져옵니다 |
| 2 | 빌더 이미지가 소스를 컴파일합니다 (Maven, Gradle, npm 등) |
| 3 | 결과물을 실행 이미지에 넣어 컨테이너 이미지를 만듭니다 |
| 4 | 만든 이미지를 레지스트리(Harbor)에 올립니다 |
레지스트리에 올리는 것이 마지막 단계입니다. 이미지는 클러스터가 가져갈 수 있는 곳에 있어야 배포됩니다. 로컬에만 만들어 두면 파드가 이미지를 못 찾습니다.
빌더 이미지란
컴파일 도구와 실행 환경이 함께 들어 있는 이미지 입니다. 언어와 빌드 도구 조합마다 따로 있습니다.
| 애플리케이션 | 빌더가 담는 것 |
|---|---|
| Java 웹 (WAR) | JDK + Maven/Gradle + Tomcat |
| Java 실행형 (JAR) | JDK + Maven/Gradle + JRE |
| Node.js | Node.js + npm |
| Python | Python + pip |
빌더 이미지는 조직이 미리 만들어 등록해 둡니다. 폐쇄망에서는 등록된 것만 쓸 수 있습니다.
실행 경로
COP 에서 S2I 빌드를 실행하는 방법은 여러 가지입니다. 어느 경로를 쓰든 만들어지는 이미지는 같습니다.
| 경로 | 어디서 | 이 문서 |
|---|---|---|
| Console | 웹 화면에서 빌드 설정을 만들고 실행 | 4.2 장·4.3 장 |
| Jenkins | Jenkins 웹 화면에서 Job 실행 | 4.4 장 |
| Bastion | 서버에 접속해 명령어 실행 | 4.5 장 |
| 다른 CI 도구 | GitLab CI·GitHub Actions 등에서 같은 스크립트 호출 | 4.6 장 |
| ArgoCD | Git 저장소를 기준으로 배포 (GitOps) | 4.7 장 |
어느 경로를 쓰든 배포 순서를 어떻게 잡을지는 따로 정합니다 — 롤링 업데이트·Recreate· 블루그린·카나리 네 가지를 4.8 장에서 비교합니다.
뒤의 두 경로는 앞의 것을 대신하는 것이 아니라 그 위에 얹힙니다. Jenkins·Bastion·다른 CI 도구는 모두 같은 셸 스크립트를 부르고(4.5 장), ArgoCD 는 그 중 배포 단계만 Git 기준으로 바꿉니다.
CI 도구는 바꿔 쓸 수 있습니다
빌드와 배포 논리가 셸 스크립트에 들어 있고 CI 도구는 그것을 부르기만 합니다. COP 가
기본으로 넣어 주는 Jenkins 작업도 cd <디렉터리> 뒤에 스크립트를 실행하는 것이 전부입 니다.
그래서 사내 표준 CI 도구가 따로 있으면 그것을 그대로 쓰면 되고, 새로 만들 것은 파이프라인
정의 파일 하나뿐입니다(4.6 장).
고르는 기준
| 상황 | 권장 경로 |
|---|---|
| 화면에서 간단히 빌드하고 결과를 바로 보고 싶다 | Console |
| 빌드한 이미지를 바로 배포까지 하고 싶다 | Console |
| 빌드와 배포를 하나로 묶고 승인·롤백까지 관리해야 한다 | Jenkins |
| 정해진 시각에 되풀이해야 한다 | Jenkins |
| 새 애플리케이션의 빌드·배포 구성을 한 번에 만들어야 한다 | Jenkins |
| 자동화 스크립트에 넣거나 세부 옵션을 직접 지정해야 한다 | Bastion |
| 앞의 두 방법으로 안 되는 예외 상황 | Bastion |
| 이미 쓰는 CI 도구가 있어 Jenkins 를 새로 쓸 수 없다 | 다른 CI 도구 |
| 배포 이력을 Git 에 남기고 승인 절차로 통제해야 한다 | ArgoCD |
| 클러스터가 정해 둔 설정에서 벗어나지 않게 해야 한다 | ArgoCD |
Console 은 빌드할 수 있는 빌더 이미지가 화면에 등록된 것으로 한정됩니다. 목록에 없는 빌더가 필요하면 Jenkins 나 Bastion 을 쓰거나 운영 담당자에게 등록을 요청하십시오.
권한도 다릅니다.
| 경로 | 필요한 권한 |
|---|---|
| Console | 해당 네임스페이스의 빌드 설정 편집 권한 (7.1 장) |
| Jenkins | Jenkins 계정과 Job 실행 권한 |
| Bastion | 서버 접속 계정 |
이 문서의 예시
4.2 장부터 4.8 장까지 같은 애플리케이션을 씁니다.
| 항목 | 값 |
|---|---|
| 애플리케이션 | 전자정부 표준프레임워크 샘플 |
| 네임스페이스 | egov |
| Jenkins Job | 20-egov-build(빌드), 30-egov-deploy(배포) |
경로가 달라도 결과가 같다는 것을 확인하려면 세 장을 차례로 읽으십시오.