कंसल के साथ घुमंतू क्लस्टर को कॉन्फ़िगर करें और गिटलैब के साथ एकीकृत करें

परिचय



हाल ही में, कुबेरनेट्स की लोकप्रियता तेजी से बढ़ रही है - अधिक से अधिक परियोजनाएं इसे घर पर लागू कर रही हैं। मैं खानाबदोश की तरह एक ऑर्केस्ट्रेटर पर स्पर्श करना चाहता था: यह उन परियोजनाओं के लिए एकदम सही है जो पहले से ही हाशिकोर्प से अन्य समाधानों का उपयोग करते हैं, उदाहरण के लिए, वॉल्ट और कौंसल, और परियोजनाएं स्वयं बुनियादी ढांचे के मामले में जटिल नहीं हैं। यह लेख घुमंतू को स्थापित करने, एक क्लस्टर में दो नोड्स के संयोजन, और गिट्लाब के साथ घुमंतू को एकीकृत करने के लिए निर्देश प्रदान करेगा।





टेस्ट स्टैंड



परीक्षण बेंच के बारे में थोड़ा सा: तीन वर्चुअल सर्वर 2 सीपीयू, 4 रैम, 50 जीबी एसएसडी की विशेषताओं के साथ उपयोग किए जाते हैं, जो एक सामान्य स्थानीय नेटवर्क में एकजुट होते हैं। उनके नाम और आईपी पते:

  1. खानाबदोश- livelinux-01 : 172.30.0.5
  2. खानाबदोश- livelinux-02 : 172.30.0.10
  3. कंसुल-लाइवलाइन -01 : 172.30.0.15


घुमंतू, कौंसुल की स्थापना। एक खानाबदोश क्लस्टर बनाना



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

अभ्यास शुरू करने से पहले, हम सैद्धांतिक भाग पर चर्चा करेंगे, क्योंकि इस स्तर पर भविष्य की संरचना को समझना महत्वपूर्ण है।

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

HashiCorp उपकरण स्थापित करना बहुत सरल है: वास्तव में, हम केवल बाइनरी फ़ाइल को बिन निर्देशिका में स्थानांतरित करते हैं, टूल की कॉन्फ़िगरेशन फ़ाइल को कॉन्फ़िगर करते हैं और इसकी सेवा फ़ाइल बनाते हैं।

कंसल बाइनरी फ़ाइल डाउनलोड करें और इसे उपयोगकर्ता के होम डायरेक्टरी में अनपैक करें:

root@consul-livelinux-01:~# wget https://releases.hashicorp.com/consul/1.5.0/consul_1.5.0_linux_amd64.zip root@consul-livelinux-01:~# unzip consul_1.5.0_linux_amd64.zip root@consul-livelinux-01:~# mv consul /usr/local/bin/ 


अब हमारे पास आगे के विन्यास के लिए एक तैयार द्विआधारी कॉन्सल फ़ाइल है।

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

 root@consul-livelinux-01:~# consul keygen 


चलिए कंसॉल को कॉन्फ़िगर करने के लिए आगे बढ़ते हैं, /etc/consul.d/ निर्देशिका को निम्न संरचना के साथ बनाते हैं:

 /etc/consul.d/ ├── bootstrap │ └── config.json 


बूटस्ट्रैप निर्देशिका में config.json कॉन्फ़िगरेशन फ़ाइल होगी - इसमें हम कॉन्सुल सेटिंग्स सेट करेंगे। इसकी सामग्री:

 { "bootstrap": true, "server": true, "datacenter": "dc1", "data_dir": "/var/consul", "encrypt": "your-key", "log_level": "INFO", "enable_syslog": true, "start_join": ["172.30.0.15"] } 


आइए हम मुख्य निर्देशों और उनके अर्थों की अलग-अलग जाँच करें:

  • बूटस्ट्रैप : सच। हम नए नोड्स के स्वचालित जोड़ को चालू करते हैं यदि वे जुड़े हुए हैं। मैं ध्यान देता हूं कि हम यहां अपेक्षित नोड्स की सटीक संख्या नहीं दर्शाते हैं।
  • सर्वर : सच है। सर्वर मोड चालू करें। इस वर्चुअल मशीन पर कंसूल फिलहाल एक ही सर्वर और मास्टर होगा, VM घुमंतू ग्राहक होंगे।
  • डाटासेंटर : dc1। क्लस्टर बनाने के लिए डेटा सेंटर का नाम निर्दिष्ट करें। यह क्लाइंट और सर्वर दोनों पर समान होना चाहिए।
  • एन्क्रिप्ट : आपकी कुंजी। एक कुंजी जो सभी ग्राहकों और सर्वरों के लिए भी अद्वितीय और मैच होनी चाहिए। कॉन्सल कीजन कमांड का उपयोग करके बनाया गया।
  • start_join इस सूची में हम आईपी पते की सूची दर्शाते हैं जिससे कनेक्शन किया जाएगा। फिलहाल, हम केवल अपना पता छोड़ते हैं।


इस बिंदु पर, हम कमांड लाइन का उपयोग करके वाणिज्य दूतावास शुरू कर सकते हैं:

 root@consul-livelinux-01:~# /usr/local/bin/consul agent -config-dir /etc/consul.d/bootstrap -ui 


यह अब डिबग करने का एक अच्छा तरीका है, हालांकि, निरंतर आधार पर, इस विधि का उपयोग स्पष्ट कारणों से काम नहीं करेगा। सिस्टमड के माध्यम से कौंसल के प्रबंधन के लिए एक सेवा फ़ाइल बनाएँ:

 root@consul-livelinux-01:~# nano /etc/systemd/system/consul.service 


Consul.service फ़ाइल की सामग्री:

 [Unit] Description=Consul Startup process After=network.target [Service] Type=simple ExecStart=/bin/bash -c '/usr/local/bin/consul agent -config-dir /etc/consul.d/bootstrap -ui' TimeoutStartSec=0 [Install] WantedBy=default.target 


रूढ़िवादी के माध्यम से चलाएं:

 root@consul-livelinux-01:~# systemctl start consul 


हम जाँचते हैं: हमारी सेवा शुरू होनी चाहिए, और वाणिज्य दूत सदस्यों को निष्पादित करके हमें अपना सर्वर देखना चाहिए:

 root@consul-livelinux:/etc/consul.d# consul members consul-livelinux 172.30.0.15:8301 alive server 1.5.0 2 dc1 <all> 


अगला कदम: Nginx को स्थापित करना और प्रॉक्सी, http प्राधिकरण स्थापित करना। पैकेज प्रबंधक के माध्यम से nginx स्थापित करें और निम्नलिखित सामग्री के साथ / etc / nginx / साइट्स-सक्षम निर्देशिका में कॉन्फ़िगरेशन फ़ाइल consul.conf बनाएं:

 upstream consul-auth { server localhost:8500; } server { server_name consul.doman.name; location / { proxy_pass http://consul-auth; proxy_set_header Host $host; auth_basic_user_file /etc/nginx/.htpasswd; auth_basic "Password-protected Area"; } } 


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

अन्य दो सर्वरों पर, निम्नलिखित निर्देशों के अनुसार कंसल एजेंट स्थापित करें। बाइनरी फ़ाइल के साथ चरणों को दोहराएं:

 root@nomad-livelinux-01:~# wget https://releases.hashicorp.com/consul/1.5.0/consul_1.5.0_linux_amd64.zip root@nomad-livelinux-01:~# unzip consul_1.5.0_linux_amd64.zip root@nomad-livelinux-01:~# mv consul /usr/local/bin/ 


पिछले सर्वर के साथ समानता से, हम निम्न संरचना के साथ विन्यास फाइल /etc/consul.d के लिए एक निर्देशिका बनाते हैं:

 /etc/consul.d/ ├── client │ └── config.json 


Config.json फ़ाइल की सामग्री:

 { "datacenter": "dc1", "data_dir": "/opt/consul", "log_level": "DEBUG", "node_name": "nomad-livelinux-01", "server": false, "encrypt": "your-private-key", "domain": "livelinux", "addresses": { "dns": "127.0.0.1", "https": "0.0.0.0", "grpc": "127.0.0.1", "http": "127.0.0.1" }, "bind_addr": "172.30.0.5", #    "start_join": ["172.30.0.15"], #     "ports": { "dns": 53 } } 


हम परिवर्तनों को सहेजते हैं और सेवा फ़ाइल, इसकी सामग्री के विन्यास के लिए आगे बढ़ते हैं:

/etc/systemd/system/consul.service:

 [Unit] Description="HashiCorp Consul - A service mesh solution" Documentation=https://www.consul.io/ Requires=network-online.target After=network-online.target [Service] User=root Group=root ExecStart=/usr/local/bin/consul agent -config-dir=/etc/consul.d/client ExecReload=/usr/local/bin/consul reload KillMode=process Restart=on-failure [Install] WantedBy=multi-user.target 


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

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

नोट : परियोजना बहुत तेजी से विकसित हो रही है, नए अपडेट अक्सर सामने आते हैं। शायद, जब तक लेख पूरा नहीं हो जाता, तब तक एक नया संस्करण जारी किया जाएगा। इसलिए, मेरा सुझाव है कि पढ़ने से पहले इस समय खानाबदोश के वर्तमान संस्करण की जांच करें और इसे डाउनलोड करें।

 root@nomad-livelinux-01:~# wget https://releases.hashicorp.com/nomad/0.9.1/nomad_0.9.1_linux_amd64.zip root@nomad-livelinux-01:~# unzip nomad_0.9.1_linux_amd64.zip root@nomad-livelinux-01:~# mv nomad /usr/local/bin/ root@nomad-livelinux-01:~# nomad -autocomplete-install root@nomad-livelinux-01:~# complete -C /usr/local/bin/nomad nomad root@nomad-livelinux-01:~# mkdir /etc/nomad.d 


अनपैक करने के बाद, हमें 65 MB वजन वाली एक नोमैड बाइनरी फाइल मिलेगी - इसे / usr / लोकल / बिन में ले जाना होगा।

घुमंतू के लिए एक डेटा निर्देशिका बनाएं और इसकी सेवा फ़ाइल को संपादित करें (यह शुरुआत में सबसे अधिक संभावना नहीं होगी):

 root@nomad-livelinux-01:~# mkdir --parents /opt/nomad root@nomad-livelinux-01:~# nano /etc/systemd/system/nomad.service 


वहां निम्न पंक्तियाँ डालें:

 [Unit] Description=Nomad Documentation=https://nomadproject.io/docs/ Wants=network-online.target After=network-online.target [Service] ExecReload=/bin/kill -HUP $MAINPID ExecStart=/usr/local/bin/nomad agent -config /etc/nomad.d KillMode=process KillSignal=SIGINT LimitNOFILE=infinity LimitNPROC=infinity Restart=on-failure RestartSec=2 StartLimitBurst=3 StartLimitIntervalSec=10 TasksMax=infinity [Install] WantedBy=multi-user.target 


हालाँकि, हम खानाबदोश चलाने की जल्दी में नहीं हैं - हमने अभी तक इसकी कॉन्फ़िगरेशन फ़ाइल नहीं बनाई है:

 root@nomad-livelinux-01:~# mkdir --parents /etc/nomad.d root@nomad-livelinux-01:~# chmod 700 /etc/nomad.d root@nomad-livelinux-01:~# nano /etc/nomad.d/nomad.hcl root@nomad-livelinux-01:~# nano /etc/nomad.d/server.hcl 


अंतिम निर्देशिका संरचना निम्नानुसार होगी:

 /etc/nomad.d/ ├── nomad.hcl └── server.hcl 


Nomad.hcl फ़ाइल में निम्न कॉन्फ़िगरेशन होना चाहिए:

 datacenter = "dc1" data_dir = "/opt/nomad" 


Server.hcl फ़ाइल की सामग्री:

 server { enabled = true bootstrap_expect = 1 } consul { address = "127.0.0.1:8500" server_service_name = "nomad" client_service_name = "nomad-client" auto_advertise = true server_auto_join = true client_auto_join = true } bind_addr = "127.0.0.1" advertise { http = "172.30.0.5" } client { enabled = true } 


दूसरे सर्वर पर कॉन्फ़िगरेशन फ़ाइल को बदलना न भूलें - वहां आपको http निर्देश के मूल्य को बदलना होगा।

इस स्तर पर अंतिम http प्राधिकरण स्थापित करने और स्थापित करने के लिए Nginx का कॉन्फ़िगरेशन है। Nomad.conf फ़ाइल की सामग्री:

 upstream nomad-auth { server 172.30.0.5:4646; } server { server_name nomad.domain.name; location / { proxy_pass http://nomad-auth; proxy_set_header Host $host; auth_basic_user_file /etc/nginx/.htpasswd; auth_basic "Password-protected Area"; } } 


अब हम बाहरी नेटवर्क के माध्यम से वेब पैनल तक पहुंच सकते हैं। हम कनेक्ट करते हैं और सर्वर पेज पर जाते हैं:


चित्रा 1. एक खानाबदोश क्लस्टर में सर्वर की सूची

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


छवि 2. खानाबदोश नोड स्थिति कमांड का उत्पादन

कौंसल के बारे में क्या? आइए देखते हैं। कॉन्सल कंट्रोल पैनल पर, नोड्स पेज पर जाएं:

चित्रा 3. वाणिज्य दूतावास में नोड्स की सूची

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

गिटलैब रनर बनाएँ



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

 FROM alpine:3.9 RUN apk add --update --no-cache libc6-compat gettext COPY nomad /usr/local/bin/nomad 


एक ही परियोजना में, .itlab-ci.yml बनाएँ:

 variables: DOCKER_IMAGE: nomad/nomad-deploy DOCKER_REGISTRY: registry.domain.name stages: - build build: stage: build image: ${DOCKER_REGISTRY}/nomad/alpine:3 script: - tag=${DOCKER_REGISTRY}/${DOCKER_IMAGE}:latest - docker build --pull -t ${tag} -f Dockerfile . - docker push ${tag} 


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

प्रोजेक्ट सेटअप



चलिए खानाबदोश के लिए नौकरी की फाइल से शुरू करते हैं। इस लेख में मेरी परियोजना काफी आदिम होगी: इसमें एक कार्य शामिल होगा। .Itlabab-ci की सामग्री इस प्रकार होगी:

 variables: NOMAD_ADDR: http://nomad.address.service:4646 DOCKER_REGISTRY: registry.domain.name DOCKER_IMAGE: example/project stages: - build - deploy build: stage: build image: ${DOCKER_REGISTRY}/nomad-runner/alpine:3 script: - tag=${DOCKER_REGISTRY}/${DOCKER_IMAGE}:${CI_COMMIT_SHORT_SHA} - docker build --pull -t ${tag} -f Dockerfile . - docker push ${tag} deploy: stage: deploy image: registry.example.com/nomad/nomad-runner:latest script: - envsubst '${CI_COMMIT_SHORT_SHA}' < project.nomad > job.nomad - cat job.nomad - nomad validate job.nomad - nomad plan job.nomad || if [ $? -eq 255 ]; then exit 255; else echo "success"; fi - nomad run job.nomad environment: name: production allow_failure: false when: manual 


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

 job "monitoring-status" { datacenters = ["dc1"] migrate { max_parallel = 3 health_check = "checks" min_healthy_time = "15s" healthy_deadline = "5m" } group "zhadan.ltd" { count = 1 update { max_parallel = 1 min_healthy_time = "30s" healthy_deadline = "5m" progress_deadline = "10m" auto_revert = true } task "service-monitoring" { driver = "docker" config { image = "registry.domain.name/example/project:${CI_COMMIT_SHORT_SHA}" force_pull = true auth { username = "gitlab_user" password = "gitlab_password" } port_map { http = 8000 } } resources { network { port "http" {} } } } } } 


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

 # Download the policy and token role $ curl https://nomadproject.io/data/vault/nomad-server-policy.hcl -O -s -L $ curl https://nomadproject.io/data/vault/nomad-cluster-role.json -O -s -L # Write the policy to Vault $ vault policy write nomad-server nomad-server-policy.hcl # Create the token role with Vault $ vault write /auth/token/roles/nomad-cluster @nomad-cluster-role.json 


अब, आवश्यक नीतियां बनाने के बाद, हम कार्य ब्लॉक में वॉल्ट के साथ एकीकरण को जोड़ देंगे।

 vault { enabled = true address = "https://vault.domain.name:8200" token = "token" } 


मैं टोकन के द्वारा प्राधिकरण का उपयोग करता हूं और इसे सीधे यहां लिखता हूं, चालू करने के समय टोकन को एक चर के रूप में निर्दिष्ट करने का विकल्प भी है:

 $ VAULT_TOKEN=<token> nomad agent -config /path/to/config 


अब हम तिजोरी के साथ चाबियों का उपयोग कर सकते हैं। ऑपरेशन का सिद्धांत सरल है: हम खानाबदोश नौकरी में एक फ़ाइल बनाते हैं, जो चर के मूल्यों को संग्रहीत करेगा, उदाहरण के लिए:

 template { data = <<EOH {{with secret "secrets/pipeline-keys"}} REGISTRY_LOGIN="{{ .Data.REGISTRY_LOGIN }}" REGISTRY_PASSWORD="{{ .Data.REGISTRY_LOGIN }}{{ end }}" EOH destination = "secrets/service-name.env" env = true } 


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

एलेक्सिया ज़ादान और लाइव लिनक्स टीम द्वारा संपादित इल्या एंड्रीव द्वारा पोस्ट किया गया

Source: https://habr.com/ru/post/hi453322/


All Articles