저희 조직은 웹 애플리케이션과 포럼, 그리고 bitwarden과 같은 몇 가지 다른 애플리케이션을 운영하고 있습니다. dev/prod 환경의 일관성을 유지하고 docker compose를 활용한 단순한 개발 환경 구축을 위해 모든 것을 컨테이너화했습니다. 프로덕션에서는 이와 매우 유사한 compose 파일을 사용하여 실행하고 있으며, 기본적인 사용 사례에 대해 매우 잘 작동하고 있습니다.
포럼을 discourse로 전환하고 싶지만, dev/prod 환경의 일관성과 단순한 개발 환경을 유지하는 방법에 대해 고민하고 있습니다.
문서에는 discourse가 설치 및 실행에 docker를 사용하지만, 다른 docker 컨테이너처럼 컨테이너 패러다임에 완전히 부합하지는 않는다고 언급하고 있습니다. 즉, 다른 애플리케이션 컨테이너처럼 데이터베이스와 redis 컨테이너에 연결하여 compose/swarm/kubernetes 스택에 추가해서 실행할 수 없다는 뜻입니다. 또한 커뮤니티가 분화되는 것을 방지하기 위해 대안적인 솔루션이나 제안을 강력히 비추천하고 있으므로, 저는 이 접근 방식에 대해 의문을 제기하러 온 것이 아닙니다.
저는 나머지 스택을 관리하는 방식과는 달리, 프로덕션에서는 전용 VM을 실행하고 다르게 관리해야 한다는 점을 받아들였습니다. 하지만 근본적인 목표인, 프로덕션과 상당한 일관성을 갖는 단순한 개발 환경을 어떻게 구성할 수 있을지 궁금합니다.
참고로, 현재 제 개발 환경은 "docker 설치, 이 저장소 클론, docker-compose up 실행"으로 요약됩니다. 로컬 설치 가이드를 올바르게 이해했다면, 이제 discourse 자체를 수동으로 클론하고 설정하기 전에 9개의 시스템 의존성(ruby, postgres 등)이 필요할 것입니다. 제 생각에 docker(및 docker compose)의 장점 중 하나는 postgres나 redis 같은 것을 시스템에 실행할 필요가 없다는 점입니다(개발자가 Windows를 사용하는 경우 해당 설정과 관련된 문제들 포함). 단순히 스택을 실행하면 프로세스가 일회용 컨테이너에 격리되므로, 이러한 장점을 유지할 수 있는 방법이 있을까요?
또 다른 단점은, 저희는 자원봉사자로 구성된 소규모 팀이라 대부분의 다른 개발자들이 Windows 10 Home을 사용한다는 점입니다. 제 지식 범위 내에서 Windows 10 Home은 WSL을 지원하지 않으므로, 어차피 Windows 설치 지침을 따를 수 없을 것입니다(docker는 Windows 10 Home에서 작동합니다).