본격적인 배포 전 준비
배포된 프로젝트에서 사용할 DB는 앞글에서 설정한 RDS이다. 이는 mariaDB이기 때문에
build.gradle에 추가해주자.
implementation 'org.mariadb.jdbc:mariadb-java-client'
운영용 applcation-real.properties 구성하기
spring.profiles.include=oauth,real-db
spring.jpa.properties.hibernate.dialect=org.hibernate.dialect.MySQL5InnoDBDialect
spring.session.store-type=jdbc
그리고 EC2에서 배포할 springboot 프로젝트의 포트 8080 인바운드도 확인해주자.
아마 되어있을 것이다. 만약 안 되어있다면 8080포트는 모든IP에 대해 열어주자.
CI/CD
CI-Git, SVN 같은 VCS 시스템에 PUSH가 되면 자동으로
테스트와 빌드를 수행해 배포 파일을 만드는 과정
CD- CI를 통해 만들어진 배포파일을 자동으로 운영서버에 로드하는 것
TRAVIS CI
깃허브에서 제공하는 무료 CI 서비스
카드 등록 + 1달러는 기본적으로 내야함
깃허브로 로그인하면 연결 됨
상세 설정은 푸쉬되는 프로젝트의 .travis.yml로 진행됨
language: java
jdk:
- openjdk11
branches:
only:
- master
# Travis CI 서버의 Home
cache:
directories:
- '$HOME/.m2/repository'
- '$HOME/.gradle'
script: "./gradlew clean build"
before_install:
- chmod +x gradlew
# CI 실행 완료시 메일로 알람
notifications:
email:
recipients:
- 메일주소. ex: abc@naver.com
프로젝트 푸쉬 후 travis 확인 ( 약 10초 후 자동으로 build 함)
배포 과정
AWS S3는 AWS에서 제공하는 일종의 파일서버입니다.
이미지파일같은 정적파일이나 travis가 만든 배포파일들을 관리하는 기능을 지원합니다.
실제 배포는 AWS의 CodeDeploy가 하지만, CodeDeploy는 저장기능이 없습니다.
그래서 Travis CI가 빌드한 결과(배포파일)을 S3가 저장하고,
CodeDeploy가 S3로 부터 배포파일을 가져와 배포합니다.
※CodeDeploy는 배포 뿐만 아니라 빌드도 할 수 있습니다.
하지만 CodeDeploy에서 빌드,
배포를 전부 하게 된다면 배포만 필요한 경우 대응하기 어렵습니다.
빌드와 배포를 분리 해 놓으면 빌드되어 만들어진 Jar파일을 재사용하면 되지만,
분리되어있지 않으면, 배포할 때 항상 빌드 먼저 한 후 배포를 하게 됩니다.
그래서 왠만하면 빌드와 배포는 분리해야 합니다.
Travis Ci 와 AWS S3 연동하기
일반적으로 AWS 서비스에 외부 서비스가 접근할 수 없습니다.
그래서 접근 가능한 권한을 가진 key를 생성해서 사용해야 합니다.
AWS에서는 이러한 인증과 관련된 기능을 제공하는 서비스로
IAM(Identiy and Access Management)가 있습니다.
검색창에 IAM을 검색 후 사용자-> 사용자 추가 버튼을 클릭합니다
사용자 이름을 입력한 후 다음버튼을 누릅니다
권한 설정에서 직접 정책 연결을 클릭 한후
S3full, CodeDeployFull을 검색해서 체크합니다.
지금 만드는 하나의 IAM으로 S3, CodeDeploy에 대해서
외부서비스가 접근 할 수 있게 됩니다.
마지막으로 태그까지 추가하고, IAM을 생성합니다.
(다음 글에서도 계속 ch로 태그를 만듭니다.
태그는 리소스를 식별하는데 샤용되기 때문에 이름을 맞춥니다.)
이렇게 만들어진 IAM에 들어가 보안자격증명 탭에서 액세스키를 만듭니다.
AWS 컴퓨팅 서비스에서 실행되는 애플리케이션을 클릭합니다.
여기서의 태그는 설명일 뿐 큰 의미는 없지만, 위의 태그와 맞춰줍시다.
다음과 같이 키가 생성되면 이 키를 Travis Ci에서 사용합니다.
(비밀 액세스 키는 절대 외부에 공개되서 안됩니다.
그리고 비밀액세스 키 복사할 때 표시 안하고 복사하면 이상하게 복사되기때문에
표시 하고 복사하도록 합니다.)
Travis로 가서 More options에 Setting을 누릅니다.
Environment Variables에서 AWS_ACCESS_KEY, AWS_SECRET_KEY를 등록해줍니다.
여기에 등록된 값들은 이제 .travis.yml에서 $AWS_ACCESS_KEY 으로 사용합니다
S3버킷 생성
S3는 Travis CI에서 생성된 Build 파일을 저장하도록 구성하겠습니다.
S3에 저장된 Build파일은 이후 AWS의 CodeDeploy에서 배포할 파이로 가져가도록 구성합니다.
AWS 검색창에 S3를 입력한 후 버킷 만들기 버튼을 누릅니다.
버킷이름은 이 버킷에 배포할 Zip 파일이 모여있는 장소임을 의미하도록 짓는 것을 추천합니다.
보안 관련 사항으로는 퍼블릭 엑세스 차단(default)을 합니다.
퍼블릭 엑세스가 차단돼도 우리는 IAM에서 발급받은 키를 이용해 접근 가능합니다.
이 후 버킷만들기를 클릭합니다.
.travis.yml에 S3 설정내용 추가하기
Travis CI를 통해 프로젝트에 대한 배포파일을 만듭니다.
그리고 S3는 이 배포파일을 저장합니다.
일단 여기까지 Travis CI와 S3의 연동만 확인해봅시다.
.travis.yml
language: java
jdk:
- openjdk11
branches:
only:
- master
# Travis CI 서버의 Home
cache:
directories:
- '$HOME/.m2/repository'
- '$HOME/.gradle'
script: "./gradlew clean build"
before_install:
- chmod +x gradlew
# CI 실행 완료시 메일로 알람
notifications:
email:
recipients:
- 완료 받을 메일
before_deploy:
- zip -r changhee * # AWS에서의 무언가가 아닌 내 프로젝트이름
- mkdir -p deploy
- mv changhee.zip deploy/changhee.zip # 파일이름도 프로젝트이름 .
deploy:
- provider: s3
access_key_id: $AWS_ACCESS_KEY # Travis repo settings에 설정된 값
secret_access_key: $AWS_SECRET_KEY # Travis repo settings에 설정된 값
bucket: ch-build # S3 버킷
region: ap-northeast-2
skip_cleanup: true
acl: private # zip 파일 접근을 private으로
local_dir: deploy # before_deploy에서 생성한 디렉토리
wait-until-deployed: true
다음로그가 나온다면 Travis CI의 빌드가 성공한 것입니다.
그리고 S3 버킷을 가보면 Travis CI에서 만든 배포파일이 업로드가 된것을 확인할 수 있습니다.
여기까지 Travis CI와 S3의 연동을 완료했습니다.
다음글에선 CodeDeploy까지 함께 연동하도록 하겠습니다.