ProHoster > Blog > Stjórnsýsla > Setja upp Nomad klasa með Consul og samþættingu við Gitlab

Setja upp Nomad klasa með Consul og samþættingu við Gitlab

Inngangur

Undanfarið hafa vinsældir Kubernetes farið ört vaxandi - fleiri og fleiri verkefni eru að hrinda því í framkvæmd. Mig langaði að snerta hljómsveitarstjóra eins og Nomad: hann er fullkominn fyrir verkefni sem nota nú þegar aðrar lausnir frá HashiCorp, til dæmis Vault og Consul, og verkefnin sjálf eru ekki flókin hvað varðar innviði. Þetta efni mun innihalda leiðbeiningar um uppsetningu Nomad, sameina tvo hnúta í þyrping, auk þess að samþætta Nomad við Gitlab.

Setja upp Nomad klasa með Consul og samþættingu við Gitlab

Prófstandur

Smá um prófunarbekkinn: þrír sýndarþjónar eru notaðir með eiginleika 2 örgjörva, 4 vinnsluminni, 50 Gb SSD, sameinuð í sameiginlegt staðarnet. Nöfn þeirra og IP tölur:

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

Uppsetning Nomad, ræðismanns. Að búa til hirðingjaklasa

Byrjum á grunnuppsetningunni. Þrátt fyrir að uppsetningin hafi verið einföld, mun ég lýsa henni vegna heiðarleika greinarinnar: hún var í meginatriðum búin til úr drögum og athugasemdum til að fá skjótan aðgang þegar þörf krefur.

Áður en við byrjum að æfa munum við ræða fræðilega hlutann, því á þessu stigi er mikilvægt að skilja framtíðarskipulagið.

Við erum með tvo hirðingjahnúta og viljum sameina þá í klasa og í framtíðinni þurfum við líka sjálfvirka klasaskala - til þess þurfum við Consul. Með þessu tóli verður klasa og bæta við nýjum hnútum mjög einfalt verkefni: búið til Nomad hnútur tengist Consul umboðsmanninum og tengist síðan við núverandi Nomad klasa. Þess vegna munum við í upphafi setja upp Consul netþjóninn, stilla grunn http heimild fyrir vefspjaldið (það er sjálfgefið án heimildar og hægt er að nálgast það á utanaðkomandi heimilisfangi), sem og Consul umboðsmenn sjálfir á Nomad netþjónum, eftir það við munum aðeins halda áfram til Nomad.

Að setja upp verkfæri HashiCorp er mjög einfalt: í rauninni færum við bara tvöfalda skrána í bin möppuna, setjum upp stillingarskrá tólsins og búum til þjónustuskrá þess.

Sæktu Consul tvíundarskrána og pakkaðu henni upp í heimamöppu notandans:

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/

Nú höfum við tilbúið ræðismannstvíundarkerfi fyrir frekari stillingar.

Til að vinna með Consul þurfum við að búa til einstakan lykil með keygen skipuninni:

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

Við skulum halda áfram að setja upp Consul stillinguna, búa til möppu /etc/consul.d/ með eftirfarandi uppbyggingu:

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

Bootstrap skráin mun innihalda stillingarskrá config.json - í henni munum við stilla Consul stillingarnar. Innihald þess:

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

Við skulum skoða helstu tilskipanir og merkingu þeirra sérstaklega:

  • stígvél: satt. Við gerum sjálfvirka viðbót við nýja hnúta ef þeir eru tengdir. Ég tek fram að við tilgreinum ekki hér nákvæman fjölda væntanlegra hnúta.
  • miðlara: satt. Virkja miðlaraham. Consul á þessari sýndarvél mun starfa sem eini þjónninn og meistarinn í augnablikinu, VM Nomad mun vera viðskiptavinirnir.
  • gagnaver:dc1. Tilgreindu nafn gagnaversins til að búa til þyrpinguna. Það verður að vera eins á bæði viðskiptavinum og netþjónum.
  • Dulkóða: þinn-lykill. Lykillinn, sem verður einnig að vera einstakur og passa á öllum viðskiptavinum og netþjónum. Búið til með því að nota consul keygen skipunina.
  • start_join. Í þessum lista tilgreinum við lista yfir IP tölur sem tengingin verður við. Í augnablikinu skiljum við aðeins eftir okkar eigið heimilisfang.

Á þessum tímapunkti getum við keyrt ræðismann með því að nota skipanalínuna:

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

Þetta er góð leið til að kemba núna, en þú munt ekki geta notað þessa aðferð stöðugt af augljósum ástæðum. Við skulum búa til þjónustuskrá til að stjórna Consul í gegnum systemd:

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

Innihald consul.service skrárinnar: 

[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

Ræstu Consul í gegnum systemctl:

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

Við skulum athuga: þjónusta okkar verður að vera í gangi og með því að framkvæma skipun ræðismanna ættum við að sjá netþjóninn okkar:

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

Næsta stig: að setja upp Nginx og setja upp umboð og http heimild. Við setjum upp nginx í gegnum pakkastjórann og í /etc/nginx/sites-enabled skránni búum við til stillingarskrá consul.conf með eftirfarandi innihaldi:

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

Ekki gleyma að búa til .htpasswd skrá og búa til notendanafn og lykilorð fyrir hana. Þetta atriði er nauðsynlegt svo að vefspjaldið sé ekki aðgengilegt öllum sem þekkja lénið okkar. Hins vegar, þegar þú setur upp Gitlab, verðum við að yfirgefa þetta - annars getum við ekki sent forritið okkar til Nomad. Í verkefninu mínu eru bæði Gitlab og Nomad eingöngu á gráa vefnum, svo það er ekkert slíkt vandamál hér.

Á hinum tveimur netþjónunum setjum við upp Consul umboðsmenn samkvæmt eftirfarandi leiðbeiningum. Við endurtökum skrefin með tvíundarskránni:

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/

Á hliðstæðan hátt við fyrri netþjóninn búum við til möppu fyrir stillingarskrár /etc/consul.d með eftirfarandi uppbyggingu:

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

Innihald config.json skráarinnar:

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

Vistaðu breytingarnar og haltu áfram að setja upp þjónustuskrána, innihald hennar:

/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

Við ræsum ræðismann á þjóninum. Nú, eftir ræsingu, ættum við að sjá stilltu þjónustuna í nsul meðlimum. Þetta þýðir að það hefur tengst þyrpingunni sem viðskiptavinur. Endurtaktu það sama á öðrum netþjóni og eftir það getum við byrjað að setja upp og stilla Nomad.

Nánari uppsetningu á Nomad er lýst í opinberum skjölum þess. Það eru tvær hefðbundnar uppsetningaraðferðir: að hlaða niður tvöfaldri skrá og setja saman frá uppruna. Ég mun velja fyrstu aðferðina.

Athugið: Verkefnið er að þróast mjög hratt, nýjar uppfærslur eru oft gefnar út. Kannski verður ný útgáfa gefin út þegar þessari grein er lokið. Þess vegna, áður en þú lest, mæli ég með því að athuga núverandi útgáfu af Nomad í augnablikinu og hala henni niður. 

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

Eftir að hafa verið pakkað upp munum við fá Nomad tvíundarskrá sem vegur 65 MB - hana verður að færa í /usr/local/bin.

Við skulum búa til gagnaskrá fyrir Nomad og breyta þjónustuskránni hennar (líklega mun hún ekki vera til í upphafi):

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

Límdu eftirfarandi línur þar:

[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

Hins vegar erum við ekkert að flýta okkur að ræsa nomad - við höfum ekki enn búið til stillingarskrá þess:

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

Endanleg möppuuppbygging verður sem hér segir:

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

Nomad.hcl skráin ætti að innihalda eftirfarandi stillingar:

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

Innihald server.hcl skráarinnar:

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
}

Ekki gleyma að breyta stillingarskránni á öðrum netþjóni - þar þarftu að breyta gildi http tilskipunarinnar.

Það síðasta á þessu stigi er að stilla Nginx fyrir umboð og setja upp http heimild. Innihald nomad.conf skráarinnar:

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

Nú getum við fengið aðgang að vefspjaldinu í gegnum ytra net. Tengstu og farðu á netþjónasíðuna:

Setja upp Nomad klasa með Consul og samþættingu við Gitlab
Mynd 1. Listi yfir netþjóna í Nomad þyrpingunni

Báðir netþjónarnir birtast með góðum árangri á spjaldinu, við munum sjá það sama í úttakinu af stöðuskipun hirðingjahnútsins:

Setja upp Nomad klasa með Consul og samþættingu við Gitlab
Mynd 2. Úttak af stöðuskipun hirðingjahnútsins

Hvað með ræðismann? Við skulum skoða. Farðu á Consul stjórnborðið, á hnútasíðuna:
Setja upp Nomad klasa með Consul og samþættingu við Gitlab
Mynd 3. Listi yfir hnúta í Consul klasanum

Nú höfum við undirbúið Nomad sem starfar í samvinnu við ræðismann. Á lokastigi munum við komast að skemmtilega hlutanum: að setja upp afhendingu á Docker gámum frá Gitlab til Nomad, og einnig tala um nokkra af öðrum sérkennum þess.

Að búa til Gitlab Runner

Til að dreifa Docker-myndum á Nomad, munum við nota sérstakan hlaupara með Nomad-tvíundarskránni inni (hér, við the vegur, getum við tekið eftir öðrum eiginleikum Hashicorp forrita - hver fyrir sig eru þau ein tvöfaldur skrá). Hladdu því upp í hlauparaskrána. Við skulum búa til einfalda Dockerfile fyrir það með eftirfarandi efni:


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

Í sama verkefni búum við til .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}

Fyrir vikið munum við hafa tiltæka mynd af Nomad hlauparanum í Gitlab Registry, nú getum við farið beint í verkefnageymsluna, búið til leiðslu og stillt hirðingjastarf Nomad.

Verkefnauppsetning

Byrjum á vinnuskránni fyrir Nomad. Verkefnið mitt í þessari grein verður frekar frumstætt: það mun samanstanda af einu verkefni. Innihald .gitlab-ci verður sem hér segir:

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

Hér fer dreifingin fram handvirkt, en þú getur stillt hana til að breyta innihaldi verkefnaskrárinnar. Leiðsla samanstendur af tveimur stigum: myndasamsetningu og dreifing hennar til hirðingja. Á fyrsta stigi setjum við saman bryggjumynd og ýtum henni inn í Registry okkar og á því síðara ræsum við starfið okkar í 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" {}
                }
            }
        }
    }
}

Vinsamlega athugið að ég er með einkaskrá og til að ná fram dokkumynd þarf ég að skrá mig inn á hana. Besta lausnin í þessu tilfelli er að slá inn notandanafn og lykilorð í Vault og samþætta það síðan við Nomad. Nomad styður innfæddan Vault. En fyrst skulum við setja upp nauðsynlegar reglur fyrir Nomad í Vault sjálfu; hægt er að hlaða þeim niður:

# 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

Nú, eftir að hafa búið til nauðsynlegar reglur, munum við bæta samþættingu við Vault í verkefnablokkinni í job.nomad skránni:

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

Ég nota heimild eftir tákni og skrái hana beint hér, það er líka möguleiki á að tilgreina táknið sem breytu þegar ég byrja á hirðingjaumboðsmanni:

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

Nú getum við notað lyklana með Vault. Meginreglan um aðgerðir er einföld: við búum til skrá í Nomad starf sem mun geyma gildi breyta, til dæmis:

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ð þessari einföldu nálgun er hægt að stilla afhendingu gáma til Nomad klasans og vinna með hann í framtíðinni. Ég mun segja að að vissu leyti hef ég samúð með Nomad - það er hentugra fyrir lítil verkefni þar sem Kubernetes getur valdið aukinni flókið og mun ekki gera sér fulla grein fyrir möguleikum sínum. Auk þess er Nomad fullkomið fyrir byrjendur - það er auðvelt að setja upp og stilla. Hins vegar, þegar ég prófa sum verkefni, lendi ég í vandræðum með fyrstu útgáfur þess - margar grunnaðgerðir eru einfaldlega ekki til staðar eða þær virka ekki rétt. Hins vegar tel ég að Nomad muni halda áfram að þróast og í framtíðinni muni það öðlast þá virkni sem allir þurfa.

Höfundur: Ilya Andreev, ritstýrt af Alexey Zhadan og Live Linux teyminu


Heimild: www.habr.com

Bæta við athugasemd