WordPress 설치 화면을 처음 띄우는 일은 생각보다 빨리 끝났다. 오래 걸린 쪽은 그 앞뒤였다. 데이터가 재시작 뒤에도 남는지, 비밀번호가 설정 파일에 그대로 드러나지 않는지, NAS에서 폴더 권한이 맞는지를 확인하는 데 시간이 더 들었다.
WordPress와 데이터베이스를 분리했다
Compose 프로젝트에는 WordPress와 MariaDB를 각각 별도 컨테이너로 넣었다. WordPress 컨테이너를 새 버전으로 바꾸더라도 글과 설정은 데이터베이스 볼륨에 남아야 한다. 반대로 데이터베이스가 준비되기 전에 WordPress가 먼저 접속을 시도하면 오류가 나기 쉬워 MariaDB 상태를 확인하는 헬스체크도 함께 뒀다.
두 컨테이너는 전용 Docker 네트워크에서 통신하게 했다. MariaDB는 외부 포트를 열지 않았다. 데이터베이스에 접근할 주체는 같은 Compose 안의 WordPress뿐이어서 NAS 밖으로 노출할 필요가 없었다.
비밀번호는 Compose 파일에서 뺐다
데이터베이스 사용자 비밀번호, 루트 비밀번호, Tunnel 토큰 같은 값은 별도 환경 파일로 분리했다. 예제 파일에는 변수 이름만 남기고 실제 값은 운영용 파일에만 넣었다. 편의를 위해 모든 비밀 값을 한 파일에 모으는 방식은 관리하기 쉽지만, 그 파일의 읽기 권한과 백업 위치를 더 조심해야 한다.
나중에 Hermes가 정리한 인사이트를 WordPress 작업 흐름에 연결하면서도 같은 원칙을 적용했다. 애플리케이션 비밀번호와 관리자 계정 비밀번호를 섞지 않고, 자동화에 필요한 권한만 따로 줬다. 한 번 편하자고 만든 비밀 값이 여러 서비스에 퍼지면 교체할 때 더 큰 일이 된다.
NAS에서는 파일 권한이 자주 발목을 잡았다
Docker 폴더가 SMB에서 바로 보이지 않거나, 터미널 사용자는 파일을 읽을 수 있는데 컨테이너는 쓰지 못하는 일이 있었다. NAS의 공유 폴더 권한, Docker가 사용하는 사용자 권한, 컨테이너 안의 소유권은 서로 같은 문제가 아니었다. 화면에서 권한을 줬다고 끝난 줄 알았다가 다시 확인한 적이 여러 번 있었다.
SSH와 Docker 권한도 필요한 동안만 열어 두었다. 구성과 점검이 끝난 뒤에는 SSH를 끄는 습관을 들였다. 평소에는 NAS 관리 화면과 Tailscale을 쓰고, 터미널이 꼭 필요할 때만 다시 켜는 편이 마음이 놓였다.
UGREEN NAS의 8GB 메모리는 시작하기에 충분했다
현재 구성은 WordPress, MariaDB, cloudflared에 Hermes까지 더해져 있다. 방문자가 많지 않은 개인 블로그 단계에서는 8GB 메모리로 무리 없이 운영할 수 있었다. 다만 플러그인을 계속 늘리거나 이미지 처리 작업을 동시에 돌리면 상황이 달라질 수 있을 것 같다. 지금은 숫자 하나보다 컨테이너별 사용량과 MariaDB 상태를 가끔 확인하는 쪽을 택했다.
Compose 파일을 쓰는 것보다 재시작 뒤 같은 상태로 돌아오는지 확인하는 데 더 신경을 썼다. 컨테이너를 다시 올리고, 로그를 보고, WordPress에 접속하고, 글과 미디어가 남아 있는지 확인했다. 이 과정을 통과한 뒤에야 외부 공개 설정으로 넘어갈 수 있었다.