ProHoster > Bloc > Administració > Configuració d'un clúster Nomad amb Consul i integració amb Gitlab

Configuració d'un clúster Nomad amb Consul i integració amb Gitlab

Introducció

Recentment, la popularitat de Kubernetes ha anat creixent ràpidament: cada cop hi ha més projectes que l'apliquen a casa. Volia tocar un orquestrador com Nomad: és perfecte per a projectes on ja s'utilitzen altres solucions de HashiCorp, com Vault i Consul, i els projectes en si no són complexos quant a infraestructura. Aquest article proporcionarà instruccions per instal·lar Nomad, fusionar dos nodes en un clúster i integrar Nomad amb Gitlab.

Configuració d'un clúster Nomad amb Consul i integració amb Gitlab

banc de proves

Una mica sobre el banc de proves: s'utilitzen tres servidors virtuals amb característiques de 2 CPU, 4 RAM, SSD de 50 Gb, units en una xarxa local comuna. Els seus noms i adreces IP:

  1. nomad-livelinux-01: 172.30.0.5
  2. nomad-livelinux-02: 172.30.0.10
  3. cònsol-livelinux-01: 172.30.0.15

Instal·lació de Nomad, Cònsol. Creació d'un clúster nòmada

Comencem amb la instal·lació bàsica. Malgrat la facilitat d'instal·lació, ho descriuré pel bé de la integritat de l'article: de fet, es va crear a partir d'esborranys i notes per a un accés ràpid en cas de necessitat.

Abans de passar a la pràctica, parlarem de la part teòrica, perquè en aquesta etapa és important entendre l'estructura futura.

Tenim dos nodes nòmades i volem combinar-los en un clúster, també per al futur necessitarem l'escalat automàtic del clúster; per això necessitem Cònsol. Amb aquesta eina, agrupar i afegir nous nodes es converteix en una tasca molt senzilla: el node Nomad creat es connecta a l'agent Cònsol i després es connecta al clúster Nomad existent. Per tant, al principi instal·larem el servidor Cònsol, configurarem l'autorització http bàsica per al panell web (per defecte és sense autorització i es pot accedir des d'una adreça externa), així com els mateixos agents Cònsol als servidors Nomad, després que només procedirem a Nomad.

Instal·lar les eines de HashiCorp és molt senzill: en essència, només movem el fitxer binari al directori bin, configurem el fitxer de configuració de l'eina i creem el seu fitxer de servei.

Baixeu el binari de Consul i extreu-lo al directori inicial de l'usuari:

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/

Ara tenim el binari del cònsol preparat per a una major personalització.

Per treballar amb Consul, hem de generar una clau única mitjançant l'ordre keygen:

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

Passem a la configuració de Consul, creeu un directori /etc/consul.d/ amb la següent estructura:

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

El directori d'arrencada contindrà el fitxer de configuració config.json: en ell establirem la configuració del Cònsol. El seu contingut:

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

Analitzem per separat les principals directrius i els seus significats:

  • bootstrap: veritat. Activa l'addició automàtica de nous nodes si estan connectats. Observo que aquí no indiquem el nombre exacte de nodes esperats.
  • servidor: veritat. Activa el mode de servidor. El cònsol d'aquesta màquina virtual actuarà com a únic servidor i mestre de moment, la VM de Nomad serà client.
  • centre de dades: dc1. Especifiqueu el nom del centre de dades per crear el clúster. Ha de ser idèntic tant als clients com als servidors.
  • xifrar: la teva clau. La clau, que també ha de ser única i coincidir en tots els clients i servidors. Generat mitjançant l'ordre consul keygen.
  • start_join. En aquesta llista, especifiquem una llista d'adreces IP a les quals es realitzarà la connexió. De moment, només deixem la nostra pròpia adreça.

En aquest punt, podem començar a cònsol mitjançant la línia d'ordres:

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

Aquesta és una bona manera de depurar ara, però no funcionarà de manera permanent per raons òbvies. Creem un fitxer de servei per gestionar Consul mitjançant systemd:

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

Contingut del fitxer Consul.service: 

[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

Executeu Consul mitjançant systemctl:

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

Comprovem: el nostre servei s'hauria d'executar, i executant l'ordre dels membres del cònsol hauríem de veure el nostre servidor:

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

El següent pas: instal·lar Nginx i configurar el proxy, autorització http. Instal·leu nginx mitjançant el gestor de paquets i al directori /etc/nginx/sites-enabled creeu un fitxer de configuració consul.conf amb el contingut següent:

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

No oblideu crear un fitxer .htpasswd i generar-hi un nom d'usuari i una contrasenya. Aquest element és necessari perquè el panell web no estigui disponible per a tothom que conegui el nostre domini. Tanmateix, quan configurem Gitlab, haurem de rebutjar-ho; en cas contrari, no podrem desplegar la nostra aplicació a Nomad. Al meu projecte, tant Gitlab com Nomad només estan a la xarxa grisa, de manera que aquí no hi ha cap problema.

Als dos servidors restants, instal·leu els agents Consul segons les instruccions següents. Repetim els passos amb el fitxer binari:

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/

Per analogia amb el servidor anterior, creem un directori per als fitxers de configuració /etc/consul.d amb l'estructura següent:

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

Contingut del fitxer 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
     }

Desem els canvis i procedim a configurar el fitxer de servei, el seu contingut és:

/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

Comencem cònsol al servidor. Ara, després de començar, hauríem de veure el servei configurat als membres de nsul. Això significarà que s'ha connectat correctament al clúster com a client. Repetiu el mateix al segon servidor i després podem començar a instal·lar i configurar Nomad.

Una instal·lació més detallada de Nomad es descriu a la seva documentació oficial. Hi ha dos mètodes d'instal·lació tradicionals: descarregar un fitxer binari i compilar des de la font. Escolliré el primer camí.

Nota: el projecte es desenvolupa molt ràpidament, sovint es publiquen noves actualitzacions. Potser, quan s'acabi l'article, es publicarà una nova versió. Per tant, abans de llegir, recomano comprovar la versió actual de Nomad en aquest moment i descarregar-la. 

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

Després de desempaquetar, obtindrem un fitxer binari Nomad de 65 MB; s'ha de moure a /usr/local/bin.

Creem un directori de dades per a Nomad i editem el seu fitxer de servei (probablement no existirà al principi):

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

Inseriu allà les línies següents:

[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

Tanmateix, no tenim pressa per llançar Nomad: encara no hem creat el seu fitxer de configuració:

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

L'estructura de directoris resultant serà la següent:

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

El fitxer nomad.hcl ha de contenir la configuració següent:

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

Contingut del fitxer 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
}

No oblideu canviar el fitxer de configuració al segon servidor: haureu de canviar el valor de la directiva http allà.

L'última cosa en aquesta etapa és configurar Nginx per proxy i instal·lar l'autorització http. Contingut del fitxer 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 "Password-protected Area";
        }
        
}

Ara podem accedir al panell web a través de la xarxa externa. Connecteu-vos i aneu a la pàgina de servidors:

Configuració d'un clúster Nomad amb Consul i integració amb Gitlab
Imatge 1. Llista de servidors d'un clúster Nomad

Els dos servidors es mostren correctament al panell, veurem el mateix a la sortida de l'ordre d'estat del node nòmada:

Configuració d'un clúster Nomad amb Consul i integració amb Gitlab
Imatge 2. Sortida de l'ordre d'estat del node nòmada

Què passa amb el cònsol? Fem una ullada. Aneu al tauler de control de Cònsol, a la pàgina de nodes:
Configuració d'un clúster Nomad amb Consul i integració amb Gitlab
Imatge 3. Llista de nodes del clúster Cònsol

Ara tenim a punt Nomad, treballant conjuntament amb Cònsol. En l'etapa final, passarem a la part més interessant: configurarem el lliurament de contenidors Docker de Gitlab a Nomad, i també parlarem d'algunes de les seves altres característiques distintives.

Creació d'un Gitlab Runner

Per desplegar imatges docker a Nomad, utilitzarem un corredor independent amb el fitxer binari de Nomad a dins (aquí, per cert, es pot observar una característica més de les aplicacions Hashicorp: individualment són l'únic fitxer binari). Carregueu-lo al directori del corredor. Creem-hi un Dockerfile senzill amb el contingut següent:


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

En el mateix projecte, creeu .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}

Com a resultat, tindrem una imatge disponible del corredor Nomad al Registre de Gitlab, ara podem anar directament al repositori del projecte, crear un Pipeline i configurar el treball nòmada de Nomad.

Configuració del projecte

Comencem amb el fitxer de la feina per a Nomad. El meu projecte en aquest article serà força primitiu: constarà d'una tasca. El contingut de .gitlab-ci serà el següent:

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

Aquí, el desplegament es fa manualment, però podeu configurar-lo per canviar el contingut del directori del projecte. Pipeline, en canvi, consta de dues etapes: des del muntatge de la imatge i el seu desplegament fins al nòmada. En la primera etapa, creem la imatge de Docker i l'enviem al nostre Registre, i en la segona etapa, iniciem la nostra feina a 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" {}
                }
            }
        }
    }
}

Tingueu en compte que tinc un registre privat i per obtenir una extracció correcta de la imatge de Docker, he d'iniciar sessió. La millor solució en aquest cas és concloure l'inici de sessió i la contrasenya a Vault i després integrar-la amb Nomad. Nomad admet Vault de manera nativa. Però primer, al mateix Vault, establirem les polítiques necessàries per a Nomad, que es poden descarregar:

# 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

Ara, un cop creades les polítiques necessàries, afegirem la integració amb Vault al bloc de tasques del fitxer job.nomad:

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

Utilitzo l'autorització del testimoni i l'escric directament aquí, també hi ha una opció per especificar el testimoni com a variable en iniciar l'agent nòmada:

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

Ara podem utilitzar claus amb Vault. El principi de funcionament és senzill: creem un fitxer al treball Nomad que emmagatzemarà els valors de les variables, per exemple:

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
}

Amb aquest senzill enfocament, podeu configurar el lliurament de contenidors al clúster Nomad i treballar-hi en el futur. Diré que fins a cert punt simpatizo amb Nomad: és més adequat per a projectes petits on Kubernetes pot causar dificultats addicionals i no aconseguirà tot el seu potencial. A més, Nomad és ideal per a principiants: és fàcil d'instal·lar i configurar. Tanmateix, en provar alguns projectes, em trobo amb el problema de les seves primeres versions: moltes funcions bàsiques simplement no existeixen o no funcionen correctament. Tanmateix, crec que Nomad seguirà desenvolupant-se i en el futur adquirirà les funcions que tothom necessita.

Autor: Ilya Andreev, editat per Alexey Zhadan i l'equip de Live Linux


Font: www.habr.com

Afegeix comentari