úvod
V poslední době popularita Kubernetes rychle roste - stále více projektů jej implementuje doma. Chtěl jsem se dotknout takového orchestrátora, jakým je Nomad: je perfektní pro projekty, kde se již používají jiná řešení od HashiCorp, jako je Vault a Consul, a projekty samotné nejsou z hlediska infrastruktury složité. Tento materiál poskytne pokyny pro instalaci Nomad, sloučení dvou uzlů do clusteru a také pro integraci Nomad s Gitlab.
Zkušební stojan
Něco málo o testovací stolici: jsou použity tři virtuální servery s charakteristikami 2 CPU, 4 RAM, 50 Gb SSD, spojené do společné lokální sítě. Jejich jména a IP adresy:
- nomad-livelinux-01: 172.30.0.5
- nomad-livelinux-02: 172.30.0.10
- consul-livelinux-01: 172.30.0.15
Instalace Nomada, konzul. Vytvoření nomádského klastru
Začněme základní instalací. Navzdory snadné instalaci jej popíšu kvůli celistvosti článku: ve skutečnosti byl vytvořen z konceptů a poznámek pro rychlý přístup v případě potřeby.
Než přistoupíme k praxi, probereme teoretickou část, protože v této fázi je důležité porozumět budoucí struktuře.
Máme dva nomádské uzly a chceme je spojit do clusteru, také do budoucna budeme potřebovat automatické škálování clusteru – k tomu potřebujeme Consul. S tímto nástrojem se shlukování a přidávání nových uzlů stává velmi jednoduchým úkolem: vytvořený uzel Nomad se připojí k agentovi Consul a poté se připojí ke stávajícímu clusteru Nomad. Na začátku tedy nainstalujeme server Consul, nakonfigurujeme základní http autorizaci pro webový panel (ve výchozím nastavení je bez autorizace a lze k němu přistupovat z externí adresy), stejně jako samotné agenty Consul na serverech Nomad, po kterou právě spustíme Nomad.
Instalace nástrojů HashiCorp je velmi jednoduchá: v podstatě jen přesuneme binární soubor do adresáře bin, nastavíme konfigurační soubor nástroje a vytvoříme jeho servisní soubor.
Stáhněte si binární soubor Consul a rozbalte jej do domovského adresáře uživatele:
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/Nyní máme konzulský binární soubor připravený k dalšímu přizpůsobení.
Abychom mohli pracovat s Consul, musíme vygenerovat jedinečný klíč pomocí příkazu keygen:
root@consul-livelinux-01:~# consul keygen
Pojďme ke konfiguraci Consul, vytvořte adresář /etc/consul.d/ s následující strukturou:
/etc/consul.d/
├── bootstrap
│ └── config.jsonAdresář bootstrap bude obsahovat konfigurační soubor config.json - v něm nastavíme nastavení Consul. Jeho obsah:
{
"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"]
}Pojďme analyzovat samostatně hlavní směrnice a jejich význam:
- bootstrap: skutečný. Povolit automatické přidávání nových uzlů, pokud jsou připojeny. Podotýkám, že zde neuvádíme přesný počet očekávaných uzlů.
- Server: skutečný. Zapněte režim serveru. Consul na tomto virtuálním stroji bude v tuto chvíli fungovat jako jediný server a master, VM Nomad budou klienti.
- datové centrum: dc1. Zadejte název datového centra pro vytvoření klastru. Musí být identické na klientech i serverech.
- šifrování:tvůj klíč. Klíč, který musí být také jedinečný a musí se shodovat na všech klientech a serverech. Generováno pomocí příkazu consul keygen.
- start_join. V tomto seznamu uvedeme seznam IP adres, na které bude navázáno spojení. V tuto chvíli necháváme pouze vlastní adresu.
V tomto okamžiku můžeme spustit konzul pomocí příkazového řádku:
root@consul-livelinux-01:~# /usr/local/bin/consul agent -config-dir /etc/consul.d/bootstrap -uiToto je nyní dobrý způsob ladění, ale ze zřejmých důvodů to nebude fungovat trvale. Vytvořme soubor služby pro správu Consul přes systemd:
root@consul-livelinux-01:~# nano /etc/systemd/system/consul.service
Obsah souboru 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.targetSpusťte Consul přes systemctl:
root@consul-livelinux-01:~# systemctl start consul
Zkontrolujeme: naše služba by měla být spuštěna a spuštěním příkazu členů konzula bychom měli vidět náš server:
root@consul-livelinux:/etc/consul.d# consul members
consul-livelinux 172.30.0.15:8301 alive server 1.5.0 2 dc1 <all>Další krok: instalace Nginx a nastavení proxy, autorizace http. Nainstalujte nginx prostřednictvím správce balíčků a v adresáři /etc/nginx/sites-enabled vytvořte konfigurační soubor consul.conf s následujícím obsahem:
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";
}
}Nezapomeňte vytvořit soubor .htpasswd a vygenerovat k němu uživatelské jméno a heslo. Tato položka je povinná, aby webový panel nebyl dostupný všem, kdo znají naši doménu. Při nastavování Gitlabu to však budeme muset odmítnout – jinak nebudeme moci naši aplikaci v Nomadu nasadit. V mém projektu jsou Gitlab i Nomad pouze na šedé síti, takže tady takový problém není.
Na zbývající dva servery nainstalujte agenty Consul podle následujících pokynů. Opakujeme kroky s binárním souborem:
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/Analogicky s předchozím serverem vytvoříme adresář pro konfigurační soubory /etc/consul.d s následující strukturou:
/etc/consul.d/
├── client
│ └── config.jsonObsah souboru 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
}Uložíme změny a přistoupíme k nastavení servisního souboru, jeho obsahem je:
/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.targetSpustíme konzul na serveru. Nyní, po spuštění, bychom měli vidět nakonfigurovanou službu v členech nsul. To bude znamenat, že se úspěšně připojil ke clusteru jako klient. Opakujte totéž na druhém serveru a poté můžeme začít instalovat a konfigurovat Nomad.
Podrobnější instalace Nomad je popsána v jeho oficiální dokumentaci. Existují dva tradiční způsoby instalace: stažení binárního souboru a kompilace ze zdroje. Zvolím první způsob.
Poznámka: projekt se vyvíjí velmi rychle, často vycházejí nové aktualizace. Možná, že v době, kdy bude článek dokončen, bude vydána nová verze. Před čtením proto doporučuji zkontrolovat aktuálně aktuální verzi Nomada a stáhnout si ji.
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.dPo rozbalení získáme binární soubor Nomad o velikosti 65 MB – je nutné jej přesunout do /usr/local/bin.
Vytvoříme datový adresář pro Nomad a upravíme jeho servisní soubor (pravděpodobně na začátku nebude existovat):
root@nomad-livelinux-01:~# mkdir --parents /opt/nomad
root@nomad-livelinux-01:~# nano /etc/systemd/system/nomad.serviceVložte tam následující řádky:
[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.targetSe spuštěním nomada však nespěcháme - ještě jsme nevytvořili jeho konfigurační soubor:
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
Výsledná adresářová struktura bude následující:
/etc/nomad.d/
├── nomad.hcl
└── server.hclSoubor nomad.hcl musí obsahovat následující konfiguraci:
datacenter = "dc1"
data_dir = "/opt/nomad"Obsah souboru 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
}Nezapomeňte změnit konfigurační soubor na druhém serveru - tam budete muset změnit hodnotu direktivy http.
Poslední věcí v této fázi je nastavení Nginx na proxy a instalace http autorizace. Obsah souboru 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";
}
}Nyní máme přístup k webovému panelu přes externí síť. Připojte se a přejděte na stránku serverů:
Obrázek 1. Seznam serverů v clusteru Nomad
Oba servery jsou úspěšně zobrazeny v panelu, totéž uvidíme ve výstupu příkazu nomad node status:
Obrázek 2. Výstup příkazu stavu uzlu Nomad
A co konzul? Pojďme se podívat. Přejděte na ovládací panel Consul na stránku uzlů:
Obrázek 3. Seznam uzlů v clusteru Consul
Nyní máme připraveného Nomada, který spolupracuje s konzulem. V konečné fázi se dostaneme k nejzajímavější části: nastavíme dodávku kontejnerů Docker z Gitlabu do Nomadu a také si povíme o některých jeho dalších charakteristických rysech.
Vytvoření Gitlab Runner
Pro nasazení docker image do Nomadu použijeme samostatný runner s binárním souborem Nomad uvnitř (zde lze mimochodem poznamenat ještě jednu vlastnost aplikací Hashicorp - jednotlivě jsou jediným binárním souborem). Nahrajte jej do adresáře runner. Vytvořme pro něj jednoduchý Dockerfile s následujícím obsahem:
FROM alpine:3.9
RUN apk add --update --no-cache libc6-compat gettext
COPY nomad /usr/local/bin/nomad
Ve stejném projektu vytvořte .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}V důsledku toho budeme mít dostupný obrázek Nomad runner v registru Gitlab, nyní můžeme přejít přímo do úložiště projektu, vytvořit Pipeline a nastavit Nomad's nomad job.
Nastavení projektu
Začněme souborem zakázky pro Nomada. Můj projekt v tomto článku bude docela primitivní: bude se skládat z jednoho úkolu. Obsah .gitlab-ci bude následující:
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: manualZde se nasazení provádí ručně, ale můžete jej nakonfigurovat tak, aby se změnil obsah adresáře projektu. Pipeline se na druhé straně skládá ze dvou fází: od sestavení obrazu a jeho nasazení až po nomáda. V první fázi vytvoříme image dockeru a pošleme jej do našeho registru a ve druhé fázi spustíme naši práci v 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" {}
}
}
}
}
}Vezměte prosím na vědomí, že mám soukromý registr a pro úspěšné stažení obrázku dockeru se do něj musím přihlásit. Nejlepším řešením v tomto případě je uzavřít přihlašovací jméno a heslo ve Vaultu a poté jej integrovat s Nomad. Nomad nativně podporuje Vault. Nejprve ale v samotném Vaultu nastavíme potřebné zásady pro Nomad, lze je stáhnout:
# 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.jsonNyní, když jsme vytvořili potřebné zásady, přidáme integraci s Vaultem do bloku úloh v souboru job.nomad:
vault {
enabled = true
address = "https://vault.domain.name:8200"
token = "token"
}Používám autorizaci tokenu a píšu to přímo sem, je zde také možnost zadat token jako proměnnou při spuštění nomádského agenta:
$ VAULT_TOKEN=<token> nomad agent -config /path/to/config
Nyní můžeme používat klíče s trezorem. Princip fungování je jednoduchý: v úloze Nomad vytvoříme soubor, který bude ukládat hodnoty proměnných, například:
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 tímto jednoduchým přístupem můžete nastavit doručování kontejnerů do clusteru Nomad a pracovat s ním v budoucnu. Řeknu, že do jisté míry sympatizuji s Nomadem - je vhodnější pro malé projekty, kde Kubernetes může způsobit další potíže a nevyužije svůj plný potenciál. Nomad je navíc skvělý pro začátečníky – snadno se instaluje a konfiguruje. Při testování na některých projektech však narážím na problém jeho raných verzí – řada základních funkcí prostě neexistuje nebo nefungují správně. Věřím však, že se Nomad bude dále rozvíjet a v budoucnu získá funkce, které každý potřebuje.
Autor: Ilya Andreev, editoval Alexey Zhadan a tým Live Linux
Zdroj: www.habr.com