Nomad-klusterin perustaminen Consulilla ja integrointi Gitlabiin

Esittely

Viime aikoina Kuberneteksen suosio on kasvanut nopeasti - yhä useammat projektit toteuttavat sitä. Halusin koskettaa Nomadin kaltaista orkestraattoria: se sopii täydellisesti projekteihin, joissa käytetään jo muita HashiCorpin ratkaisuja, esimerkiksi Vault ja Consul, eivätkä itse projektit ole infrastruktuuriltaan monimutkaisia. Tämä materiaali sisältää ohjeet Nomadin asentamiseen, kahden solmun yhdistämiseen klusteriksi sekä Nomadin integroimiseen Gitlabiin.

Testiteline

Hieman testipenkistä: käytössä on kolme virtuaalipalvelinta, joiden ominaisuudet ovat 2 CPU, 4 RAM, 50 Gb SSD, yhdistettynä yhteiseen paikallisverkkoon. Heidän nimensä ja IP-osoitteensa:

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

Nomadin asennus, konsuli. Nomad-klusterin luominen

Aloitetaan perusasennuksesta. Vaikka asennus oli yksinkertainen, kuvailen sen artikkelin eheyden vuoksi: se luotiin pääosin luonnoksista ja muistiinpanoista, jotta niitä voidaan tarvittaessa käyttää nopeasti.

Ennen kuin aloitamme harjoittelun, käsittelemme teoreettista osaa, koska tässä vaiheessa on tärkeää ymmärtää tulevaisuuden rakenne.

Meillä on kaksi nomadisolmua ja haluamme yhdistää ne klusteriksi, ja tulevaisuudessa tarvitsemme myös automaattisen klusterin skaalauksen - tähän tarvitsemme Consulin. Tämän työkalun avulla klusteroinnista ja uusien solmujen lisäämisestä tulee hyvin yksinkertainen tehtävä: luotu Nomad-solmu muodostaa yhteyden Consul-agenttiin ja sitten olemassa olevaan Nomad-klusteriin. Siksi asennamme aluksi Consul-palvelimen, määritämme web-paneelin http-perusvaltuutuksen (oletuksena se on ilman valtuutusta ja siihen pääsee ulkoisesta osoitteesta), sekä itse Consul-agentit Nomad-palvelimille, jonka jälkeen jatkamme vain Nomadiin.

HashiCorpin työkalujen asentaminen on hyvin yksinkertaista: pohjimmiltaan siirrämme binääritiedoston bin-hakemistoon, asetamme työkalun konfigurointitiedoston ja luomme sen palvelutiedoston.

Lataa Consul-binaaritiedosto ja pura se käyttäjän kotihakemistoon:

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/

Nyt meillä on valmis konsulibinaari lisäkonfigurointia varten.

Työskenteleksemme Consulin kanssa meidän on luotava ainutlaatuinen avain keygen-komennolla:

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

Siirrytään Consul-kokoonpanon määrittämiseen luomalla hakemisto /etc/consul.d/ seuraavalla rakenteella:

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

Bootstrap-hakemisto sisältää konfigurointitiedoston config.json - siinä asetamme Consul-asetukset. Sen sisältö:

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

Katsotaanpa tärkeimpiä direktiivejä ja niiden merkityksiä erikseen:

• bootstrap: totta. Otamme käyttöön automaattisen uusien solmujen lisäämisen, jos ne on kytketty. Huomaan, että emme ilmoita tässä odotettujen solmujen tarkkaa määrää.
• palvelin: totta. Ota palvelintila käyttöön. Tämän virtuaalikoneen konsuli toimii tällä hetkellä ainoana palvelimena ja isäntänä, asiakkaina toimii Nomadin VM.
• datacenter: dc1. Luo klusteri määrittämällä tietokeskuksen nimi. Sen on oltava identtinen sekä asiakkailla että palvelimilla.
• Salaa: sinun-avain. Avain, jonka tulee myös olla ainutlaatuinen ja sopia kaikille asiakkaille ja palvelimille. Luotu käyttämällä consul keygen -komentoa.
• aloita_liittyminen. Tässä luettelossa on luettelo IP-osoitteista, joihin yhteys muodostetaan. Tällä hetkellä jätämme vain oman osoitteemme.

Tässä vaiheessa voimme ajaa konsulin komentorivillä:

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

Tämä on hyvä tapa tehdä virheenkorjaus nyt, mutta et voi käyttää tätä menetelmää jatkuvasti ilmeisistä syistä. Luodaan palvelutiedosto Consulin hallintaan systemd:n ​​kautta:

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

Consul.service-tiedoston sisältö:

[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

Käynnistä Consul systemctl:n kautta:

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

Tarkistetaan: palvelumme on oltava käynnissä, ja suorittamalla konsulin jäsenten komennon meidän pitäisi nähdä palvelimemme:

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

Seuraava vaihe: Asenna Nginx ja määritä välityspalvelin ja http-valtuutus. Asennamme nginxin paketinhallinnan kautta ja luomme /etc/nginx/sites-enabled-hakemistoon kokoonpanotiedoston consul.conf, jonka sisältö on seuraava:

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

Älä unohda luoda .htpasswd-tiedostoa ja luoda sille käyttäjätunnus ja salasana. Tämä kohde on pakollinen, jotta verkkopaneeli ei ole kaikkien verkkotunnuksemme tuntevien käytettävissä. Gitlabia määritettäessä meidän on kuitenkin luovuttava tästä - muuten emme voi ottaa sovellustamme käyttöön Nomadille. Projektissani sekä Gitlab että Nomad ovat vain harmaassa verkossa, joten täällä ei ole sellaista ongelmaa.

Jäljelle jääville kahdelle palvelimelle asennamme Consul-agentit seuraavien ohjeiden mukaisesti. Toistamme vaiheet binääritiedoston kanssa:

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/

Analogisesti edellisen palvelimen kanssa luomme hakemiston asetustiedostoille /etc/consul.d, jolla on seuraava rakenne:

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

Config.json-tiedoston sisältö:

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

Tallenna muutokset ja siirry palvelutiedoston ja sen sisällön asettamiseen:

/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

Avaamme konsulin palvelimelle. Nyt käynnistämisen jälkeen meidän pitäisi nähdä määritetty palvelu nsul-jäsenissä. Tämä tarkoittaa, että se on muodostanut yhteyden klusteriin asiakkaana. Toista sama toisella palvelimella ja sen jälkeen voimme aloittaa Nomadin asennuksen ja konfiguroinnin.

Nomadin tarkempi asennus on kuvattu sen virallisessa dokumentaatiossa. On olemassa kaksi perinteistä asennustapaa: binääritiedoston lataaminen ja käännös lähteestä. Valitsen ensimmäisen menetelmän.

Huomata: Projekti kehittyy erittäin nopeasti, uusia päivityksiä julkaistaan ​​usein. Ehkä uusi versio julkaistaan, kun tämä artikkeli on valmis. Siksi ennen lukemista suosittelen tarkistamaan Nomadin nykyisen version tällä hetkellä ja lataamaan sen.

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

Pakkauksen purkamisen jälkeen saamme Nomad-binaaritiedoston, joka painaa 65 Mt - se on siirrettävä kansioon /usr/local/bin.

Luodaan Nomadille tietohakemisto ja muokataan sen palvelutiedostoa (se ei todennäköisesti ole alussa):

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

Liitä sinne seuraavat rivit:

[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

Meillä ei kuitenkaan ole kiirettä käynnistää nomad - emme ole vielä luoneet sen asetustiedostoa:

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

Lopullinen hakemistorakenne on seuraava:

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

Nomad.hcl-tiedoston tulee sisältää seuraavat asetukset:

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

Server.hcl-tiedoston sisältö:

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
}

Älä unohda muuttaa toisen palvelimen asetustiedostoa - siellä sinun on muutettava http-direktiivin arvoa.

Viimeinen asia tässä vaiheessa on määrittää Nginx välityspalvelinta varten ja http-valtuutuksen määrittäminen. Nomad.conf-tiedoston sisältö:

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

Nyt voimme käyttää verkkopaneelia ulkoisen verkon kautta. Yhdistä ja siirry palvelinsivulle:

Kuva 1. Luettelo Nomad-klusterin palvelimista

Molemmat palvelimet näytetään onnistuneesti paneelissa, näemme saman asian nomad node status -komennon lähdössä:

Kuva 2. Nomadin solmun tilakomennon tulos

Entä konsuli? Katsotaanpa. Siirry Consul-ohjauspaneeliin solmusivulle:

Kuva 3. Luettelo Consul-klusterin solmuista

Nyt meillä on valmis Nomad, joka työskentelee yhdessä konsulin kanssa. Viimeisessä vaiheessa pääsemme hauskaan osaan: Docker-konttien toimituksen määrittäminen Gitlabista Nomadille ja puhuminen myös muista sen erityispiirteistä.

Gitlab Runnerin luominen

Docker-kuvien ottamiseksi käyttöön Nomadissa käytämme erillistä juoksijaa, jonka sisällä on Nomad-binaaritiedosto (tässä muuten voimme huomata toisen Hashicorp-sovellusten ominaisuuden - yksittäin ne ovat yksi binaaritiedosto). Lataa se runner-hakemistoon. Luodaan sille yksinkertainen Docker-tiedosto seuraavalla sisällöllä:

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

Samassa projektissa luomme .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}

Tämän seurauksena meillä on käytettävissä oleva kuva Nomad-juoksusta Gitlab-rekisterissä, nyt voimme mennä suoraan projektivarastoon, luoda putkilinjan ja määrittää Nomadin nomad-työn.

Projektin asennus

Aloitetaan Nomadin työtiedostosta. Tämän artikkelin projektini on melko alkeellinen: se koostuu yhdestä tehtävästä. .gitlab-ci:n sisältö on seuraava:

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

Täällä käyttöönotto tapahtuu manuaalisesti, mutta voit määrittää sen muuttamaan projektihakemiston sisältöä. Putkilinja koostuu kahdesta vaiheesta: kuvan kokoonpano ja sen käyttöönotto nomadille. Ensimmäisessä vaiheessa kokoamme telakointikuvan ja työnnämme sen rekisteriimme, ja toisessa käynnistämme työmme Nomadissa.

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

Huomaa, että minulla on yksityinen rekisteri, ja minun on kirjauduttava sisään, jotta voin vetää telakointikuvan onnistuneesti. Paras ratkaisu tässä tapauksessa on syöttää kirjautumistunnus ja salasana Holviin ja sitten integroida se Nomadiin. Nomad tukee Vaultia alkuperäisesti. Mutta ensin asennetaan tarvittavat käytännöt Nomadille itse Holviin; ne voidaan ladata:

# 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

Nyt kun tarvittavat käytännöt on luotu, lisäämme integroinnin Holviin job.nomad-tiedoston tehtävälohkoon:

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

Käytän valtuutusta tokenilla ja rekisteröin sen suoraan täällä, on myös mahdollisuus määrittää token muuttujaksi nomadiagenttia käynnistettäessä:

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

Nyt voimme käyttää avaimia Holvin kanssa. Toimintaperiaate on yksinkertainen: luomme Nomad-työssä tiedoston, joka tallentaa muuttujien arvot, esimerkiksi:

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
}

Tällä yksinkertaisella lähestymistavalla voit määrittää konttien toimituksen Nomad-klusteriin ja työskennellä sen kanssa tulevaisuudessa. Sanon, että jossain määrin myötätun Nomadiin - se sopii paremmin pieniin projekteihin, joissa Kubernetes voi aiheuttaa lisämonimutkaisuutta eikä hyödynnä koko potentiaaliaan. Lisäksi Nomad on täydellinen aloittelijoille – se on helppo asentaa ja määrittää. Joitakin projekteja testaessani kohtaan kuitenkin ongelman sen varhaisissa versioissa - monet perustoiminnot eivät yksinkertaisesti ole olemassa tai ne eivät toimi oikein. Uskon kuitenkin, että Nomad jatkaa kehittymistä ja saa jatkossa kaikkien tarvitsemat toiminnot.

Kirjoittaja: Ilja Andreev, toimittaneet Alexey Zhadan ja Live Linux -tiimi


Lähde: will.com