🥇कंसुल का उपयोग करके घुमंतू क्लस्टर की स्थापना करना और गिटलैब के साथ एकीकरण करना

परिचय

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

परीक्षण स्टैंड

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

खानाबदोश-लिवलिनक्स-01: 172.30.0.5
खानाबदोश-लिवलिनक्स-02: 172.30.0.10
कौंसल-लिवलिनक्स-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"]
}

आइए मुख्य निर्देशों और उनके अर्थों को अलग से देखें:

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

इस बिंदु पर हम कमांड लाइन का उपयोग करके कॉन्सल चला सकते हैं:

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

Systemctl के माध्यम से कौंसल लॉन्च करें:

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/sites-enabled निर्देशिका में हम निम्नलिखित सामग्री के साथ एक कॉन्फ़िगरेशन फ़ाइल 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 फ़ाइल बनाना और उसके लिए एक उपयोगकर्ता नाम और पासवर्ड बनाना न भूलें। यह आइटम आवश्यक है ताकि वेब पैनल हमारे डोमेन को जानने वाले हर व्यक्ति के लिए उपलब्ध न हो। हालाँकि, Gitlab की स्थापना करते समय, हमें इसे छोड़ना होगा - अन्यथा हम अपने एप्लिकेशन को घुमंतू में तैनात नहीं कर पाएंगे। मेरे प्रोजेक्ट में, गिटलैब और नोमैड दोनों केवल ग्रे वेब पर हैं, इसलिए यहां ऐसी कोई समस्या नहीं है।

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

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

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

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

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

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 एमबी वजन वाली एक घुमंतू बाइनरी फ़ाइल प्राप्त होगी - इसे /usr/local/bin में ले जाना होगा।

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

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 {
  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

उसी प्रोजेक्ट में हम .gitlab-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}

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

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

आइए खानाबदोश के लिए नौकरी की फ़ाइल से शुरुआत करें। इस आलेख में मेरा प्रोजेक्ट काफी आदिम होगा: इसमें एक कार्य शामिल होगा। .gitlab-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

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

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
}

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

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

स्रोत: www.habr.com

कॉन्सल का उपयोग करके घुमंतू क्लस्टर स्थापित करना और गिटलैब के साथ एकीकरण करना

परिचय

परीक्षण स्टैंड

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

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

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

एक टिप्पणी जोड़ें उत्तर रद्द