피드로 돌아가기
I Spent 12 Hours Debugging PostHog Self-Hosting So You Don't Have To
Dev.toDev.to
Infrastructure

PostHog Self-hosting의 6가지 치명적 결함 해결 및 배포 최적화

I Spent 12 Hours Debugging PostHog Self-Hosting So You Don't Have To

Mohammad Ismail Mirza2026년 4월 14일4분intermediate

AI 요약

Context

PostHog Self-hosting의 Docker Compose 기반 기본 배포 프로세스가 실제 런타임 환경의 의존성과 네트워크 설정을 제대로 반영하지 못하는 문제 발생. 특히 Plugin Server의 이미지 분리 구조와 잘못된 기본 환경 변수로 인한 Silent Failure 및 Crash Loop가 주요 병목으로 작용.

Technical Solution

  • Kubernetes 전용 기본값인 CDP_API_URL을 Docker Compose 네트워크 환경에 맞는 http://posthog_plugins:6738로 수정하여 Plugin Server 상태 체크 성공 유도
  • posthog/posthog 이미지의 기본 CMD가 Node.js 바이너리 부재로 인해 무한 재시작되는 문제를 해결하고자 bash -c를 통한 Migrate 및 Server 실행 명령어로 Override
  • ENCRYPTION_SALT_KEYS의 중복 Base64 인코딩 문제를 방지하기 위해 32바이트 Raw UTF-8 문자열 기반의 키 생성 방식 적용
  • 정적 IP 할당으로 인한 컨테이너 바인딩 충돌 해결을 위해 ipv4_address 설정을 제거하고 Docker 내장 DNS 기반의 호스트명 해석 구조로 전환
  • Redis 분산 락(redbeat::lock) 잔류로 인한 Celery Beat 스케줄러 정지 현상을 celerybeat.pid 제거 및 프로세스 재시작을 통해 해결
  • Nginx의 컨테이너 IP 캐싱으로 인한 502 에러 방지를 위해 Web 컨테이너 재생성 후 nginx -s reload 수행으로 DNS 갱신 강제화

실천 포인트

1. Docker Compose 배포 시 정적 IP보다는 서비스 이름 기반의 DNS 해석 사용

2. 컨테이너 이미지 내 실행 파일 존재 여부와 CMD 설정의 일치성 확인

3. 분산 스케줄러 도입 시 비정상 종료 후 남은 락(Lock) 제거 프로세스 마련

4. 리버스 프록시 사용 시 업스트림 컨테이너 변경에 따른 DNS 캐시 갱신 전략 수립

태그

#Redis#Nginx#Celery#Docker Compose#Distributed Lock
원문 읽기