25장 서버 한 대를 애플리케이션 지도로 바꾼다

레거시 시스템을 넘겨받으면 webapps에 있는 WAR부터 복사하고 싶어진다. 그러나 실제 애플리케이션은 WAR 밖에 더 많이 숨어 있다. JVM 옵션, CATALINA_BASE/conf, JNDI 자원, 프록시 경로, 공유 디렉터리, cron, 배치 계정, 인증서, DNS, 방화벽, DB 스키마가 합쳐져 서비스가 된다. 먼저 변경 없는 읽기 전용 인벤토리를 만든다.


서비스: ReleasePortal
외부 URL / context: https://portal.example.invalid/releaseportal
TLS 종료: Nginx 2대
애플리케이션: releaseportal.war, SHA-256, build commit
런타임: JDK / Tomcat / Servlet namespace
설정: CATALINA_BASE, context XML, systemd EnvironmentFile
상태: HTTP session, 로컬 cache, 업로드 임시 파일
연계: JNDI DB, SMTP, SFTP, 배치, 공유 파일
소유자: 앱 / WAS / DB / 네트워크 / 인증서
복구: 이전 WAR, DB 호환 범위, RTO/RPO, 담당자

운영 서버에서는 명령이 읽기 전용인지 먼저 확인한다. 출력에 비밀이 포함될 수 있으므로 원문 전체를 출판 예제나 외부 AI에 붙이지 않는다.


java -version
"$CATALINA_HOME/bin/version.sh"
systemctl cat releaseportal
ps -ef | grep '[o]rg.apache.catalina.startup.Bootstrap'
ss -lntp
jar --list --file /srv/releases/releaseportal.war | sed -n '1,80p'

ps와 systemctl cat에는 비밀번호나 토큰이 노출될 수 있다. 공유 전 키 이름만 남기고 값은 마스킹한다. lsof, ss, 로그 열람 권한도 조직 절차를 따른다.

WAR 밖의 프록시·세션·JNDI·공유 파일·배치 의존성을 한 장에 표시한 레거시 인프라 지도

ReleasePortal 실습 앱이 namespace·세션·JNDI pool·배치·공유 파일·프록시 계약을 한 화면에서 HOLD로 판정한 동일 실습 화면

실습 25 읽기 전용 인수 카드

실제 서버 대신 제공 fixture를 기준으로 legacy-inventory.md를 만든다. 모르는 항목은 추측하지 않고 UNKNOWN으로 둔다. 각 항목에 확인 명령, 확인 시각, 소유자, 변경 금지 여부를 붙인다. 빈칸이 있다는 사실도 배포 위험의 증거다.

WAR 배포, 밤에 깨지 않게: 25장 서버 한 대를 애플리케이션 지도로 바꾼다

25장 서버 한 대를 애플리케이션 지도로 바꾼다

실습 25 읽기 전용 인수 카드