VM에서 돌던 서비스를 컨테이너로 옮길 때 가장 중요한 것은 옮긴 뒤에도 기존과 똑같이 동작하는지 확인하는 일입니다. 첫 대상으로 고른 웹 사이트에서는 기존 VM과 응답을 하나하나 비교해 HTTP 200만으로는 보이지 않던 문제 세 가지를 전환 전에 찾았습니다. 쓰기 기능을 직접 시험해 문제 하나를 더 찾았습니다. 이 글에서는 첫 대상을 고른 기준, 서비스가 쓰는 데이터(상태)를 나눈 방법, 기존 VM과 응답을 비교해 검증한 과정, 전환과 되돌리기 계획을 정리합니다. 홈랩 재구성 시리즈 3편이며, 이전 글은 홈랩 Kubernetes 클러스터 설계와 노드 배치입니다.
1. 첫 대상 고르기
첫 이관 대상으로는 실패해도 피해가 작고 바로 되돌릴 수 있는 서비스를 골랐습니다.
| 항목 | 내용 |
| 구성 | Rocky Linux 9 VM 1대, Apache 웹 서버 |
| 콘텐츠 | 파일 123개, 247MB (이미지, 3D 모델, 스크립트) |
| 동적 기능 | Python CGI 3개, 표준 라이브러리만 사용 |
| DB | 없음 |
| TLS | 앞단 리버스 프록시에서 처리, 이 서버는 HTTP만 받음 |
| 방문 | 실제 방문 요청은 하루 약 50건 |
DB가 없고 TLS를 앞단에서 처리한다는 점이 결정적이었습니다. 앞단 프록시가 요청을 보내는 주소만 VM에서 클러스터로 바꾸면 전환이 끝나고, 문제가 생기면 주소를 다시 VM으로 돌리면 됩니다.
로그를 보니 하루 요청 약 6만 9천 건 중 실제 방문은 50건 정도였고, 나머지는 로드밸런서가 서버가 살아 있는지 확인하는 요청이었습니다. 이 확인 요청 때문에 접속 로그가 하루 11MB씩 쌓이고 있었습니다. Kubernetes에서는 상태 확인을 Pod의 probe가 맡으므로, probe 요청은 접속 로그에서 빼기로 했습니다.
2. 서비스가 쓰는 데이터 나누기
컨테이너를 새로 만들면 컨테이너 내부에만 저장한 파일 변경 사항은 사라집니다. 그래서 옮기기 전에 서비스가 어떤 파일을 쓰는지 먼저 찾고, 사라져도 되는 것과 남아야 하는 것을 나눴습니다.
| 기능 | 쓰는 파일과 처리 방법 |
| 파일 업로드 | 1시간 뒤 지우는 임시 파일 → Pod와 수명을 같이하는 임시 볼륨(emptyDir), 정리는 보조 컨테이너가 10분마다 |
| 리다이렉트 | 쓰는 파일 없음 → 그대로 |
| 관리 페이지 | 사이트 설정 파일(site.json)을 고쳐 씀 → 영구 볼륨(PVC) |
설정 파일 하나만 영구 볼륨으로 붙이면 될 것 같았지만, 이 방법은 쓰지 못했습니다. 관리 페이지는 설정을 저장할 때 같은 폴더에 임시 파일을 먼저 쓴 뒤 이름을 바꿔 원래 파일을 교체합니다. 파일 하나만 따로 붙이면 이름 바꾸기가 볼륨 경계를 넘게 되어 저장이 실패합니다. 그래서 설정 파일이 있는 폴더 전체(242MB)를 영구 볼륨으로 붙였습니다. Pod가 시작될 때는 초기화 컨테이너(initContainer)가 이미지 안의 원본으로 폴더를 채우되, 이미 있는 설정 파일은 덮어쓰지 않게 했습니다. 이렇게 하면 앱 코드를 고치지 않고도 설정이 유지됩니다.
3. 이미지 만들기
이미지는 공식 Apache 이미지에 Python과 사이트 설정, CGI를 더해 만들었습니다. 콘텐츠도 이미지 안에 넣었습니다. 247MB 정도면 이미지에 넣어도 부담이 없고, 콘텐츠가 바뀌면 이미지를 다시 만들어 배포하면 되기 때문입니다.
이미지의 재료는 소스 저장소가 아니라 지금 서버에서 실제로 동작 중인 파일로 했습니다. 오랫동안 서버에 직접 배포해 온 서비스는 서버의 파일이 가장 확실한 기준입니다. 저장소에서 만든 이미지가 서버와 조금이라도 다르면, 전환한 뒤에 생긴 차이가 이관 때문인지 원래 있던 것인지 구분하기 어렵습니다.
4. 기존 VM과 응답 비교하기
컨테이너를 실행하고 사이트가 열리는 것만 확인하면 끝난 것처럼 보입니다. 하지만 저는 같은 경로에 같은 헤더로 기존 VM과 새 Pod에 요청을 보내고, 상태 코드와 응답 헤더, 본문의 해시(md5)를 비교했습니다. 비교 대상은 파일 종류별 대표 경로, CGI 3개, 접근 제한 규칙이 걸린 폴더, 없는 페이지, 디렉터리 목록, 압축 응답입니다.
같은 요청을 기존 VM과 새 Pod에 보내고 상태 코드, 헤더, 본문을 비교했습니다
첫 비교에서 다음 문제들이 나왔습니다.
| 문제 | 원인과 해결 |
| CGI가 실행되지 않고 소스 코드가 그대로 내려감 | 이미지 설정에서 CGI 모듈을 켜는 줄이 탭으로 들여쓰기되어 있어 수정이 적용되지 않음, 모듈이 켜졌는지 이미지를 만들 때 검사하도록 함 |
| 일부 파일의 Content-Type이 다름 | 3D 모델 파일(.glb, .usdz)에 Content-Type이 없었음, 기존 서버의 MIME 정의 파일을 이미지에 그대로 넣음 |
| 디렉터리 목록 모양이 다름 | 기존 서버와 같은 목록 형식을 켬 |
가장 위험한 것은 첫 번째였습니다. CGI가 실행되지 않아도 상태 코드는 200이었고, 브라우저에서 메인 페이지를 열면 아무 문제가 없어 보였습니다. 응답 본문을 비교하지 않았다면 서버의 소스 코드가 외부에 그대로 보이는 상태로 전환할 뻔했습니다.
고친 뒤 다시 비교하자 36개 경로 중 33개가 같았습니다. 남은 3개는 오류 페이지의 첫 줄과 디렉터리 목록 모양처럼 Apache 버전 차이에서 오는 것이라 그대로 두었습니다.
5. 쓰기 기능 시험하기
읽기 비교가 끝난 뒤에는 쓰기 기능을 시험했습니다. 운영 중인 VM에는 쓰지 않고 새 Pod에만 요청을 보냈습니다.
| 시험 | 결과 |
| 3D 모델 파일 업로드 | 업로드와 다운로드 모두 정상 |
| 관리 페이지에서 설정 저장 | 처음에는 저장 실패, 원인을 고친 뒤 성공 |
| 설정을 바꾼 뒤 Pod 삭제 | 새 Pod에서도 바뀐 값이 유지됨 |
| 시험 후 원래 설정으로 복원 | 기존 VM과 설정 파일의 해시가 같음 |
설정 저장이 실패한 원인은 웹 서버의 실행 계정이었습니다. 공식 Apache 이미지는 Debian 기반이라 웹 서버가 www-data 계정으로 실행되는데, 볼륨의 소유자를 다른 계정으로 맞춰 두어서 CGI가 파일을 쓰지 못했습니다. 초기화 컨테이너에서 폴더 소유자를 www-data로 바꿔 해결했습니다. 이 문제는 읽기 비교로는 드러나지 않고 실제로 써 봐야 보이는 문제였습니다.
6. 전환과 되돌리기
전환은 앞단 리버스 프록시가 요청을 보내는 주소를 기존 VM에서 클러스터의 LoadBalancer IP로 바꾸는 것으로 끝났습니다. TLS 인증서는 지금처럼 프록시가 관리하므로 클러스터 쪽에서 바꿀 것이 없었습니다.
전환한 뒤에는 공개 주소로 요청을 보내 실제로 Pod에 도착하는지 확인했습니다. 요청의 User-Agent에 표시를 붙여 보낸 뒤 Pod 로그에서 그 표시를 찾는 방법입니다. 보낸 요청 8건이 모두 Pod 로그에 남았고, 실제 방문자의 요청과 모니터링 요청도 Pod로 들어오는 것을 확인했습니다.
기존 VM 2대(메인과 백업)는 바로 지우지 않고 정상 종료해 두었습니다. 문제가 생기면 VM을 켜고 프록시 주소만 되돌리면 되므로, 며칠 지켜본 뒤 문제가 없으면 삭제합니다.
7. 남은 일
| 항목 | 내용 |
| 복제본 | 노드 로컬 디스크를 쓰기 때문에 Pod 1개가 한 워커에 묶임, NAS 공유 스토리지를 연결한 뒤 복제본을 늘림 |
| 방문자 IP | 접속 로그에 방문자 대신 프록시의 IP가 남음, 프록시가 넘겨주는 X-Forwarded-For 헤더를 로그에 쓰도록 바꿀 예정 |
| 이미지 배포 | 처음에는 이미지를 노드에 직접 넣었음, 다음 글에서 클러스터 내부 이미지 저장소와 GitOps로 바꿈 |
8. 정리
- 첫 이관 대상은 DB가 없고 앞단 프록시 주소만 바꾸면 되돌릴 수 있는 작은 웹 사이트로 골랐습니다.
- 옮기기 전에 서비스가 쓰는 파일을 찾아 임시 볼륨과 영구 볼륨으로 나눴고, 이름 바꾸기로 저장하는 파일은 폴더째 영구 볼륨에 붙였습니다.
- 이미지는 저장소가 아니라 서버에서 실제로 동작 중인 파일로 만들었습니다.
- 기존 VM과 응답을 비교해 CGI 미실행, Content-Type, 디렉터리 목록 문제를 전환 전에 찾았습니다.
- 쓰기 기능은 직접 시험해야 실행 계정 같은 문제가 드러납니다.
- 전환할 때는 프록시가 요청을 보내는 주소만 바꿨고, 기존 VM은 꺼 둔 채 며칠 지켜본 뒤 지웁니다.
참고
'Project > 홈랩' 카테고리의 다른 글
| [홈랩] PHP 사이트 6개와 MySQL을 옮기고 Gateway 하나로 합치기 (0) | 2026.10.29 |
|---|---|
| [홈랩] Jenkins와 Argo CD로 홈랩 CI/CD 구성하기 (0) | 2026.10.29 |
| [홈랩] 홈랩 Kubernetes 클러스터 설계와 노드 배치 (0) | 2026.10.28 |
| [홈랩] 홈랩 인프라 현황과 Kubernetes로 옮기는 이유 (0) | 2026.10.28 |
| [홈랩] 홈 네트워크 구축 V2 (0) | 2020.11.04 |
