ProHoster > Blog > Administrim > Konfigurimi i klasterit Nomad me ndihmën e Consul dhe integrimi me Gitlab

Konfigurimi i klasterit Nomad me ndihmën e Consul dhe integrimi me Gitlab

Hyrje

Koha e fundit, popullariteti i Kubernetes Ă«shtĂ« duke u rritur shpejt — gjithnjĂ« e mĂ« shumĂ« projekte po e pĂ«rfshijnĂ« atĂ«. UnĂ« do tĂ« doja tĂ« preka njĂ« orkestrator tjetĂ«r, si Nomad: ai Ă«shtĂ« perfekt pĂ«r projektet qĂ« tashmĂ« pĂ«rdorin zgjidhje tĂ« tjera nga HashiCorp, siç janĂ« Vault dhe Consul, dhe projekti vetĂ« nuk Ă«shtĂ« kompleks nĂ« aspektin e infrastrukturĂ«s. Ky material do tĂ« ofrojĂ« njĂ« udhĂ«zues pĂ«r instalimin e Nomad, bashkimin e dy nodave nĂ« njĂ« klaster, dhe integrimin e Nomad me GitLab.

Konfigurimi i klasterit Nomad me ndihmën e Consul dhe integrimi me Gitlab

Standi i testimit

Pak fjalë rreth skenës së testimit: përdoren tre serverë virtualë me karakteristika 2 CPU, 4 RAM, 50 Gb SSD, të lidhur në një rrjet lokal të përbashkët. Emrat dhe IP adresat e tyre janë:

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

Instalimi i Nomad dhe Consul. Krijimi i klasterit Nomad.

Të fillojmë me instalimin bazik. Pavarësisht thjeshtësisë së instalimit, unë do ta përshkruaj atë për të siguruar integritetin e artikullit: në thelb, ajo është krijuar nga draft dhe shënime për qasje të shpejtë në rast nevoje.

Para se të kalojmë në praktikë, le të diskutojmë pjesën teorike, sepse në këtë fazë është e rëndësishme të kuptohet struktura e ardhshme.

Ne kemi dy nodĂ« Nomad dhe duam t'i bashkojmĂ« ato nĂ« njĂ« klaster, gjithashtu pĂ«r tĂ« ardhmen do tĂ« na nevojitet njĂ« pĂ«rmasim automatik i klasterit — pĂ«r kĂ«tĂ« na duhen Consul. Me kĂ«tĂ« mjet, klasterizimi dhe shtimi i nodave tĂ« reja bĂ«het njĂ« detyrĂ« shumĂ« e lehtĂ«: nodja e krijuar Nomad lidhet me agjentin Consul, pastaj ajo lidhet me klasterin ekzistues Nomad. Prandaj, nĂ« fillim do tĂ« instalojmĂ« serverin Consul, do tĂ« konfigurojmĂ« autorizimin bazik http pĂ«r panelin e uebit (ai Ă«shtĂ« pa autorizim sipas parazgjedhjes dhe mund tĂ« jetĂ« i aksesueshĂ«m nga njĂ« adresĂ« e jashtme), si dhe agjentĂ«t Consul nĂ« serverĂ«t Nomad, pas sĂ« cilĂ«s do tĂ« fillojmĂ« me Nomad.

Instalimi i mjeteve të HashiCorp është shumë i thjeshtë: në thelb, ne vetëm transferojmë skedarin binar në direktorinë bin, konfiguroni skedarin e konfigurimit të mjetit dhe krijojmë skedarin e shërbimit të tij.

Shkarkojmë skedarin binar të Consul dhe e shpërndajmë atë në direktorine e 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 skedarin binar të gatshëm të consul për konfigurimin e mëtejshëm.

Për të punuar me Consul, na nevojitet të krijojmë një çelës unik me komandën keygen:

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

Të kalojmë në konfigurimin e Consul, krijojmë drejtorinë /etc/consul.d/ me strukturën e mëposhtme:

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

NĂ« drejtorinĂ« bootstrap do tĂ« gjendet skedari i konfigurimit config.json — kĂ«tu do tĂ« vendosim parametrat e Consul-it. 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"]
}

Të analizojmë veçmas direktivat kryesore dhe vlerat e tyre:

  • bootstrap: true. AktivizojmĂ« shtimin automatik tĂ« nyjave tĂ« reja nĂ« rast se ato lidhen. Theksoj se nuk e caktuam kĂ«tu numrin e saktĂ« tĂ« nyjave tĂ« pritshme.
  • server: true. AktivizojmĂ« modin e serverit. Consul do tĂ« funksionojĂ« nĂ« kĂ«tĂ« makinĂ« virtuale si serveri i vetĂ«m dhe masteri, ndĂ«rsa VM-ja e Nomad do tĂ« jetĂ« klient.
  • datacenter: dc1. ShĂ«nojmĂ« emrin e qendrĂ«s sĂ« tĂ« dhĂ«nave pĂ«r krijimin e klasterit. Ai duhet tĂ« jetĂ« identik si nĂ« klientĂ«t, ashtu edhe nĂ« serverat.
  • encrypt: your-key. ÇelĂ«si, i cili gjithashtu duhet tĂ« jetĂ« unik dhe tĂ« pĂ«rputhet nĂ« tĂ« gjitha klientĂ«t dhe serverat. Gjenerohet duke pĂ«rdorur komandĂ«n consul keygen.
  • start_join. NĂ« kĂ«tĂ« listĂ« shĂ«nojmĂ« adresat IP me tĂ« cilat do tĂ« lidhemi. PĂ«r momentin, lĂ«mĂ« vetĂ«m adresĂ«n tonĂ«.

Në këtë fazë, mund të nisim consul përmes komandës:

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

Ky është një mënyrë e mirë për diagnozë tani, megjithatë, nuk do të mund ta përdorim këtë mënyrë në përhershmëri për arsye të dukshme. Krijojmë një skedar shërbimi për menaxhimin e Consul përmes systemd:

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

PĂ«rmbajtja e skedarit consul.service:

[Unit]
Description=Procesi i nisjes së Consul
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

Nisim Consul përmes systemctl:

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

Kontrollojmë: shërbimi ynë duhet të jetë i nisur, dhe duke ekzekutuar komandën consul members 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

Hapi tjetër: instalimi i Nginx dhe konfigurimi i proksimit, autorizimit http. Instalojmë nginx përmes menaxherit të paketave dhe në drejtorinë /etc/nginx/sites-enabled krijojmë skedarin e konfigurimit consul.conf me përmbajtjen e mëposhtme:

upstream consul-auth {
    server localhost:8500;
}

server {

    server_name consul.domain.name;
    
    location / {
      proxy_pass http://consul-auth;
      proxy_set_header Host $host;
      auth_basic_user_file /etc/nginx/.htpasswd;
      auth_basic "Zona e Mbrojtur me Fjalëkalim";
    }
}

Mos mirĂ« qĂ« tĂ« krijoni skedarin .htpasswd dhe tĂ« gjeneroni njĂ« emĂ«r pĂ«rdoruesi dhe fjalĂ«kalim pĂ«r tĂ«. Ky hap kĂ«rkohet qĂ« paneli i uebit tĂ« mos jetĂ« i aksesueshĂ«m nga kushdo qĂ« e di domenin tonĂ«. MegjithatĂ«, gjatĂ« konfigurimit tĂ« Gitlab do tĂ« duhet ta heqim kĂ«tĂ« hap — pĂ«rndryshe nuk do tĂ« mundim ta depozitojmĂ« aplikacionin tonĂ« nĂ« Nomad. NĂ« projektin tim, si Gitlab ashtu edhe Nomad ndodhen vetĂ«m nĂ« rrjetin e errĂ«t, kĂ«shtu qĂ« kĂ«tu nuk ka njĂ« problem tĂ« tillĂ«.

Në dy serverat e tjerë instalojmë agjentët e Consul sipas kësaj udhëzimi. Përsërisim veprimet 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 krijojmë një direktori për skedaret e konfigurimit /etc/consul.d me këtë strukturë:

/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", # adresa lokale VM
    "start_join": ["172.30.0.15"], # adresa e largët e serverit consul
    "ports": {
      "dns": 53
     }

Ruajmë ndryshimet dhe kalojmë në konfigurimin e skedarit të shërbimit, përmbajtja e tij:

/etc/systemd/system/consul.service:

[Unit]
Description="HashiCorp Consul - Një zgjidhje për shërbimet e rrjeteve"
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

Nisim consul në server. Tani, pas nisjes ne duhet të shohim shërbimin e konfiguruar në nsul members. Kjo do të thotë se ai është lidhur me klasterin si klient. Përsërisni të njëjtën gjë në serverin e dytë dhe pas kësaj mund të fillojmë instalimin dhe konfigurimin e Nomad.

Instalimi më i detajuar i Nomad përshkruhet në dokumentacionin e tij zyrtar. Ka dy mënyra tradicionale për instalim: shkarkimi i skedarit binar dhe kompaktimi nga burimet. Unë do të zgjedh mënyrën e parë.

Shënim: projekti zhvillohet shumë shpejt, shpesh dalin përditësime të reja. Mundësisht, deri në përfundimin e artikullit do të dalë një version i ri. Prandaj, rekomandoj që para leximit të kontrolloni versionin aktual të Nomad në këtë moment 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 pastrimit, do tĂ« kemi njĂ« skedar binar Nomad me njĂ« madhĂ«si prej 65 MB — ai duhet tĂ« zhvendoset nĂ« /usr/local/bin.

Do të krijojmë një direktori data për Nomad dhe do të redaktojmë skedarin e tij të shërbimit (mund të mos ekzistojë në fillim):

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

Insertoni aty rreshtat në vijim:

[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

MegjithatĂ«, nuk shpejton tĂ« nisni nomad — ende nuk e kemi krijuar 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 direktorisë do të jetë si në vijim:

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

Skedari nomad.hcl duhet të përmbajë konfigurimin në vijim:

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Ă« duhet tĂ« ndryshoni vlerĂ«n e drejtorisĂ« http.

E fundit në këtë etapë është konfigurimi i Nginx për prokisarjen dhe vendosjen 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 "Zona e mbrojtur me fjalëkalim";
        }
        
}

Tani mund të aksesojmë panelin e uebit përmes rrjetit të jashtëm. Lidhemi dhe kalojmë në faqen e serverave:

Konfigurimi i klasterit Nomad me ndihmën e Consul dhe integrimi me Gitlab
Imazhi 1. Lista e serverave në klasterin Nomad

Të dy serverat shfaqen me sukses në panel, gjithashtu do ta shohim këtë në rezultatin e komandës nomad node status:

Konfigurimi i klasterit Nomad me ndihmën e Consul dhe integrimi me Gitlab
Imazhi 2. Rezultati i komandës nomad node status

ÇfarĂ« ndodh nga ana e Consul? Le tĂ« shohim. KalojmĂ« nĂ« panelin e administratĂ«s Consul, nĂ« faqen e nodes:
Konfigurimi i klasterit Nomad me ndihmën e Consul dhe integrimi me Gitlab
Imazhi 3. Lista e nodave në klasterin Consul

Tani tani na një Nomad të përgatitur, i cili punon në lidhje me Consul. Në fazën përfundimtare, do të fillojmë me atë që është më interesante: do të konfigurojmë dërgimin e konteinerëve Docker nga Gitlab në Nomad, si dhe do të diskutojmë rreth disa veçorive të tjera dalluese të tij.

Krijimi i Gitlab Runner

Për të bërë deploy të imazheve docker në Nomad, do të përdorim një runner të veçantë me skedarin binar të Nomad brenda (për këtë, mund të përmendim edhe një veçori tjetër të aplikacioneve Hashicorp - ato paraqesin një skedar binar të vetëm). Ngarkoje atë në direktorinë e runner-it. Për të, do të krijojmë një Dockerfile të thjeshtë 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ë këtë projekt 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}

Sipas përfundimit, do të kemi një imazh të disponueshëm të Nomad runner në Gitlab Registry, tani mund të kalojmë direkt në repository-n e projektit, të krijojmë Pipeline dhe të konfigurojmë punën Nomad në Nomad.

Konfigurimi i projektit

Të fillojmë me skedarin e punës për Nomad. Projekti im në këtë artikull do të jetë mjaft primitv: 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}'  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, deploy-i ndodh në modalitetin manual, por mund ta konfiguroni atë për të ndryshuar përmbajtjen e direktorisë së projektit. Pipeline përbëhet nga dy etapa: ndërtimi i imazhit dhe deploy-i i tij në Nomad. Në etapën e parë, ne ndërtuam imazhin docker dhe e pushuam atë në Registry-n tonë, ndërsa në etapën e dytë, ekzekutojmë punën tonë në Nomad.

puna "monitoring-status" {
    qendrat = ["dc1"]
    migroj {
        max_paralel = 3
        kontrolli_i_shëndetit = "checks"
        kohe_min_shëndetësor = "15s"
        afati_shëndetësor = "5m"
    }

    grupi "zhadan.ltd" {
        numri = 1
        përditëso {
            max_paralel      = 1
            kohe_min_shëndetësor  = "30s"
            afati_shëndetësor  = "5m"
            afati_progressit = "10m"
            auto_rivendosje       = true
        }
        detyra "monitorimi-i-shërbimeve" {
            drejtuesi = "docker"

            konfigurimi {
                imazhi = "registry.domain.name/example/project:${CI_COMMIT_SHORT_SHA}"
                force_pull = true
                autentifikimi {
                    emri_i_perdoruesit = "gitlab_user"
                    fjala_kalimi = "gitlab_password"
                }
                harta_e_portit {
                    http = 8000
                }
            }
            burimet {
                rrjeti {
                    porti "http" {}
                }
            }
        }
    }
}

Ju lutem vini re se kam një Registry të mbyllur dhe për të tërhequr me sukses imazhin docker duhet të autentohem në të. Zgjidhja më e mirë në këtë rast është shkrimi i emrit të përdoruesit dhe fjalëkalimit në Vault dhe më pas integrimi i tij me Nomad. Nomad mbështet native Vault. Por për fillim, le të vendosim politikat e nevojshme për Nomad në vetë Vault, të cilat mund t'i ngarkojmë:

# 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 krijuam politikat e nevojshme, ne do të shtojmë integrimin me Vault në bllokun detyra në skedarin job.nomad:

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

Unë përdor autorizimin me token dhe e shkruaj atë këtu, gjithashtu ka njëopsion për të specifikuar tokenin si një ndryshore gjatë nisjes së agjentit nomad:

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

Tani mund të përdorim çelësat nga Vault. Parimi i punës është i thjeshtë: krijojmë një skedar në punën Nomad, i cili do të ruajë vlerat e ndryshoreve, p.sh.:

template {
                data = <<EOH
{{with secret "secrets/pipeline-keys"}}
REGISTRY_LOGIN="{{ .Data.REGISTRY_LOGIN }}"
REGISTRY_PASSWORD="{{ .Data.REGISTRY_PASSWORD }}{{ end }}"

EOH
    destination = "secrets/service-name.env"
    env = true
}

NĂ« kĂ«tĂ« mĂ«nyrĂ«, mund tĂ« konfiguroni lehtĂ«sisht dĂ«rgimin e kontejnerĂ«ve nĂ« klasterin Nomad dhe tĂ« punoni me tĂ« nĂ« tĂ« ardhmen. UnĂ« mund tĂ« them se nĂ« njĂ« farĂ« mĂ«nyre mĂ« pĂ«lqen Nomad — ai Ă«shtĂ« mĂ« i pĂ«rshtatshĂ«m pĂ«r projekte tĂ« vogla, ku Kubernetes mund tĂ« shkaktojĂ« vĂ«shtirĂ«si tĂ« mĂ«tejshme dhe nuk do tĂ« realizojĂ« potencialin e tij plotĂ«sisht. PĂ«r mĂ« tepĂ«r, Nomad Ă«shtĂ« ideal pĂ«r fillestarĂ«t — Ă«shtĂ« lehtĂ« pĂ«r tu instaluar dhe konfiguruar. MegjithatĂ«, gjatĂ« testimit nĂ« disa projekte, kam hasur nĂ« probleme me versionet e tij tĂ« hershme — shumĂ« funksione bazĂ« thjesht nuk ekzistojnĂ« ose punojnĂ« nĂ« mĂ«nyrĂ« tĂ« pasaktĂ«. MegjithatĂ«, besoj se Nomad do tĂ« vazhdojĂ« tĂ« zhvillohet dhe nĂ« tĂ« ardhmen do tĂ« pasurohet me funksionet e nevojshme pĂ«r tĂ« gjithĂ«.

Autori: Ilya Andreyev, nën redaktimin e Alexey Zhadan dhe ekipit «Live Linux»


Burimi: habr.com

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster