🥇نحن نقوم بمهمة النشر في GKE بدون المكونات الإضافية والرسائل النصية القصيرة والتسجيل. دعونا نلقي نظرة خاطفة تحت سترة جنكينز

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

يجب أن أعترف بأنني كسول جدًا (ألم أعترف بذلك سابقًا؟ لا؟)، ونظرًا لحقيقة أن قادة الفريق لديهم إمكانية الوصول إلى Jenkins، حيث لدينا جميع CI/CD، فكرت: دعه ينشر كـ Jenkins. بقدر ما يريد! تذكرت نكتة: أعط رجلاً سمكة وسيأكل ليوم واحد؛ اتصل بشخص بنك الاحتياطي الفيدرالي وسوف يتم إطعامه طوال حياته. و ذهب لعب الحيل في العمل، والتي ستكون قادرة على نشر حاوية تحتوي على تطبيق أي إصدار تم إنشاؤه بنجاح في Kuber ونقل أي قيم إليه ENV (كان جدي، عالم فقه اللغة، ومدرس اللغة الإنجليزية في الماضي، يحرك إصبعه الآن على صدغه وينظر إليّ بشكل صريح للغاية بعد قراءة هذه الجملة).

لذا، في هذه المذكرة سأخبرك كيف تعلمت:

تحديث الوظائف في Jenkins ديناميكيًا من الوظيفة نفسها أو من وظائف أخرى؛
اتصل بوحدة التحكم السحابية (Cloud Shell) من عقدة تم تثبيت وكيل Jenkins عليها؛
نشر عبء العمل على Google Kubernetes Engine.

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

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

تنصل: 1. المذكرة كتبت "لنفسي" للدور أفضل الممارسات لا ينطبق. يسعدني قراءة خيارات "كان من الأفضل القيام بذلك بهذه الطريقة" في التعليقات.
2. إذا كان الجزء المطبق من النوتة يعتبر ملحا، فهذا مثل كل ملاحظاتي السابقة، هو محلول ملحي ضعيف.

تحديث إعدادات الوظيفة ديناميكيًا في Jenkins

أتوقع سؤالك: ما علاقة التحديث الديناميكي للوظيفة به؟ أدخل قيمة معلمة السلسلة يدويًا وانطلق!

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

الخطة هي كما يلي: نقوم بإنشاء وظيفة في Jenkins، حيث يمكننا، قبل الإطلاق، تحديد إصدار من القائمة، وتحديد قيم المعلمات التي تم تمريرها إلى الحاوية عبر ENV، ثم يجمع الحاوية ويدفعها إلى سجل الحاوية. ثم من هناك يتم إطلاق الحاوية في cuber مثل عبء العمل مع المعلمات المحددة في الوظيفة.

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

ليس هناك الكثير من الخيارات. شيئان يتبادران إلى ذهني على الفور:

استخدم واجهة برمجة تطبيقات الوصول عن بعد التي تقدمها Jenkins لمستخدميها؛
اطلب محتويات مجلد المستودع البعيد (في حالتنا هذا هو JFrog Artifactory، وهو ليس مهمًا).

جينكينز API الوصول عن بعد

ووفقا للتقاليد الممتازة الراسخة، أفضل تجنب التوضيحات المطولة.
سأسمح لنفسي فقط بترجمة مجانية لجزء من الفقرة الأولى الصفحة الأولى من وثائق API:

يوفر Jenkins واجهة برمجة التطبيقات (API) للوصول عن بعد إلى وظائفه التي يمكن قراءتها آليًا. <…> يتم تقديم الوصول عن بعد بأسلوب يشبه REST. وهذا يعني أنه لا توجد نقطة دخول واحدة لجميع الميزات، بل يوجد بدلاً من ذلك عنوان URL مثل ".../واجهة برمجة التطبيقات/"، أين "..." يعني الكائن الذي يتم تطبيق إمكانيات واجهة برمجة التطبيقات (API) عليه.

بمعنى آخر، إذا كانت مهمة النشر التي نتحدث عنها حاليًا متاحة على http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build، فإن صفارات واجهة برمجة التطبيقات (API) لهذه المهمة متاحة على http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/

بعد ذلك، لدينا خيار في الشكل الذي سنستقبل به المخرجات. دعونا نركز على XML، نظرًا لأن واجهة برمجة التطبيقات (API) تسمح بالتصفية فقط في هذه الحالة.

دعنا فقط نحاول الحصول على قائمة بجميع المهام. نحن مهتمون فقط باسم التجميع (اسم العرض) ونتيجته (نتيجة):

http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/xml?tree=allBuilds[displayName,result]

هل يعمل؟

الآن دعونا نقوم بتصفية تلك العمليات التي تنتهي بالنتيجة فقط نجاح. دعونا نستخدم الحجة &استبعاد وكمعلمة سوف نقوم بتمرير المسار إلى قيمة لا تساوي نجاح. نعم نعم. النفي المزدوج هو بيان. نستبعد كل ما لا يهمنا:

http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/xml?tree=allBuilds[displayName,result]&exclude=freeStyleProject/allBuild[result!='SUCCESS']

لقطة شاشة لقائمة الناجحين

حسنًا، من أجل المتعة فقط، دعونا نتأكد من أن الفلتر لم يخدعنا (المرشحات لا تكذب أبدًا!) ونعرض قائمة بالمرشحات "غير الناجحة":

http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/xml?tree=allBuilds[displayName,result]&exclude=freeStyleProject/allBuild[result='SUCCESS']

لقطة شاشة لقائمة الأشخاص غير الناجحين

قائمة الإصدارات من مجلد على خادم بعيد

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

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

curl -H "X-JFrog-Art-Api:VeryLongAPIKey" -s http://arts.myre.po/artifactory/awesomeapp/ | sed 's/a href=//' | grep "$(date +%b)-$(date +%Y)|$(date +%b --date='-1 month')-$(date +%Y)" | awk '{print $1}' | grep -oP '>K[^/]+' )

إعداد الوظائف وملف تكوين الوظائف في جنكينز

اكتشفنا مصدر قائمة الإصدارات. دعونا الآن ندمج القائمة الناتجة في المهمة. بالنسبة لي، كان الحل الواضح هو إضافة خطوة في مهمة بناء التطبيق. الخطوة التي سيتم تنفيذها إذا كانت النتيجة "النجاح".

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

والآن الجزء الممتع. يقوم Jenkins بتخزين تكوينات المهمة في الملفات. بتنسيق XML. على طول الطريق http://путь-до-задания/config.xml وبناءً على ذلك، يمكنك تنزيل ملف التكوين وتعديله حسب الضرورة وإعادته إلى المكان الذي حصلت عليه فيه.

تذكر أننا اتفقنا أعلاه على أننا سنقوم بإنشاء معلمة لقائمة الإصدارات BUILD_VERSION?

لنقم بتنزيل ملف التكوين وإلقاء نظرة بداخله. فقط للتأكد من أن المعلمة في مكانها ومن النوع المطلوب.

لقطة شاشة تحت المفسد.

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

هل أنت متأكد؟ هذا كل شيء، دعنا نكتب نصًا سيتم تنفيذه في حالة نجاح البناء.
سيتلقى البرنامج النصي قائمة بالإصدارات، ويقوم بتنزيل ملف التكوين، ويكتب قائمة الإصدارات فيه في المكان الذي نحتاجه، ثم يعيده مرة أخرى. نعم. صحيح. اكتب قائمة الإصدارات في XML في المكان الذي توجد فيه بالفعل قائمة الإصدارات (سيكون ذلك في المستقبل، بعد الإطلاق الأول للبرنامج النصي). أعلم أنه لا يزال هناك معجبون شرسون بالتعبيرات العادية في العالم. أنا لا أنتمي إليهم. رجاءا حمل com.xmlstarler إلى الجهاز حيث سيتم تحرير التكوين. يبدو لي أن هذا ليس ثمنًا باهظًا يجب دفعه لتجنب تحرير XML باستخدام sed.

تحت المفسد، أقدم الكود الذي ينفذ التسلسل أعلاه بالكامل.

اكتب قائمة الإصدارات من مجلد على الخادم البعيد إلى ملف config

#!/bin/bash
############## Скачиваем конфиг
curl -X GET -u username:apiKey http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_k8s/config.xml -o appConfig.xml

############## Удаляем и заново создаем xml-элемент для списка версий
xmlstarlet ed --inplace -d '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a[@class="string-array"]' appConfig.xml

xmlstarlet ed --inplace --subnode '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]' --type elem -n a appConfig.xml

xmlstarlet ed --inplace --insert '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a' --type attr -n class -v string-array appConfig.xml

############## Читаем в массив список версий из репозитория
readarray -t vers < <( curl -H "X-JFrog-Art-Api:Api:VeryLongAPIKey" -s http://arts.myre.po/artifactory/awesomeapp/ | sed 's/a href=//' | grep "$(date +%b)-$(date +%Y)|$(date +%b --date='-1 month')-$(date +%Y)" | awk '{print $1}' | grep -oP '>K[^/]+' )

############## Пишем массив элемент за элементом в конфиг
printf '%sn' "${vers[@]}" | sort -r | 
                while IFS= read -r line
                do
                    xmlstarlet ed --inplace --subnode '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a[@class="string-array"]' --type elem -n string -v "$line" appConfig.xml
                done

############## Кладем конфиг взад
curl -X POST -u username:apiKey http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_k8s/config.xml --data-binary @appConfig.xml

############## Приводим рабочее место в порядок
rm -f appConfig.xml

إذا كنت تفضل خيار الحصول على إصدارات من Jenkins وأنت كسول مثلي، فستجد تحت المفسد نفس الرمز، ولكن قائمة من Jenkins:

اكتب قائمة بالإصدارات من Jenkins إلى ملف config
فقط ضع ذلك في الاعتبار: يتكون اسم التجميع الخاص بي من رقم تسلسلي ورقم إصدار، مفصولين بنقطتين. وفقا لذلك، awk يقطع الجزء غير الضروري. لنفسك، قم بتغيير هذا الخط ليناسب احتياجاتك.

#!/bin/bash
############## Скачиваем конфиг
curl -X GET -u username:apiKey http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_k8s/config.xml -o appConfig.xml

############## Удаляем и заново создаем xml-элемент для списка версий
xmlstarlet ed --inplace -d '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a[@class="string-array"]' appConfig.xml

xmlstarlet ed --inplace --subnode '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]' --type elem -n a appConfig.xml

xmlstarlet ed --inplace --insert '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a' --type attr -n class -v string-array appConfig.xml

############## Пишем в файл список версий из Jenkins
curl -g -X GET -u username:apiKey 'http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/xml?tree=allBuilds[displayName,result]&exclude=freeStyleProject/allBuild[result!=%22SUCCESS%22]&pretty=true' -o builds.xml

############## Читаем в массив список версий из XML
readarray vers < <(xmlstarlet sel -t -v "freeStyleProject/allBuild/displayName" builds.xml | awk -F":" '{print $2}')

############## Пишем массив элемент за элементом в конфиг
printf '%sn' "${vers[@]}" | sort -r | 
                while IFS= read -r line
                do
                    xmlstarlet ed --inplace --subnode '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a[@class="string-array"]' --type elem -n string -v "$line" appConfig.xml
                done

############## Кладем конфиг взад
curl -X POST -u username:apiKey http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_k8s/config.xml --data-binary @appConfig.xml

############## Приводим рабочее место в порядок
rm -f appConfig.xml

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

قائمة الإصدارات المكتملة بشكل صحيح

إذا نجح كل شيء، انسخ النص والصقه فيه تشغيل أمر الصدفة وحفظ التغييرات.

الاتصال بـ Cloud Shell

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

قررت: حسنًا، نظرًا لأنه يمكن جمع الحاويات "الخارجية" في وحدة التحكم السحابية، فلماذا تهتم؟ يبقيه نظيفا، أليس كذلك؟ أريد جمع حاويات Jenkins في وحدة التحكم السحابية، ثم إطلاقها في المكعب من هناك. علاوة على ذلك، تتمتع Google بقنوات غنية جدًا داخل بنيتها التحتية، مما سيكون له تأثير مفيد على سرعة النشر.

للاتصال بوحدة التحكم السحابية، تحتاج إلى شيئين: com.gcloud وحقوق الوصول إلى جوجل الغيمة API لمثيل VM الذي سيتم إجراء هذا الاتصال به.

بالنسبة لأولئك الذين يخططون للاتصال ليس من Google Cloud على الإطلاق
تتيح جوجل إمكانية تعطيل التفويض التفاعلي في خدماتها. سيسمح لك هذا بالاتصال بوحدة التحكم حتى من خلال ماكينة صنع القهوة، إذا كانت تعمل بنظام *nix وتحتوي على وحدة تحكم نفسها.

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

أسهل طريقة لمنح الحقوق هي من خلال واجهة الويب.

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

بمجرد الانتهاء من تحميل VM، اتصل به عبر SSH وتأكد من أن الاتصال يحدث بدون خطأ. استخدم الأمر:

gcloud alpha cloud-shell ssh

يبدو الاتصال الناجح هكذا

النشر إلى GKE

نظرًا لأننا نسعى جاهدين بكل الطرق الممكنة للتبديل الكامل إلى IaC (البنية التحتية كرمز)، يتم تخزين ملفات الإرساء الخاصة بنا في Git. هذا من ناحية. ويتم وصف النشر في kubernetes بواسطة ملف yaml، والذي يتم استخدامه فقط لهذه المهمة، والذي يشبه أيضًا التعليمات البرمجية. وهذا من الجانب الآخر. بشكل عام، أعني أن الخطة هي كما يلي:

نحن نأخذ قيم المتغيرات BUILD_VERSION واختياريًا، قيم المتغيرات التي سيتم تمريرها ENV.
قم بتنزيل ملف dockerfile من Git.
إنشاء yaml للنشر.
نقوم بتحميل كلا الملفين عبر scp إلى وحدة التحكم السحابية.
نقوم ببناء حاوية هناك وندفعها إلى سجل الحاوية
نقوم بتطبيق ملف نشر التحميل على cuber.

لنكن أكثر تحديدا. بمجرد أن بدأنا نتحدث عن ENV، فلنفترض أننا بحاجة إلى تمرير قيم معلمتين: بارام 1 и بارام 2. نضيف مهمتهم للنشر، اكتب - معلمة السلسلة.

لقطة

سنقوم بإنشاء yaml بإعادة توجيه بسيطة صدى إلى ملف. من المفترض، بالطبع، أن يكون لديك في ملف الإرساء الخاص بك بارام 1 и بارام 2أن اسم التحميل سيكون com. Awesomeapp، والحاوية المجمعة مع تطبيق الإصدار المحدد موجودة تسجيل الحاوية على طول الطريق gcr.io/awesomeapp/awesomeapp-$BUILD_VERSIONحيث $BUILD_VERSION تم اختياره للتو من القائمة المنسدلة.

قائمة الفريق

touch deploy.yaml
echo "apiVersion: apps/v1" >> deploy.yaml
echo "kind: Deployment" >> deploy.yaml
echo "metadata:" >> deploy.yaml
echo "  name: awesomeapp" >> deploy.yaml
echo "spec:" >> deploy.yaml
echo "  replicas: 1" >> deploy.yaml
echo "  selector:" >> deploy.yaml
echo "    matchLabels:" >> deploy.yaml
echo "      run: awesomeapp" >> deploy.yaml
echo "  template:" >> deploy.yaml
echo "    metadata:" >> deploy.yaml
echo "      labels:" >> deploy.yaml
echo "        run: awesomeapp" >> deploy.yaml
echo "    spec:" >> deploy.yaml
echo "      containers:" >> deploy.yaml
echo "      - name: awesomeapp" >> deploy.yaml
echo "        image: gcr.io/awesomeapp/awesomeapp-$BUILD_VERSION:latest" >> deploy.yaml
echo "        env:" >> deploy.yaml
echo "        - name: PARAM1" >> deploy.yaml
echo "          value: $PARAM1" >> deploy.yaml
echo "        - name: PARAM2" >> deploy.yaml
echo "          value: $PARAM2" >> deploy.yaml

وكيل جينكينز بعد الاتصال باستخدام Gcloud Alpha Cloud-Shell SSH الوضع التفاعلي غير متاح، لذلك نرسل الأوامر إلى وحدة التحكم السحابية باستخدام المعلمة --يأمر.

نقوم بتنظيف المجلد الرئيسي في وحدة التحكم السحابية من ملف الإرساء القديم:

gcloud alpha cloud-shell ssh --command="rm -f Dockerfile"

ضع ملف dockerfile الذي تم تنزيله حديثًا في المجلد الرئيسي لوحدة التحكم السحابية باستخدام scp:

gcloud alpha cloud-shell scp localhost:./Dockerfile cloudshell:~

نقوم بجمع الحاوية ووضع علامة عليها ودفعها إلى سجل الحاوية:

gcloud alpha cloud-shell ssh --command="docker build -t awesomeapp-$BUILD_VERSION ./ --build-arg BUILD_VERSION=$BUILD_VERSION --no-cache"
gcloud alpha cloud-shell ssh --command="docker tag awesomeapp-$BUILD_VERSION gcr.io/awesomeapp/awesomeapp-$BUILD_VERSION"
gcloud alpha cloud-shell ssh --command="docker push gcr.io/awesomeapp/awesomeapp-$BUILD_VERSION"

نحن نفعل الشيء نفسه مع ملف النشر. يرجى ملاحظة أن الأوامر أدناه تستخدم أسماء وهمية للمجموعة التي يحدث فيها النشر (awsm-cluster) واسم المشروع (رهيبة المشروع)، حيث تقع الكتلة.

gcloud alpha cloud-shell ssh --command="rm -f deploy.yaml"
gcloud alpha cloud-shell scp localhost:./deploy.yaml cloudshell:~
gcloud alpha cloud-shell ssh --command="gcloud container clusters get-credentials awsm-cluster --zone us-central1-c --project awesome-project && 
kubectl apply -f deploy.yaml"

نقوم بتشغيل المهمة وفتح مخرجات وحدة التحكم ونأمل أن نرى التجميع الناجح للحاوية.

لقطة

ومن ثم النشر الناجح للحاوية المجمعة

لقطة

لقد تجاهلت الإعداد عمدا دخول. لسبب واحد بسيط: بمجرد إعداده عبء العمل باستخدام الاسم المحدد، سيظل قيد التشغيل، بغض النظر عن عدد عمليات النشر بهذا الاسم التي تقوم بها. حسنا، بشكل عام، هذا يتجاوز قليلا نطاق التاريخ.

بدلا من الاستنتاجات

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

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

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

نقوم بإنشاء مهمة نشر في GKE بدون مكونات إضافية أو رسائل نصية قصيرة أو تسجيل. دعونا نلقي نظرة خاطفة تحت سترة جينكينز

تحديث إعدادات الوظيفة ديناميكيًا في Jenkins

جينكينز API الوصول عن بعد

قائمة الإصدارات من مجلد على خادم بعيد

إعداد الوظائف وملف تكوين الوظائف في جنكينز

الاتصال بـ Cloud Shell

النشر إلى GKE

بدلا من الاستنتاجات

إضافة تعليق إلغاء الرد