عامل الميناء هو لعبة أم لا؟ أم أنها لا تزال؟

مرحبا بالجميع!

أريد حقا أن أنتقل مباشرة إلى الموضوع، ولكن سيكون من الأصح أن أقول قليلا عن قصتي:

دخول

أنا مبرمج ولدي خبرة في تطوير تطبيقات الواجهة الأمامية ذات الصفحة الواحدة وscala/java وnodejs على الخادم.

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

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

أسباب الاستخدام

لماذا استخدمت عامل الإرساء؟ ربما للأسباب التالية:

• إطلاق قاعدة البيانات، 99% من التطبيقات تستخدمها
• إطلاق nginx لتوزيع الواجهة الأمامية وإنشاء وكيل للواجهة الخلفية
• يمكنك حزم التطبيق في صورة عامل إرساء، وبهذه الطريقة سيعمل تطبيقي أينما يوجد عامل إرساء، ويتم حل مشكلة التوزيع على الفور
• اكتشاف الخدمة خارج الصندوق، يمكنك إنشاء خدمات صغيرة، يمكن لكل حاوية (متصلة بشبكة مشتركة) الوصول بسهولة إلى حاوية أخرى عبر اسم مستعار، وهو أمر مريح للغاية
• من الممتع إنشاء حاوية و"اللعب" فيها.

ما لا يعجبني دائمًا في عامل الإرساء:

• لكي يعمل تطبيقي، أحتاج إلى وجود Docker نفسه على الخادم. لماذا أحتاج إلى ذلك إذا كانت تطبيقاتي تعمل على jre أوnodejs وكانت البيئة الخاصة بها موجودة بالفعل على الخادم؟
• إذا كنت أرغب في تشغيل صورتي (الخاصة) المجمعة محليًا على خادم بعيد، فأنا بحاجة إلى مستودع عامل الإرساء الخاص بي، وأحتاج إلى التسجيل للعمل في مكان ما، وأحتاج أيضًا إلى تكوين https، لأن docker cli يعمل فقط عبر https. يا اللعنة... هناك خيارات بالطبع لحفظ الصورة محليًا عبر docker save وأرسل الصورة فقط عبر scp... ولكن هذا كثير من حركات الجسم. وإلى جانب ذلك، فإنه يبدو وكأنه حل "عكاز" حتى يظهر المستودع الخاص بك
• docker-compose. هناك حاجة فقط لتشغيل الحاويات. هذا كل شئ. لا يستطيع أن يفعل أي شيء آخر. Docker-compose لديه مجموعة من الإصدارات من ملفاته، بناء الجملة الخاص به. بغض النظر عن مدى وضوحها، لا أريد قراءة وثائقهم. لن أحتاجه في أي مكان آخر.
• عند العمل ضمن فريق، يكتب معظم الأشخاص ملف Dockerfile بطريقة ملتوية للغاية، ولا يفهمون كيفية تخزينه مؤقتًا، ويضيفون كل ما يحتاجونه وما لا يحتاجونه إلى الصورة، ويرثون من الصور غير الموجودة في Dockerhub أو مستودع خاص، وينشئون بعض docker-compose الملفات مع قواعد البيانات ولم يستمر شيء. في الوقت نفسه، يعلن المطورون بفخر أن Docker رائع، وكل شيء يعمل محليًا بالنسبة لهم، ومن المهم أن يكتب قسم الموارد البشرية في الوظيفة الشاغرة: "نحن نستخدم Docker ونحتاج إلى مرشح يتمتع بخبرة العمل هذه".
• تطاردني دائمًا الأفكار حول رفع كل شيء في Docker: postgresql، kafka، redis. من المؤسف أنه ليس كل شيء يعمل في حاويات، وليس كل شيء سهل التكوين والتشغيل. وهذا مدعوم من قبل مطوري الطرف الثالث، وليس من قبل البائعين أنفسهم. وبالمناسبة، يطرح السؤال على الفور: البائعون لا يقلقون بشأن الحفاظ على منتجاتهم في Docker، لماذا هذا، ربما يعرفون شيئًا ما؟
• السؤال الذي يطرح نفسه دائمًا هو مدى استمرارية بيانات الحاوية. ثم تفكر، هل يجب عليّ فقط تحميل دليل المضيف أو إنشاء وحدة تخزين عامل إرساء أو إنشاء حاوية بيانات موجودة الآن deprecated؟ إذا قمت بتثبيت دليل، فأنا بحاجة للتأكد من أن uid و gid للمستخدم في الحاوية يتطابقان مع معرف المستخدم الذي قام بتشغيل الحاوية، وإلا فسيتم إنشاء الملفات التي أنشأتها الحاوية بحقوق الجذر. إذا كنت تستخدم volume ثم سيتم ببساطة إنشاء البيانات في بعض /usr/* وستكون هناك نفس القصة مع uid و gid كما في الحالة الأولى. إذا كنت تقوم بتشغيل مكون تابع لجهة خارجية، فأنت بحاجة إلى قراءة الوثائق والبحث عن إجابة السؤال: "في أي أدلة حاوية يكتب المكون الملفات؟"

لم يعجبني دائمًا حقيقة أنني اضطررت إلى العبث بـ Docker لفترة طويلة في المرحلة الأولية: لقد اكتشفت كيفية تشغيل الحاويات، والصور التي سيتم التشغيل منها، وإنشاء ملفات Makefiles التي تحتوي على أسماء مستعارة لأوامر Docker الطويلة. لقد كرهت إنشاء عامل الإرساء لأنني لم أرغب في تعلم أداة أخرى في النظام البيئي لعامل الإرساء. و docker-compose up لقد أزعجني ذلك، خاصة إذا كانوا لا يزالون يجتمعون هناك build الإنشاءات، بدلاً من الصور المجمعة بالفعل. كل ما أردته حقًا هو صنع منتج بكفاءة وسرعة. لكن لم أتمكن من معرفة كيفية استخدام عامل الإرساء.

تقديم أنسيبل

لقد عملت مؤخرًا (قبل ثلاثة أشهر) مع فريق DevOps، وكان لكل عضو تقريبًا موقف سلبي تجاه Docker. لأسباب:

• قواعد عامل الإرساء iptables (على الرغم من أنه يمكنك تعطيلها في daemon.json)
• عامل الإرساء به أخطاء ولن نقوم بتشغيله في الإنتاج
• إذا تعطل برنامج docker daemon، فستتعطل جميع الحاويات ذات البنية التحتية وفقًا لذلك
• لا حاجة لرسو السفن
• لماذا عامل الإرساء إذا كان هناك أجهزة Ansible وافتراضية

في نفس الوظيفة، تعرفت على أداة أخرى - Ansible. لقد سمعت عنها مرة واحدة، لكنني لم أحاول كتابة قواعد اللعبة الخاصة بي. والآن بدأت بكتابة مهامي ثم تغيرت رؤيتي تماماً! لأنني أدركت: لدى Ansible وحدات نمطية لتشغيل نفس حاويات الإرساء، وبناء الصور، والشبكات، وما إلى ذلك، ويمكن تشغيل الحاويات ليس فقط محليًا، ولكن أيضًا على الخوادم البعيدة! فرحتي لا تعرف حدودًا - لقد وجدت أداة عادية وتخلصت من ملفات Makefile و docker-compose الخاصة بي، وتم استبدالها بمهام yaml. تم تقليل الكود باستخدام بنيات مثل loop, when، الخ.

Docker لتشغيل مكونات الطرف الثالث مثل قواعد البيانات

لقد تعرفت مؤخرًا على أنفاق ssh. اتضح أنه من السهل جدًا "إعادة توجيه" منفذ الخادم البعيد إلى منفذ محلي. يمكن أن يكون الخادم البعيد إما جهازًا في السحابة أو جهازًا افتراضيًا يعمل في VirtualBox. إذا كنت أنا أو زميلي بحاجة إلى قاعدة بيانات (أو أي مكون آخر تابع لجهة خارجية)، فيمكننا ببساطة تشغيل الخادم بهذا المكون وإيقاف تشغيله عندما لا تكون هناك حاجة إلى الخادم. تعطي إعادة توجيه المنفذ نفس تأثير قاعدة البيانات التي تعمل في حاوية عامل الإرساء.

يقوم هذا الأمر بإعادة توجيه المنفذ المحلي الخاص بي إلى خادم بعيد يقوم بتشغيل postgresql:

ssh -L 9000: المضيف المحلي: 5432 [البريد الإلكتروني محمي]

يؤدي استخدام خادم بعيد إلى حل مشكلة تطوير الفريق. يمكن للعديد من المطورين استخدام مثل هذا الخادم في وقت واحد، ولا يحتاجون إلى أن يكونوا قادرين على تكوين postgresql وفهم Docker والتعقيدات الأخرى. على خادم بعيد، يمكنك تثبيت نفس قاعدة البيانات في Docker نفسها، إذا كان من الصعب تثبيت إصدار معين. كل ما يحتاجه المطورون هو توفير وصول SSH!

قرأت مؤخرًا أن أنفاق SSH هي وظيفة محدودة لشبكة VPN عادية! يمكنك ببساطة تثبيت OpenVPN أو تطبيقات VPN الأخرى، وإعداد البنية التحتية وإعطائها للمطورين لاستخدامها. هذا رائع جدا!

لحسن الحظ، تمنحك AWS وGoogleCloud وغيرها سنة من الاستخدام المجاني، لذا استخدمها! فهي رخيصة الثمن إذا قمت بإيقاف تشغيلها عند عدم استخدامها. لقد تساءلت دائمًا لماذا أحتاج إلى خادم بعيد مثل gcloud، ويبدو أنني وجدته.

باعتبارك جهازًا ظاهريًا محليًا، يمكنك استخدام نفس جهاز Alpine، والذي يتم استخدامه بشكل نشط في حاويات الإرساء. حسنًا، أو بعض التوزيعات الأخرى خفيفة الوزن لجعل الجهاز يعمل بشكل أسرع.

خلاصة القول: يمكنك ويجب عليك تشغيل قواعد البيانات وغيرها من الأشياء الجيدة المتعلقة بالبنية التحتية على خوادم بعيدة أو في Virtualbox. لست بحاجة إلى عامل ميناء لهذه الأغراض.

قليلا عن صور عامل الإرساء والتوزيع

لقد كتبت بالفعل статью حيث أردت أن أنقل أن استخدام صور عامل الإرساء لا يوفر أي ضمان. صور عامل الإرساء مطلوبة فقط لإنشاء حاوية عامل إرساء. إذا كنت تقوم بالترقية إلى صورة عامل إرساء، فأنت تقوم بالترقية لاستخدام حاويات عامل الإرساء وستستخدمها فقط.

هل رأيت في أي مكان يقوم فيه مطورو البرامج بنقل منتجاتهم فقط في صورة عامل إرساء؟
نتيجة معظم المنتجات هي ملفات ثنائية لمنصة معينة، تتم إضافتها ببساطة إلى صورة عامل الإرساء الموروثة من النظام الأساسي المطلوب. هل تساءلت يومًا عن سبب وجود الكثير من الصور المشابهة على dockerhub؟ أدخل nginx على سبيل المثال، سترى 100500 صورة من أشخاص مختلفين. لم يقم هؤلاء الأشخاص بتطوير nginx بحد ذاته، بل قاموا ببساطة بإضافة nginx الرسمي إلى صورة عامل الإرساء الخاصة بهم وأضفوا عليها تكوينات خاصة بهم لتسهيل تشغيل الحاويات.

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

خلاصة القول: لا أحتاج إلى تسجيل عامل إرساء، سأستخدم نوعًا ما من S3 أو مجرد تخزين الملفات مثل google Drive/dropbox

عامل ميناء في CI

جميع الشركات التي عملت بها متشابهة. هم عادة البقالة. أي أن لديهم تطبيقًا واحدًا ومكدسًا تكنولوجيًا واحدًا (حسنًا، ربما لغتين أو ثلاث لغات برمجة).

تستخدم هذه الشركات عامل الإرساء على خوادمها حيث يتم تشغيل عملية CI. سؤال: لماذا تحتاج إلى إنشاء مشاريع في حاوية عامل إرساء على خوادمك؟ لماذا لا نقوم فقط بإعداد بيئة للبناء، على سبيل المثال، كتابة قواعد اللعبة Ansible التي ستقوم بتثبيت الإصدارات الضرورية من العقدة، php، jdk، نسخ مفاتيح ssh، وما إلى ذلك إلى الخادم الذي سيتم فيه البناء؟

الآن أفهم أن هذا بمثابة إطلاق النار على قدمي، لأن عامل الإرساء لا يحقق أي ربح من خلال عزلته. المشاكل التي واجهتها مع CI في عامل الإرساء:

• مرة أخرى، تحتاج إلى صورة عامل إرساء للبناء. تحتاج إلى البحث عن صورة أو كتابة ملف الإرساء الخاص بك.
• 90% أنك بحاجة إلى إعادة توجيه بعض مفاتيح ssh والبيانات السرية التي لا تريد كتابتها إلى صورة عامل الإرساء.
• يتم إنشاء الحاوية وتموت، ويتم فقدان جميع ذاكرات التخزين المؤقت معها. سيعمل البناء التالي على إعادة تنزيل جميع تبعيات المشروع، وهو ما يستغرق وقتًا طويلاً وغير فعال، والوقت هو المال.

لا يبني المطورون مشاريع في حاويات الإرساء (كنت من المعجبين بها ذات يوم، حقًا، أشعر بالأسف على نفسي في الماضي xD). في جافا، من الممكن أن يكون لديك عدة إصدارات وتغييرها باستخدام أمر واحد إلى الإصدار الذي تحتاجه الآن. إنه نفس الشيء في Nodejs، هناك NVM.

إنتاج

أعتقد أن عامل الإرساء أداة قوية ومرنة للغاية، وهذا هو عيبها (يبدو غريبًا، نعم). وبمساعدتها، يمكن للشركات بسهولة التعلق بها واستخدامها عند الحاجة إليها وليس عند الحاجة إليها. يطلق المطورون حاوياتهم، وبعض بيئاتهم، ثم يتدفق كل شيء بسلاسة إلى CI والإنتاج. يقوم فريق DevOps بكتابة نوع من التعليمات البرمجية لتشغيل هذه الحاويات.

استخدم عامل الإرساء فقط على الأحدث في سير العمل الخاص بك، لا تسحبه إلى المشروع في البداية. لن يحل مشاكل عملك. سوف يقوم فقط بنقل المشاكل إلى مستوى آخر وتقديم حلوله الخاصة، وسوف تقوم بعمل مزدوج.

عندما تكون هناك حاجة إلى عامل ميناء: توصلت إلى استنتاج مفاده أن عامل الإرساء جيد جدًا في تحسين عملية معينة، ولكن ليس في بناء الوظائف الأساسية

إذا كنت لا تزال تقرر استخدام عامل الإرساء، فحينئذٍ:

• كن حذرا للغاية
• لا تجبر المطورين على استخدام عامل الإرساء
• توطين استخدامه في مكان واحد، وعدم نشره عبر جميع مستودعات Dockefile وdocker-compose

PS:

• لقد صادفت مؤخرا الرازم ويقولون إنه يعمل بشكل جيد جدًا مع Ansible ويسمح لك بتوحيد عملية بناء الصور (بما في ذلك صورة عامل الإرساء)
• أيضًا حول عامل الإرساء، مقالة مثيرة للاهتمام

شكرا لقرائتكم، أتمنى لكم قرارات شفافة في شؤونكم وأيام عمل مثمرة!

المصدر: www.habr.com