🐨 🙍🏽 🎅🏿 क्या दोस्तों Gitlab CI + Docker + Systemd बनाना संभव है 🧡 🤸🏻 👙

Gitlab CI रनर के अंदर Docker को Systemd के साथ लॉन्च करने का एक सूक्ष्म नोट। हो सकता है कि कोई उपयोगी होगा, हो सकता है कि किसी ने पहले से ही अन्य तरीकों से इसी तरह की समस्या को हल किया हो और यदि आप टिप्पणियों में साझा करते हैं तो यह दिलचस्प होगा।

प्रस्तावना

Gitlab Runner को Docker कंटेनर के अंदर तैनात किया गया था। कुछ बिंदु पर, संकलन चरण और ऑटोटैस्ट के बाद एप्लिकेशन इंस्टॉल करने के लिए एक कंटेनर के अंदर सभी आवश्यक बुनियादी ढांचे (उदाहरण के लिए, पोस्टग्रैसीक्यू और टॉमकैट) को इकट्ठा करने के लिए विचार आया। इन्फ्रास्ट्रक्चर कंटेनर को पहले से ही सिस्टमड के साथ डेबियन छवि के आधार पर बनाया गया था और पूरी तरह से काम किया था। लेकिन जब रनर के अंदर इस्तेमाल किया गया, तो अप्रत्याशित समस्याएं शुरू हो गईं। सरलता के लिए कदम कोड था, चलो यह कहते हैं:

run-autotests: image: debian/systemd before_script: - cp backend.jar /opt/ - cd /opt script: - java -jar autotests.jar

सब कुछ सामान्य लग रहा है, लेकिन स्टार्टअप पर कदम एक त्रुटि के साथ विफल हो जाएगा कि ID 1 के साथ एक प्रक्रिया के रूप में systemd नहीं चल रहा है या शायद एक और त्रुटि यह होगी कि systemd बिल्कुल भी नहीं चल रहा है।

क्या समस्या होगी?

जैसा कि यह निकला - गीतालाब पर एक ताजा मुद्दे पर, मैं केवल इस समस्या का सामना करने वाला नहीं था।
समस्या यह है कि डॉकटर कंटेनर के लिए गिटलैब धावक हमेशा सीएमडी कमांड को अधिलेखित करता है, अर्थात। इस आदेश के साथ कंटेनर प्रारंभ करता है:

 docker run --cmd /bin/bash ...

और गिटलैब सीएमडी को फिर से परिभाषित करना असंभव है, आप केवल ci स्क्रिप्ट के अंदर प्रविष्टि का उपयोग कर सकते हैं, लेकिन इसके साथ नृत्य करने से कुछ भी नहीं हुआ।

सभी भूमिकाओं को अणु परीक्षणों द्वारा कवर किया गया था और उन्होंने गितलब रनर के अंदर परीक्षणों को सफलतापूर्वक पारित किया। इस पर ध्यान देने के बाद, मैंने सोचा, क्यों न लॉन्च किए गए रनर के अंदर सिस्टमड के साथ कंटेनर को लॉन्च किया जाए, जी * मोर, बेशक, लेकिन परिणाम मेरे लिए कठिनाइयों से अधिक महत्वपूर्ण था। डॉकटर कमांडों का उपयोग करके कंटेनर को केवल लॉन्च करना संभव है, लेकिन यह प्रभावी नहीं है, और किसी भी त्रुटि से निपटने में नहीं होगा - किसी भी तरह यह बहुत अधिक अनुमानित नहीं हो सकता है, इसलिए मैंने पायथन में एक छोटे से हाथ से बना लेख लिखने का फैसला किया जो सिर्फ कंटेनर को लॉन्च करेगा, आवश्यक के साथ संग्रह को कॉपी करें। फ़ाइलें और कंटेनर के अंदर आदेशों की एक सूची निष्पादित करें।

→ यहाँ कोड है: 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 #   [--network host] #     [--volumes] "/sys/fs/cgroup:/sys/fs/cgroup:ro" "<>" #  volume   systemd,      [--cmd] "/lib/systemd/systemd" # ,      ,      [--data-archive] /opt/data.tar #     *.tar  *.tar.gz [--data-unarchive-path] /opt/data/logs #     ,      [--privileged] #   systemd ,        --exec-commands "touch /opt/example.log" "{bash} ls -la /opt" "mkdir -p /opt/tmp" #

[] में कमांड वैकल्पिक हैं। कमांड के लिए एक विशेष {bash} मैक्रो की आवश्यकता होती है, जिसके लिए एक शेल की आवश्यकता होती है, उदाहरण के लिए, ls -la और अन्य। यह रनटाइम पर / bin / bash -c "कमांड" द्वारा प्रतिस्थापित किया जाएगा।

मैंने पहली बार पायथन में लिखा था, इसलिए डांटना नहीं। शायद कोड में या स्टार्टअप में कोई समस्या होगी, मैं इसे जल्दी ठीक करने की कोशिश करूंगा। यहां मैंने एक स्टार्टअप विधि के सामान्य सरल विचार को समझाने की कोशिश की। यदि आपके पास समान समस्याएं हैं तो अपने अनुभव साझा करें।

नाटकीयता / docker-debian-systemd द्वारा उपयोग की जाने वाली छवि के बारे में

इस छवि के बारे में कोई शिकायत नहीं है, लेकिन पहली बार में एक त्रुटि हुई थी जो मेजबान मशीन के कंसोल में पॉप अप हुई थी, कि सिस्टम द्वारा बनाई गई कुछ फाइलें पहले से मौजूद हैं। Nginx सेवा में ऐसी कोई समस्या नहीं थी, लेकिन वे PostgreSQL में दिखाई दिए। समाधान "VOLUME [" / sys / fs / cgroup "," / run "," / run / lock "," / tmp "] ब्लॉक को हटाना था, उसके बाद सब कुछ एक घड़ी की तरह काम करता था।

क्या दोस्तों Gitlab CI + Docker + Systemd बनाना संभव है

More articles: