ProHoster > Blog > Administrazioa > Nomad kluster bat konfiguratzea Consul erabiliz eta Gitlab-ekin integratzea

Nomad kluster bat konfiguratzea Consul erabiliz eta Gitlab-ekin integratzea

Sarrera

Azkenaldian, Kubernetesen ospea azkar hazten ari da - gero eta proiektu gehiagok ezartzen ari dira. Nomad bezalako orkestratzaile bat ukitu nahi nuen: ezin hobea da HashiCorp-en beste soluzio batzuk erabiltzen dituzten proiektuetarako, adibidez, Vault eta Consul, eta proiektuak beraiek ez dira konplexuak azpiegitura aldetik. Material honek Nomad instalatzeko argibideak izango ditu, bi nodo kluster batean konbinatuz, baita Nomad Gitlab-ekin integratzeko ere.

Nomad kluster bat konfiguratzea Consul erabiliz eta Gitlab-ekin integratzea

proba-bankua

Proba-bankuari buruz apur bat: hiru zerbitzari birtual erabiltzen dira 2 CPU, 4 RAM, 50 Gb SSDren ezaugarriekin, sare lokal komun batean elkartuta. Haien izenak eta IP helbideak:

  1. nomada-livelinux-01: 172.30.0.5
  2. nomada-livelinux-02: 172.30.0.10
  3. kontsul-livelinux-01: 172.30.0.15

Nomad, kontsularen instalazioa. Nomad kluster bat sortzea

Has gaitezen oinarrizko instalazioarekin. Konfigurazioa sinplea izan arren, artikuluaren osotasunagatik deskribatuko dut: funtsean, zirriborroetatik eta oharretatik sortu zen behar zenean azkar sartzeko.

Praktikan hasi aurretik, atal teorikoa eztabaidatuko dugu, etapa honetan garrantzitsua baita etorkizuneko egitura ulertzea.

Bi nodo nomada ditugu eta kluster batean konbinatu nahi ditugu, eta etorkizunean kluster eskalatze automatikoa ere beharko dugu; horretarako, Kontsul beharko dugu. Tresna honekin, nodo berriak multzokatzea eta gehitzea oso lan sinplea bihurtzen da: sortutako Nomad nodoa Consul agentearekin konektatzen da, eta gero lehendik dagoen Nomad klusterera konektatzen da. Hori dela eta, hasieran Consul zerbitzaria instalatuko dugu, web panelerako oinarrizko http baimena konfiguratuko dugu (lehenespenez baimenik gabe dago eta kanpoko helbide batean atzitu daiteke), baita Consul agenteak beraiek ere Nomad zerbitzarietan, eta ondoren. Nomad-era bakarrik joango gara.

HashiCorp-en tresnak instalatzea oso erraza da: funtsean, fitxategi bitarra bin direktoriora eraman, tresnaren konfigurazio fitxategia konfiguratu eta bere zerbitzu fitxategia sortu besterik ez dugu.

Deskargatu Consul fitxategi bitarra eta deskonprimitu erabiltzailearen hasierako direktorioan:

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/

Orain prest egindako kontsul bitar bat dugu konfigurazio gehiagorako.

Consul-ekin lan egiteko, gako esklusibo bat sortu behar dugu keygen komandoa erabiliz:

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

Goazen Kontsularen konfigurazioa konfiguratzera, /etc/consul.d/ direktorio bat sortuz hurrengo egiturarekin:

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

Bootstrap direktorioak config.json konfigurazio fitxategi bat edukiko du - bertan Consul ezarpenak ezarriko ditugu. Bere edukia:

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

Ikus ditzagun zuzentarau nagusiak eta haien esanahiak bereizita:

  • bootstrap: egia. Nodo berriak automatikoki gehitzea gaitzen dugu konektatuta baldin badaude. Kontuan hartzen dut hemen ez dugula adierazten espero diren nodoen kopuru zehatza.
  • zerbitzaria: egia. Gaitu zerbitzari modua. Makina birtual honetako kontsulak zerbitzari eta maisu bakar gisa jardungo du momentuz, Nomad-en VM bezeroak izango dira.
  • datacenter: dc1. Zehaztu datu-zentroaren izena klusterra sortzeko. Bezeroetan zein zerbitzarietan berdina izan behar du.
  • encrypt: zure-giltza. Gakoa, bezero eta zerbitzari guztietan bakarra eta bat etorri behar duena ere. Consul keygen komandoa erabiliz sortu da.
  • hasi_join. Zerrenda honetan konexioa egingo den IP helbideen zerrenda adierazten dugu. Momentuz gure helbidea bakarrik uzten dugu.

Une honetan, consul exekutatu dezakegu komando lerroa erabiliz:

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

Orain arazketa egiteko modu ona da, hala ere, ezin izango duzu metodo hau etengabe erabili arrazoi bistakoengatik. Sortu dezagun zerbitzu-fitxategi bat Systemd bidez Consul kudeatzeko:

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

Consul.service fitxategiaren edukia: 

[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

Abiarazi Consul systemctl bidez:

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

Egiazta dezagun: gure zerbitzuak martxan egon behar du, eta kontsulkideen komandoa exekutatuta gure zerbitzaria ikusi beharko genuke:

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

Hurrengo etapa: Nginx instalatzea eta proxy-a eta http baimena konfiguratzea. Nginx pakete-kudeatzailearen bidez instalatzen dugu eta /etc/nginx/sites-enabled direktorioan consul.conf konfigurazio fitxategi bat sortzen dugu eduki hauekin:

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

Ez ahaztu .htpasswd fitxategi bat sortzea eta erabiltzaile-izena eta pasahitza sortzea. Elementu hau beharrezkoa da web panela gure domeinua ezagutzen duten guztientzat erabilgarri egon ez dadin. Hala ere, Gitlab konfiguratzean, hau alde batera utzi beharko dugu; bestela, ezingo dugu gure aplikazioa zabaldu Nomad-en. Nire proiektuan, bai Gitlab eta bai Nomad sare grisean soilik daude, beraz, hemen ez dago horrelako arazorik.

Gainerako bi zerbitzarietan Consul agenteak instalatzen ditugu jarraibide hauen arabera. Pausoak fitxategi bitarrekin errepikatzen ditugu:

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/

Aurreko zerbitzariaren analogia eginez, /etc/consul.d konfigurazio-fitxategietarako direktorio bat sortzen dugu honako egiturarekin:

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

config.json fitxategiaren edukia:

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

Gorde aldaketak eta joan zerbitzu-fitxategia, bere edukia, konfiguratzera:

/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

Kontsul abiarazten dugu zerbitzarian. Orain, abiarazi ondoren, konfiguratutako zerbitzua ikusi beharko genuke nsul kideetan. Horrek esan nahi du klusterera arrakastaz konektatu dela bezero gisa. Errepikatu gauza bera bigarren zerbitzarian eta horren ondoren Nomad instalatzen eta konfiguratzen has gaitezke.

Nomad-en instalazio zehatzagoa bere dokumentazio ofizialean deskribatzen da. Bi instalazio metodo tradizional daude: fitxategi bitar bat deskargatzea eta iturritik konpilatzea. Lehenengo metodoa aukeratuko dut.

Kontuan izan: Proiektua oso azkar garatzen ari da, eguneratze berriak kaleratzen dira askotan. Agian, artikulu hau amaitzen denerako bertsio berri bat kaleratuko da. Horregatik, irakurri aurretik, Nomad-en uneko bertsioa egiaztatzea eta deskargatzea gomendatzen dut. 

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

Despaketatu ondoren, Nomad fitxategi bitar bat jasoko dugu 65 MB pisatzen duena - /usr/local/bin-era eraman behar da.

Sortu dezagun Nomad-entzako datu-direktorio bat eta editatu bere zerbitzu-fitxategia (seguruenik hasieran ez da existituko):

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

Itsatsi hor lerro hauek:

[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

Hala ere, ez dugu presarik nomad abiarazteko - oraindik ez dugu bere konfigurazio fitxategia sortu:

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

Direktorioaren azken egitura honako hau izango da:

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

Nomad.hcl fitxategiak konfigurazio hau eduki behar du:

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

server.hcl fitxategiaren edukia:

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
}

Ez ahaztu bigarren zerbitzarian konfigurazio fitxategia aldatzea - ​​hor http zuzentarauaren balioa aldatu beharko duzu.

Etapa honetako azken gauza Nginx proxy-a eta http baimena konfiguratzeko konfiguratzea da. nomad.conf fitxategiaren edukia:

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

Orain web panelera sar gaitezke kanpoko sare baten bidez. Konektatu eta joan zerbitzarien orrialdera:

Nomad kluster bat konfiguratzea Consul erabiliz eta Gitlab-ekin integratzea
1. irudia. Nomad klusterreko zerbitzarien zerrenda

Bi zerbitzariak ongi bistaratzen dira panelean, gauza bera ikusiko dugu nomad node status komandoaren irteeran:

Nomad kluster bat konfiguratzea Consul erabiliz eta Gitlab-ekin integratzea
2. irudia. Nomad nodo egoera komandoaren irteera

Zer esan kontsularekin? Ikus dezagun. Joan Kontsularen kontrol panelera, nodoen orrialdera:
Nomad kluster bat konfiguratzea Consul erabiliz eta Gitlab-ekin integratzea
3. irudia. Kontsul klusterreko nodoen zerrenda

Orain prest dagoen Nomada bat dugu Kontsularekin batera lanean. Azken fasean, atal dibertigarrira iritsiko gara: Gitlabetik Nomad-era Docker edukiontziak konfiguratzea eta bere beste ezaugarri bereizgarri batzuei buruz hitz egitea.

Gitlab Runner sortzen

Docker irudiak Nomad-en zabaltzeko, korridore bereizi bat erabiliko dugu barruan Nomad fitxategi bitarra duena (hemen, bide batez, Hashicorp aplikazioen beste ezaugarri bat nabari dezakegu: banan-banan fitxategi bitar bakarra dira). Kargatu korrikalarien direktoriora. Sortu dezagun Dockerfile soil bat horretarako eduki honekin:


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

Proiektu berean .gitlab-ci.yml sortzen dugu:

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}

Ondorioz, Nomad korrikalariaren irudi bat eskuragarri izango dugu Gitlab Erregistroan, orain proiektuaren biltegira joan gaitezke zuzenean, Pipeline bat sortu eta Nomad-en lan nomada konfiguratu.

Proiektuaren konfigurazioa

Has gaitezen Nomad-en lanaren fitxategiarekin. Artikulu honetako nire proiektua nahiko primitiboa izango da: zeregin bakarra izango du. .gitlab-ci-ren edukia honako hau izango da:

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

Hemen inplementazioa eskuz egiten da, baina proiektuaren direktorioaren edukia aldatzeko konfigura dezakezu. Pipeline-ak bi fase ditu: irudiaren muntaketa eta bere hedapena nomadari. Lehenengo fasean, docker irudi bat muntatzen dugu eta gure Erregistrora bultzatzen dugu, eta bigarrenean Nomad-en gure lana abiarazten dugu. 

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

Kontuan izan Erregistro pribatu bat dudala eta docker irudi bat behar bezala ateratzeko bertan saioa hasi behar dudala. Irtenbiderik onena kasu honetan saio-hasiera eta pasahitza sartu Vault-en eta gero Nomad-ekin integratzea da. Nomad-ek berez onartzen du Vault. Baina lehenik eta behin, instala ditzagun Nomad-erako beharrezko politikak Vault-en bertan; deskargatu daitezke:

# 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

Orain, beharrezko politikak sortuta, Vault-ekin integrazioa gehituko dugu job.nomad fitxategiko ataza blokean:

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

Baimena token bidez erabiltzen dut eta hemen erregistratzen dut zuzenean, agente nomada abiaraztean tokena aldagai gisa zehazteko aukera ere badago:

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

Orain gakoak erabili ditzakegu Vault-ekin. Funtzionamendu-printzipioa erraza da: Nomad lanean fitxategi bat sortzen dugu, aldagaien balioak gordeko dituena, adibidez:

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
}

Planteamendu sinple honekin, Nomad klusterera edukiontziak bidaltzea konfigura dezakezu eta etorkizunean lan egin dezakezu. Esango dut neurri batean Nomad-ekin bat egiten dudala; egokiagoa da Kubernetes-ek konplexutasun gehigarria sor dezakeen eta bere potentzial osoa jabetuko ez den proiektu txikietarako. Gainera, Nomad ezin hobea da hasiberrientzat; erraza da instalatzen eta konfiguratzen. Hala ere, zenbait proiektutan probatzean, arazo bat aurkitzen dut bere lehen bertsioekin - oinarrizko funtzio asko ez daude edo ez dute behar bezala funtzionatzen. Hala ere, Uste dut Nomad-ek garatzen jarraituko duela eta etorkizunean denek behar dituzten funtzioak eskuratuko dituela.

Egilea: Ilya Andreev, Alexey Zhadan eta Live Linux taldeak editatua


Iturria: www.habr.com

Gehitu iruzkin berria