اذهب إلى المحتوى

رشا سعد

الأعضاء
  • المساهمات

    23
  • تاريخ الانضمام

  • تاريخ آخر زيارة

5 متابعين

المعلومات الشخصية

  • النبذة الشخصية
    مهندس اتصالات من سوريا

آخر الزوار

1605 زيارة للملف الشخصي

إنجازات رشا سعد

عضو نشيط

عضو نشيط (3/3)

10

السمعة بالموقع

  1. قد تحتاج في سكريتات باش للتعامل مع مئات المتغيرات التي يدخلها المستخدم وفي هذه الحالة لن يكون من المناسب أن تنشئ هذه المتغيرات يدويًا، وهنا يأتي دور المصفوفات Arrays الحل المنقذ في مثل هذه الحالات، سنشرح في هذا المقال أساسيات التعامل مع المصفوفات في باش وتعديلها بكفاءة. أنشئ مصفوفتك الأولى في باش لنفترض أنك تحتاج لكتابة سكربت بسيط لتحديث الطابع الزمني timestamp لخمس ملفات مختلفة، والطابع الزمنية هي مجموعة محارف وأرقام تدل على تاريخ ووقت إجراء تعديل معين على الملف. لننشئ السكربت timestamp.sh الخاص بهذه العملية أولًا بطريقة المتغيرات دون استخدام المصفوفات، فسيكون على الشكل التالي: #!/bin/bash file1="f1.txt" file2="f2.txt" file3="f3.txt" file4="f4.txt" file5="f5.txt" touch $file1 touch $file2 touch $file3 touch $file4 touch $file5 لننشئه الآن باستخدام المصفوفات ونلاحظ الفرق، سنخزن في المصفوفة أسماء الملفات الخمسة عوضًا عن تعريف خمس متغيرات تقابل أسماء الملفات الخمسة، وفيما يلي الصيغة العامة لتعريف المصفوفات في باش: array_name=(value1 value2 value3 … ) لنطبق الصيغة على حالتنا، فستكون مصفوفة أسماء الملفات وفق التالي: files=("f1.txt" "f2.txt" "f3.txt" "f4.txt" "f5.txt") السكربت الآن أوضح وأكثر كفاءة وأقرب لمعايير الكود النظيف، فقد استبدلنا خمسة متغيرات بمصفوفة واحدة فقط. الوصول لعناصر مصفوفات باش تبدأ فهرسة مصفوفات باش بالصفر 0 ويستخدم الدليل n-1 للوصول إلى العنصر n من المصفوفة. فإذا رغبنا بإظهار العنصر الثاني في المصفوفة فسنكتب التالي: echo ${files[1]} وللوصول للعنصر الثالث: echo ${files[2]} وهكذا لبقية العناصر. لنجرب أمرًا آخر، ألقِ نظرة على السكربت التالي reverse.sh الذي سيظهر كامل عناصر مصفوفتك بترتيب عكسي من العنصر الأخير إلى الأول: #!/bin/bash files=("f1.txt" "f2.txt" "f3.txt" "f4.txt" "f5.txt") echo ${files[4]} echo ${files[3]} echo ${files[2]} echo ${files[1]} echo ${files[0]} وستحصل بتنفيذه على الخرج التالي: سنتعلم لاحقًا كيف نظهر عناصر المصفوفة باستخدام الحلقات Loops، فتكرار الأمر echo للغرض نفسه عددً كبيرًا من المرات ليس الطريقة الأفضل لإظهار عناصر المصفوفة. يمكننا أيضًا إظهار عناصر المصفوفة دفعة واحدة في سطرٍ واحد كما في الأمر التالي: echo ${files[*]} f1.txt f2.txt f3.txt f4.txt f5.txt ويساعدك الأمر التالي على إظهار عدد عناصر المصفوفة الذي يسمى اصطلاحًا حجم المصفوفة size of array: echo ${#files[@]} 5 وبوسعك تغيير قيمة أي عنصر من عناصر المصفوفة بسهولة، ألقِ نظرة على السطر أدناه إذ نغير فيه قيمة العنصر الأول إلى القيمة "a.txt": files[0]="a.txt" إضافة عناصر جديدة إلى مصفوفة باش لننشئ مثلًا المصفوفة التالية التي تتضمن أسماء أشهر توزيعات لينكس: distros=("Ubuntu" "Red Hat" "Fedora") تحتوي المصفوفة الحالية على ثلاثة عناصر، ويمكنك إضافة عناصر أخرى إلى نهايتها باستخدام المعامل =+، دعنا نضيف مثلًا توزيعة Kali بكتابة: distros+=("Kali") تحتوي المصفوفة الآن أربعة عناصر، وتبين الصورة أدناه السكربت بعد إضافة العنصر الأخير: حذف عناصر من مصفوفة باش لننشئ مصفوفة تتضمن الأعداد من 1 إلى 5: num=(1 2 3 4 5) يمكنك إظهار كافة عناصر المصفوفة كما يلي: echo ${num[*]} 1 2 3 4 5 لنفترض أننا نرغب بحذف العنصر الثالث منها، فسنستخدم الأمر unset وفق التالي: unset num[2] أظهر الآن كافة عناصر المصفوفة كما يلي: echo ${num[*]} 1 2 4 5 ولاحظ حذف العنصر الثالث. يمكنك أيضًا حذف المصفوفة بالطريقة نفسها بكتابة الأمر أدناه: unset num تبين الصورة أدناه تنفيذ سكربت يتضمن كل ما تعلمناه في هذه الفقرة: إنشاء مصفوفة هجينة بأنواع مختلفة من البيانات تتميز باش عن الكثير من لغات البرمجة بقدرتها على إنشاء مصفوفات هجينة hybrid arrays تحتوي أنواعًا مختلفة من البيانات، مثلًا أعداد صحيحة وسلاسل نصية وغيرها كما في سكربت باش التالي باسم user.sh: #!/bin/bash user=("john" 122 "sudo,developers" "bash") echo "User Name: ${user[0]}" echo "User ID: ${user[1]}" echo "User Groups: ${user[2]}" echo "User Shell: ${user[3]}" لاحظ أن مصفوفة المستخدمين السابقة تتضمن أربع عناصر هي: العنصر "john" نوعه سلسلة نصية String العنصر 122 نوعه عدد صحيح Integer العنصر "sudo,developers" نوعه سلسلة نصية String العنصر "bash" نوعه سلسلة نصية String سيكون خرج السكربت على النحو التالي: الخلاصة نصل بذلك لنهاية مقال المصفوفات في لغة باش Bash الذي تعرفنا فيه على المصفوفات وكيفية استخدامها لتنظيم البيانات بكفاءة، وتعلمنا كيفية إنشاء المصفوفات والوصول لعناصرها وعكس ترتيبها وتعديلها وإضافة وحذف العناصر لها، وتعرفنا على طريقة إلى إنشاء مصفوفات هجينة تحتوي على أنواع بيانات مختلفة. ترجمة -وبتصرف- للمقال Using Arrays in Bash. المقال السابق: تمرير الوسطاء إلى سكربت باش Bash طريقة التعامل مع المتغيرات وتمرير الوسطاء لسكربت باش مدخل إلى صدفة باش Bash الحصول على مدخلات من لوحة المفاتيح وإجراء العمليات الحسابية في سكربتات الصدفة الأخطاء الشائعة التي تحدث عند كتابة سكربتات الصدفة
  2. نشرح في هذا المقال نشر تطبيق روبي أون ريلز Ruby on Rails على خادم أوبنتو خطوة بخطوة بدايةً من اختيار خادم الاستضافة وتثبيت الاعتماديات dependencies عليه، ووصولًا إلى إعداد خادم NGINX لاستقبال طلبات التطبيق وبناء قاعدة بيانات التطبيق ونشرها على خادم الاستضافة بمساعدة Capistrano وهي أداة مفتوحة المصدر مخصصة لأتمتة عمليات النشر. أولًا: إعداد خادم الإنتاج سنشرح بداية أبرز معايير اختيار الخادم الافتراضي الخاص VPS الذي سيعمل عليه تطبيق Rails فخيارات الاستضافة كثيرة وعليك أن تعرف الفروقات فيما بينها وتعتمد ما يناسب احتياجات تطبيقك سواء من ناحية الحجم أو المواصفات أو الأمان وغيرها. اختيار مزود الاستضافة هناك العديد من مزودي خدمات الاستضافة ولكل منهم سلبياته وإيجابياته، ويُقصد بمزود خدمة الاستضافة الجهة التي تمتلك خوادم موجودة في مركز بيانات datacenter وتؤجرها للراغبين باستخدامها بمقابل مادي يدفعونه شهريًا. إن استئجار الخوادم الموجودة في مراكز البيانات أمر ضروري عند نشر التطبيقات في بيئة الإنتاج فهو يحميك من المشكلات الطارئة المتعلقة بالتشغيل وأعطال التجهيزات العتادية لأن المزود يؤمن حلولًا لها، كما يوفر لتطبيقك اتصالًا فائق السرعة بالإنترنت وهو أمر مفيد تشغيل التطبيقات المقدمة للعملاء عبر الإنترنت. إذا كنت تحتاج تحكمًا كبيرًا ببيئة تطبيقك فاستبعد مزودي خدمات الاستضافة المُدارة managed hosting providers أي شركات الاستضافة التي تتكفل بإدارة البنية التحتية التي استأجرتها كاملة لأنها لا تمنحك تحكمًا كافيًا ببيئتك وتفتقر عادةً إلى تثبيت آخر التحديثات. كيف أحدد مواصفات الخادم الذي أحتاجه لتطبيق ريلز؟ تحتاج تطبيقات إطار العمل Rails وتطبيقات روبي عمومًا إلى سعة ذاكرة وصول عشوائي RAM كبيرة، فسعة الذاكرة RAM معيار أساسي عليك التركيز عليه عند اختيار الخادم، وتذكر أنك ستحتاج لتثبيت مكونات أخرى على الخادم ستأخذ حصتها من RAM أيضًا، ومنها قاعدة بيانات التطبيق مثل: MongoDB أو PostgreSQL أو Redis التي تعمل في الخلفية. فإذا كنت تنشر تطبيقك الأول فإن خادمًا بذاكرة RAM حجمها 2 جيجابايت مناسب ومقبول التكلفة، وبالرغم من إمكانية البدء بذاكرة 1 جيجابايت لكنها لن تلبي طلبك على الأغلب وسرعان ما ستنفذ عند تجميع الأصول compiling assets وتجهيز الملفات أثناء النشر إلى بيئة الإنتاج. كما ستحتاج لزيادة سعة RAM على الخادم في الحالات التي تستخدم فيها اعتماديات كبيرة مع تطبيقك مثل خدمات البحث أو غيرها حسب ما تتطلبه هذه الاعتماديات إضافةً إلى احتياجات لتطبيقك، فخدمة بحث مثل ElasticSearch على سبيل المثال تحتاج لوحدها إلى 4 جيجابايت، لذا يلجأ البعض لتشغيلها على خادم منفصل عن خادم تطبيقات روبي وريلز لتسهيل توسعة الموارد المحجوزة للخدمتين (أي التطبيق والبحث) بمعزل عن بعضهما. إنشاء الخادم سنعرض هنا كمثال طريقة إنشاء الخادم على منصة الاستضافة DigitalOcean علمًا أن العملية متقاربة في معظم المنصات، افتح المنصة وانتقل إلى صفحة إنشاء قطرة Droplet ثم تابع الخطوات. ملاحظة: Droplet مصطلح خاص بمنصة DigitalOcean يشير إلى وحدة افتراضية تشبه الخادم الافتراضي Virtual Server يمكن للمستخدمين إنشاؤها لتشغيل المواقع والتطبيقات وقواعد بيانات ويمكن تخصيص مواردها المختلفة كالمعالج والذاكرة ومساحة التخزين. الخطوة 1: اختر نظام تشغيل الخادم اخترنا هنا نظام أوبنتو 20.24، وهو نظام تشغيل يتمتع بدعم فني طويل الأمد LTS أي أنه سيتلقى تحديثات أمنية أكثر من المعتاد وعلى مدى سنوات طويلة، وهذا أمر مهم عند نشر التطبيقات في بيئة الإنتاج. توضح الصورة التالية خيار الخادم أوبنتو 20.24 من القائمة المنسدلة. الخطوة 2: حدد حجم الخادم ومواصفاته بعد اختيار نظام التشغيل الخاص بخادم الاستضافة ستظهر أمامك نافذة لتحدد حجم الخادم ومواصفاته، كما توضح الصورة التالية. في حال لم تكن متأكدًا من الحجم المناسب لتطبيقك، يمكنك اختيارحجم RAM لتكون 2 جيجابايت، وتغيير لاحقًا الحجم زيادة أو نقصانًا حسب احتياجات تطبيقك، وهنا تكمن ميزة الخوادم الافتراضية مقارنة بالخوادم الفيزيائية إذ يمكنك تغيير مواصفاتها بسهولة في أي لحظة بزيادة سعة الذاكرة RAM أو إنقاصها وكذلك الأمر بالنسبة لوحدات المعالجة المركزية CPU ووحدات التخزين وغيرها. الخطوة 3: اختر المنطقة الجغرافية الخطوة التالية هي تحديد منطقة الخادم server region أي المكان الجغرافي الذي يتواجد فيه مركز البيانات الذي سيعمل عليه خادمك الافتراضي، اختر المنطقة الأقرب لمكان تواجد مستخدمي تطبيقك أو مكان تواجدك كمدير للتطبيق والخادم. الخطوة 4: ضبط الخيارات الإضافية يوجد عدد من الخيارات الأخرى يمكنك ضبطها حسب احتياجات عملك إذا رغبت بذلك، ومنها: 1. الشبكات الخاصة Private Networking: يفيدك إعداد الشبكات الخاصة إذا كان خادمك يحتاج للتخاطب مع خوادم أخرى، كالحالة التي يكون فيها خادم قاعدة البيانات منفصلًا عن خادم التطبيق. 2. البروتوكول IPv6: بتفعيل هذا الخيار يمكنك إعطاء خادمك عنوان IPv6. 3. المراقبة Monitoring: يعطيك بعض المقاييس التقريبية التي تفيدك في قياس نسب استخدام الخادم. 4. النسخ الاحتياطي Backups: يعني تفعيل هذا الخيار أخذ صورة image أو نسخة كاملة عن خادمك يمكنك استعادته منها عند حدوث أي طارئ، لكن هذه النسخ الكاملة لا تُشَغَّل بفترات متقاربة لذا تُعدّ النسخ الاحتياطية الساعية لقاعدة بيانات التطبيق أو Hourly database backups أفضل منها في معظم الحالات. الخطوة 5: أنشئ خادمك بعد ضبط كافة الخيارات السابقة، اضغط على زر الإنشاء Create وستُنشئ DigitalOcean خادمك الجديد خلال دقيقة تقريبًا. بعدها توجه إلى بريدك الإلكتروني بمجرد إتمام عملية الإنشاء لتستلم كلمة مرور الخادم. يمكنك الآن الاتصال بالخادم من حاسوبك المحلي Local Machine بواسطة عنوان IP الخاص به ومستخدم الجذر root الذي استلمته عبر البريد الإلكتروني، كما في المثال التالي طبعًا مع استبدال 1.2.3.4 بعنوان IP لخادمك: ssh root@1.2.3.4 الخطوة 6: أنشئ مستخدم النشر أنشئ مستخدمًا لعملية النشر باسم deploy مثلًا بأذونات محدودة، واعتمد عليه في تشغيل برمجياتك على الخادم في بيئة الإنتاج بدلًا من تشغيلها من حساب المستخدم الجذر، يقلل ذلك من خطر حصول المخترقين على التحكم الكامل بخادمك في حال نجح باختراقه. إذًا في أثناء دخولك الأول إلى الخادم باستخدام حساب الجذر root أنشئ مستخدمًا جديدًا وامنحه امتيازات sudo كما يلي: root@1.2.3.4 adduser deploy adduser deploy sudo exit أضف بعدها مفتاح SSH إلى الخادم لتسريع الدخول إليه، سنستخدم في ذلك الأداة ssh-copy-id، علمًا أنها لا تتوفر افتراضيًا على أجهزة ماك فإذا كان جهازك المحلي من نوع ماك ثبتها باستخدام homebrew وفق الأمر brew install ssh-copy-id ثم نفذ التالي: ssh-copy-id root@1.2.3.4 ssh-copy-id deploy@1.2.3.4 يمكنك الآن تسجيل الدخول إلى الخادم بحساب المستخدم root أو المستخدم deploy ومن دون الحاجة لكتابة كلمة المرور لأن تفعيل مفتاح SSH يغنيك عنها. لنفتح الآن جلسة اتصال SSH بواسطة مستخدم النشر deploy وهو المستخدم الذي سننفذ بواسطته كافة الخطوات التالية في المقال، علمًا أنك لن تُطالب بإدخال كلمة مروره كما ذكرنا: ssh deploy@1.2.3.4 ثانيًا: تثبيت روبي على الخادم يشبه تثبيت روبي في بيئة الإنتاج تثبيته في بيئة التطوير مع مزيد من التدقيق في تثبيت جميع اعتماديات لينكس الضرورية لضمان تصريف compile روبي بطريقة صحيحة، ويساعدك استخدام مدير إصدارات روبي Ruby version manager على نشر الإصدارات الجديدة بسهولة ومن دون أي تعديل في ملفات الإعداد config files. الخطوة الأولى هي تثبيت الاعتمادات الضرورية لتصريف كل من روبي وإطار العمل ريلز، وأهمها ما يلزم لعمل المكتبة Webpacker مع ريلز لذا سنبدأ بإضافة مستودعات Yarn و Node.js إلى نظامنا لنتمكن من تثبيتها. ثم سنثبت Redis لنستطيع استخدام ActionCable مع مقابس الويب WebSocket في بيئة الإنتاج، كما قد يرغب البعض باستخدام Redis بصفته مخزن تخبئة cashing لخادم الإنتاج. لنطبق ذلك عمليًّا، تأكد أولًا من تسجيل دخولك بالمستخدم deploy ثم اكتب الأوامر التالية: deploy@1.2.3.4 # إضافة مستودع Node.js curl -sL https://deb.nodesource.com/setup_lts.x | sudo -E bash - # إضافة مستودع Yarn curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | sudo apt-key add - echo "deb https://dl.yarnpkg.com/debian/ stable main" | sudo tee /etc/apt/sources.list.d/yarn.list sudo add-apt-repository ppa:chris-lea/redis-server # تحديث الحزم من المستودعين المضافين أعلاه sudo apt-get update # تثبيت الاعتماديات المطلوبة لتصريف روبي من المستودعين المضافين sudo apt-get install git-core curl zlib1g-dev build-essential libssl-dev libreadline-dev libyaml-dev libsqlite3-dev sqlite3 libxml2-dev libxslt1-dev libcurl4-openssl-dev software-properties-common libffi-dev dirmngr gnupg apt-transport-https ca-certificates redis-server redis-tools nodejs yarn يمكننا الآن تثبيت روبي على الخادم بعد إتمام تثبيت الاعتماديات وقد استخدمنا في هذا المقال الإصدار 3.3.1 من روبي لكن تستطيع اختيار الإصدار الذي تفضله. كما سبق وذكرنا سنستخدم مدير الإصدارات rbenv لتثبيت روبي، فهو أسهل في التعامل والترقية وأيضًا يوفر لك عددًا من المكونات الإضافية المفيدة لضبط متغيرات بيئة الإنتاج. نَفِّذْ الأوامر التالية: deploy@1.2.3.4 git clone https://github.com/rbenv/rbenv.git ~/.rbenv echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bashrc echo 'eval "$(rbenv init -)"' >> ~/.bashrc git clone https://github.com/rbenv/ruby-build.git ~/.rbenv/plugins/ruby-build echo 'export PATH="$HOME/.rbenv/plugins/ruby-build/bin:$PATH"' >> ~/.bashrc git clone https://github.com/rbenv/rbenv-vars.git ~/.rbenv/plugins/rbenv-vars exec $SHELL rbenv install 3.3.1 rbenv global 3.3.1 ruby -v # ruby 3.3.1 نثبت الآن مُجَمِّع الوحدات Bundler (وهو أداة تستخدم في مشاريع الويب لتنظيم الوحدات والاعتماديات وتوليد الأصول): deploy@1.2.3.4 # يثبت الأمر التالي الإصدار الأخير من Bundler، والإصدار الأحدث عند إعداد المقال هو 2‪.x gem install bundler # أو نفذ الأمر التالي إذا رغبت بتثبيت إصدار أقدم مثل 1‪.x gem install bundler -v 1.17.3 # يعطيك الأمر التالي رقم إصدار Bundler ويساعدك بالنتيجة على التأكد من صحة تثبيته bundle -v # Bundler version 2.0 إذا حصلت على رسالة خطأ مفادها عدم العثور على Bundler، نفذ الأمر rbenv rehash وكرر المحاولة. ثالثًا: إعداد خادم الويب NGINX والوحدة Passenger يتطلب العمل في بيئة الإنتاج وجود خادم ويب مثل NGINX أمام ريلز لاستقبال طلبات HTTP والتعامل مع شهادات SSL وملفات التطبيق الثابتة static files بطريقة أسرع من روبي، وعلى أرض الواقع من غير المنطقي طرح تطبيقك للمستخدمين من دون خادم ويب. اعتمدنا في مثالنا على NGINX والوحدة Passenger، إذ سيستقبل NGINX طلبات HTTP الواردة إلى خادم التطبيق، ويحولها إلى Passenger الذي سيشغل تطبيقك. اكتب الأوامر التالية لديك لإضافة مستودع Passenger وتثبيته على الخادم: deploy@1.2.3.4 sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 561F9B9CAC40B2F7 sudo sh -c 'echo deb https://oss-binaries.phusionpassenger.com/apt/passenger $(lsb_release -cs) main > /etc/apt/sources.list.d/passenger.list' sudo apt-get update sudo apt-get install -y nginx-extras libnginx-mod-http-passenger if [ ! -f /etc/nginx/modules-enabled/50-mod-http-passenger.conf ]; then sudo ln -s /usr/share/nginx/modules-available/mod-http-passenger.load /etc/nginx/modules-enabled/50-mod-http-passenger.conf ; fi sudo ls /etc/nginx/conf.d/mod-http-passenger.conf ثم افتح ملف إعدادات Passenger باستخدام أي محرر نصوص تفضله مثل nano أو vim كما يلي: deploy@1.2.3.4 # تحرير الملف باستخدام nano sudo nano /etc/nginx/conf.d/mod-http-passenger.conf # تحرير الملف باستخدام vim sudo vim /etc/nginx/conf.d/mod-http-passenger.conf عَدِّل السطر الذي يحتوي القيمة passenger_ruby ضمن الملف ليصبح وفق التالي، وذلك لتوجيه Passenger إلى الإصدار المطلوب من روبي: passenger_ruby /home/deploy/.rbenv/shims/ruby; احفظ التغييرات على الملف وأغلقه. ثم شغل NGINX كما يلي: deploy@1.2.3.4 sudo service nginx start يمكنك التأكد من صحة تشغيل NGINX بفتح عنوان IP العام للخادم في متصفح الإنترنت لديك، وستحصل على رسالة الترحيب التالية "Welcome to NGINX". والآن احذف ملف الإعدادات الافتراضي لخادم NGINX، وأضف ملفًا خاصًا لتطبيقك: deploy@1.2.3.4 sudo rm /etc/nginx/sites-enabled/default # تحرير الملف باستخدام nano sudo nano /etc/nginx/sites-enabled/myapp # تحرير الملف باستخدام VIM sudo vim /etc/nginx/sites-enabled/myapp عدل على الملف ليصبح وفق الآتي، واستبدل myapp باسم تطبيقك، علمًا أننا سنستخدم الملف نفسه لاحقًا لتحديد المجلد deploy_to الخاص بالمكتبة Capistrano: server { listen 80; listen [::]:80; server_name _; root /home/deploy/myapp/current/public; passenger_enabled on; passenger_app_env production; location /cable { passenger_app_group_name myapp_websocket; passenger_force_max_concurrent_requests_per_process 0; } # Allow uploads up to 100MB in size client_max_body_size 100m; location ~ ^/(assets|packs) { expires max; gzip_static on; } } احفظ التغييرات على الملف وأغلقه، ثم أعد تحميل NGINX كما يلي لتطبيق التغييرات: deploy@1.2.3.4 sudo service nginx reload رابعًا: إنشاء قاعدة البيانات سنعرض طريقتين لإنشاء قاعدة بيانات التطبيق، الأولى باستخدام PostgreSQL وهي الخيار الأفضل في بيئة الإنتاج، والثانية باستخدام MySQL، اتبع الأسلوب الذي يناسبك. إنشاء قاعدة بيانات PostgreSQL ثبت في البداية خادم Postgres مع المكتبة libpq التي تسمح بتصريف gem pg وهي مكتبة روبي المخصصة للتعامل مع PostgreSQL. للمزيد يمكنك مشاهدة الفيديو التالي: سينشأ مع التثبيت مستخدم لينكس يدعى postgres يملك الصلاحيات الكاملة على قاعدة البيانات، يمكنك استخدامه لإنشاء مستخدم قاعدة بيانات خاص بتطبيقك، اخترنا له الاسم deploy في مثالنا. ثم أنشئ قاعدة بيانات التطبيق، تدعى في مثالنا myapp، وتأكد أن المستخدم deploy هو مالك قاعدة البيانات، وفق الأوامر التالية: deploy@1.2.3.4 sudo apt-get install postgresql postgresql-contrib libpq-dev sudo su - postgres createuser --pwprompt deploy createdb -O deploy myapp exit والآن يمكنك الاتصال بقاعدة البيانات الجديدة وفق التالي: psql -U deploy -W -h 127.0.0.1 -d myapp استخدم 127.0.0.1 بدلًا من localhost عند الاتصال بقاعدة البيانات. إنشاء قاعدة بيانات MySQL ستحتاج لتثبيت نسختي الخادم server والعميل client من MySQL لإنشاء قاعدة بيانات التطبيق وتصريف روبي gem عبر الواحهة mysql2 (يساعدك الاطلاع على المقال كيفية تثبيت MySQL على أوبونتو 18.04). وبعد التثبيت اكتب الأوامر التالية: deploy@1.2.3.4 sudo apt-get install mysql-server mysql-client libmysqlclient-dev sudo mysql_secure_installation # هذا الأمر مخصص لفتح واجهة سطر الأوامر لنظام MySQL لننشئ المستخدم وقاعدة البيانات mysql -u root -p بعد تنفيذ الأوامر السابقة ستفتح واجهة سطر الأوامر لنظام MySQL وبواسطتها يمكنك إنشاء قاعدة بيانات تطبيقك ومستخدم قاعدة بيانات مخصص لإدارتها ويملك الصلاحيات الكاملة عليها، ويستحسن أن تلتزم بإنشاء مستخدم قاعدة بيانات خاص للتطبيق فهذا الإجراء يُعدّ أكثر آمانًا. عندما تقرأ الأوامر الموجودة أسفل الفقرة سيتبادر لذهنك أننا ننشئ مستخدمين اثنين على قاعدة البيانات لكن ذلك يرجع لاختلاف طريقة تعامل MySQL مع الاتصالات المحلية localhost والبعيدة التي تجري عبر الشبكة أي عبر عنوان IP، وبالأوامر التي كتبناها هنا قد سمحنا بنوعي الاتصال. وانتبه قبل التنفيذ لضرورة استبدال الأسماء المذكورة بما يناسب تطبيقك كما يلي: استبدل myapp باسم قاعدة بياناتك، وهي تماثل اسم التطبيق عادةً. استبدل omeFancyPassword123 بكلمة مرورك. استبدل deploy باسم مستخدم قاعدة البيانات الذي تختاره. deploy@1.2.3.4 CREATE DATABASE IF NOT EXISTS myapp; CREATE USER IF NOT EXISTS 'deploy'@'localhost' IDENTIFIED BY '$omeFancyPassword123'; CREATE USER IF NOT EXISTS 'deploy'@'%' IDENTIFIED BY '$omeFancyPassword123'; GRANT ALL PRIVILEGES ON myapp.* TO 'deploy'@'localhost'; GRANT ALL PRIVILEGES ON myapp.* TO 'deploy'@'%'; FLUSH PRIVILEGES; \q خامسًا: النشر باستخدام Capistrano بعد إتمام تهيئة الخادم وأدواته حان الوقت لتحميل الشيفرة البرمجية الخاصة بالتطبيق إلى مرحلة الإنتاج. وهنا يأتي دور المكتبة Capistrano التي تساعدك على إنشاء نسخ من مستودع تطبيقك في مرحلة الإنتاج، وعلى إنشاء إصداراته الجديدة لاحقًا بكل سهولة. إعداد Capistrano ثَبِّت Capistrano ضمن تطبيق ريلز على حاسوبك المحلي (أي حيث طورت التطبيق وحيث توجد شيفرته البرمجية). ثم أضف جواهر روبي أو gems التالية إلى الملف Gemfile كما يلي: gem 'capistrano', '~> 3.11' gem 'capistrano-rails', '~> 1.4' gem 'capistrano-passenger', '~> 0.2.0' gem 'capistrano-rbenv', '~> 2.1', '>= 2.1.4' ثم نَفِّذ الأوامر التالية من حاسوبك المحلي بهدف تثبيت gems السابقة وتثبيت ملفات الإعدادات الخاصة بالمكتبة Capistrano: bundle cap install STAGES=production وستنشئ بعدها الملفات التالية: Capfile. config/deploy.rb. config/deploy/production.rb. افتح في البداية الملف Capfile وأضِف إليه الأسطر التالية: require 'capistrano/rails' require 'capistrano/passenger' require 'capistrano/rbenv' set :rbenv_type, :user set :rbenv_ruby, '3.3.1' ثم افتح الملف config/deploy.rb لتُعرِّف تطبيقك ضمنه، وتحصل على التفاصيل الخاصة بمستودع التطبيق: set :application, "myapp" set :repo_url, "git@github.com:username/myapp.git" # Deploy to the user's home directory set :deploy_to, "/home/deploy/#{fetch :application}" append :linked_dirs, 'log', 'tmp/pids', 'tmp/cache', 'tmp/sockets', 'vendor/bundle', '.bundle', 'public/system', 'public/uploads' # Only keep the last 5 releases to save disk space set :keep_releases, 5 # Optionally, you can symlink your database.yml and/or secrets.yml file from the shared directory during deploy # This is useful if you don't want to use ENV variables # append :linked_files, 'config/database.yml', 'config/secrets.yml' وأخيرًا عَدِّل على الملف config/deploy/production.rb لإضافة عنوان IP العام للخادم إلى عمليات النشر، وذلك وفق التالي، ولا تنسَ استبدال 1.2.3.4 بعنوان خادمك: server '1.2.3.4', user: 'deploy', roles: %w{app db web} يتبقى لنا الخطوة الأخيرة قبل النشر وهي إضافة متغيرات البيئة إلى خادم الإنتاج، لذا افتح جلسة اتصال SSH مع الخادم من حاسوبك المحلي: ssh deploy@1.2.3.4 ونفذ التالي: mkdir /home/deploy/myapp nano /home/deploy/myapp/.rbenv-vars ثم أضف متغيرات البيئة المناسبة لحالتك من بين التالي إلى هذا الملف: # For Postgres DATABASE_URL=postgresql://deploy:PASSWORD@127.0.0.1/myapp # For MySQL DATABASE_URL=mysql2://deploy:$omeFancyPassword123@localhost/myapp RAILS_MASTER_KEY=ohai SECRET_KEY_BASE=1234567890 STRIPE_PUBLIC_KEY=x STRIPE_PRIVATE_KEY=y # etc... احفظ التغييرات على الملف، وستُحَمَّل متغيرات البيئة المذكورة هنا تلقائيًا إلى الخادم في كل مرة تُشَغِّل فيها أوامر روبي داخل مجلد التطبيق على الخادم. يفيدك هذا الأسلوب في تخصيص متغيرات بيئة مستقلة لكل تطبيق تنشره على الخادم. يمكنك الآن نشر التطبيق على خادم الإنتاج، بتنفيذ الأمر التالي من حاسوبك المحلي: cap production deploy اكتب عنوان IP الخادم في متصفح الإنترنت وإذا كانت كافة إعداداتك صحيحة فستظهر أمامك واجهة تطبيق ريلز Rails الذي نشرته. وإذا لم تحصل على واجهة ريلز، فيمكنك تتبع الخطأ بمراجعة ملفات تسجيل الأحداث logs من جلسة اتصال SSH مع الخادم كما يلي: deploy@1.2.3.4 # لعرض ملفات تسجيل الأحداث الخاصة بريلز less /home/deploy/myapp/current/log/production.log # لعرض ملفات تسجيل الأحداث الخاصة بخادم NGINX و Passenger sudo less /var/log/nginx/error.log تنجم أغلب الأخطاء عن وجود خلل في أحد متغيرات البيئة أو ملفات الإعدادات التي جهزناها لمرحلة الإنتاج، وبمجرد وصولك للخطأ وتصحيحه يمكنك إعادة تشغيل تطبيقك أو إعادة نشره ثم التحقق مجددًا من المتصفح لمعرفة النتيجة. سادسًا: توصيات إضافية إلى جانب جودة التطبيق الذي طورته بواسطة روبي أو غيرها وصحة نشره على الخادم، فإن متطلبات العمل في البيئة الحقيقية تفرض عليك الاهتمام بجوانب أخرى مثل: تركيب شهادة SSL على الخادم من خدمة مجانية مثل LetsEncrypt أو غيرها لحماية البيانات المتبادلة مع التطبيق، يساعدك في ذلك مقال تنصيب شهادة SSL مجانية عبر خدمة Let's encrypt على خادوم لينكس على أكاديمية حسوب. تفعيل النسخ الاحتياطي الساعي Hourly Backups أو النسخ الاحتياطي الدوري عمومًا الذي ينسخ بياناتك إلى وحدة تخزين خارجية مثل S3، فهو يخفف من مخاطر ضياع البيانات ويساعدك على استعادتها في حال تعرض خادمك أو تطبيقك لأي عطل أو حادث طارئ. اتباع خطة لتدوير ملفات تسجيل الأحداث logs حتى لا تملأ مساحة التخزين على الخادم دون أن تنتبه لها. اتخاذ التدابير الأمنية الضرورية لحماية الخادم من الهجمات السيبرانية، يفيدك في ذلك مقال 7 تدابير أمنية لحماية خواديمك والمقالات الأخرى الموجودة في قسم حماية على أكاديمية حسوب. ترجمة -وبتصرف- لمقال Deploy Ruby On Rails:Ubuntu 24.04 Noble Numbat in 2024 من موقع Go Rails. اقرأ أيضًا كيفية نشر تطبيق Express وتوسيعه باستخدام إضافة MemCachier من منصة تطبيقات DigitalOcean نشر تطبيقات Flask باستخدام PythonAnywhere نشر التطبيقات وتوزيعها وفق نهج التسليم المستمر فيديو: نشر تطبيق React.js ذو واجهات خلفية Node.js على منصة Heroku
  3. يعرض المقال الثالث من سلسلة باش كيفية تمرير الوسطاء arguments إلى سكربتات الصدفة باش، وإضافةً للوسطاء سنتعرف على بعض المتغيرات الخاصة في صدفة باش. تعلمنا في المقال السابق كيف نستخدم المتغيرات لكتابة سكربتات باش عامة وديناميكية تتجاوب مع أنواع مختلفة من البيانات ومدخلات المستخدم، وسنتعلم هنا تمرير الوسطاء إلى سكربتات باش ضمن سطر الأوامر. تمرير وسيط إلى سكربت باش يحتسب السكربت count_lines.sh التالي عدد الأسطر الموجودة في أي ملف تزوده باسمه: #!/bin/bash echo -n "Please enter a filename: " read filename nlines=$(wc -l < $filename) echo "There are $nlines lines in $filename" يمكنك الرجوع للمقال الأول لتعرف كيف تُنشئ سكربت باش وتحوله لملف تنفيذي. لنفترض أننا نود حساب عدد الأسطر الموجودة في الملف etc/passwd/ فستكون نتيجة تنفيذ السكربت كما في الصورة التالية: يمكننا تسهيل العملية بتمرير اسم الملف للسكربت بصفته وسيط سطر أوامر يكتب معه في نافذة سطر الأوامر عند التشغيل كما يلي: ./count_lines.sh /etc/passwd يتطلب ذلك تعديلًا على السكربت نستخدم فيه المتغير 1$ الذي يشير إلى الوسيط الأول الذي سيتلقاه السكربت من سطر الأوامر (والذي يسمى المُحَدِّد الموضعي). لنستبدل إذًا المتغير filename الخاص باسم الملف بالمتغير 1$ في كامل السكربت count_lines.sh السابق، ليصبح كما يلي: #!/bin/bash nlines=$(wc -l < $1) echo "There are $nlines lines in $1" استغنينا بهذه الطريقة عن الأمر read والأمر echo الأول، فأصبح السكربت أقصر. يمكنك الآن تجربة السكربت على ملفات أخرى كما في المثال التالي: ./count_lines.sh /etc/group There are 73 lines in /etc/group تمرير عدة وسطاء إلى سكربت باش يمكنك تمرير أكثر من وسيط لسكربتات باش، وفق الصيغة التالية: script.sh arg1 arg2 arg3 … يشير المتغير 2$ للوسيط الثاني، والمتغير 3$ للوسيط الثالث وهكذا. أما المتغير 0$ فيشير إلى اسم السكربت، وهو أحد المتغيرات الخاصة في صدفة باش. لنُعدّل الآن السكربت السابق كما يلي ليقبل أكثر من ملف، ويحسب عدد الأسطر في كل واحد منها: #!/bin/bash n1=$(wc -l < $1) n2=$(wc -l < $2) n3=$(wc -l < $3) echo "There are $n1 lines in $1" echo "There are $n2 lines in $2" echo "There are $n3 lines in $3" يمكنك الآن تشغيل السكربت، وتمرير ثلاثة ملفات نصية له، لتحصل على أعداد الأسطر فيها كما يلي: إذا فقد أعطانا السكربت عدد الأسطر في كل ملف من الملفات الثلاثة، وبالترتيب نفسه المكتوبة به، فترتيب تمرير الوسطاء للسكربت مهم لضمان دقة التنفيذ. أبدِع في استخدام وسطاء باش يساعدك استخدام وسطاء باش على تبسيط أوامر لينكس الطويلة أو المعقدة التي تحتاج لضبط الكثير من الخيارات، إذ يمكنك تحويلها لسكربتات باش بسيطة، وتشغيلها بعد تزويدها بالوسطاء. ألقِ نظرة على سكربت باش find.sh التالي لتوضيح الأمر: #!/bin/bash find / -iname $1 2> /dev/null يساعدك هذا السكربت في العثور على الملفات، وستجد استخدامه أسهل من كتابة أمر البحث الطويل في كل مرة تحتاج فيها لإيجاد ملف، فقط مرر اسم الملف الذي تبحث عنه بصفته وسيطًا للسكربت وسيعرض لك موقعه. وبالطريقة نفسها يمكنك تحويل أي أمر طويل ومعقد من أوامر لينكس إلى سكربت باش سهل الاستخدام. أما التعليمة: ‏‎2> /dev/null الواردة في السكربت فتحجب رسائل الخطأ مثل (لا يمكن الوصول للملف أو غيرها) من الظهور على الشاشة. أشهر المتغيرات الخاصة في باش توفر لك صدفة باش مجموعة من المتغيرات الخاصة المُضمنة فيها، وتُعدّ مفيدة جدًا في أي سكربت. يتضمن الجدول أشهرها: المتغير الخاص الوصف $0 اسم السكربت $1, $2…$n وسطاء سطر الأوامر $$ مُعرّف العملية process id للصدفة shell الحالية #$ العدد الكلي للوسطاء المُمَرَّة إلى السكربت @$ قيم جميع الوسطاء المُمَرَّة إلى السكربت ?$ حالة الخروج لآخر أمر مُنَفذ !$ مُعرّف العملية لآخر أمر مُنَفذ يعطيك السكربت Variables.sh التالي مثالًا عمليًّا بسيطًا عن المتغيرات الخاصة: #!/bin/bash echo "Name of the script: $0" echo "Total number of arguments: $#" echo "Values of all the arguments: $@" مرر عدد من الوسطاء التجريبية، ثم شغل السكربت، ولاحظ النتائج: وفي الختام ننصحك بالتدرب أكثر على استخدام وسطاء باش حتى تتقن استخدامها بشكل جيد، وندعوك لمتابعةبقية المقالات في هذه السلسلة للتعرف أكثر على لغة باش واحترافها. ترجمة -وبتصرف- للمقال Passing Arguments to Bash Scripts لصاحبه Kabary. اقرأ أيضًا المقال السابق: المتغيرات في سكربتات الصدفة باش مفهوم واصفات الملفات File Descriptors وارتباطها بعملية التجريد في أنظمة التشغيل أنشئ برنامجك النصي الأول على صدفة باش Bash احترف الأمر ls في لينكس
  4. المتغيرات Variables جزءٌ أساسي من أي مشروع برمجي، لا بدّ أنك تعاملت معها من قبل، وإن كنت لا تملك معرفةً مسبقة بها، فيمكنك تشبيهها بحاويات التخزين فهي تُخَزِّن أجزاءً من المعلومات قد تتغير قيمها مع الزمن. ويتناول مقالنا الثاني من سلسلة باش Bash للمبتدئين طريقة استخدام المتغيرات في كتابة سكربتات الصدفة باش bash shell scripts، تابع معنا أمثلة المقال لتتعلم استعمال المتغيرات لكتابة سكربتات باش. استخدام المتغيرات في سكربتات الصدفة باش تعلمنا في المقال السابق كيفية إنشاء سكربت باش بسيط يعرض عبارة " hello world"، اسمه "hello.sh" ويتضمن المحتوى التالي: #! /bin/bash echo 'Hello, World!' لنحاول تطوير هذا السكربت البسيط ليتظهر اسم المستخدم في عبارة الترحيب، سنستخدم لذلك المتغيرات والأمر read القادر على استلام المدخلات من المستخدمين، يمكنك مطالعة هذا المقال للحصول على معلومات أكثر عن read، والآن افتح الملف "hello.sh" وعدّل محتواه ليصبح كما يلي: #! /bin/bash echo "What's your name, stranger?" read name echo "Hello, $name" إذا شغلت السكربت سيُطالبك بإدخال اسمك ثم سيرحب بك بالاسم الذي زودته به، وفق التالي: abhishek@handbook:~/scripts$ ./hello.sh What's your name, stranger? Elliot Hello, Elliot إذًا سيسألك البرنامج عن اسمك، ثم تزوده به، وبعدها سيظهر اسمك في عبارة الترحيب. وهذا ملخص لما نفذناه حتى الآن: الشرح التفصيلي للسكربت السابق لنراجع نص السكربت سطرًا سطرًا مع توضيح دلالة كل سطر. يتضمن السطر الأول رمز التوجيه shebang ليوضح لمُفسر الأوامر أننا سنستخدم الصدفة باش لتنفيذ السكربت. #!/bin/bash وفي السطر الثاني أظهرنا العبارة التالية التي تطلب من المستخدم إدخال اسمه: echo "What's your name, stranger?" ونفذنا ذلك باستخدام أمر بسيط هو echo الذي يعرض العبارة المكتوبة بعده على شاشة الطرفية. ثم السطر الثالث، وهو الجزء الأهم الذي أحدث تطورًا في السكربت: read name استخدمنا فيه الأمر read لنقل التحكم من السكربت إلى المستخدم ليستطيع إدخال اسمه وتخزينه في متغير يدعى name. وفي السطر الأخير يستخدم السكربت المتغير name ويرحب بالمستخدم باسمه: echo “Hello, $name” تُكتب إشارة "$" قبل اسم المتغير للحصول على القيمة المخزنة فيه، أو لو كتبت name فقط في السطر السابق بدلًا من name$ فتظهر العبارة "Hello, name" عوضًا عن الترحيب بالمستخدم باسمه (الذي هو قيمة المتغير). ملاحظة: تعرف إشارة "$" في سكربتات باش بأنها معامل تحصيل dereference operator لتحصيل قيمة معينة من موقعها في الذاكرة. إنشاء متغيرات بأنواع بيانات مختلفة يمكن إنشاءمتغيرات بأنواع بيانات مختلفة مثل الأعداد والمحارف والسلاسل النصية، وتستخدم إشارة المساواة "=" لإنشاء المتغيرات وإسناد القيم الافتراضية لها، ففي السطر التالي مثلًا أنشأنا متغيرًا يدعى age وأسندنا له القيمة 27. age=27 يمكنك تغيير قيمة المتغير لاحقًا بقدر ما تريد، فالسطر التالي مثلًا يغيرها من 27 إلى 3: age=3 تحمل المتغيرات أنواعًا مختلفة من البيانات، مثل الأعداد الصحيحة، والمحارف، والسلاسل النصية، وباش لا تحدد الأنواع بشكل صارم كما في بعض لغات البرمجة الأخرى، فلا حاجة لتحديد نوع المتغير مسبقًا ويمكنك وضع أي نوع ضمن المتغير. ألقِ نظرة على الأمثلة التالية: letter=’c’ color=’blue’ year=2020 المتغيرات الثابتة في سكربت باش المتغير الثابت constant variable هو متغير ذو قيمة ثابتة لا تتغير أبدًا، تُنشِئه بواسطة الأمر readonly كما يلي: readonly PI=3.14159 أنشأ الأمر السابق متغيرًا ثابتًا يدعى PI يحمل القيمة 3.14159، وإذا حاولت تغيير قيمته فلن تتمكن من ذلك وستحصل على الخطأ التالي: bash: PI: readonly variable إذًا المتغيرات الثابتة هي متغيرات للقراءة فقط، يمكنك قراءة قيمتها فقط، ولا تستطيع تغييرها أبدًا بعد إنشائها. تعويض الأوامر Command substitutions تعويض الأوامر Command substitutions هو تخزين نتيجة أمر في متغير، ويُعدّ من أبرز مميزات البرمجة النصية باستخدام صدفة باش. والأمر date الخاص بإظهار التاريخ الحالي من أشهر الأمثلة على تعويض الأوامر، ألقِ نظرة على السطر التالي: TODAY=$(date) حسب السطر السابق يُخَزَّن خرج الأمر date في المتغير TODAY، ولاحظ أن الأمر المستخدم لتعويض الأوامر يُكتب بين قوسين هلاليين ويُسبَق بإشارة الدولار "$" على يساره. تبين الصورة أدناه كيف أخذ المتغير TODAY قيمة خرج الأمر date: يمكنك أيضًا كتابة تعويض الأوامر بوضع الأمر بين علامتي اقتباس مائلة للخلف back quotes وفق التالي، بدلًا من وضعه بين قوسين مع إشارة الدولار: TODAY=`date` لكننا ننصحك بعدم استخدام هذه الطريقة في كتابة تعويض الأوامر لأنها قديمة ولم تعد مستخدمة، احرص دائمًا على استخدام الطريقة الحديثة ذات الصيغة التالية: variable=$(command) مثال عملي على تعويض الأوامر في آخر تحديث أجريناه على السكربت "hello.sh" كنا نطلب من المستخدم إدخال اسمه ليستخدمه البرنامج في رسالة الترحيب. أما الآن -وبالاعتماد على تعويض الأوامر- لن نسأل المستخدم عن اسمه بل سنستعين بأمر خاص يدعى whoami يعطينا اسم المستخدم الحالي. عدّل محتوى الملف "hello.sh" ليصبح كما يلي: #! /bin/bash echo "Hello, $(whoami)" لاحظ الاختصار الذي طرأ على حجم السكربت فقد أصبح يقتصر على سطرين فقط، شغّل السكربت الآن: ./hello.sh سيؤكد لك الخرج نجاح العملية، فسيظهر اسم المستخدم الحالي في رسالة الترحيب، وتلخص هذه الصورة ما طبقناه هنا: وصلنا إلى نهاية المقال نأمل أنه كان مفيدًا ووضح لك طريقة استخدام المتغيرات في سكربتات باش، حاول تطبيق أمثلة أخرى لتزيد مهاراتك في العمل مع المتغيرات، وتابع مقالنا التالي لتتعرف على كيفية تمرير الوسطاء لسكربت باش. ترجمة -وبتصرف- للمقال Understanding Variables in Bash Shell Scripting. اقرأ أيضًا المقال السابق: أنشئ برنامجك النصي الأول على صدفة باش Bash مدخل إلى صدفة باش Bash دليل ميَسَّر لكتابة سكربتات Shell مدخل إلى كتابة سكربتات الصدفة الحصول على مدخلات من لوحة المفاتيح وإجراء العمليات الحسابية في سكربتات الصدفة (Shell Scripts)
  5. تعلمنا في المقالات السابقة من سلسلة Pygame التي تشرح طريقة بناء لعبة من الصفر بلغة بايثون3 ووحدة الألعاب Pygame، وكيف نضيف إليها الشخصيات سواء شخصيات الأبطال أو أعداء، ونحركهم بالقفز والركض ورمي المقذوفات مثل الكرات النارية وغيرها، وسنعرض في هذا المقال المتمم للسلسلة طريقة إضافة مؤثرات صوتية تناسب أحداث اللعبة تُشَغَّل في أثناء القتال أو القفز أو جمع الجوائز أو غير ذلك، لكن دعنا في البداية نذكرك بمقالات السلسلة بالترتيب: بناء لعبة نرد بسيطة بلغة بايثون. بناء لعبة رسومية باستخدام بايثون ووحدة الألعاب PyGame. إضافة لاعب إلى اللعبة المطورة باستخدام بايثون و Pygame. تحريك شخصية اللعبة باستخدام PyGame. إضافة شخصية العدو للعبة. إضافة المنصات إلى لعبة بايثون باستخدام الوحدة Pygame محاكاة أثر الجاذبية في لعبة بايثون. إضافة خاصية القفز والركض إلى لعبة بايثون. إضافة الجوائز إلى اللعبة المطورة بلغة بايثون تسجيل نتائج اللعبة المطورة بلغة بايثون وعرضها على الشاشة. إضافة آليات القذف إلى اللعبة المطورة بلغة بايثون. إضافة آليات القذف إلى اللعبة المطورة بلغة بايثون. إضافة المؤثرات الصوتية إلى اللعبة المطورة بلغة بايثون ومكتبة Pygame. توفر المكتبة Pygame طريقةً سهلة لإضافة المؤثرات الصوتية إلى ألعاب الفيديو المطورة بلغة بايثون، وذلك اعتمادًا على وحدة خاصة تسمى mixer module تتيح لك تشغيل صوت واحد أو أكثر حسب طلبك، فيمكنك مثلًا تشغيل موسيقى خلفية background music بالتزامن مع صوت بطل اللعبة وهو يقاتل أو يقفز أو يجمع الجوائز. لن يتضمن هذا المقال تعديلات مباشرةً على الشيفرة البرمجية للعبة التي عملنا عليها خلال السلسلة (كما في فعلنا المقالات السابقة) لكننا سنقدم لك أمثلة للتعليمات المتعلقة بالوحدة mixer وسنشرح لك بالتفصيل كيفية الاستفادة منها ودمجها في لعبتك بخطوات متسلسلة. تشغيل الوحدة mixer اكتب في البداية التعليمة الخاصة بتشغيل الوحدة mixer في قسم الإعدادات setup ضمن شيفرة اللعبة، طبعًا يمكنك جمعها مع في كتلة واحدة مع التعليمات المشابهة لها مثل تعليمة تشغيل pygame وتشغيل pygame.font لتصبح كما يلي: pygame.init() pygame.font.init() pygame.mixer.init() # أضف هذا السطر ملاحظة: يمكنك الحصول على شيفرة اللعبة بشكلها النهائي من المقال الثاني عشر من السلسلة إضافة آليات القذف إلى اللعبة المطورة بلغة بايثون. الحصول على الملفات الصوتية اللعبة خطوتك التالية هي تحديد الأصوات التي تود استخدامها في اللعبة وتوفيرها محليًّا على حاسوبك، فاستخدام الأصوات في اللعبة المطورة بلغة بايثون يتطلب وجودها كملفات على الحاسوب المحلي تمامًا مثل الخطوط والرسوم. إذًا بعد تأمين ملفات الصوت عليك وضعها في حزمة واحدة مع ملفات اللعبة حتى يحصل عليها كل من يلعب بلعبتك. لنبدأ بإنشاء مجلد خاص لحفظ ملفات الصوت ضمن المجلد الرئيسي للعبة إلى جانب مجلدي الصور والخطوط، ولنسميه sound كما يلي: s = 'sound' يتوفر العديد من الملفات الصوتية على الإنترنت لكن قد لا يسمح لك باستخدامها جميعًا بسبب حقوق الملكية، لذا ابحث عن الملفات الصوتية مفتوحة المصدر أو المنشورة تحت رخصة المشاع الإبداعي Creative Commons واستخدمها في لعبتك، وهذه بعض المصادر التي تتيح لك تحميل ملفات الصوت مجانًا وبطريقة قانونية: يحتوي Freesound على ملفات لمختلف أنواع المؤثرات الصوتية. يستضيف موقع Incompetech مجموعة واسعة من الموسيقى المناسبة لتكون موسيقى خلفية للألعاب. يوفر Open Game Art ملفاتٍ متنوعة من المؤثرات الصوتية والموسيقى. لكن احرص دائمًا على قراءة شروط الاستخدام قبل تحميل أي ملف صوتي مجاني واعتماده في لعبتك، إذ يشترط بعض المؤلفون الموسيقيون ومصممو الصوت أن تُنسب الملفات الصوتية إليهم ويذكر أنهم أصحاب الفضل في إنشائها عندما يستخدمها الآخرون مجانًا، وبكل الأحوال يُعدّ ذكر اسم صاحب الملف الصوتي تصرفًا جيدًا وأخلاقيًا لمطوري الألعاب، فهم في نهاية الأمر قد تعبوا على ملفاتهم الصوتية بالطريقة نفسها التي تعبت فيها لتطوير لعبة أو تطبيقك. فأين يُذكر اسم صاحب الملف الصوتي إذًا؟ يُنشأ عادةً ملفٌ نصيٌّ خاص في مجلد اللعبة الرئيسي يسمى CREDIT وتُكتب فيه الملفات الصوتية المستخدمة في اللعبة مع مصادرها. قد يرغب البعض بتأليف مؤثراتهم الصوتية الخاصة، فإذا كنت منهم يمكنك استخدام أدوات Linux Multimedia Studio، أو LMMS ، فهو برنامج مجاني ومفتوح المصدر يساعد على لإنتاج وتحرير الموسيقى وتوليد التأثيرات الصوتية، كما أنه سهل الاستخدام ومتوافق مع معظم المنصات الأساسية، ويوفر لك العديد من الأصوات لتبدأ منها، فضلًا عن أنه يسمح لك بتصدير الملفات الصوتية بتنسيق Ogg Vorbis مفتوح المصدر الذي يسمى اختصارًا OGG. يمكنك معرفة المزيد عن المشاريع والبرمجيات مفتوحة المصدر بمشاهدة هذا الفيديو: إضافة الملفات الصوتية إلى Pygame الآن بعد أن وجدت المؤثرات الصوتية المناسبة للعبتك ستُحَمِّلها غالبًا بصيغة ملفات مضغوطة tar أو zip لذا أول ما سنفعله هو فك ضغطها، ونقل الملفات الصوتية الناتجة إلى المجلد sound الموجود ضمن مجلد اللعبة الرئيسي. انظر بعدها إلى أسماء الملفات الصوتية فإذا وجدتها معقدة أو تتضمن العديد من المحارف الخاصة، أَعِدّْ تسميتها واختر لها أسماءً بسيطة يمكنك استخدامها بسهولة ضمن الشيفرة البرمجية. تعتمد معظم ألعاب الفيديو ملفاتٍ صوتية بصيغة OGG لأنها تجمع بين الجودة العالية وصِغَر حجم الملف، فإذا كانت الملفات الصوتية التي اخترتها للعبتك بصيغة MP3 أو WAVE أو FLAC أو غيرها، احرص على تحويلها إلى صيغة OGG باستعمال أدوات مثل fre:ac و Miro لتضمن توافقيةً أعلى وحجمًا أصغر عند تحميل اللعبة. لنفترض على سبيل المثال أن الملف الصوتي الذي حَمَّلته يدعى ouch.ogg. سننشئ متغيرًا خاصًا لتمثيله في قسم الإعدادات setup ضمن شيفرة اللعبة، ليكن مثلًا المتغير ouch كما يلي: ouch = pygame.mixer.Sound(os.path.join(s, 'ouch.ogg')) تشغيل الأصوات ضمن اللعبة الآن كل ما عليك فعله لتشغيل الصوت ضمن اللعبة هو استدعاء المتغير السابق عندما تحتاجه، فعلى سبيل المثال إذا رغبت بتشغيل الصوت OUCH عندما يصطدم بطلك بأحد الأعداء فستكتب الحلقة التالية: for enemy in enemy_hit_list: pygame.mixer.Sound.play(ouch) score -= 1 وبالطريقة نفسها يمكنك إنشاء مؤثرات صوتية لمختلف أنواع الأحداث في اللعبة، مثل: القفز، وجمع الجوائز، ورمي المقذوفات، والاصطدام بالأشياء… إلخ. إضافة موسيقى خلفية للعبة تساعدك الدالة music (إحدى دوال الوحدة mixer في Pygame) على تشغيل موسيقى أو مؤثرات جوية مثل صوت هواء أو غيره في خلفية background اللعبة، وذلك بخطوتين: أولًا تحميل الملف الصوتي بكتابة الأمر التالي في قسم الإعدادات setup من شيفرة اللعبة: music = pygame.mixer.music.load(os.path.join(s, 'music.ogg')) ثم تشغيل الدالة music كما يلي: pygame.mixer.music.play(-1) تعني القيمة 1- أن الدالة ستعمل إلى ما لا نهاية من دون توقف وهذه سمة الموسيقى الخلفية، لكن يمكنك استخدام أي عدد آخر بدءًا من 0 وما فوق لتحديد عدد المرات التي ستعمل فيها الدالة music قبل أن تتوقف. طوّر اللعبة ولا تتوقف هنا لا تتوقف عند ما تعلمناه في هذه السلسلة عن Pygame جرب إضافة المزيد من الأصوات والمراحل والمؤثرات الحركية إلى لعبتك، تعلَّم المزيد عنها فهي تضفي النكهة على لعبتك وتساهم في جعلها مفضلة لدى المستخدمين. ترجمة -وبتصرف- لمقال Add sound to your Python game لصاحبه Seth Kenlon. اقرأ أيضًا المقال السابق: إضافة آليات القذف إلى اللعبة المطورة بلغة بايثون مطور الألعاب: من هو وما هي مهامه تعرف على أشهر لغات برمجة الألعاب الأدوات المستخدمة في بناء الواجهات الرسومية في بايثون البرمجة باستخدام لغة بايثون في تطبيقات راسبيري باي تعرف على مجالات وتطبيقات لغة بايثون
  6. كتابة سكربتات باش Bash Scripting مهارة أساسية لا غنى عنها لكل مدير نظام ومهندس DevOps، فإذا كنت ترغب بتطوير مهاراتك في هذا المجال سواءً كنت مبتدئًا أو متمرسًا في نظام لينكس فإن هذه السلسلة التي تشرح Bash للمبتدئين ستلبي طلبك، بما تقدمه من أمثلة وتطبيقات عملية على أساسيات باش بدايةً من إنشاء السكريبت وحتى أتمتة تنفيذه على الخادم، وتتضمن هذه السلسلة المقالات التالية: أنشئ برنامجك النصي الأول على صدفة باش Bash. المتغيرات في سكربتات الصدفة باش Bash. تمرير الوسطاء إلى سكريبت باش Bash. استخدام المصفوفات في باش Bash. استخدام المعاملات الحسابية في سكربتات باش Bash. عمليات السلاسل النصية في باش Bash. الجمل الشرطية If و Else و Case في باش Bash. الحلقات في باش Bash. استخدام الدوال في باش Bash. أتمتة المهام باستخدام باش Bash. هذا هو المقال الأول في هذه السلسلة، إذ ستتعرف فيه على كيفية إنشاء سكريبت باش bash script يفيدك في أتمتة المهام الروتينية على الخادم، إذ كثيرًا ما نجد أنفسنا ننفذ المهام نفسها مرارًا وتكرارًا، بداية من النسخ الاحتياطي للمجلدات، وتنظيف الملفات المؤقتة، وحتى استنساخ cloning قواعد البيانات. سننشئ معًا سكريبت باش بسيط ونقوم بتشغيله، ونستعرض بعض الأساسيات التي ينبغي لك معرفتها عن كتابة سكربتات الصدفة Shell عمومًا. إنشاء سكريبت Shell وتشغيله أنشئ في البداية مجلدًا جديدًا اسمه "scripts" سنُخَزِّن فيه جميع السكربتات التي سننشئها في أثناء تطبيق أمثلة المقال، ثم انتقل للعمل ضمنه، بكتابة التالي: mkdir scripts cd scripts أنشئ ضمن المجلد السابق ملفًا نصيًّا باسم "hello.sh" باستخدام الأمر cat وفق التالي، أو أنشئه بأي طريقة أخرى تفضلها: cat > hello.sh يمكنك الآن الكتابة ضمن الملف من الطرفية terminal مباشرةً فاكتب السطر التالي: echo 'Hello, World!' ثم اضغط على Ctrl+D لحفظ التغييرات على الملف، والخروج من الأمر cat. تستطيع الكتابة ضمن الملف بالطريقة التي تناسبك باستخدام محررات النصوص العاملة في الطرفية مثلًا وأبرزها Vim و Emacs و Nano، أو محررات النصوص ذات الواجهة الرسومية نحو Gedit إذا كنت تستخدم إحدى بيئات سطح المكتب لنظام لينكس. يعرض الأمر echo العبارة "Hello World" المكتوبة بعده على الشاشة، وهدفنا هنا تشغيل echo على أنه سكريبت shell بدلًا من تشغيله بالطريقة العادية أي بكتابته ضمن الطرفية. بعد إنشاء الملف "hello.sh" سنحوله إلى ملف تنفيذي باستخدام الأمر chmod، كما يلي: chmod u+x hello.sh يمكنك معرفة المزيد عن chmod وغيره من أوامر لينكس الشهيرة بمطالعة المقال مرجع إلى أشهر أوامر لينكس. والآن لنشغّل السكريبت بكتابة الأمر "bash" قبل اسم الملف "hello.sh"، وفق التالي: bash hello.sh ستظهر العبارة !Hello, World أمامك على الشاشة مشيرةً لنجاح تنفيذ السكربت. ألقِ نظرة على الصورة أدناه فهي تتضمن ملخصًا للأوامر التي نفذناها حتى الآن. تحويل سكريبت Shell إلى سكريبت Bash يخلط البعض بين shell و bash، وهما مرتبطان بالفعل، لكن Shell أعَمّ من باش. فكلمة باش Bash اختصار للعبارة الإنجليزية "Bourne-Again shell"، وهي واحدة من أشهر أنواع الصدفات Shells المتاحة في لينكس. أما الصدفة shell فهي مُفَسِّر interpreter لسطر الأوامر يستقبل الأوامر المدخلة من المستخدم ويُشغلها، وله عدة أنواع. فأنت إذًا تستخدم الصدفة shell في كل مرة تكتب فيها أوامر لينكس، وعندما تفتح الطرفية على حاسوبك فأنت فعليَّا تشغل الصدفة الافتراضية لنظام لينكس الذي تستعمله. وباش هو الصدفة الافتراضية لمعظم توزيعات لينكس، لذا يستخدم في معظم الأحيان مرادفًا للصدفة shell. يوجد تشابه كبير في قواعد كتابة السكربتات بين أنواع الصدفات المختلفة، ولكنها مع ذلك تتباين في بعض الأحيان، فعلى سبيل المثال تبدأ فهرسة المصفوفات من "1" في صدفة Zsh بينما تبدأ من "0" في صدفة باش، وبالتالي فأي سكريبت مكتوب لصدفة Zsh ويتضمن مصفوفات، لن يعمل بطريقة صحيحة في صدفة باش. وهنا يأتي دور شيبانج shebang وهو السطر الذي تبدأ به كل سكربتات باش، فهو يوضح للمُفَسِّر أن السكريبت مكتوب للصدفة باش وليس لغيرها. السطر Shebang في بداية كل سكريبت يُقصد بسطر shebang العبارة bin/bash/ !# التي تكتب في السطر الأول من كل سكريبت باش، ويدعوه البعض hashbang لأنه يبدأ بالمحرفين هاش "#" hash وبان "!" ban. لاحظ كيف سيبدو السكريبت الذي أنشأناه قبل قليل بعد إضافة هذا السطر: #! /bin/bash echo 'Hello, World!' إذًا يخبر السطر bin/bash/ !# نظام التشغيل بنوع الصدفة أو المُفَسِّر الذي تود أن تستخدمه لتشغيل السكربت، فبعد إضافة هذا السطر إلى ملفنا السابق "hello.sh" سيعمل مباشرة بواسطة باش دون الحاجة لكتابة كلمة "bash'' قبل اسم الملف عند استدعائه كما فعلنا سابقًا. انظر الصورة أدناه: تشغيل السكريبت من أي مجلد بإضافة مساره للمتغير PATH إذا دققت في الصورة السابقة ستجد أننا استخدمنا البادئة /. قبل اسم السكريبت المُراد تشغيله للدلالة على مساره (فهو موجود في مجلد العمل الحالي)، وفي حال حذفت البادئة فستحصل على خطأ مثل التالي: abhishek@handbook:~/scripts$ hello.sh hello.sh: command not found فقد بَدَا اسم الملف للصدفة باش على أنه أمر برمجي يدعى hello.sh، وبدأ باش يبحث عن مساره بين المسارات المحددة في المتغير PATH، فمسارات حفظ جميع الأوامر التي تُشغلها الصدفات تخزن في هذا المتغير. يمكنك استعراض محتويات المتغير PATH باستخدام الأمر echo وفق ما يلي: echo $PATH /home/user/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin تفصل النقطتان الرأسيتان ":" بين المسارات الموجودة ضمن PATH والتي تفحصها صدفات shell عند تنفيذ أي أمر. يمكنك تشغيل أوامر لينكس مثل: echo و cat وغيرها من أي مجلد على الخادم لأن أماكن وجود ملفاتها التنفيذية معروفة للنظام فهي مُخَزَّنِة ضمن مجلدات bin، وجميع مجلدات bin مذكورة في المتغير PATH كما رأينا في خرج التعليمة السابقة، والمسارات الموجودة في PATH هي الأماكن التي يبحث فيها النظام عن الملف التنفيذي لأي أمر تطلب تشغيله. خلاصة القول إذا أردت تشغيل سكريبت باش الخاص بك من أي مجلد في نظام التشغيل كما لو أنه أمرٌ أساسي من أوامر النظام فأضف مسار وجوده إلى المتغير PATH، وفق الخطوات التالية. أولًا حدد مسار حفظ السكريبت بدقة، يمكنك استخدام الأمر pwd إذا كان السكريبت موجود في مجلد عملك الحالي: pwd بعد أن تحصل على المسار (وهو المجلد "scripts" في مثالنا)، استخدم الأمر export لإضافته إلى المتغير PATH كما يلي: export PATH=$PATH:/home/user/scripts ملاحظة: بعد إضافة المجلد scripts إلى نهاية متغير PATH، فهذا يعني أن النظام سيبحث في المجلدات القياسية أولاً قبل أن يبحث في المجلد scripts. إذا كان لديك نسخ من نفس البرنامج في عدة دلائل، فإن هذا الترتيب يضمن أن النسخة الموجودة في المجلدات القياسية، بمعنى سيفحص نظام التشغيل المجلدات التي تتواجد مساراتها في المتغير PATH بالترتيب، وبالتالي فهو يبحث أولًا في المجلدات القياسية لحفظ السكربتات، ثم يأتي إلى المجلدات المخصصة التي أضافها المستخدم. شغّل الآن السكريبت بكتابة اسمه مباشرةً في الطرفية مثل أي أمر من أوامر لينكس العادية ولاحظ النتيجة، وفق التالي: abhishek@handbook:~/scripts$ hello.sh Hello, World! وهذا ملخص للأوامر التي نفذناها هنا: تهانينا، لقد أنجزت السكريبت الأول لك في باش، تابع معنا بقية مقالات السلسلة لنتعلم أكثر عن متغيرات الصدفة، ونجرب معًا أمثلة متنوعة أخرى عن باش bash وطريقة التعامل معها بكفاءة. ترجمة -وبتصرف- للمقال Create and Run Your First Bash Shell Script. اقرأ أيضًا مدخل إلى صدفة باش Bash دليل ميَسَّر لكتابة سكربتات Shell الأخطاء الشائعة التي تحدث عند كتابة سكربتات الصدفة (Shell Scripts) تعديل سكربتات الصدفة (Shell Scripts) الموجودة على حاسوبك
  7. كوبرنيتس Kubernetes هو نظام تنسيق حاويات شهير ومفتوح المصدر، يستخدم لأتمتة نشر البرامج وتوسيعها وإدارتها، ويزداد الاعتماد عليه في الشركات والمؤسسات يومًا بعد يوم لتسهيل عمليات التوسعة الأفقية horizontal scaling لموارد الخادم، ويُقصد بها إضافة المزيد من الخوادم حسب الحاجة لزيادة الموارد المتاحة لتطبيقك، مثل: الحجوم التخزينية وقدرة المعالجة وغيرها. يمكنك الحصول على حلول Kubernetes السحابية من مزودي خدمات سحابية متعددين ولكل خدمة مميزات خاصة في الإدارة وغيرها. يتطلب العمل مع كوبرنيتس Kubernetes استخدامًا مكثفًا للموارد الحاسوبية، لأنه يعمل في نظام عنقودي يتكون من عدة خوادم، ويُشكل ذلك عبئًا إضافيًا على المطورين وخصوصًا في مرحلة ما قبل الإنتاج، فسيحتاجون الكثير من الموارد لتطوير مكدس Kubernetes تجريبي واختباره قبل النشر في البيئة الفعلية، لذا أنشأ مطورو Kubernetes مشروعًا مساعدًا مخصص لهذا الغرض يدعى minikube، الذي يعمل مع بيئات تشغيل الحاويات مثل دوكر Docker وغيره، ويستطيع محاكاة عنقود Kubernetes كامل على آلة واحدة فقط هي حاسوبك الشخصي مثلًا. فما هو minikube المحاكي الشهير لنظام Kubernetes؟ وكيف يستخدم لاختبار إعدادات Kubernetes قبل نشرها في بيئة الإنتاج؟ وما هي لوحة معلومات Kubernetes المضمنة فيه؟ سيجيبك المقال عن هذه الأسئلة، ويعطيك طريقة تثبيته على حاسوبك المحلي أو خادمك البعيد، ثم سنعمل معًا على نشر تطبيق تجريبي بسيط، ونحاول الوصول إليه عبر minikube، وفي الختام سنتعرف على طريقة استخدام Minikube مع عناقيد Kubernetes البعيدة بواسطة ملفات تعريف الإعدادات configuration profiles. متطلبات العمل ستحتاج المتطلبات الأولية التالية لتطبيق خطوات العمل المذكورة في المقال: فهم أساسيات Kubernetes، تفيدك مطالعة مقال تعرّف على كوبرنيتس Kubernetes لتكوين فكرة جيدة عن أبرز مفاهيم Kubernetes ومكوناته. تثبيت بيئة تشغيل الحاويات Docker على حاسوبك الذي ستعمل منه، إذ سنُشغل منها minikube. إذا كنت تستخدم نظام تشغيل لينكس، فستساعدك الخطوات الواردة في مقال كيفية تثبيت دوكر واستخدامه على دبيان، ولسهولة العمل احرص على تنفيذ الخطوة المتعلقة بضبط الإعدادات اللازمة لتشغيل Docker بدون الحاجة لكتابة sudo في بداية كل أمر. أما إذا كنت تعتمد نظام تشغيل ويندوز أو ماك فيمكنك الاستعانة بتوثيقات Docker الرسمية لإتمام عملية التثبيت. مدير الحزم Homebrew، يمكنك الاسترشاد بالخطوات الواردة في هذا المقال على DigitalOcean لتثبيته على نظام تشغيل ماك، أو بمقال لتثبيته على لينكس، وفي حال كنت تستخدم نظام ويندوز فتستطيع تثبيته باستخدام WSL نظام ويندوز الفرعي لنظام لينكس . توفير الموارد الحاسوبية اللازمة للبيئة التي ستُثَبِّت فيها Minikube، وهي بالحد الأدنى: وحدتي معالجة مركزية 2CPUs، وذاكرة مخبئية 2GB RAM، ومساحة تخزينية على القرص الصلب بسعة 20GB. الخطوة 1: تثبيت Minikube وتشغيله ثبّت minikube بواسطة مدير الحزم Homebrew كما يلي: $ brew install minikube وستحصل على خرج يشبه التالي، يبين لك نجاح التثبيت: … ==> Installing minikube ==> Pouring minikube--1.25.2.x86_64_linux.bottle.tar.gz ==> Caveats Bash completion has been installed to: /home/sammy/.linuxbrew/etc/bash_completion.d ==> Summary 🍺 /home/sammy/.linuxbrew/Cellar/minikube/1.25.2: 9 files, 70.0MB … ملاحظة: يتطلب تثبيت minikube على نظام ويندوز الانتباه لبعض التفاصيل المهمة: يعمل minikube مع WSL2 (وهي النسخة المتوفرة من WSL لتاريخ نشر المقال)، وينبغي تهيئته ليستخدم Docker واجهةً خلفية backend بدلًا من واجهته الخلفية الافتراضية. لذا بعد تثبيت Docker احرص على تفعيل ميزة دعم WSL2 باتباع إرشادات توثيقات Docker الخاصة بالموضوع ثم ثبت minikube ونفذ الأمر minikube config set driver docker. اكتب الآن الأمر start وفق التالي لبدء تشغيل minikube، وسينشأ بداخله آليًّا عنقود Kubernetes محلي بأحدث إصدار مستقر متوفر، ويتضمن عدة حاويات Docker: $ minikube start سيتطلب التشغيل بعض الوقت، وستحصل في نهايته على الخرج التالي، مع تجهيز الأداة kubectl لتستخدمها للاتصال مع العنقود cluster، كما يوضح السطر الأخير من الخرج: 👍 Starting control plane node minikube in cluster minikube 🚜 Pulling base image ... 💾 Downloading Kubernetes v1.23.1 preload ... > preloaded-images-k8s-v16-v1...: 504.42 MiB / 504.42 MiB 100.00% 81.31 Mi > gcr.io/k8s-minikube/kicbase: 378.98 MiB / 378.98 MiB 100.00% 31.21 MiB p 🔥 Creating docker container (CPUs=2, Memory=1987MB) ... 🐳 Preparing Kubernetes v1.23.1 on Docker 20.10.12 ... ▪ kubelet.housekeeping-interval=5m ▪ Generating certificates and keys ... ▪ Booting up control plane ... ▪ Configuring RBAC rules ... 🔎 Verifying Kubernetes components... ▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5 🌟 Enabled addons: default-storageclass, storage-provisioner 🏄 Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default ملاحظة: يمكنك اختيار إصدار Kubernetes الذي يناسبك لأسباب تتعلق بالتوافقية أو غيرها، بدلًا من الاعتماد على الإصدار الافتراضي الذي يوفره minikube، وذلك بكتابة رقم الإصدار المطلوب بعد الأمر minikube start بهذا الشكل kubernetes-version v.1.2.3--. يسمح لك تثبيت minikube بواسطة مدير الحزم Homebrew بالعمل مباشرةً مع kubectl الأداة الأساسية لإدارة عناقيد Kubernetes باستخدام سطر الأوامر، وبالتالي يمكنك كتابة الأمر kubectl get كما يلي لاستعراض جميع pods العاملة في العنقود بالطريقة نفسها المتبعة مع عناقيد Kubernetes العادية: $ kubectl get pods -A يعرض الوسيط A- كافة pods العاملة في جميع مساحات الأسماء namespaces الموجودة ضمن العنقود، ألقِ نظرة على شكل الخرج للأمر السابق: NAMESPACE NAME READY STATUS RESTARTS AGE kube-system coredns-64897985d-ttwl9 1/1 Running 0 46s kube-system etcd-minikube 1/1 Running 0 57s kube-system kube-apiserver-minikube 1/1 Running 0 61s kube-system kube-controller-manager-minikube 1/1 Running 0 57s kube-system kube-proxy-ddtgd 1/1 Running 0 46s kube-system kube-scheduler-minikube 1/1 Running 0 57s kube-system storage-provisioner 1/1 Running 1 (14s ago) 54s لديك الآن عنقود Kubernetes محلي، تستطيع إدارته باستخدام أدوات Kubernetes المألوفة مثل kubectl، وسنعرض في الفقرات القادمة وظائف إضافية يوفرها لك minikube لمراقبة عناقيد Kubernetes وإدارتها والتعديل عليها. الخطوة 2: الوصول إلى لوحة معلومات Kubernetes يوفر minikube لمستخدميه وصولًا سهلًا للوحة معلومات النظام Kubernetes Dashboard، التي يمكنك استخدامها لمراقبة سلامة العنقود ولنشر التطبيقات يدويًا ولغيرها من أعمال الإدارة. وفور تثبيت minikube محليًا على حاسوبك تستطيع الوصول إلى لوحة معلومات Kubernetes بكتابة الأمر minikube dashboard: $ minikube dashboard سيُشغّل هذا الأمر لوحة المعلومات آليًّا، ويفتح منفذًا port خاصًا داخل Kubernets يوجه حركة البيانات إلى العنقود، ثم يعرض رابط اللوحة الذي يشير إلى رقم المنفذ مباشرةً أمامك في متصفح الويب، كما في الصورة التالية. يؤدي تشغيل لوحة المعلومات إلى تعطيل النافذة الطرفية terminal التي كَتَبّتَ أمر التشغيل فيها، فلا يمكنك كتابة أوامر أخرى ضمنها، لذا يلجأ المستخدمون إلى تشغيل لوحة المعلومات في نافذة طرفية أخرى غير التي يعملون عليها. يمكنك إيقاف هذه العملية المُعطِّلة وغيرها من العمليات المشابهة بالضغط على Ctrl+C. أما إذا كنت تستخدم minikube على خادم بعيد، فأضِف الوسيط url-- إلى الأمر minikube dashboard السابق، وسيعطيك في الخرج رابط URL الخاص بلوحة المعلومات، بدلًا من فتحه مباشرة في المتصفح. ألقِ نظرة على الأمر التالي الخاص بتشغيل اللوحة للخادم البعيد: $ minikube dashboard --url وسيكون الخرج كما يلي: 🤔 Verifying dashboard health ... 🚀 Launching proxy ... 🤔 Verifying proxy health ... http://127.0.0.1:34197/api/v1/namespaces/kubernetes-dashboard/services/http:kubernetes-dashboard:/proxy/ يختلف رقم المنفذ الذي يفتحه minikube للوحة المعلومات من نظامٍ إلى آخر، ستلاحظ أن رقمه على حاسوبك مختلفٌ عن رقمه هنا في هذا المثال. تمنع إعدادات الأمان الافتراضية لنظام Kubernetes الوصول إلى عنوان URL هذا من الأجهزة البعيدة لحمايته، لذا ينبغي عليك بدايةً إعداد قناة SSH آمنة مع الخادم قبل فتحه. اكتب إذاً الأمر التالي مع الراية L- لفتح قناة ssh بين الحاسوب المحلي والخادم البعيد، واكتب ضمنه رقم منفذ لوحة المعلومات الظاهر في الخرج السابق، وعنوان IP لخادمك البعيد ليصبح بهذه الصيغة: $ ssh -L 34197:127.0.0.1:34197 sammy@your_server_ip يمكنك بعد ذلك الدخول إلى لوحة المعلومات باستخدام الرابط: http://127.0.0.1:34197/api/v1/namespaces/kubernetes-dashboard/services/http:kubernetes-dashboard:/proxy/. يمكنك معرفة المزيد عن تقنية الاتصال الآمن SSH بمطالعة الفيديو التالي: الآن بعد أن اختبرنا التعامل مع minikube مثل أي عنقود Kubernetes كامل عن طريق لوحة المعلومات، سننتقل للخطوة التالية، ونحاول نشر تطبيق تجريبي بسيط في هذا العنقود لنتأكد من عمله كما هو بالطريقة المرجوة منه. الخطوة 3: نشر تطبيق تجريبي واختباره يمكنك استخدام الأمر kubectl لنشر تطبيق تجريبي في عنقود Minikube. اكتب مثلًا الأمر التالي الذي سيؤدي إلى نشر تطبيق Kubernetes تجريبي متاح للاختبارات من شركة جوجل يدعى hello-app. $ kubectl create deployment web --image=gcr.io/google-samples/hello-app:1.0 يُنشئ هذا الأمر عملية نشر deployment داخل العنقود تدعى web، وتُبنى انطلاقًا من صورة بعيدة تسمى hello-app موجودة في سجل حاويات جوجل المسمى gcr.io. سنُعَرِّف الآن عملية النشر web بصفتها خدمة من خدمات Kubernetes، ونحدد منفذًا ثابتًا للاتصال معه بكتابة المحددين port=8080-- و type=NodePort--، وفق التالي: $ kubectl expose deployment web --type=NodePort --port=8080 يمكنك معرفة المزيد عن خدمات Kubernetes وكيفية الاتصال معها بمطالعة مقال تعرّف على كوبرنيتس Kubernetes. لنتحقق فيما إذا كانت الخدمة تعمل أم لا؟ بواسطة الأمر kubectl get service مع كتابة اسم الخدمة بعده، كما يلي: $ kubectl get service web ستحصل على خرج يشبه الخرج التالي، مع اختلاف في أرقام المنافذ لأن NodePort توزع أرقام المنافذ عشوائيًا على خدمات Kubernetes: NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE web NodePort 10.109.254.242 <none> 8080:31534/TCP 10s يمكننا الآن استخدام minikube للحصول على عنوان URL المتاح من خارج الحاوية، يسمح لك هذا العنوان بالاتصال مع خدمة التطبيق hello-app العاملة على المنفذ 8080 داخل العنقود. إذا كنت تستخدم Minikube على حاسوبك المحلي، فلست بحاجة لإعادة توجيه حركة البيانات من منفذ لآخر كما سنذكر لاحقًا، فقط نفذ الأمر minikube service web --url التالي، وستحصل على عنوان URL لتطبيقك التجريبي: $ minikube service web --url وسيكون الخرج عنوان URL مثل التالي: http://192.168.49.2:31534 اختبر عنوان URL بواسطة crul، وهو أحد أشهر برامج سطر الأوامر command line المستخدمة لإرسال أنواع مختلفة من طلبات الويب، يستخدم للتحقق من إمكانية عمل عناوين URL ضمن المتصفح في ظروف مناسبة، لذا ننصحك بفحص الروابط باستخدام crul دائمًا قبل تجربتها في المتصفح، وذلك وفق التالي: $ curl http://192.168.49.2:31534 يبين لك الخرج التالي نجاح العملية: Hello, world! Version: 1.0.0 Hostname: web-746c8679d4-j92tb يمكنك الآن استعراض عنوان URL هذا في المتصفح مباشرةً إذا كانت تستخدم minikube محليًا، وستحصل على النص السابق غير المنسق نفسه الذي حصلت عليه بتعليمة crul. أما إذا كنت تعمل على جهاز بعيد، استخدم اتصال SSH كما في الخطوة 2، ثم استعرض العنوان في المتصفح. أصبحت لديك الأساسيات اللازمة لنشر تطبيق عبر minikube فما ينطبق على التطبيق التجريبي البسيط الذي نشرناه يتنطبق نفسه على المشاريع الأكبر حجمًا، والتخصيص الإضافي الذي ستحتاجه فيها يتعلق بنظام Kubernetes وليس بوظائف minikube. سنتعلم في خطوتنا التالية طريقة استخدام بعض أدوات Minikube المدمجة لتغيير بعض الإعدادات الافتراضية للعنقود. الخطوة 4: إدارة نظام ملفات Minikube وموارده يوفر لك minikube عددًا من الأوامر الخاصة بتعديل إعدادات العنقود، فمثلًا يمكنك استخدام الأمر minikube config لتعديل الذاكرة المتوفرة للعنقود وفق التالي، علمًا أن الذاكرة هنا تقدر بالميجابايت MB وبالتالي يقابل الأمر minikube config 4096 توفير ذاكر بسعة 4GB لعنقودك: $ minikube config set memory 4096 ستحصل على الخرج التالي: ❗ These changes will take effect upon a minikube delete and then a minikube start يشير الخرج السابق إلى أن تعديل الذاكرة يتطلب إعادة نشر العنقود ليأخذ مفعوله. ملاحظة: لا تتطلب جميع التعديلات على الموارد إعادة نشر عنقود Kubernetes لتأخذ مفعولها، ففي بيئات الإنتاج يسري تغيير الذاكرة مباشرةً بدون إعادة نشر، لكن مع ذلك حاول أن لا تجري الكثير من التعديلات على عناقيد Kubernetes قيد التشغيل اعتمادًا على ملفات الإعدادات فقط بدون إجراء إعادة نشر، حاول الالتزام بإعادة النشر بعد كل تعديل على الموارد. تتضمن إعادة النشر مرحلتين هما minikube delete و minikube start، اكتب أولًا الأمر: $ minikube delete وستحصل على الخرج التالي: 🔥 Deleting "minikube" in docker ... 🔥 Deleting container "minikube" ... 🔥 Removing /home/sammy/.minikube/machines/minikube ... 💀 Removed all traces of the "minikube" cluster. ثم اكتب الأمر: $ minikube start يتيح لك minikube وصل أي مجلد من نظام ملفاتك المحلي الموجود على حاسوبك إلى داخل العنقود وصلًا مؤقتًا باستخدام الأمر minikube mount. أما كيفية كتابة الأمر mount قواعديًا فهي على الشكل التالي: local_path:minikube_host_path. يرمز local_path إلى مسار المجلد المحلي الذي تريد إيصاله إلى داخل العنقود، ويشير الجزء الآخر أي minikube_host_path إلى الموقع أو المجلد داخل VM أو داخل حاوية Minikube الذي تود أن تصل منه إلى ملفاتك. ألقِ نظرة على الأمر التالي الذي يوصل المجلد الأساسي الخاص بك home directory إلى المجلد host/ داخل عنقود minikube: $ minikube mount $HOME:/host وستحصل على الخرج التالي الذي يؤكد لك نجاح العملية: 📁 Mounting host path /home/sammy into VM as /host ... ▪ Mount type: ▪ User ID: docker ▪ Group ID: docker ▪ Version: 9p2000.L ▪ Message Size: 262144 ▪ Options: map[] ▪ Bind Address: 192.168.49.1:43605 🚀 Userspace file server: ufs starting ✅ Successfully mounted /home/sammy to /host 📌 NOTE: This process must stay alive for the mount to be accessible ... تفيدك هذه الطريقة في الحالات التي تحتاج فيها للحفاظ على مدخلات أو مخرجات ثابتة لعملك مع العنقود، مثل عمليات تسجيل الأحداث logging لعنقود minikube. تعطل هذه العملية نافذة الطرفية فلا يعود بإمكانك كتابة الأوامر فيها، يمكنك الخروج منها بالضغط على Ctrl+C، تمامًا كما فعلنا في حالة فتح المنفذ الخاصة بلوحة المعلومات التي ذكرناها في الخطوة 2. سنتعلم في الخطوة التالية كيف تتنقل بكفاءة بين minikube وعنقود Kubernetes كامل موجود على خادم بعيد. التعامل مع أكثر من عنقود Kubernetes يستطيع minikube التعامل مع عناقيد Kubernetes محلية متعددة في الوقت نفسه، فيُهيئ لكل عنقود ملف تعريف profile خاص به. فقد تحتاج في بعض الحالات للتعامل مع إصدارات مختلفة من عناقيد Kubernetes لإجراء اختبار معين مثلًا، فيمكنك عندها التبديل بين هذه الإصدارات باستخدام الراية p- أو profile--. وإذا كنت ستعمل مع عنقود معين لفترة طويلة أو أكثر من بقية العناقيد، فيمكنك تعيينه ليكون ملف التعريف الافتراضي في minikube بواسطة الأمر minikube profile، بدلًا من تحديده بعد الراية profile-- في كل أمر تنفذه. لنُشغّل الآن Minikube مع ملف تعريفي جديد بتنفيذ الأمر minikube start مع الراية p-، وفق التالي: $ minikube start -p new-profile اضبط الآن هذا الملف التعريفي الجديد ليكون هو الملف الفعال أو الافتراضي في Minikube بكتابة الأمر minikube profile كما يلي: $ minikube profile new-profile سيظهر لك هذا الخرج: ✅ minikube profile was successfully set to new-profile يمكنك معرفة الملف التعريفي الحالي الذي تستخدمه بواسطة الأمر get profile كما يلي: $ minikube config get profile وسيعيد لك الخرج اسم الملف التعريفي الحالي وهو في مثالنا: new-profile يُنشئ minikube ملفات الإعدادات لمنظومتك، ويخزنها هذه الملفات في مكانها الافتراضي المعروف للأداة kubectl ولغيرها من أدوات Kubernetes لتتمكن من الوصول إليها، ذلك سواء كنت تستخدم ملف تعريفي واحد أو عدة ملفات تعريفية، فمثلًا في كل مرة تنفذ فيها الأمر kubectl get nodes لاستعراض بيانات العقد nodes لعنقود minikube ستُحلل kubectl ملفات الإعدادات وتعطيك النتيجة، ألقِ نظرة على الأمر أدناه: $ kubectl get nodes وسيبين الخرج العقد الموجودة وهي عقدة واحدة فقط في حالتنا كما يلي: NAME STATUS ROLES AGE VERSION minikube Ready control-plane,master 3h18m v1.23.1 يمكنك اختيار أي ملف إعدادات تريده وإسناده للمُحَدِد kubeconfig لتقرأه kubectl عند بدء تشغيلها بدلًا من الملف الافتراضي الموجود في المجلد kube/confg. /~، وعندها ستستخدم بيانات اعتماد العنقود المذكورة في هذا الملف عوضًا عن تلك الموجودة في الملف الافتراضي. لنفترض أن لديك ملف إعدادات اسمه remote-kubeconfig.yaml مثلًا لعنقود Kubernetes آخر غير عنقودك في Minikube، وتريد استخراج العقد الموجودة فيه، فستكتب حينئذ الأمر التالي: $ kubectl --kubeconfig=remote-kubeconfig.yaml get nodes وستحصل في الخرج على العقد الموجودة في ذلك العنقود، والتي تعمل عن بعد خارج Minikube الخاص بك، وسيبدو الخرج كما يلي: NAME STATUS ROLES AGE VERSION pool-xr6rvqbox-uha8f Ready <none> 2d2h v1.21.9 pool-xr6rvqbox-uha8m Ready <none> 2d2h v1.21.9 pool-xr6rvqbox-uha8q Ready <none> 2d2h v1.21.9 صُمم Kubernetes في الأساس للعمل مع ملف إعدادات واحد لكل عنقود، يُمَرَر للأوامر مثل kubectl وغيره عند التشغيل، ومع ذلك يمكنك دمج عدة ملفات إعدادات مع بعضها، إلّا أنها ليست الطريقة المفضلة ولا تُعدّ ضرورية إذ سيضعب عليك بعدها تتبع أفضل الممارسات الموصى بها للعمل مع Kubernetes. ننصحك أيضًا بالتَعَرُّف على Krew مدير الحزم الخاص بإضافات Kubectl plugins. الخلاصة وضح هذا المقال كيفية تثبيت Minikube محليًا على الحاسوب الشخصي، واستخدام لوحة معلومات Kubernetes المُضمنة لمراقبة التطبيقات ونشرها، مع الإضاءة على الفكرة الأهم، وهي إمكانية العمل على نشر مثيل instance تجريبي للتطبيق واختباره محليًا ضمن minikube بالتزامن مع وجود مثيل Kubernetes بعيد نصل إليه بواسطة ملفات تعريف Minikube والراية kubectl --kubeconfig. خلاصة القول: يساعدك minikube على اختبار إعدادات Kubernetes وتقييمها محليًا قبل نشرها الفعلي، لتحدد كيف ومتى تصبح جاهزًا لنشر Kubernetes في بيئة الإنتاج. ترجمة -وبتصرف- للمقال How To Use minikube for Local Kubernetes Development and Testing لصاحبه Alex Garnett. اقرأ أيضًا تعلم أساسيات Kubernetes نشر التطبيقات وتوزيعها وفق نهج التسليم المستمر نظام كوبيرنتس Kubernetes وكيفية عمله أبرز المفاهيم التي يجب عليك الإلمام بها عن الحاويات
  8. نناقش في مقال اليوم النماذج اللغوية الكبيرة (LLMs) وهي صاحبة الدور الرئيسي في توليد النصوص، فهي تتكون من نماذج ذكاء اصطناعي كبيرة من نوع المحولات transformer، ومُدَرَّبة مُسبقًا على مهمة التنبؤ بالكلمة التالية (أو الـtoken التالي) من أي مُوجه يعطى لها، فهي إذًا تتنبأ بكلمات فردية بمقدار كلمة واحدة في كل مرة، لذا فإن توليد الجمل الكاملة سيحتاج تقنيةً أوسع تسمى توليد الانحدار الذاتي autoregressive generation. ويُعرَّف توليد الانحدار الذاتي بأنه إجراءٌ استدلالي متكرر مع الزمن، يستدعي نموذج LLM مراتٍ متكررة وفي كل مرة يُمرر له المخرجات التي وَلَّدها في المرة السابقة كمدخلات وهكذا، وبطبيعة الحالة يحتاح إلى مدخلات ابتدائية نقدمها له ليستخدمها في الاستدعاء الأول للنموذج، وتوفر مكتبة المحولات Transformers تابعًا خاصًا لهذا الغرض هو generate()‎، يعمل جميع النماذج ذات الإمكانات التوليدية generative. نسعى في هذا المقال لتحقيق ثلاثة أهداف رئيسية: شرح كيفية توليد نص باستخدام نموذج لغوي كبير LLM. الإضاءة على بعض المخاطر الشائعة لتتجنبها. اقتراح بعض المصادر التي ستساعدك على تحقيق أقصى استفادة ممكنة من نماذج LLMs. تأكد في البداية من تثبيت المكتبات الضرورية للعمل قبل أن نبدأ بالتفاصيل، وذلك وفق التالي: pip install transformers bitsandbytes>=0.39.0 -q توليد النص يأخذ النموذج اللغوي المُدَرَّب على النمذجة اللغوية السببية سلسلة من الرموز النصية كمدخلات inputs ويرجع بناءً عليها التوزع الاحتمالي للرمز التالي المتوقع، ألقِ نظرة على الصورة التوضيحية التالية: أما عن كيفية اختيار الرمز التالي من هذا التوزع الاحتمالي الناتج، فهي تختلف حسب الحالة، فقد تكون بسيطةً تتمثل بانتقاء الرمز الأكثر احتمالية من ضمن رموز التوزع الاحتمالي، أو معقدة لدرجة نحتاج معها لتطبيق عشرات التحويلات قبل الاختيار، وبصرف النظر عن طريقة الاختيار فإننا سنحصل بعد هذه المرحلة على رمز جديد نستخدمه في التكرار التالي أو الاستدعاء التالي للنموذج كما هو موضح في الصورة التالية لتوليد الانحدار الذاتي: تستمر عملية توليد الكلمات حتى نصل إلى أحد شروط التوقف التي يُحددها النموذج، ويتعلم النموذج متى ينبغي أن يرجع رمز نهاية السلسلة (EOS) الذي يُعدّ الإنهاء المثالي لعملية توليد النص، وفي حال لم يرجع النموذج هذا الرمز فسيظل العمل مستمرًا لحين الوصول إلى الحد الأقصى المسموح به من الرموز. إذًا فلديك أمرين مهمين ينبغي أن تهتم بهما ليعمل نموذجك التوليدي بالطريقة المرجوة، الأمر الأول هو كيفية اختيار الرمز التالي من بين رموز التوزع الاحتمالي، والأمر الثاني هو تحديد شرط إنهاء التوليد، تُضبط هذه الإعدادات في ملف إعدادات التوليد GenerationConfig الخاص بكل نموذج توليدي، يُحَمَّل هذا الملف مع النموذج وهو يتضنت معاملاتٍ افتراضية مناسبة له. لنبدأ الآن بالتطبيق العملي. حَمِّل أولًا النموذج كما يلي: >>> from transformers import AutoModelForCausalLM >>> model = AutoModelForCausalLM.from_pretrained( "mistralai/Mistral-7B-v0.1", device_map="auto", load_in_4bit=True ) استخدمنا في الاستدعاء from_pretrained السابق معاملين device_map و load_in_4bit: يضمن المعامل device_map أن حمل النموذج سيتوزع تلقائيًا على وحدات GPU المتاحة. يساعد المعامل load_in_4bit على تقليل استخدام الموارد الحاسوبية إلى أقصى حد ممكن عبر تطبيق التكميم الديناميكي 4 بت. توجد طرق أخرى عديدة لتهيئة نموذج LLM عند تحميله، عرضنا إحداها في الأمر السابق، وهي أساسية وبسيطة. نحتاج الآن لمعالجة النص معالجةً مسبقة قبل إدخاله للنموذج وذلك باستخدام المُرَمِّز Tokenizer وهو نوع المعالجة المناسب للنصوص كما تعلمنا في مقال المعالجة المُسبقة للبيانات قبل تمريرها لنماذج الذكاء الاصطناعي: >>> from transformers import AutoTokenizer >>> tokenizer = AutoTokenizer.from_pretrained("mistralai/Mistral-7B-v0.1", padding_side="left") >>> model_inputs = tokenizer(["A list of colors: red, blue"], return_tensors="pt").to("cuda") سيُخَزَّن خرج المُرَمِّز (وهو عبارة عن النص المُرَمَّز وقناع الانتباه attention mask) في المتغير model_inputs، ويوصى عادةً بتمرير بيانات قناع الانتباه ما أمكن ذلك للحصول على أفضل النتائج، رغم أن التابع generate()‎ سيسعى لتخمين قيمة قناع الانتباه عند عدم تمريره. ملاحظة: قناع الانتباه attention mask هو أداة تساعد النموذج اللغوي على معرفة الأجزاء المهمة في النص الذي يعالجه وتجاهل الأجزاء غير المهمة كرموز الحشو التي تُضاف لجعل طول النصوص موحدًا. يوجه هذا القناع النموذج ليركز فقط على الكلمات الفعلية في النص ويهمل الرموز لا تعني شيئًا للحصول على نتائج دقيقة. بعد انتهاء الترميز يُستدعى التابع generate()‎ الذي سيُرجع الرموز tokens المتنبأ بها، والتي ستتحول إلى نص قبل إظهارها في خرج النموذج. >>> generated_ids = model.generate(**model_inputs) >>> tokenizer.batch_decode(generated_ids, skip_special_tokens=True)[0] 'A list of colors: red, blue, green, yellow, orange, purple, pink,' ننوه أخيرًا إلى أنك لست مضطرًا لتمرير مدخلاتك إلى النموذج على شكل جمل مفردة، جملة واحدة في كل مرة، إذ يمكنك تجميع أكثر من جملة وتمريرها بهيئة دفعات batches مع استخدام الحشو padding لجعلها متساوية الطول، كما في المثال التالي، يزيد هذا الأسلوب من إنتاجية النموذج ويقلل الزمن والذاكرة المستهلكين: >>> tokenizer.pad_token = tokenizer.eos_token # لا تملك معظم النماذج اللغوية الكبيرة رمزًا للحشو افتراضيًا >>> model_inputs = tokenizer( ["A list of colors: red, blue", "Portugal is"], return_tensors="pt", padding=True ).to("cuda") >>> generated_ids = model.generate(**model_inputs) >>> tokenizer.batch_decode(generated_ids, skip_special_tokens=True) ['A list of colors: red, blue, green, yellow, orange, purple, pink,', 'Portugal is a country in southwestern Europe, on the Iber'] إذًا ببضع أسطر برمجية فقط استفدنا من أحد النماذج اللغوية الكبيرة LLM واستطعنا توليد نصوص مكلمة للجمل التي أعطيناها للنموذج. بعض المشكلات المحتمل وقوعها لا تناسب القيم الافتراضية لمعاملات النماذج التوليدية جميع المهام فلكل مشروع خصوصيته، والاعتماد عليها قد لا يعطينا نتائج مرضية في العديد من حالات الاستخدام، سنعرض لك أشهرها مع طرق تجنبها: لنبدأ أولًا بتحميل النموذج والمُرَمِّز ثم نتابع بقية أجزاء الشيفرة ضمن الأمثلة تباعًا: >>> from transformers import AutoModelForCausalLM, AutoTokenizer >>> tokenizer = AutoTokenizer.from_pretrained("mistralai/Mistral-7B-v0.1") >>> tokenizer.pad_token = tokenizer.eos_token # لا تمتلك معظم النماذج اللغوية الكبيرة رمزًا للحشو افتراضيًا >>> model = AutoModelForCausalLM.from_pretrained( "mistralai/Mistral-7B-v0.1", device_map="auto", load_in_4bit=True ) توليد خرج أطول أو أقصر من اللازم يُرجع التابع generate عشرين tokens كحد أقصى افتراضيًا، طالما أننا لم نحدد ما يخالف ذلك في ملف إعدادات التوليد Generation-config، ولكن ما ينبغي الانتباه له أن نماذج LLMs (وخاصة النماذج من نوع decoder models مثل GPT و CTRL) تُرجع مُوجَّه الدخل input prompt أيضًا مع كل خرج تعطيه، لذا ننصحك بتحديد الحد الأقصى لعدد الـ tokens الناتجة يدويًا، وعدم الاعتماد على الحد الافتراضي، وذلك ضمن المتغير max_new_tokens المرافق لاستدعاء generate، ألقِ نظرة على المثال التالي ولاحظ الفرق في الخرج بين الحالتين، الحالة الافتراضية، وحالة تحديد العدد الأقصى للرموز الناتجة: >>> model_inputs = tokenizer(["A sequence of numbers: 1, 2"], >>> return_tensors="pt").to("cuda") # الحالة الافتراضية الحد الأقصى لعدد الرموز الناتجة هو 20 رمز >>> generated_ids = model.generate(**model_inputs) >>> tokenizer.batch_decode(generated_ids, skip_special_tokens=True)[0] 'A sequence of numbers: 1, 2, 3, 4, 5' # عند ضبط قيمة المتغير الذي سيحدد العدد الأقصى للرموز الناتجة >>> generated_ids = model.generate(**model_inputs, max_new_tokens=50) >>> tokenizer.batch_decode(generated_ids, skip_special_tokens=True)[0] 'A sequence of numbers: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16,' نمط توليد غير مناسب افتراضيًا يختار التابع generate الرمز الأكثر احتمالية من بين الرموز الناتجة في كل تكرار ما لم نحدد طريقة مغايرة للاختيار في ملف إعدادات التوليد GenerationConfig، يسمى هذا الأسلوب الافتراضي فك التشفير الشره greedy decoding، وهو لا يناسب المهام الإبداعية التي تستفيد من بعض العينات، مثل: بناء روبوت دردشة لمحادثة العملاء أو كتابة مقال متخصص، لكنه من ناحية أخرى يعمل جيدًا مع المهام المستندة إلى المدخلات، نحو: التفريغ الصوتي والترجمة وغيره، لذا اضبط المتغير على القيمة do_sample=True في المهام الإبداعية، كما يبين المثال التالي الذي يتضمن ثلاث حالات: >>> # استخدم هذا السطر إذا رغبت بالتكرار الكامل >>> from transformers import set_seed >>> set_seed(42) >>> model_inputs = tokenizer(["I am a cat."], return_tensors="pt").to("cuda") >>> # LLM + فك التشفير الشره = مخرجات متكررة ومملة >>> generated_ids = model.generate(**model_inputs) >>> tokenizer.batch_decode(generated_ids, skip_special_tokens=True)[0] 'I am a cat. I am a cat. I am a cat. I am a cat' >>> # مع تفعيل أخذ العينات، تصبح المخرجات أكثر إبداعًا >>> generated_ids = model.generate(**model_inputs, do_sample=True) >>> tokenizer.batch_decode(generated_ids, skip_special_tokens=True)[0] 'I am a cat. Specifically, I am an indoor-only cat. I' الحشو في الجانب الخاطئ ذكرنا سابقًا أنك عندما تقوم بإدخال جمل أو نصوص ذات أطوال مختلفة للنموذج، فقد تحتاج إلى جعل هذه المدخلات بطول موحد ليتمكن النموذج من معالجتها بشكل صحيح من خلال إضافة رموز الحشو (padding tokens) التي تجعل جميع المدخلات بطول متساوٍ. لكن النماذج اللغوية الكبيرة LLMs هي بنى لفك التشفير فقط decoder-only فهي تكرر الإجراءات نفسها على مدخلاتك، لكنها غير مُدَرَّبة على الاستمرار بالتكرار على رموز الحشو، لذا عندما تكون مدخلاتك مختلفة الأطوال وتحتاج للحشو لتصبح بطول موحد، فاحرص على إضافة رموز الحشو على الجانب الأيسر left-padded (أي قبل بداية النص الحقيقي) ليعمل التوليد بطريقة سليمة، وتأكد من تمرير قناع الانتباه attention mask للتابع generate حتى لا تترك الأمر للتخمين: >>> # المُرَمِّز المستخدم هنا يحشو الرموز على الجانب الأيمن افتراضيًا، والسلسلة النصية الأولى هي >>> # السلسلة الأقصر والتي تحتاج لحشو، وعند حشوها على الجانب الأيمن سيفشل النموذج التوليدي في التنبؤ بمنطقية >>> model_inputs = tokenizer( ["1, 2, 3", "A, B, C, D, E"], padding=True, return_tensors="pt" ).to("cuda") >>> generated_ids = model.generate(**model_inputs) >>> tokenizer.batch_decode(generated_ids, skip_special_tokens=True)[0] '1, 2, 33333333333' >>> # لاحظ الفرق عند تعديل الحشو ليصبح على الجانب الأيسر >>> tokenizer = AutoTokenizer.from_pretrained("mistralai/Mistral-7B-v0.1", padding_side="left") >>> tokenizer.pad_token = tokenizer.eos_token # Most LLMs don't have a pad token by default >>> model_inputs = tokenizer( ["1, 2, 3", "A, B, C, D, E"], padding=True, return_tensors="pt" ).to("cuda") >>> generated_ids = model.generate(**model_inputs) >>> tokenizer.batch_decode(generated_ids, skip_special_tokens=True)[0] '1, 2, 3, 4, 5, 6,' مُوجَّهات خاطئة يتراجع أداء بعض النماذج عندما لا نمرر لها مُوجَّهات input prompt بالتنسيق الصحيح الذي يناسبها، يمكنك الحصول على مزيد من المعلومات عن طبيعة الدخل المتوقع للنماذج مع كل مهمة بالاطلاع على دليل المُوجَّهات في نماذج LLMs على منصة Hugging Face، ألقِ نظرة على المثال التالي الذي عن استخدام نموذج LLM للدردشة باستخدام قوالب الدردشة: >>> tokenizer = AutoTokenizer.from_pretrained("HuggingFaceH4/zephyr-7b-alpha") >>> model = AutoModelForCausalLM.from_pretrained( "HuggingFaceH4/zephyr-7b-alpha", device_map="auto", load_in_4bit=True ) >>> set_seed(0) >>> prompt = """How many helicopters can a human eat in one sitting? Reply as a thug.""" >>> model_inputs = tokenizer([prompt], return_tensors="pt").to("cuda") >>> input_length = model_inputs.input_ids.shape[1] >>> generated_ids = model.generate(**model_inputs, max_new_tokens=20) >>> print(tokenizer.batch_decode(generated_ids[:, input_length:], skip_special_tokens=True)[0]) "I'm not a thug, but i can tell you that a human cannot eat" >>> # لم يتبع النموذج تعليماتنا هنا فهو لم يرد على السؤال كما ينبغي أن يرد أي شخص عنيف >>> # سنقدم الآن دخلًا أفضل يناسب النموذج باستخدام قوالب الدردشة، ونرى الفرق النتيجة >>> set_seed(0) >>> messages = [ { "role": "system", "content": "You are a friendly chatbot who always responds in the style of a thug", }, {"role": "user", "content": "How many helicopters can a human eat in one sitting?"}, ] >>> model_inputs = tokenizer.apply_chat_template(messages, add_generation_prompt=True, return_tensors="pt").to("cuda") >>> input_length = model_inputs.shape[1] >>> generated_ids = model.generate(model_inputs, do_sample=True, max_new_tokens=20) >>> print(tokenizer.batch_decode(generated_ids[:, input_length:], skip_special_tokens=True)[0]) 'None, you thug. How bout you try to focus on more useful questions?' >>> # كما تلاحظ فقد تغير أسلوب الرد واتبع تعليماتنا بطريقة أفضل فكان رده أقرب للأسلوب المطلوب مصادر مفيدة للاستفادة من نماذج LLMs ستحتاج لتعميق معرفتك بالنماذج اللغوية الكبيرة (LLMs) إذا رغبت بتحقيق أقصى استفادة منها، وإليك بعض الأدلة المفيدة من منصة Hugging Face المتخصصة في المجال: أدلة الاستخدام المتقدم للتوليد Generating دليل استراتيجيات توليد النصوص باستخدام الذكاء الاصطناعي الذي يساعدك في تعلم كيفية التحكم بتوابع توليد مختلفة، وضبط مخرجاتها، وملفات الإعدادات الخاصة بها. دليل لاستخدام قوالب الدردشة مع نماذج LLMs. دليل LLM prompting يتضمن الأساسيات وأفضل الممارسات في كتابة المُوجَّهات. توثيقات واجهة برمجة التطبيقات API لكل من ملف إعدادات التوليد GenerationConfig و التابع ()generate و الأصناف clasess المرتبطة مع المعالجة المسبقة والعديد من الأمثلة التوضيحية. أشهر نماذج LLMs النماذج مفتوحة المصدر التي تُركِّز على الجودة Open LLM Leaderboard. النماذج التي تهتم بالإنتاجية Open LLM-Perf Leaderboard. أدلة حول تحسين السرعة والإنتاجية وتقليل استخدام الذاكرة دليل تحسين السرعة والذاكرة في نماذج LLMs. دليل التكميم Quantization باستخدام تقنيات مثل bitsandbytes و autogptq، لتخفيض متطلبات استخدام الذواكر. مكتبات مرتبطة بالنماذج اللغوية الكبيرة المكتبة text-generation-inference، وهي بمثابة خادم إنتاج جاهز للعمل مع نماذج LLMs. المكتبة optimum، وهي امتداد لمكتبة المحوّلات Transformers تساعدك في تحسين استخدام مكونات الحاسوب وموارده. كما تساعدك دورة الذكاء الاصطناعي من أكاديمية حسوب في فهم طريقة التعامل مع النماذج اللغوية الكبيرة LLMs وربط الذكاء الاصطناعي مع تطبيقاتك المختلفة، كما يمكنك الحصول على معلومات مفيدة من دروس ومقالات قسم الذكاء الاصطناعي على أكاديمية حسوب. دورة الذكاء الاصطناعي احترف برمجة الذكاء الاصطناعي AI وتحليل البيانات وتعلم كافة المعلومات التي تحتاجها لبناء نماذج ذكاء اصطناعي متخصصة. اشترك الآن الخلاصة وصلنا إلى ختام المقال وقد عرضنا فيه طريقة استخدام النماذج اللغوية الكبيرة LLMs لتوليد النصوص الطويلة تلقائيًا من نص بسيط مُدخل، مع بيان بعض المخاطر الشائعة التي تعترض مستخدميها وكيفية تجنبها، بالإضافة لتعداد أشهر نماذج LLM، وبعض المصادر الموثوقة لمن يريد تعلمها بتعمقٍ أكبر. ترجمة -وبتصرف- لقسم Generation with LLMs من توثيقات Hugging Face. اقرأ أيضًا المقال السابق: استخدام وكلاء مكتبة المحولات Transformers Agents في الذكاء الاصطناعي التوليدي تدريب المًكيَّفات PEFT Adapters بدل تدريب نماذج الذكاء الاصطناعي بالكامل بناء تطبيق بايثون يجيب على أسئلة ملف PDF باستخدام الذكاء الاصطناعي تطوير تطبيق 'اختبرني' باستخدام ChatGPT ولغة جافاسكربت مع Node.js مصطلحات الذكاء الاصطناعي للمبتدئين
  9. نعرفكم في مقال اليوم على كيفية استخدام مكتبة المحولات Transformers في مهام الذكاء الاصطناعي التوليدي مثل توليد الصور أو تحويل النص إلى كلام أو الإجابة عن أسئلة متعلقة بالمستندات حيث يوفر الإصدار v4.29.0 من مكتبة المحوّلات Transformers واجهة برمجة تطبيقات API اختبارية لعناصر مفيدة في الذكاء الاصطناعي التوليدي هي الوكلاء Agents والأدوات Tools، وسنناقشها بالتفصيل في فقراتنا التالية. يمكنك العمل مع هذه الواجهة البرمجية API من رابط مخصص لها على جوجل كولاب Google Colab، وهي تُركز على مهام فهم اللغة الطبيعية (اللغة البشرية)، فيعمل الوكيل agent على تفسير أوامر اللغة الطبيعية المعُطاة له مستخدمًا مجموعة من الأدوات الأساسية التي توفرها المكتبة؛ تحتاج لأن تبدأ عملك بتصميم الوكيل وتحديد أدواته المناسبة لمشروعك، ويمكنك في أي لحظة توسيع نطاق التصميم ليشمل أدواتٍ إضافية أنشأها وشاركها مطورون آخرون على مجتمع Hugging Face. سنعرض بعضًا من الأمثلة عمّا يمكنك تحقيقه باستخدام هذه الواجهة البرمجية API، وستلاحظ قوتها في المهام متعددة الأنماط multimodal، لذا سنبدأ أمثلتنا بتجربتها في مهام توليد الصور وقراءة النصوص صوتيًا. ألقِ نظرة على الأمر التالي فهو يوجه طلبًا مكتوبًا باللغة الإنكليزية للوكيل Agent ويطلب منه وضع تسمية توضيحية أو عنوان للصورة المعطاة له: agent.run("Caption the following image", image=image) لاحظ أن دخل الوكيل صورة والخرج تسمية توضيحية تناسبها: الدخل الخرج A beaver is swimming in the water الآن لنطلب من الوكيل Agent قراءة التسمية التوضيحية السابقة، سنمررها له ضمن text: agent.run("Read the following text out loud", text=text) وسيكون الدخل والخرج كما يلي: الدخل الخرج A beaver is swimming in the water ملف صوتي يقرأ النص باللغة الطبيعية وهي في مثالنا الإنجليزية tts_example.wav لنجرب أيضًا تمرير مستند document للوكيل Agent ونطرح عليه سؤالًا عن مضمون المستند: agent.run( "In the following `document`, where will the TRRF Scientific Advisory Council Meeting take place?", document=document, ) في هذه الحالة سيكون الدخل والخرج كما يلي: الدخل الخرج صورة المستند نص يتضمن الإجابة عن السؤال المستنتجة من المستند أكمل معنا قراءة المقال لتعرف الأساسيات، ثم ادخل إلى بيئة Google Colab الخاصة بالمكتبة وجرب بعض المهام بنفسك حتى تتقن التعامل معها. مقدمة سريعة الخطوة الأولى هي إدراج الوكيل الذي نود استخدامه بتعليمة agent.run، والوكيل هو نموذج لغوي كبير (LLM) يمكنك الحصول عليه من مصادر متنوعة، فمكتبة المحوّلات Transformers مثلًا تدعم النماذج اللغوية الخاصة بمنصات openAI و BigCode و OpenAssistant؛ تتمتع نماذج openAI بكفاءة أعلى من البقية لكنها بالمقابل غير مجانية إذ يتطلب استخدام واجهتها البرمجية مفتاحًا خاصًا "openAI API key"، أما نماذج منصتي BigCode و OpenAssistant فالوصول إليها متاح مجانًا عبر منصة Hugging Face يمكنك استخدامها بسهولة. لنُثَبِّت في البداية امتداد مكتبة المحوّلات الخاص بالوكلاء agents قبل تثبيت بقية الاعتماديات: pip install transformers[agents] تعتمد خطوتنا التالية على نوع المنصة التي سنستخدم نماذجها. إذا رغبت باعتماد نماذج OpenAI فثَبِّت الاعتمادية openai لتتمكن من استخدامها وإنشاء المثيل OpenAiAgent ليكون وكيلًا: pip install openai يمكنك الآن إدراج الوكيل OpenAiAgent كما يلي: from transformers import OpenAiAgent agent = OpenAiAgent(model="text-davinci-003", api_key="<your_api_key>") أما إذا رغبت باستخدام نماذج BigCode أو OpenAssistant، فعليك في البداية تسجيل الدخول إلى منصة Hugging Face لتحصل على صلاحية الوصول إلى واجهة API الاستدلالية التي توفرها Hugging Face لهذه النماذج: from huggingface_hub import login login("<YOUR_TOKEN>") وبعدها أدرج الوكيل agent: from transformers import HfAgent # Starcoder agent = HfAgent("https://api-inference.huggingface.co/models/bigcode/starcoder") # StarcoderBase # agent = HfAgent("https://api-inference.huggingface.co/models/bigcode/starcoderbase") # OpenAssistant # agent = HfAgent(url_endpoint="https://api-inference.huggingface.co/models/OpenAssistant/oasst-sft-4-pythia-12b-epoch-3.5") استخدمنا هنا واجهة API المجانية (حاليًا) التي توفرها Hugging Face للوصول إلى النماذج اللغوية الكبيرة، لكن يمكنك بالطبع استخدام أي واجهة API أخرى متوفرة لديك وعندها ستستبدل عنوان URL الذي استخدمناه بعنوان URL لنقطة الاتصال endpoint المتوفرة لديك. ملاحظة: تعمل النماذج المجانية لكل من OpenAssistant و StarCoder جيدًا في المهام البسيطة لكن أداءها يتراجع للأسف كلما ازداد تعقيد المهام الموكلة لها، لذا ننصحك باستخدام نماذج OpenAI في المشاريع الكبيرة فبالرغم من كونها غير مفتوحة المصدر لكنها مناسبة. لننتقل إلى الخطوة التالية، ونتعرف عن قرب على واجهتي API المتوفرتين لدينا الآن. التنفيذ الإفرادي باستخدام التابع run يستخدم التنفيذ الإفرادي single execution التابع ()run مع الوكيل agent كما في المثال التالي الذي يطلب من الوكيل توليد صورة تتضمن أنهارًا وبحيرات: agent.run("Draw me a picture of rivers and lakes.") أرجع الوكيل الصورة التالية: سيُحَدِدْ الوكيل agent تلقائيًا الأداة tool أو الأدوات المناسبة للمهمة التي طلبنا تنفيذها، ويعمل على تشغيلها بالطريقة الصحيحة، علمًا أنه يستطيع تنفيذ أكثر من مهمة في آن واحد، لكن لا ننصحك بذلك فكلما ازداد تعقيد الأوامر الموجهة له ازدادت احتمالات الفشل. وهذا مثالٌ آخر لتوليد صورة تتضمن بحرًا ثم إضافة جزيرة عليها: agent.run("Draw me a picture of the sea then transform the picture to add an island") وستكون الصورة التي ستحصل عليها كالتالي: يمكنك تشغيل ()run لمهام مختلفة عدة مرات متتالية، فكل تعليمة ()run مستقلة تمامًا عن غيرها من التعليمات. تُعدّ دقة مطالبات الدخل prompts الموجهة للوكيل مهمة جدًا في الحصول على أفضل النتائج، فالاختلافات الصغيرة فيها تصنع فرقًا فالوكيل agent في نهاية الأمر مجرد نموذج لغوي كبير يستجيب للتوجيهات التي تُعطى له. كما يوفر الوكيل خياراتٍ مفيدة أخرى عبر المتغيرات التي يقبلها، فتستطيع مثلًا تمرير كائنات غير نصية له كتمرير الصور، أو توجيهه لحفظ حالة التنفيذ الأخيرة التي وصل إليها وتحديثها بإضافة عناصر جديدة، لنفترض أننا نريد من الوكيل أخذ صورة الأنهار والبحيرات التي ولدها في مثالنا السابق وإضافة جزيرة عليها، فستكون الأوامر وفق التالي: picture = agent.run("Generate a picture of rivers and lakes.") updated_picture = agent.run("Transform the image in `picture` to add an island to it.", picture=picture) تفيدك هذه الحالة عندما لا يكون النموذج قادرًا على فهم طلبك بوضوح أو عاجزًا عن مزج عدة أدوات معًا، كما في المثال التالي: > agent.run("Draw me the picture of a capybara swimming in the sea") قد يُفسِّر الوكيل هذا الطلب بطريقتين: توليد صورة من النص text-to-image والنص هو: "ارسم لي صورة لحيوان كابيبارا يسبح في الماء". توليد صورة من النص text-to-image والنص هو: "ارسم لي صورة لحيوان كابيبارا"، ثم "استخدام أداة تحويل الصور image-transformation لجعل حيوان الكابيبارا يسبح". يمكنك حسم الموضوع وفرض السيناريو الأول بتمرير موجه prompt صريحة كمتغير للوكيل تتضمن بوضوح ما تريد وجوده في الصورة كما يلي: agent.run("Draw me a picture of the `prompt`", prompt="a capybara swimming in the sea") التنفيذ المستند إلى الدردشة باستخدام التابع chat يعمل الوكيل agent بأسلوب الدردشة النصية chat-based بواسطة التابع ()chat كما في المثال التالي: سنطالبه أولًا بتوليد صورة أنهار وبحيرات: agent.chat("Generate a picture of rivers and lakes") سيولد لنا الصورة التالية: ثم سنطلب منه تحويل الصورة وإضافة عنصر إليها كما يلي: agent.chat("Transform the picture so that there is a rock in there") يساعدك هذا الأسلوب في الاختبارات وتنفيذ التعليمات الفردية التي تحافظ فيها على الحالة الأخيرة للتنفيذ عبر مجموعة من التعليمات، لكنه ليس الأسلوب الأمثل للتعليمات المعقدة، التي يناسبها التنفيذ المعتمد على ()run. يقبل التنفيذ المعتمد على الدردشة تمرير وسيط غير نصي أو موجهات Prompts محددة للتابع ()chat. التنفيذ عن بعد Remote execution أنشأت منصة Hugging Face -باستخدام نقاط الاتصال الاستدلالية inference endpoints- مُنَفِّذْين عن بعد remote executors للعديد من الأدوات الافتراضية التي يستخدمها الوكلاء agents، ستجدها معطلة حاليًا في هذا الإصدار لكننا ذكرناها هنا لتعرف أن الإمكانية متوفرة، وأن باستطاعتك إنشاء أدوات مخصصة لاحتياجات مشروعك وتخزينها في مستودع بعيد ثم استدعائها للتنفيذ عن بعد، اقرأ دليل إنشاء الأدوات المخصصة لتعرف أكثر عن الموضوع. الوكلاء Agents والأدوات Tools بعد هذه المقدمة السريعة سنُعَرِّف الآن الوكلاء Agents والأدوات Tools، لكن اطّلع أولًا على المخطط التوضيحي التالي: الوكلاء Agents الوكيل agent هو نموذج لغوي كبير (LLM) نوجهه بواسطة مُوجّهات prompts ليستخدم مجموعة من الأدوات tools التي نحددها له بغرض تنفيذ المهمة المطلوبة. تُعَدُ النماذج اللغوية الكبيرة (LLMs) مناسبة لتوليد شيفرات برمجية صغيرة، لذا تستفيد الواجهة البرمجية API من هذه الميزة وتطلب من النموذج توليد شيفرة برمجية تتضمن التعليمات اللازمة لتنفيذ مهمة محددة مع استخدام أدوات معينة نَصِفُها له، فيأخذ الوكيل المهمة والوصف المقدم للأدوات، ويكمل المطلوب بإنشاء تعليمات متوافقة مع مدخلات الأدوات ومخرجاتها كما هو موضح في المخطط السابق. الأدوات Tools تتكون الأداة tool من دالة واحدة لها وظيفة محددة؛ وتتميز كل أداة باسم ووصف، نستخدم وصف الأدوات في المُوجِّهات prompt الموجهة للوكيل agent، فيوضح له الوصف كيف يستفيد من كل أداة في تنفيذ المهمة المطلوبة. يستخدم الوكيل agent الأدوات tools بدلًا من خطوط الأنابيب pipelines بالرغم من تشابه المفهومين لأنه يقدم أداءً أفضل في كتابة الشيفرة البرمجية مع الأدوات المحددة والصغيرة، فالأدوات تتخصص بمهمة واحدة بسيطة، بينما تجمع خطوط الأنابيب مهام متعددة في آنٍ واحد. تنفيذ الشيفرة البرمجية بعد توليد الوكيل الشيفرة البرمجية تُنَفَّذْ على المدخلات مباشرةً باستخدام مُفَسِّر أوامر بايثون المحدود والخاص في منصة Hugging Face، قد لا تطمئن لهذه الطريقة أو تظنها غير آمنة فالأوامر الناتجة عن الوكيل تذهب للمُفَسِّر مباشرةً وتُنَفَّذْ دون أن تراها. لكن ما يخفف مخاطرها أن التنفيذ يقتصر على الأدوات التي تستدعيها بنفسك فقط ، ولن تُنفذ أي تعليمات أخرى غيرها، لذا فهو يُعدّ آمنًا نوعًا ما، طالما أنك تلتزم باستخدام الأدوات التي تؤمنها منصة Hugging Face، فالمنصة تعتمد عددًا من الاحتياطات الأمنية فهي تمنع عمليات استخراج السمات من الشيفرات البرمجية أو استيرادها وتحميك من الهجمات الشهيرة. وإذا رغبت بحماية أكبر فيمكنك استخدام أسلوب التنفيذ المعتمد على التابع ()run مع الوسيط return_code=True الذي سيعرض لك الشيفرة البرمجية التي وَلَّدها الوكيل لتتفحصها وتقرر بنفسك فيما إذا ما كنت تود تنفيذها أم لا. أما حالات توقف التنفيذ غير المتوقعة التي قد تصادفك، فهي ترجع عادةً لسببين: إما تنفيذك عملية غير مصرح بها، أو وجود خطأ ما في الشيفرة التي أنتجها الوكيل. الأدوات التي توفرها مكتبة Transformers هذه قائمة بأشهر الأدوات المدمجة في مكتبة المحوّلات Transformers والمستخدمة لتشغيل الوكلاء agents: الإجابة عن أسئلة حول محتوى المستند Document question answering: نمرر للنموذج مستندًا (ملف PDF مثلًا) بصيغة صورة ويستخدم الأداة للإجابة عن أي سؤال تطرحه حول محتوى المستند، ومن أمثلته النموذج (Donut). الإجابة عن أسئلة حول النص Text question answering: تكون المدخلات هنا نص طويل وسؤال، والمخرجات هي الإجابة عن هذا السؤال من داخل النص، تعمل مع النموذج (Flan-T5). وضع تسمية توضيحية للصورة Unconditional image captioning: وضع تسميةً توضيحية للصور المدخلة، مثل النموذج (BLIP). الإجابة عن أسئلة حول الصورة Image question answering: نمرر صورة لتتم الإجابة عن السؤال المطروح عنها، (VILT). تجزئة الصور Image segmentation: المدخلات في هذه الحالة: صورة، وموجه prompt بتجزئة الصورة، ويكون الخرج قناعًا لتجزئة الصورة حسب المعيار المحدد في الموجه prompt، ومن أمثلتها النموذج (CLIPSeg) تحويل الكلام إلى نص Speech to text: نمرر ملفًا صوتيًا لشخص يتكلم، ويجري تحويله إلى نص، يناسبه مثلًا النموذج (Whisper). تحول النص إلى كلام Text to speech: العملية المعاكسة، الدخل هنا هو نص ويُحوّل إلى كلام، تعمل مع النموذج (SpeechT5). تصنيف النصوص بدون تدريب مسبق Zero-shot text classification: نمرر للنموذج نصًا ومجموعة تسميات توضيحية labels لم تكن موجودة ضمن البيانات التي تَدَرَّبَ عليها سابقًا، وينبغي له تحديد التسمية التوضيحية الأكثر توافقًا مع النص، مثل النموذج (BART). تلخيص النصوص Text summarization: تلخيص النص الطويل ببضع جمل فقط، مثل النموذج (BART). الترجمة Translation: ترجمة النص المُعطى إلى اللغة المحددة، مثل النموذج (NLLB). هذه الأدوات مدمجة في مكتبة المحولات Transformers ويمكنك استدعائها واستخدامها يدويًا خارج الإطار السابق كما في المثال التالي: from transformers import load_tool tool = load_tool("text-to-speech") audio = tool("This is a text to speech tool") الأدوات المخصصة بالرغم من توفر العديد من الأدوات الجاهزة في منصة Hugging Face إلّا أن الإمكانية متاحة أمامك لإنشاء أدوات مخصصة لاحتياجات عملك ومشاركتها على المنصة بسرعة وبسهولة. بعد الانتهاء من برمجة الأداة ارفع شيفرتها البرمجية إلى المنصة أو إلى مستودع النموذج الخاص بك، وستتمكن بعدها من استخدامها مع أي وكيل agent، وهذه بعض الأمثلة عن أدوات مخصصة موجودة في قسم huggingface-tools على منصة Hugging Face وهي مستقلة عن مكتبة Transformers: تحميل النصوص Text downloader: تحميل نص من عنوان URL معين. تحويل النص إلى صورة Text to image: توليد صورة بناءً على النص المُدخل في الموجه prompt، وذلك باستخدام نموذج الذكاء الاصطناعي stable diffusion. تحويل الصور Image transformation: تكون المدخلات صورة مبدئية، وموجه prompt بتعديلها، ويجري تعديل الصورة بناءً على الموجه prompt، وذلك باستخدام تعليمات pix2pix stable diffusion. تحويل النص إلى فيديو Text to video: يُنشئ مقطع فيديو صغير بناءً على الموجه prompt المقدم له، وذلك بالاستفادة من damo-vilab. بالمناسبة إن أداة تحويل النص إلى صورة text-to-image التي استخدمناها في أمثلة المقال هي أداة بعيدة مستضافة على منصة Hugging Face على الرابط huggingface-tools/text-to-image، وستجد العديد من الأدوات الأخرى المستضافة هناك. يمكنك الاطلاع على دليل إنشاء الأدوات المخصصة لتتعرف أكثر على طريقة إنشاء الأدوات ومشاركتها، علمًا أن الوكلاء agents يتمتعون تلقائيًا بصلاحية الوصول إلى كافة الأدوات الموجودة على Hugging Face. توليد الشيفرة البرمجية Code generation استخدمنا في أمثلتنا السابقة الوكلاء agents لتنفيذ الإجراءات دون أي تدخل منا، فالوكيل يوّلِد الشيفرة البرمجية ثم تُنَفَّذ هذه الشيفرة باستخدام مُفَسِّر بايثون المحدود، وبالتالي إذا رغبت باستخدام الشيفرة البرمجية الموَّلدة بأي طريقة أخرى، يمكنك ذلك عبر مطالبة الوكيل بإرجاع الشيفرة البرمجية الناتجة جنبًا إلى جنب مع تعريف الأداة المستخدمة وعمليات الاستيراد imports الدقيقة. فالتعليمة المبينة أدناه على سبيل المثال: agent.run("Draw me a picture of rivers and lakes", return_code=True) تُرجع الشيفرة التالية التي تستطيع تعديلها وتنفيذها يدويًا حسب ما تريد: from transformers import load_tool image_generator = load_tool("huggingface-tools/text-to-image") image = image_generator(prompt="rivers and lakes") الخلاصة تعرفنا في هذا المقال على الوكلاء agents والأدوات tools والأساليب المختلفة لاستخدامها في تحويل أوامر اللغة الطبيعية إلى تعليمات برمجية لتوليد الصور والنصوص والفيديوهات أو لترجمتها أو تلخيصها أو تحويلها حالة إلى أخرى، وتعلمنا أيضًا أننا أحرار في طريقة الاستفادة من هذه التعليمات البرمجية الناتجة، فيمكننا تركها لتُنَفَّذْ تلقائيًا أو استعراضها وتنفيذها يدويًا أو حتى استخدامها في أغراضٍ أخرى في برامج أوسع مثلًا أو غير ذلك. وفي الختام ندعوك لمتابعة مقالنا التالي حول توليد النصوص باستخدام النماذج اللغوية الكبيرة LLMs لتعزز معرفتك أكثر بهذا المجال الحيوي. ترجمة -وبتصرف- لقسم Transformers Agents من منصة Hugging Face. اقرأ أيضًا المقال السابق: تدريب المًكيَّفات PEFT Adapters بدل تدريب نماذج الذكاء الاصطناعي بالكامل بناء تطبيق بايثون يجيب على أسئلة ملف PDF باستخدام الذكاء الاصطناعي تطوير تطبيق 'اختبرني' باستخدام ChatGPT ولغة جافاسكربت مع Node.js مصطلحات الذكاء الاصطناعي للمبتدئين
  10. تساهم مشاركة نماذج الذكاء الاصطناعي مع الآخرين في نشر المعرفة، وتوفير الوقت والموارد على الراغبين باستثمارها وبالأخص على المستخدمين الجدد، إذا كنت تتابع معنا هذه السلسلة عن مكتبة المحولات Transformers مفتوحة المصدر من منصة Hugging Face فقد تعلمت كيفية صقل Fine-Tune نموذج ذكاء اصطناعي مُدَرَّبْ مُسبقًا باستخدام كل من PyTorch و Keras وأيضًا كيفية تسريع تدريبه بواسطة التدريب الموزع والمكتبة Accelerate، وستتعلم الآن كيف تشاركه مع المجتمع. سواء كنت قد دَرَّبتَ نموذجك من الصفر أو استخدمت نموذجًا مُسبق التدريب وصقلته fine-tune على بيانات محددة فلديك طريقتين لمشاركته على مستودع نماذج Hugging Face المسمى Model Hub: رفع الملفات إلى المستودع برمجيًا. رفع الملفات إلى المستودع بطريقة السحب والإفلات من واجهة الويب للمستودع. ميزات مستودع النماذج Model Hub يتمتع كل مستودع repository في مستودع النماذج Model Hub بكافة المميزات الخاصة بمستودعات GitHub التقليدية، مثل: توفر نظام التحكم بالإصدارات versioning، وسجل تتبع التعديلات commit history، وإمكانية العرض المرئي للاختلافات بين الإصدارات visualize differences وغيرها. يعتمد نظام التحكم بالإصدار versioning المُضَمَّنْ في مستودع النماذج على كل من git و git-lfs، فتستطيع التعامل مع النموذج على أنه مستودع مستقل، يزيد ذلك من قدرتك على التوسع، ويمنحك تحكمًا أكبر بإمكانية الوصول للنماذج، كما يسمح نظام التحكم بالإصدار بالمراجعات revisions أي تثبيت إصدار محدد من النموذج وتمييزه بعلامةٍ خاصة قد تكون رمزًا commit hash أو وسمًا tag أو فرعًا من المستودع branch. بالنتيجة يمكنك تحديد إصدار النموذج الذي تريده باستخدام المعامل revision: model = AutoModel.from_pretrained( "julien-c/EsperBERTo-small", revision="v2.0.1" # tag name, or branch name, or commit hash ) تُعَدَّل ملفات المستودع بسهولة، ويمكنك مشاهدة التعديلات التي طرأت عليعا والاختلافات التي أحدثتها في النموذج بمرونة تامة، كما في الصورة التالية: إعداد متطلبات العمل تحتاج إلى بيانات الاعتماد الخاصة بك على منصة Hugging Face قبل مشاركة أي نموذج على مستودع النماذج، إذا كنت تملك وصولًا لنافذة الطرفية terminal، فاكتب الأمر التالي ضمن البيئة الافتراضية التي أنشأناها عند تثبيت مكتبة المُحوّلات Transformers وبمجرد تنفيذه ستُخَزَّن بيانات اعتمادك المتمثلة برمز الدخول access token في مجلد الذاكرة المخبئية الخاص بمنصة Hugging Face (وهو المجلد /‎~/.cache افتراضيًا): huggingface-cli login أما إذا كنت تستخدم دفترًا للملاحظات notebook عبر الويب مثل: Jupyter أو Colaboratory فاحرص في البداية على تثبيت المكتبة huggingface_hub التي تسمح لك بالتفاعل البرمجي مع مستودع النماذج: pip install huggingface_hub ثم استخدم notebook_login كما يلي لتسجيل الدخول إلى مستودع النماذج، واتبع بعدها الخطوات الخاصة بتوليد رمز الدخول token لتستخدمه: >>> from huggingface_hub import notebook_login >>> notebook_login() تحويل النموذج ليعمل مع أي إطار عمل ننصحك بإنشاء نقطتي تحقق checkpoints لنموذجك قبل رفعه إلى المستودع واحدة باستخدام إطار العمل PyTorch وأخرى باستخدام TensorFlow، يُسَهِّل هذا الأمر استفادة الآخرين من النموذج بصرف النظر عن إطار العمل الذي يستخدمونه. ونشير هنا إلى المستخدمين سيظلون قادرين على تحميل نموذجك بأي إطار عمل يرغبون به حتى إذا تجاوزت هذه الخطوة ولم تحوّل نموذجك، لكنهم سيعانون عندها من بعض البطء في التحميل، لأن المحوّلات Transformers ستُحَوّل النموذج إلى صيغة تناسب إطار عملهم في أثناء التحميل فيزداد الوقت المستغرق له. أما تحويل نقطة التحقق الخاصة بنموذجك من إطار العمل الذي تعتمده إلى إطار عمل آخر فيُعَدُّ إجراءً سهلًا سنتعلمه معًا، لكن تأكد في البداية من تثبيت إطاري العمل باي تورش PyTorch وتنسرفلو TensorFlow (يمكنك مراجعة مقال تثبيت مكتبة المحوّلات Transformers من هذه السلسلة على أكاديمية حسوب لتتعرف على خطوات التثبيت)، ثم ابحث عن نموذج مهمتك في إطار العمل الآخر الذي ستحول نموذجك إليه لتتأكد أنه متوافق معه. تحويل نقطة التحقق من TensorFlow إلى PyTorch عبر ضبط قيمة المعامل from_tf=True وفق التالي: >>> pt_model = DistilBertForSequenceClassification.from_pretrained("path/to/awesome-name-you-picked", from_tf=True) >>> pt_model.save_pretrained("path/to/awesome-name-you-picked") تحويل نقطة التحقق من PyTorch إلى TensorFlow عبر ضبط قيمة المعامل from_pt=True كما يلي: >>> tf_model = TFDistilBertForSequenceClassification.from_pretrained("path/to/awesome-name-you-picked", from_pt=True) ثم احفظ نموذج TensorFlow الجديد بنقطة تحققه الجديدة: >>> tf_model.save_pretrained("path/to/awesome-name-you-picked") وإذا كان النموذج مدعومًا في Flax يمكنك تحويله من PyTorch إلى Flax وفق التالي: >>> flax_model = FlaxDistilBertForSequenceClassification.from_pretrained( "path/to/awesome-name-you-picked", from_pt=True ) رفع النموذج إلى المستودع في أثناء التدريب يُعدّ رفع النماذج ومشاركتها على المستودع عملًا بسيطًا يماثل إضافة معامل أو رد نداء callback أو غيره من الخيارات المألوفة، فهو في نهاية الأمر أحد معاملات التدريب التي نُحددها ضمن الصنف TrainingArguments كما تعلمنا في مقال صقل Fine-Tune نموذج ذكاء اصطناعي مُدَرَّبْ مُسبقًا فكل ما عليك فعله هو ضبط المعامل Push_to_hub=True في الصنف TrainingArguments كما في الخطوات التالية، وسيُرفَع نموذجك مباشرةً إلى المستودع: >>> training_args = TrainingArguments(output_dir="my-awesome-model", push_to_hub=True) نُمَرِّر هذه الخيارات الآن إلى المُدَرِّب Trainer: trainer = Trainer( model=model, args=training_args, train_dataset=small_train_dataset, eval_dataset=small_eval_dataset, compute_metrics=compute_metrics, ) وبعد الانتهاء من صقل fine-tune النموذج نستدعي الدالة call push_to_hub()‎ بواسطة المُدَرِّب Trainer لرفعه إلى مستودع النماذج، وستُضيف مكتبة المحوّلات Transformers تلقائيًا معلومات النموذج إلى بطاقة الوصف الخاصة به، وهي تتضمن مثلًا: المعاملات الفائقة hyperparameters للنموذج، ونتائج تدريبه، وإصدارات إطار العمل التي يعمل عليها وما إلى ذلك: trainer.push_to_hub() وفي إطار العمل TensorFlow يمكنك مشاركة النماذج على المستودع بواسطة الدالة PushToHubCallback مع إضافة الخيارات التالية: مجلد خرج النموذج. المُرَمِّز tokenizer. مُعَرِّف النموذج على المستودع hub_model_id وهو يتكون من اسم المستخدم مالك النموذج username واسم النموذج. وستكون الأوامر كما يلي: >>> from transformers import PushToHubCallback >>> push_to_hub_callback = PushToHubCallback( output_dir="./your_model_save_path", tokenizer=tokenizer, hub_model_id="your-username/my-awesome-model" ) ثم أضف رد نداء callback للدالة fit وفق التالي وسترفع المحوّلات Transformers نموذجك إلى المستودع: >>> model.fit(tf_train_dataset, validation_data=tf_validation_dataset, epochs=3, callbacks=push_to_hub_callback) استخدام الدالة push_to_hub يمكنك بدلًا من استخدام الطريقة السابقة استدعاء الدالة push_to_hub وتمرير اسم النموذج المطلوب رفعه إلى المستودع. حَدِّدْ اسم النموذج ضمن push_to_hub وفق التالي: >>> pt_model.push_to_hub("my-awesome-model") سينشأ الآن مستودعًا repository للنموذج على مستودع النماذج لمنصة Hugging Face يكون تحت اسمك، ويُسمى باسم النموذج وهو في مثالنا my-awesome-model، ويمكن للمستخدمين الآخرين بعد ذلك تحميله بواسطة الدالة from_pretrained كما يلي: >>> from transformers import AutoModel >>> model = AutoModel.from_pretrained("your_username/my-awesome-model") أما إذا كنت تنتمي لمؤسسة لديها حساب على Hugging Face وتريد رفع نموذجك تحت اسم المؤسسة فأضف مُعَرِّف مستودع المؤسسة repo_id مع اسم النموذج وفق التالي: >>> pt_model.push_to_hub("my-awesome-org/my-awesome-model") تساعدك الدالة Push_to_hub على رفع ملفات أخرى إلى مستودع النموذج نحو المُرَمِّز tokenizer مثلًا: >>> tokenizer.push_to_hub("my-awesome-model") أو نسخة TensorFlow من نموذج PyTorch المصقول fine-tuned كما يلي أو غير ذلك: >>> tf_model.push_to_hub("my-awesome-model") الآن عندما تفتح حسابك على منصة Hugging Face سترى المستودع الجديد الذي أنشأته، وبالضغط على تبويب الملفات Files ستستعرض جميع الملفات التي حَمَّلتها إلى المستودع. شرحنا هنا الأساسيات فقط، ولمزيد من المعلومات حول إنشاء الملفات ورفعها على مستودع Hugging Face راجع التوثيقات ذات الصلة على المنصة. تحميل النماذج من واجهة الويب الخاصة بالمستودع إذا كنت تفضل العمل مع الواجهات الرسومية بدلًا من سطر الأوامر فيمكنك استخدام واجهة مستودع Hugging Face الموجودة على الرابط huggingface.co/new لإنشاء المستودع الجديد ورفع النماذج إليه كما في الصورة التالية: بعدها أدخل المعلومات التالية المطلوبة في الصورة أعلاه وهي كالتالي: حَدِّدْ مالك المستودع owner، سواء كنت أنت بصفتك الشخصية أو أي مؤسسة تنتمي إليها. اختر اسمًا مميزًا لنموذجك، والذي سيكون اسمًا للمستودع أيضًا. حَدِّدْ خصوصية مستودعك عامًا أم خاصًا. اختر رخصة استخدام نموذجك. اضغط بعدها على تبويب الملفات Files ثم زر أضف ملف Add file وحَمِّل ملفك الجديد إلى المستودع بطريقة السحب والإفلات، وأخيرًا أضف رسالة التثبيت commit message، ألقِ نظرة على الصورة التوضيحية التالية: إضافة بطاقة وصف للنموذج Model Card تساعد البطاقات مستخدمي النماذج على معرفة مزايا كل نموذج وإمكاناته والاعتبارات الأخلاقية لاستخدامه وغير ذلك من التفاصيل، لذا احرص على إضافة بطاقة خاصة لنموذجك لترشد كل من يود الاستفادة منه أو لتعود إليها عند الحاجة؛ تُعَرَّفْ بطاقة وصف النموذج model card بواسطة الملف README.md ويمكنك إنجاز الأمر بطريقتين: إنشاء الملف README.md وتحميله يدويًا. الضغط على زر تحرير بطاقة النموذج Edit model card من الواجهة الرسومية لمستودعك. ألق نظرة على بطاقة وصف النموذج DistilBert على سبيل المثال، واطَّلِع على المعلومات التي تتضمنها عادةً بطاقات النماذج، كما يفيدك أيضًا استعراض قسم التوثيقات الخاص ببطاقات النماذج على منصة Hugging Face لتعرف المزيد عن الخيارات المرتبطة بالملف README.md مثل البصمة الكربونية للنموذج model’s carbon footprint (التي تقيس استهلاك الطاقة المستخدمة في تشغيل الحواسيب اللازمة لتدريب النموذج، أو اختباره وتشغيله)، وبعض الأمثلة عن الأدوات الملحقة به widget examples. الخلاصة تعلمنا في هذا المقال كيفية مشاركة نماذج الذكاء الاصطناعي على مستودع Hugging Face بعدة طرق برمجيًا وعبر واجهة الويب الرسومية لمستودع النماذج، برمجيًا لدينا طريقتين استخدام الدالة push_to_hub أو إضافة المعامل Push_to_hub=True إلى معاملات التدريب، أما عبر واجهة الويب فيمكنك إنشاء حسابك على المنصة ورفع نموذجك ببضع نقرات بسيطة، والنقطة الأهم أنك تستطيع تحويل النموذج إلى أطر العمل المختلفة قبل مشاركته على المستودع، وذلك بخطوات بسيطة عرضناها في المقال، فتُسهل على الآخرين تحميله بالصيغة التي يفضلونها مثل: PyTorch أو TensorFlow أو Flax، ولا تنسَ إضافة بطاقة وصف دقيقة للنموذج توضح للراغبين بتحميله إمكاناته وخصائصه وشروط استخدامه. ترجمة -وبتصرف- لقسم Share a model من توثيقات Hugging Face. اقرأ أيضًا المقال السابق: تدريب المًكيَّفات PEFT Adapters بدل تدريب نماذج الذكاء الاصطناعي بالكامل. تعرف على أهم مشاريع الذكاء الاصطناعي مكتبات وأطر عمل الذكاء الاصطناعي: القوة الكامنة خلف الأنظمة الذكية المعالجة المُسبقة للبيانات قبل تمريرها لنماذج الذكاء الاصطناعي
  11. نناقش في مقال اليوم طريقة استخدام توابع PEFT أو ما يعرف باسم توابع المعاملات الفعالة لصقل النماذج Parameter-Efficient Fine Tuning methods، وهي نوعٌ خاص من التوابع يُلغي أو يجمًد فعالية المعاملات الأصلية للنماذج المُدَرَّبة مسبقًا أثناء التدريب، ويستبدلها بمجموعة أصغر من المعاملات الخاصة بالمُكيّفات adapters ليجري تدريبها على المهمة المطلوبة بدلًا من تدريب النموذج كاملًا. توفر هذه الطريقة استخدام الذاكرة والموارد الحاسوبية المختلفة بشكل كبير لأن المكيّفات adapters المُدَرَّبة باستعمال توابع PEFT صغيرة الحجم مقارنة بالنماذج الكاملة، وهذا يجعلها أسهل في التحميل والتخزين والمشاركة، وهي تعطي النتائج نفسها التي نحصل عليها بتدريب كامل النموذج. ما هي المكيفات Adapters؟ المكيفات adapters هي بدائل خفيفة الوزن لتحسين نماذج الذكاء الاصطناعي المدربة مسبقًا pre-trained والمصقولة fine-tuned، فبدلاً من ضبط النموذج بالكامل، تُضاف المكيفات adapters بهيئة تعديلات صغيرة بين طبقات النموذج بعد مراحل معينة، وعند التدريب تُجَمَّدْ جميع أوزان النموذج وتُحدَّث أوزان المكيفات فقط وهو ما يؤدي إلى توفير كبير في الموارد الحاسوبية وتسريع التدريب وتحسين الأداء. ألقِ نظرة على الصورة التالية مثلًا فهي مأخوذة من مستودع النماذج، ولاحظ الفرق بين حجم مكيف النموذج OPTForCausalLM وبين حجم النموذج نفسه، إذ يبلغ حجم المكيف adapter حوالي 6 ميجا بايت بينما يصل حجم النموذج الأساسي إلى 700 ميجا. كما سيفيدك الاطلاع على PEFT إذا كنت مهتمًا بمعرفة المزيد من التفاصيل عنها. إعداد بيئة العمل ابدأ بتثبيت المكتبة PEFT من خلال الأمر التالي: pip install peft وإذا رغبت باستثمار مزاياها الحديثة أولًا بأول ثَبِّتها من المصدر الأساسي كما يلي: pip install git+https://github.com/huggingface/peft.git توافق نماذج PEFT مع مكتبة المحوّلات Transformers تدعم مكتبة المحوّلات Transformers عددًا من توابع PEFT تلقائيًا، فيمكنك تحميل أوزانها weights بسهولة سواء كانت مخزنة محليًّا أو في مستودع النماذج، ويمكن تدريبها وتشغيلها ببضع أسطر برمجية فقط، وهذه أبرزها: Low Rank Adapters. IA3. AdaLoRA. أما إذا رغبت باستخدام توابع أخرى مع مكتبة المحولات Transformers مثل: Prompt Learning و Prompt tuning فراجع توثيقات PEFT. تحميل PEFT Adapter يساعدك الصنف AutoModelFor وأصناف أخرى مشابهة على تحميل نماذج PEFT adapter من مكتبة المحوّلات Transformers واستخدامها في مشروعك، لكن تأكد من وجود الملف adapter_config.json وأوزان adapter في مجلدك المحلي أو المستودع البعيد Hub كما هو موضوح في الصورة السابقة. على سبيل المثال يمكنك تحميل نموذج PEFT adapter لمهمة النمذجة اللغوية السببية causal language modeling التي تمكنك من التنبؤ بالكلمة التالية في سلسلة نصية معينة بناءً على الكلمات السابقة باتباع التالي: حدد المُعَرِّف الخاص بنموذج PEFT الذي تريده (أي PEFT model id). مَرِّرْ هذا المُعَرِّف إلى الصنف AutoModelForCausalLM. from transformers import AutoModelForCausalLM, AutoTokenizer peft_model_id = "ybelkada/opt-350m-lora" model = AutoModelForCausalLM.from_pretrained(peft_model_id) يمكنك تحميل PEFT adapter أيضًا باستخدام الصنف AutoModelFor والصنف OPTForCausalLM والصنف LlamaForCausalLM كما يمكنك تحميله أيضًا بواسطة التابع load_adapter كما يلي: from transformers import AutoModelForCausalLM, AutoTokenizer model_id = "facebook/opt-350m" peft_model_id = "ybelkada/opt-350m-lora" model = AutoModelForCausalLM.from_pretrained(model_id) model.load_adapter(peft_model_id) التحميل بصيغة 8 بت أو 4 بت يمكنك الاستفادة من مكتبة bitsandbytes لتقليل استهلاك الذاكرة عن طريق تحميل النماذج باستخدام أنواع بيانات 8 بت و 4 بت، يساعدك هذا على توفير الذاكرة وتسريع تحميل النماذج الكبيرة، حيث يمكنك استخدام المعامل الذي تريده سواء كان load_in_8bit أو load_in_4bit ضمن محددات الدالة from_pretrained()‎ لتختار طبيعة تحميل نموذجك، ويمكنك أيضًا ضبط المعامل device_map="auto"‎ لتوزيع حمل النموذج بكفاءة على الموارد الحاسوبية المتاحة لك، وذلك وفق التالي: from transformers import AutoModelForCausalLM, AutoTokenizer peft_model_id = "ybelkada/opt-350m-lora" model = AutoModelForCausalLM.from_pretrained(peft_model_id, device_map="auto", load_in_8bit=True) تحميل adapter جديد يمكنك تعزيز إمكانيات نموذج الذكاء الاصطناعي من خلال تحميل مُكيَّف adapter إضافي لأي نموذج يحتوي على مُكيَّف adapter سابق لكن يشترط أن يكون من نفس نوع المُكيَّف الحالي الموجود مسبقًا في النموذج، كأن يكونا كلاهما من النوع LoRA مثلًا، وتُنجز ذلك باستخدام ‎~peft.PeftModel.add_adapter كما في المثال التالي: هذه الشيفرة الأصلية لتحميل مُكيَّف LoRA adapter لنموذج الذكاء الاصطناعي: from transformers import AutoModelForCausalLM, OPTForCausalLM, AutoTokenizer from peft import LoraConfig model_id = "facebook/opt-350m" model = AutoModelForCausalLM.from_pretrained(model_id) lora_config = LoraConfig( target_modules=["q_proj", "k_proj"], init_lora_weights=False ) model.add_adapter(lora_config, adapter_name="adapter_1") والآن سنضيف إليها السطر التالي لتحميل مُكيَّف LoRA adapter إضافي: # إضافة adapter جديد بنفس الإعدادات تمامًا model.add_adapter(lora_config, adapter_name="adapter_2") ثم سنستخدم ‎~peft.PeftModel.set_adapter لنُحدد أي adapter هو المعتمد في النموذج: # استخدام adapter_1 model.set_adapter("adapter_1") output = model.generate(**inputs) print(tokenizer.decode(output_disabled[0], skip_special_tokens=True)) # استخدام adapter_2 model.set_adapter("adapter_2") output_enabled = model.generate(**inputs) print(tokenizer.decode(output_enabled[0], skip_special_tokens=True)) طريقة تفعيل adapter معين أو إلغاء تفعيله يبين المثال التالي طريقة تفعيل adapter module: from transformers import AutoModelForCausalLM, OPTForCausalLM, AutoTokenizer from peft import PeftConfig model_id = "facebook/opt-350m" adapter_model_id = "ybelkada/opt-350m-lora" tokenizer = AutoTokenizer.from_pretrained(model_id) text = "Hello" inputs = tokenizer(text, return_tensors="pt") model = AutoModelForCausalLM.from_pretrained(model_id) peft_config = PeftConfig.from_pretrained(adapter_model_id) # تهيئة الأوزان العشوائية peft_config.init_lora_weights = False model.add_adapter(peft_config) model.enable_adapters() output = model.generate(**inputs) وهذه طريقة إلغاء التفعيل: model.disable_adapters() output = model.generate(**inputs) تدريب PEFT adapter يمكنك تدريب PEFT adapters على المهمة التي تريدها باستخدام صنف المُدَرِّب Trainer ببضع أوامر برمجية فقط، ألقِ نظرة على المثال التالي لتدريب LoRA adapter: 1. حدد ضمن إعدادات adapter المهمة التي تود تدريبه عليها، والمعاملات الفائقة hyperparameters الخاصة به وفق التالي، (يمكنك التَعرُّف على المعاملات الفائقة للنوع LoRA adapter واستخداماتها باستعراض تفاصيل ‎~peft.LoraConfig😞 from peft import LoraConfig peft_config = LoraConfig( lora_alpha=16, lora_dropout=0.1, r=64, bias="none", task_type="CAUSAL_LM", ) 2. أضِفْ adapter إلى النموذج: model.add_adapter(peft_config) 3. مَرِّرْ النموذج إلى المُدَرِّب: trainer = Trainer(model=model, ...) trainer.train() وفي النهاية احفظ adapter بعد التدريب وحَمِّله مجددًا كما يلي: model.save_pretrained(save_dir) model = AutoModelForCausalLM.from_pretrained(save_dir) زيادة طبقات إضافية قابلة للتدريب إلى PEFT adapter مَرِّرْ modules_to_save ضمن إعدادات PEFT لصقل fine-tune أي مُكيَّفات تود إضافتها إلى نموذجك الذي يحتوي في الأساس على adapters أخرى، كما في المثال التالي الذي يبين طريقة صقل lm_head فوق نموذج يحتوي في الأساس على LoRA adapter: from transformers import AutoModelForCausalLM, OPTForCausalLM, AutoTokenizer from peft import LoraConfig model_id = "facebook/opt-350m" model = AutoModelForCausalLM.from_pretrained(model_id) lora_config = LoraConfig( target_modules=["q_proj", "k_proj"], modules_to_save=["lm_head"], ) model.add_adapter(lora_config) الخلاصة تعرفنا في هذا المقال على المكيفات adapters وهي وحدات صغيرة تعوض عن تدريب نماذج الذكاء الاصطناعي الكاملة فتُحسِّن الأداء، وتعلمنا كيفية تحميل PEFT Adapters وإضافتها إلى نماذج مكتبة المحولات Transformers وتدريبها، وأيضًا تعرفنا على طريقة إضافة أكثر من مكيف adapter إلى النموذج لتحسين كفاءته بشرط أن تكون جميعها من نوعٍ واحد، مع إمكانية تفعيلها أو إلغاء تفعيلها حسب الحاجة. ترجمة -وبتصرف- لقسم Load adapters with PEFT من توثيقات Hugging Face. اقرأ أيضًا المقال السابق: استخدام التدريب الموزع ومكتبة Accelerate لتسريع تدريب نماذج الذكاء الاصطناعي مكتبات وأطر عمل الذكاء الاصطناعي: القوة الكامنة خلف الأنظمة الذكية خوارزميات الذكاء الاصطناعي تدريب نموذج ذكاء اصطناعي على تلخيص النصوص باستخدام سكربتات Transformers
  12. كوبرنيتس Kubernetes هو نظام فعّال ومفتوح المصدر لإدارة التطبيقات المغلفة داخل الحاويات والمبنية في بيئة عنقودية (Clustered environment)، طوّرته في البداية شركة جوجل ثم حظي بدعم مؤسسة CNCF أو Cloud Native Computing Foundation، وهدفه الأساسي توفير طرق مرنة لإدارة الخدمات والمكونات الموزعة في بنية تحتية متنوعة التقنيات. فإذا كنت تتساءل ما هو Kubernetes؟ وما مكوناته الأساسية وما المشكلات التي يحلّها؟ وأي نموذج يعتمد في نشر التطبيقات وتوسعتها؟ فسيُجيبك هذا المقال على كل تساؤلاتك تلك. ما هو Kubernetes؟ كوبرنيتس Kubernetes في الأساس هو نظام لتشغيل التطبيقات المغلفة في الحاويات وتنسيقها ضمن بيئة عمل مكونة من عدة خوادم. وقد صُممت منصة Kubernetes لإدارة دورة حياة التطبيقات والخدمات المغلفة في الحاويات إدارةً كاملة وبطرق فعالة تجعلها قابلة للتنبؤ، وسهلة التوسعة، وعالية التوافرية. يُمَكِّنُك كوبرنيتس Kubernetes من تحديد كيفية تشغيل تطبيقاتك، وطريقة تفاعلها مع التطبيقات الأخرى ومع المصادر الخارجية، ويمنحك القدرة على توسيع مواردها الحاسوبية أو إنقاصها حسب الحاجة، ويسهل إجراء التحديثات التدريجية rolling updates بسلاسة دون انقطاع الخدمة، وتبديل حركة مرور البيانات بين إصداراتها المختلفة لاختبار الميزات الجديدة أو للتراجع عن عمليات النشر المصحوبة بالأخطاء أو غير ذلك. وتأتي إمكاناته هذه مما يوفره لمستخدميه من واجهات استخدام، ومنصة قوية قابلة للبناء حسب تفضيلاتهم، ومختلف الأساسيات التي يحتاجونها ليُنشئوا بيئات تطبيقاتهم كما يريدون بمرونة وموثوقية عالية. ولمزيد من المعلومات حول تقنية كوبرنتيس Kubernetes والاطلاع على أكثر الأسئلة شيوعًا حولها تتصحك بمطالعة الفيديو التالي: بنية Kubernetes سنتعرّف على بنية Kubernetes وطريقة تصميمها وتنظيمها لنفهم إمكاناته الكبيرة التي يوفرها للمطورين. يشبه Kubernetes نظامًا مكوّنًا من عدة طبقات، وتُجَرِّد كل طبقة منه التعقيدات الموجودة في الطبقات الأدنى منها. سبيل المثال تتضمن كائنات Pod (التي تمثل أصغر وحدة في Kubernetes والتي سنشرحها بعد قليل) عدة حاويات، وتشير الخدمة (Service) إلى عدة كائنات Pod وتوفر نقطة وصول واحدة إليها وقِس على ذلك، فيخفف هذا التجريد على المطوّر كمية التفاصيل التي عليه التعامل معها، فنحن هنا نتعامل مع مفاهيم منطقية دون أن نربطها بآلة فيزيائية أو افتراضية معينة. يضم Kubernetes في قاعدته عنقودًا cluster من الآلات الفيزيائية أو الافتراضية (VMs) يجمعها مع بعضها شبكة اتصال مشتركة، ويُعدّ هذا العنقود المنصة الفيزيائية التي تُضبَط فيها جميع مكونات Kubernetes، وإمكاناته، وأحمال العمل workloads، ويُقصد بأحمال العمل هنا تطبيقك الذي ستُشغله ضمن الحاوية سواء كان تطبيق ويب أو أي نوع آخر من التطبيقات. تتمتع كل آلة ضمن العنقود بدورٍ خاص في نظام Kubernetes. ويعمل خادم واحد (أو مجموعة خوادم في عمليات النشر التي تتطلب توافرية عالية) دور الخادم الرئيسي master server، فيكون بمثابة بوابة العنقود أو عقله المُدبِّر، ويؤدي مهامًا مثل: إتاحة واجهة برمجة التطبيقات Kubernetes API للمستخدمين والعملاء، والتحقق من سلامة الخوادم الأخرى وتقسيم العمل عليها (بعملية تسمى "الجدولة scheduling")، بالإضافة إلى تنظيم الاتصال بين مكونات العنقود (أو ما يُعرف بتنسيق الحاويات container orchestration). إذًا فالخادم الرئيسي هو نقطة الاتصال الأساسية مع عنقود Kubernetes والمسؤول عن معظم أعماله المركزية. تدعى الآلات الأخرى في العنقود عقدًا nodes: وهي مجموعة خوادم مسؤولة عن استقبال أحمال العمل workloads وتشغيلها باستخدام الموارد الحاسوبية المتوفرة لها المحلية والخارجية. وتُجَهَّز كل عقدة ببرنامج لتشغيل الحاويات مثل دوكر Docker أو روكيت rkt، إذ إن Kubernetes يُشغِّل التطبيقات والخدمات ضمن حاويات containers ليؤمن لها المستويات المرجوة من العزل والمرونة والإدارة الفعالة، وتتلقى العقدة تعليمات العمل الخاصة بها من الخادم الرئيسي، فتُنشئ بناءً عليها حاوياتٍ جديدة أو تُدمِّر حاوياتٍ أخرى، وتُعدِّل قواعد المرور عبر الشبكة لتُوجّه حركة البيانات حسب المطلوب. تعمل التطبيقات والخدمات على العنقود وهي ضمن الحاويات (كما ذكرنا أعلاه)، وتتأكد المكونات الأساسية باستمرار من توافق الحالة المرغوبة للتطبيقات مع الحالة الفعلية للعنقود. أما المستخدمون فيتفاعلون مع العنقود عبر الاتصال مع خادم Kubernetes API الرئيسي مباشرةً أو بواسطة تطبيقات العملاء clients والمكتبات البرمجية. والخطوة الأولى التي يبدأ بها تشغيل أي تطبيق أو خدمة هي إعداد خطة تصريحية declarative plan بصيغة JSON أو YAML تتضمن ما ينبغي إنشاؤه لتشغيل التطبيق، وكيف سيُدّار. ثم يُحلل الخادم الرئيسي هذه الخطة، ويحدد أنسب الطرق لتشغيلها على البنية التحتية المتوفرة له، وذلك عبر فحص المتطلبات اللازمة والحالة الحالية للنظام والموازنة بينهما. وتمثل مجموعة التطبيقات التي خصصها المستخدم لتعمل وفق خطة محددة الطبقة الأخيرة في نظام Kubernetes. يجعل هذا النهج التصريحي من إدارة التطبيقات المعقدة أكثر سهولة وقابلية للتوسع ويسمح للمطورين بالتركيز على وصف ما يريدونه، بينما يتولى كوبرنيتس Kubernetes تفاصيل التنفيذ. مكونات الخادم الرئيسي Master Server يتحكم الخادم الرئيسي بعناقيد Kubernetes، ويؤمن نقطة اتصال رئيسية لمدراء الأنظمة administrators والمستخدمين، ويوفر العديد من الأنظمة لإدارة العقد العاملة worker nods الأقل منه تطورًا على نطاق العنقود. بالعموم، تؤدي مكونات الخادم الرئيسي مجموعةً من الوظائف أبرزها: قبول طلبات المستخدمين، وتحديد أفضل الطرق لجدولة حاويات أحمال العمل workload containers، وإجراء المصادقة بين العملاء والعقد، وضبط قواعد التوجيه والوصول الشبكي على مستوى العنقود، وإدارة مهام التوسعة والتحقق من سلامة النظام. تُثبَّت مكونات الخادم الرئيسي (التي سنذكرها تاليًا) على خادم واحد أو على عدة خوادم حسب الحالة. المَخزَّن العام للإعدادات etcd يُعدّ المَخزَّن العام للإعدادات واحدًا من أهم المكونات الضرورية لعمل عنقود Kubernetes، يوفره مشروع etcd الذي أنشأه فريق تطوير CoreOS (وهو نظام التشغيل الموجه للحاويات ويمكنك معرفة المزيد عنه بقراءة مقدّمة إلى مكونات نظام CoreOS). و etcd هو نظام لتخزين ملفات الإعدادت وإدارتها بشكل موزع، وهو عبارة عن مَخزَنَ قيم-مفاتيح موزّع على المستوى العام لنظام Kubernetes، ويتصف بأنه خفيف في استخدام الموارد، ويمكن تهيئته لتمرير الإعدادات بين عدة عقد. إذ يُخزِّن Kubernetes بيانات الإعدادات التي يُسمح لكل عقدة بالوصول إليها في مَخزَّن etcd. وتستخدم مكونات Kubernetes هذه البيانات لاكتشاف الخدمة المطلوبة، وتهيئة نفسها للعمل حسب المعطيات الجديدة، وتساهم أيضًا في الحفاظ على حالة العنقود بواسطة ميزات، مثل: اختيار القائد leader election، والقفل الموزع distributed locking وغيرها. وتجري عملية تعيين القيم أو استردادها بواسطة واجهة برمجة تطبيقات HTTP/JSON API بسيطة تجعل العملية سلسة وواضحة. يمكن بناء etcd على خادم رئيسي واحد أو جعله موزعًا على عدة آلات في بعض بيئات الإنتاج، والشرط الوحيد هو توفر اتصال شبكي يصله بجميع آلات العنقود. خادم kube-apiserver API خادم API من أهم الخدمات المحورية على الخادم الرئيسي لعنقود Kubernetes، ويُعدّ نقطة الإدارة الرئيسية للعنقود بأكمله فهو يسمح للمستخدم بإعداد أحمال العمل والوحدات التنظيمية، والتحقق من توافق تفاصيل الخدمة على الحاويات المنشورة مع البيانات الموجودة في مخزَّن etcd. يمكنك النظر إلى خادم API مثل جسر يصل المكونات ببعضها، ويعمل للحفاظ على سلامة العنقود، ولنقل المعلومات والأوامر عبره. يطبق هذا الخادم واجهة برمجة تطبيقات من نوع RESTful API، وتضع شهرتها الواسعة العديد من المكتبات والأدوات في أيدي مستخدمي Kubernetes لتيسير عليهم التخاطب مع خادم API. يتوفر لخادم kube-apiserver عميلٌ افتراضي يدعى kubectl يتيح لك الاتصال مع عنقود Kubernetes من حاسبك المحلي. مدير التحكم kube-controller-manager مدير التحكم controller manager هو خدمة عامة تتولى عدة مسؤوليات ضمن العنقود، أولها إدارة المتحكمات المختلفة التي تنظم حالة العنقود، وإدارة دورات حياة حمل العمل workload، بالإضافة لبعض المهام الروتينية الأخرى. فعلى سبيل المثال: يفحص متحكم النظائر replication controller عدد النظائر المحددة لكائن pod معين (أي عدد تكراراته أو النسخ المماثلة له)، ويتأكد أن هذا العدد مطابقٌ للعدد الفعلي المنشور حاليًا على العنقود. تُكتب تفاصيل العمليات جميعها في etcd، ويراقب مدير التحكم التغييرات التي تطرأ على المعلومات ضمنه بواسطة خادم API. عندما يحدث أي تغيير، يقرأ المتحكم المعلومات الجديدة، ويُطبق الإجراءات اللازمة للوصول إلى الحالة المطلوبة، فقد يعمل مثلًا على توسيع نطاق التطبيق أو تقليصه، أو على ضبط نقاط الوصول الخاصة به endpoints أو غير ذلك. المُجَدّوِل kube-scheduler الجدولة هي ربط أحمال العمل بالعقد؛ فتحدد خدمة المُجَدّوِل ما ستُنفذه كل عقدة. تقرأ الخدمة متطلبات تشغيل كل حمل عمل، وتُحلل مواصفات بيئة البنية التحتية الحالية المتوفرة، وبناءً على ذلك تقرر أي عقد أو مجموعة عقد هي المقبولة لتنفيذ العمل. يتتبع المُجَدّوِل الإمكانات المتاحة على كل مضيف، ليضمن أن أحمال العمل لم تُجَدول على العقد بطريقة خاطئة تتعارض مع الموارد المتاحة. وبالتالي يعرف المُجَدّوِل في كل لحظة الموارد الإجمالية المتوفرة والموارد المخصصة حاليًّا لأحمال العمل. مدير التحكم السحابي cloud-controller-manager نظام Kubernetes قابلٌ للنشر في بيئات متعددة، ويمكنه التعامل مع خدمات البنى التحتية لمزودين مختلفين، فيأخذ معلومات عن حالة الموارد الحاسوبية التي توفرها للعنقود ويديرها حسب متطلباته. ولكونه يتعامل مع تمثيلات عامة للموارد الحاسوبية مثل: موازنات الحمل Load Balancers والحجوم التخزينية وغيرها، فإنه يحتاج لربط map هذه التمثيلات بالموارد الفعلية التي يوفرها له مزودو الخدمات السحابية المتعددون. وهنا تبرز أهمية مدير التحكم السحابي، إذ يسمح لنظام Kubernetes بالتخاطب مع مزودي خدمات مختلفين في المزايا والإمكانات وواجهات API، مع الحفاظ على بنيته الداخلية عامة نوعًا ما بالرغم من تنوع الخدمات السحابية التي يتعامل معها. يعطي ذلك Kubernetes القدرة على تحديث معلومات الحالة لديه بناءً على المعلومات التي يوفرها له المزود السحابي، ويستخدمها لضبط الموارد السحابية المخصصة له لتلبي متغيرات العمل، فقد يُنشئ مثلًا خدمات سحابية إضافية عندما تزداد احتياجات العمل المطلوبة من العنقود. مكونات خادم العقدة Node Server العقد Nodes في Kubernetes هي الخوادم التي تعمل عليها حاويات التطبيق؛ تتطلب العقد بعض الضروريات لتؤدي أعمالها في التخاطب مع مكونات الخادم الرئيسي، وضبط إعدادات الاتصال الشبكي للحاويات، وتشغيل أحمال العمل التي يكلفها بها الخادم الرئيسي. بيئة تشغيل الحاوية Container Runtime بيئة تشغيل الحاوية Container Runtime من أهم مكونات العقدة، ودوكر Docker هو من أشهر بيئات التشغيل المعتمدة، لكنه ليس الوحيد، إذ يوجد بدائل له أخرى مثل rkt المطُور من قبل CoreOS وكان يُعتبر بديلاً أكثر أماناً وقابلية للتحكم مقارنة بدوكر و runc وهو مكون منخفض المستوى يستخدمه دوكر نفسه لتنفيذ الحاويات. تتولى أدوات بيئة تشغيل الحاوية عمليات بدء تشغيل الحاويات وإدارتها، والحاويات Containers هي تطبيقات خفيفة مغلفة في بيئة تشغيل معزولة، وتُعدّ المكون الأساسي في وحدات عمل عنقود Kubernetes، فتشتمل كل وحدة عمل على حاوية واحدة ينبغي نشرها أو أكثر حسب متطلبات المشروع. وعندما ترد أحمال العمل إلى العنقود تعمل بيئة تشغيل الحاوية على تشغيل الحاويات المطلوبة لتنفيذ العمل. نقطة اتصال العقدة kubelet نقطة اتصال العقدة kubelet هي صلة الوصل التي تربط كل عقدة ببقية أجزاء العنقود. وهي خدمة صغيرة تنقل المعلومات ذهابًا وإيابًا بين العقدة وخدمات مستوى التحكم على الخادم الرئيسي، وتتخاطب أيضًا مع مخزن الإعدادات etcd لقراءة بيانات العمل منه أو كتابة بيانات جديدة فيه. تتواصل kubelet مع مكونات الخادم الرئيسي لإتمام عملية المصادقة بين العقدة والعنقود، وللحصول على الأوامر وتفاصيل الأعمال المُسندة إليها، والتي تردها بصيغة بيان manifest أو خطة تحدد حمل العمل المطلوب ومعطيات parameters التشغيل. تحافظ kubelet على حالة العمل على العقدة، وتتحكم ببيئة تشغيل الحاوية لإنشاء الحاويات أو تدميرها حسب الحاجة. الوكيل kube-proxy يستخدم الوكيل لإدارة الشبكات الفرعية داخل المضيف، وجعل الخدمات متاحة بين المكونات، وهو خدمة صغيرة تدعى kube-proxy توجد على كل عقدة، توجه الطلبات الواردة إليها إلى الحاوية المسؤولة عن تنفيذها، وتجري نوعًا مبسطًا من موازنة الحمل Load Balancing، وتضمن أن سلوك الشبكة قابلًا للتنبؤ به، وأنها متاحة أو معزولة حيث ينبغي ذلك. كائنات Kubernetes وأحمال العمل يستخدم Kubernetes طبقات تجريد abstraction إضافية فوق الحاويات -التي تُعدّ الآلية الرئيسية لنشر التطبيقات المغلفة containerized applications- توفر هذه التجريدات للمستخدمين ميزات المرونة والتوسع وإدارة دورة الحياة، فبدلًا من تعاملهم مع الحاويات مباشرةً يتفاعلون مع المثيلات instances التي تتألف من مجموعة مكونات أولية يوفرها نموذج عمل كائن Kubernetes، سنعرض في هذه الفقرة كائنات Kubernetes وكيفية استخدامها للتعامل مع أحمال الحمل. الكائنات Pods الكائن Pod هو أصغر وحدة تنظيمية يتعامل معها عنقود Kubernetes، تتكون من حاوية أو مجموعة حاويات، فعند الإعداد لا نخصص الحاويات على مضيف معين، إنما نشير إليها بكائن Pod الذي تنتمي إليه. تمثل الحاويات الموجودة في Pod واحد تطبيقًا واحدًا أي أنها تعمل معًا بارتباطٍ وثيق، فتتشارك دورة الحياة، وتُجدّوَل أعمالها على عقدة واحدة، وتُدار بصفتها وحدة واحدة، وتتقاسم بيئة التشغيل والموارد مثل: المساحات التخزينية وعناوين IP. فِكِّر دائمًا بالكائن Pod على أنه تطبيق واحد متجانس بالرغم من تعدد حاوياته، لتفهم كيف يتعامل معه العنقود، ويُدّير موارده، ويُجدّول مهامه. يحتوي كل Pod على حاوية رئيسية لا غنى عنها تلبي الهدف العام من حمل العمل workload، وقد يحتوي حاويات أخرى اختيارية تؤدي مهامًا مساعدة حسب احتياجات مشروعك، تتضمن الحاويات المساعدة عادةً برامج مستقلة تعمل وتُدار فيها باستقلالية لكنها ترتبط بالمشروع بطريقة أو بأخرى، لذا توضع معه في كائن Pod واحد. على سبيل المثال: قد يتضمن Pod معين حاويةً رئيسية لتشغيل خادم التطبيق، وحاويةً مساعدة تتحسس لأي تغييرات تحدث على مستودع خارجي متعلق به، وتسحب الملفات المرتبطة منه إلى نظام الملفات المشترك داخل Pod. لا يُنصح عادةً بالتوسع الأفقي على مستوى كائنات Pods إذ تترك هذه المهمة عادة لكائنات أخرى بمستوى أعلى. لا يُدّير المستخدمون عمومًا كائنات Pods بأنفسهم، فهي لا توفر لهم المميزات التي غالبًا ما يحتاجونها لإدارة تطبيقاتهم، مثل: الإدارة المتقدمة لدورة حياة التطبيق أو إدارة عمليات التوسعة Scaling، وبالمقابل تشجعهم بنية Kubernetes على استخدام كائنات بمستوى أعلى، تستخدم بدورها كائنات Pods أو قوالب Pods لتأدية الوظائف. متحكمات النظائر ومجموعات النظائر يعمل معظم من يستخدم Kubernetes مع نظائر متعددة للكائنات Pods مطابقة لها تمامًا، بدلًا من التعامل مع Pods مفردة. تُنشئ هذه النظائر انطلاقًا من قوالب Pod، وتوسعها أفقيًا متحكماتٌ خاصة تدعى متحكمات النظائر Replication Controllers ومجموعات النظائر Replication Sets. متحكم النظائر replication controller هو أحد كائنات Kubernetes، مسؤول عن تحديد قالب Pod الذي ستُبنى النظائر انطلاقًا منه، وأيضًا عن تحديد معطيات التحكم التي تُمَكِّنهُ من إدارة التوسعة الأفقية لنظائر Pod فيزيد عدد النظائر قيد التشغيل أو ينقصها حسب الحاجة. تمثل هذه العملية طريقةً سهلة لموازنة الحمل وتحسين التوافرية availability داخل نظام Kubernetes، فالقالب الذي ستنشئ منه النظائر الجديدة، والذي يشبه إلى حدٍ كبير تعريف للكائن Pod، يكون مضمنًا embedded في إعدادات متحكم النظائر. يتأكد متحكم النظائر باستمرار من تطابق عدد Pods المنشورة فعليًّا على العنقود مع العدد المطلوب والمحدد في إعدادته. وفي حال فشل أي Pod أو مضيف، سيستجيب المتحكم على الفور، ويبدأ بتشغيل Pods جديدة لتعويض النقص. أما إذا طرأ أي تغيير على عدد النظائر المحدد في إعداداته بالزيادة أو النقصان فسيُشغِّل المتحكم حاويات جديدة أو يدمر الحاويات الموجودة أصلًا ليصل للعدد المطلوب. يؤدي متحكم النظائر أيضًا مهمة التحديثات التدريجية rolling updates فيَنقُل مجموعة Pods إلى الإصدار الجديد بالتتابع واحدًا تلو الآخر حتى لا يسبب انقطاع كلي للخدمة فيؤثر على توافرية التطبيق. مجموعات النظائر Replication sets تتمتع بتصميم مشابه لتصميم متحكم النظائر، مع مرونة أكبر في آلية تعريف المتحكم لكائنات Pods التي سيُدِّيرها. يتسع نطاق الاعتماد على مجموعات النظائر على حساب متحكمات النظائر، بسبب إمكاناتها الكبيرة في اختيار النظائر، لكنها بالمقابل قاصرة عن إجراء التحديثات التدريجية للتطبيق وترقية واجهاته الخلفية إلى إصدار جديد كما تفعل متحكمات النظائر، فقد صممت مجموعات النظائر لتعمل في وحدات تنظيمية أخرى أعلى منها مستوى تؤدي هذه المهمة. تمامًا مثل Pods، تُعدّ متحكمات النظائر ومجموعات النظائر وحداتٍ أولية في نظام Kubernetes وناردًا ما يتعامل معها المستخدم العادي، رغم أنها توفر لتطبيقاته التوسعة الأفقية والوثوقية في العمل، إلَا أنها تفتقر لمميزات إدارة دورات الحياة بطريقة سلسة يفضلها المستخدمون والموجودة في مكونات Kubernetes الأكثر تعقيدًا. النشر Deployments يُعدّ النشر Deployments واحدًا من أشهر أحمال العمل التي تُنشئ وتُدار مباشرةً على Kubernetes. تستخدم عمليات النشر مجموعات النظائر بوصفها كتلة بناء أو مكون أساسي تُبنى منه، وهذا ما يمنح مجموعات النظائر المرونة التي تفتقدها في إدارة دورة الحياة. للوهلة الأولى قد تبدو لك عمليات النشر deployments المكونة من اجتماع عدد من مجموعات النظائر مشابهة في وظائفها لمتحكمات النظائر، إلّا أنها في الواقع تعالج العديد من نقاط ضعفها في إطلاق التحديثات. فعند استخدام المتحكمات ينبغي عليك إعداد خطة لمتحكم النظائر الجديد الذي سيحل محل المتحكم الحالي، وستكون أعمال كثيرة مثل: سجلات تتبع الأحداث، واستعادة التطبيق في حال طرأ عطل في الشبكة، والتراجع عن التحديث rolling back، عملياتٍ صعبة التنفيذ أو تلقى مسؤوليتها على المستخدم. إذًا فالنشر Deployments هو كائن عالي المستوى، ومصمم لتسهيل إدارة دورة حياة نظائر Pods، وهو أكثر الكائنات التي ستعمل معها مباشرةً في Kubernetes، إذ يمكنك تعديله بسهولة حسب ما تريد فكل ما يتطلبه الأمر تعديل إعداداته، وبعدها سيضبط Kubernetes مجموعات النظائر replica sets بناءً على إعداداتك، ويدير الانتقالات بين إصدارات التطبيق مع تفعيل اختياري لميزات مثل: سجل تتبع الأحداث والتراجع الآلي عن التحديث وغيرها. مجموعات الحالة Stateful sets مجموعات الحالة Stateful sets هي pod تحكم متخصصة نوعًأ ما، تضمن ترتيب طلبات إنشاء Pods في مجموعة الحالة، وأن يمتلك كل Pod في هذه المجموعة معرفًا فريدًا خاصًا به. وتوفر للمستخدمين تحكمًا دقيقًا في المشاريع ذات المتطلبات الخاصة سواءً على صعيد النشر أو الاستقرار الشبكي أو وجود البيانات الدائمة Persistent data التي تبقى متاحة لوقت طويل دون تغيير. فغالبًا ما ترتبط مجموعات الحالة بالتطبيقات الموجهة للبيانات، مثل قواعد البيانات التي تتطلب وصولًا دائمًا لوحدات التخزين نفسها في جميع الظروف حتى إذا أُعِيدَت جدولتها على عقدة جديدة. توفر مجموعات الحالة مُعرِّفًا شبكيًا ثابتًا لكل Pod، هو اسمٌ عددي فريد يشير إلى Pod بعينها دائمًا حتى إذا انتقلت إلى عقدة أخرى. والأمر نفسه مع وحدات التخزين الدائمة التي تنتقل مع Pod إن أُعِيدَت جدولتها لسبب ما. علماً أن وحدات التخزين الدائمة هذه تبقى موجودة ولا تحذف تلقائيًا مع حذف Pod لمنع الفقدان غير المقصود للبيانات. تنفذ مجموعات الحالة العمليات المناطة بها في أثناء النشر أو ضبط التوسعة وفقًا للمُعرِّف الفريد، ويعزز ذلك إمكانية التنبؤ والتحكم بترتيب التنفيذ، ويُعدّ مفيدًا في بعض المشاريع ذات الطبيعة الخاصة. مجموعات برامج التشغيل الخلفية Daemon Sets مجموعات البرامج الخفية Daemon sets هي نموذج متخصص آخر من متحكمات pod التي تُشَغِّل نسخة من pod معين على كل عقدة (أو مجموعة عقد مترابطة) في العنقود. وتبرز فائدتها عند نشر Pods الخدمية لعقد Kubernetes مثل Pods الصيانة وغيرها. فعلى سبيل المثال تُعدّ خدمات نحو: جمع ملفات تسجيل الأحداث وإعادة توجيهها، وتنظيم المقاييس، وتشغيل الخدمات التي تزيد من إمكانات العقد وغيرها، حالات شائعة للاستفادة من مجموعات البرامج الخفية. ولا تخضع مجموعات البرامج الخفية لقيود الجدولة المفروضة على pods العادية والتي تربطها بمضيفين معينين، ذلك أنها تقدم خدمات أساسية ومطلوبة في كامل نظام Kubernetes حتى **على الخادم الرئيسي، الذي يُعدّ محظورًا على المجدول بسبب مسؤولياته الخاصة، إلّا أن مجموعات البرامج الخلفية تتجاوز هذه القيود لتتأكد من سلامة تشغيل الخدمات الرئيسية. المهام Jobs والمهام الدورية Cron Jobs تتصف معظم أحمال العمل التي أوردناها في المقال بدورة حياة طويلة الأمد تشبه دورة حياة الخدمة، لكن Kubernetes يستخدم أيضًا نوعًا آخر من أحمال العمل يسمى المهام jobs لتأمين سير عمل أشبه بالمأمورية المؤقتة task-based تخرج فيه الحاوية من الخدمة بعد مضي بعض الوقت وانتهاء مهمتها. تساعدك كائنات المهام Jobs على تنفيذ العمليات التي لا تتطلب تشغيل خدمات دائمة، مثل: العمليات الدفعية batch أو العمليات التي تُجرى لمرة واحدة. تُبنى المهام الدورية cron jobs على المهام jobs. وهي تماثل جدولة المهام بتقنية cron في لينكس وغيره من أنظمة يونيكس المشابهة التي تُنَفَذ بموجبها السكربتات وفقًا لجدول زمني محدد، إذ توفر المهام الدورية في Kubernetes واجهة لتشغيل المهام بواسطة المجدول (مكون الخادم الرئيسي الذي ذكرناه سابقًا). تستخدم المهام الدورية لضبط تنفيذ مهمة معينة بوقت محدد في المستقبل، سواء لمرة واحدة أو لتكرار تنفيذها بانتظام. ويمكنك النظر إلى المهام الدورية في Kubernetes على أنها تطبيق لمهام cron التقليدية ولكن على منصة كاملة هي العنقود بدلًا من نظام تشغيل منفرد. مكونات أخرى لنظام Kubernetes يوفر Kubernetes عددًا من التجريدات إضافةً إلى أحمال العمل تساعدك على إدارة تطبيقاتك، والتحكم بالشبكات، وتأمين الاستمرارية وغير ذلك، سنناقش بعضًا منها أدناه: خدمات Kubernetes استخدمنا مصطلح "خدمة service" بالمعنى التقليدي كما في أنظمة يونيكس، أي للدلالة على العمليات طويلة الأمد، والتي غالبًا ما تتصل بالشبكة، وتستجيب للطلبات. إنما في Kubernetes تعمل الخدمة بصفتها موازن حمل أساسي داخلي ومرسال لوحدات pods. وتجمع الخدمة مجموعات منطقية من pods التي تؤدي الوظيفة نفسها، وتقدمها بوصفها كيان واحد. يمكنك مثلًا نشر خدمة لتتبع الحاويات الخلفية من نوع معين وتوجيه الطلبات إليها. علمًا أن كل ما يحتاج المستهلكون الداخليون لمعرفته عن الخدمة هو نقطة النهاية الثابتة التي توفرها فقط دون أي تفاصيل أخرى، يتيح لك هذا التجريد توسيع نطاق وحدات العمل العاملة في الخلفية أو استبدالها حسب الحاجة، وسيبقى عنوان IP المخصص للخدمة ثابتًا بصرف النظر عن أي تغيير يطرأ على pods المرتبطة به. يكسبك نشر الخدمات قابلية الاكتشاف ويبسيط تصميم حاوياتك. تفيدك الخدمات في الحالات التي تحتاج فيها للوصول إلى pods تطبيق آخر أو للاتصال مع مستهلكين خارجيين. فعلى سبيل المثال: إذا كان لتطبيقك عددٌ من pods العاملة على خوادم الويب ويتصل بها العملاء عن طريق الإنترنت، فإن بناء خدمة خاصة بهذه الحالة سيوفر لك التجريد اللازم. وهذا مثال آخر: لنفترض أن خوادم الويب في مشروعك بحاجة لتخزين البيانات واستردادها في قاعدة بيانات معينة، فيمكنك تأمين وصولها إلى pods قاعدة البيانات عبر بناء خدمة داخلية تتكفل بالأمر. خدمات Kubernetes متاحة افتراضيًا داخل العنقود بعنوان IP الخاص بها، وإذا أردت طلبها من الخارج فيمكنك تحقيق ذلك بعدة طرق، تتمثل إحداها بفتح منفذ ثابت static port خاص بالخدمة على واجهة الشبكة الخارجية لكل عقدة، ثم توجيه حركة المرور الواردة إليه تلقائيًا إلى عنوان IP الداخلي للخدمة، وبالتالي إلى pods المناسبة. تسمى هذه الطريقة NodePort. أو يمكنك استخدام خدمة خاصة من نوع موازن حمل LoadBalancer تُنشئ لك موازن حمل خارجي يوجه حركة البيانات نحو الخدمة الداخلية المقصودة، تُنَفَذ هذه الطريقة باستخدام تكامل موازن الحمل الخاص بمزود Kubernetes السحابي، إذ ينشئ مدير التحكم السحابي الموارد اللازمة ويربطها بعناوين خدمة موازن الحمل التي تشير لخدمتنا الداخلية المقصودة. وحدات التخزين ووحدات التخزين الدائمة تُعدّ مشاركة البيانات بين أكثر من حاوية مشاركةً موثوقة، والحفاظ عليها وضمان توفرها بين عمليات إعادة تشغيل الحاويات، تحدّيًا كبيرًا في العديد من بيئات الحاويات. وتوفر بعض بيئات تشغيل الحاويات آليات خاصة ترتبط وحدات التخزين بالحاوية، وتحافظ عليها بعد انتهاء عمر الحاوية، لكن هذه الآليات تفتقد غالبًا للمرونة في التنفيذ العملي. يستخدم Kubernetes تجريدًا خاصًا لمعالجة هذا التحدّي يدعى وحدات التخزين volumes، يسمح للحاويات المغلفة في pod واحد بمشاركة البيانات فيما بينها، والإبقاء عليها متاحة لحين انتهاء عمل pod، وحتى إذا فشلت حاوية معينة أو توقفت لسبب من الأسباب فالبيانات المشتركة ستبقى قابلة للوصول طالما أن pod موجود، وعند إنهاء عمله يُحذف المجلد المشترك. يُسهّل ذلك مشاركة الملفات بين عناصر pod الواحد دون الحاجة لأي آليات خارجية معقدة، لكنه لا يُعدّ حلًا مناسبًا للبيانات الدائمة التي لا تتعلق بعمر pod بل تستمر بعدها. لذا يوفر Kubernetes تجريدًا أقوى لتخزين البيانات الدائمة، يسمى وحدات التخزين الدائمة Persistent volumes، لا يرتبط بدورة حياة pod، ويسمح لمديري النظام بإعداد موارد التخزين على مستوى العنقود ليتمكن المستخدمون من حجزها لكائنات pod التي يُشغِّلونها حسب تفضيلاتهم. ويحدد كل مستخدم سياسة الاسترداد الخاصة به، التي تقرر فيما إذا كانت وحدة التخزين وبياناتها ستُحذف يدويًا من قبله أم آليًّا عند انتهاء عمر pod. يخفف استخدام وحدات التخزين الدائمة من المخاطر المترتبطة بحالات فشل العقدة، ويساعدك على زيادة مساحات التخزين المخصصة لصالح مشروعك عمّا هو متاحٌ له محليًّا على المضيف. التعليقات التوضيحية Annotations والتسميات التوضيحية Labels التسميات التوضيحية label هي تجريد تنظيمي في Kubernetes ينظم المفاهيم الأخرى في النظام ويوضحها، وهي علاماتٌ دلالية ترفق بكائنات Kubernetes لوسمها بوسمٍ خاص يشير لانتمائها لمجموعة معينة، أي أنها تُستَخدم لتصنيف الكائنات ولاستهداف مثيلات مختلفة لأغراض الإدارة أو التوجيه أو غيرها، فمثلًا تعتمد الخدمات على التسميات التوضيحية لمعرفة pods الواجهة الخلفية التي ينبغي توجيه الطلبات إليها، وكذلك الأمر مع كائنات التحكم التي تستعمل التسميات التوضيحية لتحديد pods التي ستعمل عليها. تُوضع التسميات التوضيحية بهيئة أزواج مفتاح-قيمة، ويمكن أن تحظى الوحدة التنظيمية عدة لصائق، لكنها لا تحمل أبدًا إلّا بقيمة واحدة لكل مفتاح. ومفتاح "الاسم name" هو أشهر المفاتيح، ويُعدّ مُعَرِّفًا عامًا متعدد الأغراض، يمكنك أيضًا تصنيف الكائنات وفق معايير أخرى حسب احتياجات عملك، مثل: مرحلة التطوير، وإمكانية الوصول العام، وإصدار التطبيق… إلخ. تشبه **التعليقات التوضيحية Annotations ** التسميات التوضيحية لكنها تترك لك الحرية في إرفاق أي تعليق تريده ضمن خانة القيمة للدلالة على الكائن ما دون الالتزام بمعايير محددة، في حين تفرض عليك التسميات التوضيحية قواعد معينة في كتابة المعلومات الدلالية لتجري مطابقتها عند اختيار pod. باختصار تساعدك التعليقات التوضيحية في إضافة بيانات تعريفية غنية للكائن لكنها لا تفيدك في تصنيفه أو تحديده لأمرٍ معين. الخلاصة يتيح Kubernetes لمستخدميه تشغيل مشاريعهم المغلفة في الحاويات على منصة قوية وعالية التجريد، وبطريقة تكفل لهم قابلية التوسع والتوافرية العالية. وعندما تبدأ بالتعرف عليه ستبدو لك بنيته معقدة، ويصعب التعامل معها، لكن ما أن تفهم أساسياتها وكيفية توافق عناصرها معًا ستشعر بمرونتها وفائدتها الكبيرة للمشاريع مفتوحة المصدر والتطوير السحابي الأصلي، وبمزيد من التدريب ستصبح قادرًا على استثمار ميزاتها المتنوعة لتشغيل أحمال العمل وإدارتها على نطاق واسع، ولإنشاء تطبيقاتك السحابية الأصلية. ترجمة -وبتصرف- للمقال ?What is Kubernetes لصاحبه Justin Ellingwood. اقرأ أيضًا تعلم أساسيات Kubernetes نشر تطبيق جانغو آمن وقابل للتوسيع باستخدام كوبيرنتس Kubernetes مدخل إلى Kubernetes ما الفرق بين دوكر Docker وكوبيرنيتيس Kubernetes؟
  13. يُعدّ التدريب الموزع أو التدريب على التوازي استراتيجيةً ناجحة في تدريب نماذج الذكاء الاصطناعي كبيرة الحجم على أجهزة حاسوبية محدودة الموارد، ويزداد الاعتماد عليها يومًا بعد يوم مع ازدياد أحجام النماذج المطروحة، وفي هذا المجال توفر منصة Hugging Face لمستخدميها مكتبةً متخصصة تدعى Accelerate تُسَهِّل عليهم تدريب نماذج مكتبة المحولات Transformers تدريبًا موزعًا بأنواعٍ مختلفة من الإعدادات مثل استخدام عدة وحدات معالجة رسومية (GPU) سواء كانت موجودة على الجهاز نفسه أو موزعة على عدة أجهزة، فكيف نطبق هذا الأسلوب عمليًّا على حلقات تدريب PyTorch الأصلي للاستفادة منه في تدريب نماذج الذكاء الاصطناعي في البيئات الحاسوبية ذات الموارد الموزعة؟ إعداد بيئة العمل ابدأ أولًا بتثبيت المكتبة Accelerate كما يلي: pip install accelerate ثم استورد كائن المُسَرِّع Accelerator وأنشئ واحدًا في مشروعك، وسيكتشف المُسَرِّع نوعية الإعدادات الموزعة المتوفرة لديك ويهيئ لك المكونات الضرورية للتدريب اعتمادًا عليها، ولا حاجة لتخزين النموذج على جهازك: >>> from accelerate import Accelerator >>> accelerator = Accelerator() التحضير لعملية التسريع Accelerate خطوتنا التالية هي تمرير كافة الكائنات المرتبطة بالتدريب إلى تابع التحضير accelerator.prepare والتي تشمل مُحَمِّلات البيانات DataLoaders لكل من مرحلتي التدريب training والتقييم evaluation بالإضافة إلى النموذج model والمُحَسِّن optimizer على النحو التالي: train_dataloader, eval_dataloader, model, optimizer = accelerator.prepare( train_dataloader, eval_dataloader, model, optimizer ) ملاحظة: إن مهمة التابع prepare هنا هي تجهيز جميع مكونات التدريب للعمل في بيئة موزعة، وضمان توافق جميع المكونات مع بعضها البعض. استبدال الدالة Backward وأخيرًا علينا استبدل الدالة loss.backward()‎ المعتادة في حلقة التدريب بدالة Backward الخاصة بمكتبة Accelerate لضمان حساب التدرجات الخلفية (backward pass) بشكل صحيح على الأجهزة الموزعة على النحو التالي: for epoch in range(num_epochs): for batch in train_dataloader: outputs = model(**batch) loss = outputs.loss accelerator.backward(loss) optimizer.step() lr_scheduler.step() optimizer.zero_grad() progress_bar.update(1) إذًا يمكنك تحويل حلقة التدريب العادية إلى حلقة تدريب موزعة بإضافة أربعة أوامر برمجية فقط إلى حلقة التدريب (ميَّزناها هنا بإشارة "+")، وبحذف أمرين فقط (ميَّزناهما بإشارة "-"): + from accelerate import Accelerator from transformers import AdamW, AutoModelForSequenceClassification, get_scheduler + accelerator = Accelerator() model = AutoModelForSequenceClassification.from_pretrained(checkpoint, num_labels=2) optimizer = AdamW(model.parameters(), lr=3e-5) - device = torch.device("cuda") if torch.cuda.is_available() else torch.device("cpu") - model.to(device) + train_dataloader, eval_dataloader, model, optimizer = accelerator.prepare( + train_dataloader, eval_dataloader, model, optimizer + ) num_epochs = 3 num_training_steps = num_epochs * len(train_dataloader) lr_scheduler = get_scheduler( "linear", optimizer=optimizer, num_warmup_steps=0, num_training_steps=num_training_steps ) progress_bar = tqdm(range(num_training_steps)) model.train() for epoch in range(num_epochs): for batch in train_dataloader: - batch = {k: v.to(device) for k, v in batch.items()} outputs = model(**batch) loss = outputs.loss - loss.backward() + accelerator.backward(loss) optimizer.step() lr_scheduler.step() optimizer.zero_grad() progress_bar.update(1) التدريب بعد إضافة الأسطر البرمجية السابقة لحلقة التدريب يمكنك البدء بتدريب نموذجك إما بتشغيل السكريبت لديك أو بكتابته في Colaboratory notebook أو أي دفتر ملاحظات مشابه. التدريب باستخدام السكربت إذا كنت تُدَرِّب نموذجك اعتمادًا على سكريبت، فاكتب الأمر التالي لإنشاء ملف الإعدادات وحفظه: accelerate config ثم باشر بالتدريب بكتابة الأمر التالي: accelerate launch train.py التدريب باستخدام دفتر الملاحظات Notebook يمكنك تشغيل مكتبة Accelerate داخل دفتر ملاحظات مثل Colaboratory notebook أو غيره إذا كنت ترغب باستخدام وحدات TPU (أي وحدات معالجة الموتر أو التنسور tensor) الخاصة بخدمة Colaboratory، لكن عليك في هذه الحالة وضع جميع تعليمات التدريب في دالة واحدة وتمريرها إلى notebook_launcher كما يلي: >>> from accelerate import notebook_launcher >>> notebook_launcher(training_function) الخلاصة تعرفنا في مقال اليوم على الخطوات الأساسية لاستخدام المكتبة Accelerate في تسريع تدريب نماذج الذكاء الاصطناعي باستخدام التدريب الموزع وهي طريقة مفيدة لتدريب نماذج الذكاء الاصطناعي الكبيرة على أجهزة محدودة الموارد، ويمكنك التعمق أكثر في خياراتها المختلفة بمطالعة توثيقاتها الرسمية. ترجمة -وبتصرف- لقسم Distributed training with Accelerate من توثيقات Hugging Face. اقرأ أيضًا المقال السابق: تدريب نموذج ذكاء اصطناعي على تلخيص النصوص باستخدام سكربتات Transformers أدوات برمجة نماذج تعلم الآلة مكتبات وأطر عمل الذكاء الاصطناعي: القوة الكامنة خلف الأنظمة الذكية كيفية تهيئة تطبيق المفكرة Jupyter Notebook للعمل مع لغة البرمجة Python
  14. تزخر مكتبة المحوّلات Transformers بالسكربتات التوضيحية والأمثلة التي تشرح تدريب نماذج الذكاء الاصطناعي على مختلف المهام بأطر العمل الشهيرة بايتورش PyTorch وتنسرفلو TensorFlow و JAX/Flax، وترتبط هذه الأمثلة ببعض المشاريع البحثية والمساهمات القديمة لمجتمع Hugging Face، لكن لن تعمل هذه الأمثلة بدقة تامة في مشروعك من دون بعض التعديلات فهي في نهاية الأمر لا تخضع للصيانة والتحديث الدوري ومعظمها لا يتوافق مع الإصدارات الحديثة من مكتبة المحوّلات، لذا ستحتاج لتكييفها مع مشروعك. وبعد سحب الملف من GitHub يمكنك متابعة قراءة هذا المقال لتتعلم كيفية الاستفادة من السكربتات التدريبية الموجود على منصة Hugging Face وتكييفها لمشروعك، اخترنا هنا سكريبت بسيط لمهمة تلخيص النصوص وسنعرض طريقة التعامل معه في كل من إطاري العمل PyTorch و TensorFlow. إعداد بيئة العمل الخطوة الأولى لتشغيل أحدث إصدار من السكربتات التوضيحية بنجاح هي تثبيت مكتبة المحوّلات Transformers من المصدر في بيئة افتراضية جديدة كما يلي: git clone https://github.com/huggingface/transformers cd transformers pip install . وإذا أردت استخدام أمثلة تناسب الإصدارات القديمة من مكتبة المحوّلات Transformers مثل الإصدار v.4.5.1 يمكنك الاطلاع على الرابط وبنفس الطريقة للإصدارات الأخرى. ثم بَدِّل نسحتك من المكتبة إلى الإصدار الذي اخترته حسب المثال وليكن فرضًا الإصدار v3.5.1: git checkout tags/v3.5.1 بعد ضبط الإصدار الصحيح للمكتبة، انتقل إلى مجلد المثال الذي اخترته وثَبِّت متطلباته كما يلي: pip install -r requirements.txt تشغيل السكربت التوضيحي يبدأ السكربت بتحميل مجموعة بيانات dataset من مكتبة مجموعات البيانات Datasets ومعالجتها معالجةً مسبقة، ويستخدم بعدها المُدَرِّب Trainer لضبط مجموعة البيانات على بنية مناسبة لمهمة التلخيص summarization. يبين المثال التالي كيفية صقل النموذج T5-small وتدريبه بدقة fine-tuning على مجموعة البيانات CNN/DailyMail، لاحظ وجود الوسيط source_prefix وهو أحد متطلبات للنموذج T5 ويتيح له معرفة طبيعة المهمة التي سيستخدم لأجلها أي التلخيص في حالتنا، لنعرض السكربت الآن بإطاري العمل: أولًا باستخدام إطار العمل Pytorch: python examples/pytorch/summarization/run_summarization.py \ --model_name_or_path google-t5/t5-small \ --do_train \ --do_eval \ --dataset_name cnn_dailymail \ --dataset_config "3.0.0" \ --source_prefix "summarize: " \ --output_dir /tmp/tst-summarization \ --per_device_train_batch_size=4 \ --per_device_eval_batch_size=4 \ --overwrite_output_dir \ --predict_with_generate ثانيًا باستخدام إطار العمل TensorFlow: python examples/tensorflow/summarization/run_summarization.py \ --model_name_or_path google-t5/t5-small \ --dataset_name cnn_dailymail \ --dataset_config "3.0.0" \ --output_dir /tmp/tst-summarization \ --per_device_train_batch_size 8 \ --per_device_eval_batch_size 16 \ --num_train_epochs 3 \ --do_train \ --do_eval التدريب الموزع والدقة المختلطة يدعم المُدَرِّب ميزة التدريب الموزع distributed training أي توزيع التدريب على أكثر من وحدة معالجة، وميزة الدقة المختلطة mixed precision التي تتيح إمكانية العمل على 32 بت أو 16 بت للتسريع، يمكنك تفعيل الميزتين ضمن السكربت بضبط قيم الوسيطين التاليين: أضف الوسيط fp16 لتفعيل ميزة الدقة المختلطة. حدد عدد وحدات المعالجة الرسومية (GPUs) التي تريد استخدامها ضمن الوسيط nproc_per_node. torchrun \ --nproc_per_node 8 pytorch/summarization/run_summarization.py \ --fp16 \ --model_name_or_path google-t5/t5-small \ --do_train \ --do_eval \ --dataset_name cnn_dailymail \ --dataset_config "3.0.0" \ --source_prefix "summarize: " \ --output_dir /tmp/tst-summarization \ --per_device_train_batch_size=4 \ --per_device_eval_batch_size=4 \ --overwrite_output_dir \ --predict_with_generate أما إطار TensorFlow فيستخدم التدريب الموزع افتراضيًا باستراتيجية خاصة تدعى MirroredStrategy ويوزع العمل على كافة وحدات GPU المتوفرة للتدريب من دون الحاجة لضبط أي وسيط إضافي بهذا الخصوص ضمن السكربت. تشغيل السكربت باستخدام وحدات TPU إن تسريع الأداء هو الهدف الكامن وراء تصميم وحدات معالجة المُوترات أو التنسورات Tensors التي تدعى اختصارًا TPUs، ويساعدك مترجم التعلُّم العميق XLA compiler على استخدامها مع إطار العمل PyTorch (يمكنك معرفة المزيد عنها بمطالعة هذا الرابط). الآن افتح السكربت xla_spawn.py وحدد عدد نوى معالجة المُوترات TPU cors التي تود استخدامها بذكرها ضمن الوسيط num_cores وفق التالي: python xla_spawn.py --num_cores 8 \ summarization/run_summarization.py \ --model_name_or_path google-t5/t5-small \ --do_train \ --do_eval \ --dataset_name cnn_dailymail \ --dataset_config "3.0.0" \ --source_prefix "summarize: " \ --output_dir /tmp/tst-summarization \ --per_device_train_batch_size=4 \ --per_device_eval_batch_size=4 \ --overwrite_output_dir \ --predict_with_generate أما إطار العمل TensorFlow فيستخدم استراتيجيةً اسمها TPUStrategy لتدريب النماذج اعتمادًا على وحدات TPU، ويتعين عليك تحديد اسم المورد الحاسوبي resource الذي ستستخدمه ضمن الوسيط tpu في السكربت كما يلي: python run_summarization.py \ --tpu name_of_tpu_resource \ --model_name_or_path google-t5/t5-small \ --dataset_name cnn_dailymail \ --dataset_config "3.0.0" \ --output_dir /tmp/tst-summarization \ --per_device_train_batch_size 8 \ --per_device_eval_batch_size 16 \ --num_train_epochs 3 \ --do_train \ --do_eval تشغيل السكربت مع المكتبة Accelerate مكتبة Accelerate هي مكتبة خاصة بإطار العمل بايتورش PyTorch فقط، حيث توفر أسلوبًا موحدًا لتدريب نموذج الذكاء الاصطناعي نفسه بإعدادات مختلفة (سواء بالاعتماد على وحدة المعالجة المركزية CPU فقط، أو على أكثر من وحدة معالجة رسومية GPU، أو على وحدات معالجة الموترات TPU) مع الحفاظ على وضوح حلقة التدريب، لكن في البداية ينبغي لنا التأكد من تثبيت المكتبة Accelerate: تنويه: تتطور مكتبة Accelerate باستمرار لذا احرص على تثبيتها من مستودعها على git. pip install git+https://github.com/huggingface/accelerate سنستخدم الآن السكربت run_summarization_no_trainer.py الذي يتضمن الإعدادات الخاصة باستخدام مكتبة Accelerate بدلًا من السكربت السابق run_summarization.py، يمكنك تمييز السكربتات الخاصة بمكتبة Accelerate بوجود الملف Task_no_trainer.py ضمن مجلداتها. ابدأ بتنفيذ الأمر التالي الخاص بإنشاء ملف الإعدادات وحفظه: accelerate config ثم اختبر ملف الإعدادات للتأكد من سلامته: accelerate test أصبحنا جاهزين لبدء التدريب: accelerate launch run_summarization_no_trainer.py \ --model_name_or_path google-t5/t5-small \ --dataset_name cnn_dailymail \ --dataset_config "3.0.0" \ --source_prefix "summarize: " \ --output_dir ~/tmp/tst-summarization استخدام مجموعة بيانات مخصصة مع سكربت التلخيص يمكنك استخدام مجموعة بيانات مخصصة مع سكربت التلخيص التوضيحي الذي اخترناه هنا، بشرط أن تكون بصيغة CSV أو JSON وستحتاج أيضًا لضبط بعض الوسطاء الإضافية لتتناسب مع مجموعة بياناتك وفق التالي: يحدد كل من الملف Train_file وملف validation_file مسار حفظ ملفات التدريب والتحقق على التوالي. يشير text_columnd إلى الدخل أو النص المطلوب تلخيصه. يَدُّل على الخرج ٍSummary_column على الخرج أو النص الهدف بعد التلخيص. وستكون الصيغة النهائية لسكربت التلخيص مع استخدام مجموعة بيانات مخصصة على النحو التالي: python examples/pytorch/summarization/run_summarization.py \ --model_name_or_path google-t5/t5-small \ --do_train \ --do_eval \ --train_file path_to_csv_or_jsonlines_file \ --validation_file path_to_csv_or_jsonlines_file \ --text_column text_column_name \ --summary_column summary_column_name \ --source_prefix "summarize: " \ --output_dir /tmp/tst-summarization \ --overwrite_output_dir \ --per_device_train_batch_size=4 \ --per_device_eval_batch_size=4 \ --predict_with_generate اختبار السكربت على عينة من البيانات يُعدّ اختبار السكربتات على عينة صغيرة من مجموعة البيانات أسلوبًا ناجحًا للتأكد من صحتها وفعاليتها قبل تطبيقها على كامل البيانات، فتجريب السكربت على dataset كاملة يستغرق وقتًا طويلًا ربما ساعات قبل حصولك على النتيجة، ويساعدك الوسطاء الثلاثة الموجودين أدناه على اقتطاع جزء من مجموعة البيانات حسب قيمة كل وسيط ليُنَفَذ السكربت على جزء العينات المقتطع فقط من مجموعة البيانات بدلًا من تنفيذه على كامل المجموعة: max_train_samples. max_eval_samples. max_predict_samples. python examples/pytorch/summarization/run_summarization.py \ --model_name_or_path google-t5/t5-small \ --max_train_samples 50 \ --max_eval_samples 50 \ --max_predict_samples 50 \ --do_train \ --do_eval \ --dataset_name cnn_dailymail \ --dataset_config "3.0.0" \ --source_prefix "summarize: " \ --output_dir /tmp/tst-summarization \ --per_device_train_batch_size=4 \ --per_device_eval_batch_size=4 \ --overwrite_output_dir \ --predict_with_generate ملاحظة: لا تتيح جميع السكربتات التوضيحية الموجودة في مكتبة المحوّلات إمكانية استخدام الوسيط max_predict_samples لذا ننصحك بالتحقق أولًا من توفر هذه الإمكانية في السكربت بإضافة الوسيط h- وفق التالي: examples/pytorch/summarization/run_summarization.py -h استئناف التدريب من نقطة تحقق سابقة قد يتوقف تدريب النموذج لأسباب غير متوقعة؛ هل سبق أن تعرضت لذلك؟ يساعدك خيار استئناف التدريب من نقطة تحقق checkpoint سابقة على متابعة تدريب نموذجك من حيث توقف دون الحاجة لإعادته من البداية، ويوجد طريقتان لإجراء ذلك: سنستخدم في الطريقة الأولى الوسيط output_dir Previous_output_dir لاستئناف التدريب من أحدث نقطة تحقق متوفرة ومخزنة في المجلد output_dir، لكن علينا حذف الأمر overwrite_output_dir من السكربت في هذه الحالة: python examples/pytorch/summarization/run_summarization.py --model_name_or_path google-t5/t5-small \ --do_train \ --do_eval \ --dataset_name cnn_dailymail \ --dataset_config "3.0.0" \ --source_prefix "summarize: " \ --output_dir /tmp/tst-summarization \ --per_device_train_batch_size=4 \ --per_device_eval_batch_size=4 \ --output_dir previous_output_dir \ --predict_with_generate وفي الطريقة الثانية سيُستأنف التدريب انطلاقًا من نقطة التحقق الموجودة في مجلد محدد وذلك باستخدام الوسيط resume_from_checkpoint path_to_specific_checkpoint وفق التالي: python examples/pytorch/summarization/run_summarization.py --model_name_or_path google-t5/t5-small \ --do_train \ --do_eval \ --dataset_name cnn_dailymail \ --dataset_config "3.0.0" \ --source_prefix "summarize: " \ --output_dir /tmp/tst-summarization \ --per_device_train_batch_size=4 \ --per_device_eval_batch_size=4 \ --overwrite_output_dir \ --resume_from_checkpoint path_to_specific_checkpoint \ --predict_with_generate شارك نموذجك يمكنك أن ترفع السكربتات التوضيحية لنموذجك النهائي إلى مستودع النماذج Model Hub على منصة Hugging Face بعد انتهائك من استخدام السكربت، لكن عليك أولًا تسجيل حساب على المنصة وفق التالي: huggingface-cli login ثم إضافة الوسيط Push_to_hub إلى السكربت، يؤدي ذلك إلى إنشاء مستودع خاص بالمستخدم على Hugging Face يُسمى باسم الدخول الخاص به (أي username) مع اسم المجلد المُحدد في put_dir. يمكنك تغيير آلية التسمية واختيار الاسم الذي تريده لمستودعك باستخدام الوسيط Push_to_hub_model_id وسيُدرج تلقائيًا تحت المساحة الاسمية namespace المخصصة لك على المنصة. يبين المثال التالي طريقة تحميل النموذج إلى مستودعٍ محدد: python examples/pytorch/summarization/run_summarization.py --model_name_or_path google-t5/t5-small \ --do_train \ --do_eval \ --dataset_name cnn_dailymail \ --dataset_config "3.0.0" \ --source_prefix "summarize: " \ --push_to_hub \ --push_to_hub_model_id finetuned-t5-cnn_dailymail \ --output_dir /tmp/tst-summarization \ --per_device_train_batch_size=4 \ --per_device_eval_batch_size=4 \ --overwrite_output_dir \ --predict_with_generate الخلاصة شرحنا في مقال اليوم كيفية تدريب نموذج ذكاء اصطناعي على مهمة تلخيص النصوص باستخدام مكتبة المحولات Transformers وشرحنا خطوات إعداد بيئة العمل بداية من تثبيت هذه المكتبة من المصدر، ثم تشغيل سكربت تلخيص نصوص بسيط باستخدام إطاري عمل PyTorch و TensorFlow، كما وضحنا تقنيات تدريب وتسريع وتكييف السكربت ومشاركة النموذج المدرب على منصة Hugging Face. ترجمة -وبتصرف- لقسم Train with a script من توثيقات Hugging Face. اقرأ أيضًا المقال السابق: طريقة الصقل Fine-Tune لنموذج ذكاء اصطناعي مُدَرَّبْ مُسبقًا المعالجة المُسبقة للبيانات قبل تمريرها لنماذج الذكاء الاصطناعي تلخيص النصوص باستخدام الذكاء الاصطناعي أهم مشاريع عملية عن الذكاء الاصطناعي مصطلحات الذكاء الاصطناعي للمبتدئين
  15. يُعرّف سجل دوكر Docker Registry بأنه تطبيق يُدّير عمليات تخزين صور حاويات Docker وتسليمها للمطورين، حيث تكون صور الحاويات متاحة أمامهم في سجلٍ مركزي واحد ومُضمّن فيها جميع المكونات الضرورية لعملها، وفي هذا استثمارٌ كبير لوقت المطوّر، إذ تكفل صور دوكر بيئة تشغيل مماثلة لمتطلباته عبر المحاكاة الافتراضية، وبهذا يمكن للمطور سحب الصورة التي يحتاجها من السجل مع كل ما يلزم وتنزيلها بهيئة مضغوطة، بدلًا من تنزيل الاعتماديات والحزم واحدة واحدة وتثبيتها داخل الحاوية في كل مرة، وبالمثل أيضًا يستطيع المطوّر أتمتة عمليات نشر الصور على السجل باستخدام أدوات التكامل المستمر (CI) مثل TravisCI أو غيرها لتحديث صوره باستمرار في مراحل التطوير والإنتاج. قد تكون سجلات Docker عامة أو خاصة ولعل Docker Hub هو أبرز مثال على سجلات دوكر العامة، فهو مجاني ومتاح للجميع ويمكنك تخصيص صورك حسب احتياجات عملك واستضافتها عليه، وإذا رغبت بمستوى أعلى من السرية والخصوصية فيمكنك استخدام سجل خاص بك فهو الخيار الأفضل للتطبيقات مغلقة المصدر، إذ تتضمن الصور عادةً جميع التعليمات البرمجية اللازمة لعمل التطبيق، ويبقيها السجل الخاص في متناول مجموعة محددة من الأشخاص فقط. سنشرح لك في هذا المقال كيفية إعداد سجلك الخاص لصور حاويات Docker، وطريقة تأمينه، واستخدام كل من Docker Compose لضبط إعدادات التحكم بتشغيل الحاويات، وخادم Nginx لتوجيه حركة مرور البيانات القادمة من الإنترنت إلى حاوية Docker قيد التشغيل. وستمتلك في النهاية المعرفة الكافية لرفع صورة Docker إلى سجلك الخاص، وسحب الصور بأمان من خادمٍ بعيد. متطلبات العمل ستحتاج لتوفير المتطلبات التالية لتتابع معنا سير العمل خطوة بخطوة: خادمين مثبت عليهما نظام تشغيل أوبنتو (الإصدار 22.04 )، ويمكنك اتباع هذا الدليل لتجهيزهما، حيث يتضمن هذا الدليل طريقة إنشاء مستخدم جديد غير مستخدم الجذر لكنه يتمتع بصلاحيات sudo بالإضافة إلى آلية إعداد جدار الحماية للخادم، احرص على تنفيذ هذه الخطوات إذ سيستضيف أحد الخادمين سجل Docker الخاص بك وسنسميه الخادم المضيف host، وسيكون الخادم الآخر عميلًا client يستخدم السجل. تثبيت Docker على الخادمين، تساعدك الخطوتان 1 و 2 من مقال كيفية تثبيت دوكر واستخدامه على دبيان في تنفيذ المطلوب فتثبيت Docker على دبيان يشبه تثبيته على أوبنتو. اضبط بعد ذلك الإعدادات التالية على الخادم المضيف: ثبّت عليه دوكر كومبوزر Docker Compose مستعينًا بالخطوات الواردة في مقال تثبيت الأداة دوكر كومبوز Docker Compose واستخدامها ضمن نظام لينكس أوبونتو. ثبّت عليه إنجن إكس Nginx بإتباع الإرشادات الواردة في مقال كيفية تثبيت Nginx على أوبونتو 18.04. أمّن حماية الخادم Nginx الموجود على المضيف بشهادات مصدقة من Let’s Encrypt مثلًا لحماية سجل Docker الخاص الذي تنشؤه، اطلّع على مقال كيف تؤمّن خادم ويب NGINX على أوبنتو 16.04 على أكاديمية حسوب أو مقال تأمين خادم NGINX باستخدام Let’s Encrypt على DigitalOcean لإنجاز هذه الخطوة. وتأكد من توجيه حركة مرور البيانات الواردة إلى تطبيقك من HTTP إلى HTTPS. احجز اسم نطاق لخادمك المضيف لسجل Docker، واسم النطاق المعتمد في المقال هو your_domain، وتوفير اسم النطاق ضروري قبل البدء بإعدادات خدمة Let’s Encrypt. الخطوة 1: تثبيت سجل Docker وإعداده يفيدك تشغيل Docker من سطر الأوامر في بداية التشغيل وعند اختبار الحاويات، لكن استمرارك باستخدامه من سطر الأوامر لن يكون عمليًّا مع تقدم سير العمل، وبالأخص في عمليات النشر واسعة النطاق أو تلك التي تتطلب التحكم بعدة حاويات تعمل معًا على التوازي. لذا يستخدم المطورون أداة Docker Compose، حيث تكتب ملف yml. واحد لكل حاوية يتضمن إعداداتها والمعلومات التي تحتاجها للتواصل مع بقية الحاويات. ويمكنك استخدام تعليمة docker compose لتطبيق الأوامر دفعةً واحدة على جميع الأجزاء المكوّنة لتطبيقك والتحكم بها على أنها مجموعة. تُستخدم أداة Docker Compose أيضًا لإدارة سجل دوكر ومكوناته فهو تطبيق في نهاية الأمر ويتكون من عدة أجزاء. لتشغيل مثيل instance لسجل Docker على Docker Compose عليك إعداد الملف docker-compose.yml لتعريف السجل، وتوفير مساحة تخزينية له على القرص الصلب ليُخزّن البيانات. أنشئ في البداية مجلدًا اسمه docker-registry على الخادم المضيف وفق التالي، إذ سنُخزّن فيه إعدادات السجل: $ mkdir ~/docker-registry انتقل إلى المجلد الجديد بكتابة التالي: $ cd ~/docker-registry وأنشئ بداخله مجلدًا فرعيًّا باسم data، وفق الأمر التالي حيث سيُخزّن السجل صور الحاويات بداخله: $ mkdir data أنشئ أيضًا ملفًا نصيًّا باسم docker-compose.yml باستعمال محرر نصوص مثل نانو كما يلي: $ nano docker-compose.yml واكتب ضمنه المعلومات التالية، التي تُعرّف المثيل الأساسي لسجل Docker: version: '3' services: registry: image: registry:latest ports: - "5000:5000" environment: REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY: /data volumes: - ./data:/data لنشرح المعلومات السابقة، عرّفنا في البداية خدمةً جديدة باسم registry، وحددنا الصورة التي ستُبنى انطلاقًا منها وهي registry، أما الكلمة latest فتعني أنك تطلب استخدام أحدث إصدار متوفر من الصورة، وفي القسم التالي وجهّنا المنفذ port رقم 5000 على الخادم المضيف إلى المنفذ 5000 على الحاوية، وذلك يعني أن الطلبات الواردة إلى المنفذ 5000 على الخادم سترسل مباشرةً إلى السجل. أما في قسم بيئة العمل environment فقد أسندنا القيمة data/ للمتغير REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY وهو المسؤول عن تحديد المجلد المخصص لتخزين بيانات السجل. وفي القسم volumes وصلنا المجلد data/ على نظام ملفات الخادم المضيف بالمجلد data/ داخل الحاوية، الذي يُعدّ بمثابة معبر فقط إذ ستُخزّن البيانات فعليًّا على الخادم المضيف. احفظ التغييرات على الملف، وأغلقه وشغّل الآن الإعدادات بتنفيذ الأمر التالي: $ docker compose up سيبدأ تحميل حاوية السجل مع اعتمادياتها، وستصبح في وضع التشغيل، ثم ستحصل على خرج يشبه التالي: [+] Running 2/2 ⠿ Network docker-registry_default Created 0.1s ⠿ Container docker-registry-registry-1 Created 0.1s Attaching to docker-registry-registry-1 docker-registry-registry-1 | time="2024-01-19T14:31:20.40444638Z" level=warning msg="No HTTP secret provided - generated random secret. This may cause problems with uploads if multiple registries are behind a load-balancer. To provide a shared secret, fill in http.secret in the configuration file or set the REGISTRY_HTTP_SECRET environment variable." go.version=go1.16.15 instance.id=4fb8d420-eaf8-4a69-b740-bdc94fa52d91 service=registry version="v2.8.1+unknown" docker-registry-registry-1 | time="2024-01-19T14:31:20.404960549Z" level=info msg="redis not configured" go.version=go1.16.15 instance.id=4fb8d420-eaf8-4a69-b740-bdc94fa52d91 service=registry version="v2.8.1+unknown" docker-registry-registry-1 | time="2024-01-19T14:31:20.412312462Z" level=info msg="using inmemory blob descriptor cache" go.version=go1.16.15 instance.id=4fb8d420-eaf8-4a69-b740-bdc94fa52d91 service=registry version="v2.8.1+unknown" docker-registry-registry-1 | time="2024-01-19T14:31:20.412803878Z" level=info msg="Starting upload purge in 52m0s" go.version=go1.16.15 instance.id=4fb8d420-eaf8-4a69-b740-bdc94fa52d91 service=registry version="v2.8.1+unknown" docker-registry-registry-1 | time="2024-01-19T14:31:20.41296431Z" level=info msg="listening on [::]:5000" go.version=go1.16.15 instance.id=4fb8d420-eaf8-4a69-b740-bdc94fa52d91 service=registry version="v2.8.1+unknown" ... يتضمن الخرج السابق رسالة تحذير مفادها عدم توفر اتصال HTTP آمن No HTTP secret provided، لا تقلق سنعالجها في الفقرات القادمة. إذا دققت في السطر الأخير، ستجده يعلمك بإتمام عملية التشغيل بنجاح، وبأن السجل جاهز لاستقبال الطلبات على المنفذ 5000. يمكنك الآن الضغط على CTRL+C لإيقاف التنفيذ. إذًا فقد أنشأنا في هذه الخطوة إعدادات Docker Compose التي شغّلت سجل Docker على المنفذ 5000، وسنعمل في الخطوات التالية على استعراضه باسم النطاق المخصص له، وعلى ضبط إعدادات المصادقة Authentication للتحكم بصلاحية الوصول إليه. الخطوة 2: ضبط إعدادات التوجيه لمنفذ Nginx ذكرنا في بداية المقال أن تفعيل بروتوكول HTTPS على اسم نطاقك هو أحد متطلبات العمل الأولية، وسنعمل الآن على توجيه حركة مرور البيانات من اسم النطاق إلى حاوية السجل لنضمن أن الوصول لسجل Docker سيجري عبر اتصالٍ آمن. لابد أنك جهزت الملف etc/nginx/sites-available/your_domain/ أثناء إعدادك لخادم Nginx، إذ يحتوى هذا الملف على قسمٍ خاص بإعدادات الخادم، افتحه بواسطة أي محرر نصوص وفق التالي، لنجري عليه بعض التعديلات: $ sudo nano /etc/nginx/sites-available/your_domain ابحث ضمنه عن القسم المسمى location: ... location / { ... } ... المطلوب في حالتنا أمران: توجيه حركة مرور البيانات إلى المنفذ 5000 الذي يتلقى السجل عبره الطلبات، وإضافة ترويسات headers للطلبات الموجهة إلى السجل تحتوي معلوماتٍ إضافية عنها يضيفها الخادم. استبدل محتوى القسم location بالتالي لتنفيذهما: ... location / { # Do not allow connections from docker 1.5 and earlier # docker pre-1.6.0 did not properly set the user agent on ping, catch "Go *" user agents if ($http_user_agent ~ "^(docker\/1\.(3|4|5(?!\.[0-9]-dev))|Go ).*$" ) { return 404; } proxy_pass http://localhost:5000; proxy_set_header Host $http_host; # required for docker client's sake proxy_set_header X-Real-IP $remote_addr; # pass on real client's IP proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_read_timeout 900; } ... تتأكد الجملة if من توفر عدة شروط قبل أن تسمح للطلب بالمرور إلى السجل، فتتحقق من وكيل المستخدم صاحب الطلب User Agent، ومن كون إصدار Docker الذي يستعمله أعلى من 1.5، ومن أنه ليس تطبيق مبرمج بلغة Go ويسعى للوصول إلى السجل. يمكنك معرفة المزيد عن ترويسة nginx بمراجعة دليل إعداد Ngin لسجل Docker من توثيقات Docker الرسمية. احفظ التغييرات على الملف، وأعِد تشغيل Nginx بكتابة التعليمة التالية، حتى تأخذ التغييرات مفعولها: $ sudo systemctl restart nginx إذا حصلت على أي رسالة خطأ تفيد بعدم نجاح عملية إعادة التشغيل، فتحقق مجددًا من صحة التعديلات التي أجريتها على الملف. سنشغل السجل الآن لنتأكد من توجيه Nginx الطلبات الواردة إلى حاوية السجل، اكتب الأمر التالي: $ docker compose up استعرض العنوان التالي في متصفحك، والذي يتضمن اسم النطاق يليه v2 نقطة الوصول endpoint: https://your_domain/v2 سيعرض لك المتصفح كائن JSON فارغ على الشكل: وستحصل في الطرفية على الخرج التالي: docker-registry-registry-1 | time="2024-01-19T14:32:50.082396361Z" level=info msg="response completed" go.version=go1.16.15 http.request.host=your_domain http.request.id=779fe265-1a7c-4a15-8ae4-eeb5fc35de98 http.request.method=GET http.request.remoteaddr=87.116.166.89 http.request.uri="/v2" http.request.useragent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Safari/537.36" http.response.contenttype="text/html; charset=utf-8" http.response.duration="162.546µs" http.response.status=301 http.response.written=39 docker-registry-registry-1 | 172.19.0.1 - - [19/Nov/2022:14:32:50 +0000] "GET /v2 HTTP/1.0" 301 39 "" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Safari/537.36" docker-registry-registry-1 | 172.19.0.1 - - [19/Nov/2022:14:32:50 +0000] "GET /v2/ HTTP/1.0" 200 2 "" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Safari/537.36" docker-registry-registry-1 | time="2024-01-19T14:32:50.132472674Z" level=info msg="response completed" go.version=go1.16.15 http.request.host=your_domain http.request.id=0ffb17f0-c2a0-49d6-94f3-af046cfb96e5 http.request.method=GET http.request.remoteaddr=87.116.166.89 http.request.uri="/v2/" http.request.useragent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Safari/537.36" http.response.contenttype="application/json; charset=utf-8" http.response.duration=2.429608ms http.response.status=200 http.response.written=2 يخبرك السطر الأخير أن الطلب GET قد وصل إلى نقطة الوصول /v2/ المذكورة في العنوان الذي طلبته من المتصفح، واستقبلته حاوية السجل (بفضل إعدادات التوجيه التي عملنا عليها) وأرسلت استجابة بكائن JSON {} مع رمز الاستجابة 200 الذي يشير لنجاح العملية. اضغط الآن CTRL+C لإيقاف التنفيذ. أنهينا بذلك إعدادات التوجيه وننتقل لإعدادات تأمين السجل. الخطوة 3: ضبط إعدادات المصادقة Authentication يتيح Nginx لمستخدمه إعداد آلية مصادقة Authentication باسم مستخدم وكلمة مرور لتقييد الوصول إلى مواقعهم المستضافة عليه وذلك بإنشاء ملف مصادقة htpasswd وكتابة أسماء المستخدمين المسموح له بالوصول إليه مع كلمات مرورهم. سنستخدم هذه الآلية هنا لحماية سجل Docker. يمكنك الحصول على الأداة htpasswd بتثبيت الحزمة apache2-utils وفق الأمر التالي: $ sudo apt install apache2-utils -y سننشئ الآن المجلد docker-registry/auth/~ لتخزين ملف المصادقة الذي يتضمن بيانات الاعتماد، وفق ما يلي: $ mkdir ~/docker-registry/auth انتقل للمجلد الجديد بكتابة التالي: $ cd ~/docker-registry/auth نفذّ الأمر المبين أدناه لإنشاء المستخدم الأول، واستبدل العبارة username باسم المستخدم الفعلي، واحرص على كتابة الراية B- فهي مسؤولة عن تفعيل خاصية التشفير bcrypt التي تشترطها Docker: $ htpasswd -Bc registry.password username سيُطلب منك إدخال كلمة المرور الخاصة بهذا المستخدم، أدخلها بدقة. وستخزن بيانات الاعتماد هذه التي أدخلتها في registry.password. ملاحظة: أعِدّ تنفيذ الأمر السابق بدون الراية c- لإضافة مستخدمين آخرين إلى الملف وفق التالي: $ htpasswd -B registry.password username إذ تشير الراية c- إلى إنشاء ملف جديد، وتعني إزالتها التعديل على الملف الحالي (أي إضافة مستخدمين جدد). عدّل الآن الملف docker-compose.yml ليستخدم Docker ملف بيانات الاعتماد -الذي أنشأناه- لإجراء المصادقة مع المستخدمين للتحقق من هوياتهم. افتح أولًا الملف بكتابة التالي: $ nano ~/docker-registry/docker-compose.yml أضف الأجزاء المتعلقة بالمصادقة إلى محتواه، ليصبح كما يلي: version: '3' services: registry: image: registry:latest ports: - "5000:5000" environment: REGISTRY_AUTH: htpasswd REGISTRY_AUTH_HTPASSWD_REALM: Registry REGISTRY_AUTH_HTPASSWD_PATH: /auth/registry.password REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY: /data volumes: - ./auth:/auth - ./data:/data أضفت بهذه التعديلات بعض المتغيرات إلى متغيرات البيئة لفرض استخدام المصادقة مع بروتوكول HTTP، ولتوفير مسار الملف htpasswd. فقد حدد المتغير REGISTRY_AUTH الذي يحمل القيمة htpasswd مخطط المصادقة المستخدم أو authentication scheme، وأُسندت القيمة التي تدل على مسار ملف المصادقة إلى المتغير REGISTRY_AUTH_HTPASSWD_PATH، أما المتغير REGISTRY_AUTH_HTPASSWD_REALM فيوضح نطاق تنفيذ المصادقة htpasswd. وفي السطر ما قبل الأخير وصلت المجلد auth/. إلى داخل حاوية السجل ليكون متاحًا ضمنها. احفظ التغييرات على الملف وأغلقه. ودعنا نتأكد من استخدام السجل لإجراء المصادقة. توجه في البداية إلى مجلد السجل الأساسي بكتابة الأمر: $ cd ~/docker-registry شغّل السجل بتنفيذ ما يلي: $ docker compose up حدّث الصفحة في متصفح الويب إذا كان ما يزال مفتوحًا لديك، أو اطلب مجددًا اسم النطاق الذي حددته للسجل، ولاحظ الفرق. سيطلب منك في هذه المرة اسم مستخدم وكلمة مرور. أدخل البيانات الصحيحة وستحصل على الخرج السابق نفسه، كائن JSON فارغ كما يلي، وهو ما يشير لصحة التنفيذ: نجحت إذا عملية المصادقة وسُمح لك بالوصول للسجل بعد إدخال بيانات الاعتماد الصحيحة. يمكنك الخروج بالضغط على CTRL+C في نافذة الطرفية. خطوتنا التالية هي تحويل السجل إلى خدمة تعمل في الخلفية، وتقلع تلقائيًا، مع الإبقاء على المرونة التي تسمح لنا بإعادة تشغيلها. الخطوة 4: بدء تشغيل سجل Docker بصفته خدمة يعني تحويل سجل Docker إلى خدمة ضبط بعض الإعدادات في Docker Compose لإبقاء حاوية السجل في وضع التشغيل دائمًا، فتُقلع تلقائيًا مع إقلاع نظام التشغيل، ويُعاد تشغيلها بعد أي عطل. اكتب الأمر التالي، وافتح الملف docker-compose.yml لنجري عليه بعض التعديلات: $ nano docker-compose.yml ابحث ضمن الملف عن قسم السجل المسمى registry، واكتب تحته السطر التالي: ... registry: restart: always ... يعني ضبط المحدد restart على القيمة always أن حاوية السجل سيُعاد تشغيلها دائمًا بعد أي طارئ يسبب إيقافها. احفظ الآن التغييرات على الملف، وأغلقه لننتقل إلى الإجراء التالي. اكتب الأمر المبين أدناه لبدء تشغيل حاوية السجل بصفتها عملية تعمل في الخلفية background process، وذلك بتمرير الراية d-: $ docker compose up -d يمكنك إغلاق جلسة SSH والاطمئنان بأن حاوية السجل لن تتوقف فهي الآن تعمل في الخلفية. ستتناول الخطوة التالية زيادة حجم الملفات التي يُسمح برفعها على خادم Nginx ليناسب حجوم صور الحاويات التي ستحفظ على السجل. الخطوة 5: زيادة حجم الملفات المسموح رفعها على Nginx الحجم الأعظمي المسموح رفعه على خادم Nginx افتراضيًا هو 1m أي 1 ميجا بايت للملف الواحد، ويُعدّ صغيرًا نسبيًا موازنةً بحجوم صور الحاويات، لذا يتحتم علينا تغيره قبل البدء برفع الصور إلى السجل. يمكنك تغييره بتعديل قيمته في ملف إعدادات Nginx الموجود في المسار etc/nginx/nginx.conf/. افتح ملف إعدادات Nginx بكتابة الأمر التالي: $ sudo nano /etc/nginx/nginx.conf أضف السطر التالي إلى القسم http ضمنه: ... http { client_max_body_size 16384m; ... } ... زدنا بهذا التعديل الحجم الأعظمي للملف المسموح برفعه إلى 16 جيجا بايت، وذلك بضبط قيمة المحدد client_max_body_size على 16384m. احفظ التغييرات على الملف وأغلقه. أعِدّ تشغيل الخادم Nginx لتأخذ التغييرات مفعولها، وفق التالي: $ sudo systemctl restart nginx يمكنك الآن رفع الصور إلى السجلات بدون أي أخطاء تتعلق بالحجم من Nginx. الخطوة 6: نشر صور الحاويات على سجل Docker الخاص أصبح خادم السجل قادرًا على استيعاب الملفات كبيرة الحجم، لذا سنجرب نشر صورة تجريبية عليه، فإذا لم يتوفر لديك أي صورة لرفعها، يمكنك تحميل صورة أوبنتو من Docker Hub (سجل Docker العام) لتجرب نشرها على هذا السجل. افتح جلسة طرفية جديدة على الخادم العميل، ونفذّ الأمر المبين أدناه لتحميل صورة الحاوية ubuntu وتشغيلها (تذكر أننا طلبنا وجود خادمين ضمن المتطلبات الأولية خادم مضيف وخادم عميل): $ docker run -t -i ubuntu /bin/bash تمنحك الرايتان t- و i- واجهة صدفة shell تفاعلية لتُنفذ بواسطتها الأوامر داخل حاوية أوبنتو. أنشئ الآن ملفًا يدعى SUCCESS داخل حاوية أوبنتو وفق التالي: root@f7e13d5464d1:/# touch /SUCCESS أنشأنا هذا الملف داخل الحاوية كنوع من التخصيص لتمييزها عن غيرها، فيمكننا لاحقًا استعراضه للتأكد من استخدامنا الحاوية الصحيحة. اخرج من صدفة الحاوية بكتابة التالي: root@f7e13d5464d1:/# exit أنشئ الآن صورة عن هذه الحاوية بعد تخصيصها، بكتابة الأمر التالي: $ docker commit $(docker ps -lq) test-image أصبح لديك صورة عن حاوية أوبنتو المخصصة محفوظة محليًا على خادمك، سجِّل دخول إلى سجل Docker وفق التالي لنحاول نشرها عليه: $ docker login https://your_domain سيُطلب منك إدخال اسم مستخدم وكلمة مرور، أدخل بيانات أحد المستخدمين الذين أنشأتهم في الخطوة 3 قبل قليل، وستحصل على الخرج التالي: Login Succeeded بعد تسجيل الدخول بنجاح عدّل تسمية صورة الحاوية كما يلي: $ docker tag test-image your_domain/test-image انشرها الآن على سجلك بكتابة الأمر التالي: $ docker push your_domain/test-image وستحصل على خرج يشبه ما يلي يؤكد لك نجاح العملية: Using default tag: latest The push refers to a repository [your_domain/test-image] 1cf9c9034825: Pushed f4a670ac65b6: Pushed latest: digest: sha256:95112d0af51e5470d74ead77932954baca3053e04d201ac4639bdf46d5cd515b size: 736 إذًا فقد نشرنا صورة حاوية Docker على السجل الخاص، وتأكدنا من فعالية عملية المصادقة، إذ لم نتمكن من الوصول للسجل والنشر عليه بدون إدخال اسم مستخدم وكلمة مرور صحيحين، لنختبر الآن سحب الصور من السجل. سحب الصور من سجل Docker الخاص سنحاول سحب الصورة نفسها التي نشرتها على السجل في الخطوة السابقة. اكتب الأمر التالي، وسجل دخول إلى سجل Docker من الخادم الرئيسي باستخدام بيانات المستخدمين الذين أنشأتهم سابقًا: $ docker login https://your_domain جرّب سحب الصورة test-image من السجل كما يلي: $ docker pull your_domain/test-image حمَّل Docker الآن هذه الصورة إلى خادمك المحلي، شغّل حاوية جديدة باستخدامها عبر كتابة ما يلي: $ docker run -it your_domain/test-image /bin/bash يوفر لنا هذا الأمر صدفة shell تفاعلية مع الحاوية المُشغّلة. اكتب ضمنها الأمر التالي لنستعرض نظام ملفاتها: root@f7e13d5464d1:/# ls لاحظ الخرج التالي، إنه يتضمن الملف SUCCESS الذي أنشأناه قبلًا لتمييز صورة الحاوية قبل نشرها على السجل، وهذا يؤكد أن الحاوية المُشغّلة حاليًّا مبنية على الصورة نفسها المسحوبة من السجل: root@f7e13d5464d1:/# SUCCESS bin boot dev etc home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var اخرج الآن من صدفة الحاوية بكتابة الأمر التالي: $ exit أنهينا بذلك إنشاء سجل Docker خاص وآمن لتخزين صور الحاويات التي تخصصها حسب احتياجاتك، وجربنا معًا نشر صورة تجريبية عليه وسحبها منه إلى الخادم المحلي. الخلاصة يساعدك هذا المقال التعليمي على إنشاء سجلك الخاص لحفظ صور حاويات Docker ونشر الصور عليه بمرونة وأمان، ويمكنك أيضًا الاستفادة من بعض الأدوات الخاصة بالتكامل المستمر لأتمتة عمليات النشر عليه. وتذكر دائمًا أن اعتمادك على حاويات Docker في سير عملك يعني أن الصور التي تتضمن الشيفرات البرمجية لتطبيقاتك ستعمل دائمًا بالصورة المطلوبة نفسها على أي جهاز وفي أي بيئة العمل سواءً في مرحلة التطوير أو الإنتاج. لمزيد من المعلومات عن حاويات Docker وتفاصيل التعامل معها، وطرق كتابة ملفات Docker، ننصحك بالاطلاع على مقالات قسم Docker باللغة العربية على أكاديمية حسوب أو على توثيقات Docker الرسمية. ترجمة -وبتصرف- للمقال How To Set Up a Private Docker Registry on Ubuntu 22.04 لصاحبيه Young Kim و Savic. اقرأ أيضًا ما هي تقنية Docker؟ استخدام الأمر docker exec في حاويات Docker مدخل إلى دوكر Docker تثبيت الأداة دوكر كومبوز Docker Compose واستخدامها ضمن نظام لينكس أوبونتو
×
×
  • أضف...