워드프레스 Docker 스택 구성 — nginx · PHP-FPM · MariaDB · Redis

워드프레스 호스팅 사고의 상당수는 “그 서버에만 있던 설정” 에서 나옵니다. PHP 버전, 확장 모듈, nginx 규칙이 서버에 손으로 쌓여 있으면 이전도 복구도 고고학이 됩니다. compose 파일 하나로 스택을 선언하면 서버가 아니라 파일이 진실이 됩니다.

최소 골격

services:
  nginx:
    image: nginx:alpine
    ports: ['80:80', '443:443']
    volumes:
      - ./wordpress:/var/www/html
      - ./docker/nginx.conf:/etc/nginx/conf.d/default.conf
  php:
    build: ./docker          # php-fpm + 필요한 확장 + wp-cli
    volumes:
      - ./wordpress:/var/www/html
  db:
    image: mariadb:11
    environment:
      MARIADB_DATABASE: wordpress
    volumes:
      - db-data:/var/lib/mysql
  redis:
    image: redis:7-alpine
volumes:
  db-data:

결정의 이유들

• DB_HOST 는 서비스명 — define('DB_HOST', 'db'). IP 를 적는 순간 파일의 재현성이 깨집니다.
• utf8mb4 고정 — 구형 utf8 은 3바이트라 이모지 · 일부 한자가 무음 손실됩니다. 새 스택에서 이걸 물려받을 이유가 없습니다.
• Redis 는 오브젝트 캐시만 — 페이지 캐시까지 맡기면 nginx 캐시와 무효화 타이밍이 어긋나 “관리자에겐 새 페이지, 방문자에겐 옛 페이지” 가 됩니다.
• 코드는 읽기 전용 마운트가 이상적 — 쓰기가 필요한 곳은 uploads 뿐입니다. 침해 시 변조 범위가 그만큼 줄어듭니다.

스택이 선 다음

docker compose up -d
docker compose exec php wp core version   # WP-CLI 가 컨테이너 안에서 동작하는가
docker compose exec php wp redis status   # Drop-in: Valid 확인

페이지 캐시 계층의 규칙은 FastCGI 캐시 우회 규칙에서 이어집니다. 이 스택 구성 — Docker 미설치 서버의 설치부터 — 이 최적화 지원 사업의 배포 항목입니다.