Nomad კლასტერის შექმნა Consul-ის გამოყენებით და Gitlab-თან ინტეგრაცია

შესავალი

ბოლო დროს Kubernetes-ის პოპულარობა სწრაფად იზრდება - უფრო და უფრო მეტი პროექტი ახორციელებს მას. მსურდა შევეხო ისეთ ორკესტრატორს, როგორიცაა Nomad: ის შესანიშნავია პროექტებისთვის, რომლებიც უკვე იყენებენ HashiCorp-ის სხვა გადაწყვეტილებებს, მაგალითად, Vault და Consul, და თავად პროექტები არ არის რთული ინფრასტრუქტურის თვალსაზრისით. ეს მასალა შეიცავს ინსტრუქციებს Nomad-ის დაყენების, ორი კვანძის კლასტერში გაერთიანების, ასევე Nomad-ის Gitlab-თან ინტეგრაციის შესახებ.

სატესტო სტენდი

ცოტა რამ სატესტო სკამზე: სამი ვირტუალური სერვერი გამოიყენება 2 CPU, 4 RAM, 50 Gb SSD მახასიათებლებით, გაერთიანებულია საერთო ლოკალურ ქსელში. მათი სახელები და IP მისამართები:

1. nomad-livelinux-01: 172.30.0.5
2. nomad-livelinux-02: 172.30.0.10
3. consul-livelinux-01: 172.30.0.15

Nomad-ის ინსტალაცია, კონსული. მომთაბარე კლასტერის შექმნა

დავიწყოთ ძირითადი ინსტალაცია. მიუხედავად იმისა, რომ დაყენება მარტივი იყო, მე აღვწერ მას სტატიის მთლიანობისთვის: ის არსებითად შეიქმნა ნახაზებიდან და შენიშვნებიდან, საჭიროების შემთხვევაში სწრაფი წვდომისთვის.

სანამ პრაქტიკას დავიწყებთ, განვიხილავთ თეორიულ ნაწილს, რადგან ამ ეტაპზე მნიშვნელოვანია მომავალი სტრუქტურის გაგება.

ჩვენ გვაქვს ორი მომთაბარე კვანძი და გვინდა გავაერთიანოთ ისინი კლასტერში და მომავალში ასევე დაგვჭირდება კლასტერების ავტომატური მასშტაბირება - ამისთვის დაგვჭირდება კონსული. ამ ხელსაწყოს საშუალებით კლასტერირება და ახალი კვანძების დამატება ხდება ძალიან მარტივი ამოცანა: შექმნილი Nomad კვანძი უკავშირდება Consul-ის აგენტს, შემდეგ კი უერთდება არსებულ Nomad კლასტერს. ამიტომ, დასაწყისში ჩვენ დავაინსტალირებთ Consul სერვერს, დავაყენებთ ძირითად http ავტორიზაციას ვებ პანელისთვის (ის ნაგულისხმევად არის ავტორიზაციის გარეშე და მისი წვდომა შესაძლებელია გარე მისამართზე), ასევე თავად კონსულის აგენტებს Nomad სერვერებზე, რის შემდეგაც ჩვენ მხოლოდ Nomad-ზე გავაგრძელებთ.

HashiCorp-ის ინსტრუმენტების ინსტალაცია ძალიან მარტივია: არსებითად, ჩვენ უბრალოდ გადავიტანთ ორობით ფაილს bin დირექტორიაში, ვაყენებთ ხელსაწყოს კონფიგურაციის ფაილს და ვქმნით მის სერვის ფაილს.

ჩამოტვირთეთ Consul ორობითი ფაილი და გახსენით იგი მომხმარებლის სახლის დირექტორიაში:

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

მოდით გადავიდეთ Consul-ის კონფიგურაციის დაყენებაზე, შევქმნათ დირექტორია /etc/consul.d/ შემდეგი სტრუქტურით:

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

ჩატვირთვის დირექტორია შეიცავს კონფიგურაციის ფაილს config.json - მასში დავაყენებთ Consul-ის პარამეტრებს. მისი შინაარსი:

{
"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"]
}

მოდით განვიხილოთ ძირითადი დირექტივები და მათი მნიშვნელობა ცალკე:

• ჩატვირთვის: მართალია. ჩვენ ჩართავთ ახალი კვანძების ავტომატურ დამატებას, თუ ისინი დაკავშირებულია. მე აღვნიშნავ, რომ ჩვენ აქ არ მივუთითებთ მოსალოდნელი კვანძების ზუსტ რაოდენობას.
• სერვერზე: მართალია. სერვერის რეჟიმის ჩართვა. კონსული ამ ვირტუალურ მანქანაზე იმოქმედებს, როგორც ერთადერთი სერვერი და მასტერი ამ მომენტში, Nomad's VM იქნება კლიენტები.
• მონაცემთა ცენტრი: dc1. მიუთითეთ მონაცემთა ცენტრის სახელი კლასტერის შესაქმნელად. ის უნდა იყოს იდენტური როგორც კლიენტებზე, ასევე სერვერებზე.
• დაშიფროთ: შენი გასაღები. გასაღები, რომელიც ასევე უნდა იყოს უნიკალური და ემთხვევა ყველა კლიენტსა და სერვერს. გენერირებულია consul keygen ბრძანების გამოყენებით.
• დაწყება_შეერთება. ამ სიაში ჩვენ მივუთითებთ IP მისამართების ჩამონათვალს, რომლებთანაც დაკავშირება განხორციელდება. ამ დროისთვის მხოლოდ საკუთარ მისამართს ვტოვებთ.

ამ ეტაპზე ჩვენ შეგვიძლია გავატაროთ კონსული ბრძანების ხაზის გამოყენებით:

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 წევრებში. ეს ნიშნავს, რომ ის წარმატებით დაუკავშირდა კლასტერს, როგორც კლიენტს. იგივე გაიმეორეთ მეორე სერვერზე და ამის შემდეგ შეგვიძლია დავიწყოთ Nomad-ის ინსტალაცია და კონფიგურაცია.

Nomad-ის უფრო დეტალური ინსტალაცია აღწერილია მის ოფიციალურ დოკუმენტაციაში. არსებობს ინსტალაციის ორი ტრადიციული მეთოდი: ბინარული ფაილის ჩამოტვირთვა და წყაროდან კომპილაცია. მე ავირჩევ პირველ მეთოდს.

შენიშვნა: პროექტი ძალიან სწრაფად ვითარდება, ხშირად გამოდის ახალი განახლებები. შესაძლოა ახალი ვერსია გამოვა ამ სტატიის დასრულების დროისთვის. ამიტომ, წაკითხვამდე გირჩევთ შეამოწმოთ Nomad-ის მიმდინარე ვერსია და გადმოწეროთ.

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

ამოხსნის შემდეგ მივიღებთ Nomad ორობით ფაილს 65 მბ მასით - ის უნდა გადავიდეს /usr/local/bin-ში.

მოდით შევქმნათ მონაცემთა დირექტორია Nomad-ისთვის და შევცვალოთ მისი სერვისის ფაილი (ის სავარაუდოდ თავიდან არ იარსებებს):

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

თუმცა, ჩვენ არ ვჩქარობთ nomad-ის გაშვებას - ჯერ არ შეგვიქმნია მისი კონფიგურაციის ფაილი:

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 დირექტივის მნიშვნელობის შეცვლა.

ბოლო რამ ამ ეტაპზე არის Nginx-ის კონფიგურაცია პროქსისთვის და http ავტორიზაციის დასაყენებლად. 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. Nomad კლასტერში სერვერების სია

ორივე სერვერი წარმატებით არის ნაჩვენები პანელში, ჩვენ იგივეს დავინახავთ მომთაბარე კვანძის სტატუსის ბრძანების გამოსავალში:

სურათი 2. მომთაბარე კვანძის სტატუსის ბრძანების გამომავალი

რაც შეეხება კონსულს? მოდით შევხედოთ. გადადით კონსულის მართვის პანელზე, კვანძების გვერდზე:

სურათი 3. კვანძების სია კონსულის კლასტერში

ახლა ჩვენ გვყავს მომზადებული Nomad, რომელიც მუშაობს კონსულთან ერთად. ფინალურ ეტაპზე მივიღებთ სახალისო ნაწილს: Docker-ის კონტეინერების მიწოდების დაყენება Gitlab-დან Nomad-მდე და ასევე საუბარი მის სხვა გამორჩეულ მახასიათებლებზე.

Gitlab Runner-ის შექმნა

Nomad-ში დოკერის სურათების განსათავსებლად, ჩვენ გამოვიყენებთ ცალკეულ მორბენალს, რომელშიც შედის Nomad ორობითი ფაილი (აქ, სხვათა შორის, შეგვიძლია აღვნიშნოთ Hashicorp აპლიკაციების კიდევ ერთი მახასიათებელი - ინდივიდუალურად ისინი ერთი ორობითი ფაილია). ატვირთეთ იგი runner დირექტორიაში. მოდით შევქმნათ მისთვის მარტივი Dockerfile შემდეგი შინაარსით:

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}

შედეგად, ჩვენ გვექნება Nomad runner-ის ხელმისაწვდომი სურათი Gitlab Registry-ში, ახლა ჩვენ შეგვიძლია პირდაპირ გადავიდეთ პროექტის საცავში, შევქმნათ Pipeline და დავაკონფიგურიროთ Nomad-ის მომთაბარე სამუშაო.

პროექტის დაყენება

დავიწყოთ Nomad-ის სამუშაოს ფაილით. ჩემი პროექტი ამ სტატიაში საკმაოდ პრიმიტიული იქნება: ის შედგება ერთი დავალებისგან. .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

აქ განლაგება ხდება ხელით, მაგრამ შეგიძლიათ მისი კონფიგურაცია შეცვალოთ პროექტის დირექტორიაში შიგთავსი. მილსადენი შედგება ორი ეტაპისგან: გამოსახულების აწყობა და მისი განლაგება მომთაბარეზე. პირველ ეტაპზე ჩვენ ვაწყობთ დოკერის სურათს და ვაყენებთ მას ჩვენს რეესტრში, ხოლო მეორეში ვიწყებთ სამუშაოს Nomad-ში.

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

გთხოვთ გაითვალისწინოთ, რომ მე მაქვს პირადი რეესტრი და დოკერის სურათის წარმატებით გამოსატანად უნდა შეხვიდე მასში. საუკეთესო გამოსავალი ამ შემთხვევაში არის შესვლა და პაროლი Vault-ში შეყვანა და შემდეგ მისი ინტეგრირება Nomad-თან. მომთაბარე მხარს უჭერს Vault-ს. მაგრამ პირველ რიგში, მოდით დავაინსტალიროთ Nomad-ისთვის საჭირო პოლიტიკა თავად Vault-ში; მათი ჩამოტვირთვა შესაძლებელია:

# 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-თან ინტეგრაციას job.nomad ფაილში ამოცანების ბლოკში:

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

მე ვიყენებ ავტორიზაციას ტოკენით და ვარეგისტრირებ მას პირდაპირ აქ, ასევე არის მომთაბარე აგენტის დაწყებისას ტოკენის ცვლადის მითითების შესაძლებლობა:

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

ახლა ჩვენ შეგვიძლია გამოვიყენოთ გასაღებები Vault-ით. მუშაობის პრინციპი მარტივია: ჩვენ ვქმნით ფაილს Nomad job-ში, რომელიც ინახავს ცვლადების მნიშვნელობებს, მაგალითად:

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
}

ამ მარტივი მიდგომით შეგიძლიათ დააკონფიგურიროთ კონტეინერების მიწოდება Nomad კლასტერში და იმუშაოთ მასთან მომავალში. მე ვიტყვი, რომ გარკვეულწილად თანავუგრძნობ Nomad-ს - ის უფრო შესაფერისია მცირე პროექტებისთვის, სადაც Kubernetes-მა შეიძლება გამოიწვიოს დამატებითი სირთულე და არ გააცნობიეროს მისი სრული პოტენციალი. გარდა ამისა, Nomad შესანიშნავია დამწყებთათვის — მისი ინსტალაცია და კონფიგურაცია მარტივია. თუმცა, ზოგიერთ პროექტზე ტესტირებისას, მე ვაწყდები პრობლემას მის ადრეულ ვერსიებთან დაკავშირებით - ბევრი ძირითადი ფუნქცია უბრალოდ არ არის ან ისინი სწორად არ მუშაობს. თუმცა, მჯერა, რომ Nomad გააგრძელებს განვითარებას და სამომავლოდ შეიძენს იმ ფუნქციებს, რაც ყველას სჭირდება.

ავტორი: ილია ანდრეევი, რედაქტირებულია ალექსეი ჟადანის და Live Linux გუნდის მიერ


წყარო: www.habr.com