കോൺസൽ ഉപയോഗിച്ച് ഒരു നോമാഡ് ക്ലസ്റ്റർ സജ്ജീകരിക്കുകയും Gitlab-മായി സംയോജിപ്പിക്കുകയും ചെയ്യുന്നു

ആമുഖം

അടുത്തിടെ, കുബർനെറ്റസിൻ്റെ ജനപ്രീതി അതിവേഗം വളരുകയാണ് - കൂടുതൽ കൂടുതൽ പ്രോജക്ടുകൾ ഇത് നടപ്പിലാക്കുന്നു. നോമാഡ് പോലെയുള്ള ഒരു ഓർക്കസ്ട്രേറ്ററെ സ്പർശിക്കാൻ ഞാൻ ആഗ്രഹിച്ചു: ഹാഷികോർപ്പിൽ നിന്നുള്ള മറ്റ് പരിഹാരങ്ങൾ ഇതിനകം ഉപയോഗിക്കുന്ന പ്രോജക്റ്റുകൾക്ക് ഇത് അനുയോജ്യമാണ്, ഉദാഹരണത്തിന്, വോൾട്ട്, കോൺസൽ, കൂടാതെ പ്രോജക്റ്റുകൾ തന്നെ അടിസ്ഥാന സൗകര്യങ്ങളുടെ കാര്യത്തിൽ സങ്കീർണ്ണമല്ല. ഈ മെറ്റീരിയലിൽ നൊമാഡ് ഇൻസ്റ്റാൾ ചെയ്യുന്നതിനും രണ്ട് നോഡുകൾ ഒരു ക്ലസ്റ്ററിലേക്ക് സംയോജിപ്പിക്കുന്നതിനും അതുപോലെ തന്നെ നോമാഡിനെ Gitlab-മായി സംയോജിപ്പിക്കുന്നതിനുമുള്ള നിർദ്ദേശങ്ങൾ അടങ്ങിയിരിക്കും.

ടെസ്റ്റ് സ്റ്റാൻഡ്

ടെസ്റ്റ് ബെഞ്ചിനെക്കുറിച്ച് കുറച്ച്: മൂന്ന് വെർച്വൽ സെർവറുകൾ 2 സിപിയു, 4 റാം, 50 ജിബി എസ്എസ്ഡി, ഒരു പൊതു ലോക്കൽ നെറ്റ്‌വർക്കിലേക്ക് സംയോജിപ്പിച്ച് ഉപയോഗിക്കുന്നു. അവരുടെ പേരും ഐപി വിലാസവും:

1. nomad-livelinux-01: 172.30.0.5
2. nomad-livelinux-02: 172.30.0.10
3. consul-livelinux-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/

ഇപ്പോൾ നമുക്ക് കൂടുതൽ കോൺഫിഗറേഷനായി ഒരു റെഡിമെയ്ഡ് കോൺസൽ ബൈനറി ഉണ്ട്.

കോൺസലുമായി പ്രവർത്തിക്കാൻ, കീജെൻ കമാൻഡ് ഉപയോഗിച്ച് ഞങ്ങൾ ഒരു അദ്വിതീയ കീ സൃഷ്ടിക്കേണ്ടതുണ്ട്:

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

ഇത് ഇപ്പോൾ ഡീബഗ് ചെയ്യുന്നതിനുള്ള ഒരു നല്ല മാർഗമാണ്, എന്നിരുന്നാലും, വ്യക്തമായ കാരണങ്ങളാൽ നിങ്ങൾക്ക് ഈ രീതി തുടർച്ചയായി ഉപയോഗിക്കാൻ കഴിയില്ല. systemd വഴി കോൺസൽ മാനേജുചെയ്യാൻ നമുക്ക് ഒരു സേവന ഫയൽ സൃഷ്ടിക്കാം:

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 സജ്ജീകരിക്കുമ്പോൾ, ഞങ്ങൾ ഇത് ഉപേക്ഷിക്കേണ്ടിവരും - അല്ലാത്തപക്ഷം ഞങ്ങളുടെ ആപ്ലിക്കേഷൻ Nomad-ലേക്ക് വിന്യസിക്കാൻ കഴിയില്ല. എൻ്റെ പ്രൊജക്റ്റിൽ, Gitlab ഉം Nomad ഉം ഗ്രേ വെബിൽ മാത്രമാണ്, അതിനാൽ ഇവിടെ അത്തരം പ്രശ്‌നങ്ങളൊന്നുമില്ല.

ശേഷിക്കുന്ന രണ്ട് സെർവറുകളിൽ ഞങ്ങൾ താഴെ പറയുന്ന നിർദ്ദേശങ്ങൾ അനുസരിച്ച് കോൺസൽ ഏജൻ്റ്സ് ഇൻസ്റ്റാൾ ചെയ്യുന്നു. ബൈനറി ഫയൽ ഉപയോഗിച്ച് ഞങ്ങൾ ഘട്ടങ്ങൾ ആവർത്തിക്കുന്നു:

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 ഭാരമുള്ള ഒരു Nomad ബൈനറി ഫയൽ നമുക്ക് ലഭിക്കും - അത് /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.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. കോൺസൽ ക്ലസ്റ്ററിലെ നോഡുകളുടെ ലിസ്റ്റ്

ഇപ്പോൾ കോൺസലുമായി ചേർന്ന് പ്രവർത്തിക്കുന്ന ഒരു തയ്യാറാക്കിയ നാടോടി ഞങ്ങൾക്കുണ്ട്. അവസാന ഘട്ടത്തിൽ, ഞങ്ങൾ രസകരമായ ഭാഗത്തിലേക്ക് കടക്കും: Gitlab മുതൽ Nomad വരെയുള്ള ഡോക്കർ കണ്ടെയ്‌നറുകൾ ഡെലിവറി സജ്ജീകരിക്കുക, കൂടാതെ അതിൻ്റെ മറ്റ് ചില വ്യതിരിക്തമായ സവിശേഷതകളെ കുറിച്ച് സംസാരിക്കുക.

Gitlab റണ്ണർ സൃഷ്ടിക്കുന്നു

Nomad-ലേക്ക് ഡോക്കർ ഇമേജുകൾ വിന്യസിക്കാൻ, ഉള്ളിൽ Nomad ബൈനറി ഫയലുള്ള ഒരു പ്രത്യേക റണ്ണർ ഞങ്ങൾ ഉപയോഗിക്കും (ഇവിടെ, വഴിയിൽ, Hashicorp ആപ്ലിക്കേഷനുകളുടെ മറ്റൊരു സവിശേഷത നമുക്ക് ശ്രദ്ധിക്കാം - വ്യക്തിഗതമായി അവ ഒരൊറ്റ ബൈനറി ഫയലാണ്). ഇത് റണ്ണർ ഡയറക്ടറിയിലേക്ക് അപ്‌ലോഡ് ചെയ്യുക. ഇനിപ്പറയുന്ന ഉള്ളടക്കം ഉപയോഗിച്ച് അതിനായി ഒരു ലളിതമായ ഡോക്കർഫയൽ സൃഷ്ടിക്കാം:

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