개발블로그

aws codebuild로 패키징하기 본문

AWS

aws codebuild로 패키징하기

개발자수니 2020. 2. 13. 11:07

spark application을 빌드하고, packaging된 jar파일을 S3에 업로드해야 했다. 

이 때, aws codebuild를 이용하기로 했다.

 

먼저 aws codebuild 프로젝트를 생성한다. 

소스는 Github에서 관리하고 있으므로 소스 공급자에서 GitHub을 선택한다. 

 

하나의 Repository가 Submodule로 여러 Spark application을 가지고 있는 구조이기 때문에 추가 작업을 해주었다. 

Submodule인 cf-item2item 내에 있는 buildspec.yml을 참조하여 build하라는 설정을 준 것이다. 

 

buildspec.yml은 다음과 같다.

version: 0.2

phases:
  install:
    runtime-versions:
      java: corretto8
  build:
    commands:
      - cd cf-item2item
      - mvn clean package
artifacts:
  files:
    - cf-item2item/target/cf-item2item-1.0-RELEASE-jar-with-dependencies.jar
  discard-paths: yes

cache:
  paths:
    - '/root/.m2/**/*'

9라인을 보면, submodule로 경로를 이동시킨 후에 packaging하는 것을 확인할 수 있다. 

그렇지 않으면 repository root 경로에서 packaing하려 하기 때문에 원하는 결과가 나오지 않는다. 

 

아티팩트는 packaging한 Jar file을 저장할 위치를 저장할 곳을 설정하는 곳이다. 

S3에 저장을 하기 위해 bucket을 미리 만들어두었다. 

"이름" 란은 jar파일이 저장될 bucket의 최상단 경로를 지정하는 란이다. 

 

아티팩트의 나머지 부분은 default 값으로 설정했는데, 추가 구성의 캐시만 설정해줬다. 

캐시는 매우 중요하다. 캐시를 설정해주지 않으면, maven central로부터 소스를 매번 다운로드 받는다. 

그리고 이 차이가 크다. 

아래 그림을 보면 cache 없을 때에 5분 52초 가량 시간이 걸렸고, cache를 사용한 결과 1분 3초가 걸렸음을 확인할 수 있다.

 


현 구조에서 문제가 없는 것은 아니다. 

하나의 repository가 여러 submodule을 가지고 있는 구조가 될 수 있다는 것을 codebuild는 염두하지 않은 것 같다.

위와 같은 방식에서는 source를 모두 다 가지고 온 후, 하나의 submodule만 패키징하고 있다. 

source를 모두 가지고 온다는 것이 큰 문제가아닐까 싶다. 

repository의 특정 directory의 소스만 가지고 오면 퍼펙트인데, 이 부분이 아쉽다. 

Comments