التعامل مع بيئات متعددة لمشاريع متعددة على جهاز واحد؟

دعنا نلقي نظرة على بيئة العمل النموذجية في دار البرمجيات. لديك عدد قليل من العملاء الذين لديهم بيئات مختلفة. البعض يفضل MySQL، والبعض الآخر يفضل Postgres. يحتاج إصدار واحد من تطبيقك إلى جافا 11، وآخر جافا 17. تحتاج الواجهة الأمامية إلى npm 12 أو 16 لأنك تستخدم إصدارات مختلفة من الزاوي. أخيرًا، لديك تلك المصفوفة ثلاثية الأبعاد التي تحتوي على مجموعات من جميع إصدارات قاعدة البيانات الخاصة بك، والواجهة الخلفية، والواجهة الأمامية. يبدو الأمر سيئاً، ولكن في يوم من الأيام يقول رئيسك في العمل

جذور بيئة الأكوان المتعددة

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

• سهلة الاستخدام - أمر واحد لتغيير تكوين أو إصدار,
• مكتبة غنية - يجب أن تدعم تقنيات و"أشياء" متعددة (مكتبات وأطر عمل وتطبيقات),
• قابل للتوسيع - يجب أن توفر إمكانية إضافة ملحقاتك.

سأركز في هذه المقالة على ثلاثة مجالات. الأول هو أدوات جافا و JVM. والثاني هو أدوات الأغراض العامة. والثالث هو كيفية استخدام docker لتحقيق أهدافنا.

​

أنا جافا وأعمل على JVM

عندما تكون مطور جافا أو، بشكل عام، تعمل مع تقنيات JVMفيمكنك استخدام SDKMAN. هذه أداة رائعة جدًا وسهلة الاستخدام تدعم العديد من المكتبات والأطر واللغات.

عملية تركيب SDKMAN بسيط للغاية. تحتاج إلى الجري:

curl -s "https://get.sdkman.io" | bash

ثم

المصدر "$HOME/.sdkman/bin/sdkman-init.sh"

يمكنك الآن إدارة جافا, سكالا و مافن الإصدارات.

إدارة الإصدارات - مثال على ذلك

في هذا المثال، سنقوم بتثبيت وتحديث إصدار بعض الأدوات. هذه مجرد مجموعة فرعية صغيرة من الأدوات المتاحة.

التركيب

لنفترض أن المشروع الاستخدامات جافا 17. ليس لديك أي جافا مثبتة. تريد تثبيته، بالإضافة إلى إضافة أداة Maven Daemon لجعل عمليات الإنشاء أسرع. لذا، تحتاج إلى تثبيت Maven أيضًا. للقيام بذلك، تحتاج إلى تنفيذ ثلاثة أوامر بسيطة:

$ sdk install java 17-open

$ sdk تثبيت مافن 3.8.4

$ sdk تثبيت mvnd 0.7.1

عند الانتهاء من تثبيت كل أداة، سيُطلب منك في نهاية تثبيت كل أداة جعلها افتراضية:

هل تريد أن يتم تعيين جافا 17-مفتوح كافتراضي؟ (نعم/لا):

هذا أمر مهم عند تثبيت إصدار جديد من مكتبة أو لغة ما، لأن SDKMAN! سيقوم بتعيين هذا الإصدار الافتراضي كإصدار عام لجميع المحطات الطرفية للمستخدم الحالي.

التحقق من الإصدارات والتحديث

من وقت لآخر، يحتاج SDKMAN! إلى تحديث الفهارس. أثناء ذلك، قد تصلك رسالة تفيد بوجود بعض الإصدارات الجديدة من الأدوات التي تستخدمها. يمكننا التحقق من الإصدارات المتوفرة من خلال كتابة sdk ls. بالنسبة لـ sdk ls maven:

إصدارات Maven المتوفرة

================================================================================

    3.8.6 3.3.3

    3.8.5 3.3.1

3.8.4 3.2.5

    3.8.3 3.2.3

    3.8.2 3.2.2

    3.8.1 3.2.1

    3.6.3 3.1.1

    3.6.2 3.1.0

    3.6.1 3.0.5

    3.6.0 3.0.4

    3.5.4

    3.5.3

    3.5.2

    3.5.0

    3.3.9



================================================================================

الإصدار المحلي

قيد الاستخدام حالياً

================================================================================

كما نرى أعلاه، لدى Maven إصدار أحدث من الإصدار الذي نستخدمه. نفس الشيء بالنسبة لـ مفند (0.8.2) وجافا (19-مفتوح). لنقم بتحديث كل شيء. للقيام بذلك، نحتاج فقط إلى استدعاء أمر التثبيت ولكن في هذه المرة، لا نستخدم محدد الإصدار:

$ sdk تثبيت maven

$ sdk تثبيت mvnd

$ sdk تثبيت java

ولكن حدث شيء خاطئ. مافن و مفند لها إصدارات صحيحة، ولكن جافا لديه نسخة 17.0.5 تيم. ذلك لأن الإصدار "الأحدث" من الأداة يتحكم فيه البائع وليس SDKMAN المحلي! من هو هذا البائع؟ البائع في SDKMAN! هو شخص يمكنه نشر إصدار. ومع ذلك، لنفترض أننا قمنا أخيرًا بتثبيت 19-مفتوح، وجعلناها افتراضية، ولكن لسبب ما، نحتاج إلى استخدام 17-مفتوح.

الإصدارات المحلية وإدارة الإصدار لكل محطة طرفية

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

في حين أن الخيار الأول مخصص للاستخدام الفردي، فإن الخيار الثاني مصمم للعمل مع الفرق ومشاركة التكوينات بين الفريق الأعضاء.

إيجابيات وسلبيات SDKMAN!

SDKMAN! سهل الاستخدام للغاية ويحتوي على مكتبة غنية بالأدوات والأطر واللغات المدعومة. وهي تعمل على لينكس وماك أو إس وويندوز. من ناحية أخرى، تركز هذه الأداة على JVM وتتطلب موافقة المؤلف على أن يكون بائعًا. بالإضافة إلى ذلك، فإن ميكانيكية .sdkmanrc ضعيف للغاية ويمكن أن يبطئ عملية تغيير الدلائل بشكل كبير.

أود استخدام العديد من اللغات الأخرى

إذا كنت بحاجة إلى استخدام العديد من اللغات والأدوات، فعليك إلقاء نظرة على أسدف. تركز هذه الأداة على الأدوات "عالية المستوى". بينما يمكنك أن تجد في SDKMAN! العديد من الأدوات الخاصة بجافا مثل Bpipe أو Znai، بينما يقدم asdf أدوات أكثر بكثير ولكن ليست محددة. بالطبع، تتداخل بعض هذه الأدوات، على سبيل المثال جافا أو تومكات أو mvnd متوفرة في كليهما.

عندما ترغب في استخدام أسدفيجب أن يكون لديك git و الضفيرة مثبتة. بعد ذلك، أنت فقط

git clone https://github.com/asdf-vm/asdf.git ~/.asdf - الفرع v0.10.2

وإضافة هذه الأسطر في ~/.bashrc file:

. $HOME/.asdf/asdf.sh

. $HOME/.asdf/completions/asdf.bash

يمكنك الآن تثبيت الإضافات والأدوات في إصداراتك المفضلة.

الإدارة القائمة على المكونات الإضافية

على عكس SDKMAN! أسدف يستخدم إضافات لإدارة الأدوات. لذا، قبل أن تتمكن من تثبيت أداة، تحتاج إلى تثبيت مكون إضافي. دعنا نعود إلى مثال المشروع ونحاول تهيئة البيئة باستخدام أسادسفد.

أولاً، نحتاج إلى تثبيت الإضافات:

المكون الإضافي ASD إضافة جافا

المكون الإضافي asdf إضافة مافن

المكون الإضافي asdf إضافة mvnd

ثم يمكننا تثبيت أدواتنا:

Asdf install java openjdk-17

تثبيت asdf مافن 3.8.4

تثبيت asdf mvnd 0.7.1

ومرة أخرى، على عكس SDKMAN! أسدف لا يغير أي شيء في بيئتنا. عندما نحاول استخدام java، نحصل على رسالة خطأ مثل:

لم يتم تعيين أي إصدار للأمر Java

ضع في اعتبارك إضافة أحد الإصدارات التالية في ملف التكوين الخاص بك في ~/.tool-versions

جافا openjdk-17

نحتاج إلى إنشاء ملف إصدارات الأدوات في الدليل الرئيسي لإدارة الإصدارات الافتراضية.

الإصدارات المحلية والعالمية

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

تعارض الإصدار

أسدف لا يدعم فقط لغات البرمجة والأطر والأدوات مثل vim أو kubernetess. بل يدعم قواعد البيانات أيضًا. في مثل هذه الحالة، يمكننا تثبيت إصدارات متعددة من Postgres على سبيل المثال ولكن يمكن تشغيل مثيل واحد فقط. وذلك لأن أسدف تنفيذ الأوامر مباشرة على نظام التشغيل الخاص بك دون أي طبقة فصل. يؤدي ذلك إلى مشاكل مثل "المنفذ قيد الاستخدام بالفعل" والتعارض على الموارد.

الإيجابيات والسلبيات

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

أخيراً وليس آخراً - Docker

عندما أتحدث عن تعارض المنافذ أعلاه، يعرف الكثير منكم الحل.

دوكر يمكن أن تساعدنا في بعض الحالات. أذكرها من باب الواجب، لأن هذه الأداة كبيرة ومعقدة لدرجة أننا لا نستطيع مناقشتها في مقال واحد.

مع Docker، يجب علينا استخدام دوكر-كومبوس أداة تمنحنا إمكانية تنسيق بيئات متعددة الحاويات.

إيجابيات Docker وسلبياته

يساعدنا Docker في إدارة الأدوات التي تحتاج إلى بعض الموارد المحددة، مثل المنافذ أو الملفات. فهو يفصل المثيلات في حاويات ويمنحنا التحكم الكامل فيها. ومع ذلك، فإن Docker أداة تُدخل الكثير من التعقيدات على بيئة عملنا وقد تكون إشكالية في بعض الحالات. إحدى تلك الحالات لاستخدام Docker في اختبار موصوفة في إحدى حالاتنا السابقة المقال.

خلاصة القول

أعلم أنني لم أصف جميع الأدوات التي يمكن استخدامها لإدارة إصدارات الأدوات. هناك الكثير منها، مثل يإنف يمكن أن تحل محل SDKMAN

أو NVM التي يمكننا استخدامها لإدارة npm أو آلة التصوير الإذاعي والتلفزيوني لروبي. لقد ركزت على الأدوات التي "اختبرتها في ساحة المعركة" ويمكنني أن أوصي بها أي شخص.