ProHoster > Blog > administratë > Krijimi i një grupi Nomad duke përdorur Consul dhe integrimi me Gitlab

Krijimi i një grupi Nomad duke përdorur Consul dhe integrimi me Gitlab

Paraqitje

Kohët e fundit, popullariteti i Kubernetes është rritur me shpejtësi - gjithnjë e më shumë projekte po e zbatojnë atë. Doja të prekja një orkestrues si Nomad: është perfekt për projektet që tashmë përdorin zgjidhje të tjera nga HashiCorp, për shembull, Vault dhe Consul, dhe vetë projektet nuk janë komplekse për sa i përket infrastrukturës. Ky material do të përmbajë udhëzime për instalimin e Nomad, kombinimin e dy nyjeve në një grup, si dhe integrimin e Nomad me Gitlab.

Krijimi i një grupi Nomad duke përdorur Consul dhe integrimi me Gitlab

Stand testimi

Pak për stolin e provës: përdoren tre serverë virtualë me karakteristikat e 2 CPU, 4 RAM, 50 Gb SSD, të bashkuar në një rrjet të përbashkët lokal. Emrat dhe adresat e tyre IP:

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

Instalimi i Nomad, Konsull. Krijimi i një grupi Nomad

Le të fillojmë me instalimin bazë. Edhe pse konfigurimi ishte i thjeshtë, unë do ta përshkruaj atë për hir të integritetit të artikullit: ai u krijua në thelb nga draftet dhe shënimet për qasje të shpejtë kur është e nevojshme.

Para se të fillojmë praktikën, do të diskutojmë pjesën teorike, sepse në këtë fazë është e rëndësishme të kuptojmë strukturën e ardhshme.

Ne kemi dy nyje nomade dhe duam t'i kombinojmë ato në një grup, dhe në të ardhmen do të kemi nevojë gjithashtu për shkallëzim automatik të grupimit - për këtë do të na duhet Konsulli. Me këtë mjet, grupimi dhe shtimi i nyjeve të reja bëhet një detyrë shumë e thjeshtë: nyja e krijuar Nomad lidhet me agjentin Consul dhe më pas lidhet me grupin ekzistues Nomad. Prandaj, në fillim do të instalojmë serverin Consul, do të konfigurojmë autorizimin bazë http për panelin në internet (është pa autorizim si parazgjedhje dhe mund të aksesohet në një adresë të jashtme), si dhe vetë agjentët e Konsullit në serverët Nomad, pas së cilës ne do të vazhdojmë vetëm në Nomad.

Instalimi i veglave të HashiCorp është shumë i thjeshtë: në thelb, ne thjesht e zhvendosim skedarin binar në drejtorinë e koshit, konfigurojmë skedarin e konfigurimit të mjetit dhe krijojmë skedarin e tij të shërbimit.

Shkarkoni skedarin binar të Konsullit dhe shpaketoni atë në drejtorinë kryesore të përdoruesit:

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/

Tani kemi një konsul binar të gatshëm për konfigurim të mëtejshëm.

Për të punuar me Konsullin, duhet të krijojmë një çelës unik duke përdorur komandën keygen:

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

Le të kalojmë në konfigurimin e konfigurimit të Konsullit, duke krijuar një direktori /etc/consul.d/ me strukturën e mëposhtme:

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

Drejtoria e bootstrap do të përmbajë një skedar konfigurimi config.json - në të do të vendosim cilësimet e Konsullit. Përmbajtja e tij:

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

Le të shohim veçmas direktivat kryesore dhe kuptimet e tyre:

  • bootstrap: e vertete. Ne mundësojmë shtimin automatik të nyjeve të reja nëse ato janë të lidhura. Unë vërej se ne nuk tregojmë këtu numrin e saktë të nyjeve të pritura.
  • server: e vertete. Aktivizo modalitetin e serverit. Konsulli në këtë makinë virtuale do të veprojë si serveri dhe masteri i vetëm për momentin, klienti do të jetë VM i Nomad.
  • Qendra e të dhënave: dc1. Specifikoni emrin e qendrës së të dhënave për të krijuar grupin. Duhet të jetë identik si në klientët ashtu edhe në serverë.
  • encrypt: çelësi juaj. Çelësi, i cili gjithashtu duhet të jetë unik dhe të përputhet me të gjithë klientët dhe serverët. Gjeneruar duke përdorur komandën e konsullit keygen.
  • start_join. Në këtë listë ne tregojmë një listë të adresave IP me të cilat do të bëhet lidhja. Për momentin ne lëmë vetëm adresën tonë.

Në këtë pikë ne mund të ekzekutojmë konsullin duke përdorur vijën e komandës:

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

Kjo është një mënyrë e mirë për të korrigjuar gabimet tani, megjithatë, nuk do të jeni në gjendje ta përdorni këtë metodë në mënyrë të vazhdueshme për arsye të dukshme. Le të krijojmë një skedar shërbimi për të menaxhuar Konsullin përmes systemd:

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

Përmbajtja e dosjes consul.service: 

[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

Nisni Konsullin përmes systemctl:

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

Le të kontrollojmë: shërbimi ynë duhet të funksionojë dhe duke ekzekutuar komandën e anëtarëve të konsullit, ne duhet të shohim serverin tonë:

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

Faza tjetër: instalimi i Nginx dhe konfigurimi i proxying dhe autorizimit http. Ne instalojmë nginx përmes menaxherit të paketave dhe në drejtorinë /etc/nginx/sites-enabled krijojmë një skedar konfigurimi consul.conf me përmbajtjen e mëposhtme:

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

Mos harroni të krijoni një skedar .htpasswd dhe të krijoni një emër përdoruesi dhe fjalëkalim për të. Ky artikull kërkohet në mënyrë që paneli i uebit të mos jetë i disponueshëm për të gjithë ata që e njohin domenin tonë. Sidoqoftë, kur konfigurojmë Gitlab, do të duhet ta braktisim këtë - përndryshe nuk do të jemi në gjendje ta vendosim aplikacionin tonë në Nomad. Në projektin tim, si Gitlab ashtu edhe Nomad janë vetëm në rrjetin gri, kështu që nuk ka asnjë problem të tillë këtu.

Në dy serverët e mbetur ne instalojmë agjentët e konsullit sipas udhëzimeve të mëposhtme. Ne përsërisim hapat me skedarin binar:

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ër analogji me serverin e mëparshëm, ne krijojmë një direktori për skedarët e konfigurimit /etc/consul.d me strukturën e mëposhtme:

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

Përmbajtja e skedarit config.json:

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

Ruani ndryshimet dhe vazhdoni te konfiguroni skedarin e shërbimit, përmbajtjen e tij:

/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

Ne lëshojmë konsullin në server. Tani, pas nisjes, ne duhet të shohim shërbimin e konfiguruar në anëtarët nsul. Kjo do të thotë që ai është lidhur me sukses me grupin si klient. Përsëriteni të njëjtën gjë në serverin e dytë dhe pas kësaj ne mund të fillojmë instalimin dhe konfigurimin e Nomad.

Instalimi më i detajuar i Nomad përshkruhet në dokumentacionin e tij zyrtar. Ekzistojnë dy metoda tradicionale të instalimit: shkarkimi i një skedari binar dhe përpilimi nga burimi. Unë do të zgjedh metodën e parë.

Shënim: Projekti po zhvillohet shumë shpejt, shpesh lëshohen përditësime të reja. Ndoshta një version i ri do të dalë në kohën kur të përfundojë ky artikull. Prandaj, para se të lexoni, unë rekomandoj të kontrolloni versionin aktual të Nomad për momentin dhe ta shkarkoni atë. 

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

Pas shpaketimit, do të marrim një skedar binar Nomad me peshë 65 MB - ai duhet të zhvendoset në /usr/local/bin.

Le të krijojmë një direktori të dhënash për Nomad dhe të modifikojmë skedarin e shërbimit të tij (ka shumë të ngjarë që nuk do të ekzistojë në fillim):

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

Ngjitni rreshtat e mëposhtëm atje:

[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

Sidoqoftë, ne nuk jemi me nxitim për të nisur nomad - ne nuk kemi krijuar ende skedarin e tij të konfigurimit:

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

Struktura përfundimtare e drejtorisë do të jetë si më poshtë:

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

Skedari nomad.hcl duhet të përmbajë konfigurimin e mëposhtëm:

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

Përmbajtja e skedarit server.hcl:

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
}

Mos harroni të ndryshoni skedarin e konfigurimit në serverin e dytë - atje do t'ju duhet të ndryshoni vlerën e direktivës http.

Gjëja e fundit në këtë fazë është konfigurimi i Nginx për proxying dhe konfigurimin e autorizimit http. Përmbajtja e skedarit nomad.conf:

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

Tani mund të hyjmë në panelin e uebit përmes një rrjeti të jashtëm. Lidhu dhe shko te faqja e serverëve:

Krijimi i një grupi Nomad duke përdorur Consul dhe integrimi me Gitlab
Imazhi 1. Lista e serverëve në grupin Nomad

Të dy serverët shfaqen me sukses në panel, do të shohim të njëjtën gjë në daljen e komandës së statusit të nyjes nomad:

Krijimi i një grupi Nomad duke përdorur Consul dhe integrimi me Gitlab
Imazhi 2. Dalja e komandës së statusit të nyjës nomad

Po konsulli? Le të hedhim një vështrim. Shkoni te paneli i kontrollit të Konsullit, në faqen e nyjeve:
Krijimi i një grupi Nomad duke përdorur Consul dhe integrimi me Gitlab
Imazhi 3. Lista e nyjeve në grupin e Konsullit

Tani kemi një Nomad të përgatitur që punon në bashkëpunim me Konsullin. Në fazën përfundimtare, do të arrijmë te pjesa argëtuese: vendosja e shpërndarjes së kontejnerëve Docker nga Gitlab në Nomad, dhe gjithashtu duke folur për disa nga veçoritë e tjera dalluese të tij.

Krijimi i Gitlab Runner

Për të vendosur imazhe docker në Nomad, ne do të përdorim një vrapues të veçantë me skedarin binar Nomad brenda (këtu, meqë ra fjala, mund të vërejmë një veçori tjetër të aplikacioneve Hashicorp - individualisht ato janë një skedar i vetëm binar). Ngarkoni atë në direktorinë e runner. Le të krijojmë një Dockerfile të thjeshtë për të me përmbajtjen e mëposhtme:


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

Në të njëjtin projekt ne krijojmë .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}

Si rezultat, ne do të kemi një imazh të disponueshëm të vrapuesit Nomad në Regjistrin Gitlab, tani mund të shkojmë drejtpërdrejt te depoja e projektit, të krijojmë një Pipeline dhe të konfigurojmë punën nomad të Nomad.

Vendosja e projektit

Le të fillojmë me dosjen e punës për Nomad. Projekti im në këtë artikull do të jetë mjaft primitiv: do të përbëhet nga një detyrë. Përmbajtja e .gitlab-ci do të jetë si më poshtë:

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

Këtu vendosja ndodh manualisht, por ju mund ta konfiguroni atë për të ndryshuar përmbajtjen e drejtorisë së projektit. Tubacioni përbëhet nga dy faza: montimi i imazhit dhe vendosja e tij në nomad. Në fazën e parë, ne mbledhim një imazh docker dhe e futim atë në Regjistrin tonë, dhe në të dytën nisim punën tonë në 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" {}
                }
            }
        }
    }
}

Ju lutemi vini re se unë kam një Regjistr privat dhe për të tërhequr me sukses një imazh doker, duhet të identifikohem në të. Zgjidhja më e mirë në këtë rast është të futni një hyrje dhe fjalëkalim në Vault dhe më pas ta integroni atë me Nomad. Nomad mbështet nga natyra Vault. Por së pari, le të instalojmë politikat e nevojshme për Nomad në vetë Vault; ato mund të shkarkohen:

# 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

Tani, pasi kemi krijuar politikat e nevojshme, ne do të shtojmë integrimin me Vault në bllokun e detyrave në skedarin job.nomad:

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

Unë përdor autorizimin me shenjë dhe e regjistroj atë direkt këtu, ekziston gjithashtu opsioni i specifikimit të tokenit si një variabël kur filloni agjentin nomad:

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

Tani mund të përdorim çelësat me Vault. Parimi i funksionimit është i thjeshtë: ne krijojmë një skedar në punën Nomad që do të ruajë vlerat e variablave, për shembull:

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
}

Me këtë qasje të thjeshtë, ju mund të konfiguroni dërgimin e kontejnerëve në grupin Nomad dhe të punoni me të në të ardhmen. Unë do të them që në një farë mase unë simpatizoj Nomad - është më i përshtatshëm për projekte të vogla ku Kubernetes mund të shkaktojë kompleksitet shtesë dhe nuk do të realizojë potencialin e tij të plotë. Plus, Nomad është perfekt për fillestarët—është e lehtë për t'u instaluar dhe konfiguruar. Sidoqoftë, kur testoj në disa projekte, has një problem me versionet e tij të hershme - shumë funksione themelore thjesht nuk janë aty ose nuk funksionojnë siç duhet. Megjithatë, besoj se Nomad do të vazhdojë të zhvillohet dhe në të ardhmen do të marrë funksionet që i duhen të gjithëve.

Autori: Ilya Andreev, redaktuar nga Alexey Zhadan dhe ekipi Live Linux


Burimi: www.habr.com

Shto një koment