ProHoster > Blog > Administrimi > Konfigurimi i klasterit Nomad me Consul dhe integrimi me Gitlab

Konfigurimi i klasterit Nomad me Consul dhe integrimi me Gitlab

Hyrje

Në kohët e fundit, popullariteti i Kubernetes po rritet me shpejtësi - gjithnjë e më shumë projekte po e implementojnë atë. Unë do të doja të preka një orkestrator të caktuar, siç është Nomad: ai është ideal për projekte ku tashmë përdoren zgjidhje të tjera nga kompania HashiCorp, të tilla si Vault dhe Consul, ndërsa vetë projektet nuk janë të ndërlikuara në aspektin e infrastrukturës. Në këtë material do të ofrohet një udhëzim për instalimin e Nomad-it, bashkimin e dy nodave në një klaster dhe integrimin e Nomad me Gitlab.

Konfigurimi i klasterit Nomad me Consul dhe integrimi me Gitlab

Njësia e testimit

Pak fjalë rreth strukturës së testimit: përdoren tre serverë virtualë me karakteristika 2 CPU, 4 RAM, 50 Gb SSD, të bashkuar në një rrjet lokal të përbashkët. Emrat e tyre dhe adresat IP 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, Consul. Krijimi i klasterit Nomad

Le të fillojmë me instalimin bazë. Pavarësisht se instalimi është i thjeshtë, do ta përshkruaj atë për të ruajtur koherencën e artikullit: në thelb, ai u krijua nga skica 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ë të Nomad dhe dëshirojmë t'i bashkojmë ato në një klaster; gjithashtu në të ardhmen do na nevojitet një skailing automatik i klasterit - për këtë na nevojitet Consul. Me ndihmën e këtij instrumenti, klasterizimi dhe shtimi i nodave të reja bëhet një detyrë shumë e thjeshtë: nodi i krijuar i Nomad lidhet me agjentin Consul, pas së cilës lidhet me klasterin ekzistues të Nomad-it. Prandaj, në fillim do të instalojmë serverin Consul, do të konfigurojmë autorizimin bazë http për panelin e uebit (ai është pa autorizim nga default dhe mund të jetë i aksesueshëm në adresën ekstern), si dhe agjentët e Consul në serverat e Nomad, pas së cilës do të kalojmë në Nomad.

Instalimi i mjeteve të kompanisë HashiCorp është shumë i thjeshtë: në thelb, ne thjesht lëvizim skedarin binar në direktoriumin bin, konfigurojmë skedarin e konfigurimit të mjetit dhe krijojmë skedarin e shërbimit të tij.

Shkarkojmë skedarin binar të Consul dhe e shpërndajmë në direktoriumin e shtëpisë së 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ë skedar 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

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

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

Në direktoriumin bootstrap do të ndodhet skedari i konfigurimit config.json - në të ne do të vendosim konfigurimet për Consul. 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ë shqyrtojmë një nga një direktivat kryesore dhe vlerat e tyre:

  • bootstrap: true. AktivizojmĂ« shtimin automatik tĂ« nodave tĂ« reja kur ato lidhen. Do tĂ« theksoj se kĂ«tu nuk e japim numrin e saktĂ« tĂ« nodave tĂ« pritura.
  • server: true. AktivizojmĂ« modin e serverit. Consul nĂ« kĂ«tĂ« makinĂ« virtuale do tĂ« veprojĂ« pĂ«r momentin si serveri dhe masteri i vetĂ«m, ndĂ«rsa makinat virtuale tĂ« Nomad do tĂ« jenĂ« klientĂ«.
  • datacenter: dc1. Vendosim emrin e qendrĂ«s sĂ« tĂ« dhĂ«nave pĂ«r krijimin e klasterit. Ai duhet tĂ« jetĂ« identik si te klientĂ«t ashtu edhe te serverĂ«t.
  • encrypt: your-key. ÇelĂ«si, i cili gjithashtu duhet tĂ« jetĂ« unik dhe tĂ« pĂ«rputhet nĂ« tĂ« gjitha klientĂ«t dhe serverĂ«t. Krijohet me komandĂ«n consul keygen.
  • start_join. NĂ« kĂ«tĂ« listĂ« vendosim adresat IP tĂ« tĂ« cilĂ«ve do tĂ« bĂ«het lidhja. NĂ« kĂ«tĂ« moment, ne do tĂ« lĂ«mĂ« vetĂ«m adresĂ«n tonĂ«.

Në këtë fazë mund ta fillojmë consul duke përdorur komandën e linjë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 debug, megjithatë, nuk do të mund ta përdorim këtë mënyrë në përherë për arsye të dukshme. Le të 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=Processi 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ë aktiv, dhe duke ekzekutuar komandën consul members 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

Hapi tjetër: instalimi i Nginx dhe konfigurimi i proxy-t, autorizimit http. Instalojmë nginx përmes menaxherit të paketave dhe në direktoriumin /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.doman.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 u rëndoni të krijoni një skedarin .htpasswd dhe të gjeneroni emrin e përdoruesit dhe fjalëkalimin për të. Ky hap është i nevojshëm që paneli i uebit të mos jetë i arritshëm për këdo që di domenin tonë. Megjithatë, gjatë konfigurimit të Gitlab, do të na duhet ta heqim këtë kërkesë - përndryshe nuk do të mund të depolojmë aplikacionin tonë në Nomad. Në projektin tim, si Gitlab ashtu edhe Nomad ndodhen vetëm në rrjetin e brendshëm, kështu që ky problem nuk ekziston këtu.

Në dy serverët e tjerë vendosim agjentët e Consul sipas këtij 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 të njëjtin server krijojmë një direktor për skedarët e konfigurimit /etc/consul.d me këtë strukturë:

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

KĂ« Contents of the file 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 e VM
    "start_join": ["172.30.0.15"], # adresa e largët e serverit consul
    "ports": {
      "dns": 53
     }

Ruani ndryshimet dhe kaloni në konfigurimin e skedarit të shërbimit, përmbajtja e tij:

/etc/systemd/system/consul.service:

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

Nisni consul në server. Tani, pas nisjes, ne duhet të shohim shërbimin e vendosur në nsul members. Kjo do të thotë se ai është lidhur me sukses me klasterin si klient. Përsëritni 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 është përshkruar 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 po zhvillohet shumë shpejt, shpesh dalin përditësime të reja. Ka gjasa që në momentin e përfundimit të artikullit të dalë një version i ri. Prandaj, rekomandoj të kontrolloni versionin aktual të Nomad para leximit 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 shkarkimit, do të marrim një skedar binar të Nomad që ka 65 MB - ky duhet të transferohet në /usr/local/bin.

Krijojmë një direktor data për Nomad dhe redaktojmë skedarin e tij të shërbimit (ndoshta nuk do të ekzistojë në fillim):

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

Shtoni këto rreshta:

[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 nxitohemi të nisim nomad - ende nuk 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 direktorive do të jetë si më poshtë:

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

Skedari nomad.hcl duhet të përmbajë këtë konfigurim:

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 e harroni të ndryshoni skedarin e konfigurimit në serverin e dytë - do të duhet të ndryshoni vlerën e direktivës http.

Në këtë fazë të fundit mbetet konfigurimi i Nginx për proxy dhe vendosja 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ë qasje në panelin e uebit përmes rrjetit të jashtëm. Lidheni dhe kaloni në faqen e serverëve:

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

Të dy serverët shfaqen me sukses në panel, po ashtu do të shohim në daljen e komandës nomad node status:

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

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

Tani tani tani tani tani tani tani tani tani tani tani tani tani tani tani tani tani tani tani tani tani tani tani tani tani tani tani tani tani tani tani tani tani tani tani tani tani tani tani tani tani tani tani tani tani tani tani tani tani tani tani tani tani

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 (kĂ«tu, pĂ«r tĂ« vĂ«rejtur njĂ« tjetĂ«r veçori tĂ« aplikacioneve Hashicorp — ato pĂ«rfaqĂ«sojnĂ« njĂ« skedar binar tĂ« vetĂ«m pĂ«rveçse). Shkarko 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:
  - ndërtim

ndërtim:
  stage: ndërtim
  image: ${DOCKER_REGISTRY}/nomad/alpine:3
  script:
    - tag=${DOCKER_REGISTRY}/${DOCKER_IMAGE}:latest
    - docker build --pull -t ${tag} -f Dockerfile .
    - docker push ${tag}

Në përfundim, do të kemi një imazh të disponueshëm të runner-it Nomad në Gitlab Registry, tani mund të kalojmë direkt në depozitën e projektit, të krijojmë Pipeline dhe të Konfigurojmë punën nomad të Nomad.

Konfigurimi i projektit

Le të fillojmë me skedarin e punës për Nomad. Projekti im në këtë artikull do të jetë mjaft i thjeshtë: 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:
  - ndërtim
  - deploy

ndërtim:
  stage: ndërtim
  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 "sukses"; fi
    - nomad run job.nomad
  environment:
    name: prodhim
  allow_failure: false
  when: manual

Këtu deploy ndodh në mënyrë manuale, por mund ta konfiguroni për të ndryshuar përmbajtjen e direktorive të projektit. Pipeline përbëhet nga dy faza: ndërtimi i imazhit dhe deploy i tij në nomad. Në fazën e parë ne ndërtojmë imazhin docker dhe e dërgojmë atë në Registry tonë, ndërsa në fazën e dytë, startojmë 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" {}
                }
            }
        }
    }
}

Kujtoni, qĂ« kam njĂ« Registry tĂ« mbyllur dhe pĂ«r tĂ« bĂ«rĂ« njĂ« pull tĂ« suksesshĂ«m tĂ« imazhit docker, duhet tĂ« autentikohem nĂ« tĂ«. Zgjidhja mĂ« e mirĂ« nĂ« kĂ«tĂ« rast Ă«shtĂ« tĂ« vendosni pĂ«rdoruesin dhe fjalĂ«kalimin nĂ« Vault me integrimin pasues me Nomad. Nomad natyrshĂ«m mbĂ«shtet Vault. Por, pĂ«r fillim, nĂ« vetĂ« Vault do tĂ« vendosim politikat e nevojshme pĂ«r Nomad, tĂ« cilat mund t’i ngarkoni:

# 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, në bllokun e detyrës në skedarin job.nomad do të shtojmë integrimin me Vault:

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

Përdorim autentifikimin me token dhe e shkruajmë atë direkt këtu, gjithashtu ka mundësi të specifikoni token-in si një variabël kur startoni agent-in nomad:

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

Tani mund të përdorim çelësat nga Vault. Parimi i funksionimit është i thjeshtë: ne krijojmë një skedar në punën Nomad, i cili do të mbajë 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Ă« mund tĂ« konfigurojmĂ« dĂ«rgimin e konteinerĂ«ve nĂ« klasterin Nomad dhe tĂ« punojmĂ« me tĂ« nĂ« tĂ« ardhmen. UnĂ« do tĂ« them se nĂ« njĂ« farĂ« mĂ«nyre e simpatizoj Nomad — ai pĂ«rshtatet mĂ« mirĂ« pĂ«r projekte tĂ« vogla, ku Kubernetes mund tĂ« shkaktojĂ« vĂ«shtirĂ«si tĂ« mĂ«tejshme dhe nuk do tĂ« realizojĂ« potencialin e tij deri nĂ« fund. Gjithashtu, Nomad Ă«shtĂ« shumĂ« i pĂ«rshtatshĂ«m pĂ«r fillestarĂ«t — instalohet dhe konfigurohet lehtĂ«sisht. MegjithatĂ«, gjatĂ« testimit nĂ« disa projekte, kam hasur nĂ« probleme me versionet e tij tĂ« hershme — shumĂ« funksione bazike thjesht nuk ekzistojnĂ« ose nuk funksionojnĂ« siç duhet. MegjithatĂ«, besoj se Nomad do tĂ« zhvillohet mĂ« tej dhe nĂ« tĂ« ardhmen do tĂ« ketĂ« tĂ« gjitha funksionet e nevojshme.

Autori: Ilia Andreev, me redaktimin e Aleksej Zhadan dhe ekipit 'Live Linux'


Burimi: habr.com

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