Nastavitev gruče Nomad z uporabo Consula in integracija z Gitlabom

Predstavitev

V zadnjem času priljubljenost Kubernetesa hitro narašča - vse več projektov ga izvaja. Želel sem se dotakniti orkestratorja, kot je Nomad: popoln je za projekte, ki že uporabljajo druge rešitve HashiCorp, na primer Vault in Consul, sami projekti pa niso infrastrukturno kompleksni. To gradivo bo vsebovalo navodila za namestitev Nomada, združevanje dveh vozlišč v gručo, kot tudi integracijo Nomada z Gitlabom.

Testno stojalo

Nekaj ​​o preskusni napravi: uporabljeni so trije virtualni strežniki z značilnostmi 2 CPE, 4 RAM, 50 Gb SSD, povezani v skupno lokalno omrežje. Njihova imena in naslovi IP:

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

Namestitev Nomad, Consul. Ustvarjanje gruče Nomad

Začnimo z osnovno namestitvijo. Čeprav je bila nastavitev preprosta, jo bom opisal zaradi celovitosti članka: v bistvu je bila ustvarjena iz osnutkov in opomb za hiter dostop, ko je to potrebno.

Preden začnemo s prakso, se bomo pogovorili o teoretičnem delu, saj je na tej stopnji pomembno razumeti prihodnjo strukturo.

Imamo dve nomad vozlišči in ju želimo združiti v gručo, v prihodnosti pa bomo potrebovali tudi samodejno skaliranje gruče - za to bomo potrebovali Consul. S tem orodjem postane združevanje v gruče in dodajanje novih vozlišč zelo preprosta naloga: ustvarjeno vozlišče Nomad se poveže z agentom Consul in se nato poveže z obstoječo gručo Nomad. Zato bomo na začetku namestili strežnik Consul, konfigurirali osnovno http avtorizacijo za spletno ploščo (ta je privzeto brez avtorizacije in je dostopna na zunanjem naslovu), ter same agente Consul na strežnikih Nomad, nato pa nadaljevali bomo le do Nomada.

Namestitev orodij HashiCorp je zelo preprosta: binarno datoteko preprosto premaknemo v imenik bin, nastavimo konfiguracijsko datoteko orodja in ustvarimo njegovo servisno datoteko.

Prenesite binarno datoteko Consul in jo razpakirajte v domači imenik uporabnika:

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/

Zdaj imamo pripravljeno dvojiško datoteko konzula za nadaljnjo konfiguracijo.

Za delo s Consulom moramo ustvariti edinstven ključ z ukazom keygen:

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

Preidimo na nastavitev konfiguracije Consul in ustvarimo imenik /etc/consul.d/ z naslednjo strukturo:

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

Imenik bootstrap bo vseboval konfiguracijsko datoteko config.json - v njej bomo nastavljali nastavitve Consul. Njegova vsebina:

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

Oglejmo si glavne direktive in njihov pomen ločeno:

• škorenj: prav. Omogočamo samodejno dodajanje novih vozlišč, če so povezana. Ugotavljam, da tukaj ne navajamo natančnega števila pričakovanih vozlišč.
• strežnik: prav. Omogoči strežniški način. Consul na tem virtualnem stroju bo trenutno deloval kot edini strežnik in master, Nomadov VM pa bodo odjemalci.
• podatkovno središče: dc1. Podajte ime podatkovnega centra, da ustvarite gručo. Biti mora enak na odjemalcih in strežnikih.
• šifriranje: vaš-ključ. Ključ, ki mora biti tudi edinstven in se mora ujemati na vseh odjemalcih in strežnikih. Ustvarjeno z ukazom consul keygen.
• start_join. Na tem seznamu navedemo seznam naslovov IP, na katere bo vzpostavljena povezava. Trenutno puščamo samo svoj naslov.

Na tej točki lahko zaženemo consul z ukazno vrstico:

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

To je dober način za odpravljanje napak zdaj, vendar te metode ne boste mogli nenehno uporabljati iz očitnih razlogov. Ustvarimo servisno datoteko za upravljanje Consul prek systemd:

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

Vsebina datoteke 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

Zaženi Consul prek systemctl:

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

Preverimo: naša storitev mora delovati in z izvedbo ukaza consul members bi morali videti naš strežnik:

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

Naslednja faza: namestitev Nginxa in nastavitev proxyja in http avtorizacije. Nginx namestimo prek upravitelja paketov in v imeniku /etc/nginx/sites-enabled ustvarimo konfiguracijsko datoteko consul.conf z naslednjo vsebino:

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

Ne pozabite ustvariti datoteke .htpasswd in zanjo ustvariti uporabniškega imena in gesla. Ta element je potreben, da spletna plošča ni na voljo vsem, ki poznajo našo domeno. Vendar pa bomo morali pri nastavitvi Gitlaba to opustiti - drugače ne bomo mogli razmestiti naše aplikacije v Nomad. V mojem projektu sta Gitlab in Nomad samo na sivem spletu, tako da tukaj ni te težave.

Na preostala dva strežnika namestimo Consul agente po naslednjih navodilih. Ponovimo korake z binarno datoteko:

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/

Po analogiji s prejšnjim strežnikom ustvarimo imenik za konfiguracijske datoteke /etc/consul.d z naslednjo strukturo:

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

Vsebina datoteke 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
     }

Shranite spremembe in nadaljujte z nastavitvijo storitvene datoteke, njene vsebine:

/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

Zaženemo konzul na strežniku. Zdaj, po zagonu, bi morali videti konfigurirano storitev v članih nsul. To bo pomenilo, da se je uspešno povezal z gručo kot odjemalec. Enako ponovimo na drugem strežniku in po tem lahko začnemo z namestitvijo in konfiguracijo Nomada.

Podrobnejša namestitev Nomada je opisana v njegovi uradni dokumentaciji. Obstajata dva tradicionalna načina namestitve: prenos binarne datoteke in prevajanje iz vira. Izbral bom prvo metodo.

Obvestilo: Projekt se razvija zelo hitro, pogosto se objavljajo nove posodobitve. Morda bo do konca tega članka izdana nova različica. Zato pred branjem priporočam, da preverite trenutno različico Nomada in jo prenesete.

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

Po razpakiranju bomo prejeli binarno datoteko Nomad, ki tehta 65 MB - premakniti jo je treba v /usr/local/bin.

Ustvarimo podatkovni imenik za Nomad in uredimo njegovo servisno datoteko (najverjetneje na začetku ne bo obstajala):

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

Tja prilepite naslednje vrstice:

[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

Vendar se nam ne mudi z zagonom nomada - nismo še ustvarili njegove konfiguracijske datoteke:

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

Končna struktura imenika bo naslednja:

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

Datoteka nomad.hcl mora vsebovati naslednjo konfiguracijo:

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

Vsebina datoteke 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
}

Ne pozabite spremeniti konfiguracijske datoteke na drugem strežniku - tam boste morali spremeniti vrednost http direktive.

Zadnja stvar na tej stopnji je konfiguracija Nginxa za proxy in nastavitev avtorizacije http. Vsebina datoteke 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";
        }
        
}

Zdaj lahko do spletne plošče dostopamo preko zunanjega omrežja. Povežite se in pojdite na stran strežnikov:

Slika 1. Seznam strežnikov v gruči Nomad

Oba strežnika sta uspešno prikazana na plošči, isto stvar bomo videli v izhodu ukaza status vozlišča nomad:

Slika 2. Izhod ukaza status vozlišča nomad

Kaj pa konzul? Gremo pogledat. Pojdite na nadzorno ploščo Consul, na stran z vozlišči:

Slika 3. Seznam vozlišč v gruči Consul

Zdaj imamo pripravljenega Nomada, ki deluje v povezavi s konzulom. V zadnji fazi bomo prišli do zabavnega dela: nastavitev dostave vsebnikov Docker iz Gitlaba v Nomad in govorili tudi o nekaterih njegovih drugih značilnih lastnostih.

Ustvarjanje Gitlab Runnerja

Za namestitev slik dockerja v Nomad bomo uporabili ločen tekalnik z binarno datoteko Nomad v notranjosti (tukaj lahko mimogrede opazimo še eno značilnost aplikacij Hashicorp - posamezno so ena binarna datoteka). Naložite ga v imenik tekačev. Ustvarimo preprosto Dockerfile zanj z naslednjo vsebino:

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

V istem projektu ustvarimo .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}

Posledično bomo imeli na voljo sliko tekača Nomad v registru Gitlab, zdaj pa lahko gremo neposredno v repozitorij projekta, ustvarimo cevovod in konfiguriramo Nomadovo nomadsko opravilo.

Nastavitev projekta

Začnimo z datoteko opravila za Nomad. Moj projekt v tem članku bo precej primitiven: sestavljen bo iz ene naloge. Vsebina .gitlab-ci bo naslednja:

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

Tu se uvedba izvede ročno, vendar jo lahko konfigurirate tako, da spremeni vsebino imenika projekta. Cevovod je sestavljen iz dveh stopenj: sestavljanje slike in njena namestitev v nomad. Na prvi stopnji sestavimo docker sliko in jo potisnemo v naš register, na drugi pa zaženemo naše delo v Nomadu.

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

Upoštevajte, da imam zasebni register in da se moram prijaviti vanj, če želim uspešno pridobiti sliko dockerja. Najboljša rešitev v tem primeru je, da vnesete prijavo in geslo v Vault in ga nato integrirate z Nomadom. Nomad izvorno podpira Vault. Najprej pa bomo v Vault samem namestili potrebne pravilnike za Nomad, lahko jih prenesete:

# 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

Zdaj, ko smo ustvarili potrebne pravilnike, bomo dodali integracijo z Vaultom v blok opravil v datoteki job.nomad:

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

Uporabljam avtorizacijo z žetonom in jo registriram neposredno tukaj, obstaja tudi možnost podajanja žetona kot spremenljivke ob zagonu nomad agenta:

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

Zdaj lahko uporabljamo ključe z Vaultom. Načelo delovanja je preprosto: v opravilu Nomad ustvarimo datoteko, ki bo shranila vrednosti spremenljivk, na primer:

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
}

S tem preprostim pristopom lahko konfigurirate dostavo vsebnikov v gručo Nomad in z njo delate v prihodnosti. Rekel bom, da do neke mere sočustvujem z Nomadom - bolj je primeren za majhne projekte, kjer lahko Kubernetes povzroči dodatno zapletenost in ne bo izkoristil svojega celotnega potenciala. Poleg tega je Nomad kot nalašč za začetnike – enostavno ga je namestiti in konfigurirati. Vendar pa pri testiranju na nekaterih projektih naletim na težavo z njegovimi zgodnjimi različicami - veliko osnovnih funkcij preprosto ni ali pa ne delujejo pravilno. Verjamem pa, da se bo Nomad še razvijal in v prihodnosti pridobil funkcije, ki jih vsi potrebujejo.

Avtor: Ilya Andreev, uredil Alexey Zhadan in ekipa Live Linux


Vir: www.habr.com