🥇Opsætning af en Nomad-klynge ved hjælp af Consul og integration med Gitlab

Indledning

For nylig er populariteten af Kubernetes vokset hurtigt - flere og flere projekter implementerer det. Jeg ville gerne røre ved en orkestrator som Nomad: den er perfekt til projekter, der allerede bruger andre løsninger fra HashiCorp, for eksempel Vault og Consul, og selve projekterne er ikke komplekse i forhold til infrastrukturen. Dette materiale vil indeholde instruktioner til installation af Nomad, kombination af to noder i en klynge, samt integration af Nomad med Gitlab.

Prøvestativ

Lidt om testbænken: Tre virtuelle servere bruges med egenskaberne 2 CPU, 4 RAM, 50 Gb SSD, samlet til et fælles 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, Konsul. Oprettelse af en Nomad-klynge

Lad os starte med den grundlæggende installation. Selvom opsætningen var enkel, vil jeg beskrive den af hensyn til artiklens integritet: den blev i det væsentlige skabt ud fra kladder og noter for hurtig adgang, når det var nødvendigt.

Inden vi begynder praksis, vil vi diskutere den teoretiske del, fordi det på dette stadium er vigtigt at forstå den fremtidige struktur.

Vi har to nomadeknuder, og dem vil vi kombinere til en klynge, og i fremtiden får vi også brug for automatisk klyngeskalering - til dette skal vi bruge Consul. Med dette værktøj bliver klyngedannelse og tilføjelse af nye noder en meget simpel opgave: Den oprettede Nomad-knude forbinder til Consul-agenten og forbinder derefter til den eksisterende Nomad-klynge. Derfor vil vi i starten installere Consul-serveren, konfigurere grundlæggende http-autorisation til webpanelet (det er uden autorisation som standard og kan tilgås på en ekstern adresse), samt Consul-agenterne selv på Nomad-servere, hvorefter vi går kun videre til Nomad.

Installation af HashiCorps værktøjer er meget enkel: i det væsentlige flytter vi bare den binære fil til bin-biblioteket, opsætter værktøjets konfigurationsfil og opretter dens servicefil.

Download den binære Consul-fil og pak den ud i brugerens hjemmemappe:

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 klargjort konsul-binær til yderligere konfiguration.

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

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

Lad os gå videre til opsætning af Consul-konfigurationen, ved at oprette en mappe /etc/consul.d/ med følgende struktur:

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

Bootstrap-mappen vil indeholde en konfigurationsfil config.json - i den vil vi indstille Consul-indstillingerne. 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 på hoveddirektiverne og deres betydning separat:

bootstrap: rigtigt. Vi aktiverer automatisk tilføjelse af nye noder, hvis de er tilsluttet. Jeg bemærker, at vi ikke her angiver det nøjagtige antal forventede noder.
server: rigtigt. Aktiver servertilstand. Consul på denne virtuelle maskine vil fungere som den eneste server og master i øjeblikket, Nomads VM vil være klienterne.
datacenter: dc1. Angiv navnet på datacenteret for at oprette klyngen. Det skal være identisk på både klienter og servere.
kryptere: din-nøgle. Nøglen, som også skal være unik og matche på alle klienter og servere. Genereret ved hjælp af kommandoen consul keygen.
start_join. I denne liste angiver vi en liste over IP-adresser, som forbindelsen vil blive oprettet til. I øjeblikket efterlader vi kun vores egen adresse.

På dette tidspunkt kan vi køre consul ved hjælp af kommandolinjen:

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

Dette er en god måde at fejlsøge nu, men du vil ikke være i stand til at bruge denne metode løbende af indlysende årsager. Lad os oprette en servicefil til at administrere Consul via systemd:

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

Indhold af 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

Start Consul via systemctl:

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

Lad os tjekke: vores tjeneste skal køre, og ved at udføre kommandoen for konsulmedlemmer bør 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  <all>

Næste trin: installation af Nginx og opsætning af proxy og http-autorisation. Vi installerer nginx gennem pakkehåndteringen og i mappen /etc/nginx/sites-enabled opretter vi en konfigurationsfil 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-protected Area";
    }
}

Glem ikke at oprette en .htpasswd-fil og generere et brugernavn og en adgangskode til den. Denne vare er påkrævet, så webpanelet ikke er tilgængeligt for alle, der kender vores domæne. Men når vi opsætter Gitlab, bliver vi nødt til at opgive dette - ellers vil vi ikke være i stand til at implementere vores applikation til Nomad. I mit projekt er både Gitlab og Nomad kun på det grå web, så der er ikke et sådant problem her.

På de resterende to servere installerer vi Consul-agenter i henhold til følgende instruktioner. Vi gentager trinene med den binære fil:

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/

Analogt med den tidligere server opretter vi en mappe til konfigurationsfiler /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", # локальный адрес вм
    "start_join": ["172.30.0.15"], # удаленный адрес консул сервера
    "ports": {
      "dns": 53
     }

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

/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.target

Vi starter konsul på serveren. Nu, efter lanceringen, skulle vi se den konfigurerede tjeneste i nsul-medlemmer. Dette vil betyde, at den har oprettet forbindelse til klyngen som klient. Gentag det samme på den anden server, og derefter kan vi begynde at installere og konfigurere Nomad.

Mere detaljeret installation af Nomad er beskrevet i dens officielle dokumentation. Der er to traditionelle installationsmetoder: download af en binær fil og kompilering fra kilde. Jeg vælger den første metode.

Bemærk: Projektet udvikler sig meget hurtigt, nye opdateringer udgives ofte. Måske vil en ny version blive frigivet, når denne artikel er færdig. Derfor anbefaler jeg, før du læser, at tjekke den aktuelle version af Nomad i øjeblikket og downloade 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 udpakning modtager vi en Nomad binær fil, der vejer 65 MB - den skal flyttes til /usr/local/bin.

Lad os oprette en datamappe til Nomad og redigere dens servicefil (den vil højst sandsynligt ikke eksistere i begyndelsen):

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

Indsæt følgende linjer der:

[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

Vi har dog ikke travlt 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

Nomad.hcl-filen skal indeholde følgende konfiguration:

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

Indhold af server.hcl-filen:

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
}

Glem ikke at ændre konfigurationsfilen på den anden server - der skal du ændre værdien af http-direktivet.

Den sidste ting på dette trin er at konfigurere Nginx til proxy og opsætning af http-autorisation. Indhold af nomad.conf filen:

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 via et eksternt netværk. Tilslut og gå til serversiden:

Billede 1. Liste over servere i Nomad-klyngen

Begge servere vises med succes i panelet, vi vil se det samme i outputtet af nomad node status kommandoen:

Billede 2. Output af nomadeknudestatuskommandoen

Hvad med konsul? Lad os tage et kig. Gå til Consul-kontrolpanelet, til noder-siden:

Billede 3. Liste over noder i Consul-klyngen

Nu har vi en forberedt Nomad, der arbejder i samarbejde med Consul. I den sidste fase vil vi komme til den sjove del: opsætning af levering af Docker-containere fra Gitlab til Nomad, og også tale om nogle af dets andre karakteristiske træk.

Oprettelse af Gitlab Runner

For at implementere docker-billeder til Nomad, vil vi bruge en separat runner med den binære Nomad-fil indeni (her kan vi i øvrigt bemærke en anden funktion af Hashicorp-applikationer - individuelt er de en enkelt binær fil). Upload det til runner-biblioteket. Lad os oprette en simpel Dockerfile til det med følgende indhold:


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

I det samme 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 et resultat vil vi have et tilgængeligt billede af Nomad-løberen i Gitlab-registret, nu kan vi gå direkte til projektlageret, oprette en Pipeline og konfigurere Nomads nomadejob.

Projektopsætning

Lad os starte med jobbets fil for Nomad. Mit projekt i denne artikel vil være ret primitivt: det vil bestå af én 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}' < 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: manual

Her sker implementeringen manuelt, men du kan konfigurere den til at ændre indholdet af projektmappen. Pipeline består af to faser: billedsamling og dens udrulning til nomad. På det første trin samler vi et docker-billede og skubber det ind i vores Registry, og i det andet lancerer vi 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" {}
                }
            }
        }
    }
}

Bemærk venligst, at jeg har et privat register, og for at kunne trække et docker-billede skal jeg logge ind på det. Den bedste løsning i dette tilfælde er at indtaste et login og adgangskode i Vault og derefter integrere det med Nomad. Nomad understøtter oprindeligt Vault. Men lad os først installere de nødvendige politikker for Nomad i selve Vault; de kan downloades:

# 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 at have oprettet de nødvendige politikker, tilføjer vi integration med Vault i opgaveblokken i job.nomad-filen:

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

Jeg bruger autorisation via token og registrerer det direkte her, der er også mulighed for at angive token som en variabel ved start af nomadeagent:

$ VAULT_TOKEN=<token> nomad agent -config /path/to/config

Nu kan vi bruge nøglerne med Vault. Operationsprincippet er enkelt: vi opretter en fil i Nomad job, der gemmer værdierne af variabler, 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
}

Med denne enkle tilgang kan du konfigurere leveringen af containere til Nomad-klyngen og arbejde med den i fremtiden. Jeg vil sige, at jeg til en vis grad sympatiserer med Nomad - det er mere velegnet til små projekter, hvor Kubernetes kan forårsage yderligere kompleksitet og ikke vil realisere sit fulde potentiale. Plus, Nomad er perfekt til begyndere – det er nemt at installere og konfigurere. Men når jeg tester på nogle projekter, støder jeg på et problem med dens tidlige versioner - mange grundlæggende funktioner er der simpelthen ikke, eller de fungerer ikke korrekt. Jeg tror dog på, at Nomad vil fortsætte med at udvikle sig og i fremtiden får de funktioner, som alle har brug for.

Forfatter: Ilya Andreev, redigeret af Alexey Zhadan og Live Linux-teamet

Kilde: www.habr.com

Opsætning af en Nomad-klynge ved hjælp af Consul og integration med Gitlab

Indledning

Prøvestativ

Installation af Nomad, Konsul. Oprettelse af en Nomad-klynge

Oprettelse af Gitlab Runner

Projektopsætning

Tilføj en kommentar Annuller svar