ProHoster > Dienoraštis > Administravimas > Nomad klasterio nustatymas naudojant Consul ir integravimas su Gitlab

Nomad klasterio nustatymas naudojant Consul ir integravimas su Gitlab

įvedimas

Pastaruoju metu „Kubernetes“ populiarumas sparčiai auga – vis daugiau projektų ją įgyvendina. Norėjau paliesti tokį orkestrantą kaip Nomad: jis puikiai tinka projektams, kuriuose jau naudojami kiti HashiCorp sprendimai, pavyzdžiui, Vault ir Consul, o patys projektai nėra sudėtingi infrastruktūros požiūriu. Šioje medžiagoje bus instrukcijos, kaip įdiegti Nomad, sujungti du mazgus į klasterį, taip pat integruoti Nomad su Gitlab.

Nomad klasterio nustatymas naudojant Consul ir integravimas su Gitlab

Bandymo stendas

Šiek tiek apie bandymų stendą: naudojami trys virtualūs serveriai su 2 CPU, 4 RAM, 50 Gb SSD charakteristikomis, sujungti į bendrą vietinį tinklą. Jų vardai ir IP adresai:

  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, konsulas, įrengimas. Klasterio kūrimas

Pradėkime nuo pagrindinio diegimo. Nors sąranka buvo paprasta, aprašysiu jį dėl straipsnio vientisumo: jis iš esmės buvo sukurtas iš juodraščių ir pastabų, kad prireikus būtų galima greitai pasiekti.

Prieš pradėdami praktiką, aptarsime teorinę dalį, nes šiame etape svarbu suprasti būsimą struktūrą.

Turime du nomadinius mazgus ir norime juos sujungti į klasterį, o ateityje taip pat reikės automatinio klasterio mastelio keitimo – tam mums reikės Consul. Naudojant šį įrankį, grupavimas ir naujų mazgų pridėjimas tampa labai paprasta užduotimi: sukurtas Nomad mazgas prisijungia prie Consul agento, o tada prisijungia prie esamo Nomad klasterio. Todėl pradžioje įdiegsime Consul serverį, sukonfigūruosime pagrindinį http autorizavimą žiniatinklio skydeliui (ji pagal nutylėjimą yra be leidimo ir pasiekiama išoriniu adresu), taip pat patys Consul agentai Nomad serveriuose, po kurių mes eisime tik į Nomadą.

„HashiCorp“ įrankių diegimas yra labai paprastas: iš esmės mes tiesiog perkeliame dvejetainį failą į bin katalogą, nustatome įrankio konfigūracijos failą ir sukuriame jo aptarnavimo failą.

Atsisiųskite „Consul“ dvejetainį failą ir išpakuokite jį į vartotojo namų katalogą:

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/

Dabar turime paruoštą dvejetainį konsulo konfigūraciją.

Norėdami dirbti su Consul, turime sukurti unikalų raktą naudodami komandą keygen:

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

Pereikime prie Consul konfigūracijos nustatymo, sukurdami katalogą /etc/consul.d/ su tokia struktūra:

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

Bootstrap kataloge bus konfigūracijos failas config.json – jame nustatysime Consul nustatymus. Jo turinys:

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

Pažvelkime į pagrindines direktyvas ir jų reikšmes atskirai:

  • bootstrap: tiesa. Įjungiame automatinį naujų mazgų pridėjimą, jei jie yra prijungti. Atkreipiu dėmesį, kad čia nenurodome tikslaus numatomų mazgų skaičiaus.
  • serveris: tiesa. Įjungti serverio režimą. Konsulas šioje virtualioje mašinoje šiuo metu veiks kaip vienintelis serveris ir pagrindinis kompiuteris, klientai bus Nomad's VM.
  • duomenų centras: dc1. Norėdami sukurti klasterį, nurodykite duomenų centro pavadinimą. Jis turi būti identiškas tiek klientuose, tiek serveriuose.
  • šifruoti: jūsų raktas. Raktas, kuris taip pat turi būti unikalus ir atitikti visus klientus ir serverius. Sukurta naudojant komandą consul keygen.
  • start_join. Šiame sąraše nurodome IP adresų, prie kurių bus užmegztas ryšys, sąrašą. Šiuo metu paliekame tik savo adresą.

Šiuo metu galime paleisti konsulą naudodami komandinę eilutę:

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

Tai geras būdas derinti dabar, tačiau dėl akivaizdžių priežasčių negalėsite nuolat naudoti šio metodo. Sukurkime paslaugos failą, skirtą valdyti Consul per systemd:

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

Consul.service failo turinys: 

[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

Paleiskite Consul per systemctl:

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

Patikrinkime: mūsų paslauga turi veikti, o vykdydami konsulo narių komandą turėtume pamatyti savo serverį:

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

Kitas etapas: „Nginx“ diegimas ir tarpinio serverio bei http autorizacijos nustatymas. Įdiegiame nginx per paketų tvarkyklę ir /etc/nginx/sites-enabled kataloge sukuriame konfigūracijos failą consul.conf su tokiu turiniu:

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

Nepamirškite sukurti .htpasswd failo ir sugeneruoti jam vartotojo vardą bei slaptažodį. Šis elementas reikalingas, kad žiniatinklio skydelis nebūtų pasiekiamas visiems, kurie žino mūsų domeną. Tačiau nustatydami „Gitlab“ turėsime to atsisakyti – kitaip negalėsime įdiegti savo programos „Nomad“. Mano projekte ir „Gitlab“, ir „Nomad“ yra tik pilkame žiniatinklyje, todėl čia tokios problemos nėra.

Likusiuose dviejuose serveriuose įdiegiame Consul agentus pagal šias instrukcijas. Kartojame veiksmus su dvejetainiu failu:

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/

Analogiškai su ankstesniu serveriu sukuriame konfigūracijos failų /etc/consul.d katalogą su tokia struktūra:

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

Config.json failo turinys:

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

Išsaugokite pakeitimus ir pereikite prie paslaugos failo nustatymo, jo turinio:

/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

Paleidžiame konsulą serveryje. Dabar po paleidimo turėtume matyti sukonfigūruotą paslaugą nsul nariuose. Tai reikš, kad jis sėkmingai prisijungė prie klasterio kaip klientas. Pakartokite tą patį antrame serveryje ir po to galime pradėti diegti ir konfigūruoti Nomad.

Išsamesnis Nomad montavimas aprašytas oficialioje jo dokumentacijoje. Yra du tradiciniai diegimo būdai: dvejetainio failo atsisiuntimas ir kompiliavimas iš šaltinio. Aš pasirinksiu pirmąjį metodą.

Atkreipti dėmesį: Projektas vystosi labai greitai, dažnai išleidžiami nauji atnaujinimai. Galbūt iki šio straipsnio pabaigos bus išleista nauja versija. Todėl prieš skaitant rekomenduoju patikrinti šiuo metu galiojančią Nomad versiją ir ją atsisiųsti. 

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

Išpakavus gausime 65 MB sveriantį dvejetainį Nomad failą – jį reikia perkelti į /usr/local/bin.

Sukurkime Nomad duomenų katalogą ir redaguosime jo paslaugų failą (jo greičiausiai nebus iš pradžių):

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

Įklijuokite ten šias eilutes:

[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

Tačiau mes neskubame paleisti nomad - dar nesukūrėme jo konfigūracijos failo:

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

Galutinė katalogo struktūra bus tokia:

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

Nomad.hcl faile turi būti tokia konfigūracija:

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

Server.hcl failo turinys:

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
}

Nepamirškite pakeisti konfigūracijos failo antrame serveryje – ten reikės pakeisti http direktyvos reikšmę.

Paskutinis dalykas šiame etape yra sukonfigūruoti „Nginx“, kad būtų galima naudoti tarpinį serverį ir nustatyti http prieigos teisę. Failo nomad.conf turinys:

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

Dabar žiniatinklio skydelį galime pasiekti per išorinį tinklą. Prisijunkite ir eikite į serverių puslapį:

Nomad klasterio nustatymas naudojant Consul ir integravimas su Gitlab
1 vaizdas. Nomad klasterio serverių sąrašas

Abu serveriai sėkmingai rodomi skydelyje, tą patį matysime klajoklių mazgo būsenos komandos išvestyje:

Nomad klasterio nustatymas naudojant Consul ir integravimas su Gitlab
2 vaizdas. Klajoklių mazgo būsenos komandos išvestis

O konsulas? Pažiūrėkime. Eikite į Consul valdymo skydelį, į mazgų puslapį:
Nomad klasterio nustatymas naudojant Consul ir integravimas su Gitlab
3 vaizdas. Konsulų klasterio mazgų sąrašas

Dabar turime paruoštą Nomadą, kuris dirba kartu su konsulu. Paskutiniame etape pateksime į smagiąją dalį: nustatysime „Docker“ konteinerių pristatymą iš „Gitlab“ į „Nomad“ ir pakalbėsime apie kai kurias kitas išskirtines jo savybes.

„Gitlab Runner“ kūrimas

Norėdami įdiegti docker vaizdus į Nomad, naudosime atskirą bėgiką su Nomad dvejetainiu failu (čia, beje, galime atkreipti dėmesį į dar vieną Hashicorp programų ypatybę - atskirai jie yra vienas dvejetainis failas). Įkelkite jį į bėgikų katalogą. Sukurkime jam paprastą Docker failą su tokiu turiniu:


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

Tame pačiame projekte sukuriame .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}

Dėl to Gitlab registre turėsime galimą Nomad bėgiko vaizdą, dabar galime eiti tiesiai į projekto saugyklą, sukurti vamzdyną ir sukonfigūruoti Nomad klajoklių darbą.

Projekto sąranka

Pradėkime nuo Nomad darbo failo. Mano projektas šiame straipsnyje bus gana primityvus: jį sudarys viena užduotis. .gitlab-ci turinys bus toks:

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

Čia diegimas vyksta rankiniu būdu, tačiau galite jį sukonfigūruoti, kad pakeistumėte projekto katalogo turinį. Dujotiekį sudaro du etapai: vaizdo surinkimas ir jo diegimas klajokliams. Pirmajame etape mes surenkame dokerio vaizdą ir įkeliame jį į savo registrą, o antrajame pradedame darbą 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" {}
                }
            }
        }
    }
}

Atkreipkite dėmesį, kad turiu privatų registrą ir norint sėkmingai ištraukti dockerio vaizdą, turiu prie jo prisijungti. Geriausias sprendimas šiuo atveju yra įvesti prisijungimo vardą ir slaptažodį į Vault ir integruoti juos su Nomad. Nomad iš prigimties palaiko Vault. Tačiau pirmiausia įdiegkime pačiam „Nomad“ pačiam „Vault“ reikalingas strategijas; jas galima atsisiųsti:

# 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

Dabar, sukūrę reikiamą politiką, įtrauksime integraciją su Vault į užduočių bloką faile job.nomad:

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

Aš naudoju įgaliojimą pagal prieigos raktą ir registruoju tiesiogiai čia, taip pat yra galimybė nurodyti prieigos raktą kaip kintamąjį paleidžiant klajoklių agentą:

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

Dabar galime naudoti raktus su Vault. Veikimo principas paprastas: Nomad darbe sukuriame failą, kuriame bus saugomos kintamųjų reikšmės, pavyzdžiui:

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
}

Naudodami šį paprastą metodą galite sukonfigūruoti konteinerių pristatymą į Nomad klasterį ir dirbti su juo ateityje. Pasakysiu, kad tam tikru mastu užjaučiu Nomadą – jis labiau tinka mažiems projektams, kur Kubernetes gali sukelti papildomo sudėtingumo ir neišnaudos viso savo potencialo. Be to, Nomad puikiai tinka pradedantiesiems – jį lengva įdiegti ir konfigūruoti. Tačiau bandydamas kai kuriuos projektus, susiduriu su problema dėl ankstyvųjų jo versijų – daugelio pagrindinių funkcijų tiesiog nėra arba jos neveikia tinkamai. Tačiau tikiu, kad Nomad toliau vystysis ir ateityje įgis visiems reikalingų funkcijų.

Autorius: Ilja Andrejevas, redagavo Aleksejus Zhadanas ir „Live Linux“ komanda


Šaltinis: www.habr.com

Добавить комментарий