Can Discourse ship frequent Docker images that do not need to be bootstrapped?

Docker compose에는 필요한 기능이 없습니다. Discourse의 Dockerfile 템플릿 구성은 유연한 Docker 결과를 허용합니다. 반면 compose에서는 고정된 Dockerfile 세트만 사용할 수 있어 여러 컨테이너가 생성될 수 있습니다.

제 Discourse 설정에서는 UNIX 소켓을 사용하여 Discourse와 nginx를 단일 컨테이너로 실행합니다. PostgreSQL과 Redis는 호스트의 서비스로 실행됩니다. 이는 기본 설정에서 상당히 벗어난 방식이지만, 추가 설정 없이도 가능합니다.

compose를 사용하면 부분적으로 구현할 수 있습니다. 예를 들어, 설계가 다소 엉성한 profile 기능을 사용할 수 있습니다. 하지만 그렇게 하더라도 여전히 복잡합니다. 아니면 각 변형별로 다른 compose 파일을 제공해야 합니다.

문제를 단순히 옮기는 것뿐입니다.

Discourse에 대한 깔끔한 compose 설정은 다음과 같은 서비스를 개별 컨테이너로 구성하는 것입니다:

  • Discourse
  • nginx
  • PostgreSQL
  • Redis

Discourse와 nginx는 볼륨을 공유해야 하지만, 큰 문제는 아닙니다.

PostgreSQL과 Redis는… 이러한 서비스는 다른 곳에 호스팅하는 것이 더 나을 수 있으며, Discourse 전용 컨테이너로 실행하고 싶지 않을 수 있습니다. 그런데 이제 docker compose가 문제가 됩니다. docker compose up -d를 실행하면 원치 않는 PostgreSQL이 시작됩니다. 그래서 기본 Discourse 설정과 postgresql 컨테이너를 시작하려면 docker compose --profile postgresql up -d를 사용해야 합니다. “완전한” 자체 포함 Discourse 컨테이너 설정을 위해선 docker compose --profile postgresql --profile redis up -d를 사용해야 합니다. --profile ... 인수를 누르면 더 많은 문제가 발생하므로 주의해야 합니다.

따라서 더 나은 UX를 위해 원하는 docker compose 명령을 생성하도록 launcher를 만들어야 합니다. 이제 우리는 거의 처음 위치로 돌아온 셈입니다. 다만, nginx 컨테이너에 대한 수정은 아직 불가능합니다. 그래서 nginx-http 컨테이너와 nginx-unix 컨테이너가 필요하며, 이들은 상호 배타적이어야 하나요? …

확실히 플러그인 관리가 더 좋아질 수는 있지만, docker compose로 이렇게 하려면 지옥이 될 것입니다.