ProHoster > Blogs > Administrācija > Nomad klastera iestatīŔana, izmantojot Consul, un integrācija ar Gitlab

Nomad klastera iestatīŔana, izmantojot Consul, un integrācija ar Gitlab

Ievads

Pēdējā laikā Kubernetes popularitāte strauji aug ā€“ arvien vairāk projektu to Ä«steno. Es gribēju pieskarties tādam orÄ·estrim kā Nomad: tas ir lieliski piemērots projektiem, kuros jau tiek izmantoti citi HashiCorp risinājumi, piemēram, Vault un Consul, un paÅ”i projekti nav sarežģīti infrastruktÅ«ras ziņā. Å ajā materiālā bÅ«s norādÄ«jumi par Nomad instalÄ“Å”anu, divu mezglu apvienoÅ”anu klasterÄ«, kā arÄ« Nomad integrÄ“Å”anu ar Gitlab.

Nomad klastera iestatīŔana, izmantojot Consul, un integrācija ar Gitlab

Testa stends

Nedaudz par testÄ“Å”anas stendu: tiek izmantoti trÄ«s virtuālie serveri ar 2 CPU, 4 RAM, 50 Gb SSD Ä«paŔībām, kas apvienoti kopējā lokālajā tÄ«klā. Viņu vārdi un IP adreses:

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

Nomad, konsula uzstādīŔana. Nomad klastera izveide

Sāksim ar pamata instalÄ“Å”anu. Lai gan iestatÄ«Å”ana bija vienkārÅ”a, es to aprakstÄ«Å”u raksta integritātes labad: tas bÅ«tÄ«bā tika izveidots no melnrakstiem un piezÄ«mēm, lai vajadzÄ«bas gadÄ«jumā varētu ātri piekļūt.

Pirms sākam praksi, mēs apspriedÄ«sim teorētisko daļu, jo Å”ajā posmā ir svarÄ«gi saprast nākotnes struktÅ«ru.

Mums ir divi nomadu mezgli, un mēs vēlamies tos apvienot klasterÄ«, un nākotnē mums bÅ«s nepiecieÅ”ama arÄ« automātiska klasteru mērogoÅ”ana - Å”im nolÅ«kam mums bÅ«s nepiecieÅ”ams Consul. Izmantojot Å”o rÄ«ku, klasterÄ“Å”ana un jaunu mezglu pievienoÅ”ana kļūst par ļoti vienkārÅ”u uzdevumu: izveidotais Nomad mezgls izveido savienojumu ar Consul aÄ£entu un pēc tam savienojas ar esoÅ”o Nomad klasteru. Tāpēc sākumā mēs uzstādÄ«sim Consul serveri, konfigurēsim pamata http autorizāciju tÄ«mekļa panelim (tas pēc noklusējuma ir bez autorizācijas un tam var piekļūt no ārējās adreses), kā arÄ« paÅ”us Consul aÄ£entus uz Nomad serveriem, pēc kura mēs dosimies tikai uz Nomad.

HashiCorp rÄ«ku instalÄ“Å”ana ir ļoti vienkārÅ”a: bÅ«tÄ«bā mēs vienkārÅ”i pārvietojam bināro failu uz bin direktoriju, iestatām rÄ«ka konfigurācijas failu un izveidojam tā pakalpojuma failu.

Lejupielādējiet Consul bināro failu un izpakojiet to lietotāja mājas direktorijā:

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/

Tagad mums ir gatavs konsula binārs tālākai konfigurācijai.

Lai strādātu ar Consul, mums ir jāizveido unikāla atslēga, izmantojot keygen komandu:

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

Pāriesim pie Consul konfigurācijas iestatīŔanas, izveidojot direktoriju /etc/consul.d/ ar Ŕādu struktūru:

/etc/consul.d/
ā”œā”€ā”€ bootstrap
ā”‚   ā””ā”€ā”€ config.json

Bootstrap direktorijā būs konfigurācijas fails config.json - tajā mēs iestatīsim Consul iestatījumus. Tās saturs:

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

Apskatīsim galvenās direktīvas un to nozīmi atseviŔķi:

  • bootstrap: taisnÄ«ba. Mēs iespējojam jaunu mezglu automātisku pievienoÅ”anu, ja tie ir savienoti. Es atzÄ«mēju, ka mēs Å”eit nenorādam precÄ«zu paredzamo mezglu skaitu.
  • serveris: taisnÄ«ba. Iespējot servera režīmu. Konsuls Å”ajā virtuālajā maŔīnā Å”obrÄ«d darbosies kā vienÄ«gais serveris un galvenais, klienti bÅ«s Nomad virtuālā maŔīna.
  • datu centrs: dc1. Norādiet datu centra nosaukumu, lai izveidotu klasteru. Tam ir jābÅ«t identiskam gan klientiem, gan serveriem.
  • Å”ifrēt: jÅ«su atslēga. Atslēgai, kurai arÄ« jābÅ«t unikālai un jāatbilst visiem klientiem un serveriem. Ä¢enerēts, izmantojot komandu consul keygen.
  • start_join. Å ajā sarakstā mēs norādām to IP adreÅ”u sarakstu, ar kurām tiks izveidots savienojums. Å obrÄ«d atstājam tikai savu adresi.

Šajā brīdī mēs varam palaist konsulu, izmantojot komandrindu:

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

Tas ir labs veids, kā tagad atkļūdot, taču acÄ«mredzamu iemeslu dēļ Å”o metodi nevarēsit izmantot pastāvÄ«gi. Izveidosim pakalpojuma failu, lai pārvaldÄ«tu Consul, izmantojot systemd:

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

Faila consul.service saturs: 

[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

Palaidiet programmu Consul, izmantojot systemctl:

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

Pārbaudīsim: mūsu pakalpojumam ir jādarbojas, un, izpildot konsula dalībnieku komandu, mums vajadzētu redzēt mūsu serveri:

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

Nākamais posms: Nginx instalÄ“Å”ana un starpniekservera un http autorizācijas iestatÄ«Å”ana. Mēs instalējam nginx, izmantojot pakotņu pārvaldnieku, un direktorijā /etc/nginx/sites-enabled mēs izveidojam konfigurācijas failu consul.conf ar Ŕādu saturu:

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

Neaizmirstiet izveidot .htpasswd failu un Ä£enerēt tam lietotājvārdu un paroli. Å is vienums ir nepiecieÅ”ams, lai tÄ«mekļa panelis nebÅ«tu pieejams visiem, kas zina mÅ«su domēnu. Tomēr, iestatot Gitlab, mums tas bÅ«s jāatsakās - pretējā gadÄ«jumā mēs nevarēsim izvietot savu lietojumprogrammu pakalpojumā Nomad. Manā projektā gan Gitlab, gan Nomad atrodas tikai pelēkajā tÄ«meklÄ«, tāpēc Å”eit Ŕādas problēmas nav.

AtlikuÅ”ajos divos serveros mēs instalējam Consul aÄ£entus saskaņā ar tālāk sniegtajiem norādÄ«jumiem. Mēs atkārtojam darbÄ«bas ar bināro failu:

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/

Pēc analoÄ£ijas ar iepriekŔējo serveri mēs izveidojam direktoriju konfigurācijas failiem /etc/consul.d ar Ŕādu struktÅ«ru:

/etc/consul.d/
ā”œā”€ā”€ client
ā”‚   ā””ā”€ā”€ config.json

Faila config.json saturs:

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

Saglabājiet izmaiņas un pārejiet pie pakalpojuma faila, tā satura iestatÄ«Å”anas:

/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

Mēs palaižam konsulu serverÄ«. Tagad pēc palaiÅ”anas mums vajadzētu redzēt konfigurēto pakalpojumu nsul biedros. Tas nozÄ«mēs, ka tas ir veiksmÄ«gi izveidojis savienojumu ar klasteru kā klients. Atkārtojiet to paÅ”u otrajā serverÄ«, un pēc tam mēs varam sākt instalēt un konfigurēt Nomad.

Detalizētāka Nomad uzstādÄ«Å”ana ir aprakstÄ«ta tā oficiālajā dokumentācijā. Ir divas tradicionālās instalÄ“Å”anas metodes: binārā faila lejupielāde un kompilÄ“Å”ana no avota. Es izvēlÄ“Å”os pirmo metodi.

PiezÄ«me: Projekts attÄ«stās ļoti ātri, bieži tiek izdoti jauni atjauninājumi. Iespējams, lÄ«dz Ŕī raksta pabeigÅ”anai tiks izlaista jauna versija. Tāpēc pirms lasÄ«Å”anas iesaku pārbaudÄ«t Å”obrÄ«d aktuālo Nomad versiju un to lejupielādēt. 

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ēc izpakoÅ”anas mēs saņemsim Nomad bināro failu, kas sver 65 MB - tas ir jāpārvieto uz /usr/local/bin.

Izveidosim Nomad datu direktoriju un rediģēsim tā servisa failu (visticamāk, sākumā tas nepastāvēs):

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

IelÄ«mējiet tur Ŕādas rindiņas:

[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

Tomēr mēs nesteidzamies palaist nomad - mēs vēl neesam izveidojuÅ”i tā konfigurācijas failu:

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

Galīgā direktoriju struktūra būs Ŕāda:

/etc/nomad.d/
ā”œā”€ā”€ nomad.hcl
ā””ā”€ā”€ server.hcl

Failā nomad.hcl jābūt Ŕādai konfigurācijai:

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

Server.hcl faila saturs:

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
}

Neaizmirstiet mainīt konfigurācijas failu otrajā serverī - tur jums būs jāmaina http direktīvas vērtība.

Pēdējā lieta Å”ajā posmā ir Nginx konfigurÄ“Å”ana starpniekserveram un http autorizācijas iestatÄ«Å”anai. Faila nomad.conf saturs:

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

Tagad mēs varam piekļūt tīmekļa panelim, izmantojot ārēju tīklu. Izveidojiet savienojumu un dodieties uz servera lapu:

Nomad klastera iestatīŔana, izmantojot Consul, un integrācija ar Gitlab
1. attēls. Nomad klastera serveru saraksts

Abi serveri ir veiksmÄ«gi parādÄ«ti panelÄ«, mēs redzēsim to paÅ”u komandas nomad node statusa izvadē:

Nomad klastera iestatīŔana, izmantojot Consul, un integrācija ar Gitlab
2. attēls. Nomad mezgla statusa komandas izvade

Kā ar konsulu? Paskatīsimies. Dodieties uz Consul vadības paneli, uz mezglu lapu:
Nomad klastera iestatīŔana, izmantojot Consul, un integrācija ar Gitlab
3. attēls. Konsulu klastera mezglu saraksts

Tagad mums ir sagatavots nomads, kas strādā kopā ar konsulu. Pēdējā posmā mēs nonāksim pie jautrās daļas: Docker konteineru piegādes iestatÄ«Å”ana no Gitlab uz Nomad, kā arÄ« runāsim par dažām citām tā raksturÄ«gajām iezÄ«mēm.

Gitlab Runner izveide

Lai izvietotu Docker attēlus pakalpojumā Nomad, mēs izmantosim atseviŔķu skrējēju ar Nomad bināro failu (Å”eit, starp citu, mēs varam atzÄ«mēt vēl vienu Hashicorp lietojumprogrammu funkciju - atseviŔķi tie ir viens binārs fails). AugÅ”upielādējiet to skrējēja direktorijā. Izveidosim tam vienkārÅ”u Dockerfile ar Ŕādu saturu:


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

Tajā paŔā projektā mēs izveidojam .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}

Rezultātā mums bÅ«s pieejams Nomad skrējēja attēls Gitlab reÄ£istrā, tagad mēs varam doties tieÅ”i uz projekta repozitoriju, izveidot cauruļvadu un konfigurēt Nomad nomad darbu.

Projekta iestatīŔana

Sāksim ar Nomad darba failu. Mans projekts Å”ajā rakstā bÅ«s diezgan primitÄ«vs: tas sastāvēs no viena uzdevuma. Faila .gitlab-ci saturs bÅ«s Ŕāds:

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

Å eit izvietoÅ”ana notiek manuāli, taču varat to konfigurēt, lai mainÄ«tu projekta direktorijas saturu. Cauruļvads sastāv no diviem posmiem: attēla montāža un tā izvietoÅ”ana nomadā. Pirmajā posmā mēs apkopojam docker attēlu un ievietojam to savā reÄ£istrā, bet otrajā mēs sākam darbu pakalpojumā 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" {}
                }
            }
        }
    }
}

LÅ«dzu, ņemiet vērā, ka man ir privāts reÄ£istrs un, lai veiksmÄ«gi izvilktu docker attēlu, man tajā jāpiesakās. Labākais risinājums Å”ajā gadÄ«jumā ir Vault ievadÄ«t pieteikumvārdu un paroli un pēc tam integrēt to ar Nomad. Nomad sākotnēji atbalsta Vault. Bet vispirms instalēsim nepiecieÅ”amās politikas Nomad in Vault; tās var lejupielādēt:

# 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

Tagad, izveidojot nepiecieÅ”amās politikas, mēs pievienosim integrāciju ar Vault uzdevumu blokā failā job.nomad:

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

Es izmantoju autorizāciju ar pilnvaru un reÄ£istrēju to tieÅ”i Å”eit, ir arÄ« iespēja norādÄ«t marÄ·ieri kā mainÄ«go, startējot nomadu aÄ£entu:

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

Tagad mēs varam izmantot atslēgas ar Vault. DarbÄ«bas princips ir vienkārÅ”s: mēs izveidojam failu Nomad darbā, kurā tiks saglabātas mainÄ«go vērtÄ«bas, piemēram:

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
}

Izmantojot Å”o vienkārÅ”o pieeju, varat konfigurēt konteineru piegādi Nomad klasterim un strādāt ar to turpmāk. TeikÅ”u, ka zināmā mērā simpatizē Nomad - tas ir vairāk piemērots maziem projektiem, kur Kubernetes var radÄ«t papildu sarežģītÄ«bu un pilnÄ«bā neizmantos savu potenciālu. Turklāt Nomad ir lieliski piemērots iesācējiem ā€” to ir viegli uzstādÄ«t un konfigurēt. Tomēr, testējot dažus projektus, es saskaros ar problēmu ar tā agrÄ«najām versijām - daudzas pamatfunkcijas vienkārÅ”i nav vai arÄ« tās nedarbojas pareizi. Tomēr uzskatu, ka Nomad turpinās attÄ«stÄ«ties un nākotnē iegÅ«s ikvienam nepiecieÅ”amās funkcijas.

Autors: Iļja Andrejevs, rediģējis Aleksejs Žadans un Live Linux komanda


Avots: www.habr.com

Pievieno komentāru