Joonseok week10 - #112
Conversation
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 6825dd8fea
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| @@ -0,0 +1,59 @@ | |||
| name: CD | |||
There was a problem hiding this comment.
현재 cd.yml이 Joonseok/.github/workflows 아래에 있어 GitHub Actions가 워크플로로 읽지 않습니다. GitHub는 저장소 루트의 .github/workflows를 검색해 실행할 워크플로를 찾기 때문에(GitHub Docs), CI가 성공해도 이 CD는 트리거되지 않습니다. 파일은 루트 .github/workflows/cd.yml로 옮기고, Joonseok 하위 경로는 각 step의 working-directory나 파일 경로로 표현해 보세요. 다음에는 Actions의 워크플로 발견 규칙과 모노레포 경로 기준을 같이 공부하면 좋겠습니다.
Useful? React with 👍 / 👎.
| username: ${{ secrets.SERVER_USER }} | ||
| key: ${{ secrets.SERVER_SSH_KEY }} | ||
| port: 22 | ||
| source: "docker-compose.yml,nginx/conf.d/default.conf" |
There was a problem hiding this comment.
이 source는 체크아웃된 저장소 루트를 기준으로 docker-compose.yml과 nginx/conf.d/default.conf를 찾는데, 저장소 전체 파일 목록(rg --hidden --files)을 확인해도 docker-compose.yml은 없고 nginx 설정은 Joonseok/nginx/conf.d/default.conf에만 있습니다. CD가 실행되면 scp 단계에서 필요한 배포 파일을 못 복사해 이후 docker compose 흐름도 검증되지 않습니다. compose 파일을 커밋하고 Joonseok/docker-compose.yml,Joonseok/nginx/conf.d/default.conf처럼 실제 위치와 맞추세요. 다음 학습 포인트는 GitHub Actions의 working directory와 배포 아티팩트 경로입니다.
Useful? React with 👍 / 👎.
| username: ${{ secrets.SERVER_USER }} | ||
| key: ${{ secrets.SERVER_SSH_KEY }} | ||
| port: 22 | ||
| envs: BACKEND_IMAGE |
There was a problem hiding this comment.
script에서는 ${FASTAPI_IMAGE}로 .env를 만들고 docker pull도 하는데, appleboy/ssh-action에서 원격 셸로 넘길 변수 목록인 envs에는 BACKEND_IMAGE만 있습니다(ssh-action 문서). 이 상태에서는 원격 서버에서 FASTAPI_IMAGE가 빈 값이 되어 FASTAPI_IMAGE=:latest 및 docker pull :latest가 실행될 수 있습니다. envs: BACKEND_IMAGE,FASTAPI_IMAGE로 맞추거나 GitHub expression으로 값을 직접 작성해 보세요. 다음에는 GitHub runner 환경변수와 SSH 원격 셸 환경의 차이를 공부하면 좋겠습니다.
Useful? React with 👍 / 👎.
| ARG JAR_FILE=build/libs/*.jar | ||
| COPY ${JAR_FILE} project.jar |
There was a problem hiding this comment.
Spring Boot Gradle 플러그인은 기본적으로 실행 가능한 bootJar와 -plain.jar를 함께 만들기 때문에(Spring Boot Docs), build/libs/*.jar는 보통 두 JAR에 매칭됩니다. Docker COPY는 여러 소스를 파일명 project.jar 하나로 복사할 수 없어 CI의 이미지 빌드가 실패합니다. jar { enabled = false }로 plain jar를 끄거나 bootJar 산출물 이름을 고정한 뒤 명시 경로를 복사하세요. 다음에는 bootJar와 plain jar의 역할 차이를 공부하면 좋겠습니다.
Useful? React with 👍 / 👎.
kjhh2605
left a comment
kjhh2605
left a comment
There was a problem hiding this comment.
[키워드 조사]
클라우드 컴퓨팅, 환경변수, Docker 이미지와 jar, 세션 전략, Blue-Green 배포까지 Week10 핵심 주제를 폭넓게 정리한 점이 좋습니다. 다만 일부 설명이 개념 소개 수준에 머물러 있어서 실제 Spring 배포 흐름과 연결하는 보완이 필요합니다. 예를 들어 GitHub Secrets, 서버 환경변수, application-*.yml, Docker ENV/ARG가 각각 어느 시점에 값을 주입하는지 비교하면 이해가 더 선명해집니다. 추가로 AWS EC2, 보안 그룹, Docker Compose, 리버스 프록시, 헬스 체크, 이미지 태그 전략을 함께 정리하는 것을 권장합니다.
[코드 리뷰]
Dockerfile, CI, Nginx 설정, 서버 식별 API를 함께 추가하여 배포 흐름을 직접 구성해 본 점이 좋습니다. 특히 로드밸런싱을 확인하기 위한 /server/info API를 만든 의도는 학습 목적에 적절합니다. 다만 GitHub Actions 워크플로의 위치와 실행 조건, 배포 파일 경로가 실제 실행 가능성과 직접 연결되므로 우선적으로 점검해야 합니다. 또한 컨테이너와 프록시를 다룰 때는 애플리케이션 코드보다 운영 설정의 경로, 실행 주체, 예외 응답 경계를 명확히 하는 습관이 중요합니다.
| @@ -0,0 +1,47 @@ | |||
| name: CI | |||
|
|
|||
| on: | |||
There was a problem hiding this comment.
현재 CI가 main 브랜치 push에서만 실행됩니다. 이번 PR의 기준 브랜치가 Joonseok이고 학습 PR 검증 목적도 있으므로 pull_request 또는 대상 브랜치 전략을 함께 정의하는 것을 권장합니다. CI는 코드가 합쳐진 뒤보다 합치기 전에 피드백을 주는 역할이 크기 때문에 실행 시점을 명확히 잡을 필요가 있습니다.
| @@ -0,0 +1,59 @@ | |||
| name: CD | |||
There was a problem hiding this comment.
GitHub Actions 워크플로는 저장소 루트의 .github/workflows/ 아래에 있어야 자동으로 인식됩니다. 현재처럼 Joonseok/.github/workflows/에 두면 CD가 실행되지 않을 가능성이 높으므로, 루트 워크플로에서 working-directory: ./Joonseok를 지정하는 구조를 검토하는 것을 권장합니다.
| host: ${{ secrets.SERVER_HOST }} | ||
| username: ${{ secrets.SERVER_USER }} | ||
| key: ${{ secrets.SERVER_SSH_KEY }} | ||
| port: 22 |
There was a problem hiding this comment.
배포 파일을 복사할 때 경로가 저장소 루트 기준으로 해석됩니다. 현재 설정은 docker-compose.yml과 nginx/conf.d/default.conf를 루트에서 찾지만, 이번 PR의 Nginx 설정은 Joonseok/nginx/conf.d/default.conf에 있습니다. 워크플로 위치를 루트로 옮기는 경우에도 source 경로와 EC2에서 실행할 compose 파일 위치를 함께 맞출 필요가 있습니다.
| public class ServerInfoController { | ||
|
|
||
| @GetMapping("/info") | ||
| public ResponseEntity<Map<String, String>> getServerInfo() throws UnknownHostException { |
There was a problem hiding this comment.
컨트롤러 메서드가 UnknownHostException을 그대로 밖으로 전달하면 서버 정보 조회 실패가 기본 500 응답으로 노출될 수 있습니다. 학습용 API라도 Controller는 응답 계약을 유지하고, 실패 처리는 서비스 또는 예외 핸들러에서 명확한 메시지로 변환하는 구조를 권장합니다. 예외 처리 계층과 Controller 책임 분리를 함께 점검하면 좋습니다.
2 participants
🔗 연관 이슈
🛠 작업 내용
🖼 스크린샷 (선택)
👀 리뷰 요구사항 (선택)
🤖 AI 활용
💬 나의 프롬프트
🧠 AI 응답
✅ 내가 최종 선택한 방법 (이유)
💡 나만의 Tip (선택)