Nastavení clustera Nomad pomocí Consul a integrace s GitLab

Úvod

V poslední době rychle roste popularita Kubernetes – stále více projektů jej implementuje. Chtěl bych se však zaměřit na orchestrátor, jako je Nomad: je ideální pro projekty, kde již používáte jiné nástroje od společnosti HashiCorp, například Vault a Consul, a projekty nejsou z hlediska infrastruktury složité. V tomto materiálu najdete pokyny k instalaci Nomadu, spojení dvou uzlů do clusteru a integraci Nomadu s Gitlabem.

Nastavení clustera Nomad pomocí Consul a integrace s GitLab

Testovací stanice

Trochu o testovacím prostředí: používáme tři virtuální servery s parametry 2 CPU, 4 RAM, 50 Gb SSD, spojené do jedné místní sítě. Jejich názvy a IP adresy:

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

Instalace Nomadu a Consulu. Vytvoření clusteru Nomad

Přejdeme k základní instalaci. Přestože je instalace jednoduchá, popíšu ji pro úplnost článku: vlastně byla vytvořena z konceptů a poznámek pro rychlý přístup v případě potřeby.

Než přejdeme k praktické části, probereme teoretickou část, protože v tomto kroku je důležité pochopit budoucí strukturu.

Existují dva uzly Nomadu a chceme je spojit do clusteru, také nám v budoucnu bude potřeba automatické škálování clusteru – k tomu nám bude potřeba Consul. S pomocí tohoto nástroje je clusterizace a přidávání nových uzlů velmi jednoduchým úkolem: vytvořený uzel Nomad se připojí k agentovi Consul, po čemž se připojí k existujícímu clusteru Nomad. Proto na začátku nainstalujeme server Consul, nastavíme základní http autorizaci pro webové rozhraní (to je ve výchozím nastavení bez autorizace a může být přístupné přes veřejnou adresu), a také samotné agenty Consul na serverech Nomad, po čemž teprve začneme s Nomadem.

Instalace nástrojů společnosti HashiCorp je velmi jednoduchá: vlastně jen přesuneme binární soubor do složky bin, nastavíme konfigurační soubor nástroje a vytvoříme jeho servisní soubor.

Stáhněte 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 připravený binární soubor consul pro další nastavení.

Pro práci s Consulem potřebujeme vytvořit jedinečný klíč pomocí příkazu keygen:

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

Přejdeme ke konfiguraci Consul, vytvoříme adresář /etc/consul.d/ s následující strukturou:

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

V adresáři bootstrap bude umístěn konfigurační soubor config.json — v něm nastavíme parametry 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"]
}

Podrobně si rozebereme hlavní direktivy a jejich hodnoty:

  • bootstrap: true. Aktivujeme automatické přidávání nových uzlů při jejich připojení. Upozorňuji, že zde neudáváme přesný počet očekávaných uzlů.
  • server: true. Aktivujeme režim serveru. Consul na tomto virtuálním stroji bude v tuto chvíli jediným serverem a mistrem, zatímco VM Nomad’a budou klienti.
  • datacenter: dc1. Zadáváme název datacentra pro vytvoření clusteru. Musí být identický jak na klientech, tak na serverech.
  • šifrovat: your-key. Klíč, který také musí být jedinečný a shodovat se na všech klientech a serverech. Generuje se pomocí příkazu consul keygen.
  • start_join. V tomto seznamu uvádíme IP adresy, ke kterým bude probíháno připojení. V tuto chvíli ponecháme pouze vlastní adresu.

V této fázi můžeme spustit consul pomocí příkazové řádky:

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

To je dobrý způsob ladění nyní, avšak trvale tento způsob použít nelze z očividných důvodů. Vytvoříme servisní soubor pro správu Consul prostřednictvím systemd:

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

Obsah souboru consul.service:

[Unit]
Description=Spouštěcí proces Consul
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

Spouštíme Consul pomocí systemctl:

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

Ověřujeme: náš servis by měl být spuštěn a po vykonání příkazu consul members 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

Další krok: instalace Nginx a nastavení proxy, http autorizace. Nginx nainstalujeme pomocí balíčkového správce a v adresáři /etc/nginx/sites-enabled vytvoříme 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 "Oblast chráněná heslem";
    }
}

Nezapomeňte vytvořit soubor .htpasswd a vygenerovat pro něj uživatelské jméno a heslo. Tento krok je nezbytný, aby webová painel nebyla dostupná každému, kdo zná naši doménu. Při konfiguraci Gitlaba se však tomuto kroku musíme vyhnout — jinak nebudeme moci nasadit naši aplikaci na Nomad. V mém projektu jsou Gitlab i Nomad umístěny pouze v šedé síti, takže tento problém zde není.

Na zbývajících dvou serverech nainstalujeme agenty Consul podle následující instrukce. Opakujeme akce 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/

Podobně jako na předchozím serveru vytvoříme adresář pro konfigurační soubory /etc/consul.d s následující strukturou:

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

Obsah 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", # lokální adresa vm
    "start_join": ["172.30.0.15"], # vzdálená adresa consulu serveru
    "ports": {
      "dns": 53
     }

Uložíme změny a přecházíme k nastavení služebního souboru, jehož obsah je:

/etc/systemd/system/consul.service:

[Unit]
Description="HashiCorp Consul - Řešení pro síťovou vrstvu služeb"
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

Spouštíme Consul na serveru. Nyní, po spuštění, bychom měli v nsul members vidět nastavenou službu. To znamená, že se úspěšně připojila k clustru jako klient. Opakujte to samé na druhém serveru a poté se můžeme pustit do instalace a nastavení Nomadu.

Podrobnější instalace Nomadu je popsána v oficiální dokumentaci. Existují dva tradiční způsoby instalace: stažení binárního souboru a kompilace ze zdrojových kódů. Já zvolím první způsob.

Poznámka: projekt se rychle vyvíjí, často vycházejí nová aktualizace. Možná do doby dokončení článku vyjde nová verze. Proto doporučuji před čtením zkontrolovat aktuální verzi Nomadu a stáhnout právě tu.

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 rozbalení získáme binární soubor Nomad vážící 65 MB — ten je nutné přesunout do /usr/local/bin.

Vytvoříme adresář data pro Nomad a upravíme jeho soubor služby (ten pravděpodobně na začátku nebude existovat):

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

Vložíme 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.target

Ale nespěcháme s spuštěním nomad — 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

Konečná struktura adresáře bude následující:

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

Soubor nomad.hcl by měl 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 — je potřeba změnit hodnotu direktivy http.

Posledním krokem v této fázi je nastavení Nginxu pro proxy a nastavení 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 "Ochráněná oblast";
        }
        
}

Nyní máme přístup k webovému panelu přes veřejnou síť. Připojujeme se a přecházíme na stránku servery:

Nastavení clustera Nomad pomocí Consul a integrace s GitLab
Obrázek 1. Seznam serverů v clusteru Nomad

Oba servery se úspěšně zobrazují v panelu, totéž uvidíme ve výstupu příkazu nomad node status:

Nastavení clustera Nomad pomocí Consul a integrace s GitLab
Obrázek 2. Výstup příkazu nomad node status

Jak je na tom Consul? Podívejme se. Přecházíme do panelu řízení Consul, na stránku uzly:
Nastavení clustera Nomad pomocí Consul a integrace s GitLab
Obrázek 3. Seznam uzlů v clusteru Consul

Nyní máme připravený Nomad, který funguje ve spojení s Consul. V závěrečné fázi se dostaneme k tomu nejzajímavějšímu: nastavíme dodávku Docker kontejnerů z Gitlabu do Nomadu a také si promluvíme o některých jeho dalších vyznačujících se vlastnostech.

Vytváření Gitlab Runneru

Pro nasazení docker obrazů do Nomadu použijeme samostatného runnery s binárním souborem Nomadu uvnitř (mimochodem, zde je možné zmínit další vlastnost aplikací Hashicorp — jednotlivě představují pouze jediný binární soubor). Nahrajte ho do adresáře runneru. Pro něj vytvoříme nejjednodušší 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

V tomto projektu vytváříme .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ý obraz runneru Nomadu v Gitlab Registry, nyní se můžeme přenést přímo do repozitáře projektu, vytvořit Pipeline a nastavit úlohu Nomadu.

Nastavení projektu

Začneme s job soubory pro Nomad. Můj projekt v tomto článku bude dost primitivní: bude se skládat z jedné úlohy. 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}'  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

Zde probíhá nasazení v manuálním režimu, ale můžete jej nastavit na změnu obsahu adresáře projektu. Pipeline se skládá ze dvou fází: z vybudování obrazu a jeho nasazení do Nomadu. V první fázi vytváříme docker obraz a posíláme ho do našeho Registru, ve druhé však spouštíme naši úlohu 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" {}
                }
            }
        }
    }
}

Vezměte prosím na vědomí, že mám uzavřený Registry a pro úspěšné stažení dockerového obrazu se potřebuji do něj autorizovat. Nejlepším řešením v tomto případě je uchovat přihlašovací údaje v Vault a následně je integrovat s Nomad. Nomad nativně podporuje Vault. Nejdříve však v samotném Vault nastavíme potřebné zásady pro Nomad, které lze nahrát:

# 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

Nyní, když jsme vytvořili potřebné zásady, přidáme v bloku task v souboru job.nomad integraci s Vault:

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

Používám autorizaci pomocí tokenu a zapisuji ho přímo sem, také je možnost zadat token jako proměnnou při spuštění nomad agent:

$ VAULT_TOKEN= nomad agent -config /path/to/config

Nyní můžeme používat klíče z Vault. Princip fungování je jednoduchý: v Nomad job vytvoříme soubor, který bude uchovávat 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
}

Tímto jednoduchým přístupem lze nastavit dodávání kontejnerů do clustru Nomad a nadále s ním pracovat. Osobně mohu říci, že do určité míry mám rád Nomad – je více vhodný pro malé projekty, kde Kubernetes může způsobit další komplikace a nevyužije svůj potenciál naplno. Navíc, Nomad je skvělý pro začátečníky – snadno se instaluje a konfiguruje. Nicméně, při testování některých projektů se setkávám s problémy jeho raných verzí – mnohé základní funkce prostě chybí nebo nefungují správně. Přesto si myslím, že Nomad se bude i nadále vyvíjet a v budoucnu se obohatí o potřebné funkce pro všechny.

Autor: Ilya Andrejev, pod vedením Alexeje Žadana a týmu «Live Linux»


Zdroj: habr.com

Koupit spolehlivý hosting pro webové stránky s ochranou proti DDoS, VPS VDS servery 🔥 Koupit spolehlivý hosting pro webové stránky s ochranou proti DDoS, VPS VDS servery | ProHoster