Excellent. Nope that will be perfect. Thanks again! Very much appreciated.
إعجاب واحد (1)
The command is now ./discourse-setup --two-container
worked as expected just now 
إعجابَين (2)
Good catch! Did it print a message that made it easy to figure that out?
I’ve been meaning to clean up this topic since they change.
إعجاب واحد (1)
Yes, very helpful thanks.
إعجابَين (2)
Are there any plans to migrate from the old “container links” thing to proper setup with a custom network with two containers being connected to it?
“Links” are legacy and may be removed in the future according to Docker docs
إعجاب واحد (1)
That sounds like a good idea.
Unless someone beats me to it, I’ll see about subunits /creating a PR to switch to networks and /or sockets (which some prefer anyway) and creating a howto to convert an existing setup to the new configuration.
5 إعجابات
@pfaffman لا أعرف ما إذا كنت قد وصلت إلى ذلك، ولكن إذا كنت قد فعلت، فهل ترغب في ربطه هنا؟ 
3 إعجابات
هل يجب أن نضيف && ./launcher cleanup إلى نهاية هذه الأوامر؟
لقد وجدت أنه بعد التبديل إلى تثبيت حاويتين، لا يستغرق الأمر وقتًا طويلاً لملء مساحة التخزين المتاحة بالصور القديمة.
إعجاب واحد (1)
أوصي بذلك بالتأكيد في دليلي… الكثير من الأشخاص ينشرون على أنظمة صغيرة مثل قطرات DO وأعلم أنني ساعدت آخرين لم يدركوا تمامًا أين كانت مساحتهم تذهب.
إعجابَين (2)
@pfaffman، مرحبًا،
قبل بضعة أيام قمت بتثبيت AWS EC2 مع حاوية واحدة وعمل كل شيء بشكل جيد. لكنني بحاجة إلى تكوين الحاوية المكونة من حاويتين بالضبط، web_only على EC2 و data على AWS RDS (PostgreSQL 15.3 على المنفذ 5432 => لا يمكنني اختيار إصدار آخر، وقاعدة البيانات ليس لديها معلمة DB_NAME). كمجموعة Redis، حاولت استخدام AWS ElastiCache، لكنني تركت رابطًا في data.yml للقالب الموجود:
#- "templates/postgres.template.yml"
- "templates/redis.template.yml"
بعد التمهيد الناجح لـ data و web_only، لا يمكنني فتح صفحة الويب. “لا يمكن الوصول إلى هذا الموقع”
لم أقم بإجراء أي تغييرات على سجلات DNS أو تغيير إعدادات الوصول في مجموعات أمان AWS (جدار الحماية للويب وقاعدة البيانات).
تم التمهيد بنجاح، للبدء استخدم ./launcher start data
root@ip-172-31-3-68:/var/discourse# ./launcher start data
تم اكتشاف بنية x86_64.
+ /usr/bin/docker run --shm-size=512m -d --restart=always -e LANG=en_US.UTF-8 -e LC_ALL=en_US.UTF-8 -e LANGUAGE=en_US.UTF-8 -h ip-172-31-3-68-data -e DOCKER_HOST_IP=172.17.0.1 --name data -t -v /var/discourse/shared/data:/shared -v /var/discourse/shared/data/log/var-log:/var/log --mac-address <...> local_discourse/data /sbin/boot
27b66e577d250e4178f5e145c9962be7b5f2d905cfacd233d3d2278e7b83aa93
تم التمهيد بنجاح، للبدء استخدم ./launcher start web_only
root@ip-172-31-3-68:/var/discourse# ./launcher start web_only
تم اكتشاف بنية x86_64.
+ /usr/bin/docker run --shm-size=512m --link data:data -d --restart=always -e LANG=en_US.UTF-8 -e RAILS_ENV=production -e UNICORN_WORKERS=2 -e UNICORN_SIDEKIQS=1 -e RUBY_GC_HEAP_GROWTH_MAX_SLOTS=40000 -e RUBY_GC_HEAP_INIT_SLOTS=400000 -e RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR=1.5 -e DISCOURSE_DB_SOCKET= -e DISCOURSE_DB_HOST=database-discourse.<...>.rds.amazonaws.com -e DISCOURSE_DB_PORT= -e LETSENCRYPT_DIR=/shared/letsencrypt -e DISCOURSE_FORCE_HTTPS=true -e LC_ALL=en_US.UTF-8 -e LANGUAGE=en_US.UTF-8 -e DISCOURSE_HOSTNAME=talk.furtherium.com -e DISCOURSE_DEVELOPER_EMAILS=hello@furtherium.com -e DISCOURSE_SMTP_ADDRESS=email-smtp.us-east-2.amazonaws.com -e DISCOURSE_SMTP_PORT=587 -e DISCOURSE_SMTP_USER_NAME=A<...>S -e DISCOURSE_SMTP_PASSWORD=B<...>M -e DISCOURSE_NOTIFICATION_EMAIL=noreply@talk.furtherium.com -e LETSENCRYPT_ACCOUNT_EMAIL=me@example.com -e DISCOURSE_DB_NAME= -e DISCOURSE_DB_USERNAME=postgres -e DISCOURSE_DB_PASSWORD=7<...>1 -e DISCOURSE_REDIS_HOST=data -h ip-172-31-3-68-web-only -e DOCKER_HOST_IP=172.17.0.1 --name web_only -t -p 80:80 -p 443:443 -v /var/discourse/shared/web-only:/shared -v /var/discourse/shared/web-only/log/var-log:/var/log --mac-address <...> local_discourse/web_only /sbin/boot
1233f1c660eb7cecc48d2a840aae037b46ecfd7afe029ef89b2e686b136b9886
- لقد تحققت من الاتصال بقاعدة البيانات من SSH باستخدام telnet - حسنًا
- يمكنني رؤية اتصالات قاعدة البيانات في لوحة تحكم AWS RDS
- لقد أعدت تشغيل المثيلات 3 مرات
- لقد قمت بإعادة البناء 3-4 مرات دون أخطاء
- لقد تحققت من قائمة الحاويات والصور النشطة، وقمت بتنظيف غير الضرورية
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
1233f1c660eb local_discourse/web_only "/sbin/boot" 18 minutes ago Up 18 minutes 0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp web_only
27b66e577d25 local_discourse/data "/sbin/boot" 47 minutes ago Up 47 minutes data
ماذا يمكنني أن أفعل أيضًا؟ شكرًا لجهودكم ووقتكم!
لست بحاجة لذلك. أنت تحتاج فقط إلى حاوية الويب وحذف قوالب Postgres و Redis. Elasticache، في رأيي، باهظ الثمن بشكل سخيف، لذا يمكنك تشغيله على EC2 الخاص بك إذا كنت تستخدم مضيفًا واحدًا.
فقط أضف متغيرات البيئة إلى ملف app.yml الحالي الخاص بك واحذف القوالب غير الضرورية. سمعت مؤخرًا أن هذا الموقع يعمل على PG15، لذا يجب أن يكون ذلك جيدًا.
شكراً على الرد يا جاي (@pfaffman). أود فقط توضيح:
- هل يجب أن أستخدم تثبيت app.yml بالحاوية الواحدة وأعلق على الأسطر المتعلقة بقاعدة البيانات و Redis؟ وأيضًا في حقل ENV الخاص بـ app.yml ثم أضيف أسطرًا لقاعدة البيانات البعيدة في AWS (DB_USER، إلخ - من web_only كما هو الآن)؟
- أم أتركه كما هو، ولكن أوقف حاوية البيانات وأترك فقط web-only؟
- إذا لم أستخدم ElastiCache، فهل أحتاج إلى ترك السطر “templates/redis.template.yml”؟
تغيير الإعداد القياسي إلى حاويتين تم بسلاسة تقريبًا. أضعت الكثير من الوقت بسبب بعض المسافات المفقودة في ملف yml، والتي حاولت إقناعي بأن لدي مشاكل في الترجمة (لم تكن قريبة حتى) ولكن هذا كان خطأ من المستخدم.
ولكن عندما قمت بتشغيل المنتدى، كان لدي منتدى جديد تمامًا. كان من السهل إصلاح ذلك، لأن لدي نسخة احتياطية محدثة في S3، ولكني أتساءل الآن لماذا حدث ذلك في المقام الأول - أي تخمينات؟
أعني أن اتخاذ المسار الذي سأقوم فيه بتثبيت إعداد حاويتين جديدتين تمامًا ثم استعادته من النسخ الاحتياطية يمكن أن يوفر بعض الوقت. أو لا، لأنني ما زلت سأقوم بتحرير ملف yml، على الأقل إضافة المكونات الإضافية، وإصلاح إعدادات البريد الإلكتروني، و maxmind وما إلى ذلك.
إعجاب واحد (1)
[غير متعلق بالمنشور أعلاه]
أتساءل، ما هي ميزة استخدام إعداد حاويتين؟ لماذا ليس الحاوية الواحدة العادية؟
أعتقد أن ذلك لعدم إبقاء منتداك غير متصل بالإنترنت عند إجراء إعادة بناء للترقيات/تثبيت مكون إضافي
إعجابَين (2)
بالنسبة لي، تم بالفعل ذكر فترة توقف قصيرة. بالإضافة إلى ذلك، أقوم بالترقية كثيرًا، مرة واحدة على الأقل في الأسبوع، لذا فإن إعداداتي عرضة لمواجهة الأخطاء - ليس كثيرًا، يجب أن أقول، ولكن بين الحين والآخر لا يزال الأمر كذلك.
في المرات التي يكون فيها السبب هو إضافة - ليس كثيرًا، في الغالب يكون مكونًا ما - أحتاج إلى ثلاث إلى أربع جولات لحل المشكلة. وعندما تستغرق كل جولة حوالي 30 دقيقة، سيكون منتداي معطلاً لفترة طويلة جدًا، حتى لو كان صغيرًا ويعتمد على الهواية.
والسبب الثالث هو لأنني أستطيع.
إعجابَين (2)
أجد الأمر مرهقًا للغاية إذا فشل إعادة البناء وتعطل موقعي. في الأساس، يتطلب اهتمامي الفوري (وأحيانًا المطول) للفرز / إيجاد حل بديل. ليس ممتعًا على الإطلاق!!!
يقوم تثبيت الحاويتين بتحويل هذا إلى مجرد إزعاج، ويمكن عادةً التعامل مع المشكلة الأساسية في وقت يناسبني. أيضًا، غالبًا ما تم حل المشكلة التي تسببت في المشكلة بحلول تلك المرحلة.
إذا كنت تستخدم stable، فربما لن أزعج نفسي. ولكن العيش أقرب إلى الحافة باستخدام tests-passed، فهو لا يقدر بثمن للمرونة التي يمنحها أثناء عمليات إعادة البناء / التحديثات.
إعجابَين (2)
أوه ، فهمت. شكراً على الشرح!
لقد نسيت تمامًا أنني نشرت ذلك!
إعجاب واحد (1)
دروس لطيفة. استغرقت مني 5 دقائق، مع خادم جديد، لإنشاء واستعادة النسخة الاحتياطية ثم `./discourse-setup --two-container’.
شكرا لك
إعجابَين (2)
هل يمكن لأي شخص شرح لماذا، إذا كنت تقوم بتحويل خادم موجود بقاعدة بيانات سليمة، فهذه الخطوة ضرورية؟
أتفهم أن إنشاء نسخة احتياطية آمنة خارج الموقع قبل الترحيل مباشرة هو ممارسة جيدة، ولكن لماذا التنزيل؟
إعجابَين (2)