Docker compose biedt niet de benodigde functionaliteit. Discourse’s docker file templating constructie maakt flexibele docker resultaten mogelijk. Met compose heb je slechts een mogelijke set van vaste Dockerfiles die kunnen resulteren in een hoop containers.
In mijn Discourse setup gebruik ik een enkele container met Discourse en nginx via een UNIX socket. PostgreSQL en Redis zijn een service op de host. Dat is een behoorlijke afwijking van de standaard setup, maar het is out-of-the-box mogelijk.
Het is gedeeltelijk mogelijk met compose, misschien door gebruik te maken van de nogal slecht ontworpen profiel functie. Maar zelfs dan is het nogal rommelig. Of je zou verschillende compose files moeten leveren voor elke variatie.
Je verplaatst het probleem alleen maar.
Een schone compose setup voor Discourse zou de volgende services in aparte containers zijn:
- Discourse
- nginx
- PostgreSQL
- Redis
Discourse en nginx moeten een volume delen, geen probleem.
PostgreSQL en Redis… dat zijn dingen die je misschien elders wilt hosten, en geen Discourse specifieke container ervoor wilt hebben. En nu wordt docker compose een probleem docker compose up -d zal je ongewenste PostgreSQL starten. Ok, dus we maken er docker compose --profile postgresql up -d van om de basis discourse setup en een postgresql container te starten. docker compose --profile postgresql --profile redis up -d voor de “volledige” zelfstandige Discourse container setup. Je kunt beter geen --profile ... argument vergeten, want dan heb je meer problemen.
Dus voor een betere UX, maak je een launcher om het aanmaken van het gewenste docker compose commando af te handelen. Nu zijn we weer terug waar we waren. Behalve dat aanpassingen aan de nginx container nog niet mogelijk zijn. Dus ik heb een nginx-http container en een nginx-unix container nodig die wederzijds exclusief zouden moeten zijn? …
Zeker, het plugin management zou beter kunnen, maar dit doen met docker compose, dat wordt de hel.