ProHoster > Блог > Administrado > Agordante Nomad-grupon uzante Consul kaj integriĝante kun Gitlab

Agordante Nomad-grupon uzante Consul kaj integriĝante kun Gitlab

Enkonduko

Lastatempe, la populareco de Kubernetes rapide kreskis - pli kaj pli da projektoj efektivigas ĝin. Mi volis tuŝi orkestranton kiel Nomad: ĝi estas perfekta por projektoj, kiuj jam uzas aliajn solvojn de HashiCorp, ekzemple, Vault kaj Consul, kaj la projektoj mem ne estas kompleksaj laŭ infrastrukturo. Ĉi tiu materialo enhavos instrukciojn por instali Nomad, kombinante du nodojn en areton, kaj ankaŭ integri Nomad kun Gitlab.

Agordante Nomad-grupon uzante Consul kaj integriĝante kun Gitlab

Testbenko

Iom pri la testbenko: tri virtualaj serviloj estas uzataj kun la karakterizaĵoj de 2 CPU, 4 RAM, 50 Gb SSD, kunigitaj en komuna loka reto. Iliaj nomoj kaj IP-adresoj:

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

Instalado de Nomado, Konsulo. Kreante Nomad-grupon

Ni komencu kun la baza instalado. Kvankam la aranĝo estis simpla, mi priskribos ĝin pro la integreco de la artikolo: ĝi estis esence kreita el skizoj kaj notoj por rapida aliro kiam bezonite.

Antaŭ ol komenci praktikon, ni diskutos la teorian parton, ĉar en ĉi tiu etapo gravas kompreni la estontan strukturon.

Ni havas du nomadajn nodojn kaj ni volas kombini ilin en areton, kaj estonte ni ankaŭ bezonos aŭtomatan grapskalon - por tio ni bezonos Konsulon. Kun ĉi tiu ilo, amasigi kaj aldoni novajn nodojn fariĝas tre simpla tasko: la kreita Nomad-nodo konektas al la Konsul-agento, kaj poste ligas al la ekzistanta Nomad-grupo. Sekve, komence ni instalos la Konsulservilon, agordos bazan http-rajtigon por la retpanelo (ĝi estas sen rajtigo defaŭlte kaj alireblas ĉe ekstera adreso), same kiel la Konsulajn agentojn mem sur Nomad-serviloj, post kio ni ni nur iros al Nomado.

Instali la ilojn de HashiCorp estas tre simpla: esence, ni simple movas la binaran dosieron al la dosierujo bin, agordas la agordan dosieron de la ilo kaj kreas ĝian servodosieron.

Elŝutu la binaran dosieron de Konsulo kaj malpaku ĝin en la hejman dosierujon de la uzanto:

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/

Nun ni havas pretan konsulan binaron por plia agordo.

Por labori kun Consul, ni devas krei unikan ŝlosilon per la keygen-komando:

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

Ni pluiru al agordo de la Konsula agordo, kreante dosierujon /etc/consul.d/ kun la sekva strukturo:

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

La bootstrap-dosierujo enhavos agordan dosieron config.json - en ĝi ni starigos la Konsulajn agordojn. Ĝia enhavo:

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

Ni rigardu la ĉefajn direktivojn kaj iliajn signifojn aparte:

  • bootstrap: vera. Ni ebligas aŭtomatan aldonon de novaj nodoj se ili estas konektitaj. Mi rimarkas, ke ni ne indikas ĉi tie la precizan nombron da atendataj nodoj.
  • servilo: vera. Ebligu servilan reĝimon. Konsulo sur ĉi tiu virtuala maŝino agos kiel la sola servilo kaj majstro nuntempe, la VM de Nomad estos la klientoj.
  • centro de datumoj: dc1. Indiku la nomon de la datumcentro por krei la areton. Ĝi devas esti identa ĉe klientoj kaj serviloj.
  • ĉifri: via-ŝlosilo. La ŝlosilo, kiu ankaŭ devas esti unika kaj kongrua ĉe ĉiuj klientoj kaj serviloj. Generita per la konsula keygen komando.
  • start_join. En ĉi tiu listo ni indikas liston de IP-adresoj al kiuj la konekto estos farita. Nuntempe ni lasas nur nian propran adreson.

Je ĉi tiu punkto ni povas ruli konsulon uzante la komandlinion:

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

Ĉi tio estas bona maniero sencimigi nun, tamen vi ne povos uzi ĉi tiun metodon daŭrante pro evidentaj kialoj. Ni kreu servodosieron por administri Konsulo per systemd:

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

Enhavo de la konsul.service-dosiero: 

[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

Lanĉu Consul per systemctl:

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

Ni kontrolu: nia servo devas funkcii, kaj plenumante la komandon de konsulaj membroj ni devus vidi nian servilon:

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

Sekva etapo: instali Nginx kaj agordi prokuradon kaj http-rajtigon. Ni instalas nginx per la pakadministranto kaj en la dosierujo /etc/nginx/sites-enabled ni kreas agordan dosieron consul.conf kun la jena enhavo:

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

Ne forgesu krei .htpasswd-dosieron kaj generi uzantnomon kaj pasvorton por ĝi. Ĉi tiu aĵo estas postulata por ke la retpanelo ne estu disponebla por ĉiuj, kiuj konas nian domajnon. Tamen, instalante Gitlab, ni devos forlasi ĉi tion - alie ni ne povos deploji nian aplikaĵon al Nomad. En mia projekto, kaj Gitlab kaj Nomad estas nur sur la griza retejo, do ne ekzistas tia problemo ĉi tie.

Sur la ceteraj du serviloj ni instalas konsulajn agentojn laŭ la sekvaj instrukcioj. Ni ripetas la paŝojn kun la binara dosiero:

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/

Analogie kun la antaŭa servilo, ni kreas dosierujon por agordaj dosieroj /etc/consul.d kun la sekva strukturo:

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

Enhavo de la dosiero 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", # локальный адрес вм
    "start_join": ["172.30.0.15"], # удаленный адрес консул сервера
    "ports": {
      "dns": 53
     }

Konservu la ŝanĝojn kaj daŭrigu agordi la servodosieron, ĝian enhavon:

/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

Ni lanĉas konsulon sur la servilo. Nun, post lanĉo, ni devus vidi la agorditan servon en nsul-membroj. Ĉi tio signifos, ke ĝi sukcese konektiĝis al la areto kiel kliento. Ripetu la samon sur la dua servilo kaj post tio ni povas komenci instali kaj agordi Nomad.

Pli detala instalado de Nomad estas priskribita en ĝia oficiala dokumentaro. Estas du tradiciaj instalmetodoj: elŝuti binaran dosieron kaj kompili el fonto. Mi elektos la unuan metodon.

Примечание: La projekto disvolviĝas tre rapide, novaj ĝisdatigoj ofte estas publikigitaj. Eble nova versio estos publikigita kiam ĉi tiu artikolo estos kompletigita. Tial, antaŭ ol legi, mi rekomendas kontroli la nunan version de Nomad nuntempe kaj elŝuti ĝin. 

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

Post malpakado, ni ricevos Nomad-binaran dosieron pezan 65 MB - ĝi devas esti movita al /usr/local/bin.

Ni kreu datumdosierujon por Nomad kaj redaktu ĝian servodosieron (ĝi plej verŝajne ne ekzistos komence):

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

Algluu la sekvajn liniojn tie:

[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

Tamen ni ne rapidas lanĉi nomadon - ni ankoraŭ ne kreis ĝian agordan dosieron:

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

La fina dosierujo-strukturo estos kiel sekvas:

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

La nomad.hcl dosiero devus enhavi la sekvan agordon:

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

Enhavo de la server.hcl dosiero:

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
}

Ne forgesu ŝanĝi la agordan dosieron sur la dua servilo - tie vi devos ŝanĝi la valoron de la http-direktivo.

La lasta afero en ĉi tiu etapo estas agordi Nginx por prokurado kaj agordo de http-rajtigo. Enhavo de la nomad.conf dosiero:

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

Nun ni povas aliri la retpanelon per ekstera reto. Konektu kaj iru al la paĝo de serviloj:

Agordante Nomad-grupon uzante Consul kaj integriĝante kun Gitlab
Bildo 1. Listo de serviloj en la Nomad-grupo

Ambaŭ serviloj estas sukcese montrataj en la panelo, ni vidos la samon en la eligo de la nomada noda statusa komando:

Agordante Nomad-grupon uzante Consul kaj integriĝante kun Gitlab
Bildo 2. Eligo de la nomada noda statusa komando

Kio pri Konsulo? Ni rigardu. Iru al la Konsula kontrolpanelo, al la paĝo de nodoj:
Agordante Nomad-grupon uzante Consul kaj integriĝante kun Gitlab
Bildo 3. Listo de nodoj en la Konsula areto

Nun ni havas pretan Nomadon laborantan kune kun Konsulo. En la fina etapo, ni atingos la amuzan parton: starigi liveron de Docker-ujoj de Gitlab al Nomad, kaj ankaŭ paroli pri iuj el ĝiaj aliaj karakterizaĵoj.

Kreante Gitlab Runner

Por deploji docker-bildojn al Nomad, ni uzos apartan kurilon kun la Nomad-binara dosiero ene (ĉi tie, cetere, ni povas noti alian funkcion de Hashicorp-aplikoj - individue ili estas ununura binara dosiero). Alŝutu ĝin al la dosierujo de kuristo. Ni kreu simplan Dockerfile por ĝi kun la sekva enhavo:


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

En la sama projekto ni kreas .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}

Kiel rezulto, ni havos disponeblan bildon de la Nomad-kuristo en la Gitlab-Registro, nun ni povas iri rekte al la projekta deponejo, krei Pipeline kaj agordi la nomadlaboron de Nomad.

Agordo de projekto

Ni komencu per la dosiero de la laboro por Nomad. Mia projekto en ĉi tiu artikolo estos sufiĉe primitiva: ĝi konsistos el unu tasko. La enhavo de .gitlab-ci estos kiel sekvas:

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

Ĉi tie la deplojo okazas permane, sed vi povas agordi ĝin por ŝanĝi la enhavon de la projekta dosierujo. Dukto konsistas el du etapoj: bilda asembleo kaj ĝia deplojo al nomado. En la unua etapo, ni kunvenas docker-bildon kaj puŝas ĝin en nian Registron, kaj ĉe la dua ni lanĉas nian laboron en 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" {}
                }
            }
        }
    }
}

Bonvolu noti, ke mi havas privatan Registron kaj por sukcese eltiri docker-bildon mi devas ensaluti al ĝi. La plej bona solvo en ĉi tiu kazo estas enigi ensaluton kaj pasvorton en Vault kaj poste integri ĝin kun Nomad. Nomad denaske subtenas Vault. Sed unue, ni instalu la necesajn politikojn por Nomad en Vault mem; ili povas esti elŝutitaj:

# 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

Nun, kreinte la necesajn politikojn, ni aldonos integriĝon kun Vault en la taskoblokon en la dosiero job.nomad:

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

Mi uzas rajtigon per ĵetono kaj registras ĝin rekte ĉi tie, ekzistas ankaŭ la eblo specifi la ĵetonon kiel variablon kiam oni komencas nomadan agenton:

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

Nun ni povas uzi la ŝlosilojn kun Vault. La principo de operacio estas simpla: ni kreas dosieron en Nomad-laboro, kiu stokos la valorojn de variabloj, ekzemple:

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
}

Kun ĉi tiu simpla aliro, vi povas agordi la liveron de ujoj al la Nomad-grupo kaj labori kun ĝi estonte. Mi diros, ke iagrade mi simpatias kun Nomad - ĝi pli taŭgas por malgrandaj projektoj, kie Kubernetes povas kaŭzi plian kompleksecon kaj ne realigos ĝian plenan potencialon. Krome, Nomad estas perfekta por komencantoj—ĝi estas facile instalebla kaj agordi. Tamen, kiam mi provas iujn projektojn, mi renkontas problemon pri ĝiaj fruaj versioj - multaj bazaj funkcioj simple ne ekzistas aŭ ili ne funkcias ĝuste. Tamen mi kredas, ke Nomad daŭre disvolvos kaj estonte ĝi akiros la funkciojn, kiujn ĉiuj bezonas.

Aŭtoro: Ilya Andreev, redaktita de Alexey Zhadan kaj la teamo Live Linux


fonto: www.habr.com

Aldoni komenton