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

Nomadi klastri seadistamine Consuli abil ja integreerimine Gitlabi

Sissejuhatus

Viimastel aegadel on Kubernetes'i populaarsus kiiresti kasvanud — jĂ€rjest rohkem projekte rakendab seda. Soovisin siiski rÀÀkida korraldajatest, nagu Nomad: see sobib suurepĂ€raselt projektidele, kus juba kasutatakse teisi HashiCorpi lahendusi, nagu Vault ja Consul, ning projektid ise ei ole infrastruktuuri osas liiga keerulised. KĂ€esolevas materjalis on juhend Nomadi installimiseks, kahe sĂ”lme ĂŒhendamiseks klastrisse ning Nomadi integreerimiseks Gitlabi.

Nomadi klastri seadistamine Consuli abil ja integreerimine Gitlabi

Teststand

Veidi testkeskkonnast: kasutatakse kolme virtuaalset serverit, mille omadused on 2 CPU, 4 RAM, 50 Gb SSD, ĂŒhendatud ĂŒhte kohalikku vĂ”rku. Nende nimed ja IP-aadressid:

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

Nomadi, Consuli installimine. Nomadi klastrite loomine

Alustame pÔhiinstalleerimisega. Vaatamata installimise lihtsusele, kirjeldan seda artikli terviklikkuse nimel: tegelikult on see loodud mustandite ja mÀrkmete pÔhjal kiireks ligipÀÀsuks vajaduse korral.

Enne praktikas alustamist arutame teooria osa, sest antud etapis on tulevase struktuuri mÔistmine oluline.

Meil on kaks Nomad sĂ”lme ja soovime need klastrisse ĂŒhendada. Tulevikus vajame me ka automaatset klastrite skaleerimist — selleks on meil vaja Consulit. Selle tööriista abil muutub klasterdamine ja uute sĂ”lmede lisamine vĂ€ga lihtsaks: loodud Nomadi sĂ”lm ĂŒhendub Consuli agentidega, pĂ€rast seda ĂŒhendub see olemasoleva Nomadi klastriga. Seega alustame Consuli serveri seadistamisest, konfigureerime baasi http autentimise veebipaneelile (see on vaikimisi ilma autentimiseta ja vĂ”ib olla kĂ€ttesaadav vĂ€lisest aadressist), samuti seadistame Consuli agendid Nomadi serverites, seejĂ€rel liigume edasi Nomadi seadistamise juurde.

HashiCorpi tööriistade paigaldamine on vÀga lihtne: pÔhimÔtteliselt liigutame lihtsalt binaarfaili bin kausta, konfigureerime tööriista konfiguratsioonifaili ja loome teenuse faili.

Laadime alla Consuli binaarfaili ja dekompressime selle kasutaja kodukatalooge:

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 olemas valmis Consuli binaarfail edasiseks seadistamiseks.

Consul'i kasutamiseks peame looma ainulaadse vÔtme kÀsuga keygen:

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

Liigume Consul'i konfiguratsiooni seadistamise juurde, loome katalooge /etc/consul.d/ jÀrgmise struktuuriga:

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

Kataloogis bootstrap asub konfiguratsioonifail config.json — selles mÀÀrame Consul'i seadistused. 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 eraldi pÔhi direktiive ja nende tÀhendusi:

  • bootstrap: true. Lubame uute nodede automaatse lisamise, kui need ĂŒhenduvad. TĂ€histan, et me ei mĂ€rgi siin oodatavate nodede tĂ€pset arvu.
  • server: true. Lubame serveri reĆŸiimi. Consul on sellel virtuaalsel masinal praegu ainus server ja meistrina, Nomad'i VM'id toimivad klientidena.
  • datacenter: dc1. MÀÀrame klastrite jaoks andmekeskuse nime. See peab olema identne nii klientide kui ka serveritega.
  • encrypt: your-key. VĂ”ti, mis peab samuti olema ainulaadne ja ĂŒhtima kĂ”igi klientide ja serveritega. Loobetakse kĂ€suga consul keygen.
  • start_join. Selles loendis toome vĂ€lja IP-aadresside loetelu, millele ĂŒhendust luuakse. Praegu jĂ€tame alles ainult oma aadressi.

Selles etapis saame kÀivitada consul kÀsurea abil:

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

See on praegu hea tĂ”rkeotsingu meetod, kuid pĂŒsivalt seda kasutada ei saa ilmselgetel pĂ”hjustel. Loome teenuse faili, et hallata Consulit lĂ€bi systemd:

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

faili consul.service sisu:

[Unit]
Description=Consuli kÀivitamisprotsess
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Àivitame Consuli lÀbi systemctl:

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

Kontrollime: meie teenus peaks olema kÀivitatud, ja kui kÀivitame kÀsu consul members, peaksime nÀgema meie serverit:

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

JÀrgmine etapp: Nginxi installimine ja pöördumise, http-autentimise seadistamine. Installeerime nginx pakihalduri kaudu ja kataloogis /etc/nginx/sites-enabled loome konfiguratsioonifaili consul.conf jÀrgmise sisuga:

ĂŒlesvoolne 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 "Parooliga kaitstud ala";
    }
}

Ärge unustage luua .htpasswd faili ja genereerida sellele kasutajanimi ja parool. See samm on vajalik, et veebiportaal ei oleks kergesti kĂ€ttesaadav kĂ”igile, kes meie domeeni tunnevad. Siiski tuleb Gitlabi seadistamisel sellest loobuda — vastasel juhul ei saa me oma rakendust Nomadi seadistada. Minu projektis asuvad nii Gitlab kui ka Nomad ainult hallis vĂ”rgus, seega pole siin sellist probleemi.

Paigaldame Consul agentid kahes ĂŒlejÀÀnud serveris jĂ€rgnevate juhiste kohaselt. Korrake toiminguid 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/

Sama nagu eelmine server, loome konfiguratsioonifailide kausta /etc/consul.d jÀrgmise struktuuriga:

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

config.json faili 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", # kohalik VM aadress
    "start_join": ["172.30.0.15"], # kaugserveri konsul aadress
    "ports": {
      "dns": 53
     }

Salvestame muudatused ja liigume teenuse faili seadistamise juurde, selle sisu:

/etc/systemd/system/consul.service:

[Unit]
Description="HashiCorp Consul - teenuste vÔrgu lahendus"
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 Consul serveris. NĂŒĂŒd, pĂ€rast kĂ€ivitamist, peaksime nsul members nĂ€gema seadistatud teenust. See tĂ€hendaks, et see on edukalt liitunud klastriga kliendina. Korrake sama teisel serveril ja seejĂ€rel saame alustada Nomadi installimise ja seadistamisega.

PodrobnejĆĄa installacija Nomad on kirjeldatud selle ametlikus dokumentatsioonis. On kaks traditsioonilist installimise meetodit: binaarfaili allalaadimine ja allikakoodist kompileerimine. Valin esimese meetodi.

MÀrkus: projekt areneb vÀga kiiresti, tihti tulevad vÀlja uued uuendused. VÔib-olla on artikli lÔpetamise ajaks vÀlja tulnud uus versioon. SeetÔttu soovitan enne lugemist kontrollida Nomadi praegust versiooni ja laadida alla just see.

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

Pakkimise jĂ€rel saame Nomad’i binaarfaili, mille suurus on 65 MB — see tuleb paigutada /usr/local/bin.

Loome Nomad’i jaoks andmedirectory ja redigeerime tema teenuse faili (seda pole tĂ”enĂ€oliselt alguses olemas):

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

Kopeerime 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Ă€ivitama — me pole veel tema konfigureerimise faili 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

Katalooge struktuur on jÀrgmine:

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

Fail nomad.hcl peab sisaldama jÀrgmist konfiguratsiooni:

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

Faili server.hcl 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 konfigureerimise fail teisel serveril — seal tuleb muuta http direktiivi vÀÀrtust.

Viimase sammu hulka kuulub Nginxi seadistamine proksiks ja http autoriseerimise seadistamine. 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 "Parooliga kaitstud ala";
        }
        
}

NĂŒĂŒd saame pÀÀseda veebihalduspaneelile vĂ€lisest vĂ”rgust. Logime sisse ja liigume servers lehele:

Nomadi klastri seadistamine Consuli abil ja integreerimine Gitlabi
Pilt 1. Nomadi klastri serverite nimekiri

MÔlemad serverid kuvatakse juhtpaneelis edukalt, sama nÀeme ka kÀsu nomad node status vÀljundis:

Nomadi klastri seadistamine Consuli abil ja integreerimine Gitlabi
Kujutis 2. KÀsk nomad node status vÀljund

Aga kuidas on Consuliga? Vaadakem. Liigume Consuli juhtpaneeli, nodide lehele:
Nomadi klastri seadistamine Consuli abil ja integreerimine Gitlabi
Kujutis 3. Consuli klastri nodide nimekiri

NĂŒĂŒd on meie Nomad valmis ja töötab koos Consuliga. LĂ”ppfaasis alustame kĂ”ige huvitavaga: seadistame Docker konteinerite saatmise Gitlabist Nomadi ja rÀÀgime ka mĂ”nest tema teistsugusest omadusest.

Gitlab Runneri loomine

Docker piltide juurutamiseks Nomadis kasutame eraldi runtnerit koos Nomadi binaarfailiga sees (siin on muideks veel ĂŒks Hashicorpi rakenduste omadus — nad esindavad eraldi ĂŒhtset binaarfaili). Laadige see runneri katalooge. Loome sellele kĂ”ige lihtsama Dockerfile'i jĂ€rgmise sisuga:


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

Loome samas projektis .gitlab-ci.yml:

muutujad:
  DOCKER_IMAGE: nomad/nomad-deploy
  DOCKER_REGISTRY: registry.domain.name
 

etapid:
  - ehitamine

ehitamine:
  etapp: ehitamine
  pilt: ${DOCKER_REGISTRY}/nomad/alpine:3
  skript:
    - tag=${DOCKER_REGISTRY}/${DOCKER_IMAGE}:latest
    - docker build --pull -t ${tag} -f Dockerfile .
    - docker push ${tag}

KokkuvĂ”ttes saame Gitlab Registry'sse juurdepÀÀsetava Nomadi runner'i pildi, nĂŒĂŒd saame minna otse projekti reposi, luues Pipeline'i ja seadistades Nomadi töö.

Projekti seadistus

Alustame Nomadi töö failiga. Minu projekt selles artiklis on piisavalt primitiivne: see koosneb ĂŒhest ĂŒlesandest. Faili .gitlab-ci sisu on jĂ€rgmine:

muutujad:
  NOMAD_ADDR: http://nomad.address.service:4646
  DOCKER_REGISTRY: registry.domain.name
  DOCKER_IMAGE: example/project

etapid:
  - ehitamine
  - juurutamine

ehitamine:
  etapp: ehitamine
  pilt: ${DOCKER_REGISTRY}/nomad-runner/alpine:3
  skript:
    - tag=${DOCKER_REGISTRY}/${DOCKER_IMAGE}:${CI_COMMIT_SHORT_SHA}
    - docker build --pull -t ${tag} -f Dockerfile .
    - docker push ${tag}


juurutamine:
  etapp: juurutamine
  pilt: registry.example.com/nomad/nomad-runner:latest
  skript:
    - 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
  keskkond:
    nimi: tootmine
  lubatud_viga: vale
  kui: kÀsitsi

Siin toimub juurutamine kÀsitsi, kuid vÔite seadistada selle projektikausta sisu muutmiseks. Pipeline koosneb kahest etapist: pildi koostamisest ja selle juurutamisest Nomadis. Esimeses etapis koostame Docker-pildi ja pushime selle meie registrisse, teises etapis kÀivitame meie 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" {}
                }
            }
        }
    }
}

Palun pange tÀhele, et mul on suletud Register ja docker-image'i eduka tÔmbamise jaoks pean seal sisse logima. Parim lahendus antud juhtumis on lisada kasutajanimi ja parool Vaulti, mille jÀrel integreerime selle Nomadiga. Nomad toetab Vaulti natiivselt. Aga kÔigepealt seadistame Vaultis vajalikud poliitikad Nomadi jaoks, 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, kui oleme loonud vajalikud poliitikad, lisame job.nomadi faili task plokis Vaultiga integreerimise:

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

Kasutame autentimist tokeniga ja kirjutame selle siia otse; samuti on vÔimalus mÀÀrata token muutujana, kui kÀivitada nomad agent:

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

NĂŒĂŒd saame kasutada vĂ”tmeid Vaultist. Tööprincip on lihtne: loome faili Nomadi töö jaoks, mis hoiab endas muutujate vÀÀrtusi, 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
}

Nii lihtsa lĂ€henemisega saab seadistada konteinerite tarnimist Nomad-klastrisse ja töötada sellega edaspidi. Ütlen ausalt, et mingil mÀÀral tunnen Nomadi vastu sĂŒmpaatiat — see sobib rohkem vĂ€ikestele projektidele, kus Kubernetes vĂ”ib tekitada lisaraskusi ja ei saavuta oma potentsiaali tĂ€ielikult. Lisaks sobib Nomad suurepĂ€raselt algajatele — selle paigaldamine ja konfigureerimine on lihtne. Siiski olen mĂ”nede projektide testimisel kokku puutunud varasemate versioonide probleemidega — paljudes pĂ”hifunktsioonides ei ole neid ĂŒldse vĂ”i need ei tööta korralikult. Sellegipoolest usun, et Nomad areneb edasi ja tulevikus on tal kĂ”ik vajalikud funktsioonid.

Autor: Ilya Andreyev, toimetanud Alexey Zhadan ja 'Live Linux' meeskond


Allikas: habr.com

Osta usaldusvÀÀrne veebihosting DDoS kaitsega, VPS VDS serverid đŸ”„ Osta usaldusvÀÀrne veebihosting DDoS kaitsega, VPS VDS serverid | ProHoster