Ein Seitengespräch mit @rosscdh hat ergeben, dass sein Hauptziel Discourse auf Kubernetes ist. Dies wird hier nicht als unterstützte Konfiguration angeboten. Es gibt berechtigte Kritik an unserer Vorgehensweise im Zusammenhang mit Docker/Kubernetes; dennoch haben wir uns für diesen Ansatz mit launcher entschieden, um die Benutzerfreundlichkeit im Bereich Self-Hosting zu erhöhen.
Ich habe dieses Thema wieder geöffnet, bitte bleibt aber zivil und konstruktiv.
Aber es gab diese Sache erst, nachdem ./launcher entwickelt wurde. 
Wenn du auf k8s oder Ähnliches starten möchtest, dann mache ich folgendes: Ich verwende den Launcher, um das Image zu erstellen und irgendwohin zu pushen, und lasse dann k8s dieses Image starten. Der Launcher erledigt einige Dinge wie die Migration der Datenbank bei Updates, also musst du darauf achten, wie das funktioniert.
Danke dafür,
Das Ziel ist es, es docker-ähnlicher zu gestalten, damit es sowohl auf Kubernetes als auch mit Docker in Standalone-Containern laufen kann.
Ich habe es geschafft, den Launcher zu verwenden und ein 2+ GB großes Image zu generieren (4 Plugins, 6 sind aufgrund von Limits nicht möglich).
Außerdem habe ich es mit Docker Compose konfiguriert, sodass es jetzt ein sauberes Runbook ist. Ich bin mit GlobalSettings vertraut und habe application.rb und routes.rb leicht angepasst, sodass ich nur noch Anpassungen mounte.
version: '3'
networks:
discourse-net:
services:
mailhog:
image: mailhog/mailhog:latest
networks:
- discourse-net
ports:
- 8025:8025
postgres:
image: postgres:9.6
networks:
- discourse-net
environment:
POSTGRES_PASSWORD: password
POSTGRES_USER: discourse
POSTGRES_DB: discourse
redis:
image: redis:alpine
networks:
- discourse-net
discourse:
image: discourse-monkey:latest
working_dir: /var/www/discourse
command: bash /var/www/discourse/entrypoint.sh
# ports:
# - 3000:3000 # use the nginx entrypoint
networks:
- discourse-net
volumes:
- ./entrypoint.sh:/var/www/discourse/entrypoint.sh
- ./config/unicorn.rb:/var/www/discourse/config/unicorn.rb
- ./config/application.rb:/var/www/discourse/config/application.rb
- ./envs/production.rb:/var/www/discourse/config/environments/production.rb
- ./overrides/routes.rb:/var/www/discourse/config/routes.rb
- ./generated/public/assets:/var/www/discourse/public/assets
- ./generated/public/images:/var/www/discourse/public/images
- ./generated/public/uploads:/var/www/discourse/public/uploads
- ./generated/public/javascripts:/var/www/discourse/public/javascripts
- ./generated/public/svg-sprite:/var/www/discourse/public/svg-sprite
environment:
LANG: en_US.UTF-8
DISCOURSE_DEFAULT_LOCALE: en
RAILS_ENV: production
## Wie viele gleichzeitige Webanfragen werden unterstützt? Hängt von Arbeitsspeicher und CPU-Kernen ab.
## Wird automatisch durch das Bootstrap-Script basierend auf erkannten CPUs gesetzt, oder Sie können es überschreiben
UNICORN_WORKERS: 3
## TODO: Der Domainname, auf den diese Discourse-Instanz antworten soll
DISCOURSE_HOSTNAME: discuss.monkey.tech:3001
DOCKER_USE_HOSTNAME: "true"
## Kommentieren Sie dies aus, wenn Sie möchten, dass der Container mit demselben
## Hostnamen (-h-Option) gestartet wird, wie oben angegeben (Standard: "$hostname-$config")
#DOCKER_USE_HOSTNAME: true
## TODO: Durch Kommas getrennte Liste von E-Mail-Adressen, die bei der ersten Anmeldung zu Administratoren und Entwicklern werden
## Beispiel: 'user1@example.com,user2@example.com'
DISCOURSE_DEVELOPER_EMAILS: 'me@example.com,you@example.com'
## TODO: Der SMTP-Mailserver, der zur Validierung neuer Konten und zum Senden von Benachrichtigungen verwendet wird
# SMTP-Adresse, Benutzername und Passwort sind erforderlich
# WARNUNG: Das Zeichen '#' im SMTP-Passwort kann Probleme verursachen!
DISCOURSE_SMTP_ADDRESS: mailhog
#DISCOURSE_SMTP_PORT: 587
DISCOURSE_SMTP_USER_NAME: mailhog
DISCOURSE_SMTP_PASSWORD: password
#DISCOURSE_SMTP_ENABLE_START_TLS: true # (optional, Standard: true)
## Wenn Sie die Lets-Encrypt-Vorlage hinzugefügt haben, kommentieren Sie unten aus, um ein kostenloses SSL-Zertifikat zu erhalten
#LETSENCRYPT_ACCOUNT_EMAIL: me@example.com
## TODO: Konfigurieren Sie die Verbindung zu den Datenbanken
# DISCOURSE_DB_SOCKET: ''
DISCOURSE_DB_HOST: postgres
DISCOURSE_DB_USERNAME: discourse
DISCOURSE_DB_PASSWORD: password
DISCOURSE_REDIS_HOST: redis
## Die HTTP- oder HTTPS-CDN-Adresse für diese Discourse-Instanz (konfiguriert zum Abrufen)
## Details unter https://meta.discourse.org/t/14857
DISCOURSE_CDN_URL: http://discuss.monkey.tech:3001
DISCOURSE_SERVE_STATIC_ASSETS: "true"
SKIP_ENFORCE_HOSTNAME: '0'
ENABLE_ASSETS_PIPELINE: '0'
ENABLE_DB_MIGRATE: '0'
DISCOURSE_ENABLE_CORS: 'false'
DISCOURSE_CORS_ORIGIN: '*'
#SKIP_DB_AND_REDIS: '1'
nginx:
image: fholzer/nginx-brotli
# command: /bin/sh -c "envsubst < /etc/nginx/conf.d/discourse.template.conf > /etc/nginx/conf.d/default.conf && nginx -g 'daemon off;'"
ports:
- 3001:80
depends_on:
- discourse
networks:
- discourse-net
volumes:
- ./config/nginx.application.conf:/etc/nginx/conf.d/default.conf
- ./generated/public:/var/www/discourse/public
- ./generated/nginx/cache:/var/nginx/cache
Funktioniert hervorragend; und der gesamte Verkehr wird über Nginx geleitet, das auch die Ausgaben von assets:precompile bereitstellt.
Der nächste Schritt besteht einfach darin, eine Reihe von Aufrufen an das Image zu haben, um Assets und db:migrate “on demand” vorzu compilieren, oder einfach exec zu verwenden, um dasselbe zu tun (da sich diese Elemente nicht häufig ändern), und vielleicht zu prüfen, ob ich die Größe dieses 2,6 GB großen Images reduzieren kann…
Es fühlt sich deutlich sauberer an. Wie bereits erwähnt, ist die pup-Funktionalität in Ordnung, und ich kann die Vorteile schätzen. Ich habe jedoch einige Bedenken bezüglich des Builds, bei dem Sie es ausführen, und der Verwendung von sudo-Strategien. (Dies ist sehr selten die Art und Weise, wie ich oder jemand, den ich kenne, arbeitet.) Normalerweise werden Images unabhängig erstellt und an anderer Stelle bereitgestellt (Kubernetes, SaltStack, Nomad, Docker Compose).
Ich habe einen potenziellen PR, um eine sample/kube.yml und applications/kubernetes.template.yml hinzuzufügen, da es bestimmte Elemente, Überschreibungen und Einstellungen gibt, um db und redis zu deaktivieren, und dann auch redis und db beim Build zu deaktivieren sowie precompile zu deaktivieren. Falls das interessant ist.
Es war eine interessante Erfahrung, danke für den Push.
Es gibt nur eine kleine Seltsamkeit im Zusammenhang mit den Fixtures (vielleicht durch mehrfaches Aufrufen von migrate).
Siehe angehängtes Bild
Ich glaube, docker-compose basiert auf einem Tool namens „fig“.
