Une conversation parallèle avec @rosscdh a révélé que son objectif principal est d’utiliser Discourse sur Kubernetes. Ce n’est pas une configuration prise en charge ici. Il existe des critiques valables concernant la manière dont nous procédons en relation avec Docker/Kubernetes ; cependant, nous avons choisi cette approche avec launcher pour faciliter son utilisation dans le monde de l’hébergement autonome.
J’ai rouvert ce sujet, mais veuillez rester courtois et constructif.
Mais ce n’était pas le cas avant que ./launcher ne soit développé. 
Si vous souhaitez lancer sur k8s ou similaire, ce que je fais est d’utiliser le lanceur pour construire l’image, de la pousser quelque part, puis de laisser k8s lancer cette image. Le lanceur effectue certaines tâches comme la migration de la base de données lors des mises à niveau, vous devez donc faire attention au fonctionnement de cela.
Merci pour cela,
L’objectif est de rendre le tout plus compatible Docker afin qu’il puisse s’exécuter sur Kubernetes, tout en restant utilisable avec Docker et des conteneurs autonomes.
J’ai réussi à utiliser le lanceur pour générer une image de plus de 2 Go (4 plugins, impossible d’aller à 6 à cause des limites).
J’ai également créé un docker-compose pour en faire un runbook propre.
Je suis familier avec GlobalSettings et j’ai légèrement modifié application.rb et routes.rb afin de simplement monter les personnalisations.
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 # utiliser l'entrypoint nginx
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
## Combien de requêtes web simultanées sont prises en charge ? Dépend de la mémoire et des cœurs CPU.
## Sera défini automatiquement par bootstrap en fonction des CPU détectés, ou vous pouvez le remplacer
UNICORN_WORKERS: 3
## TODO : Le nom de domaine auquel cette instance Discourse répondra
DISCOURSE_HOSTNAME: discuss.monkey.tech:3001
DOCKER_USE_HOSTNAME: "true"
## Décommentez si vous souhaitez que le conteneur soit démarré avec le même
## nom d'hôte (option -h) que spécifié ci-dessus (par défaut "$hostname-$config")
#DOCKER_USE_HOSTNAME: true
## TODO : Liste d'e-mails séparés par des virgules qui seront administrateurs et développeurs
## lors de l'inscription initiale, par exemple 'user1@example.com,user2@example.com'
DISCOURSE_DEVELOPER_EMAILS: 'me@example.com,you@example.com'
## TODO : Le serveur de messagerie SMTP utilisé pour valider les nouveaux comptes et envoyer des notifications
# L'adresse, le nom d'utilisateur et le mot de passe SMTP sont requis
# ATTENTION : le caractère '#' dans le mot de passe SMTP peut causer des problèmes !
DISCOURSE_SMTP_ADDRESS: mailhog
#DISCOURSE_SMTP_PORT: 587
DISCOURSE_SMTP_USER_NAME: mailhog
DISCOURSE_SMTP_PASSWORD: password
#DISCOURSE_SMTP_ENABLE_START_TLS: true # (optionnel, par défaut true)
## Si vous avez ajouté le modèle Lets Encrypt, décommentez ci-dessous pour obtenir un certificat SSL gratuit
#LETSENCRYPT_ACCOUNT_EMAIL: me@example.com
## TODO : configurer la connectivité aux bases de données
# DISCOURSE_DB_SOCKET: ''
DISCOURSE_DB_HOST: postgres
DISCOURSE_DB_USERNAME: discourse
DISCOURSE_DB_PASSWORD: password
DISCOURSE_REDIS_HOST: redis
## L'adresse CDN http ou https pour cette instance Discourse (configurée pour récupérer)
## voir https://meta.discourse.org/t/14857 pour les détails
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
Ça fonctionne à merveille ; tout le trafic passe par nginx qui partage également la sortie de assets:precompile.
La prochaine étape consiste simplement à avoir un ensemble d’appels à l’image pour précompiler les assets et exécuter db:migrate “à la demande” ou simplement utiliser exec pour faire la même chose (car ces éléments ne changent pas souvent) et peut-être voir si je peux réduire la taille de cette image de 2,6 Go…
Cela semble beaucoup plus propre. Comme mentionné précédemment, la fonctionnalité pup est correcte et j’apprécie ce qu’elle offre. J’ai cependant plusieurs réserves concernant la méthode de build où vous l’exécutez et l’utilisation de stratégies sudo (c’est très rarement ainsi que je fonctionne, ou que toute personne que je connais fonctionne). Habituellement, les images sont construites indépendamment et déployées ailleurs (kube, saltstack, nomad, docker-compose).
J’ai un PR potentiel à ajouter avec un échantillon/kube.yml et applications/kubernetes.template.yml car il y a certains éléments, des remplacements et des paramètres pour désactiver la base de données et Redis, puis désactiver réellement Redis et la base de données lors du build, ainsi que désactiver la précompilation… si cela vous intéresse.
Ce fut une expérience intéressante, merci pour le relancement.
Il n’y a qu’une seule petite bizarrerie liée aux fixtures (peut-être due à l’appel de migrate plusieurs fois).
Voir l’image jointe
Je pense que docker-compose était basé sur un outil appelé “fig”.
