배포/테스트 자동화 1
배포자동화를 하는 이유
- 여러가지 환경과 서버에 배포할 때 유리하다.
- 배포, 테스트에 드는 수작업이 줄어서 코딩에 집중할 수 있다.
-
여러가지 환경, 서버에 수동으로 배포한다면 그 만큼 시간이 걸리지만 한번 자동화를 해놓으면 그런 수고가 사라집니다. 테스트도 마찬가지입니다. 예를들면 python 라이브러리를 만들었는데 3.5, 3.6, 3.7 버전 전부 호환되는지를 테스트를 배포자동화를 한번 구축해놓으면 소스 commit 마다 할 수 있습니다.
-
배포자동화를 하기 이전에는 branch별로 AWS Elastic beanstalk에 config.yml을 수정하고 war 파일 만들고 EB deploy 명령으로 배포했습니다. 자잘하게 시간이 걸리고 실수의 여지도 있었지만 배포자동화를 한후에는 commit push만 하면 서버에 반영되서 편해졌습니다.
어떤걸 써야하나?
후보
- Jenkins
- Circle CI
- AWS CodePipeline
- Travis CI
위 4가지를 사용해보았습니다. 각자 장단점이 있지만 결론부터 말하면 결국 Travis를 사용했습니다. 처음 자료 조사를 할 때는 해당 글을 참고했습니다.
시행착오 1 Jenkins
시행착오 과정
- AWS에 프리티어로 EC2를 만든후 yum에 Jenkins를 추가해서 설치
- SBT 설치
- 젠킨스 파이프라인 작성 + Github 연동
- JVM 기반의 SBT와 Jenkins가 생각보다 메모리를 많이 사용해서 둘을 같이 사용하면 오버플로우가 발생해 EC2 볼륨을 키움
- 서버배포를 위해 pip로 Elasticbeanstalk cli를 설치함
- Elasticbeanstalk 줄여서 EB를 pip로 설치해서 권한이 꼬임 Jenkins는 jenkins-user라는 유저이고 EB는 ec2-user로 되어있었다
- Jenkins와 EB를 yum (같은 패키지 관리자) 다시 설치하고 그래도 꼬여있는 권한은 chmod로 수정함
- EB config.yml을 설정하는 shell 작성
- 배포자동화 성공
장단점
장점: 혼자 리눅스를 공부하기는 좋다, 리눅스를 잘한다면 다양한 커스터마이징이 가능함, 오픈소스이기에 무료
단점: 다양한 환경을 일일이 세팅하기가 힘들다, 리눅스를 못한다면 끔찍한 야근각, 배포자동화를 위해 서버가 필요함(과금)
결론: jenkins 자체는 무료지만 서버는 유료 리눅스사용에 미숙하고 개인 프로젝트가 아니라면 사용하는데 예매함
Jenkins 사용 후기
고등학교 1학년 이후로 오랜만에 리눅스로 이것저것 삽질하는 경험 자체는 생각보다 재미있지만 회사 프로젝트로 Jenkins를 쓰기에 시간이 너무 많이 들고 지속적인 서버관리가 필요했습니다. jenkins 자체도 무료지만 결국 서버비용이 들기에 리눅스에 미숙한 제가하기는 시행착오와 시간소모가 너무 컸습니다.
Jenkins를 사용하는 친구들을 찾아보아도 다들 와우의 전설 리로이 젠킨스만 알려줬습니다… 저 같은 신입수준에서 Jenkins를 사용해본 개발자는 적어서 조금 이라도 편하게 하려면 다른 CI를 사용해야합니다.
리이로이이~ 젠킨스!!!
시행착오 2 Circle CI
시행착오 과정
- 테스트를 위해 Circle CI 무료 버전을 사용
- Circle CI 자료조사; Docker 기반으로 환경을 구성하기에 Docker와 매우 흡사함
- docker 참조해서 circle.yml 작성
- 배포를 위해 pip로 EB cli룰 설치하는 코드를 yml에 추가
- EB의 config.yml을 만드는 쉘 작성
version: 2
jobs:
build:
docker:
- image: circleci/openjdk:8-jdk
working_directory: ~/repo
environment:
JVM_OPTS: -Xmx3200m
TERM: dumb
checkout:
post:
- git clone https://github.com/madup-inc/revenue-api
- git checkout develop
steps:
- checkout
- run: sbt package
##### deploy 생략
workflows:
version: 2
build_deploy:
jobs:
- build
- deploy
장단점
장점: Jenkins의 비해 매우 쉬움, 설치해야될 패키지가 많을 수록 빠름, 도커기반, 클라우드 환경, 빌드 배포 테스트를 각 step 별로 나눠서 가능함
단점: 도커와 다른게 없으므로 그냥 서버에 도커로 배포자동화를 하는것과 무엇이 다른지 의문이 듬, AWS와의 연동은 가능하지만 불편함을 느낌
결론: 도커
Circle CI 사용 후기
빌드, 배포, 테스트를 각 step별로 할려면 Jenkins에서는 groovy코드를 짜야하고 Travis CI에서는 아직 베타 기능인데 yml에서 간단하게 사용할 수 있는점이 좋있다. 하지만 AWS 중에 EB 와의 연동이 불편했고 도커와 다른점을 느끼기 힘들었다. 그래서 일단 다른 툴도 써보기로 했다.
시행착오 3 AWS CodePipeline
시행착오 과정
- 사수인 제이슨이 먼저 pipeline을 사용함
- 그 동안에 너무 고생을 많이 해서 제이슨의 yml을 참조함
- Github - AWS CodeBuild (새로 만든 부분) - EB 서버 형태로 Pipeline 작성
- 도커를 참조해서 code build에 sbt를 설치하는 yml 작성
- 처음에는 file을 안쓰고 그 이후에는 file 경로가 잘못되서 제이슨의 도움으로 직접 eb의 톰캣을 확인하고 수정함
- 제대로 파일을 명시한 이후에는 war 파일이 아니라 소스가 톰캣에 들어있는 상황을 확인
version: 0.2
env:
variables:
PACKAGE: revenue-api
SBT_VERSION: 0.13.16
phases:
install:
commands:
- curl -L -o sbt-${SBT_VERSION}.deb https://dl.bintray.com/sbt/debian/sbt-${SBT_VERSION}.deb && \
- dpkg -i sbt-${SBT_VERSION}.deb && \
- rm sbt-${SBT_VERSION}.deb && \
- apt update && \
- apt install sbt && \
- sbt sbtVersion
build:
commands:
- sbt package
artifacts:
discard-paths: yes
files:
- target/scala-2.12/revenue-api_2.12-0.1.0-SNAPSHOT.war
장단점
장점: EB 배포 자체는 별다른 노력이 필요없음, 간단함
단점: 이런저런 시행착오 과정에서 톰캣 설정을 많이 확인함
결론: 다 좋은데, 이상하게 삽질을 많이 하게됨
pipeline 사용 후기
심플함은 좋았으나 마지막 6번 문제를 해결하고 싶지않아 결국 Travis CI 를 쓰기로 결정했습니다.
후기
고등학교 시절 처음 써보는 언어로 프로젝트를 했었습니다. (주로 PHP, python3) 처음에는 무작적 코딩부터 시작했다가 코드량이 늘어나면서 나중에는 소스관리도 안되고 개발하는 시간보다는 리서치와 빌드, 배포로 시간을 다 까먹고 프로젝트가 망한 경험이 있습니다. 그 후로 코딩 외적인 주석이나 테스트, 배포 자동화, 일정관리의 중요성을 깨달았지만 별다른 공부를 못했었습니다. 그러다 이번에 배포자동화 툴 Jenkins , Circle CI, AWS CodePipeline (CodeBuild), Travis CI 를 사용하면서 리눅스와 shell을 공부하는 계기가 되었습니다.
