Geekly articles weekly

GitLab لمشروع التسليم المستمر على تقنيات InterSystems: حاويات

هذه المقالة هي استمرار لمقال حول تنظيم عمليات التكامل المستمر / التسليم المستمر التي تعمل على أتمتة التجميع والاختبار وتسليم التطبيقات التي تنطبق على الحلول القائمة على منصة InterSystems.


ضع في اعتبارك مواضيع مثل:


  • حاويات 101
  • حاويات في مراحل مختلفة من دورة تطوير البرمجيات
  • التسليم المستمر مع الحاويات

حاويات 101


تمت كتابة الكثير من المقالات والكتب حول الحاويات والحاويات ، لذلك سأقدم هنا مقدمة صغيرة ، والتي ، مع ذلك ، لا تدعي أنها نهائية. لذلك دعونا نبدأ.


الحاويات ، من الناحية الفنية ، هي طريقة افتراضية تدعم فيها نواة نظام التشغيل عدة حالات معزولة من مساحة المستخدم (الحاويات) ، بدلاً من واحدة. يبدو هذا بصريًا كما يلي:


دوكر ضد VM


من المهم ملاحظة أن الحاويات ليست أجهزة افتراضية ، إليك مقالة جيدة عن اختلافاتها.


فوائد الحاوية


هناك فوائد عديدة لاستخدام الحاويات:


  • قابلية
  • الفعالية
  • العزلة
  • خفة
  • الثبات

قابلية


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


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


الفعالية


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


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


العزلة


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


خفة


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


الثبات


تتكون البنية التحتية الثابتة من مكونات ثابتة يتم استبدالها لكل عملية نشر ولا يتم تحديثها. يقلل الاتساق من عدم الاتساق ويسمح لك بالنسخ والتحرك بسهولة وسرعة بين الحالات المختلفة لتطبيقك. المزيد عن الثبات .


الميزات الجديدة


تسمح لك كل هذه المزايا بإدارة بنيتك الأساسية وتطبيقاتك بطريقة جديدة.


تزامن


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


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


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


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


تحجيم


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


حاويات في مراحل مختلفة من دورة حياة البرنامج


ضع في اعتبارك فوائد الحاويات في مراحل مختلفة من دورة حياة البرنامج.


دورة حياة البرمجيات


التنمية


أهم ميزة هي سهولة بدء التطوير. بعد تثبيت Docker ، يكفي تشغيل أمرين: docker pull لتحميل الصورة docker run لبدء تشغيله. تم حل جميع التبعيات بالفعل في مرحلة إنشاء التطبيق.


تصحيح الأخطاء


جميع البيئات متناسقة وتعاريفها موجودة ؛ بالإضافة إلى ذلك ، من السهل نشر البيئة اللازمة. يكفي أن تجعل docker pull الحاوية المهمة ويديرها.


اختبار / ضمان الجودة


في حالة حدوث خطأ ، يمكن نقل بيئة المشكلة وظروف إعادة إنتاج الخطأ مع الحاوية. جميع التغييرات في البنية التحتية "موثقة". عدد المتغيرات آخذ في التناقص - إصدارات المكتبات والأطر ونظام التشغيل ... من الممكن تشغيل عدة حاويات لموازنة الاختبارات.


التسليم


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


التسليم المستمر


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


قرص مضغوط


يمكن تمييز ثلاث مراحل رئيسية:


  • التجمع
  • التسليم
  • إطلاق

التجمع


في المقالة السابقة ، كان التجميع تدريجيًا - فقد اعتبرنا الاختلاف بين البيئة الحالية وقاعدة الكود الجديد وقمنا بتغيير بيئتنا بحيث تتوافق مع قاعدة الكود الجديدة. مع الحاويات ، اكتمال كل تجميع. نتيجة البناء هي صورة Docker التي يمكن تشغيلها في أي مكان.


التسليم


بعد تجميع صورتنا واختبارها ، يتم تحميلها على Docker Registry ، وهو تطبيق متخصص لاستضافة صورة Docker. هناك يمكنه استبدال الصورة السابقة بنفس الاسم (العلامة). على سبيل المثال ، نظرًا لالتزام جديد بالفرع الرئيسي ، قمنا بتجميع صورة جديدة ( MyProject/MyApp:master ) ، وإذا تم اجتياز الاختبارات ، يمكننا تحديث الصورة في Docker Registry وسيحصل كل من يقوم بتنزيل MyProject/MyApp:master على إصدار جديد.


إطلاق


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


تحقق من ندوة الويب موضحا هذه الخطوات.


بدلاً من ذلك ، من حيث الالتزام:



في تكوين التسليم المستمر لدينا:


  • تنفيذ التعليمات البرمجية لمستودع GitLab
  • نجمع الصورة
  • اختباره
  • انشر صورة جديدة في Docker Registry
  • قم بتحديث الحاوية القديمة إلى الإصدار الجديد من Docker Registry

لهذا نحن بحاجة إلى:


  • عامل ميناء
  • تسجيل عامل الميناء
  • المجال المسجل (اختياري ، ولكن مرغوب فيه)
  • أدوات واجهة المستخدم الرسومية (اختياري)

عامل ميناء


بادئ ذي بدء ، نحن بحاجة إلى بدء Docker. أوصي بالبدء بخادم واحد مع إصدار شائع من Linux ، مثل Ubuntu أو RHEL أو Suse. لا أوصي بالبدء بتوزيعات مثل CoreOS و RancherOS وما إلى ذلك - فهي لا تستهدف المبتدئين. تذكر تبديل برنامج تشغيل التخزين إلى devicemapper .


إذا تحدثنا عن عمليات نشر على نطاق واسع ، فعندئذ باستخدام أدوات تنسيق مثل Kubernetes أو Rancher أو Swarm ، يمكنك أتمتة معظم المهام ، لكننا لن نناقشها (على الأقل في إطار هذه المقالة).


تسجيل عامل الميناء


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


  • تحكم في مكان تخزين صورك
  • تملك خادم توزيع الصور
  • دمج تخزين الصور وتوزيعها في عملية التطوير

فيما يلي وثائق حول تشغيل وتكوين Docker Registry.


قم بتوصيل Docker Registry و GitLab


لتوصيل Docker Registry بـ GitLab ، تحتاج إلى تشغيل Docker Registry مع دعم HTTPS . أستخدم Let's Encrypt للحصول على الشهادات ، واتبعت هذه التعليمات للحصول على شهادة. بعد التحقق من أن Docker Registry يمكن الوصول إليه عبر HTTPS (يمكنك التحقق منه في المتصفح) ، اتبع هذه التعليمات لتوصيل Docker Registry بـ GitLab. تختلف هذه التعليمات اعتمادًا على تثبيت GitLab والتكوين الذي تحتاجه. في حالتي ، كان الإعداد لإضافة شهادة Docker Registry والمفتاح إلى /etc/gitlab/ssl ، وهذه الأسطر إلى /etc/gitlab/gitlab.rb :


 registry_external_url 'https://docker.domain.com' gitlab_rails ['registry_api_url'] = "https://docker.domain.com"

بعد إعادة تكوين GitLab ، ظهرت علامة تبويب تسجيل جديدة ، والتي توفر معلومات حول كيفية تسمية الصور التي تم إنشاؤها بشكل صحيح بحيث تظهر هنا.



المجال


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


  • فروع <featureName>.docker.domain.com متعددة في <featureName>.docker.domain.com
  • نسخة تجريبية على موقع master.docker.domain.com
  • نسخة تجريبية على موقع preprod.docker.domain.com
  • إصدار المنتج على prod.docker.domain.com

للقيام بذلك ، نحتاج إلى اسم مجال وسجل DNS بدل بدل يعيد توجيه الطلبات إلى * .docker.domain.com إلى عنوان IP الخاص بـ docker.domain.com . بدلاً من ذلك ، يمكنك استخدام منافذ مختلفة.


Nginx


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


أدوات واجهة المستخدم الرسومية


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


  • رانشر
  • الميكروبادجر
  • Portainer
  • واجهة مستخدم بسيطة لرسو السفن
  • ...

تسمح لك بإنشاء حاويات وإدارتها من واجهة المستخدم الرسومية بدلاً من واجهة المستخدم الرسومية. إليك ما يبدو عليه رانشر:


رانشر


عداء Gitlab


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


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


تكوين التسليم المستمر


الآن بعد أن تم تكوين جميع المكونات الضرورية ، يمكنك البدء في إنشاء تكوين تسليم مستمر.


التجمع


أولاً ، نحتاج إلى تجميع صورة.


يتم تخزين الكود الخاص بنا ، كما هو الحال دائمًا ، في المستودع وتكوين القرص المضغوط في gitlab-ci.yml ، ولكن بالإضافة إلى ذلك (لتحسين الأمان) ، سنقوم بتخزين العديد من الملفات المتعلقة بالصورة على خادم البناء.


Gitlab.xml


يحتوي على رمز رد الاتصال للقرص المضغوط. تم تطويره في مقال سابق وهو متاح على GitHub . هذه مكتبة صغيرة لتنزيل الكود وتشغيل مختلف عمليات الاستدعاء وكود الاختبار. يفضل استخدام وحدات git الفرعية لتضمين هذا المشروع أو شيء مشابه في مستودعك. الوحدات الفرعية أفضل لأنه من الأسهل إبقائها محدثة. بديل آخر هو إنشاء إصدار على GitLab وتنزيله باستخدام الأمر ADD بالفعل في وقت البناء.


القزحية


مفتاح الترخيص. يمكن تحميلها أثناء تجميع الحاوية ، ولا يتم تخزينها على الخادم. ليس من الآمن تخزين المفتاح في المستودع. يمكنك الحصول على مفتاح تجريبي في WRC أو تجربة InterSystems IRIS Experience .


pwd.txt


ملف يحتوي على كلمة المرور الافتراضية. مرة أخرى ، تخزين كلمة المرور في المستودع غير آمن إلى حد ما.


load_ci.script


برنامج نصي:



 set sc = ##Class(Security.System).Get("SYSTEM",.Properties) write:('sc) $System.Status.GetErrorText(sc) set AutheEnabled = Properties("AutheEnabled") set AutheEnabled = $ZBOOLEAN(+AutheEnabled,16,7) set Properties("AutheEnabled") = AutheEnabled set sc = ##Class(Security.System).Modify("SYSTEM",.Properties) write:('sc) $System.Status.GetErrorText(sc) zn "USER" do ##class(%SYSTEM.OBJ).Load(##class(%File).ManagerDirectory() _ "GitLab.xml","cdk") do ##class(isc.git.Settings).setSetting("hooks", "MyApp/Hooks/") do ##class(isc.git.Settings).setSetting("tests", "MyApp/Tests/") do ##class(isc.git.GitLab).load() halt

لاحظ أن السطر الأول ترك عمداً فارغاً. إذا كان هذا البرنامج النصي الأولي هو نفسه دائمًا ، يمكنك حفظه في المستودع.


gitlab-ci.yml


الآن ، دعنا ننتقل إلى تكوين التسليم المستمر:


 build image: stage: build tags: - test script: - cp -r /InterSystems/mount ci - cd ci - echo 'SuperUser' | cat - pwd.txt load_ci.script > temp.txt - mv temp.txt load_ci.script - cd .. - docker build --build-arg CI_PROJECT_DIR=$CI_PROJECT_DIR -t docker.domain.com/test/docker:$CI_COMMIT_REF_NAME .

ما الذي يحدث هنا؟


بادئ ذي بدء ، نظرًا لأن عملية تجميع الصور لا يمكنها الوصول إلا إلى الأدلة الفرعية للدليل الأساسي - في حالتنا ، الدليل الجذر للمستودع ، تحتاج إلى نسخ الدليل "السري" (الذي يحتوي على GitLab.xml و iris.key و pwd.txt و load_ci.skript ) إلى مستودع مستنسخ.


علاوة على ذلك ، يلزم المستخدم / كلمة المرور للوصول إلى المحطة الطرفية ، لذلك load_ci.script إلى load_ci.script (لهذا نحتاج إلى سطر فارغ في بداية load_ci.script ).


أخيرًا ، نقوم بإنشاء صورة Docker docker.domain.com/test/docker:$CI_COMMIT_REF_NAME : docker.domain.com/test/docker:$CI_COMMIT_REF_NAME


حيث يكون $CI_COMMIT_REF_NAME هو اسم الفرع. يرجى ملاحظة: يجب أن يتطابق الجزء الأول من علامة الصورة مع اسم المستودع في GitLab بحيث يمكن رؤيته في علامة التبويب التسجيل (تتوفر تعليمات أكثر اكتمالًا لوضع العلامات الصحيحة).


ملف Dockerfile


يتم إنشاء صورة Docker باستخدام Dockerfile ، وهنا:


 FROM docker.intersystems.com/intersystems/iris:2018.1.1.613.0 ENV SRC_DIR=/tmp/src ENV CI_DIR=$SRC_DIR/ci ENV CI_PROJECT_DIR=$SRC_DIR COPY ./ $SRC_DIR RUN cp $CI_DIR/iris.key $ISC_PACKAGE_INSTALLDIR/mgr/ \ && cp $CI_DIR/GitLab.xml $ISC_PACKAGE_INSTALLDIR/mgr/ \ && $ISC_PACKAGE_INSTALLDIR/dev/Cloud/ICM/changePassword.sh $CI_DIR/pwd.txt \ && iris start $ISC_PACKAGE_INSTANCENAME \ && irissession $ISC_PACKAGE_INSTANCENAME -U%SYS < $CI_DIR/load_ci.script \ && iris stop $ISC_PACKAGE_INSTANCENAME quietly

يتم تنفيذ الإجراءات التالية:


  • نأخذ صورة InterSystems IRIS كأساس. يجب أن يكون في سجل Docker الخاص بك. إذا لم تكن قد عملت مع Docker من قبل ، فجرّب النظرة الأولى: Docker ، التي تصف كيفية الحصول على صورة InterSystems IRIS ، وإضافتها إلى Docker Registry ، وتشغيلها يدويًا.
  • بادئ ذي بدء ، انسخ مستودعنا (والدليل "السري") داخل الحاوية.
  • انسخ مفتاح الترخيص و GitLab.xml إلى دليل GitLab.xml .
  • قم بتغيير كلمة المرور إلى القيمة من pwd.txt . لاحظ أنه تم حذف pwd.txt أثناء هذه العملية.
  • يبدأ InterSystems IRIS.
  • يتم load_ci.script .
  • توقف InterSystems IRIS.

هنا سجل بناء جزئي
 Running with gitlab-runner 10.6.0 (a3543a27) on docker 7b21e0c4 Using Shell executor... Running on docker... Fetching changes... Removing ci/ Removing temp.txt HEAD is now at 5ef9904 Build load_ci.script From http://gitlab.eduard.win/test/docker 5ef9904..9753a8d master -> origin/master Checking out 9753a8db as master... Skipping Git submodules setup $ cp -r /InterSystems/mount ci $ cd ci $ echo 'SuperUser' | cat - pwd.txt load_ci.script > temp.txt $ mv temp.txt load_ci.script $ cd .. $ docker build --build-arg CI_PROJECT_DIR=$CI_PROJECT_DIR -t docker.eduard.win/test/docker:$CI_COMMIT_REF_NAME . Sending build context to Docker daemon 401.4kB Step 1/6 : FROM docker.intersystems.com/intersystems/iris:2018.1.1.613.0 ---> cd2e53e7f850 Step 2/6 : ENV SRC_DIR=/tmp/src ---> Using cache ---> 68ba1cb00aff Step 3/6 : ENV CI_DIR=$SRC_DIR/ci ---> Using cache ---> 6784c34a9ee6 Step 4/6 : ENV CI_PROJECT_DIR=$SRC_DIR ---> Using cache ---> 3757fa88a28a Step 5/6 : COPY ./ $SRC_DIR ---> 5515e13741b0 Step 6/6 : RUN cp $CI_DIR/iris.key $ISC_PACKAGE_INSTALLDIR/mgr/ && cp $CI_DIR/GitLab.xml $ISC_PACKAGE_INSTALLDIR/mgr/ && $ISC_PACKAGE_INSTALLDIR/dev/Cloud/ICM/changePassword.sh $CI_DIR/pwd.txt && iris start $ISC_PACKAGE_INSTANCENAME && irissession $ISC_PACKAGE_INSTANCENAME -U%SYS < $CI_DIR/load_ci.script && iris stop $ISC_PACKAGE_INSTANCENAME quietly ---> Running in 86526183cf7c . Waited 1 seconds for InterSystems IRIS to start This copy of InterSystems IRIS has been licensed for use exclusively by: ISC Internal Container Sharding Copyright (c) 1986-2018 by InterSystems Corporation Any other use is a violation of your license agreement %SYS> 1 %SYS> Using 'iris.cpf' configuration file This copy of InterSystems IRIS has been licensed for use exclusively by: ISC Internal Container Sharding Copyright (c) 1986-2018 by InterSystems Corporation Any other use is a violation of your license agreement 1 alert(s) during startup. See messages.log for details. Starting IRIS Node: 39702b122ab6, Instance: IRIS Username: Password: Load started on 04/06/2018 17:38:21 Loading file /usr/irissys/mgr/GitLab.xml as xml Load finished successfully. USER> USER> [2018-04-06 17:38:22.017] Running init hooks: before [2018-04-06 17:38:22.017] Importing hooks dir /tmp/src/MyApp/Hooks/ [2018-04-06 17:38:22.374] Executing hook class: MyApp.Hooks.Global [2018-04-06 17:38:22.375] Executing hook class: MyApp.Hooks.Local [2018-04-06 17:38:22.375] Importing dir /tmp/src/ Loading file /tmp/src/MyApp/Tests/TestSuite.cls as udl Compilation started on 04/06/2018 17:38:22 with qualifiers 'c' Compilation finished successfully in 0.194s. Load finished successfully. [2018-04-06 17:38:22.876] Running init hooks: after [2018-04-06 17:38:22.878] Executing hook class: MyApp.Hooks.Local [2018-04-06 17:38:22.921] Executing hook class: MyApp.Hooks.Global Removing intermediate container 39702b122ab6 ---> dea6b2123165 [Warning] One or more build-args [CI_PROJECT_DIR] were not consumed Successfully built dea6b2123165 Successfully tagged docker.domain.com/test/docker:master Job succeeded

إطلاق


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


أولاً ، البرنامج النصي لحذف الحاوية القديمة.


 destroy old: stage: destroy tags: - test script: - docker stop iris-$CI_COMMIT_REF_NAME || true - docker rm -f iris-$CI_COMMIT_REF_NAME || true

هذا البرنامج النصي يدمر الحاوية قيد التشغيل وينجح دائمًا (بشكل افتراضي ، يقوم Docker بإرجاع خطأ عند محاولة إيقاف / حذف حاوية غير موجودة).


بعد ذلك ، أطلقنا حاوية جديدة وسجلناها كبيئة.


 run image: stage: run environment: name: $CI_COMMIT_REF_NAME url: http://$CI_COMMIT_REF_SLUG.docker.eduard.win/index.html tags: - test script: - docker run -d --expose 52773 --volume /InterSystems/durable/$CI_COMMIT_REF_SLUG:/data --env ISC_DATA_DIRECTORY=/data/sys --env VIRTUAL_HOST=$CI_COMMIT_REF_SLUG.docker.eduard.win --name iris-$CI_COMMIT_REF_NAME docker.eduard.win/test/docker:$CI_COMMIT_REF_NAME --log $ISC_PACKAGE_INSTALLDIR/mgr/messages.log

تقوم حاوية Nginx تلقائيًا بإعادة توجيه الطلبات باستخدام VIRTUAL_HOST البيئة VIRTUAL_HOST إلى المنفذ المحدد - في هذه الحالة ، 52773.


نظرًا لأنه من الضروري تخزين بعض البيانات (كلمات المرور ،٪ SYS ، بيانات التطبيق) على المضيف في InterSystems IRIS ، فهناك وظيفة ٪ SYS دائمة تسمح لك بتخزين البيانات على المضيف مثل:


  • iris.cpf هو ملف التكوين الرئيسي.
  • /csp مع ملفات تطبيق الويب.
  • /httpd/httpd.conf بتكوين خادم Apache الخاص.
  • الدليل /mgr الذي يتم تخزينه فيه:
    • قواعد البيانات IRISSYS ، IRISTEMP ، IRISAUDIT ، IRIS ، USER .
    • IRIS.WIJ .
    • دليل /journal تخزين المجلات.
    • دليل /temp للملفات المؤقتة.
    • سجلات journal.log ، journal.log ، SystemMonitor.log .

لتمكين Durable٪ SYS ، يتم تحديد وسيطة volume التي تقوم ISC_DATA_DIRECTORY الدليل المضيف ISC_DATA_DIRECTORY المتغير ISC_DATA_DIRECTORY بتعيين الدليل لتخزين ملفات Durable٪ SYS. هذا الدليل غير موجود ، سيتم إنشاؤه تلقائيًا.


وبالتالي ، فإن بنية تطبيق الحاوية لدينا هي كما يلي:


بنية التطبيق في حاويات


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


بناءً على ما سبق ، يجب على ٪ Installer :


  • إنشاء منطقة APP / قاعدة البيانات
  • رمز التحميل إلى منطقة APP
  • إنشاء فئات رسم الخرائط لتطبيقنا في منطقة USER
  • تنفيذ تكوين آخر (لقد قمت بإنشاء تطبيق ويب CSP وتطبيق ويب REST)

رمز٪ المثبت
 Class MyApp.Hooks.Local { Parameter Namespace = "APP"; /// See generated code in zsetup+1^MyApp.Hooks.Local.1 XData Install [ XMLNamespace = INSTALLER ] { <Manifest> <Log Text="Creating namespace ${Namespace}" Level="0"/> <Namespace Name="${Namespace}" Create="yes" Code="${Namespace}" Ensemble="" Data="IRISTEMP"> <Configuration> <Database Name="${Namespace}" Dir="/usr/irissys/mgr/${Namespace}" Create="yes" MountRequired="true" Resource="%DB_${Namespace}" PublicPermissions="RW" MountAtStartup="true"/> </Configuration> <Import File="${Dir}Form" Recurse="1" Flags="cdk" IgnoreErrors="1" /> </Namespace> <Log Text="End Creating namespace ${Namespace}" Level="0"/> <Log Text="Mapping to USER" Level="0"/> <Namespace Name="USER" Create="no" Code="USER" Data="USER" Ensemble="0"> <Configuration> <Log Text="Mapping Form package to USER namespace" Level="0"/> <ClassMapping From="${Namespace}" Package="Form"/> <RoutineMapping From="${Namespace}" Routines="Form" /> </Configuration> <CSPApplication Url="/" Directory="${Dir}client" AuthenticationMethods="64" IsNamespaceDefault="false" Grant="%ALL" Recurse="1" /> </Namespace> </Manifest> } /// This is a method generator whose code is generated by XGL. /// Main setup method /// set vars("Namespace")="TEMP3" /// do ##class(MyApp.Hooks.Global).setup(.vars) ClassMethod setup(ByRef pVars, pLogLevel As %Integer = 0, pInstaller As %Installer.Installer) As %Status [ CodeMode = objectgenerator, Internal ] { Quit ##class(%Installer.Manifest).%Generate(%compiledclass, %code, "Install") } /// Entry point ClassMethod onAfter() As %Status { try { write "START INSTALLER",! set vars("Namespace") = ..#Namespace set vars("Dir") = ..getDir() set sc = ..setup(.vars) write !,$System.Status.GetErrorText(sc),! set sc = ..createWebApp() } catch ex { set sc = ex.AsStatus() write !,$System.Status.GetErrorText(sc),! } quit sc } /// Modify web app REST ClassMethod createWebApp(appName As %String = "/forms") As %Status { set:$e(appName)'="/" appName = "/" _ appName #dim sc As %Status = $$$OK new $namespace set $namespace = "%SYS" if '##class(Security.Applications).Exists(appName) { set props("AutheEnabled") = $$$AutheUnauthenticated set props("NameSpace") = "USER" set props("IsNameSpaceDefault") = $$$NO set props("DispatchClass") = "Form.REST.Main" set props("MatchRoles")=":" _ $$$AllRoleName set sc = ##class(Security.Applications).Create(appName, .props) } quit sc } ClassMethod getDir() [ CodeMode = expression ] { ##class(%File).NormalizeDirectory($system.Util.GetEnviron("CI_PROJECT_DIR")) } }

ألاحظ أنه لإنشاء قاعدة بيانات ليست على المضيف ، أستخدم الدليل /usr/irissys/mgr ، نظرًا لأن المكالمة ##class(%File).ManagerDirectory() تُرجع المسار إلى الدليل لـ Durable٪ SYS.


الاختبارات


الآن قم بإجراء الاختبارات.


 test image: stage: test tags: - test script: - docker exec iris-$CI_COMMIT_REF_NAME irissession iris -U USER "##class(isc.git.GitLab).test()"

التسليم


تم اجتياز الاختبارات ، سننشر صورتنا في Docker Registry.


 publish image: stage: publish tags: - test script: - docker login docker.domain.com -u user -p pass - docker push docker.domain.com/test/docker:$CI_COMMIT_REF_NAME

يمكن تمرير تسجيل الدخول / كلمة المرور باستخدام المتغيرات السرية .


الآن يتم عرض الصورة على GitLab.



ويمكن للمطورين الآخرين تنزيله من Docker Registry. في علامة التبويب البيئات ، تتوفر جميع بيئاتنا للعرض:


الاستنتاجات


تناقش سلسلة المقالات هذه الأساليب الشائعة للتكامل المستمر. أتمتة تجميع واختبار وتسليم تطبيقك على منصات InterSystems ممكنة وسهلة التنفيذ.


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


المراجع


Source: https://habr.com/ru/post/ar420749/

More articles:


All Articles