ملاحظة صغيرة حول كيفية إطلاق Docker مع Systemd داخل Gitlab CI Runner. ربما يكون شخص ما مفيدًا ، ربما قام شخص ما بالفعل بحل مشكلة مماثلة بطرق أخرى وسيكون من المثير للاهتمام إذا شاركت في التعليقات.
مقدمةتم نشر Gitlab Runner داخل حاوية Docker. في مرحلة ما ، ظهرت الفكرة لجمع جميع البنية التحتية اللازمة (على سبيل المثال ، PostgreSQL و Tomcat) داخل حاوية واحدة لتثبيت التطبيق بعد مرحلة التجميع والاختبارات التلقائية. تم بناء حاوية البنية التحتية نفسها بالفعل بناءً على صورة دبيان مع Systemd وعملت بشكل مثالي. ولكن عند استخدامها داخل Runner ، بدأت مشاكل غير متوقعة. رمز الخطوة ، من أجل البساطة ، دعنا نقول هذا:
run-autotests: image: debian/systemd before_script: - cp backend.jar /opt/ - cd /opt script: - java -jar autotests.jar
يبدو أن كل شيء طبيعي ، ولكن عند بدء التشغيل ستفشل الخطوة مع وجود خطأ في أن systemd لا يعمل كعملية ذات معرف 1 أو ربما خطأ آخر هو أن systemd لا يعمل على الإطلاق.
ماذا ستكون المشكلة؟
كما اتضح - في قضية جديدة على Gitlab نفسها ، لم أكن الوحيد الذي واجه هذه المشكلة.
تكمن المشكلة في أن Gitlab Runner لحاوية Docker دائمًا ما يستبدل أمر CMD ، أي يبدأ الحاوية بهذا الأمر:
docker run --cmd /bin/bash ...
ومن المستحيل إعادة تعريف Gitlab CMD ، يمكنك فقط استخدام نقطة الدخول داخل البرنامج النصي ci ، لكن الرقص معه لم يؤد إلى أي شيء.
تم تغطية جميع الأدوار من خلال اختبارات الجزيء واجتازوا الاختبارات بنجاح داخل عداء GitLab. بعد الانتباه إلى ذلك ، فكرت ، لماذا لا تطلق الحاوية مع systemd داخل Runner ، g * mor ، بالطبع ، ولكن النتيجة كانت أكثر أهمية بالنسبة لي من الصعوبات. من الممكن ببساطة إطلاق حاوية باستخدام أوامر عامل إرساء ، ولكنها ليست فعالة ، ولن يكون هناك أي خطأ في المعالجة - بطريقة ما قد لا يمكن التنبؤ بها كثيرًا ، لذلك قررت كتابة مقالة صغيرة مصنوعة يدويًا في Python من شأنها إطلاق الحاوية فقط ، ونسخ الأرشيف مع ما يلزم الملفات وتنفيذ قائمة الأوامر داخل الحاوية.
→ الكود هنا:
GitHubيمكنك تشغيله على النحو التالي:
cd <path-with-code> pip install virtualenv virtualenv venv source venv/bin/activate pip install -r requirements.txt python main.py \ --image dramaturg/docker-debian-systemd
الأوامر في [] اختيارية. هناك حاجة إلى ماكرو {bash} خاص للأوامر التي تتطلب shell ، على سبيل المثال ، ls -la وغيرها ، وسيتم استبداله بـ
/ bin / bash -c "command" في وقت التشغيل.
لقد كتبت في Python لأول مرة ، لذلك لا توبخ. ربما ستكون هناك مشاكل في الرمز أو عند بدء التشغيل ، سأحاول إصلاحه بسرعة. حاولت هنا شرح الفكرة العامة البسيطة لأسلوب بدء التشغيل. شارك تجاربك إذا كان لديك مشاكل مماثلة.
حول الصورة المستخدمة من قبل المسرحي / docker-debian-systemdلا توجد شكاوى حول هذه الصورة ، ولكن في البداية كان هناك خطأ ظهر في وحدة تحكم الجهاز المضيف ، وهو أن بعض الملفات التي أنشأها النظام موجودة بالفعل. لم يكن هناك مثل هذه المشكلة في خدمة Nginx ، لكنها ظهرت في PostgreSQL. كان الحل هو حذف الكتلة "VOLUME [" / sys / fs / cgroup "،" / run "،" / run / lock "،" / tmp "]" ، بعد ذلك عمل كل شيء مثل الساعة.