🥇Opsætning af Nomad-kluster med Consul og integration med GitLab

Introduktion

I den seneste tid er populariteten af Kubernetes steget hastigt - flere og flere projekter implementerer det. Jeg vil dog berøre en orkestrator som Nomad: den er ideel til projekter, hvor der allerede anvendes andre løsninger fra HashiCorp, såsom Vault og Consul, og hvor projekterne ikke er komplekse med hensyn til infrastruktur. I dette materiale vil der være en vejledning til installation af Nomad, oprettelse af to noder i et cluster samt integration af Nomad med GitLab.

Testbænk

Lidt om testmiljøet: der anvendes tre virtuelle servere med specifikationerne 2 CPU, 4 RAM, 50 Gb SSD, der er forbundet i et samlet lokalt netværk. Deres navne og IP-adresser:

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

Installation af Nomad, Consul. Oprettelse af Nomad-cluster

Lad os påbegynde den grundlæggende installation. På trods af installationens enkelhed vil jeg beskrive den for at sikre artikelens sammenhæng: i grunden blev den oprettet ud fra udkast og noter for hurtig adgang i tilfælde af behov.

Før vi går i gang med det praktiske, lad os diskutere den teoretiske del, da det på dette stadium er vigtigt at forstå den fremtidige struktur.

Vi har to Nomad-noder, og vi ønsker at sammenkæde dem i et cluster; derudover vil vi senere have brug for automatisk skalering af clusteren - til dette vil vi have brug for Consul. Med dette værktøj bliver clustering og tilføjelse af nye noder en meget enkel opgave: den oprettede Nomad-node forbinder til Consul-agenten, hvorefter den forbinder til det eksisterende Nomad-cluster. Derfor vil vi først installere Consul-serveren, konfigurere grundlæggende HTTP-godkendelse til webpanelet (det er som standard uden godkendelse og kan tilgås via en ekstern adresse), samt de nødvendige Consul-agenter på Nomad-serverne, hvorefter vi kun går i gang med Nomad.

Installation af HashiCorp-værktøjer er meget enkel: i princippet flytter vi blot binærfilen til bin-mappen, konfigurerer konfigurationsfilen for værktøjet og opretter dens servicefil.

Vi downloader binærfilen Consul og udpakker den i brugerens hjemmebibliotek:

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 den binære fil consul klar til videre opsætning.

For at arbejde med Consul skal vi oprette en unik nøgle ved hjælp af kommandoen keygen:

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

Lad os gå videre til konfigurationen af Consul, og oprettere mappen /etc/consul.d/ med følgende struktur:

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

I mappen bootstrap vil der være en konfigurationsfil config.json — her angiver vi indstillingerne for Consul. Dens indhold:

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

Lad os se nærmere på de vigtigste direktiver og deres betydning:

bootstrap: true. Vi aktiverer automatisk tilføjelse af nye noder, når de tilsluttes. Jeg vil bemærke, at vi ikke angiver det nøjagtige antal forventede noder her.
server: true. Aktiverer servermodus. Consul på denne virtuelle maskine vil i øjeblikket være den eneste server og master, mens Nomad VMs vil fungere som klienter.
datacenter: dc1. Her angiver vi navnet på datacenteret for at oprette klyngen. Det skal være identisk på både klienter og servere.
krypter: your-key. Nøgle, som også skal være unik og være identisk på alle klienter og servere. Den genereres med kommandoen consul keygen.
start_join. I denne liste angiver vi listen med IP-adresser, som der vil blive oprettet forbindelse til. Indtil videre efterlader vi kun vores egen adresse.

På dette tidspunkt kan vi starte Consul via kommandolinjen:

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

Dette er en god metode til fejlfinding lige nu, men denne metode kan ikke bruges permanent af åbenlyse grunde. Lad os oprette en servicefil til at styre Consul via systemd:

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

Indholdet 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 starter Consul via systemctl:

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

Vi kontrollerer: vores service bør være startet, og når vi udfører kommandoen consul members, skal vi se vores server:

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

Næste trin: installation af Nginx og opsætning af proxy, http-godkendelse. Vi installerer nginx via pakkestyring og i mappen /etc/nginx/sites-enabled opretter vi konfigurationsfilen consul.conf med følgende indhold:

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

Husk at oprette .htpasswd-filen og generere et brugernavn og adgangskode til den. Dette punkt er nødvendigt for at sikre, at webpanelet ikke er tilgængeligt for alle, der kender vores domæne. Men ved opsætning af Gitlab må vi give afkald på dette — ellers kan vi ikke implementere vores applikation i Nomad. I mit projekt er både Gitlab og Nomad kun tilgængelige i et lukket netværk, så der er ikke noget problem her.

På de to øvrige servere installerer vi Consul-agenter efter følgende instruktion. Gentag handlingerne 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/

På samme måde som den forrige server opretter vi en mappe til konfigurationsfilerne /etc/consul.d med følgende struktur:

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

Indholdet af 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 adresse for VM
    "start_join": ["172.30.0.15"], # fjern adresse for Consul-server
    "ports": {
      "dns": 53
     }

Gem ændringerne og gå videre til konfigurationen af servicefilen, dens indhold:

/etc/systemd/system/consul.service:

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

Start consul på serveren. Nu skal vi, efter opstart, kunne se den konfigurerede service i nsul members. Det betyder, at den er tilsluttet til klyngen som klient. Udfør det samme på den anden server, og efter dette kan vi gå videre med installation og konfiguration af Nomad.

En mere grundig installation af Nomad er beskrevet i den officielle dokumentation. Der er to traditionelle måder at installere på: download af binærfilen og kompilering fra kildekoden. Jeg vælger den første metode.

Bemærk: projektet udvikler sig meget hurtigt, og der udgives ofte nye opdateringer. Det er muligt, at der vil være en ny version, når artiklen er færdig. Derfor anbefaler jeg at tjekke den aktuelle version af Nomad, før du læser, og downloade netop 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 udpakkingen får vi en Nomad-binærfil på 65 MB — den skal flyttes til /usr/local/bin.

Vi opretter en data-mappe til Nomad og redigerer dens servicefil (den findes sandsynligvis ikke i starten):

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

Indsæt følgende linjer:

[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 lad os ikke skynde os med at starte nomad — vi har endnu ikke oprettet dens 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 endelige mappestruktur vil være som følger:

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

Filen nomad.hcl skal indeholde følgende konfiguration:

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

Indholdet af 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
}

Husk at ændre konfigurationsfilen på den anden server — der skal ændres værdien af http-direktivet.

Til sidst er der tilbage at konfigurere Nginx til at proxy og sætte http-godkendelse op. Indholdet af 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å adgang til webpanelet over det offentlige netværk. Vi logger ind og går til siden servers:

Billede 1. Liste over servere i Nomad-klyngen

Begge servere vises korrekt i panelet, og det samme vil vi se i output af kommandoen nomad node status:

Billede 2. Output af kommandoen nomad node status

Hvad med Consul-siden? Lad os tage et kig. Vi går ind i Consul-administrationspanelet, på siden nodes:

Billede 3. Liste over noder i Consul-klyngen

Nu har vi en forberedt Nomad, der kører sammen med Consul. I den afsluttende fase går vi til det mest interessante: vi konfigurerer levering af Docker-containere fra Gitlab til Nomad, og vi vil også tale om nogle af hans andre karakteristiske funktioner.

Oprettelse af Gitlab Runner

For at deploye Docker-billeder til Nomad vil vi bruge en separat runner med Nomad-binary filen indeni (for øvrigt kan man bemærke endnu en særhed ved Hashicorp-applikationer — hver for sig udgør de en enkelt binary fil). Upload det til runnerens mappe. Vi laver en simpleste Dockerfile med følgende indhold:


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

I dette projekt opretter 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 et tilgængeligt billede af Nomad-runneren i Gitlab Registry, nu kan vi gå videre til projektets repository, oprette en pipeline og konfigurere Nomad-jobben.

Konfiguration af projektet

Lad os starte med job-filen til Nomad. Mit projekt i denne artikel vil være temmelig primitivt: det vil bestå af en enkelt opgave. Indholdet af .gitlab-ci vil være som følger:

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

Her sker deployment manuelt, men du kan indstille det til at ændre indholdet af projektmappen. Pipeline består af to faser: bygning af billedet og dets deployment til Nomad. I den første fase bygger vi Docker-billedet og pusher det til vores Registry, mens vi i den anden fase kører vores job i 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" {}
                }
            }
        }
    }
}

Vær opmærksom på, at jeg har et lukket Registry, og for at kunne hente docker-billedet skal jeg logge ind. Den bedste løsning i dette tilfælde er at gemme login og adgangskode i Vault med efterfølgende integration med Nomad. Nomad understøtter Vault nativt. Men først i Vault skal vi installere de nødvendige policies for Nomad, som kan indlades:

# 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 vi har oprettet de nødvendige policies, skal vi tilføje integrationen med Vault i task-blokken i job.nomad-filen:

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

Jeg bruger token-autentifikation og angiver det direkte her, men der er også mulighed for at angive token som en variabel ved opstart af nomad agent:

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

Nu kan vi bruge nøglerne fra Vault. Princippet er enkelt: vi opretter en fil i Nomad-jobbet, der vil indeholde værdierne for variablerne, for eksempel:

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ådan en simpel tilgang kan bruges til at konfigurere levering af containere til Nomad-klyngen og arbejde videre med den. Jeg må sige, at jeg på en måde er tilhænger af Nomad - den passer bedre til små projekter, hvor Kubernetes kan skabe yderligere komplikationer og ikke udnytter sit potentiale fuldt ud. Desuden er Nomad perfekt til begyndere - den er nem at installere og konfigurere. Dog har jeg under testning af nogle projekter oplevet problemer med visse tidligere versioner - mange grundlæggende funktioner mangler eller fungerer ikke korrekt. Ikke desto mindre mener jeg, at Nomad vil udvikle sig og i fremtiden få de nødvendige funktioner, som alle vil have.

Forfatter: Ilya Andreev, redigeret af Alexey Zhadan og teamet fra «Live Linux»

Kilde: habr.com