Introductie
De laatste tijd is de populariteit van Kubernetes snel gegroeid: steeds meer projecten implementeren het. Ik wilde een orkestrator als Nomad aanraken: het is perfect voor projecten die al andere oplossingen van HashiCorp gebruiken, bijvoorbeeld Vault en Consul, en de projecten zelf zijn niet complex qua infrastructuur. Dit materiaal bevat instructies voor het installeren van Nomad, het combineren van twee knooppunten in een cluster en het integreren van Nomad met Gitlab.
Testbank
Iets over de testbank: er worden drie virtuele servers gebruikt met de kenmerken van 2 CPU, 4 RAM, 50 Gb SSD, verenigd in een gemeenschappelijk lokaal netwerk. Hun namen en IP-adressen:
- 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. Een Nomad-cluster maken
Laten we beginnen met de basisinstallatie. Hoewel de opzet eenvoudig was, zal ik deze beschrijven omwille van de integriteit van het artikel: het is in wezen gemaakt op basis van concepten en notities voor snelle toegang wanneer dat nodig is.
Voordat we met de praktijk beginnen, zullen we het theoretische deel bespreken, omdat het in dit stadium belangrijk is om de toekomstige structuur te begrijpen.
We hebben twee nomadenknooppunten en we willen ze combineren tot een cluster, en in de toekomst zullen we ook automatische clusterschaling nodig hebben - hiervoor hebben we Consul nodig. Met deze tool wordt het clusteren en toevoegen van nieuwe knooppunten een heel eenvoudige taak: het gemaakte Nomad-knooppunt maakt verbinding met de Consul-agent en maakt vervolgens verbinding met het bestaande Nomad-cluster. Daarom zullen we in het begin de Consul-server installeren, de basis http-autorisatie voor het webpaneel configureren (deze is standaard zonder autorisatie en toegankelijk via een extern adres), evenals de Consul-agenten zelf op Nomad-servers, waarna we gaan alleen verder naar Nomad.
Het installeren van de tools van HashiCorp is heel eenvoudig: in wezen verplaatsen we gewoon het binaire bestand naar de map bin, stellen we het configuratiebestand van de tool in en maken we het servicebestand.
Download het binaire Consul-bestand 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 een kant-en-klaar consul-binair bestand voor verdere configuratie.
Om met Consul te kunnen werken, moeten we een unieke sleutel maken met behulp van de keygen-opdracht:
root@consul-livelinux-01:~# consul keygen
Laten we verder gaan met het instellen van de Consul-configuratie, waarbij we een map /etc/consul.d/ maken met de volgende structuur:
/etc/consul.d/
├── bootstrap
│ └── config.jsonDe bootstrap-directory bevat een configuratiebestand config.json - daarin zullen we de Consul-instellingen instellen. De inhoud:
{
"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 betekenis afzonderlijk bekijken:
- bootstrap: WAAR. We maken automatische toevoeging van nieuwe knooppunten mogelijk als ze verbonden zijn. Ik merk op dat we hier niet het exacte aantal verwachte knooppunten aangeven.
- server: WAAR. Schakel de servermodus in. Consul op deze virtuele machine zal op dit moment fungeren als de enige server en master, de VM van Nomad zal de clients zijn.
- datacenter: dc1. Geef de naam op van het datacenter waar het cluster moet worden gemaakt. Het moet identiek zijn op zowel clients als servers.
- encrypt: je sleutel. De sleutel, die bovendien uniek moet zijn en op alle clients en servers moet overeenkomen. Gegenereerd met behulp van het consul keygen-commando.
- start_deelnemen. In deze lijst geven we een lijst met IP-adressen aan waarmee verbinding zal worden gemaakt. Op dit moment laten we alleen ons eigen adres achter.
Op dit punt kunnen we consul uitvoeren via de opdrachtregel:
root@consul-livelinux-01:~# /usr/local/bin/consul agent -config-dir /etc/consul.d/bootstrap -uiDit is nu een goede manier om fouten op te sporen, maar om voor de hand liggende redenen kunt u deze methode niet voortdurend gebruiken. Laten we een servicebestand maken om Consul via systemd te beheren:
root@consul-livelinux-01:~# nano /etc/systemd/system/consul.service
Inhoud van het consul.service-bestand:
[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.targetStart Consul via systemctl:
root@consul-livelinux-01:~# systemctl start consul
Laten we eens kijken: onze service moet actief zijn, en door het commando van de consulleden 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 dc1 <all>Volgende fase: Nginx installeren en proxying en http-autorisatie instellen. We installeren nginx via de pakketbeheerder en in de map /etc/nginx/sites-enabled maken we een 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 "Password-protected Area";
}
}Vergeet niet een .htpasswd-bestand te maken en hiervoor een gebruikersnaam en wachtwoord te genereren. Dit item is vereist zodat het webpaneel niet beschikbaar is voor iedereen die ons domein kent. Bij het opzetten van Gitlab zullen we hier echter van af moeten zien, anders kunnen we onze applicatie niet op Nomad implementeren. In mijn project bevinden zowel Gitlab als Nomad zich alleen op het grijze web, dus hier is er geen probleem.
Op de overige twee servers installeren we Consul-agenten volgens de volgende instructies. We herhalen 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/Naar analogie met de vorige server creëren we een directory voor configuratiebestanden /etc/consul.d met de volgende structuur:
/etc/consul.d/
├── client
│ └── config.jsonInhoud van het config.json-bestand:
{
"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
}Sla de wijzigingen op en ga verder met het instellen van het servicebestand, de inhoud ervan:
/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.targetWe lanceren consul op de server. Nu, na de lancering, zouden we de geconfigureerde service in nsul-leden moeten zien. Dit betekent dat het als client met succes verbinding heeft gemaakt met het cluster. Herhaal hetzelfde op de tweede server en daarna kunnen we beginnen met het installeren en configureren van Nomad.
Een meer gedetailleerde installatie van Nomad wordt beschreven in de officiële documentatie. Er zijn twee traditionele installatiemethoden: een binair bestand downloaden en vanaf de broncode compileren. Ik kies voor de eerste methode.
Noot: Het project ontwikkelt zich zeer snel, er worden vaak nieuwe updates uitgebracht. Misschien komt er tegen de tijd dat dit artikel klaar is een nieuwe versie uit. Daarom raad ik aan om, voordat u gaat lezen, de huidige versie van Nomad te controleren en deze 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 ontvangen we een binair Nomad-bestand van 65 MB - het moet worden verplaatst naar /usr/local/bin.
Laten we een gegevensmap voor Nomad maken en het servicebestand bewerken (deze zal in het begin waarschijnlijk niet bestaan):
root@nomad-livelinux-01:~# mkdir --parents /opt/nomad
root@nomad-livelinux-01:~# nano /etc/systemd/system/nomad.servicePlak 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 hebben echter geen haast om nomad te lanceren - we hebben het configuratiebestand nog niet gemaakt:
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 mapstructuur zal als volgt zijn:
/etc/nomad.d/
├── nomad.hcl
└── server.hclHet nomad.hcl-bestand moet de volgende configuratie bevatten:
datacenter = "dc1"
data_dir = "/opt/nomad"Inhoud van het server.hcl-bestand:
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 het configuratiebestand op de tweede server te wijzigen - daar moet u de waarde van de http-richtlijn wijzigen.
Het laatste dat in deze fase moet gebeuren, is het configureren van Nginx voor proxying en het instellen van http-autorisatie. Inhoud van het nomad.conf-bestand:
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";
}
}Nu hebben we toegang tot het webpaneel via een extern netwerk. Maak verbinding en ga naar de serverspagina:
Afbeelding 1. Lijst met servers in het Nomad-cluster
Beide servers worden met succes weergegeven in het paneel, we zullen hetzelfde zien in de uitvoer van het nomad node-statuscommando:
Afbeelding 2. Uitvoer van het statuscommando van het nomadenknooppunt
Hoe zit het met de consul? Laten we eens kijken. Ga naar het Consul controlepaneel, naar de knooppuntenpagina:
Afbeelding 3. Lijst met knooppunten in het Consul-cluster
Nu hebben we een voorbereide Nomade die samenwerkt met Consul. In de laatste fase komen we bij het leuke gedeelte: het opzetten van de levering van Docker-containers van Gitlab naar Nomad, en ook praten over enkele van de andere onderscheidende kenmerken ervan.
Gitlab Runner maken
Om docker-images op Nomad te implementeren, zullen we een aparte runner gebruiken met het binaire Nomad-bestand erin (hier kunnen we trouwens nog een ander kenmerk van Hashicorp-applicaties opmerken - afzonderlijk zijn ze één enkel binair bestand). Upload het naar de runner-map. Laten we er een eenvoudig Dockerbestand voor maken met de volgende inhoud:
FROM alpine:3.9
RUN apk add --update --no-cache libc6-compat gettext
COPY nomad /usr/local/bin/nomad
In hetzelfde project maken 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}Als gevolg hiervan hebben we een beschikbare afbeelding van de Nomad-runner in het Gitlab-register. Nu kunnen we rechtstreeks naar de projectrepository gaan, een pijplijn maken en de nomad-taak van Nomad configureren.
Projectopstelling
Laten we beginnen met het taakbestand voor Nomad. Mijn project in dit artikel zal vrij primitief 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}' < 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: manualHier vindt de implementatie handmatig plaats, maar u kunt deze configureren om de inhoud van de projectmap te wijzigen. Pipeline bestaat uit twee fasen: het samenstellen van afbeeldingen en de implementatie ervan bij nomaden. In de eerste fase stellen we een docker-image samen en plaatsen deze in ons register, en in de tweede fase lanceren we onze taak 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" {}
}
}
}
}
}Houd er rekening mee dat ik een privéregister heb en om succesvol een docker-image te kunnen ophalen, moet ik daarop inloggen. De beste oplossing in dit geval is om een login en wachtwoord in Vault in te voeren en deze vervolgens met Nomad te integreren. Nomad ondersteunt Vault standaard. Maar laten we eerst het benodigde beleid voor Nomad in Vault zelf installeren; ze kunnen worden gedownload:
# 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 het noodzakelijke beleid hebben gemaakt, zullen we integratie met Vault toevoegen aan het taakblok in het job.nomad-bestand:
vault {
enabled = true
address = "https://vault.domain.name:8200"
token = "token"
}Ik gebruik autorisatie per token en registreer deze hier direct, er is ook de mogelijkheid om het token als variabele op te geven bij het starten van nomad agent:
$ VAULT_TOKEN=<token> nomad agent -config /path/to/config
Nu kunnen we de sleutels gebruiken met Vault. Het werkingsprincipe is eenvoudig: we maken een bestand in Nomad Job waarin de waarden van variabelen worden opgeslagen, bijvoorbeeld:
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
}Met deze eenvoudige aanpak kunt u de levering van containers aan het Nomad-cluster configureren en er in de toekomst mee werken. Ik zal zeggen dat ik tot op zekere hoogte sympathiseer met Nomad - het is meer geschikt voor kleine projecten waarbij Kubernetes extra complexiteit kan veroorzaken en het volledige potentieel ervan niet zal realiseren. Bovendien is Nomad perfect voor beginners: het is eenvoudig te installeren en te configureren. Bij het testen van sommige projecten stuit ik echter op een probleem met de vroege versies ervan: veel basisfuncties zijn er simpelweg niet of ze werken niet correct. Ik geloof echter dat Nomad zich zal blijven ontwikkelen en in de toekomst de functies zal verwerven die iedereen nodig heeft.
Auteur: Ilya Andreev, onder redactie van Alexey Zhadan en het Live Linux-team
Bron: www.habr.com