O Docker Compose não possui a funcionalidade necessária. A construção de templates de arquivos Docker do Discourse permite resultados flexíveis de Docker. Com o Compose, tudo o que você tem é um conjunto possível de Dockerfiles fixos que podem resultar em um monte de contêineres.
Na minha configuração do Discourse, uso um único contêiner com Discourse e nginx usando um socket UNIX. PostgreSQL e Redis são um serviço no host. Isso é um desvio considerável da configuração padrão, mas é possível de imediato.
É parcialmente possível com o Compose, talvez usando o recurso de perfil, que é mal projetado. Mas mesmo assim, é bastante confuso. Ou você precisaria entregar arquivos Compose diferentes para cada variação.
Você está apenas movendo o problema.
Uma configuração Compose limpa para o Discourse seria os seguintes serviços em contêineres separados:
- Discourse
- nginx
- PostgreSQL
- Redis
Discourse e nginx precisam compartilhar um volume, nada demais.
PostgreSQL e Redis… são coisas que você pode querer hospedar em outro lugar, e não ter um contêiner específico do Discourse para isso. E agora o docker compose se torna um problema: docker compose up -d iniciará seu PostgreSQL indesejado. Ok, então fazemos docker compose --profile postgresql up -d para iniciar a configuração básica do Discourse e um contêiner PostgreSQL. docker compose --profile postgresql --profile redis up -d para a configuração completa de contêineres do Discourse autossuficiente. É melhor você não esquecer um argumento --profile ..., porque então você terá mais problemas.
Então, para uma melhor experiência do usuário (UX), você cria um launcher para cuidar da criação do comando docker compose desejado. Agora estamos meio que de volta onde estávamos. Exceto que modificações no contêiner nginx ainda não são possíveis. Então eu preciso de um contêiner nginx-http e um contêiner nginx-unix que deveriam ser mutuamente exclusivos? …
Claro, o gerenciamento de plugins poderia ser melhor, mas fazer isso com o docker compose, isso será um inferno.