🥇Konfigurering av Nomad-kluster med hjälp av Consul och integration med Gitlab

Introduktion

På senare tid har populariteten för Kubernetes snabbt ökat - allt fler projekt implementerar det. Jag vill dock beröra en orkestrator såsom Nomad: den passar utmärkt för projekt där andra lösningar från HashiCorp, såsom Vault och Consul, redan används, och själva projekten inte är komplexa ur infrastruktursynpunkt. Denna text kommer att innehålla en installationsguide för Nomad, sammanfogning av två noder i ett kluster, samt integration av Nomad med Gitlab.

Testbänk

Lite om testmiljön: tre virtuella servrar används med specifikationerna 2 CPU, 4 RAM, 50 Gb SSD, kopplade i ett gemensamt lokalt nätverk. Deras namn och IP-adresser är:

nomad-livelinux-01: 172.30.0.5
nomad-livelinux-02: 172.30.0.10
consul-livelinux-01: 172.30.0.15

Installation av Nomad, Consul. Skapa ett Nomad-kluster

Vi börjar med en grundläggande installation. Trots att installationen är enkel, kommer jag att beskriva den för artikelns helhet: den skapades i grunden från utkast och anteckningar för snabb åtkomst vid behov.

Innan vi påbörjar praktiken ska vi diskutera den teoretiska delen, eftersom det på detta stadium är viktigt att förstå den framtida strukturen.

Vi har två Nomad-noder och vi vill sammanfoga dem i ett kluster, och framöver kommer vi att behöva automatisk skalning av klustret - för detta kommer vi att behöva Consul. Med detta verktyg blir klustring och tillägg av nya noder en mycket enkel uppgift: den skapade Nomad-noden ansluter till Consul-agenten och ansluter sedan till det befintliga Nomad-klustret. Därför kommer vi först att installera Consul-servern, konfigurera grundläggande http-autentisering för webbpanelen (den är som standard utan autentisering och kan nås via en extern adress), samt Consul-agenterna på Nomad-servrarna, innan vi går vidare till Nomad.

Installationen av HashiCorp-verktygen är mycket enkel: i princip flyttar vi bara binärfilen till bin-katalogen, konfigurerar verktygets konfigurationsfil och skapar dess tjänstefil.

Vi laddar ner binärfilen för Consul och packar upp den i användarens hemkatalog:

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/

Nu har vi en färdig binärfil för consul för vidare konfiguration.

För att arbeta med Consul måste vi skapa en unik nyckel med kommandot keygen:

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

Vi går vidare med att konfigurera Consul. Vi skapar katalogen /etc/consul.d/ med följande struktur:

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

I katalogen bootstrap kommer konfigurationsfilen config.json att finnas — här anger vi inställningarna för Consul. Innehållet är:

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

Låt oss gå igenom huvuddirektiven och deras betydelse:

bootstrap: true. Vi aktiverar automatisk registrering av nya noder vid anslutning. Jag påpekar att vi inte anger det exakta antalet förväntade noder här.
server: true. Vi aktiverar serverläge. Consul på denna virtuella maskin kommer för tillfället att vara den enda servern och mästaren, medan VM Nomad kommer att vara klienter.
datacenter: dc1. Vi anger namnet på datacentret för att skapa klustret. Det måste vara identiskt på både klienter och servrar.
encrypt: your-key. Nyckeln som också måste vara unik och matcha på alla klienter och servrar. Den genereras med kommandot consul keygen.
start_join. I denna lista anger vi IP-adresserna som vi ska ansluta till. För tillfället lämnar vi bara vår egen adress.

Vid detta skede kan vi starta consul via kommandoraden:

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

Detta är en bra metod för felsökning just nu, men det är uppenbart att denna metod inte kan användas regelbundet. Vi skapar en servicefil för att hantera Consul via systemd:

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

Innehållet i filen 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

Vi startar Consul via systemctl:

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

Kontrollera: tjänsten bör vara igång och när vi utför kommandot consul members bör vi se vår server:

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

Nästa steg: installera Nginx och konfigurera proxying, http-autentisering. Vi installerar nginx genom paketförvaltaren och i katalogen /etc/nginx/sites-enabled skapar vi konfigurationsfilen consul.conf med följande innehåll:

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-skyddat område";
    }
}

Kom ihåg att skapa en .htpasswd-fil och generera ett användarnamn och lösenord för det. Detta steg krävs så att webbpanelen inte är tillgänglig för alla som känner till vår domän. Men när vi konfigurerar Gitlab måste vi avstå från detta - annars kan vi inte distribuera vår applikation till Nomad. I mitt projekt finns både Gitlab och Nomad endast i det interna nätverket, så det finns inget sådant problem här.

På de andra två servrarna installerar vi Consul-agenter enligt följande instruktioner. Vi upprepar stegen med binärfilen:

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/

I likhet med den tidigare servern skapar vi en katalog för konfigurationsfiler /etc/consul.d med följande struktur:

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

Innehållet i filen 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", # lokal VM-adress
    "start_join": ["172.30.0.15"], # extern adress till Consul-servern
    "ports": {
      "dns": 53
     }

Spara ändringarna och gå vidare till konfigurationen av service-filen, dess innehåll:

/etc/systemd/system/consul.service:

[Unit]
Description="HashiCorp Consul - En lösning för service mesh"
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

Starta Consul på servern. Nu, efter starten, bör vi se den konfigurerade tjänsten i nsul members. Detta kommer att innebära att den framgångsrikt har anslutit sig till klustret som en klient. Upprepa samma sak på den andra servern och efter det kan vi börja installera och konfigurera Nomad.

En mer detaljerad installation av Nomad beskrivs i dess officiella dokumentation. Det finns två traditionella sätt att installera: nedladdning av binärfil och kompilering från källkod. Jag väljer det första sättet.

Anmärkning: projektet utvecklas mycket snabbt, nya uppdateringar släpps ofta. Det kan hända att en ny version kommer att släppas innan artikeln är färdig. Därför rekommenderar jag att kontrollera den aktuella versionen av Nomad just nu och ladda ner just den.

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

Efter uppackningen får vi en binärfil av Nomad som väger 65 MB – den måste flyttas till /usr/local/bin.

Vi skapar en data-katalog för Nomad och redigerar dess servicefil (den kommer förmodligen inte att finnas från början):

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

Klistra in följande rader:

[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

Men vi skyndar oss inte att starta nomad – vi har ännu inte skapat dess konfigurationsfil:

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

Den slutgiltiga katalogstrukturen kommer att se ut som följande:

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

Filen nomad.hcl bör innehålla följande konfiguration:

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

Innehållet i filen 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
}

Kom ihåg att ändra konfigurationsfilen på den andra servern – där behövs värdet för direktivet http ändras.

Det sista steget i detta skede är att konfigurera Nginx för proxying och ställa in http-autentisering. Innehållet i filen 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";
        }
        
}

Nu kan vi få tillgång till webbpanelen över det externa nätverket. Vi ansluter och går till sidan servers:

Bild 1. Lista över servrar i Nomad-klustret

Båda servrarna visas framgångsrikt i panelen, detsamma ser vi i utskriften av kommandot nomad node status:

Bild 2. Utskrift av kommandot nomad node status

Vad säger Consul? Låt oss ta en titt. Vi går till Consuls kontrollpanel, på sidan nodes:

Bild 3. Lista över noder i Consul-klustret

Nu har vi en förberedd Nomad som arbetar i tandem med Consul. I det avslutande steget kommer vi att gå vidare till det mest intressanta: vi kommer att konfigurera leveransen av Docker-containrar från Gitlab till Nomad, samt diskutera några av dess andra utmärkande egenskaper.

Skapa Gitlab Runner

För att deploya Docker-bilder i Nomad kommer vi att använda en separat runner med Nomads binärfil inuti (detta är också en annan särskild egenskap hos Hashicorp-appar — de representerar var för sig en enda binärfil). Ladda ner den till runner-katalogen. För den skapar vi en enkel Dockerfile med följande innehåll:


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

I detta projekt skapar vi .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}

Som resultat får vi en tillgänglig bild av Nomad-runner i Gitlab Registry, nu kan vi gå direkt till projektets repository, skapa en Pipeline och konfigurera Nomads job.

Konfigurera projektet

Vi börjar med jobbfilen för Nomad. Mitt projekt i denna artikel kommer att vara ganska enkelt: det kommer att bestå av en enda uppgift. Innehållet i .gitlab-ci kommer att vara som följer:

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

Här sker deployment i manuell läge, men du kan konfigurera det att förändra innehållet i projektkatalogen. Pipelines består av två steg: bygga bilden och deploya den i Nomad. Under det första steget samlar vi Docker-bilden och pushar den till vår Registry, och under det andra kör vi vår jobb i Nomad.

jobb "monitoring-status" {
    datacenter = ["dc1"]
    migrera {
        max_parallel = 3
        health_check = "checks"
        min_healthy_time = "15s"
        healthy_deadline = "5m"
    }

    grupp "zhadan.ltd" {
        antal = 1
        uppdatera {
            max_parallel      = 1
            min_healthy_time  = "30s"
            healthy_deadline  = "5m"
            progress_deadline = "10m"
            auto_revert       = true
        }
        uppgift "service-monitoring" {
            driver = "docker"

            konfiguration {
                bild = "registry.domain.name/example/project:${CI_COMMIT_SHORT_SHA}"
                force_pull = true
                autentisering {
                    användarnamn = "gitlab_user"
                    lösenord = "gitlab_password"
                }
                port_mappning {
                    http = 8000
                }
            }
            resurser {
                nätverk {
                    port "http" {}
                }
            }
        }
    }
}

Observera att jag har ett privat Registry och för att framgångsrikt dra ned Docker-bilden behöver jag autentisera mig. Den bästa lösningen i detta fall är att placera användarnamn och lösenord i Vault och sedan integrera det med Nomad. Nomad stöder Vault natively. Men först i Vault måste vi ställa in de nödvändiga policyerna för Nomad, de kan laddas:

# 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

Nu, efter att ha skapat de nödvändiga policyerna, kommer vi att lägga till integration med Vault i task-blocket i job.nomad-filen:

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

Jag använder token-autentisering och anger den direkt här, det finns också ett alternativ att ange token som en variabel vid start av nomad-agenten:

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

Nu kan vi använda nycklar med Vault. Arbetsprincipen är enkel: vi skapar en fil i Nomad-jobbet som kommer att lagra värdena för variabler, till exempel:

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
}

På detta enkla sätt kan vi ställa in leveransen av containrar till Nomad-klustret och arbeta med det i framtiden. Jag måste säga att jag på vissa sätt gillar Nomad — det passar bättre för mindre projekt där Kubernetes kan orsaka ytterligare kompliceringar och inte kommer att realisera sin potential fullt ut. Dessutom passar Nomad utmärkt för nybörjare — det är lätt att installera och konfigurera. Men under tester på vissa projekt har jag stött på problem med tidiga versioner — många grundläggande funktioner finns helt enkelt inte eller fungerar inte korrekt. Ändå anser jag att Nomad kommer att utvecklas vidare och i framtiden få de funktioner som alla behöver.

Författare: Ilja Andrejev, redigerad av Alexej Zhadan och teamet bakom "Live Linux"

Källa: habr.com