명령어보다 먼저 실행 위치를 확인한다

win-j.com을 Synology NAS에서 운영하며 DSM 화면과 PuTTY를 함께 사용해 왔습니다. 컨테이너 상태와 최근 로그를 빠르게 확인할 때 SSH가 편하지만, NAS 셸·컨테이너 셸·Django shell·psql은 서로 다른 명령을 받습니다. 원문의 명령 모음에서 잘못 적힌 pwd 설명과 \l 표기, 수동 배포 명령을 이 기준으로 정리합니다.

PuTTY는 SSH 접속 도구이고 실제 명령은 접속한 서버에서 실행됩니다. 처음 접속하거나 호스트 키가 달라졌다면 서버의 키를 별도 경로로 확인하는 절차는 PuTTY 공식 설명에 따릅니다. 아래 컨테이너 이름은 현재 프로젝트의 운영 Compose 기준입니다.

1. NAS 셸에서 위치와 상태 읽기

pwd
ls -al
docker ps -a
docker logs --tail 100 myapp_web

pwd는 현재 디렉터리 경로를 출력합니다. 파일 목록은 ls이며, -al은 숨김 항목과 상세 정보도 보여줍니다. docker ps -a는 중지된 컨테이너까지 포함합니다. 로그는 최근 100줄로 범위를 제한하되 발생 시각이 더 오래됐다면 범위를 조정합니다.

docker logs -f로 따라가던 로그는 Ctrl+C로 조회를 끝낼 수 있습니다. 이미 실행 중인 컨테이너 자체를 중지하는 것과는 다릅니다. 반면 컨테이너의 주 프로세스에 attach한 경우는 동작이 다를 수 있으므로 명령을 혼동하지 않습니다.

2. Django 검사는 절대 경로로 실행하기

이 프로젝트에서 manage.py는 /app/src/manage.py입니다. 컨테이너 안에 먼저 들어가지 않고 NAS 셸에서 실행할 수 있습니다.

docker exec myapp_web python /app/src/manage.py check
docker exec myapp_web python /app/src/manage.py showmigrations blog
docker exec myapp_web python /app/src/manage.py migrate --plan

일반 검사, 적용 기록, 적용 예정 작업을 차례로 봅니다. migrate --plan은 실제 migration을 적용하지 않습니다. 모델을 바꾸지 않았는데 운영에서 매번 makemigrations를 실행하는 습관은 피합니다. migration 파일은 개발에서 만들고 검토해 코드와 함께 배포하는 편이 어느 변경을 적용했는지 추적하기 쉽습니다.

대화형 Django shell은 docker exec -it myapp_web python /app/src/manage.py shell로 들어갑니다. 여기서는 Python 코드를 입력하고 exit()로 나올 수 있습니다. NAS 명령인 docker ps를 Python 프롬프트에 입력하면 문법 오류가 납니다.

3. DB 이름을 확인하되 기본 계정을 가정하지 않는다

DB 컨테이너는 myapp_db지만 DB 사용자와 DB명까지 postgres라고 단정할 수는 없습니다. 승인된 실제 계정과 DB명을 확인해 psql에 접속하고, 비밀번호를 명령줄·공개 로그에 직접 쓰지 않습니다. Django 연결 자체를 점검할 목적이면 DATABASE_URL을 출력하지 않는 조회 예제를 먼저 사용할 수 있습니다.

psql에 들어온 뒤 사용하는 명령은 다음과 같습니다.

SELECT current_database();
SELECT 1;

\l
\dt
\q

\l의 마지막 글자는 소문자 영문 l입니다. DB 목록을 보여주며, \dt는 현재 검색 경로에서 보이는 테이블 목록, \q는 종료입니다. 일반 SQL은 세미콜론으로 끝내지만 이 역슬래시 명령들은 psql 자체 명령입니다. 표 목록만으로 모든 schema와 Django migration 일치가 확인되는 것은 아닙니다.

4. Nginx는 검사와 재적용을 구분한다

docker exec myapp_nginx nginx -t

이 명령은 설정을 검사합니다. nginx -s reload는 설정을 실행 중 프로세스에 반영하는 변경 작업입니다. 검사 성공 뒤에도 정상 URL, 정적 파일, 프록시 연결을 확인해야 합니다. Nginx의 시작·재적용 동작은 공식 운영 문서에 설명되어 있습니다.

자동 배포가 있는 서버에서 중복 작업하지 않기

이 프로젝트는 NAS Git 서버로 push하면 배포 hook이 코드 반영과 컨테이너 재시작을 수행하도록 운영해 왔습니다. 저장소의 운영 web 시작 명령에도 migrate와 collectstatic이 들어 있습니다. 따라서 원문에 나열한 git pull, up, migrate, collectstatic, restart를 push 직후 다시 모두 실행할 필요는 없습니다. hook의 실제 실행 내용은 서버에서 관리되는 별도 설정입니다.

조회 작업 별도로 계획할 변경 작업
상태·최근 로그 확인 컨테이너 재생성·재시작
check·showmigrations·migrate --plan migrate 실제 적용
파일 존재와 mount 확인 collectstatic·파일 교체
nginx -t nginx reload
기존 DB 연결로 SELECT 데이터 수정·삭제·복원

배포 후에는 대상 컨테이너, 오류 시각, 새 코드의 실제 응답을 묶어 확인합니다. 백업이 필요하다면 컨테이너 안의 임시 파일을 NAS의 지속 보관 폴더로 옮긴 뒤 내용과 복원 방법도 확인합니다. 컨테이너 안에 파일이 생겼다는 사실만으로 보관을 마쳤다고 기록하지 않습니다. 전체 점검 순서는 Django 배포 점검 기록과 함께 사용할 수 있습니다.