Inleiding
De populariteit van Kubernetes groeit de laatste tijd snel — steeds meer projecten implementeren het. Ik wil echter een orkestrator zoals Nomad bespreken: deze is uitstekend geschikt voor projecten die al gebruikmaken van andere oplossingen van HashiCorp, zoals Vault en Consul, en waarvan de infrastructuur niet al te complex is. Dit materiaal bevat een instructie voor het installeren van Nomad, het samenvoegen van twee knooppunten in een cluster, en de integratie van Nomad met GitLab.
Teststand
Even iets over de testomgeving: er worden drie virtuele servers gebruikt met de specificaties 2 CPU, 4 RAM, 50 Gb SSD, verbonden in een gemeenschappelijk lokaal netwerk. Hun namen en IP-adressen zijn:
- nomad-livelinux-01: 172.30.0.5
- nomad-livelinux-02: 172.30.0.10
- consul-livelinux-01: 172.30.0.15
Installatie van Nomad, Consul. Aanmaken van een Nomad-cluster
Laten we beginnen met de basisinstallatie. Ondanks de eenvoud van de installatie, zal ik deze beschrijven voor de volledigheid van het artikel: het is in feite gemaakt vanuit concepten en notities voor snelle toegang in geval van nood.
Voordat we met de praktijk beginnen, bespreken we het theoretische gedeelte, omdat het op dit moment belangrijk is om de toekomstige structuur te begrijpen.
We hebben twee Nomad-knooppunten en we willen deze in een cluster samenvoegen; op termijn hebben we ook automatische schaalvergroting van het cluster nodig — hiervoor hebben we Consul nodig. Met behulp van deze tool wordt clustering en het toevoegen van nieuwe knooppunten een heel eenvoudige taak: het aangemaakte Nomad-knooppunt maakt verbinding met de Consul-agent, waarna het verbinding maakt met het bestaande Nomad-cluster. Daarom zullen we eerst de Consul-server installeren, de basis HTTP-authenticatie voor het webpaneel configureren (deze is standaard niet geauthenticeerd en kan toegankelijk zijn via een extern adres), en ook de Consul-agenten op de Nomad-servers installeren, waarna we beginnen met Nomad.
De installatie van de tools van HashiCorp is erg eenvoudig: in feite verplaatsen we gewoon het binaire bestand naar de bin-directory, configureren we het configuratiebestand van de tool en creëren we zijn servicebestand.
Download het binaire bestand van Consul en pak het uit in de thuismap van de gebruiker:
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/Nu hebben we het binaire bestand consul klaar voor verdere configuratie.
Om met Consul te werken, moeten we een unieke sleutel genereren met het commando keygen:
root@consul-livelinux-01:~# consul keygen
Laten we overgaan tot het configureren van Consul, we maken een directory /etc/consul.d/ met de volgende structuur:
/etc/consul.d/
├── bootstrap
│ └── config.jsonIn de bootstrap directory bevindt zich het configuratiebestand config.json — hierin stellen we de instellingen voor Consul in. De inhoud ervan is:
{
"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"]
}Laten we de belangrijkste richtlijnen en hun waarden apart bekijken:
- bootstrap: true. We schakelen de automatische toevoeging van nieuwe knooppunten in wanneer ze verbinding maken. Ik wil opmerken dat we hier niet het exacte aantal verwachte knooppunten opgeven.
- server: true. We schakelen de servermodus in. Consul zal op deze virtuele machine momenteel de enige server en master zijn, de VM van Nomad zal als klanten fungeren.
- datacenter: dc1. We geven de naam van het datacenter op voor het creëren van een cluster. Deze moet identiek zijn op zowel de klanten als de servers.
- encrypt: your-key. Deze sleutel moet ook uniek zijn en overeenkomen op alle klanten en servers. Het wordt gegenereerd met behulp van het commando consul keygen.
- start_join. In deze lijst geven we een lijst van IP-adressen op waarmee verbinding zal worden gemaakt. Voor nu laten we alleen ons eigen adres staan.
In dit stadium kunnen we Consul starten via de opdrachtregel:
root@consul-livelinux-01:~# /usr/local/bin/consul agent -config-dir /etc/consul.d/bootstrap -uiDit is een redelijke manier van debuggen momenteel, maar het is om voor de lange termijn deze methode niet consistent te gebruiken om voor de hand liggende redenen. Laten we een servicebestand maken om Consul via systemd te beheren:
root@consul-livelinux-01:~# nano /etc/systemd/system/consul.service
De inhoud van het bestand 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.targetWe starten Consul met systemctl:
root@consul-livelinux-01:~# systemctl start consul
We controleren: onze service moet draaien en door het commando consul members uit te voeren zouden we onze server moeten zien:
root@consul-livelinux:/etc/consul.d# consul members
consul-livelinux 172.30.0.15:8301 alive server 1.5.0 2 dc1De volgende stap: installatie van Nginx en configuratie van proxy, http-authenticatie. We installeren nginx via de pakketbeheerder en in de directory /etc/nginx/sites-enabled maken we het configuratiebestand consul.conf met de volgende inhoud:
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 "Wachtwoord beschermd gebied";
}
}Vergeet niet een .htpasswd-bestand te maken en ervoor een gebruikersnaam en wachtwoord te genereren. Dit is nodig zodat het webpaneel niet toegankelijk is voor iedereen die onze domeinnaam kent. Bij het instellen van Gitlab moeten we hier echter van afzien, anders kunnen we onze applicatie niet in Nomad implementeren. In mijn project bevinden zowel Gitlab als Nomad zich alleen in het interne netwerk, dus daar is dit probleem niet.
Op de andere twee servers installeren we Consul-agents volgens de volgende instructies. Herhaal de stappen met het binaire bestand:
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/We maken een map voor configuratiebestanden /etc/consul.d aan met de volgende structuur:
/etc/consul.d/
├── client
│ └── config.jsonInhoud van het bestand 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", # lokale VM-adres
"start_join": ["172.30.0.15"], # externe Consul-serveradres
"ports": {
"dns": 53
}We slaan de wijzigingen op en gaan verder met het configureren van het servicebestand, de inhoud is als volgt:
/etc/systemd/system/consul.service:
[Unit]
Description="HashiCorp Consul - Een oplossing voor service mesh"
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.targetWe starten Consul op de server. Nu, na de opstart, zouden we de geconfigureerde service in nsul members moeten zien. Dit betekent dat deze succesvol is verbonden met het cluster als client. Herhaal hetzelfde op de tweede server en daarna kunnen we beginnen met de installatie en configuratie van Nomad.
Een gedetailleerdere installatie van Nomad is beschreven in de officiële documentatie. Er zijn twee traditionele manieren om het te installeren: het downloaden van het binaire bestand en het compileren vanuit de bron. Ik kies voor de eerste methode.
Opmerking: het project ontwikkelt zich erg snel en er komen vaak nieuwe updates uit. Mogelijk is er tegen de tijd dat het artikel af is een nieuwe versie beschikbaar. Daarom raad ik aan om voor het lezen te controleren welke versie van Nomad momenteel actueel is en die te downloaden.
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.dNa het uitpakken krijgen we een binair bestand van Nomad van 65 MB - dit moet naar /usr/local/bin worden verplaatst.
Laten we een data-directory voor Nomad aanmaken en het servicebestand bewerken (dit bestaat waarschijnlijk in het begin nog niet):
root@nomad-livelinux-01:~# mkdir --parents /opt/nomad
root@nomad-livelinux-01:~# nano /etc/systemd/system/nomad.servicePlaats daar de volgende regels:
[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.targetWe zijn echter nog niet klaar om nomad te starten - we hebben de configuratiebestand nog niet aangemaakt:
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
De uiteindelijke directorystructuur zal er als volgt uitzien:
/etc/nomad.d/
├── nomad.hcl
└── server.hclHet bestand nomad.hcl moet de volgende configuratie bevatten:
datacenter = "dc1"
data_dir = "/opt/nomad"Inhoud van het bestand 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
}Vergeet niet om het configuratiebestand op de tweede server te wijzigen - daar moet de waarde van de http-directive worden aangepast.
Als laatste op deze fase staat de configuratie van Nginx voor proxying en het instellen van http-authenticatie. Inhoud van het bestand 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-beveiligd gebied";
}
}Nu kunnen we de webinterface via het externe netwerk bereiken. We verbinden en gaan naar de pagina servers:
Afbeelding 1. Lijst van servers in de Nomad-cluster
Beide servers worden succesvol weergegeven in het paneel, hetzelfde zien we in de uitvoer van de opdracht nomad node status:
Afbeelding 2. Uitvoer van de opdracht nomad node status
Hoe zit het met de Consul-kant? Laten we eens kijken. We gaan naar het Consul beheerpaneel, naar de pagina nodes:
Afbeelding 3. Lijst van nodes in de Consul-cluster
Nu hebben we een voorbereid Nomad, dat samenwerkt met Consul. In de laatste fase zullen we doorgaan naar het meest interessante: we zullen de levering van Docker-containers vanuit Gitlab naar Nomad instellen en enkele andere kenmerken ervan bespreken.
Gitlab Runner aanmaken
Voor het implementeren van Docker-images in Nomad gaan we een aparte runner gebruiken met het binaire bestand van Nomad erin (hierbij kan nog een andere eigenschap van Hashicorp-applicaties worden opgemerkt - afzonderlijk zijn ze een enkel binaire bestand). Upload het naar de directory van de runner. Voor hem creëren we een simpele Dockerfile met de volgende inhoud:
FROM alpine:3.9
RUN apk add --update --no-cache libc6-compat gettext
COPY nomad /usr/local/bin/nomad
In dit project creëren we .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}Uiteindelijk hebben we een beschikbare image van de Nomad-runner in de Gitlab Registry. Nu kunnen we direct naar het projectrepository gaan, een Pipeline maken en de nomad job van Nomad instellen.
Projectconfiguratie
Laten we beginnen met de job-bestanden voor Nomad. Mijn project in dit artikel zal vrij eenvoudig zijn: het zal uit één taak bestaan. De inhoud van .gitlab-ci zal als volgt zijn:
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}' 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: manualHier wordt de implementatie handmatig uitgevoerd, maar je kunt deze configureren om wijzigingen in de projectdirectory te detecteren. De Pipeline bestaat uit twee fasen: het bouwen van de image en het implementeren ervan in Nomad. In de eerste fase bouwen we de Docker-image en pushen deze naar onze Registry, en in de tweede fase starten we onze job in 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" {}
}
}
}
}
}Let op, ik heb een gesloten Registry en ik moet me aanmelden om succesvol een Docker-image te pullen. De beste oplossing in dit geval is om de gebruikersnaam en het wachtwoord in Vault op te slaan en deze vervolgens te integreren met Nomad. Nomad ondersteunt Vault native. Maar laten we eerst de nodige policy voor Nomad in Vault instellen, ze kunnen worden geladen:
# 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.jsonNu we de nodige policy hebben gecreëerd, voegen we in de task-block in het job.nomad-bestand de integratie met Vault toe:
vault {
enabled = true
address = "https://vault.domain.name:8200"
token = "token"
}Ik gebruik token-authenticatie en schrijf deze hier direct in; er is ook de mogelijkheid om de token als een variabele op te geven bij het starten van de nomad agent:
$ VAULT_TOKEN= nomad agent -config /path/to/config
Nu kunnen we sleutels uit Vault gebruiken. Het principe is eenvoudig: we creëren een bestand in de Nomad-job, dat de waarden van variabelen zal opslaan, bijvoorbeeld:
template {
data = <<EOH
{{with secret "secrets/pipeline-keys"}}
REGISTRY_LOGIN="{{ .Data.REGISTRY_LOGIN }}"
REGISTRY_PASSWORD="{{ .Data.REGISTRY_PASSWORD }}{{ end }}"
EOH
destination = "secrets/service-name.env"
env = true
}Met deze eenvoudige aanpak kunnen we de levering van containers naar de Nomad-cluster instellen en er later mee werken. Ik moet zeggen dat ik op een bepaalde manier sympathie voor Nomad heb — het is beter geschikt voor kleine projecten, waar Kubernetes extra complicaties kan veroorzaken en niet zijn volledige potentieel kan waarmaken. Bovendien is Nomad uitstekend voor beginners — het is eenvoudig te installeren en te configureren. Tijdens het testen op enkele projecten ben ik echter tegen problemen met de vroege versies gestoten — veel basisfuncties ontbreken of werken niet correct. Desalniettemin geloof ik dat Nomad verder zal ontwikkelen en in de toekomst de nodige functies voor iedereen zal bieden.
Auteur: Ilya Andreev, onder redactie van Alexey Zhadán en het team van «Live Linux»
Bron: habr.com
