تدير منظمتنا تطبيقًا ويبًا ومنتدىً، بالإضافة إلى بعض التطبيقات الأخرى مثل Bitwarden. قمتُ بتغليف جميع هذه الخدمات في حاويات (containers) لتحقيق التكافؤ بين بيئتي التطوير والإنتاج، ولتسهيل إعداد بيئة التطوير باستخدام Docker Compose. نستخدم ملف Compose مشابهًا جدًا لتشغيلها في الإنتاج، وقد أثبتت هذه الطريقة فعاليتها جدًا في حالتنا البسيطة.
أرغب في الانتقال بمنتدىنا إلى منصة Discourse، لكنني أجد صعوبة في كيفية الحفاظ على التكافؤ بين بيئتي التطوير والإنتاج، مع الحفاظ على بساطة إعداد بيئة التطوير.
تُشير الوثائق إلى أنه رغم استخدام Discourse لـ Docker للتثبيت والتشغيل، إلا أنه لا ينسجم تمامًا مع نموذج الحاويات كما هو الحال مع حاويات Docker الأخرى: فلا يمكنك إضافته إلى مكدس (stack) من نوع Compose أو Swarm أو Kubernetes وتشغيله، وربطه بقواعد البيانات وحاويات Redis كما تفعل مع حاويات التطبيقات الأخرى. كما أن الحلول البديلة أو الاقتراحات تُثبَّط بشدة في محاولة لتجنب انقسام المجتمع، لذا فأنا هنا ليس لأسائل عن هذا النهج.
لقد قبلتُ أنه بدلًا من تشغيل وإدارة Discourse بنفس الطريقة التي أدير بها باقي مكدس خدماتي، سأحتاج إلى تشغيل آلة افتراضية مخصصة (VM) في بيئة الإنتاج وإدارتها بشكل مختلف. لكنني فضولي بشأن كيفية تحقيق أهدافي الأساسية: إعداد بيئة تطوير بسيطة تتمتع بتكافؤ معقول مع بيئة الإنتاج.
كخلفية، فإن إعداد التطوير الحالي لدينا هو: “تثبيت Docker، استنساخ هذا المستودع، ثم تشغيل أمر docker-compose up”. وإذا كنتُ أفهم بشكل صحيح من دليل التثبيت المحلي، فإننا سنحتاج الآن إلى 9 تبعيات للنظام (مثل Ruby، وPostgres، وغيرها) قبل أن نستنسخ ونعد إعدادات Discourse يدويًا. في رأيي، إحدى مزايا Docker (وDocker Compose) هي أنك لا تحتاج إلى تشغيل برامج مثل Postgres وRedis على نظامك (مع المشاكل المرتبطة بإعدادها عندما يعمل المطورون على نظام Windows)؛ بل يمكنك فقط تشغيل المكدس وتكون العمليات معزولة داخل حاويات قابلة للتخلص منها. فهل هناك أي طريقة للحفاظ على هذه الميزة؟
العيب الآخر هو أنه، بما أننا فريق صغير من المتطوعين، فإن معظم المطورين الآخرين يستخدمون نظام Windows 10 Home، والذي، حسب علمي، لا يدعم WSL، مما يعني أنهم لن يتمكنوا من اتباع إرشادات التثبيت الخاصة بـ Windows على أي حال (حيث يعمل Docker على Windows 10 Home).