WordPress용 Docker: 격리된 컨테이너가 모든 것을 바꾸는 이유

기존 WordPress 호스팅은 여러 사이트를 하나의 서버에 배치합니다. PHP를 공유하고, 파일 시스템 액세스를 공유하며, 종종 데이터베이스 서버도 공유합니다. 이는 괜찮지만 그렇지 않을 때는 심각한 문제가 됩니다.

PAGEnza는 모든 WordPress 사이트를 자체 Docker 컨테이너에 프로비저닝합니다. 이 게시물에서는 이것이 실제로 무엇을 의미하며 여러 클라이언트 사이트를 관리하는 에이전시에게 왜 중요한지 설명합니다.

공유 호스팅 문제

일반적인 공유 호스팅 플랜 또는 여러 WordPress 설치가 있는 기본 VPS에서도 마찬가지입니다:

리소스 경합: 한 사이트에서 트래픽 급증이 발생하면 서버의 다른 모든 사이트가 느려집니다. 사이트 A의 최적화되지 않은 플러그인이 사이트 B의 성능을 저하시킵니다.

보안 유출: 취약한 플러그인, 약한 비밀번호 또는 오래된 코어 버전을 통해 WordPress 설치가 손상되면 파일 시스템 액세스 권한을 얻은 공격자는 종종 동일한 서버의 다른 사이트의 파일을 읽을 수 있습니다.

PHP 버전 충돌: 사이트 A는 오래된 플러그인을 위해 PHP 7.4가 필요합니다. 사이트 B는 최신 플러그인을 위해 PHP 8.2가 필요합니다. 공유 호스팅에서는 하나를 선택해야 합니다.

데이터베이스 노출: 공유 데이터베이스 서버는 잘못 구성된 사용자 권한 하나가 다른 사이트의 데이터를 노출할 수 있음을 의미합니다.

Docker 컨테이너는 인프라 수준에서 이 모든 문제를 해결합니다.

컨테이너란 실제로 무엇인가

Docker 컨테이너는 자체적인 다음을 갖춘 가볍고 격리된 프로세스입니다.

• 파일 시스템 (컨테이너는 경계 외부의 파일을 볼 수 없습니다)
• 네트워크 스택 (자체 IP 주소, 자체 포트)
• 프로세스 공간 (다른 컨테이너의 프로세스를 볼 수 없습니다)
• 리소스 제한 (CPU 및 메모리 제한)

다른 컨테이너와 호스트 커널을 공유하지만 커널 위의 모든 것은 격리됩니다. 완전한 가상 머신이 아니라 몇 초 안에 시작되고 몇 분이 걸리지 않으며 리소스의 일부만 사용합니다.

WordPress의 경우 단일 컨테이너에서 Nginx, PHP-FPM 및 WordPress 파일을 실행합니다. 데이터베이스는 별도의 컨테이너에서 실행되며 해당 특정 WordPress 컨테이너에만 연결됩니다.

PAGEnza는 어떻게 사이트를 프로비저닝하는가

PAGEnza에서 새 클라이언트 사이트를 만들 때 45초 이내에 다음과 같은 일이 발생합니다.

1. 기본 WordPress 이미지에서 새 Docker 컨테이너가 생성됩니다.
2. WordPress는 공유 MariaDB 인스턴스에 새 데이터베이스로 구성됩니다 (해당 컨테이너의 자격 증명으로 격리됨).
3. PAGEnza 플러그인이 자동으로 설치 및 활성화됩니다.
4. Nginx 가상 호스트가 클라이언트의 하위 도메인으로 구성됩니다.
5. Let's Encrypt를 통해 SSL이 발급됩니다.
6. 컨테이너가 올바른 라우팅 규칙으로 리버스 프록시에 등록됩니다.

클라이언트는 "사이트 만들기"를 클릭한 후 45초 이내에 라이브가 되는 clientname.pagenza.com과 같은 URL을 받습니다. 수동 서버 구성, SSH, DNS 대기 시간(하위 도메인의 경우 - 사용자 정의 도메인 DNS 전파는 별도)이 없습니다.

실제 컨테이너 격리

메모리 제한: 각 컨테이너에는 구성 가능한 메모리 제한이 있습니다. 실행 중인 플러그인이 한 클라이언트 사이트에서 메모리 급증을 유발하더라도 다른 컨테이너에 할당된 메모리를 소비할 수 없습니다. 해당 사이트는 느려지거나 503 오류를 반환할 수 있지만 다른 클라이언트에게는 영향을 미치지 않습니다.

파일 시스템 격리: 클라이언트 A의 WordPress 파일은 클라이언트 B의 컨테이너에서 완전히 보이지 않습니다. 클라이언트 A 사이트의 손상된 플러그인은 클라이언트 B의 파일에 접근할 경로가 없습니다.

네트워크 격리: 컨테이너는 정의된 네트워크 브리지를 통해서만 통신합니다. 클라이언트 A의 데이터베이스 컨테이너는 시스템의 다른 컨테이너가 아닌 클라이언트 A의 WordPress 컨테이너에서만 연결을 수락합니다.

컨테이너별 PHP: 각 컨테이너는 자체 PHP-FPM 인스턴스를 실행하므로 클라이언트마다 다른 PHP 버전을 실행할 수 있습니다. PHP 7.4가 필요한 클라이언트 A의 레거시 플러그인은 PHP 8.2의 클라이언트 B의 최신 스택과 함께 잘 실행됩니다.

사용자 정의 도메인

기본 설정은 모든 클라이언트에게 *.pagenza.com 하위 도메인을 제공합니다. 자체 도메인을 원하는 클라이언트의 경우 프로세스는 다음과 같습니다.

1. 클라이언트가 도메인의 A 레코드를 PAGEnza 서버 IP로 가리킵니다.
2. PAGEnza 대시보드에서 사용자 정의 도메인을 입력합니다.
3. 리버스 프록시 구성이 자동으로 업데이트됩니다.
4. Let's Encrypt를 통해 사용자 정의 도메인에 대한 SSL이 발급됩니다.

WordPress의 siteurl 및 home 옵션이 일치하도록 업데이트됩니다. 클라이언트의 관점에서 사이트는 도메인에서 작동하며 방문자에게 보이지 않는 리디렉션이나 하위 도메인이 없습니다.

에이전시에게 의미하는 바

여러 클라이언트 사이트를 운영하는 에이전시의 실질적인 이점:

온보딩 속도: 새 클라이언트 사이트 프로비저닝에 1분도 채 걸리지 않습니다. 서버 설정, cPanel, 수동 WordPress 설치가 필요 없습니다.

클라이언트 분리: 각 클라이언트의 사이트는 진정으로 격리됩니다. 문제가 있는 플러그인을 설치하는 클라이언트는 자신의 사이트에만 영향을 미칩니다.

확장성: 새 클라이언트를 추가해도 새 서버를 프로비저닝할 필요가 없습니다. 컨테이너 인프라는 호스트의 용량에 맞게 확장되며, 용량 추가는 호스트 노드 추가 문제일 뿐입니다.

재해 복구: 각 사이트가 컨테이너화되어 있으므로 백업 및 복원은 컨테이너 수준에서 작동합니다. 단일 클라이언트 사이트를 복원해도 다른 클라이언트에게는 영향을 미치지 않습니다.

단점은 컨테이너 호스팅이 공유 호스팅보다 사이트당 비용이 더 많이 든다는 것입니다. 그러나 사이트 안정성과 클라이언트 분리가 협상 불가능한 에이전시의 경우, 특히 프로비저닝 시간 절약을 고려할 때 경제성이 맞습니다.