#4 배포 파이프라인 구성 #7
Conversation
Actuator 테스트를 위해 csrf, formLogin 기능을 무효화한 기본 설정 파일을 생성했습니다.
헬스 체크를 위한 Actuator 의존성을 추가했습니다. 열릴 엔드포인트는 [health, info] 입니다.
특정 브랜치에 Push Event 발생 시 Github Runner VM에 의해 배포 파이프라인이 동작합니다.
EC2_HOST -> DEV_EC2_HOST EC2_USERNAME -> DEV_EC2_USERNAME EC2_PRIVATE_KEY -> DEV_EC2_PRIVATE_KEY EC2_SSH_PORT -> DEV_EC2_SSH_PORT
Setup Java 17에서 distribution 설정이 없던 버그를 수정했습니다.
Java Buildpack 4.0 기본 메모리 옵션이 t2.micro 스펙을 넘어서기 때문에 free tier 환경에 맞게 수정했습니다.
|
코드 리뷰 요청합니다 🙆 @h-beeen |
There was a problem hiding this comment.
코드리뷰에 앞서, Pn룰을 사용해 코드리뷰를 진행해보고자 합니다.
저도 처음으로 도입하는 룰인 만큼, 조금 서투른 리뷰더라도 감안해서 예쁘게 반영해주시면 좋을 것 같습니다.
Pn 룰은 Reviewer가 피드백을 남길 때 Assignee에게 얼마나 해당 피드백에 대해 강조하고 싶은 지 표현하기 위한 규칙입니다.
P1 : 꼭 반영해 주세요 (Request Changes) - 이슈가 발생하거나 취약점이 발견되는 케이스 등
P2 : 반영을 적극적으로 고려해 주시면 좋을 것 같아요 (Comment)
P3 : 이런 방법도 있을 것 같아요~ 등의 사소한 의견입니다 (Chore)
- 참고자료 : 코드 리뷰 문화를 리뷰해봐요
명범님께서도 편한 코드리뷰 방식을 채택하셔서 자유롭게 제 코드를 리뷰해주신다면
코드 품질 향상에 큰 도움이 될 것 같습니다 🌱
This comment was marked as duplicate.
This comment was marked as duplicate.
Sorry, something went wrong.
There was a problem hiding this comment.
P2
Develop 브랜치에 푸쉬되는 트리거를 기점으로, 개발서버 EC2에 서버를 올리는 플로우로 인식했어요.
다만 ./gradlew test 만으로, 해당 코드의 정상적인 빌드와 실행 여부를 모두 파악하기에는 어려울 수도 있다고 생각이 들어요.
./gradlew clean build -i와 같이, 깃허브 액션으로 빌드 테스트 + 로그까지
한 번에 확인할 수 있는 방식도 좋을 것 같아 제안드립니다 :)
There was a problem hiding this comment.
bootBuildImage가 빌드에 필요한 태스크를 진행해주기 때문에 따로 build 태스크를 넣지 않았습니다!
| ### local properties ### | ||
| /src/main/resources/application.yml |
There was a problem hiding this comment.
서브모듈 핸들링 이슈 ㅠ
수정해주셔서 감사합니다 :)
| tasks.named('bootBuildImage') { | ||
| environment["BPE_DELIM_JAVA_TOOL_OPTIONS"] = " " | ||
| environment["BPE_APPEND_JAVA_TOOL_OPTIONS"] = "-XX:+ExitOnOutOfMemoryError -XX:MaxDirectMemorySize=10M " + | ||
| "-XX:MaxMetaspaceSize=100M -XX:ReservedCodeCacheSize=60M -Xss256K" | ||
|
|
||
| def dockerhubId = project.property("DOCKERHUB_ID") | ||
| def dockerhubToken = project.property("DOCKERHUB_TOKEN") | ||
|
|
||
| imageName = dockerhubId + "/${project.name}" | ||
| publish = true | ||
| docker { | ||
| publishRegistry { | ||
| username = dockerhubId | ||
| password = dockerhubToken | ||
| } | ||
| } |
There was a problem hiding this comment.
궁금증 ❓
보통 EC2 컨테이너를 사용하더라도, 도커 컨테이너를 띄우지 않고 작업을 했던 경험이 많아요.
도커 컨테이너를 띄우고 연동 했을 때, 도커를 사용하지 않았을 때 보다 얻을 수 있는 장점이 어떤 점이 있을까요?
There was a problem hiding this comment.
저희가 사용 중인 프리티어 인스턴스 하나로 사용하면 Standalone이 더 유리했겠네용
제가 항상 도커로 배포하는 것만 진행해서 이 부분은 생각하지 못했습니다..
그래도 도커를 사용했을 때 얻을 수 있는 장점에 대해 확장성이 있겠네요.
저희가 만약에 서비스가 잘 나가서 분산환경, 오토스케일링을 적용한다면 아키텍처 확장에는 도커가 편할 것 같다는 생각이 듭니다.
그러면 혹시 의견을 주실 수 있을까요?
Standalone 방식을 사용한다면 리소스 격리를 하지 않아 온전히 EC2의 성능을 이끌어낼 수 있을 것 같습니다.
도커를 사용한다면 추후에 아키텍처 확장 시 쉽게 확장이 가능하리라 생각합니다.
어떤 것이 더 나을까요??
There was a problem hiding this comment.
음.. 일단 질문의 본질은, 도커의 확장성 부분에 있어서 여쭈었던 질문입니다!
분산환경이나 오토스케일링을 고려해보거나 적용해본 경험이 경험이 없어서 여쭤봤던 사항입니다.
현재 개발 환경에서는 EC2 환경에서 말씀주신 standalone도 나쁘지 않을 것 같다는 의견도 있는데요.
저도 도커를 이용한 인프라 작업이 처음인 만큼, 이번 프로젝트에서는 도커 컨테이너를 활용한 프로젝트를 진행해보고 싶습니다!!
|
성공적으로 Merge 되었습니다. Shout out to @h-beeen 😉 |
Issue ticket link and number
Describe changes
Summary
배포 파이프라인 과정
git submodule update --remote --recursive명령어를 통해 설정 정보를 불러온다../gradlew test명령어를 통해 테스트를 진행한다../gradlew clean bootBuildImage -PDOCKERHUB_ID=$DOCKERHUB_ID -P DOCKERHUB_TOKEN=$DOCKERHUB_TOKEN명령어를 통해 스프링 부트 프로젝트를 이미지화한 후, Dockerhub에 업로드한다. (이 때DOCKERHUB_ID,DOCKERHUB_TOKEN인자를 github repo secrets에서 가져온다.)Notification for Reviewer
@h-beeen