자바 애플리케이션 배포

RAM 4GB 서버에서 Spring Boot 앱 하나만 띄웁니다. 적절한 -Xms·-Xmx 값과 이유를 쓰세요.

-Xms2g -Xmx2g 정도가 적당합니다. OS 와 JVM 의 힙 밖 메모리(메타스페이스, 스레드 스택, 네이티브)에 12GB 를 남겨야 하므로 RAM 의 5070% 를 힙에 줍니다. 둘을 같게 두면 힙 확장이 없어 시작 후 성능이 일정합니다.

app.sh 안에 JAVA_OPTS=${JAVA_OPTS:--Xmx512m} 이 있고, conf/env 에 JAVA_OPTS="-Xmx1g" 가 있으며, 실행 시 JAVA_OPTS=-Xmx256m bash app.sh start 로 띄웠습니다. 최종 힙은 얼마입니까?

1g 입니다. 명령줄 변수 256m 이 기본값 512m 을 이기지만, 그 뒤에 . conf/env 가 실행되어 1g 로 덮습니다. 서버 설정 파일이 항상 최종 우선이 되도록 설계한 것입니다.

배포 직후 헬스 체크가 60초 안에 성공하지 않으면 자동으로 롤백하는 셸 조각을 쓰세요. app.sh 와 4.2 의 대기 루프를 조합합니다.

bash app.sh deploy "$NEW_JAR" && bash app.sh restart
for _ in $(seq 1 60); do
  curl -sf localhost:8080/actuator/health >/dev/null && { echo "배포 성공"; exit 0; }
  sleep 1
done
echo "헬스 실패, 롤백"; bash app.sh rollback

성공 시 exit 0 으로 루프를 빠져나가고, 60번 실패하면 아래로 내려와 롤백합니다.

서버에서 현재 실행 중인 앱의 jar 경로와 빌드 버전을 확인하는 명령을 쓰세요.

cat /opt/myapp/run/current.rel
unzip -p /opt/myapp/current/app.jar META-INF/MANIFEST.MF | grep -i version
ps -ef | grep '[a]pp.jar' | grep -o '\-jar [^ ]*'

ps 출력에서 -jar 뒤 경로를 잘라내면 실제로 떠 있는 프로세스가 어느 jar 인지 확인됩니다. current 링크와 다르면 배포 후 재시작을 안 한 것입니다.

ls -1dt releases/*/ | tail -n +6 | xargs -r rm -rf 에서 -t, +6, -r 각각의 역할을 설명하세요.

-t 는 수정 시각 최신순 정렬로 새 릴리스가 위에 옵니다. tail -n +6 은 6번째 줄부터 끝까지, 즉 최신 5개를 제외한 나머지입니다. xargs -r 은 입력이 비어 있으면 rm 을 아예 실행하지 않아 릴리스가 5개 이하일 때 안전합니다.