ProHoster > Blog > administrasie > Die opstel van 'n Nomad-kluster met Consul en integrasie met Gitlab

Die opstel van 'n Nomad-kluster met Consul en integrasie met Gitlab

Inleiding

Onlangs het die gewildheid van Kubernetes vinnig gegroei - meer en meer projekte implementeer dit tuis. Ek wou 'n orkeseerder soos Nomad aanraak: dit is perfek vir projekte waar ander oplossings van HashiCorp, soos Vault en Consul, reeds gebruik word, en die projekte self is nie kompleks in terme van infrastruktuur nie. Hierdie artikel sal instruksies verskaf vir die installering van Nomad, die samevoeging van twee nodusse in 'n groepering, en die integrasie van Nomad met Gitlab.

Die opstel van 'n Nomad-kluster met Consul en integrasie met Gitlab

toetsbank

'n Bietjie oor die toetsbank: drie virtuele bedieners met kenmerke van 2 SVE's, 4 RAM, 50 Gb SSD word gebruik, verenig in 'n gemeenskaplike plaaslike netwerk. Hul name en IP-adresse:

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

Installeer Nomad, Consul. Die skep van 'n Nomade Cluster

Kom ons begin met die basiese installasie. Ten spyte van die gemak van installasie, sal ek dit beskryf ter wille van die integriteit van die artikel: in werklikheid is dit geskep uit konsepte en notas vir vinnige toegang in geval van behoefte.

Voordat ons na die praktyk voortgaan, sal ons die teoretiese deel bespreek, want op hierdie stadium is dit belangrik om die toekomstige struktuur te verstaan.

Ons het twee nomad nodusse en ons wil hulle in 'n cluster kombineer, ook vir die toekoms sal ons outomatiese skaal van die cluster nodig hê - hiervoor het ons Consul nodig. Met hierdie hulpmiddel word groepering en byvoeging van nuwe nodusse 'n baie eenvoudige taak: die geskepde Nomad-nodus koppel aan die Consul-agent, waarna dit aan die bestaande Nomad-kluster koppel. Daarom sal ons aan die begin die Consul-bediener installeer, die basiese http-magtiging vir die webpaneel instel (dit is by verstek sonder magtiging en kan by 'n eksterne adres verkry word), sowel as die Consul-agente self op Nomad-bedieners, na wat ons net sal voortgaan na Nomad.

Die installering van HashiCorp se gereedskap is baie eenvoudig: in wese skuif ons net die binêre lêer na die bin-gids, stel die instrument se konfigurasielêer op en skep sy dienslêer.

Laai die Consul-binêre af en onttrek dit na die gebruiker se tuisgids:

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/

Ons het nou die konsul binêre gereed vir verdere aanpassing.

Om met Consul te werk, moet ons 'n unieke sleutel genereer deur die keygen-opdrag te gebruik:

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

Kom ons gaan voort met die konfigurasie van Consul, skep 'n gids /etc/consul.d/ met die volgende struktuur:

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

Die bootstrap-gids sal die config.json-konfigurasielêer bevat - daarin sal ons die Consul-instellings stel. Die inhoud daarvan:

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

Kom ons ontleed die hoofriglyne en hul betekenisse afsonderlik:

  • bootstrap:waar. Aktiveer outomatiese toevoeging van nuwe nodusse as hulle gekoppel is. Ek neem kennis dat ons nie hier die presiese aantal verwagte nodusse aandui nie.
  • bediener:waar. Skakel bedienermodus aan. Konsul op hierdie virtuele masjien sal op die oomblik as die enigste bediener en meester optree, Nomad se VM sal kliënte wees.
  • datacenter:dc1. Spesifiseer die naam van die datasentrum om die groep te skep. Dit moet identies wees op beide kliënte en bedieners.
  • Enkripteer:jou-sleutel. Die sleutel, wat ook uniek moet wees en ooreenstem met alle kliënte en bedieners. Gegenereer met behulp van die konsul keygen opdrag.
  • begin_aansluit. In hierdie lys spesifiseer ons 'n lys van IP-adresse waaraan die verbinding gemaak sal word. Op die oomblik los ons net ons eie adres.

Op hierdie punt kan ons konsul begin deur die opdragreël te gebruik:

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

Dit is 'n goeie manier om nou te ontfout, maar dit sal om ooglopende redes nie op 'n permanente basis werk nie. Kom ons skep 'n dienslêer om Consul via systemd te bestuur:

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

Consul.service lêer inhoud: 

[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

Begin Consul via systemctl:

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

Ons kyk: ons diens moet loop, en deur die konsullede opdrag uit te voer, behoort ons ons bediener te sien:

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

Die volgende stap: die installering van Nginx en die opstel van proxying, http-magtiging. Installeer nginx deur die pakketbestuurder en in die /etc/nginx/sites-enabled gids skep 'n consul.conf konfigurasielêer met die volgende inhoud:

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";
    }
}

Moenie vergeet om 'n .htpasswd-lêer te skep en 'n gebruikersnaam en wagwoord daarvoor te genereer nie. Hierdie item word vereis sodat die webpaneel nie beskikbaar is vir almal wat ons domein ken nie. Wanneer ons Gitlab opstel, sal ons dit egter moet weier - anders sal ons nie ons toepassing in Nomad kan ontplooi nie. In my projek is beide Gitlab en Nomad slegs op die grys netwerk, so daar is nie so 'n probleem hier nie.

Installeer Consul-agente op die oorblywende twee bedieners volgens die volgende instruksies. Ons herhaal die stappe met die binêre lêer:

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/

In analogie met die vorige bediener, skep ons 'n gids vir konfigurasielêers /etc/consul.d met die volgende struktuur:

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

Inhoud van config.json lêer:

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

Ons stoor die veranderinge en gaan voort met die opstel van die dienslêer, die inhoud daarvan is:

/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

Ons begin konsul op die bediener. Nou, nadat ons begin het, behoort ons die gekonfigureerde diens in nsul-lede te sien. Dit sal beteken dat hy as kliënt suksesvol aan die cluster gekoppel het. Herhaal dieselfde op die tweede bediener en daarna kan ons begin om Nomad te installeer en op te stel.

'n Meer gedetailleerde installasie van Nomad word in sy amptelike dokumentasie beskryf. Daar is twee tradisionele installasiemetodes: aflaai van 'n binêre lêer en samestelling vanaf bron. Ek sal die eerste manier kies.

Let daarop: die projek ontwikkel baie vinnig, nuwe opdaterings word dikwels vrygestel. Miskien, teen die tyd dat die artikel voltooi is, sal 'n nuwe weergawe vrygestel word. Daarom beveel ek aan dat u die huidige weergawe van Nomad op die oomblik nagaan en aflaai voordat u dit lees. 

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

Nadat ons uitgepak het, sal ons 'n 65 MB Nomad-binêre lêer kry - dit moet na /usr/local/bin geskuif word.

Kom ons skep 'n datagids vir Nomad en wysig sy dienslêer (dit sal waarskynlik nie aan die begin bestaan ​​nie):

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

Voeg die volgende reëls daar in:

[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

Ons is egter nie haastig om nomad te begin nie - ons het nog nie sy konfigurasielêer geskep nie:

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

Die gevolglike gidsstruktuur sal soos volg wees:

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

Die nomad.hcl-lêer moet die volgende konfigurasie bevat:

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

Server.hcl lêer inhoud:

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
}

Moenie vergeet om die konfigurasielêer op die tweede bediener te verander nie - jy sal die waarde van die http-aanwysing daar moet verander.

Die laaste ding op hierdie stadium is om Nginx op te stel om instaanbediener en http-magtiging te installeer. Inhoud van nomad.conf lêer:

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";
        }
        
}

Nou het ons toegang tot die webpaneel oor die eksterne netwerk. Koppel en gaan na die bedienersbladsy:

Die opstel van 'n Nomad-kluster met Consul en integrasie met Gitlab
Beeld 1. Lys van bedieners in 'n Nomad-groepering

Beide bedieners word suksesvol in die paneel vertoon, ons sal dieselfde sien in die uitvoer van die nomad node status opdrag:

Die opstel van 'n Nomad-kluster met Consul en integrasie met Gitlab
Beeld 2. Nomade node status opdrag uitvoer

Wat van konsul? Kom ons kyk. Gaan na die Consul-kontrolepaneel, na die nodusse-bladsy:
Die opstel van 'n Nomad-kluster met Consul en integrasie met Gitlab
Beeld 3. Lys van nodusse in die Konsul-kluster

Nou het ons Nomad gereed, in samewerking met konsul. In die laaste stadium sal ons by die interessantste deel uitkom: ons sal die aflewering van Docker-houers vanaf Gitlab na Nomad opstel, en ook praat oor sommige van sy ander onderskeidende kenmerke.

Skep 'n Gitlab Runner

Om docker-beelde na Nomad te ontplooi, sal ons 'n aparte hardloper gebruik met Nomad se binêre lêer binne (hier kan terloops nog 'n kenmerk van Hashicorp-toepassings opgemerk word - individueel is dit die enigste binêre lêer). Laai dit op na die hardlopergids. Kom ons skep 'n eenvoudige Dockerfile daarvoor met die volgende inhoud:


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

In dieselfde projek, skep .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}

As gevolg hiervan sal ons 'n beskikbare beeld van die Nomad-hardloper in die Gitlab-register hê, nou kan ons direk na die projekbewaarplek gaan, 'n pyplyn skep en Nomad se nomad-werk opstel.

Projek opstelling

Kom ons begin met die werk se lêer vir Nomad. My projek in hierdie artikel sal redelik primitief wees: dit sal uit een taak bestaan. Die inhoud van .gitlab-ci sal soos volg wees:

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

Hier word die ontplooiing met die hand gedoen, maar u kan dit instel om die inhoud van die projekgids te verander. Pyplyn, daarenteen, bestaan ​​uit twee stadiums: van die samestelling van die beeld en die ontplooiing daarvan tot by die nomade. In die eerste stadium bou ons die docker-beeld en stoot dit na ons register, en in die tweede stadium begin ons ons werk in 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" {}
                }
            }
        }
    }
}

Neem asseblief kennis dat ek 'n private register het en vir 'n suksesvolle trek van die docker-beeld moet ek daarby aanmeld. Die beste oplossing in hierdie geval is om die aanmelding en wagwoord in Vault af te sluit en dit dan met Nomad te integreer. Nomad ondersteun Vault inheems. Maar eers, in die Vault self, sal ons die nodige beleide vir Nomad stel, dit kan afgelaai word:

# 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

Nou, nadat ons die nodige beleide geskep het, sal ons integrasie met Vault in die taakblok in die job.nomad-lêer byvoeg:

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

Ek gebruik tokenmagtiging en skryf dit direk hier, daar is ook 'n opsie om die token as 'n veranderlike te spesifiseer wanneer die nomad agent begin:

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

Nou kan ons sleutels met Vault gebruik. Die beginsel van werking is eenvoudig: ons skep 'n lêer in die Nomad-werk wat die waardes van veranderlikes sal stoor, byvoorbeeld:

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
}

Met hierdie eenvoudige benadering kan jy die aflewering van houers aan die Nomad-kluster opstel en in die toekoms daarmee werk. Ek sal sê dat ek tot 'n mate simpatie het met Nomad - dit is meer geskik vir klein projekte waar Kubernetes bykomende probleme kan veroorsaak en nie sy volle potensiaal sal verwesenlik nie. Boonop is Nomad ideaal vir beginners - dit is maklik om te installeer en op te stel. Wanneer ek egter op sommige projekte toets, kry ek die probleem van die vroeë weergawes daarvan - baie basiese funksies bestaan ​​eenvoudig nie of hulle werk nie reg nie. Ek glo egter dat Nomad sal aanhou ontwikkel en in die toekoms die funksies sal bekom wat almal nodig het.

Skrywer: Ilya Andreev, geredigeer deur Alexey Zhadan en die Live Linux-span


Bron: will.com

Voeg 'n opmerking