Docker Compose vs Docker Swarm

Docker Compose Vs Docker Swarm



نمت تطبيقات 'ثورة' الحاوية أكثر بكثير من كونها مجرد قاعدة بيانات وواجهة أمامية. تنقسم التطبيقات إلى خدمات صغيرة متنوعة وتتواصل عادةً مع بعضها البعض عبر واجهة برمجة تطبيقات REST (عادةً حمولات بتنسيق JSON عبر HTTP). تعتبر حاويات Docker مثالية لهذا النوع من الهندسة المعمارية. يمكنك تجميع 'الخدمات المصغرة' للواجهة الأمامية في حاوية Docker ، وتنتقل قاعدة البيانات إلى حاوية أخرى ، وهكذا دواليك. تتحدث كل خدمة إلى أخرى عبر واجهة برمجة تطبيقات REST محددة مسبقًا بدلاً من أن تكون متراصة مكتوبة كقطعة واحدة من البرامج.

إذا كنت بحاجة إلى تنفيذ وظيفة أو ميزة جديدة ، على سبيل المثال ، محرك تحليلات ، فيمكنك ببساطة كتابة خدمة مصغرة جديدة لذلك وسوف تستهلك البيانات عبر واجهة برمجة تطبيقات REST التي تعرضها الخدمات المصغرة المتنوعة لتطبيق الويب الخاص بك. ومع نمو وظائفك بمرور الوقت ، ستنمو قائمة الخدمات المصغرة هذه أيضًا.







لا تريد نشر كل حاوية فردية ، وتهيئتها ثم تهيئة كل شيء آخر للتحدث معها أيضًا. سيصبح ذلك مملاً حتى مع وجود ثلاث حاويات. يتيح لك Docker-Compose أتمتة نشر العديد من الحاويات.



Docker-Compose هي واحدة من أبسط الأدوات التي تساعدك على تحويل الفكرة المجردة للخدمات المصغرة إلى مجموعة وظيفية من حاوية Docker.



الانظمة الموزعة

الآن بعد أن قمنا بتقسيم تطبيق الويب إلى عدة حاويات ، فليس من المنطقي الاحتفاظ بها جميعًا على خادم واحد (والأسوأ من ذلك على جهاز افتراضي واحد!) حيث يتم تشغيل خدمات مثل Docker Swarm و Kubernetes.





يتيح لك Docker Swarm تشغيل عدة نسخ متماثلة لتطبيقك عبر خوادم متعددة. إذا كانت خدمتك المصغرة مكتوبة بطريقة يمكن توسيع نطاقها 'أفقيًا' ، فيمكنك استخدام Docker Swarm لنشر تطبيق الويب الخاص بك عبر مراكز بيانات متعددة ومناطق متعددة. يوفر هذا مرونة ضد فشل واحد أو أكثر من مراكز البيانات أو روابط الشبكة. يتم ذلك عادةً باستخدام أمر فرعي في Docker ، أي Docker Stack.

ال عامل ميناء المكدس يتصرف الأمر الفرعي إلى حد كبير مثل أمر Docker-Compose ويمكن أن يؤدي ذلك إلى مفاهيم خاطئة لشخص يستخدم أيًا من التقنيات.



مصدر الارتباك

من حيث الاستخدام وسير العمل ، تعمل كلتا التقنيتين بشكل متشابه جدًا ، وهذا يسبب الارتباك. الطريقة التي تنشر بها تطبيقك باستخدام Docker Swarm أو Docker-Compose متشابهة جدًا. أنت تحدد تطبيقك في ملف YAML ، وسيحتوي هذا الملف على اسم الصورة والتكوين لكل صورة وأيضًا المقياس (عدد النسخ المتماثلة) التي ستكون كل خدمة صغيرة مطلوبة للوفاء بها أثناء النشر.

يكمن الاختلاف في الغالب في الخلفية ، حيث ينشر عامل الإرساء حاوية على مضيف Docker واحد ، ينشرها Docker Swarm عبر عقد متعددة. بشكل فضفاض ، لا يزال بإمكانه القيام بمعظم الأشياء التي يمكن أن يقوم عامل الإرساء بتكوينها ولكنه يوسع نطاقها عبر مضيفي Docker المتعددين.

التشابه

لكل من Docker Swarm و Docker-Compose أوجه التشابه التالية:

  1. يأخذ كلاهما تعريفات بتنسيق YAML لمكدس التطبيقات الخاص بك.
  2. كلاهما مخصص للتعامل مع التطبيقات متعددة الحاويات (الخدمات المصغرة)
  3. كلاهما له معلمة مقياس تسمح لك بتشغيل حاويات متعددة لنفس الصورة مما يسمح للخدمة المصغرة بالتوسع أفقيًا.
  4. كلاهما تحتفظ بهما نفس الشركة ، أي Docker ، Inc.

اختلافات

الاختلافات القليلة بين Docker Swarm و Docker-Compose:

  1. يستخدم Docker Swarm لتوسيع نطاق تطبيق الويب الخاص بك عبر خادم واحد أو أكثر. حيث سيقوم Docker-compose بتشغيل تطبيق الويب الخاص بك على مضيف Docker واحد.
  2. توسيع نطاق تطبيق الويب الخاص بك يوفر Docker Swarm توفرًا عاليًا للغاية وتحملًا للأخطاء. توسيع نطاق تطبيق الويب الخاص بك باستخدام Docker-Compose على مضيف واحد مفيد فقط للاختبار والتطوير.
  3. تم دمج Docker Swarm والأوامر الفرعية ذات الصلة مثل Docker Swarm و Docker Stack في Docker CLI نفسه. كلهم جزء من Docker binary الذي تتصل به عبر جهازك الطرفي. Docker-Compose هو برنامج ثنائي مستقل بذاته.

حالة استخدام ل Docker-Compose

كما هو موضح أعلاه ، كلاهما أداتان مختلفتان تمامًا وكل منهما يحل مشكلة مختلفة تمامًا ، لذا لا يبدو أن أحدهما بديل للآخر. ومع ذلك ، لمنح القادمين الجدد فكرة عما أتحدث عنه ، إليك حالة استخدام لـ Docker Compose.

لنفترض أنك تريد استضافة مدونة WordPress بنفسك على خادم واحد. إعداده أو صيانته ليس شيئًا تريد القيام به يدويًا ، لذا ما ستفعله بدلاً من ذلك هو تثبيت Docker و Docker-compose على VPS الخاص بك ، وإنشاء ملف YAML بسيط يحدد جميع الجوانب المختلفة لمكدس WordPress الخاص بك ، كما هو موضح أدناه ، :

ملاحظة: إذا كنت تستخدم ما يلي لنشر موقع WordPress ، فالرجاء تغيير جميع كلمات المرور إلى شيء آمن. والأفضل من ذلك ، استخدم Docker Secrets لتخزين البيانات الحساسة مثل كلمات المرور ، بدلاً من وضعها في ملف نصي عادي.

إصدار:'3'

خدمات:
ديسيبل:
الصورة: mysql:5.7
أحجام:
- db_data:/أين/ليب/mysql
إعادة التشغيل: دائمًا
بيئة:
MYSQL_ROOT_PASSWORD: ضغط ما
MYSQL_DATABASE: وورد
MYSQL_USER: وورد
MYSQL_PASSWORD: وورد

ووردبرس:
يعتمد على:
- ديسيبل
الصورة: وورد: الأحدث
الموانئ:
-'8000: 80'
إعادة التشغيل: دائمًا
بيئة:
WORDPRESS_DB_HOST: ديسيبل:3306
WORDPRESS_DB_USER: wordpress
WORDPRESS_DB_PASSWORD: wordpress
WORDPRESS_DB_NAME: وورد
أحجام:
db_data:{}

بمجرد إنشاء الملف وتثبيت كل من Docker و Docker-compose ، كل ما عليك فعله هو تشغيل:

$عامل الميناء يؤلف

وسيكون موقعك جاهزًا للعمل. إذا كان هناك تحديث ، فقم بتشغيل:

$عامل ميناء يؤلف

ثم تخلص من صور Docker القديمة وقم بتشغيل الأمر docker-compose up -d وسيتم سحب الصور الجديدة تلقائيًا. نظرًا لأن لديك بيانات ثابتة مخزنة في Docker Volume ، فلن يتم فقد محتوى موقع الويب الخاص بك.

متى تستخدم Docker Swarm

بينما يعد Docker-compose أداة أتمتة ، فإن Docker Swarm مخصص للتطبيقات الأكثر تطلبًا. تطبيقات الويب مع مئات أو آلاف المستخدمين أو عبء العمل الذي يحتاج إلى توسيع نطاقه بشكل متوازي. قد ترغب الشركات التي لديها قاعدة مستخدمين كبيرة ومتطلبات صارمة لاتفاقية مستوى الخدمة (SLA) في استخدام نظام موزع مثل Docker Swarm. إذا كان تطبيقك يعمل عبر خوادم متعددة ومراكز بيانات متعددة ، فإن فرص التوقف بسبب ارتباط DC أو الشبكة المتأثرة تقل بشكل كبير.

ومع ذلك ، أتردد في التوصية بـ Docker Swarm لحالات استخدام الإنتاج لأن التقنيات المنافسة مثل Kubernetes يمكن القول إنها أكثر ملاءمة لهذه المهمة. يتم دعم Kubernetes محليًا عبر العديد من موفري الخدمات السحابية وهو يعمل بشكل جيد مع Docker Containers ، لذا لن تضطر حتى إلى إعادة إنشاء تطبيقك للاستفادة من Kubernetes.

استنتاج

آمل أن يكون هذا التنزه على Docker ومشاريع الأقمار الصناعية الخاصة به مفيدًا وأنك أكثر استعدادًا للنظام البيئي لرسو السفن.