نشر الرمز مباشرة إلى الحاوية عامل ميناء. أو كيف لا تسويف بعد كل التزام

جاءت المهمة WEB-12982
قم بإنشاء فرع web-12982 في المستودع
أثناء سير الفرع ، اقرأ TZ وشرب القهوة
تابع مباشرة التطوير

بوابة ارتكاب ، بوابة دفع
بينما الفرع يعيد تجميعه
بوابة ارتكاب ، بوابة دفع
بينما يتم إعادة بناء الفرع ، يتقلب تويتر
بوابة ارتكاب ، بوابة دفع
...
تقوم بتسليم فرع المراجعة مع 50 عملية ارتكاب

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

هل الوضع مألوف؟ في شركتي ، يتم تنظيم البنية التحتية للتطوير على النحو التالي:

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

لكن ، ببطء ... إذا كان هذا الموقف قريبًا منك ، فمرحبًا بك!

• جوهر المشكلة
• خيارات الحل
• تنفيذ الحل

جوهر المشكلة

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

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

حتى إذا تخطيت المراحل الإضافية وتركت فقط build-dev و publish-dev ، فإن وقت الانتظار غير مهم لأي إجراءات مفيدة ، ولكن بشكل كبير في إجمالي الوقت الذي يقضيه ، خاصةً عندما يتعلق الأمر بـ CI \ CD ، من Gitlab.

بالطبع ، يمكنك تسريع العملية من خلال تجميع المشروع محليًا ، شريطة أن يكون للمبرمج كمبيوتر قوي نسبيًا ، وتم تكوين gitlab-runner ، وتكوين نفس البيئة على الخادم البعيد ، وإضافة العلامات المقابلة إلى gitlab-ci.yml ، لكنني أشك في ذلك أن تكون سرعة الإنشاء هي نفسها نشر رمز FTP التلقائي بعد مفاتيح ctrl + s.

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

ما هو المطلوب وخيارات الحل

tldr: ابحث عن طريقة لمعرفة نتيجة التعديلات بكل بساطة وبأسرع وقت ممكن. حتى لا يرتكب كل مرة ولا تنتظر إعادة بناء الفرع. لقد حددت rsync من الكمبيوتر المحلي إلى مجلد الخادم البعيد المثبت على مجلد الحاوية.

لم أجد حلاً كاملاً على الإنترنت ، ولكن في الواقع هناك عدة خيارات:

• قم بتهيئة ftp \ ssh مباشرة في الحاوية باستخدام قاعدة الكود ، وقم بتضمينها في الصورة ، وقم بالاتصال عبر FTP مباشرة إلى الحاوية نفسها
  
  • شخصيا ، بدا لي هذا الخيار معقدًا قليلاً ، و "عكازًا" أيضًا ، رغم أن جميع الخيارات هنا عكازات
• (للاستخدام المحلي) استخدم عامل ميناء cp لتحميل التعليمات البرمجية مباشرة في الحاوية
  
  • الخيار غير مناسب للعمل مع خادم بعيد.
  • لدى docker cp وظائف محدودة للغاية ، بالنظر إلى مجلدات البائعين التي لا ينبغي نسخها في كل مرة ، وخوارزمية النسخ نفسها ، سيكون هذا بطيئًا إلى حد ما.
• (للاستخدام عن بعد \ المحلي) قم بتثبيت مجلد الحاوية المرغوب فيه على مجلد المضيف الخارجي. قم بتنزيل الملفات المحلية مباشرة إلى مجلد المضيف المحمّل. هناك بالفعل الكثير من خيارات التنفيذ:
  
  • استخدم عامل الإرساء و scp لرسو السفن بالتحديد
    
    • مرة أخرى ، أنت بحاجة إلى تهيئة البيئة ، وتكوين docker-machine ، وربما يكون ذلك منطقيًا عندما تعمل باستمرار مع خوادم مختلفة
  • في IDE ، قم بتكوين اتصال FTP مع مجلد المضيف المطلوب
    
    • يتطلب كل فرع جديد إنشاء اتصال جديد أو تغيير التعيينات
  • استخدم scp أو rsync لتحميل الملفات إلى مجلد المضيف المرغوب ، لهذا استخدم نص bash صغير وقم بتعليقه على المفاتيح الساخنة
    
    • في البداية ، يبدو الأمر معقدًا بشكل غير ضروري ، لكنه في الحقيقة ليس كذلك. البرنامج النصي نفسه بسيط قدر الإمكان وهو ضروري لأتمتة العملية بحيث لا تضطر إلى إعادة تكوين التعيينات في كل مرة

الحل نفسه: rsync + مجلدات

tldr:

• تحتاج الوصول إلى SSH الخادم البعيد و rsync على الجهاز المحلي
• يجب أن يحتوي الخادم البعيد على مجلد قابل للكتابة
• تحميل مجلد المشروع في الحاوية إلى مجلد المضيف الخارجي
• قم بإضافة نص برمجي صغير إلى جذر المشروع لمزامنة الملفات مع الخادم البعيد
• تكوين مفتاح الاختصار لتنفيذ البرنامج النصي للتزامن

تجدر الإشارة إلى أن الحل المقدم مستبعد من أجل التطوير وبيئة الاختبار

في هذه الحالة ، سألقي نظرة على بيئات عامل التأسيس و gitlab-ci ، مع عامل التهيئة باستخدام متغيرات البيئة من gitlab-ci.

نحن نشكل المسار إلى المجلد الوجهة في gitlab-ci ونصدر هذا المسار إلى docker-compose.yml:

before_script: - export SHARED_DIR_BASE='/var/www/builds' #    ,      - export SHARED_BRANCH_DIR=${SHARED_DIR_BASE}/${PROJECT_GROUP}/${PROJECT_NAME}/${CI_COMMIT_REF_NAME} #     web-123   my_group/my_project,      /var/shared/my_group/my_project/web-123 Deploy dev: stage: deploy_dev script: #   ,         - mkdir -p ${SHARED_BRANCH_DIR} - rsync -r --exclude-from=.gitignore --exclude-from=.dockerignore . ${SHARED_BRANCH_DIR} - find ${SHARED_BRANCH_DIR} -type d -exec setfacl -d -mo:rwx {} \; - find ${SHARED_BRANCH_DIR} -type d -exec setfacl -mo:rwx {} \; - find ${SHARED_BRANCH_DIR} -type f -exec setfacl -mo:rwx {} \; - envsubst < docker-compose.tmpl > docker-compose.yml #     gitlab-ci.yml  docker-compose.yml,   docker-compose.tmpl - docker-compose up -d 

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

 version: '2.3' services: web: ... volumes: - ${SHARED_BRANCH_DIR}:/app/:rw #             #        .    ,      ,           .              ,     ,        - /app/protected/vendor/ 

بالفعل التكوين الحالي كافي ، الآن عند إنشاء الفرع على الخادم المضيف ، سيتم إنشاء المجلد / var / www / builds / GROUP_NAME / PROJECT_NAME / BRANCH_NAME وسيتم نقل المشروع إلى هناك باستثناء تلك الملفات والمجلدات المحددة في .gitignore و. dockerignore يمكنك ببساطة تكوين تعيينات FTP ، لكننا سنذهب أبعد من ذلك قليلاً ونجعل العملية تلقائية أكثر قليلاً.

في الواقع ، لمزامنة الملفات ، نحتاج إلى تشغيل شيء مثل هذا:

 rsync -r -u \ --delete-after \ --exclude-from=.gitignore \ --exclude-from=.dockerignore \ . $sshUserName@$sshHost:$sharedBaseDir 

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

 #!/usr/bin/env bash #    while [ -n "$1" ] do case "$1" in --sshUserName=*) sshUserName=${1#*=} ;; --sshHost=*) sshHost=${1#*=} ;; esac shift done #  shared    gitBranch=$(git branch | grep \* | cut -d ' ' -f2) gitProject=$(git config --local remote.origin.url|sed -n 's#.*/\([^.]*\)\.git#\1#p') gitGroup=$(git config --local remote.origin.url|sed -n 's#.*/\([^.]*\)/.*\.git#\1#p') sharedBaseDir=/var/www/builds/$gitGroup/$gitProject/$gitBranch #         rsync -r -u \ --delete-after \ --exclude-from=.gitignore \ --exclude-from=.dockerignore \ . $sshUserName@$sshHost:$sharedBaseDir echo "done" 

تجدر الإشارة إلى أنه يجب وضع البرنامج النصي في جذر مجلد المشروع الخاص بالمستودع أو الإشارة إلى الدليل الذي يجب أن يعمل فيه.

يبقى فقط ربط تنفيذ هذا البرنامج النصي على مفاتيح الاختصار المحددة وتعيين المعلمتين sshUserName و sshHost (من المعلوم أن هناك بالفعل وصولاً إلى الخادم البعيد عبر ssh). كيفية القيام بذلك ، سأقدم مثالًا على PHPstorm.

• انتقل إلى ملف -> إعدادات
• في نافذة الإعدادات في القائمة اليمنى ، قم بتوسيع أدوات ، حدد أدوات خارجية
• نكتب المسار إلى البرنامج النصي ونحدد sshUserName الحقيقي و sshHost في الوسائط
  
  
• بعد ذلك ، انتقل إلى Keymap وابحث عن اسم أدواتنا الخارجية ، وقم بتعيين المجموعة اللازمة
  
  

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

لا أدعي أنني "مثالي" لهذا الحل ، فربما تكون هناك خيارات أفضل ، سأكون سعيدًا إذا علمت بها في التعليقات. شكرا لك