ProHoster > Blogi > Haldamine > Nomadi klastri seadistamine Consuli abil ja integreerimine Gitlabiga

Nomadi klastri seadistamine Consuli abil ja integreerimine Gitlabiga

Sissejuhatus

Viimasel ajal on Kubernetese populaarsus kiiresti kasvanud – seda rakendab üha rohkem projekte. Tahtsin puudutada sellist orkestraatorit nagu Nomad: see sobib suurepäraselt projektidele, mis juba kasutavad muid HashiCorpi lahendusi, näiteks Vault ja Consul, ning projektid ise pole infrastruktuuri poolest keerulised. See materjal sisaldab juhiseid Nomadi installimiseks, kahe sõlme ühendamiseks klastriks ja Nomadi integreerimiseks Gitlabiga.

Nomadi klastri seadistamine Consuli abil ja integreerimine Gitlabiga

Katselaud

Natuke katsestendist: kasutusel on kolm virtuaalserverit, millel on 2 CPU, 4 RAM, 50 Gb SSD omadused, mis on ühendatud ühiseks kohtvõrguks. Nende nimed ja IP-aadressid:

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

Nomad, konsul paigaldamine. Nomadi klastri loomine

Alustame põhiinstallatsiooniga. Kuigi seadistus oli lihtne, kirjeldan seda artikli terviklikkuse huvides: see loodi sisuliselt mustanditest ja märkmetest, et vajadusel kiiresti juurde pääseda.

Enne praktika alustamist arutame teoreetilise osa üle, sest selles etapis on oluline mõista tulevast struktuuri.

Meil on kaks nomaadsõlme ja tahame need klastriks ühendada ning tulevikus on vaja ka automaatset klastri skaleerimist - selleks on vaja Consulit. Selle tööriistaga muutub rühmitamine ja uute sõlmede lisamine väga lihtsaks ülesandeks: loodud Nomadi sõlm loob ühenduse konsuli agendiga ja seejärel olemasoleva Nomadi klastriga. Seetõttu installime alguses Consuli serveri, seadistame veebipaneelile põhilise http autoriseerimise (vaikimisi on see ilma autoriseerimiseta ja sellele pääseb juurde välisaadressil), aga ka Consuli agendid ise Nomad serverites, mille järel liigume edasi ainult Nomadile.

HashiCorpi tööriistade installimine on väga lihtne: sisuliselt teisaldame binaarfaili lihtsalt bin kataloogi, seadistame tööriista konfiguratsioonifaili ja loome selle teenusefaili.

Laadige alla Consuli binaarfail ja pakkige see lahti kasutaja kodukataloogi:

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/

Nüüd on meil edasiseks konfigureerimiseks valmis konsuli binaarfail.

Consuliga töötamiseks peame looma unikaalse võtme, kasutades käsku keygen:

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

Liigume edasi Consul konfiguratsiooni seadistamise juurde, luues järgmise struktuuriga kataloogi /etc/consul.d/:

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

Bootstrap kataloog sisaldab konfiguratsioonifaili config.json - selles määrame Consuli sätted. Selle sisu:

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

Vaatame põhidirektiive ja nende tähendusi eraldi:

  • bootstrap: tõsi. Lubame uute sõlmede automaatse lisamise, kui need on ühendatud. Märgin, et me ei näita siin eeldatavate sõlmede täpset arvu.
  • server: tõsi. Luba serverirežiim. Konsul selles virtuaalmasinas tegutseb hetkel ainsa serverina ja masterina, klientideks on Nomadi VM.
  • andmekeskus: dc1. Määrake klastri loomiseks andmekeskuse nimi. See peab olema identne nii klientides kui ka serverites.
  • krüptida: teie võti. Võti, mis peab samuti olema ainulaadne ja sobima kõikides klientides ja serverites. Loodud käsu consul keygen abil.
  • start_join. Selles loendis näitame IP-aadresside loendit, millega ühendus luuakse. Hetkel jätame ainult enda aadressi.

Sel hetkel saame käivitada consul käsurealt:

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

See on praegu hea viis silumiseks, kuid te ei saa seda meetodit arusaadavatel põhjustel pidevalt kasutada. Loome teenusefaili Consuli haldamiseks systemd kaudu:

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

Faili consul.service sisu: 

[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

Käivitage Consul systemctl kaudu:

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

Kontrollime: meie teenus peab töötama ja konsuli liikmete käsu täitmisel peaksime nägema oma serverit:

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

Järgmine etapp: Nginxi installimine ning puhverserveri ja http autoriseerimise seadistamine. Installime nginxi paketihalduri kaudu ja kataloogis /etc/nginx/sites-enabled loome järgmise sisuga konfiguratsioonifaili consul.conf:

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

Ärge unustage luua .htpasswd-faili ning genereerida sellele kasutajanimi ja parool. See üksus on vajalik, et veebipaneel poleks kõigile meie domeeni tundjatele kättesaadav. Gitlabi seadistamisel peame aga sellest loobuma – muidu ei saa me oma rakendust Nomadile juurutada. Minu projektis on nii Gitlab kui ka Nomad ainult hallis veebis, seega siin sellist probleemi pole.

Ülejäänud kahele serverile installime Consuli agendid vastavalt järgmistele juhistele. Kordame samme binaarfailiga:

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/

Analoogiliselt eelmise serveriga loome konfiguratsioonifailide /etc/consul.d jaoks järgmise struktuuriga kataloogi:

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

Faili config.json sisu:

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

Salvestage muudatused ja jätkake teenusefaili ja selle sisu seadistamisega:

/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

Käivitame serveris konsuli. Nüüd, pärast käivitamist, peaksime nsuli liikmetes nägema konfigureeritud teenust. See tähendab, et see on klastriga kliendina edukalt ühendatud. Korrake sama teises serveris ja pärast seda saame alustada Nomadi installimist ja konfigureerimist.

Nomadi täpsemat paigaldamist kirjeldatakse selle ametlikus dokumentatsioonis. On kaks traditsioonilist installimeetodit: binaarfaili allalaadimine ja allikast kompileerimine. Ma valin esimese meetodi.

Märkus: Projekt areneb väga kiiresti, sageli antakse välja uusi värskendusi. Võib-olla ilmub selle artikli valmimise ajaks uus versioon. Seetõttu soovitan enne lugemist vaadata hetkel Nomadi praegust versiooni ja see alla laadida. 

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

Pärast lahtipakkimist saame 65 MB kaaluva Nomad binaarfaili – see tuleb teisaldada kausta /usr/local/bin.

Loome Nomadile andmekataloogi ja redigeerime selle teenusefaili (tõenäoliselt pole seda alguses olemas):

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

Kleepige sinna järgmised read:

[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

Kuid me ei kiirusta nomadi käivitamisega - me pole veel selle konfiguratsioonifaili loonud:

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

Lõplik kataloogistruktuur on järgmine:

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

Fail nomad.hcl peaks sisaldama järgmist konfiguratsiooni:

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

Server.hcl faili sisu:

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
}

Ärge unustage muuta konfiguratsioonifaili teises serveris - seal peate muutma http-direktiivi väärtust.

Viimane asi selles etapis on Nginxi konfigureerimine puhverserveri kasutamiseks ja http-volituse seadistamiseks. Faili nomad.conf sisu:

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

Nüüd pääseme veebipaneelile juurde välisvõrgu kaudu. Ühendage ja minge serverite lehele:

Nomadi klastri seadistamine Consuli abil ja integreerimine Gitlabiga
1. pilt. Nomadi klastri serverite loend

Mõlemad serverid kuvatakse paneelil edukalt, nomad node status käsu väljundis näeme sama:

Nomadi klastri seadistamine Consuli abil ja integreerimine Gitlabiga
2. pilt. Nomaadsõlme staatuse käsu väljund

Aga konsul? Vaatame. Minge konsuli juhtpaneelile sõlmede lehele:
Nomadi klastri seadistamine Consuli abil ja integreerimine Gitlabiga
3. pilt. Konsulite klastri sõlmede loend

Nüüd on meil ettevalmistatud Nomad, kes töötab koos konsuliga. Viimases etapis jõuame lõbusa osani: Dockeri konteinerite tarnimise seadistamine Gitlabist Nomadile ja räägime ka mõnest muust selle eripärast.

Gitlab Runneri loomine

Dockeri kujutiste juurutamiseks Nomadile kasutame eraldi jooksjat, mille sees on Nomadi binaarfail (siin, muide, võime märkida veel ühte Hashicorpi rakenduste funktsiooni - eraldi on need üks kahendfail). Laadige see üles jooksja kataloogi. Loome selle jaoks lihtsa Dockeri faili järgmise sisuga:


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

Samas projektis loome faili .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}

Selle tulemusel on meil Gitlabi registris Nomad Runneri pilt, nüüd saame minna otse projekti hoidlasse, luua torujuhtme ja konfigureerida Nomadi nomadi töö.

Projekti seadistamine

Alustame Nomadi tööfailiga. Minu projekt selles artiklis on üsna primitiivne: see koosneb ühest ülesandest. Faili .gitlab-ci sisu on järgmine:

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

Siin toimub juurutamine käsitsi, kuid saate selle konfigureerida projektikataloogi sisu muutmiseks. Torujuhe koosneb kahest etapist: pildi kokkupanek ja selle juurutamine nomadile. Esimeses etapis koostame dokipildi ja lükkame selle oma registrisse ning teises käivitame oma töö Nomadis. 

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

Pange tähele, et mul on privaatne register ja dokkeri kujutise edukaks tõmbamiseks pean sellesse sisse logima. Parim lahendus on sel juhul sisestada Vaulti sisselogimine ja parool ning seejärel integreerida see Nomadiga. Nomad toetab algselt Vaulti. Kuid kõigepealt installime Vaultis Nomadi jaoks vajalikud poliitikad; neid saab alla laadida:

# 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

Nüüd, pärast vajalike poliitikate loomist, lisame faili job.nomad tegumiplokki integratsiooni Vaultiga:

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

Kasutan autoriseerimist loa alusel ja registreerin selle otse siin, samuti on nomaadagendi käivitamisel võimalus määrata token muutujaks:

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

Nüüd saame võtmeid Vaultiga kasutada. Toimimispõhimõte on lihtne: loome Nomad töös faili, mis salvestab muutujate väärtused, näiteks:

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
}

Selle lihtsa lähenemisviisi abil saate konfigureerida konteinerite tarnimise Nomad klastrisse ja sellega edaspidi koostööd teha. Ütlen, et mingil määral tunnen Nomadile kaasa - see sobib pigem väikeste projektide jaoks, kus Kubernetes võib tekitada täiendavat keerukust ega realiseeri oma täit potentsiaali. Lisaks on Nomad ideaalne algajatele – seda on lihtne paigaldada ja konfigureerida. Mõne projektiga testides puutun aga kokku probleemiga selle varajaste versioonidega – paljud põhifunktsioonid lihtsalt puuduvad või ei tööta korralikult. Usun aga, et Nomad areneb edasi ja tulevikus omandab need funktsioonid, mida kõik vajavad.

Autor: Ilja Andreev, toimetanud Aleksei Zhadan ja Live Linuxi meeskond


Allikas: www.habr.com

Lisa kommentaar