أتمنى لك يومًا لطيفًا
لدينا عدة مجموعات سحابية تحتوي كل منها على عدد كبير من الأجهزة الافتراضية. نحن نستضيف هذا العمل بأكمله في Hetzner. في كل مجموعة لدينا جهاز رئيسي واحد، يتم أخذ لقطة منه وتوزيعها تلقائيًا على جميع الأجهزة الافتراضية داخل المجموعة.
لا يسمح لنا هذا المخطط باستخدام gitlab-runners بشكل طبيعي، حيث تنشأ الكثير من المشكلات عند ظهور العديد من المتسابقين المسجلين المتطابقين، مما دفعنا إلى إيجاد حل بديل وكتابة هذا المقال/الدليل.
ربما لا تكون هذه أفضل ممارسة، ولكن هذا الحل يبدو مريحًا وبسيطًا قدر الإمكان.
للحصول على البرنامج التعليمي، يرجى الاطلاع على القط.
الحزم المطلوبة على الجهاز الرئيسي:
- الثعبان
- طائرة نفاثة
- ملف بمفاتيح ssh
المبدأ العام لتطبيق سحب القناة الهضمية التلقائي على جميع الأجهزة الافتراضية هو أنك تحتاج إلى جهاز سيتم تثبيت Ansible عليه. من هذا الجهاز، سيرسل ansible أوامر git pull وسيعيد تشغيل الخدمة التي تم تحديثها. لهذه الأغراض، قمنا بإنشاء جهاز افتراضي منفصل خارج المجموعات وقمنا بتثبيته:
- الثعبان
- ansible
- عداء جيت لاب
من المشكلات التنظيمية - تحتاج إلى تسجيل gitlab-runner، وإنشاء ssh-keygen، وتحميل مفتاح ssh العام لهذا الجهاز إلى .ssh/authorized_keys على الجهاز الرئيسي، افتح المنفذ 22 ليكون غير ممكن على الجهاز الرئيسي.
الآن دعونا نقوم بتكوين ansible
لأن هدفنا هو أتمتة كل ما هو ممكن. في الملف /etc/ansible/ansible.cfg سنقوم بإلغاء التعليق على السطر host_key_checking = Falseبحيث لا يطلب ansible تأكيد الأجهزة الجديدة.
بعد ذلك، تحتاج إلى إنشاء ملف مخزون تلقائيًا لـ ansible، حيث سيأخذ عنوان IP للأجهزة التي تحتاج إلى سحب git عليها.
نقوم بإنشاء هذا الملف باستخدام واجهة برمجة تطبيقات Hetzner، ويمكنك الحصول على قائمة المضيفين من قاعدة بيانات AWS وAsure (لديك واجهة برمجة تطبيقات في مكان ما لعرض أجهزتك قيد التشغيل، أليس كذلك؟).
تعتبر بنية ملف المخزون مهمة جدًا لـ Ansible، حيث يجب أن تبدو كما يلي:
[группа]
ip-адрес
ip-адрес
[группа2]
ip-адрес
ip-адресلإنشاء مثل هذا الملف، سنقوم بإنشاء برنامج نصي بسيط (دعنا نسميه vm_list):
#!/bin/bash
echo [group] > /etc/ansible/cloud_ip &&
"ваш CLI запрос на получение IP запущенных машин в кластере" >> /etc/ansible/cloud_ip
echo " " >> /etc/ansible/cloud_ip
echo [group2] > /etc/ansible/cloud_ip &&
"ваш CLI запрос на получение IP запущенных машин в другом кластере" >> /etc/ansible/cloud_ipحان الوقت للتأكد من أن Ansible يعمل ويتوافق مع تلقي عناوين IP:
/etc/ansible/./vm_list && ansible -i /etc/ansible/cloud_ip -m shell -a 'hostname' group
يجب أن يحتوي الإخراج على أسماء المضيفين للأجهزة التي تم تنفيذ الأمر عليها.
بضع كلمات حول بناء الجملة:
- /etc/ansible/./vm_list - إنشاء قائمة بالأجهزة
- -i - المسار المطلق لملف المخزون
- -m - أخبر أنه من غير الممكن استخدام وحدة الصدفة
- -أ هي الحجة. يمكن إدخال أي أمر هنا
- المجموعة - اسم مجموعتك. إذا كنت بحاجة إلى القيام بذلك على كافة المجموعات، قم بتغيير المجموعة إلى الكل
لنذهب أبعد من ذلك - فلنحاول تنفيذ git pull على أجهزتنا الافتراضية:
/etc/ansible/./vm_list && ansible -i /etc/ansible/cloud_ip -m shell -a 'cd /path/to/project && git pull' group إذا رأينا في الإخراج أنه تم تحديثه بالفعل أو تم التفريغ من المستودع، فهذا يعني أن كل شيء يعمل.
الآن هذا هو ما كان المقصود من كل ذلك
دعونا نعلم البرنامج النصي الخاص بنا أن يعمل تلقائيًا عند الالتزام بالفرع الرئيسي في gitlab
أولاً، دعونا نجعل البرنامج النصي الخاص بنا أكثر جمالاً ونضعه في ملف قابل للتنفيذ (دعنا نسميه exec_pull) -
#!/bin/bash
/etc/ansible/./get_vms && ansible -i /etc/ansible/cloud_ip -m shell -a "$@"
دعنا نذهب إلى gitlab الخاص بنا ونقوم بإنشاء ملف في المشروع .gitlab-ci.yml
ونضع داخله ما يلي:
variables:
GIT_STRATEGY: none
VM_GROUP: group
stages:
- pull
- restart
run_exec_pull:
stage: pull
script:
- /etc/ansible/exec_pull 'cd /path/to/project/'$CI_PROJECT_NAME' && git pull' $VM_GROUP
only:
- master
run_service_restart:
stage: restart
script:
- /etc/ansible/exec_pull 'your_app_stop && your_app_start' $VM_GROUP
only:
- master كل شيء جاهز. الآن -
- جعل الالتزام
- أنا سعيد لأن كل شيء يعمل
عند نقل .yml إلى مشاريع أخرى، تحتاج فقط إلى تغيير اسم الخدمة المراد إعادة تشغيلها واسم المجموعة التي سيتم تنفيذ الأوامر غير المرئية عليها.
المصدر: www.habr.com