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

इस काम के लिए प्रेरणा साइट kubernetes.io थी , जो स्वचालित रूप से स्रोत कोड से उत्पन्न होती है, और प्रत्येक भेजे गए पूल के लिए, रोबोट स्वचालित रूप से आपके परिवर्तनों के साथ साइट का पूर्वावलोकन संस्करण उत्पन्न करता है और देखने के लिए एक लिंक प्रदान करता है।

मैंने स्क्रैच से एक समान प्रक्रिया बनाने की कोशिश की, लेकिन पूरी तरह से गिटलैब सीआई और मुफ्त टूल पर आधारित है जिसका उपयोग मैं कुबेरनेट्स में एप्लिकेशन को तैनात करने के लिए करता था। आज मैं अंत में आपको उनके बारे में अधिक बताऊंगा।

लेख इस तरह के उपकरणों पर विचार करेगा:
ह्यूगो , क्यूबेक , कानिको , गिट-क्रिप्ट और गितलाब सीआई गतिशील वातावरण के निर्माण के साथ।

अंतर्वस्तु

1. पेश है ह्यूगो
2. डॉकरफाइल तैयार करना
3. कानिको के साथ परिचित होना
4. पेश है क्यूबेक
5. कुबेरनेत्स-निष्पादक के साथ गिटलब-रनर की कोशिश करना
6. क्यूबेक के साथ हेल्म चार्ट की तैनाती
7. पेश है गिट-क्रिप्ट
8. टूलबॉक्स छवि बनाएं
9. टैग द्वारा हमारी पहली पाइपलाइन और छवियों की विधानसभा
10. परिनियोजन स्वचालन
11. कलाकृतियों और धक्का मास्टर में निर्माण
12. गतिशील वातावरण
13. ऐप्स की समीक्षा करें

1. ह्यूगो का परिचय

हमारी परियोजना के एक उदाहरण के रूप में, हम ह्यूगो पर निर्मित प्रलेखन प्रकाशन के लिए एक वेबसाइट बनाने की कोशिश करेंगे। ह्यूगो एक स्थिर सामग्री जनरेटर है।

जो लोग स्थैतिक जनरेटर से परिचित नहीं हैं, मैं आपको उनके बारे में थोड़ा और बताऊंगा। नियमित डेटाबेस साइट इंजनों और कुछ php इंजनों के विपरीत, जो किसी उपयोगकर्ता द्वारा प्रेरित किए जाने पर, मक्खी पर पृष्ठ उत्पन्न करते हैं, स्थैतिक जनरेटर को थोड़ा अलग तरीके से व्यवस्थित किया जाता है। वे आपको स्रोत लेने की अनुमति देते हैं, एक नियम के रूप में यह मार्कडाउन मार्कअप और थीम टेम्प्लेट में फ़ाइलों का एक सेट है, फिर उन्हें पूरी तरह से तैयार साइट में संकलित करें।

यही है, आउटपुट पर आपको निर्देशिका संरचना और जेनरेट की गई html-files का एक सेट मिलेगा, जिसे बस किसी भी सस्ते होस्टिंग पर अपलोड किया जा सकता है और एक वर्किंग साइट मिल सकती है।

ह्यूगो स्थानीय रूप से स्थापित किया जा सकता है और इसे आज़मा सकते हैं:

हम नई साइट को इनिशियलाइज़ करते हैं:

hugo new site docs.example.org 

और एक ही समय में गिट रिपॉजिटरी:

 cd docs.example.org git init 

अब तक, हमारी साइट प्राचीन है और इस पर कुछ दिखाई देने के लिए सबसे पहले हमें एक थीम, एक थीम कनेक्ट करने की आवश्यकता है - यह सिर्फ टेम्पलेट्स का एक सेट और प्रीसेट नियम है जिसके द्वारा हमारी साइट उत्पन्न होती है।

एक विषय के रूप में, हम Learn का उपयोग करेंगे, जो, मेरी राय में, प्रलेखन वाली साइट के लिए सबसे उपयुक्त है।

मैं इस तथ्य पर विशेष ध्यान देना चाहूंगा कि हमें अपनी परियोजना के भंडार में थीम फ़ाइलों को सहेजने की आवश्यकता नहीं है, इसके बजाय हम इसे गिट सबमॉड्यूल का उपयोग करके कनेक्ट कर सकते हैं:

 git submodule add https://github.com/matcornic/hugo-theme-learn themes/learn 

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

Config.toml config को ठीक करें:

 baseURL = "http://docs.example.org/" languageCode = "en-us" title = "My Docs Site" theme = "learn" 

पहले से ही इस स्तर पर, आप चला सकते हैं:

 hugo server 

और http: // localhost: 1313 पर / हमारी नई बनाई गई साइट की जाँच करें, निर्देशिका में किए गए सभी परिवर्तन स्वचालित रूप से अपडेट हो जाते हैं और ब्राउज़र में खुला पृष्ठ बहुत सुविधाजनक है!

चलिए कंटेंट / _index.md में एक कवर पेज बनाने की कोशिश करते हैं:

 # My docs site ## Welcome to the docs! You will be very smart :-) 

साइट बनाने के लिए, बस चलाएं:

 hugo 

सार्वजनिक / निर्देशिका की सामग्री आपकी साइट होगी।
हाँ, वैसे, तुरंत इसे .gitignore में जोड़ें:

 echo /public > .gitignore 

हमारे परिवर्तन करने के लिए मत भूलना:

 git add . git commit -m "New site created" 

2. डॉकरफाइल तैयार करना

यह हमारे भंडार की संरचना को निर्धारित करने का समय है। आमतौर पर मैं कुछ का उपयोग करता हूं जैसे:

 . ├── deploy │ ├── app1 │ └── app2 └── dockerfiles ├── image1 └── image2 

• dockerfiles / - Dockerfiles के साथ निर्देशिकाएं शामिल हैं और आपको हमारे docker छवियों को बनाने की आवश्यकता है।
• तैनात / - कुबेरनेट्स के लिए हमारे अनुप्रयोगों को तैनात करने के लिए निर्देशिकाएं शामिल हैं

इस प्रकार, हम पथ dockerfiles / वेबसाइट / Dockerfile के साथ अपना पहला Dockerfile बनाएंगे

 FROM alpine:3.11 as builder ARG HUGO_VERSION=0.62.0 RUN wget -O- https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_${HUGO_VERSION}_linux-64bit.tar.gz | tar -xz -C /usr/local/bin ADD . /src RUN hugo -s /src FROM alpine:3.11 RUN apk add --no-cache darkhttpd COPY --from=builder /src/public /var/www ENTRYPOINT [ "/usr/bin/darkhttpd" ] CMD [ "/var/www" ] 

जैसा कि आप देख सकते हैं, डॉकरीफाइल में दो FROM शामिल हैं, इस सुविधा को मल्टी-स्टेज बिल्ड कहा जाता है और आपको अंतिम docker छवि से अनावश्यक सब कुछ बाहर करने की अनुमति देता है।
इस प्रकार, अंतिम छवि में केवल darkhttpd (एक हल्का HTTP सर्वर) और सार्वजनिक / - हमारी सांख्यिकीय रूप से उत्पन्न साइट की सामग्री शामिल होगी।

हमारे परिवर्तन करने के लिए मत भूलना:

 git add dockerfiles/website git commit -m "Add Dockerfile for website" 

3. कानिको के साथ परिचित होना

Docker की छवियों के संग्रहकर्ता के रूप में, मैंने kaniko का उपयोग करने का निर्णय लिया, क्योंकि इसे काम करने के लिए docker डेमॉन की आवश्यकता नहीं है, और असेंबली को किसी भी मशीन पर किया जा सकता है और कैश को सीधे रजिस्ट्री में संग्रहीत किया जा सकता है, जिससे एक पूर्ण भंडारण की आवश्यकता होती है ।

छवि बनाने के लिए, बस कनिको एक्ज़ीक्यूटर के साथ कंटेनर शुरू करें और वर्तमान निर्माण के संदर्भ को पास करें, आप इसे स्थानीय रूप से, docker द्वारा कर सकते हैं:

 docker run -ti --rm \ -v $PWD:/workspace \ -v ~/.docker/config.json:/kaniko/.docker/config.json:ro \ gcr.io/kaniko-project/executor:v0.15.0 \ --cache \ --dockerfile=dockerfiles/website/Dockerfile \ --destination=registry.gitlab.com/kvaps/docs.example.org/website:v0.0.1 

जहाँ रजिस्ट्री .itlab.com/kvaps/docs.example.org/website आपकी डॉकटर छवि का नाम है, असेंबली के बाद यह स्वतः डॉकटर रजिस्टर में धकेल दिया जाएगा।

Thecache पैरामीटर आपको docker रजिस्ट्री में परतों को कैश करने की अनुमति देता है, दिए गए उदाहरण के लिए उन्हें रजिस्ट्री में सहेजा जाएगा ।gitlab.com/kvaps/docs.example.org/website/cache , लेकिन आप .cache- पैरामीटर का उपयोग करके एक और पथ निर्दिष्ट कर सकते हैं रेपो ।

4. क्यूबेक के साथ परिचित

क्यूबेक एक तैनाती उपकरण है जो आपको अपने आवेदन की अभिव्यक्ति का वर्णन करने और इसे कुबेरनेट्स पर तैनात करने की अनुमति देता है। मुख्य वाक्यविन्यास के रूप में Jsonnet का उपयोग करना आपको कई वातावरणों के लिए मतभेदों के विवरण को सरल बनाने की अनुमति देता है, और कोड पुनरावृत्ति को भी लगभग पूरी तरह से समाप्त कर देता है।

यह उन मामलों में विशेष रूप से सच हो सकता है जहां आपको विभिन्न मापदंडों के साथ कई समूहों में एक एप्लिकेशन को तैनात करने की आवश्यकता होती है और आप उन्हें जीआईटी में घोषित करना चाहते हैं।

क्यूबेक आपको आवश्यक मापदंडों को पार करके और बाद में उन्हें नियमित रूप से घोषणापत्र के साथ-साथ उन विभिन्न म्यूटेशनों सहित लागू कर सकता है जो हेल्म चार्ट को प्रस्तुत करने की अनुमति देता है, और यह बदले में, चार्टम्यूज का उपयोग करने की आवश्यकता को समाप्त करता है। यही है, आप चार्ट को सीधे गिट से स्टोर और रेंडर कर सकते हैं, जहां उनके पास जगह है।

जैसा कि मैंने पहले कहा था, हम सभी तैनाती को तैनाती / निर्देशिका में संग्रहीत करेंगे:

 mkdir deploy cd deploy 

चलो हमारे पहले आवेदन को इनिशियलाइज़ करते हैं:

 qbec init website cd website 

अब हमारे आवेदन की संरचना इस प्रकार है:

 . ├── components ├── environments │  ├── base.libsonnet │  └── default.libsonnet ├── params.libsonnet └── qbec.yaml 

qbec.yaml फ़ाइल देखें:

 apiVersion: qbec.io/v1alpha1 kind: App metadata: name: website spec: environments: default: defaultNamespace: docs server: https://kubernetes.example.org:8443 vars: {} 

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

आपके सभी वातावरण qbec.yaml में वर्णित हैं, और params.libsonnet फ़ाइल में, जहां यह कहता है कि आपको उनके लिए पैरामीटर लेने की आवश्यकता है।

आगे हम दो निर्देशिकाएँ देखते हैं:

• घटक / - हमारे आवेदन के लिए सभी अभिव्यक्तियाँ यहाँ संग्रहीत की जाएंगी, उन्हें जोंसनेट और साधारण याम्ल-फ़ाइलों दोनों में वर्णित किया जा सकता है
• वातावरण / - यहाँ हम अपने वातावरण के लिए सभी चर (मापदंडों) का वर्णन करेंगे।

डिफ़ॉल्ट रूप से, हमारे पास दो फाइलें हैं:

• वातावरण / base.libsonnet - इसमें सभी वातावरणों के लिए सामान्य पैरामीटर होंगे
• वातावरण / default.libsonnet - में डिफ़ॉल्ट वातावरण के लिए ओवरराइड पैरामीटर हैं

चलो वातावरण खोलें / base.libsonnet और हमारे पहले घटक के लिए पैरामीटर जोड़ें:

 { components: { website: { name: 'example-docs', image: 'registry.gitlab.com/kvaps/docs.example.org/website:v0.0.1', replicas: 1, containerPort: 80, servicePort: 80, nodeSelector: {}, tolerations: [], ingressClass: 'nginx', domain: 'docs.example.org', }, }, } 

हम अपने पहले कंपोनेंट कंपोनेंट्स / वेबसाइट.jsonnet भी बनाएंगे:

 local env = { name: std.extVar('qbec.io/env'), namespace: std.extVar('qbec.io/defaultNs'), }; local p = import '../params.libsonnet'; local params = p.components.website; [ { apiVersion: 'apps/v1', kind: 'Deployment', metadata: { labels: { app: params.name }, name: params.name, }, spec: { replicas: params.replicas, selector: { matchLabels: { app: params.name, }, }, template: { metadata: { labels: { app: params.name }, }, spec: { containers: [ { name: 'darkhttpd', image: params.image, ports: [ { containerPort: params.containerPort, }, ], }, ], nodeSelector: params.nodeSelector, tolerations: params.tolerations, imagePullSecrets: [{ name: 'regsecret' }], }, }, }, }, { apiVersion: 'v1', kind: 'Service', metadata: { labels: { app: params.name }, name: params.name, }, spec: { selector: { app: params.name, }, ports: [ { port: params.servicePort, targetPort: params.containerPort, }, ], }, }, { apiVersion: 'extensions/v1beta1', kind: 'Ingress', metadata: { annotations: { 'kubernetes.io/ingress.class': params.ingressClass, }, labels: { app: params.name }, name: params.name, }, spec: { rules: [ { host: params.domain, http: { paths: [ { backend: { serviceName: params.name, servicePort: params.servicePort, }, }, ], }, }, ], }, }, ] 

इस फ़ाइल में हमने तुरंत तीन कुबेरनेट संस्थाओं का वर्णन किया, ये हैं: तैनाती , सेवा और प्रगति । यदि वांछित है, तो हम उन्हें विभिन्न घटकों में ले जा सकते हैं, लेकिन इस स्तर पर, हमारे लिए पर्याप्त है।

Jsonnet सिंटैक्स नियमित json के समान होता है, सिद्धांत रूप में json पहले से ही मान्य jsonnet है, इसलिए सबसे पहले आपके सामान्य yaml को json में बदलने के लिए yaml2json जैसी ऑनलाइन सेवाओं का उपयोग करना आसान हो सकता है, या यदि आपके घटकों में कोई चर नहीं है, तो उन्हें साधारण यम के रूप में वर्णित किया जा सकता है।

Jsonnet के साथ काम करते समय, मैं आपके संपादक के लिए एक प्लगइन स्थापित करने की अत्यधिक सलाह देता हूं

उदाहरण के लिए, vim के लिए एक vim-jsonnet प्लगइन है जो सिंटैक्स हाइलाइटिंग को चालू करता है और सहेजे जाने पर प्रत्येक बार jsonnet fmt को स्वचालित रूप से करता है (इसे jsonnet इंस्टॉल करने की आवश्यकता होती है)।

सब कुछ तैयार है, अब हम तैनाती शुरू कर सकते हैं:

क्या हुआ, यह देखने के लिए हम करेंगे:

 qbec show default 

आउटपुट पर, आप रेंडर किए गए यम मैनिफ़ेस्ट देखेंगे जो डिफ़ॉल्ट क्लस्टर पर लागू होगा।

ठीक है, अब आवेदन करें:

 qbec apply default 

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

हो गया, अब हमारा आवेदन डॉक हो गया है!

यदि आप परिवर्तन करते हैं, तो आप हमेशा कर सकते हैं:

 qbec diff default 

यह देखने के लिए कि ये परिवर्तन वर्तमान तैनाती को कैसे प्रभावित करेंगे

हमारे परिवर्तन करने के लिए मत भूलना:

 cd ../.. git add deploy/website git commit -m "Add deploy for website" 

5. कुबेरनेट्स-निष्पादक के साथ गिटलब-रनर की कोशिश करना

कुछ समय पहले तक, मैं एक पूर्व-तैयार मशीन (एलएक्ससी कंटेनर) पर शेल या डॉक-एग्ज़िक्यूटर के साथ केवल सामान्य गिटलैब-रनर का उपयोग करता था। प्रारंभ में, हमारे पास कई ऐसे धावक थे जो विश्व स्तर पर हमारे हिटलैब में परिभाषित थे। उन्होंने सभी परियोजनाओं के लिए डॉकटर चित्र एकत्र किए।

लेकिन जैसा कि अभ्यास से पता चला है, यह विकल्प व्यावहारिकता और सुरक्षा के संदर्भ में, सबसे आदर्श नहीं है। प्रत्येक प्रोजेक्ट के लिए और यहां तक ​​कि प्रत्येक वातावरण के लिए अलग-अलग धावकों को तैनात करना बेहतर और वैचारिक रूप से अधिक सही है।

सौभाग्य से, यह बिल्कुल भी समस्या नहीं है, क्योंकि अब हम अपनी परियोजना के हिस्से के रूप में कुबेरनेट्स को सीधे गीतालाब-धावक तैनात करेंगे।

Gitlab कुबेरनेट्स में gitlab-runner को तैनात करने के लिए तैयार हेलम चार्ट प्रदान करता है। इस प्रकार, आपको बस इतना करना है कि सेटिंग में हमारे प्रोजेक्ट के लिए पंजीकरण टोकन पता करें -> CI / CD -> धावक और इसे पास करें:

 helm repo add gitlab https://charts.gitlab.io helm install gitlab-runner \ --set gitlabUrl=https://gitlab.com \ --set runnerRegistrationToken=yga8y-jdCusVDn_t4Wxc \ --set rbac.create=true \ gitlab/gitlab-runner 

जहां:

• https://gitlab.com आपके Gitlab सर्वर का पता है।
• yga8y-jdCusVDn_t4Wxc - आपके प्रोजेक्ट के लिए पंजीकरण टोकन।
• rbac.create = true - धावक कुबेरनेट्स-निष्पादक का उपयोग करके हमारे कार्यों को करने के लिए पॉड्स बनाने में सक्षम होने के लिए आवश्यक विशेषाधिकार की संख्या देता है।

यदि सब कुछ सही ढंग से किया गया है, तो आपको अपनी परियोजना की सेटिंग्स में, धावक अनुभाग में पंजीकृत धावक को देखना चाहिए।

क्या यह इतना आसान है? - हाँ, इतना आसान! मैन्युअल रूप से पंजीकृत धावकों के साथ कोई और परेशानी नहीं है, अब से धावकों को स्वचालित रूप से बनाया और नष्ट कर दिया जाएगा।

6. QBEC के साथ हेलम चार्ट की तैनाती

चूंकि हमने अपने प्रोजेक्ट के गिटलैब-रनर भाग पर विचार करने का फैसला किया है, इसलिए हमारे गिट रिपॉजिटरी में इसका वर्णन करने का समय है।

हम इसे वेबसाइट के एक अलग घटक के रूप में वर्णित कर सकते हैं, लेकिन भविष्य में हम वेबसाइट की अलग-अलग प्रतियों को तैनात करने की योजना बना रहे हैं, अक्सर गिटलब-रनर के विपरीत, जिसे प्रत्येक कुबेरनेट क्लस्टर के लिए केवल एक बार तैनात किया जाएगा। तो चलिए इसके लिए एक अलग एप्लिकेशन को इनिशियलाइज़ करते हैं:

 cd deploy qbec init gitlab-runner cd gitlab-runner 

इस बार हम मैन्युअल रूप से कुबेरनेट्स संस्थाओं का वर्णन नहीं करेंगे, लेकिन तैयार हेलम चार्ट लें। क्यूबेक के फायदों में से एक हेलित चार्ट को सीधे गिट रिपॉजिटरी से रेंडर करने की क्षमता है।

आइए इसे गिट सबमॉड्यूल का उपयोग करके प्लग करें:

 git submodule add https://gitlab.com/gitlab-org/charts/gitlab-runner vendor/gitlab-runner 

अब वेंडर / गिट्लाब-रनर डायरेक्टरी में गिटलैब-रनर के लिए एक चार्ट के साथ हमारी रिपॉजिटरी है।

इसी तरह, आप अन्य रिपॉजिटरी को कनेक्ट कर सकते हैं, उदाहरण के लिए, आधिकारिक चार्ट के साथ संपूर्ण रिपॉजिटरी https://github.com/helm/charts

आइए घटकों का वर्णन करें / gitlab-runner.jsonnet घटक :

 local env = { name: std.extVar('qbec.io/env'), namespace: std.extVar('qbec.io/defaultNs'), }; local p = import '../params.libsonnet'; local params = p.components.gitlabRunner; std.native('expandHelmTemplate')( '../vendor/gitlab-runner', params.values, { nameTemplate: params.name, namespace: env.namespace, thisFile: std.thisFile, verbose: true, } ) 

विस्तार करने के लिए पहला तर्कहेल्मेटप्लेट हम चार्ट के लिए रास्ता पास करते हैं, फिर params.values , जिसे हम पर्यावरण मापदंडों से लेते हैं, फिर एक वस्तु के साथ

• nameTemplate - रिलीज़ नाम
• namespace - namespace ने helm को पास किया
• यह फ़ाइल - आवश्यक पैरामीटर वर्तमान फ़ाइल के लिए पथ गुजर रहा है
• वर्बोज़ - चार्ट को प्रस्तुत करते समय सभी तर्कों के साथ पतवार टेम्पलेट कमांड दिखाता है

अब हम वातावरण / बेस में हमारे घटक के मापदंडों का वर्णन करेंगे।

 local secrets = import '../secrets/base.libsonnet'; { components: { gitlabRunner: { name: 'gitlab-runner', values: { gitlabUrl: 'https://gitlab.com/', rbac: { create: true, }, runnerRegistrationToken: secrets.runnerRegistrationToken, }, }, }, } 

RunnerRegistrationToken पर ध्यान दें, हम बाहरी रहस्यों / आधार.लिब्सननेट फ़ाइल से लेते हैं , आइए इसे बनाएँ:

 { runnerRegistrationToken: 'yga8y-jdCusVDn_t4Wxc', } 

जांचें कि क्या सब कुछ काम करता है:

 qbec show default 

यदि सब कुछ क्रम में है, तो हम अपने पहले रिलीज को हेल्म रिलीज के माध्यम से हटा सकते हैं:

 helm uninstall gitlab-runner 

और इसे तैनात करें, लेकिन पहले से ही क्यूबेक के माध्यम से:

 qbec apply default 

7. गिट-क्रिप्ट का परिचय

गिट-क्रिप्ट एक उपकरण है जो आपको अपने रिपॉजिटरी के लिए पारदर्शी एन्क्रिप्शन सेट करने देता है।

फिलहाल, गिटलैब-रनर के लिए हमारी निर्देशिका की संरचना इस प्रकार है:

 . ├── components │  ├── gitlab-runner.jsonnet ├── environments │  ├── base.libsonnet │  └── default.libsonnet ├── params.libsonnet ├── qbec.yaml ├── secrets │  └── base.libsonnet └── vendor └── gitlab-runner (submodule) 

लेकिन Git में रहस्य रखना सुरक्षित नहीं है, है ना? इसलिए हमें उन्हें ठीक से एन्क्रिप्ट करने की आवश्यकता है।

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

इसके अलावा, इस मामले में, मैं आपको गिट-क्रिप्ट जैसे अद्भुत उपकरण के बारे में नहीं बता पाऊंगा।

गिट-क्रिप्ट भी सुविधाजनक है क्योंकि यह आपको रहस्यों के पूरे इतिहास को सहेजने की अनुमति देता है, साथ ही साथ टकराव की तुलना, विलय और समाधान उसी तरह से करता है जैसे हम गिट के मामले में करते थे।

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

 git crypt init 

यदि आपके पास PGP कुंजी है, तो आप तुरंत इस परियोजना के लिए सहयोगी के रूप में खुद को जोड़ सकते हैं:

 git-crypt add-gpg-user kvapss@gmail.com 

इस प्रकार, आप हमेशा अपनी निजी कुंजी का उपयोग करके इस भंडार को डिक्रिप्ट कर सकते हैं।

यदि आपके पास PGP कुंजी नहीं है और आप अपेक्षित नहीं हैं, तो आप दूसरे तरीके से जा सकते हैं और परियोजना की कुंजी निर्यात कर सकते हैं:

 git crypt export-key /path/to/keyfile 

इस तरह, एक निर्यात कुंजी के साथ कोई भी आपके भंडार को डिक्रिप्ट कर सकेगा।

यह हमारे पहले रहस्य को स्थापित करने का समय है।
मैं आपको याद दिलाता हूं कि हम अभी भी तैनात / gitlab-runner / निर्देशिका में हैं, जहां हमारे पास रहस्य / निर्देशिका हैं, चलो इसमें सभी फाइलों को एन्क्रिप्ट करते हैं, इसके लिए हम निम्नलिखित सामग्री के साथ रहस्य / .itattributes फ़ाइल बनाते हैं:

 * filter=git-crypt diff=git-crypt .gitattributes !filter !diff 

जैसा कि आप सामग्री से देख सकते हैं, नकाब * द्वारा सभी फाइलें गीता -क्रिप्ट के माध्यम से चलेंगी।

हम इसे चलाकर सत्यापित कर सकते हैं:

 git crypt status -e 

आउटपुट पर, हमें रिपॉजिटरी में सभी फाइलों की एक सूची मिलती है जिसके लिए एन्क्रिप्शन सक्षम है

बस, अब हम सुरक्षित रूप से अपने बदलाव कर सकते हैं:

 cd ../.. git add . git commit -m "Add deploy for gitlab-runner" 

भंडार को अवरुद्ध करने के लिए, बस करें:

 git crypt lock 

और फिर सभी एन्क्रिप्टेड फाइलें एक बाइनरी में बदल जाती हैं, उन्हें पढ़ना असंभव होगा।
एक भंडार को डिक्रिप्ट करने के लिए, करें:

 git crypt unlock 

8. एक टूलबॉक्स छवि बनाएं

एक टूलबॉक्स छवि सभी उपकरणों के साथ एक ऐसी छवि है जिसका उपयोग हम अपनी परियोजना को तैनात करने के लिए करेंगे। इसका उपयोग gitlab धावक द्वारा विशिष्ट परिनियोजन कार्य करने के लिए किया जाएगा।

यहां सब कुछ सरल है, हम निम्नलिखित सामग्री के साथ एक नया डॉकफाइल्स / टूलबॉक्स / डॉकफेराइल बनाते हैं :

 FROM alpine:3.11 RUN apk add --no-cache git git-crypt RUN QBEC_VER=0.10.3 \ && wget -O- https://github.com/splunk/qbec/releases/download/v${QBEC_VER}/qbec-linux-amd64.tar.gz \ | tar -C /tmp -xzf - \ && mv /tmp/qbec /tmp/jsonnet-qbec /usr/local/bin/ RUN KUBECTL_VER=1.17.0 \ && wget -O /usr/local/bin/kubectl \ https://storage.googleapis.com/kubernetes-release/release/v${KUBECTL_VER}/bin/linux/amd64/kubectl \ && chmod +x /usr/local/bin/kubectl RUN HELM_VER=3.0.2 \ && wget -O- https://get.helm.sh/helm-v${HELM_VER}-linux-amd64.tar.gz \ | tar -C /tmp -zxf - \ && mv /tmp/linux-amd64/helm /usr/local/bin/helm 

जैसा कि आप देख सकते हैं, इस छवि में हम उन सभी उपयोगिताओं को स्थापित करते हैं जो हम अपने एप्लिकेशन को तैनात करने के लिए उपयोग करते थे। हमें यहां कुब्जता की आवश्यकता नहीं है , लेकिन आप इसे पाइपलाइन सेटअप चरण में खेलना चाहते हैं।

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

ऐसा करने के लिए, gitlab-runner के साथ डायरेक्टरी पर जाएं:

 cd deploy/gitlab-runner 

और एक नया घटक घटक जोड़ें / rbac.jsonnet :

 local env = { name: std.extVar('qbec.io/env'), namespace: std.extVar('qbec.io/defaultNs'), }; local p = import '../params.libsonnet'; local params = p.components.rbac; [ { apiVersion: 'v1', kind: 'ServiceAccount', metadata: { labels: { app: params.name, }, name: params.name, }, }, { apiVersion: 'rbac.authorization.k8s.io/v1', kind: 'Role', metadata: { labels: { app: params.name, }, name: params.name, }, rules: [ { apiGroups: [ '*', ], resources: [ '*', ], verbs: [ '*', ], }, ], }, { apiVersion: 'rbac.authorization.k8s.io/v1', kind: 'RoleBinding', metadata: { labels: { app: params.name, }, name: params.name, }, roleRef: { apiGroup: 'rbac.authorization.k8s.io', kind: 'Role', name: params.name, }, subjects: [ { kind: 'ServiceAccount', name: params.name, namespace: env.namespace, }, ], }, ] 

हम वातावरण / base.libsonnet में नए मापदंडों का भी वर्णन करेंगे, जो अब इस तरह दिखता है:

 local secrets = import '../secrets/base.libsonnet'; { components: { gitlabRunner: { name: 'gitlab-runner', values: { gitlabUrl: 'https://gitlab.com/', rbac: { create: true, }, runnerRegistrationToken: secrets.runnerRegistrationToken, runners: { serviceAccountName: $.components.rbac.name, image: 'registry.gitlab.com/kvaps/docs.example.org/toolbox:v0.0.1', }, }, }, rbac: { name: 'gitlab-runner-deploy', }, }, } 

नोट $ .compitters.rbac.name rbac घटक का नाम बताता है

आइए देखें कि क्या बदल गया है:

 qbec diff default 

और कुबेरनेट्स में हमारे परिवर्तन लागू करें:

 qbec apply default 

इसके अलावा हमारे परिवर्तन करने के लिए प्रतिबद्ध करने के लिए मत भूलना:

 cd ../.. git add dockerfiles/toolbox git commit -m "Add Dockerfile for toolbox" git add deploy/gitlab-runner git commit -m "Configure gitlab-runner to use toolbox" 

9. टैग्स द्वारा हमारी पहली पाइपलाइन और छवियों की विधानसभा

परियोजना की जड़ में हम निम्न सामग्री के साथ .itlab-ci.yml बनाएंगे :

 .build_docker_image: stage: build image: name: gcr.io/kaniko-project/executor:debug-v0.15.0 entrypoint: [""] before_script: - echo "{\"auths\":{\"$CI_REGISTRY\":{\"username\":\"$CI_REGISTRY_USER\",\"password\":\"$CI_REGISTRY_PASSWORD\"}}}" > /kaniko/.docker/config.json build_toolbox: extends: .build_docker_image script: - /kaniko/executor --cache --context $CI_PROJECT_DIR/dockerfiles/toolbox --dockerfile $CI_PROJECT_DIR/dockerfiles/toolbox/Dockerfile --destination $CI_REGISTRY_IMAGE/toolbox:$CI_COMMIT_TAG only: refs: - tags build_website: extends: .build_docker_image variables: GIT_SUBMODULE_STRATEGY: normal script: - /kaniko/executor --cache --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/dockerfiles/website/Dockerfile --destination $CI_REGISTRY_IMAGE/website:$CI_COMMIT_TAG only: refs: - tags 

कृपया ध्यान दें कि हम GIT_SUBMODULE_STRATEGY का उपयोग करते हैं: उन नौकरियों के लिए सामान्य जहां आपको निष्पादन से पहले सबमॉड्यूल को स्पष्ट रूप से शुरू करने की आवश्यकता होती है।

हमारे परिवर्तन करने के लिए मत भूलना:

 git add .gitlab-ci.yml git commit -m "Automate docker build" 

मुझे लगता है कि आप सुरक्षित रूप से इसे संस्करण v0.0.1 कह सकते हैं और एक टैग लटका सकते हैं:

 git tag v0.0.1 

जब भी हमें नया संस्करण जारी करने की आवश्यकता होगी, हम टैग लटका देंगे। Docker छवियों में टैग Git टैग से बंधा होगा। नए टैग के साथ प्रत्येक पुश इस टैग के साथ छवियों की असेंबली को इनिशियलाइज़ करेगा।

Git push --tags चलाएं , और हमारी पहली पाइपलाइन देखें:

यह इस तथ्य पर आपका ध्यान देने योग्य है कि टैग द्वारा विधानसभा डॉक छवियों को इकट्ठा करने के लिए उपयुक्त है, लेकिन कुबेरनेट्स में एक एप्लिकेशन को तैनात करने के लिए उपयुक्त नहीं है। चूंकि नए टैग को पुराने कमिट्स को भी सौंपा जा सकता है, ऐसे में उनके लिए पाइपलाइन का इनिशियलाइजेशन पुराने वर्जन की तैनाती को बढ़ावा देगा।

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

10. तैनाती स्वचालन

अपने रहस्यों को डिक्रिप्ट करने के लिए गिटलैब-रनर के लिए, हमें रिपॉजिटरी की को एक्सपोर्ट करना होगा और इसे हमारे CI के पर्यावरण वेरिएबल्स में जोड़ना होगा:

 git crypt export-key /tmp/docs-repo.key base64 -w0 /tmp/docs-repo.key; echo 

Gitlab में परिणामी स्ट्रिंग को सहेजें, इसके लिए हम अपनी परियोजना की सेटिंग में जाएंगे:
सेटिंग्स -> सीआई / सीडी -> चर

:

.gitlab-ci.yml :

 .deploy_qbec_app: stage: deploy only: refs: - master deploy_gitlab_runner: extends: .deploy_qbec_app variables: GIT_SUBMODULE_STRATEGY: normal before_script: - base64 -d "$GITCRYPT_KEY" | git-crypt unlock - script: - qbec apply default --root deploy/gitlab-runner --force:k8s-context __incluster__ --wait --yes deploy_website: extends: .deploy_qbec_app script: - qbec apply default --root deploy/website --force:k8s-context __incluster__ --wait --yes 

qbec:

• --root some/app —
• --force:k8s-context __incluster__ — , gtilab-runner. , qbec Kubernetes- kubeconfig
• --wait — qbec , Ready exit-code.
• --yes — Are you sure? .

:

 git add .gitlab-ci.yml git commit -m "Automate deploy" 

git push :

11. push master

, . digest master-.

: website push master , Kubernetes.

.gitlab-ci.yml :

 build_website: extends: .build_docker_image variables: GIT_SUBMODULE_STRATEGY: normal script: - mkdir -p $CI_PROJECT_DIR/artifacts - /kaniko/executor --cache --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/dockerfiles/website/Dockerfile --destination $CI_REGISTRY_IMAGE/website:$CI_COMMIT_REF_NAME --digest-file $CI_PROJECT_DIR/artifacts/website.digest artifacts: paths: - artifacts/ only: refs: - master - tags deploy_website: extends: .deploy_qbec_app script: - DIGEST="$(cat artifacts/website.digest)" - qbec apply default --root deploy/website --force:k8s-context __incluster__ --wait --yes --vm:ext-str digest="$DIGEST" 

, master refs build_website $CI_COMMIT_REF_NAME $CI_COMMIT_TAG , Git . , , docker-registry.

docker- , Kubernetes, , .

--vm:ext-str digest="$DIGEST" qbec — jsonnet. . , , , .

Kaniko digest ( --digest-file )
.

deploy/website/environments/base.libsonnet :

 { components: { website: { name: 'example-docs', image: 'registry.gitlab.com/kvaps/docs.example.org/website@' + std.extVar('digest'), replicas: 1, containerPort: 80, servicePort: 80, nodeSelector: {}, tolerations: [], ingressClass: 'nginx', domain: 'docs.example.org', }, }, } 

, master docker- website , Kubernetes.

:

 git add . git commit -m "Configure dynamic build" 

, git push - :

gitlab-runner push, , , , .gitlab-ci.yml :

 deploy_gitlab_runner: extends: .deploy_qbec_app variables: GIT_SUBMODULE_STRATEGY: normal before_script: - base64 -d "$GITCRYPT_KEY" | git-crypt unlock - script: - qbec apply default --root deploy/gitlab-runner --force:k8s-context __incluster__ --wait --yes only: changes: - deploy/gitlab-runner/**/* 

changes deploy/gitlab-runner/

:

 git add .gitlab-ci.yml git commit -m "Reduce gitlab-runner deploy" 

git push , - :

12. Dynamic environments

.

build_website .gitlab-ci.yml , only , Gitlab :

 build_website: extends: .build_docker_image variables: GIT_SUBMODULE_STRATEGY: normal script: - mkdir -p $CI_PROJECT_DIR/artifacts - /kaniko/executor --cache --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/dockerfiles/website/Dockerfile --destination $CI_REGISTRY_IMAGE/website:$CI_COMMIT_REF_NAME --digest-file $CI_PROJECT_DIR/artifacts/website.digest artifacts: paths: - artifacts/ 

deploy_website , environment :

 deploy_website: extends: .deploy_qbec_app environment: name: prod url: https://docs.example.org script: - DIGEST="$(cat artifacts/website.digest)" - qbec apply default --root deploy/website --force:k8s-context __incluster__ --wait --yes --vm:ext-str digest="$DIGEST" 

Gitlab prod .

:

 deploy_website: extends: .deploy_qbec_app environment: name: prod url: https://docs.example.org script: - DIGEST="$(cat artifacts/website.digest)" - qbec apply default --root deploy/website --force:k8s-context __incluster__ --wait --yes --vm:ext-str digest="$DIGEST" deploy_review: extends: .deploy_qbec_app environment: name: review/$CI_COMMIT_REF_NAME url: http://$CI_ENVIRONMENT_SLUG.docs.example.org on_stop: stop_review script: - DIGEST="$(cat artifacts/website.digest)" - qbec apply review --root deploy/website --force:k8s-context __incluster__ --wait --yes --vm:ext-str digest="$DIGEST" --vm:ext-str subdomain="$CI_ENVIRONMENT_SLUG" --app-tag "$CI_ENVIRONMENT_SLUG" only: refs: - branches except: refs: - master stop_review: extends: .deploy_qbec_app environment: name: review/$CI_COMMIT_REF_NAME action: stop stage: deploy before_script: - git clone "$CI_REPOSITORY_URL" master - cd master script: - qbec delete review --root deploy/website --force:k8s-context __incluster__ --yes --vm:ext-str digest="$DIGEST" --vm:ext-str subdomain="$CI_ENVIRONMENT_SLUG" --app-tag "$CI_ENVIRONMENT_SLUG" variables: GIT_STRATEGY: none only: refs: - branches except: refs: - master when: manual 

push master preview .

qbec: --app-tag — , Kubernetes qbec .
review, .

qbec apply review , qbec apply default — (review default):

review deploy/website/qbec.yaml

 spec: environments: review: defaultNamespace: docs server: https://kubernetes.example.org:8443 

deploy/website/params.libsonnet :

 local env = std.extVar('qbec.io/env'); local paramsMap = { _: import './environments/base.libsonnet', default: import './environments/default.libsonnet', review: import './environments/review.libsonnet', }; if std.objectHas(paramsMap, env) then paramsMap[env] else error 'environment ' + env + ' not defined in ' + std.thisFile 

deploy/website/environments/review.libsonnet :

 // this file has the param overrides for the default environment local base = import './base.libsonnet'; local slug = std.extVar('qbec.io/tag'); local subdomain = std.extVar('subdomain'); base { components+: { website+: { name: 'example-docs-' + slug, domain: subdomain + '.docs.example.org', }, }, } 

stop_review , gitlab checkout GIT_STRATEGY: none , master - review .
, .
review , .

:

 git add . git commit -m "Enable automatic review" 

git push , git checkout -b test , git push origin test , :

? — , : git checkout master , git push origin :test , environment .

, , .gitlab-ci.yml .
protected-, master , .

13. Review Apps

Review Apps , .

, .gitlab/route-map.yml , :

 # Indices - source: /content\/(.+?)_index\.(md|html)/ public: '\1' # Pages - source: /content\/(.+?)\.(md|html)/ public: '\1/' 

:

 git add .gitlab/ git commit -m "Enable review apps" 

git push , :

Job is done!

:

• Gitlab: https://gitlab.com/kvaps/docs.example.org
• GitHub: https://github.com/kvaps/docs.example.org

,