Nomád fürt létrehozása a Consul segítségével és integrálása a Gitlabbal

Bevezetés

Az utóbbi időben a Kubernetes népszerűsége gyorsan növekszik - egyre több projekt valósítja meg. Egy olyan hangszerelőt szerettem volna érinteni, mint a Nomad: tökéletes olyan projektekhez, amelyek már a HashiCorp más megoldásait használják, például a Vault és a Consul, és maguk a projektek sem bonyolultak az infrastruktúra szempontjából. Ez az anyag utasításokat tartalmaz a Nomad telepítéséhez, két csomópont egy klaszterbe való kombinálásához, valamint a Nomad és a Gitlab integrálásához.

Próbapad

Egy kicsit a tesztpadról: három virtuális szervert használnak 2 CPU, 4 RAM, 50 Gb SSD jellemzőkkel, közös helyi hálózatba egyesítve. A nevük és IP-címük:

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, konzul telepítése. Nomád klaszter létrehozása

Kezdjük az alap telepítéssel. Bár a beállítás egyszerű volt, a cikk sértetlensége érdekében leírom: lényegében piszkozatokból és jegyzetekből készült, hogy szükség esetén gyorsan elérhető legyen.

Mielőtt elkezdené a gyakorlatot, megbeszéljük az elméleti részt, mert ebben a szakaszban fontos megérteni a jövőbeli struktúrát.

Két nomád csomópontunk van, és ezeket szeretnénk egy klaszterbe egyesíteni, és a jövőben szükségünk lesz az automatikus klaszterskálázásra is - ehhez szükségünk lesz a Consulra. Ezzel az eszközzel a fürtözés és az új csomópontok hozzáadása nagyon egyszerű feladattá válik: a létrehozott Nomad csomópont csatlakozik a Consul ügynökhöz, majd csatlakozik a meglévő Nomad fürthöz. Ezért az elején telepítjük a Consul szervert, beállítjuk az alapvető http jogosultságot a webpanelhez (alapértelmezés szerint jogosulatlan és külső címről érhető el), valamint magukat a Consul ügynököket a Nomad szervereken, ami után csak a Nomádhoz megyünk tovább.

A HashiCorp eszközeinek telepítése nagyon egyszerű: lényegében csak áthelyezzük a bináris fájlt a bin könyvtárba, beállítjuk az eszköz konfigurációs fájlját, és létrehozzuk a szervizfájlt.

Töltse le a Consul bináris fájlt, és csomagolja ki a felhasználó kezdőkönyvtárába:

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/

Most már van egy kész konzuli binárisunk a további konfiguráláshoz.

A Consul-lal való együttműködéshez létre kell hoznunk egy egyedi kulcsot a keygen paranccsal:

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

Térjünk át a Consul konfiguráció beállítására, hozzunk létre egy /etc/consul.d/ könyvtárat a következő szerkezettel:

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

A bootstrap könyvtár tartalmazni fog egy config.json konfigurációs fájlt - ebben adjuk meg a Consul beállításait. A tartalma:

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

Nézzük külön-külön a főbb irányelveket és azok jelentését:

• bootstrap: igaz. Ha csatlakoztatva vannak, engedélyezzük az új csomópontok automatikus hozzáadását. Megjegyzem, itt nem tüntetjük fel a várható csomópontok pontos számát.
• szerver: igaz. Szerver mód engedélyezése. A konzul ezen a virtuális gépen jelenleg az egyetlen szerverként és mesterként fog működni, a Nomad virtuális gépe lesz a kliens.
• adatközpont: dc1. Adja meg az adatközpont nevét a fürt létrehozásához. A klienseken és a szervereken azonosnak kell lennie.
• titkosítani: a kulcsod. A kulcs, amelynek egyedinek kell lennie, és minden kliensen és szerveren meg kell egyeznie. A consul keygen paranccsal generálva.
• start_join. Ebben a listában megadjuk azoknak az IP-címeknek a listáját, amelyekhez a kapcsolat létrejön. Jelenleg csak a saját címünket hagyjuk meg.

Ezen a ponton a consul parancsot futtathatjuk a parancssor használatával:

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

Ez egy jó módja a hibakeresésnek, azonban nyilvánvaló okok miatt nem fogja tudni folyamatosan használni ezt a módszert. Hozzon létre egy szolgáltatásfájlt a Consul systemd-n keresztüli kezelésére:

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

A consul.service fájl tartalma:

[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

Indítsa el a Consul programot a systemctl-n keresztül:

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

Ellenőrizzük: a szolgáltatásunknak futnia kell, és a consul Members parancsot végrehajtva látnunk kell a szerverünket:

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

Következő lépés: az Nginx telepítése, valamint a proxy és a http hitelesítés beállítása. Az nginx-et a csomagkezelőn keresztül telepítjük, és az /etc/nginx/sites-enabled könyvtárban létrehozunk egy consul.conf konfigurációs fájlt a következő tartalommal:

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 felejtsen el létrehozni egy .htpasswd fájlt, és létrehozni hozzá egy felhasználónevet és jelszót. Ez az elem azért szükséges, hogy a webpanel ne legyen elérhető mindenki számára, aki ismeri a domainünket. A Gitlab beállításakor azonban ezt el kell hagynunk - különben nem tudjuk telepíteni az alkalmazásunkat a Nomadra. Az én projektemben a Gitlab és a Nomad is csak a szürke weben van, tehát itt nincs ilyen probléma.

A fennmaradó két szerveren a Consul ügynököket telepítjük az alábbi utasítások szerint. A lépéseket megismételjük a bináris fájllal:

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/

Az előző szerverhez hasonlóan létrehozunk egy könyvtárat az /etc/consul.d konfigurációs fájlok számára a következő szerkezettel:

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

A config.json fájl tartalma:

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

Mentse el a változtatásokat, és folytassa a szolgáltatásfájl beállításával, annak tartalmával:

/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

Elindítjuk a konzult a szerveren. Most az indítás után látnunk kell a konfigurált szolgáltatást az nsul tagokban. Ez azt jelenti, hogy sikeresen csatlakozott a fürthöz ügyfélként. Ismételje meg ugyanezt a második szerveren, és ezután kezdhetjük a Nomad telepítését és konfigurálását.

A Nomad részletesebb telepítése a hivatalos dokumentációban található. Két hagyományos telepítési mód létezik: bináris fájl letöltése és forrásból való fordítás. Én az első módszert választom.

Megjegyzés: A projekt nagyon gyorsan fejlődik, gyakran jelennek meg új frissítések. Talán egy új verzió jelenik meg, mire ez a cikk elkészül. Ezért olvasás előtt azt javaslom, hogy ellenőrizze a Nomad aktuális verzióját, és töltse le.

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

Kicsomagolás után kapunk egy 65 MB súlyú Nomad bináris fájlt - át kell helyezni a /usr/local/bin mappába.

Hozzon létre egy adatkönyvtárat a Nomad számára, és szerkessze a szolgáltatásfájlját (valószínűleg az elején nem fog létezni):

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

Illessze be a következő sorokat:

[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

Azonban nem sietünk a nomad elindításával - még nem hoztuk létre a konfigurációs fájlját:

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

A végső könyvtárstruktúra a következő lesz:

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

A nomad.hcl fájlnak a következő konfigurációt kell tartalmaznia:

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

A server.hcl fájl tartalma:

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 felejtse el megváltoztatni a konfigurációs fájlt a második szerveren - ott meg kell változtatnia a http direktíva értékét.

Az utolsó dolog ebben a szakaszban az Nginx konfigurálása a proxy használatához és a http hitelesítés beállításához. A nomad.conf fájl tartalma:

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

Most már külső hálózaton keresztül érhetjük el a webpanelt. Csatlakozzon, és lépjen a szerverek oldalára:

1. kép A Nomad fürt kiszolgálóinak listája

Mindkét szerver sikeresen megjelenik a panelen, ugyanazt fogjuk látni a nomad node status parancs kimenetében:

2. kép A nomád csomópont állapota parancs kimenete

Mi a helyzet a konzullal? Nézzük meg. Lépjen a Consul vezérlőpultra, a csomópontok oldalára:

3. kép A Consul klaszter csomópontjainak listája

Most van egy felkészült Nomádunk, aki a konzullal együttműködve dolgozik. Az utolsó szakaszban eljutunk a szórakoztató részhez: a Docker konténerek szállításának beállítása a Gitlabtól a Nomadig, és beszélünk néhány egyéb jellegzetességéről is.

Gitlab Runner létrehozása

A docker képek Nomadra történő telepítéséhez külön futót fogunk használni, amelyben a Nomad bináris fájl található (itt egyébként megjegyezhetjük a Hashicorp alkalmazások egy másik jellemzőjét - külön-külön ezek egyetlen bináris fájl). Töltsd fel a futókönyvtárba. Készítsünk hozzá egy egyszerű Docker-fájlt a következő tartalommal:

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

Ugyanebben a projektben létrehozzuk a .gitlab-ci.yml fájlt:

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}

Ennek eredményeként elérhető lesz a Nomad runner képe a Gitlab Registry-ben, most már közvetlenül a projekt tárolójába léphetünk, létrehozhatunk egy Pipeline-t és konfigurálhatjuk a Nomad nomád feladatát.

Projekt beállítása

Kezdjük a Nomad feladatfájljával. A cikkben szereplő projektem meglehetősen primitív lesz: egyetlen feladatból fog állni. A .gitlab-ci tartalma a következő lesz:

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

Itt a központi telepítés manuálisan történik, de konfigurálhatja úgy, hogy módosítsa a projektkönyvtár tartalmát. A csővezeték két szakaszból áll: a kép összeállításából és a nomádba történő telepítéséből. Az első szakaszban összeállítunk egy docker image-et, és betoljuk a Registry-be, a másodikban pedig elindítjuk a munkát a Nomadban.

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

Kérjük, vegye figyelembe, hogy van egy privát rendszerleíró adatbázisom, és a docker-kép sikeres lekéréséhez be kell jelentkeznem abba. Ebben az esetben a legjobb megoldás az, ha beír egy bejelentkezési nevet és jelszót a Vaultba, majd integrálja a Nomaddal. A Nomad natívan támogatja a Vaultot. De először telepítsük a Nomad in Vault szükséges szabályzatait; ezek letölthetők:

# 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

Most, miután létrehoztuk a szükséges házirendeket, hozzáadjuk a Vault integrációt a job.nomad fájl feladatblokkjához:

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

A token általi engedélyezést használom, és közvetlenül itt regisztrálom, lehetőség van arra is, hogy a tokent változóként adja meg a nomád agent indításakor:

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

Most már használhatjuk a kulcsokat a Vaulttal. A működés elve egyszerű: Nomad jobban létrehozunk egy fájlt, amely tárolja a változók értékeit, például:

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
}

Ezzel az egyszerű megközelítéssel konfigurálhatja a tárolók szállítását a Nomad fürthöz, és a jövőben dolgozhat vele. Azt fogom mondani, hogy bizonyos mértékig szimpatizálok a Nomaddal - alkalmasabb kis projektekhez, ahol a Kubernetes további bonyolultságot okozhat, és nem fogja kihasználni a benne rejlő lehetőségeket. Ráadásul a Nomad tökéletes kezdőknek – könnyű telepíteni és konfigurálni. Néhány projekt tesztelésekor azonban problémába ütközöm a korai verzióival – sok alapvető funkció egyszerűen nincs meg, vagy nem működik megfelelően. Úgy gondolom azonban, hogy a Nomad tovább fog fejlődni, és a jövőben el fogja érni azokat a funkciókat, amelyekre mindenkinek szüksége van.

Szerző: Ilya Andreev, szerkesztette Alexey Zhadan és a Live Linux csapata


Forrás: will.com