ProHoster > Blog > Bestjoer > In Nomad-kluster ynstelle mei Consul en yntegrearje mei Gitlab

In Nomad-kluster ynstelle mei Consul en yntegrearje mei Gitlab

Ynlieding

Koartlyn is de populariteit fan Kubernetes rap groeid - hieltyd mear projekten implementearje it. Ik woe in orkestrator lykas Nomad oanreitsje: it is perfekt foar projekten dy't al oare oplossingen fan HashiCorp brûke, bygelyks Vault en Consul, en de projekten sels binne net kompleks yn termen fan ynfrastruktuer. Dit materiaal sil ynstruksjes befetsje foar it ynstallearjen fan Nomad, it kombinearjen fan twa knooppunten yn in kluster, en ek it yntegrearjen fan Nomad mei Gitlab.

In Nomad-kluster ynstelle mei Consul en yntegrearje mei Gitlab

test stand

In bytsje oer de testbank: trije firtuele servers wurde brûkt mei de skaaimerken fan 2 CPU, 4 RAM, 50 Gb SSD, ferienige yn in mienskiplik lokaal netwurk. Harren nammen en IP-adressen:

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

Ynstallaasje fan Nomad, konsul. It meitsjen fan in Nomad-kluster

Litte wy begjinne mei de basis ynstallaasje. Hoewol de opset ienfâldich wie, sil ik it beskriuwe om 'e yntegriteit fan it artikel: it is yn essinsje makke fan ûntwerpen en notysjes foar rappe tagong as it nedich is.

Foardat wy de praktyk begjinne, sille wy it teoretyske diel besprekke, om't op dit stadium it wichtich is om de takomstige struktuer te begripen.

Wy hawwe twa nomadenknooppunten en wy wolle se kombinearje yn in kluster, en yn 'e takomst sille wy ek automatyske klusterskalearring nedich wêze - dêrfoar sille wy Consul nedich hawwe. Mei dit ark wurdt klusterjen en tafoegjen fan nije knooppunten in heul ienfâldige taak: de oanmakke Nomad-knooppunt ferbynt mei de Consul-agint, en ferbynt dan mei it besteande Nomad-kluster. Dêrom sille wy oan it begjin de Consul-tsjinner ynstallearje, de basis http-autorisaasje foar it webpaniel ynstelle (it is standert sûnder autorisaasje en kin tagonklik wurde op in ekstern adres), lykas de Consul-aginten sels op Nomad-tsjinners, wêrnei't wy sille allinne fierder nei Nomad.

It ynstallearjen fan de ark fan HashiCorp is heul ienfâldich: yn essinsje ferpleatse wy it binêre bestân gewoan nei de bin-map, set it konfiguraasjetriem fan it ark op en meitsje it tsjinstbestân oan.

Download it Consul-binêre bestân en pak it út yn 'e thúsmap fan de brûker:

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/

No hawwe wy in klear makke konsul binêr foar fierdere konfiguraasje.

Om mei Consul te wurkjen, moatte wy in unike kaai meitsje mei it keygen kommando:

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

Litte wy trochgean mei it ynstellen fan de Consul-konfiguraasje, it meitsjen fan in map /etc/consul.d/ mei de folgjende struktuer:

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

De bootstrap-map sil in konfiguraasjetriem befetsje config.json - dêryn sille wy de Consul-ynstellingen ynstelle. Syn ynhâld:

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

Litte wy de wichtichste rjochtlinen en har betsjuttingen apart besjen:

  • bootstrap:wier. Wy skeakelje automatyske tafoeging fan nije knopen yn as se ferbûn binne. Ik konstatearje dat wy hjir it krekte oantal ferwachte knopen net oanjaan.
  • tsjinner:wier. Server modus ynskeakelje. Konsul op dizze firtuele masine sil op it stuit fungearje as de ienige tsjinner en master, Nomad's VM sil de kliïnten wêze.
  • datasintrum:dc1. Spesifisearje de namme fan it datasintrum om it kluster te meitsjen. It moat identyk wêze op sawol kliïnten as servers.
  • kodearje:dy-kaai. De kaai, dy't ek unyk wêze moat en oerienkomt op alle kliïnten en servers. Generearre mei help fan de konsul keygen kommando.
  • start_join. Yn dizze list jouwe wy in list oan mei IP-adressen wêrmei de ferbining makke wurde sil. Op dit stuit litte wy allinnich ús eigen adres efter.

Op dit punt kinne wy ​​​​konsul útfiere mei de kommandorigel:

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

Dit is in goede manier om no te debuggen, lykwols, jo kinne dizze metoade net trochgean om foar de hân lizzende redenen. Litte wy in tsjinstbestân oanmeitsje om Consul fia systemd te behearjen:

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

Ynhâld fan it consul.service-bestân: 

[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

Launch Consul fia systemctl:

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

Litte wy kontrolearje: ús tsjinst moat rinne, en troch it kommando fan konsulleden út te fieren soene wy ​​ús server moatte sjen:

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

Folgjende poadium: Nginx ynstallearje en proxying en http-autorisaasje ynstelle. Wy ynstallearje nginx fia de pakketbehearder en yn 'e /etc/nginx/sites-enabled map meitsje wy in konfiguraasjetriem consul.conf mei de folgjende ynhâld:

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

Ferjit net om in .htpasswd-bestân te meitsjen en dêr in brûkersnamme en wachtwurd foar te generearjen. Dit item is fereaske sadat it webpaniel net beskikber is foar elkenien dy't ús domein ken. By it ynstellen fan Gitlab sille wy dit lykwols moatte ferlitte - oars kinne wy ​​ús applikaasje net ynsette op Nomad. Yn myn projekt binne sawol Gitlab as Nomad allinich op it grize web, dus d'r is hjir gjin probleem.

Op de oerbleaune twa servers ynstallearje wy Consul-aginten neffens de folgjende ynstruksjes. Wy werhelje de stappen mei de binêre triem:

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/

Troch analogy mei de foarige tsjinner meitsje wy in map foar konfiguraasjebestannen /etc/consul.d mei de folgjende struktuer:

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

Ynhâld fan it config.json-bestân:

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

Bewarje de wizigingen en gean troch nei it ynstellen fan it tsjinstbestân, de ynhâld:

/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

Wy lansearje konsul op de tsjinner. No, nei lansearring, moatte wy de ynstelde tsjinst sjen yn nsul-leden. Dit sil betsjutte dat it mei súkses ferbûn is mei it kluster as kliïnt. Werhelje itselde op de twadde tsjinner en dêrnei kinne wy ​​begjinne mei it ynstallearjen en konfigurearjen fan Nomad.

Mear detaillearre ynstallaasje fan Nomad wurdt beskreaun yn syn offisjele dokumintaasje. D'r binne twa tradisjonele ynstallaasjemetoaden: it downloaden fan in binêre bestân en kompilearjen fan boarne. Ik sil de earste metoade kieze.

remark: It projekt ûntwikkelet heul fluch, nije updates wurde faak frijlitten. Miskien sil in nije ferzje wurde frijlitten tsjin 'e tiid dat dit artikel foltôge is. Dêrom advisearje ik foar it lêzen de hjoeddeistige ferzje fan Nomad op it stuit te kontrolearjen en it te downloaden. 

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

Nei it útpakken krije wy in Nomad-binêr bestân mei in gewicht fan 65 MB - it moat ferpleatst wurde nei /usr/local/bin.

Litte wy in gegevensmap foar Nomad oanmeitsje en syn tsjinstbestân bewurkje (it sil nei alle gedachten oan it begjin net bestean):

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

Plak dêr de folgjende rigels:

[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

Wy hawwe lykwols gjin haast om nomad te starten - wy hawwe syn konfiguraasjetriem noch net oanmakke:

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

De definitive mapstruktuer sil as folgjend wêze:

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

It nomad.hcl-bestân moat de folgjende konfiguraasje befetsje:

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

Ynhâld fan it server.hcl-bestân:

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
}

Ferjit net it konfiguraasjetriem op 'e twadde tsjinner te feroarjen - dêr moatte jo de wearde fan 'e http-rjochtline feroarje.

It lêste ding op dit poadium is om Nginx te konfigurearjen foar proxying en it ynstellen fan http-autorisaasje. Ynhâld fan it nomad.conf-bestân:

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

No kinne wy ​​tagong krije ta it webpaniel fia in ekstern netwurk. Ferbine en gean nei de serverside:

In Nomad-kluster ynstelle mei Consul en yntegrearje mei Gitlab
Ofbylding 1. List fan tsjinners yn it Nomad-kluster

Beide tsjinners wurde mei súkses werjûn yn it paniel, wy sille itselde ding sjen yn 'e útfier fan it kommando nomad node status:

In Nomad-kluster ynstelle mei Consul en yntegrearje mei Gitlab
Ofbylding 2. Utfier fan de nomad node status kommando

Hoe sit it mei konsul? Lit ús ris efkes sjen. Gean nei it Consul-kontrôlepaniel, nei de knooppunten-side:
In Nomad-kluster ynstelle mei Consul en yntegrearje mei Gitlab
Ofbylding 3. List fan knopen yn it Consul kluster

No hawwe wy in taret Nomad wurkjen yn gearhing mei Consul. Yn 'e lêste etappe komme wy ta it leuke diel: it ynstellen fan levering fan Docker-konteners fan Gitlab nei Nomad, en ek prate oer guon fan har oare ûnderskiedende funksjes.

Gitlab Runner oanmeitsje

Om docker-ôfbyldings nei Nomad yn te setten, sille wy in aparte runner brûke mei it Nomad-binêre bestân binnen (hjir kinne wy ​​trouwens in oare funksje fan Hashicorp-applikaasjes notearje - yndividueel binne se in inkeld binêr bestân). Upload it nei de runner-map. Litte wy in ienfâldige Dockerfile foar meitsje mei de folgjende ynhâld:


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

Yn itselde projekt meitsje wy .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 gefolch hawwe wy in beskikbere ôfbylding fan 'e Nomad runner yn' e Gitlab Registry, no kinne wy ​​​​direkt nei it projektrepository gean, in Pipeline oanmeitsje en Nomad's nomad job konfigurearje.

Projekt opset

Litte wy begjinne mei it bestân fan 'e baan foar Nomad. Myn projekt yn dit artikel sil frij primityf wêze: it sil bestean út ien taak. De ynhâld fan .gitlab-ci sil sa wêze:

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

Hjir bart de ynset mei de hân, mar jo kinne it ynstelle om de ynhâld fan 'e projektmap te feroarjen. Pipeline bestiet út twa stadia: ôfbylding gearstalling en syn ynset nei nomad. Op it earste poadium sammelje wy in dockerôfbylding en drukke it yn ús register, en yn 'e twadde lansearje wy ús baan yn 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" {}
                }
            }
        }
    }
}

Tink derom dat ik in privee registraasje haw en om in dockerôfbylding mei súkses te lûken, moat ik my oanmelde. De bêste oplossing yn dit gefal is om in oanmelding en wachtwurd yn Vault yn te fieren en it dan te yntegrearjen mei Nomad. Nomad stipet natuerlik Vault. Mar litte wy earst it nedige belied foar Nomad yn Vault sels ynstallearje; se kinne wurde downloade:

# 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

No, nei't wy it nedige belied makke hawwe, sille wy yntegraasje mei Vault tafoegje yn it taakblok yn it job.nomad-bestân:

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

Ik brûk autorisaasje troch token en registrearje it hjir direkt, d'r is ek de opsje om it token as in fariabele op te jaan by it starten fan nomad agent:

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

No kinne wy ​​​​de kaaien brûke mei Vault. It prinsipe fan wurking is ienfâldich: wy meitsje in bestân yn Nomad job dat de wearden fan fariabelen opslaan sil, bygelyks:

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
}

Mei dizze ienfâldige oanpak kinne jo de levering fan konteners oan it Nomad-kluster ynstelle en dêrmei wurkje yn 'e takomst. Ik sil sizze dat ik yn guon mjitte sympatisearje mei Nomad - it is mear gaadlik foar lytse projekten wêr't Kubernetes ekstra kompleksiteit kin feroarsaakje en har folsleine potensjeel net realisearje. Plus, Nomad is perfekt foar begjinners - it is maklik te ynstallearjen en te konfigurearjen. By it testen fan guon projekten kom ik lykwols in probleem tsjin mei har iere ferzjes - in protte basisfunksjes binne der gewoan net of se wurkje net goed. Ik leau lykwols dat Nomad sil trochgean te ûntwikkeljen en yn 'e takomst sil krije de funksjes dy't elkenien nedich.

Auteur: Ilya Andreev, bewurke troch Alexey Zhadan en it Live Linux-team


Boarne: www.habr.com

Add a comment