كيفية البناء على جنكينز ونشر القطع الأثرية عبر ssh مع خطوط الأنابيب

في هذه المقالة ، أود أن أشارك تجربتي في نشر المشروع عن بُعد المجمعة في جنكينز وإرسالها إلى المثيل بواسطة بروتوكول SSH. أعتقد أن قراءة ما هو مكتوب أدناه لن يثير اهتمامًا كبيرًا ، ولكن يجب التحقق منه بواسطة DevOps padawan ، مثلي :)

إدارة الخادم عن بعد عبر SSH

لذلك ، لدينا مشروع ، تجميع على CI- الخادم ، ونحن بحاجة إلى إرسال بناء أو لتشغيل أوامر معينة من خلال SSH.

من الممكن استخدام نشر فوق SSH Plugin. يتيح إعداد تفاصيل اتصال ssh في واجهة إعدادات جينكينز. نقوم بتعيين اسم الخادم وعنوانه واسم المستخدم وطريقة التفويض - عن طريق كلمة المرور أو عبارة المرور أو مفتاح الإشارة. هذه التعديلات بسيطة وسهلة. قد تجد المزيد من التفاصيل على صفحة البرنامج المساعد.

بمساعدة هذا البرنامج المساعد ، يمكنك تشغيل أمر أو نشر ملفات في أي مرحلة تجميع (يمكنك الاطلاع على هذه التفاصيل الآن في تكوين المهمة).

  1. قبل أو بعد تجميع البدء:

2. أثناء التجميع

3. بعد التجميع:

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

خطوط الأنابيب

بالنسبة لي ، كان من الضروري (والغريب في الأمر) أن أفرز الأشياء باستخدام مقتنيات النشر وأن ننفذ أوامر SSH أعلاه بأسلوب مشروع قيد التنفيذ.

Pipeline - هي طريقة تجميع البرامج المنقسم على سلسلة من عناصر المعالجة (المراحل) ، يمكن إعداد كل منها بشكل خاص.

مزايا خطوط الأنابيب:

1. القدرة على تحقيق البرامج النصية ، والتي قد يتم تخزينها في عنصر تحكم إصدار النظام.

2. يمكن ضبط المشروع على الإيقاف المؤقت أو انتظار الأذونات أو أي إجراء آخر لمزيد من الأداء.

3. فرصة للجمع بين تشغيل المرحلة ، بما في ذلك التنفيذ المتوازي.

دعونا نجربها في الممارسة الفعلية.

سننشئ مشروع خط أنابيب اختبار بسيط:

حدد نص Pipeline وقم بتسجيلنا:

عقدة {
المرحلة ("تحضير البيئة") {
git branch: ‘development” ، url: ‘git@bitbucket.org: example / myapp.git '
sh 'npm install'
}
المرحلة ("تحليل الشفرة") {
sh ‘echo" Run some lints "
}
المرحلة ("اختبار الوحدة") {
‘صدى" الاختبارات ستعود "
}
المرحلة ("بناء") {
sh 'npm run clean'
sh 'npm run build'
}
}

للمشروع أربع مراحل الآن: إعداد البيئة ، تحليل الكود الإحصائي ، الاختبارات وتجميع نفسها.

تحضير البيئة

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

إذا لم يتم تثبيته بعد ، فقم بتشغيل الأمر sudo apt-get install ssh.

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

سه كجن ، ر

بعد ذلك ، نحتاج إلى كتابة كلمة مرور لحماية ملفات المفاتيح. إذا كنا سنشغل نصوص SSH ، فاتركها فارغة. من الممكن تغيير كلمة المرور إلى مفتاح بواسطة الأمر ssh-keygen. استعادة كلمة المرور أمر مستحيل.

يتم تخزين المفاتيح في ملفين (إذا لم يكن هناك مجلد آخر ، فيمكنك العثور عليها في الكتالوج الرئيسي):

~ / .ssh / id_rsa.pub - مفتاح مفتوح. يتم نسخها إلى الخادم ، حيث يلزم الوصول ؛

~ / .ssh / id_rsa - مفتاح مغلق. تأكد من عدم إظهارها لأي شخص. ومع ذلك ، إذا حدث ذلك ، فأعد إنشاء المفاتيح على الفور.

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

شمود الذهاب ث / /
chmod 700 ~ / .ssh
chmod 600 ~ / .ssh / Author_keys

بواسطة هذه الأوامر نحن:

أ) حرمان الجميع ، باستثناء المالك ، من الكتابة في الدليل الرئيسي ؛

ب) القراءة وتسجيل الدخول والكتابة متاحة فقط للمالك مع إعدادات .ssh ؛

ج) يمكن للمالك فقط قراءة وحفظ التغييرات في file.ssh / مفاتيح _ المسموح بها.

لأول مرة سنقوم بتسجيل الدخول عن طريق ssh مباشرة من وحدة تحكم خادم CI. يسأل Ssh دائمًا ، سواء كنا نثق بالمفتاح أم لا. إذا كانت الإجابة لا ، فسيتم إغلاق الاتصال. إذا كانت الإجابة بنعم - فسيتم حفظ المفتاح في الملف ~ / .ssh / known_hosts.

إنتاج جميع الإعدادات اللازمة ، يمكننا تشغيل الأوامر على الخادم البعيد دون طلب كلمة المرور. للتحقق من ذلك من وحدة التحكم ، قم بتشغيل الأمر:

ssh user @ server ls / var / www /

يجب أن تكون هناك قائمة بالملفات والدلائل / var / www / folder تظهر على الشاشة على الخادم البعيد.

الآن دعونا نحل مهمة لنسخ الملفات إلى خادم بعيد. Command scp يناسب أكثر من غيرها ، لأنه يجعل نسخة ملف خلال جلسة ssh. Ssh بالفعل منح أمر ، لذلك لا شيء إضافي اللازمة لتثبيت.

بناء جملة الأمر بسيط: نشير إلى ملف ، وإلى الخادم الذي نسخته والطريقة التي ينبغي القيام بها:

scp some_file user @ server: / new / path /

يسمح أمر Scp بإجراء النسخ العكسي من الخادم البعيد:

scp user @ server: / path / remote_file / path / local

نشر القطع الأثرية عبر ssh

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

ssh user @ server rm -rf / var / www / temp_deploy / dist /
ssh user @ server mkdir -p / var / www / temp_deploy
scp -r dist user @ server: / var / www / temp_deploy / dist /
ssh user @ server "rm -rf /var/www/example.com/dist/ && mv / var / www / temp_deploy / dist / /var/www/example.com/"

نضيف مرحلة النشر الأخيرة إلى مشروعنا ونتلقى نصًا مكتملًا بالكامل لنشر تسليم نتائج خادم:

عقدة {
المرحلة ("تحضير البيئة") {
git branch: ‘development” ، url: ‘git@bitbucket.org: example / myapp.git '
sh 'npm install'
}
المرحلة ("تحليل الشفرة") {
sh ‘echo" Run some lints "
}
المرحلة ("اختبار الوحدة") {
‘صدى" الاختبارات ستعود "
}
المرحلة ("بناء") {
sh 'npm run clean'
sh 'npm run build'
}
المرحلة ("النشر") {
sh user ssh user @ server rm -rf / var / www / temp_deploy / dist / ’
sh ‘ssh user @ server mkdir -p / var / www / temp_deploy’
sh ‘scp -r dist user @ server: / var / www / temp_deploy / dist /’
sh ‘ssh user @ server" rm -rf /var/www/example.com/dist/ && mv / var / www / temp_deploy / dist / /var/www/example.com/ "
}
}

هنا لدينا سفر ليست طويلة قد انتهت. بالطبع ، ليست الطريقة الوحيدة لنشر الأعمال الفنية على الخوادم. هناك FTP ، مجلدات Windows ، مستودعات (Artifactory ، Aptly) وطرق أخرى. هذا سبب وجيه لكتابة شيء جديد ، أليس كذلك؟ على أي حال ، أنا لا أقول وداعا :)

من قبل ماكسيم كولنيكوف ، DevOps
ديما دميترينكو ، محررة وخبيرة تسويق
بمساعدة أولكسندر كنيا ، مهندس برمجيات