ProHoster > Blog > Pangangasiwa > Pagse-set up ng Nomad cluster gamit ang Consul at pagsasama sa Gitlab

Pagse-set up ng Nomad cluster gamit ang Consul at pagsasama sa Gitlab

Pagpapakilala

Kamakailan, ang katanyagan ng Kubernetes ay mabilis na lumalaki - parami nang parami ang mga proyektong nagpapatupad nito. Nais kong hawakan ang isang orkestra tulad ng Nomad: ito ay perpekto para sa mga proyekto na gumagamit na ng iba pang mga solusyon mula sa HashiCorp, halimbawa, Vault at Consul, at ang mga proyekto mismo ay hindi kumplikado sa mga tuntunin ng imprastraktura. Maglalaman ang materyal na ito ng mga tagubilin para sa pag-install ng Nomad, pagsasama-sama ng dalawang node sa isang cluster, pati na rin ang pagsasama ng Nomad sa Gitlab.

Pagse-set up ng Nomad cluster gamit ang Consul at pagsasama sa Gitlab

Test stand

Kaunti tungkol sa test bench: tatlong virtual server ang ginagamit na may mga katangian ng 2 CPU, 4 RAM, 50 Gb SSD, na pinagsama sa isang karaniwang lokal na network. Ang kanilang mga pangalan at IP address:

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

Pag-install ng Nomad, Consul. Paglikha ng Nomad cluster

Magsimula tayo sa pangunahing pag-install. Bagama't simple ang pag-setup, ilalarawan ko ito para sa kapakanan ng integridad ng artikulo: mahalagang ginawa ito mula sa mga draft at tala para sa mabilis na pag-access kapag kinakailangan.

Bago tayo magsimula ng pagsasanay, tatalakayin natin ang teoretikal na bahagi, dahil sa yugtong ito mahalaga na maunawaan ang istraktura sa hinaharap.

Mayroon kaming dalawang nomad node at gusto naming pagsamahin ang mga ito sa isang kumpol, at sa hinaharap kakailanganin din namin ang awtomatikong pag-scale ng kumpol - para dito kakailanganin namin ang Consul. Gamit ang tool na ito, ang clustering at pagdaragdag ng mga bagong node ay nagiging isang napakasimpleng gawain: ang nilikhang Nomad node ay kumokonekta sa ahente ng Consul, at pagkatapos ay kumokonekta sa umiiral na Nomad cluster. Samakatuwid, sa simula ay i-install namin ang server ng Consul, i-configure ang pangunahing awtorisasyon ng http para sa web panel (ito ay walang pahintulot bilang default at maaaring ma-access sa isang panlabas na address), pati na rin ang mga ahente ng Consul mismo sa mga server ng Nomad, pagkatapos nito tayo ay magpapatuloy lamang sa Nomad.

Ang pag-install ng mga tool ng HashiCorp ay napakasimple: sa pangkalahatan, ililipat lang namin ang binary file sa direktoryo ng bin, i-set up ang configuration file ng tool, at gagawa ng service file nito.

I-download ang Consul binary file at i-unpack ito sa home directory ng user:

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/

Ngayon ay mayroon na kaming handa na consul binary para sa karagdagang pagsasaayos.

Para makipagtulungan sa Consul, kailangan naming gumawa ng natatanging key gamit ang keygen command:

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

Magpatuloy tayo sa pagse-set up ng configuration ng Consul, paggawa ng isang direktoryo /etc/consul.d/ na may sumusunod na istraktura:

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

Ang direktoryo ng bootstrap ay maglalaman ng configuration file na config.json - dito namin itatakda ang mga setting ng Consul. Ang nilalaman nito:

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

Tingnan natin ang pangunahing mga direktiba at ang kanilang mga kahulugan nang hiwalay:

  • bootstrap: totoo. Pinagana namin ang awtomatikong pagdaragdag ng mga bagong node kung nakakonekta ang mga ito. Tandaan ko na hindi namin ipinapahiwatig dito ang eksaktong bilang ng mga inaasahang node.
  • server: totoo. Paganahin ang mode ng server. Ang Consul sa virtual machine na ito ay gaganap bilang ang tanging server at master sa ngayon, ang VM ng Nomad ang magiging mga kliyente.
  • datacenter: dc1. Tukuyin ang pangalan ng data center para gawin ang cluster. Dapat itong magkapareho sa parehong mga kliyente at server.
  • encrypt: iyong-susi. Ang susi, na dapat ding natatangi at tumutugma sa lahat ng kliyente at server. Binuo gamit ang consul keygen command.
  • start_join. Sa listahang ito, ipinapahiwatig namin ang isang listahan ng mga IP address kung saan gagawin ang koneksyon. Sa ngayon, sarili naming address lang ang iniiwan namin.

Sa puntong ito maaari tayong magpatakbo ng consul gamit ang command line:

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

Ito ay isang mahusay na paraan upang mag-debug ngayon, gayunpaman, hindi mo magagamit ang paraang ito sa patuloy na batayan para sa mga malinaw na dahilan. Gumawa tayo ng file ng serbisyo upang pamahalaan ang Consul sa pamamagitan ng systemd:

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

Mga nilalaman ng consul.service file: 

[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

Ilunsad ang Consul sa pamamagitan ng systemctl:

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

Suriin natin: ang aming serbisyo ay dapat na tumatakbo, at sa pamamagitan ng pagpapatupad ng utos ng mga miyembro ng consul dapat naming makita ang aming server:

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

Susunod na yugto: pag-install ng Nginx at pag-set up ng proxying at http authorization. Nag-i-install kami ng nginx sa pamamagitan ng manager ng package at sa /etc/nginx/sites-enabled directory gumawa kami ng configuration file consul.conf na may mga sumusunod na nilalaman:

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

Huwag kalimutang gumawa ng .htpasswd file at bumuo ng username at password para dito. Ang item na ito ay kinakailangan upang ang web panel ay hindi magagamit sa lahat ng nakakaalam ng aming domain. Gayunpaman, kapag nagse-set up ng Gitlab, kakailanganin naming iwanan ito - kung hindi, hindi namin magagawang i-deploy ang aming application sa Nomad. Sa aking proyekto, parehong Gitlab at Nomad ay nasa grey web lamang, kaya walang ganoong problema dito.

Sa natitirang dalawang server ay nag-i-install kami ng mga ahente ng Consul ayon sa mga sumusunod na tagubilin. Ulitin namin ang mga hakbang sa binary file:

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/

Sa pamamagitan ng pagkakatulad sa nakaraang server, lumikha kami ng isang direktoryo para sa mga file ng pagsasaayos /etc/consul.d na may sumusunod na istraktura:

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

Mga nilalaman ng config.json file:

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

I-save ang mga pagbabago at magpatuloy sa pag-set up ng file ng serbisyo, ang mga nilalaman nito:

/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

Naglulunsad kami ng konsul sa server. Ngayon, pagkatapos ng paglunsad, dapat nating makita ang naka-configure na serbisyo sa mga miyembro ng nsul. Nangangahulugan ito na matagumpay itong nakakonekta sa cluster bilang isang kliyente. Ulitin ang parehong sa pangalawang server at pagkatapos nito maaari naming simulan ang pag-install at pag-configure ng Nomad.

Ang mas detalyadong pag-install ng Nomad ay inilarawan sa opisyal na dokumentasyon nito. Mayroong dalawang tradisyonal na paraan ng pag-install: pag-download ng binary file at pag-compile mula sa pinagmulan. Pipiliin ko ang unang paraan.

Nota: Ang proyekto ay mabilis na umuunlad, ang mga bagong update ay madalas na inilabas. Marahil ay may ilalabas na bagong bersyon sa oras na makumpleto ang artikulong ito. Samakatuwid, bago basahin, inirerekumenda kong suriin ang kasalukuyang bersyon ng Nomad sa sandaling ito at i-download ito. 

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

Pagkatapos mag-unpack, makakatanggap kami ng Nomad binary file na tumitimbang ng 65 MB - dapat itong ilipat sa /usr/local/bin.

Gumawa tayo ng isang direktoryo ng data para sa Nomad at i-edit ang file ng serbisyo nito (malamang na hindi ito umiiral sa simula):

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

Idikit ang mga sumusunod na linya doon:

[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

Gayunpaman, hindi kami nagmamadaling maglunsad ng nomad - hindi pa namin nagagawa ang configuration file nito:

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

Ang panghuling istraktura ng direktoryo ay ang mga sumusunod:

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

Ang nomad.hcl file ay dapat maglaman ng sumusunod na configuration:

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

Mga nilalaman ng server.hcl file:

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
}

Huwag kalimutang baguhin ang configuration file sa pangalawang server - doon ay kakailanganin mong baguhin ang halaga ng http directive.

Ang huling bagay sa yugtong ito ay i-configure ang Nginx para sa pag-proxy at pag-set up ng http authorization. Mga nilalaman ng nomad.conf file:

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

Ngayon ay maa-access na natin ang web panel sa pamamagitan ng panlabas na network. Kumonekta at pumunta sa pahina ng mga server:

Pagse-set up ng Nomad cluster gamit ang Consul at pagsasama sa Gitlab
Larawan 1. Listahan ng mga server sa Nomad cluster

Ang parehong mga server ay matagumpay na ipinapakita sa panel, makikita natin ang parehong bagay sa output ng nomad node status command:

Pagse-set up ng Nomad cluster gamit ang Consul at pagsasama sa Gitlab
Larawan 2. Output ng nomad node status command

Paano ang Consul? Tingnan natin. Pumunta sa Consul control panel, sa pahina ng mga node:
Pagse-set up ng Nomad cluster gamit ang Consul at pagsasama sa Gitlab
Larawan 3. Listahan ng mga node sa cluster ng Consul

Ngayon ay mayroon kaming nakahanda na Nomad na nagtatrabaho kasabay ng Consul. Sa huling yugto, pupunta tayo sa nakakatuwang bahagi: ang pagse-set up ng paghahatid ng mga container ng Docker mula Gitlab hanggang Nomad, at pag-uusapan din ang tungkol sa ilan sa iba pang mga natatanging tampok nito.

Paglikha ng Gitlab Runner

Upang mag-deploy ng mga docker na imahe sa Nomad, gagamit kami ng isang hiwalay na runner na may Nomad binary file sa loob (dito, sa pamamagitan ng paraan, maaari naming tandaan ang isa pang tampok ng mga aplikasyon ng Hashicorp - isa-isa silang isang binary file). I-upload ito sa direktoryo ng runner. Gumawa tayo ng isang simpleng Dockerfile para dito na may sumusunod na nilalaman:


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

Sa parehong proyekto, lumikha kami ng .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}

Bilang resulta, magkakaroon tayo ng available na imahe ng Nomad runner sa Gitlab Registry, ngayon ay maaari na tayong direktang pumunta sa repository ng proyekto, lumikha ng Pipeline at i-configure ang nomad's nomad na trabaho.

Pag-setup ng proyekto

Magsimula tayo sa file ng trabaho para sa Nomad. Ang aking proyekto sa artikulong ito ay magiging primitive: ito ay bubuo ng isang gawain. Ang mga nilalaman ng .gitlab-ci ay ang mga sumusunod:

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

Dito manu-manong nagaganap ang deployment, ngunit maaari mo itong i-configure upang baguhin ang mga nilalaman ng direktoryo ng proyekto. Ang pipeline ay binubuo ng dalawang yugto: image assembly at ang deployment nito sa nomad. Sa unang yugto, nag-iipon kami ng isang docker na imahe at itulak ito sa aming Registry, at sa pangalawa ay inilunsad namin ang aming trabaho sa 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" {}
                }
            }
        }
    }
}

Pakitandaan na mayroon akong pribadong Registry at upang matagumpay na makuha ang isang docker na imahe kailangan kong mag-log in dito. Ang pinakamahusay na solusyon sa kasong ito ay ang pagpasok ng login at password sa Vault at pagkatapos ay isama ito sa Nomad. Ang Nomad ay katutubong sumusuporta sa Vault. Ngunit una, i-install natin ang mga kinakailangang patakaran para sa Nomad sa Vault mismo; mada-download ang mga ito:

# 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

Ngayon, sa paggawa ng mga kinakailangang patakaran, magdaragdag kami ng integration sa Vault sa task block sa job.nomad file:

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

Gumagamit ako ng awtorisasyon sa pamamagitan ng token at direktang irehistro ito dito, mayroon ding opsyon na tukuyin ang token bilang variable kapag nagsisimula ng nomad agent:

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

Ngayon ay magagamit na natin ang mga susi sa Vault. Ang prinsipyo ng pagpapatakbo ay simple: lumikha kami ng isang file sa Nomad job na mag-iimbak ng mga halaga ng mga variable, halimbawa:

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
}

Sa simpleng diskarte na ito, maaari mong i-configure ang paghahatid ng mga container sa Nomad cluster at magtrabaho kasama nito sa hinaharap. Sasabihin ko na sa ilang sukat ay nakikiramay ako sa Nomad - ito ay mas angkop para sa maliliit na proyekto kung saan ang Kubernetes ay maaaring magdulot ng karagdagang kumplikado at hindi mapagtanto ang buong potensyal nito. Dagdag pa, ang Nomad ay perpekto para sa mga nagsisimula—madali itong i-install at i-configure. Gayunpaman, kapag sumusubok sa ilang mga proyekto, nakatagpo ako ng problema sa mga naunang bersyon nito - maraming mga pangunahing pag-andar ang wala doon o hindi gumagana nang tama. Gayunpaman, naniniwala ako na ang Nomad ay patuloy na bubuo at sa hinaharap ay makukuha nito ang mga function na kailangan ng lahat.

May-akda: Ilya Andreev, na-edit ni Alexey Zhadan at ng Live Linux team


Pinagmulan: www.habr.com

Magdagdag ng komento