Bevezetés
Az utóbbi időben rohamosan nőtt a Kubernetes népszerűsége - egyre több projekt implementálja azt. Én viszont szeretném érinteni egy másik orchestrátort, a Nomadot: ez kiválóan alkalmas olyan projektekhez, ahol már más HashiCorp megoldásokat használnak, például Vaultot és Consulta, és maguk a projektek nem komplexek az infrastruktúra szempontjából. A cikkben útmutatót talál a Nomad telepítéséről, két nóda klaszterbe integraciónjáról, valamint a Nomad és Gitlab integrációjáról.
Tesztkörnyezet
Kicsit a tesztkörnyezetről: három virtuális szervert használunk, amelyek jellemzői 2 CPU, 4 RAM, 50 Gb SSD, és egy közös helyi hálózatba vannak kötve. A nevük és IP címük:
- nomad-livelinux-01: 172.30.0.5
- nomad-livelinux-02: 172.30.0.10
- consul-livelinux-01: 172.30.0.15
Nomad és Consul telepítése. Nomad klaszter létrehozása
Kezdjük az alapvető telepítéssel. A telepítés egyszerűsége ellenére leírom azt a cikk teljessége érdekében: valójában jegyzetekből és vázlatokból készült a gyors hozzáférés érdekében.
Mielőtt a gyakorlati részhez kezdenénk, beszéljük át a teoretikus részt, mert ebben a szakaszban fontos megérteni a jövőbeli struktúrát.
Két Nomad nodánk van, és szeretnénk őket klaszterbe egyesíteni, a jövőbeli időszakra pedig szükségünk lesz automatikus klaszter méretezésre — ehhez a Consult fog kelleni. Ezzel az eszközzel a klaszterizálás és új nodák hozzáadása nagyon egyszerű feladat: a létrehozott Nomad noda csatlakozik a Consul ügynökhöz, majd csatlakozik a meglévő Nomad klaszterhez. Ezért először telepítjük a Consul szervert, beállítjuk az alap HTTP hitelesítést a webpanelhez (ez alapértelmezettként hitelesítés nélkül elérhető és külső címről is hozzáférhető), valamint magukat a Consul ügynököket a Nomad szervereken, csak ezután fogunk hozzá a Nomadhoz.
A HashiCorp eszközök 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 szolgáltatás fájlt.
Letöltjük a Consul bináris fájlt és kibővítjük a felhasználó otthoni könyvtárában:
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 megvan a kész bináris fájlunk a Consul további konfigurálásához.
A Consullal való munkához létre kell hoznunk egy egyedi kulcsot a keygen parancs segítségével:
root@consul-livelinux-01:~# consul keygen
Lépjünk a Consul konfigurációjának beállítására, hozzunk létre egy könyvtárat /etc/consul.d/ a következő struktúrával:
/etc/consul.d/
├── bootstrap
│ └── config.jsonA bootstrap könyvtárban lesz a config.json konfigurációs fájl - itt fogjuk beállítani a Consul paramétereit. A fájl 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 meg az alapvető direktívákat és azok értelmezését:
- bootstrap: true. Automatikus új csomópontok hozzáadása engedélyezve, amennyiben csatlakoznak. Megjegyzem, hogy itt nem határozzuk meg az elvárt csomópontok számát.
- server: true. A szerver üzemmód aktiválása. A Consul ezen a virtuális gépen jelenleg az egyetlen szerver és mester, a Nomad VM-ek kliensek lesznek.
- datacenter: dc1. A klaszter létrehozásához megadjuk a adatközpont nevét. Ennek egyeznie kell a klienseken és a szervereken is.
- encrypt: your-key. A kulcs, amelynek szintén egyedinek kell lennie, és minden kliensnek és szervernek egybe kell esnie. Ezt a consul keygen paranccsal generáljuk.
- start_join. Ebben a listában megadjuk az IP címek listáját, amelyekhez csatlakozni fogunk. Jelenleg csak a saját címünket hagyjuk benne.
Ezen a ponton elindíthatjuk a consolt a parancssoron keresztül:
root@consul-livelinux-01:~# /usr/local/bin/consul agent -config-dir /etc/consul.d/bootstrap -uiEz egy elég jó hibakeresési módszer most, azonban tartósan nem fogjuk tudni használni nyilvánvaló okok miatt. Készítsünk szolgáltatásfájlt a Consul systemd általi kezelésére:
root@consul-livelinux-01:~# nano /etc/systemd/system/consul.service
A consul.service fájl tartalma:
[Unit]
Description=Consul indítási folyamat
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.targetIndítsuk el a Consult a systemctl segítségével:
root@consul-livelinux-01:~# systemctl start consul
Ellenőrizzük: a szolgáltatásnak elindítva kell lennie, és a consul members parancs végrehajtásakor 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 dc1A következő lépés: Nginx telepítése és a proxyzás, http hitelesítés beállítása. Telepítsük az nginx-t a csomagkezelőn keresztül, és az /etc/nginx/sites-enabled könyvtárban hozzuk létre a 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 "Jelszóval védett terület";
}
}Ne felejtsen el .htpasswd fájlt létrehozni és generálni hozzá felhasználónevet és jelszót. Ez a lépés szükséges ahhoz, hogy a webpanel ne legyen elérhető bárki számára, aki ismeri a domainünket. Azonban a Gitlab beállításakor ezt a megoldást el kell hagynunk - különben nem tudjuk telepíteni az alkalmazásunkat a Nomad-ba. A projektomban a Gitlab és a Nomad csak a szürke hálózaton belül található, így itt ezzel a problémával nem találkozunk.
A másik két szerveren telepítsük a Consul ügynököket a következő utasítások alapján. Ismételjük meg a lépéseket 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/A korábbi szerverhez hasonlóan hozzunk létre egy könyvtárat a konfigurációs fájlok számára /etc/consul.d a következő struktúrával:
/etc/consul.d/
├── client
│ └── config.jsonA 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", # lokális vm cím
"start_join": ["172.30.0.15"], # távoli konzol szerver cím
"ports": {
"dns": 53
}Mentjük a változtatásokat, és folytatjuk a szolgáltatásfájl beállításával, annak tartalma:
/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.targetElindítjuk a consolt a szerveren. Most, a megkezdés után, a nsul members-ben látnunk kell a beállított szolgáltatást. Ez azt jelenti, hogy sikeresen csatlakozott a klaszterhez mint kliens. Ismételje meg ugyanezt a második szerveren, majd elkezdhetjük a Nomad telepítését és beállítását.
A Nomad részletes telepítése az hivatalos dokumentációjában található. Két hagyományos telepítési mód létezik: a 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. Lehetséges, hogy a cikk befejezésének időpontjára új verzió jelenik meg. Ezért ajánlom, hogy olvasás előtt ellenőrizze az aktuális Nomad verziót, és ezt 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.dA kibővítés után egy 65 MB-os Nomad bináris fájlunk lesz, amelyet a /usr/local/bin/ mappába kell áthelyezni.
Hozzunk létre egy data mappát a Nomad számára, és módosítsuk a service fájlját (valószínűleg az elején még nem létezik):
root@nomad-livelinux-01:~# mkdir --parents /opt/nomad
root@nomad-livelinux-01:~# nano /etc/systemd/system/nomad.serviceIllesszük be az alábbi 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.targetNe rohanjunk 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ő mappa struktúrája a következő lesz:
/etc/nomad.d/
├── nomad.hcl
└── server.hclA 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 felejtsd el módosítani a konfigurációs fájlt a második szerveren - ott meg kell változtatni az http direktíva értékét.
Az utolsó lépés ezen a ponton az Nginx beállítása a proxizáláshoz é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 "Jelszóval védett terület";
}
}Most már hozzáférhetünk a web panelhez külső hálózaton. Csatlakozzunk és lépjünk a servers oldalra:
1. kép. A Nomad klaszterben található szerverek listája
Mindkét szerver sikeresen megjelenik a panelen, ugyanazt látjuk a nomad node status parancs kimenetében is:
2. kép. A nomad node status parancs kimenete
Mi a helyzet a Consul oldaláról? Nézzük meg. Lépjünk a Consul vezérlőpultra, a nodes oldalra:
3. kép. A Consul klaszterben található nodok listája
Most már van egy előkészített Nomadunk, amely működik a Consul mellett. A záró lépésben a legérdekesebbhez érkezünk: beállítjuk a Docker konténerek szállítását a Gitlabból a Nomadhoz, és néhány más jellemzőjéről is beszélünk.
Gitlab Runner létrehozása
A Docker képek telepítéséhez a Nomadban külön runner-t használunk, amelyben a Nomad bináris fájlja található (itt érdemes megemlíteni a Hashicorp alkalmazások egy másik sajátosságát - külön-külön egyetlen bináris fájlt képviselnek). Töltsd le a runner könyvtárába. Számára létrehozunk egy egyszerű Dockerfile-t 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-t:
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 egy elérhető Nomad runner képünk lesz a Gitlab Registry-ben, most közvetlenül a projekt tárolójába léphetünk, létrehozunk egy Pipeline-t és beállítjuk a Nomad job-ot.
A projekt beállítása
Kezdjük a Nomad job fájljával. A cikkben bemutatott projekt meglehetősen primitív lesz: egyetlen feladatból fog állni. A .gitlab-ci tartalma a következőképpen alakul:
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}' 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: manualItt a telepítés manuális módban történik, de beállíthatod, hogy a projekt könyvtárának tartalmát változtassa. A Pipeline két lépésből áll: a kép létrehozásából és annak telepítéséből a Nomadba. Az első lépésben létrehozzuk a Docker képet és felpusholjuk a Registry-be, a második lépésben pedig elindítjuk a job-ot a Nomadban.
feladat "monitoring-status" {
adatközpontok = ["dc1"]
migrálás {
max_párhuzamos = 3
egészség_ellenőrzés = "ellenőrzések"
min_egészséges_idő = "15s"
egészséges_határidő = "5m"
}
csoport "zhadan.ltd" {
szám = 1
frissítés {
max_párhuzamos = 1
min_egészséges_idő = "30s"
egészséges_határidő = "5m"
előrehaladás_határidő = "10m"
automatikus_visszaállítás = true
}
feladat "szolgáltatás-ellenőrzés" {
vezető = "docker"
konfiguráció {
kép = "registry.domain.name/example/project:${CI_COMMIT_SHORT_SHA}"
kényszer_húzás = true
hitelesítés {
felhasználónév = "gitlab_user"
jelszó = "gitlab_password"
}
port_térkép {
http = 8000
}
}
erőforrások {
hálózat {
port "http" {}
}
}
}
}
}Kérjük, vegye figyelembe, hogy zárt Registry-m van, és a Docker-kép sikeres lehúzásához be kell jelentkeznem. A legjobb megoldás ebben az esetben a felhasználónév és jelszó Vault-ba való zárása, majd annak integrálása a Nomaddal. A Nomad natív módon támogatja a Vault-ot. De először a Vault-ban állítsuk be a szükséges irányelveket a Nomad számára, amelyeket le lehet tölteni:
# 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.jsonMost, hogy létrehoztuk a szükséges irányelveket, a feladat blokkban a job.nomad fájlban hozzáadjuk a Vault integrációját:
vault {
engedélyezve = true
cím = "https://vault.domain.name:8200"
token = "token"
}Token alapú hitelesítést használok, és ezt közvetlenül itt adom meg, van lehetőség a token változóként való megadására a nomad agent indításakor:
$ VAULT_TOKEN= nomad agent -config /path/to/config
Most már használhatjuk a Vault kulcsait. A működési elv egyszerű: létrehozunk egy fájlt a Nomad jobban, amely tárolni fogja a változók értékeit, például:
sablon {
adatok = <<EOH
{{with secret "secrets/pipeline-keys"}}
REGISTRY_LOGIN="{{ .Data.REGISTRY_LOGIN }}"
REGISTRY_PASSWORD="{{ .Data.REGISTRY_LOGIN }}{{ end }}"
EOH
cél = "secrets/service-name.env"
env = true
}Ezzel az egyszerű megközelítéssel beállíthatjuk a konténerek szállítását a Nomad klaszterbe, és a továbbiakban is dolgozhatunk vele. Én azt mondom, hogy bizonyos szempontból kedvelem a Nomadot — jobban illik a kis projektekhez, ahol a Kubernetes további bonyodalmakat okozhat, és nem tudja teljes mértékben kihasználni a potenciálját. Ezen kívül, a Nomad kiválóan alkalmas kezdők számára — egyszerűen telepíthető és konfigurálható. Azonban, bizonyos projektek tesztelése során találkoztam a korai verziók problémáival — sok alapfunkció egyszerűen hiányzik, vagy nem működnek megfelelően. Mindezek ellenére úgy gondolom, hogy a Nomad tovább fog fejlődni és a jövőben elnyeri a szükséges funkciókat.
Szerző: Ilya Andrejev, szerkesztette Alexej Zsadan és a «Live Linux» csapata
Forrás: habr.com
