كشف محادثة جانبية مع @rosscdh أن هدفه النهائي الرئيسي هو تشغيل Discourse على Kubernetes. هذا التكوين غير مدعوم هنا. هناك انتقادات مشروعة لطريقة تعاملنا مع Docker/Kubernetes؛ ومع ذلك، فقد اخترنا اتباع هذا النهج مع launcher لتسهيل الاستخدام في عالم الاستضافة الذاتية.
لقد أعيدت فتح هذا الموضوع، ولكن يرجى الحفاظ على الاحترام والبناء في النقاش.
لكنه لم يكن موجودًا حتى بعد تطوير ./launcher. 
إذا كنت ترغب في التشغيل على k8s أو ما شابه، فإن ما أفعله هو استخدام المشغّل لبناء الصورة ودفعها إلى مكان ما، ثم ترك k8s يشغّل تلك الصورة. يقوم المشغّل ببعض المهام مثل ترحيل قاعدة البيانات عند الترقية، لذا يجب أن تنتبه لكيفية عمل ذلك.
شكرًا لك،
الهدف هو جعل الأمر أكثر تشابهًا مع Docker بحيث يمكن تشغيله على Kubernetes وكذلك باستخدام Docker مع حاويات مستقلة.
تمكنت من استخدام المُشغّل (launcher) وتوليد صورة بحجم 2+ جيجابايت (مع 4 إضافات، ولا يمكن استخدام 6 بسبب القيود).
كما قمت بتكوينها باستخدام Docker Compose لتصبح الآن دليل تشغيل نظيف.
أنا على دراية بـ GlobalSettings وقمت بتعديل application.rb و routes.rb بشكل طفيف، لذا أنا أقوم فقط بتحميل التخصيصات.
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
## How many concurrent web requests are supported? Depends on memory and CPU cores.
## will be set automatically by bootstrap based on detected CPUs, or you can override
UNICORN_WORKERS: 3
## TODO: The domain name this Discourse instance will respond to
DISCOURSE_HOSTNAME: discuss.monkey.tech:3001
DOCKER_USE_HOSTNAME: "true"
## Uncomment if you want the container to be started with the same
## hostname (-h option) as specified above (default "$hostname-$config")
#DOCKER_USE_HOSTNAME: true
## TODO: List of comma delimited emails that will be made admin and developer
## on initial signup example 'user1@example.com,user2@example.com'
DISCOURSE_DEVELOPER_EMAILS: 'me@example.com,you@example.com'
## TODO: The SMTP mail server used to validate new accounts and send notifications
# SMTP ADDRESS, username, and password are required
# WARNING the char '#' in SMTP password can cause problems!
DISCOURSE_SMTP_ADDRESS: mailhog
#DISCOURSE_SMTP_PORT: 587
DISCOURSE_SMTP_USER_NAME: mailhog
DISCOURSE_SMTP_PASSWORD: password
#DISCOURSE_SMTP_ENABLE_START_TLS: true # (optional, default true)
## If you added the Lets Encrypt template, uncomment below to get a free SSL certificate
#LETSENCRYPT_ACCOUNT_EMAIL: me@example.com
## TODO: configure connectivity to the databases
# DISCOURSE_DB_SOCKET: ''
DISCOURSE_DB_HOST: postgres
DISCOURSE_DB_USERNAME: discourse
DISCOURSE_DB_PASSWORD: password
DISCOURSE_REDIS_HOST: redis
## The http or https CDN address for this Discourse instance (configured to pull)
## see https://meta.discourse.org/t/14857 for details
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 \u003c /etc/nginx/conf.d/discourse.template.conf \u003e /etc/nginx/conf.d/default.conf \u0026\u0026 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
يعمل بشكل رائع؛ وجميع حركة المرور تمر عبر Nginx الذي يشارك أيضًا مخرجات assets:precompile.
الخطوات التالية هي ببساطة وجود مجموعة من المكالمات للصورة لتجميع الأصول (precompile) وتشغيل db:migrate “حسب الطلب” أو ببساطة استخدام exec للقيام بنفس الشيء (حيث أن هذه العناصر لا تتغير كثيرًا)، وربما نرى ما إذا كان يمكنني تقليل حجم هذه الصورة البالغة 2.6 جيجابايت…
أشعر أنها أصبحت أنظف بكثير، وكما ذكرت سابقًا، وظيفة pup جيدة؛ ويمكنني تقدير ما تقدمه. لدي العديد من التحفظات حول عملية البناء حيث يتم تشغيلها واستخدام استراتيجيات sudo.. (هذا نادرًا جدًا كيف أعمل أنا أو أي شخص أعرفه) عادةً ما تُبنى الصور بشكل مستقل وتُنشر في أماكن أخرى (kube, saltstack, nomad, docker-compose).
لدي اقتراح محتمل لطلب سحب (PR) لإضافة sample/kube.yml و applications/kubernetes.template.yml حيث توجد عناصر معينة، وتجاوزات وإعدادات لتعطيل قاعدة البيانات و Redis، ثم تعطيل Redis و قاعدة البيانات فعليًا أثناء البناء بالإضافة إلى تعطيل التجميع المسبق للأصول.. إذا كان ذلك مثيرًا للاهتمام.
كانت تجربة مثيرة للاهتمام، شكرًا لك على التذكير..
هناك غرابة صغيرة واحدة تتعلق بملفات fixtures (ربما ناتجة عن استدعاء migrate عدة مرات)
انظر الصورة المرفقة
أعتقد أن docker-compose استند إلى أداة تسمى “fig”.
