EinfĂĽhrung
In letzter Zeit wächst die Popularität von Kubernetes rasant - immer mehr Projekte setzen es zu Hause um. Ich wollte einen Orchestrator wie Nomad ansprechen: Er eignet sich perfekt für Projekte, die bereits andere Lösungen von HashiCorp verwenden, z. B. Vault und Consul, und die Projekte selbst sind in Bezug auf die Infrastruktur nicht kompliziert. Dieser Artikel enthält Anweisungen zum Installieren von Nomad, zum Kombinieren von zwei Knoten in einem Cluster und zum Integrieren von Nomad in Gitlab.
PrĂĽfstand
Ein bisschen ĂĽber den PrĂĽfstand: Es werden drei virtuelle Server mit den Eigenschaften von 2 CPU, 4 RAM, 50 Gb SSD verwendet, die in einem gemeinsamen lokalen Netzwerk vereint sind. Ihre Namen und IP-Adressen:
- nomad-livelinux-01 : 172.30.0.5
- nomad-livelinux-02 : 172.30.0.10
- consul-livelinux-01 : 172.30.0.15
Installation von Nomad, Consul. Erstellen eines Nomadenclusters
Fahren wir mit der Grundinstallation fort. Trotz der einfachen Installation werde ich es für die Integrität des Artikels beschreiben: Tatsächlich wurde es aus Entwürfen und Notizen erstellt, um bei Bedarf schnell darauf zugreifen zu können.
Bevor wir mit der Praxis beginnen, werden wir den theoretischen Teil diskutieren, da es in dieser Phase wichtig ist, die zukĂĽnftige Struktur zu verstehen.
Wir haben zwei Nomadenknoten und wollen sie zu einem Cluster zusammenfassen. Für die Zukunft benötigen wir eine automatische Skalierung des Clusters - dafür benötigen wir Consul. Mit diesem Tool wird das Clustering und Hinzufügen neuer Knoten zu einer sehr einfachen Aufgabe: Der erstellte Nomad-Knoten stellt eine Verbindung zum Consul-Agenten und dann eine Verbindung zum vorhandenen Nomad-Cluster her. Daher werden wir zu Beginn den Consul-Server installieren, die grundlegende http-Autorisierung für das Webpanel konfigurieren (standardmäßig ohne Autorisierung und über eine externe Adresse zugänglich) sowie die Consul-Agenten selbst auf den Nomad-Servern. Danach starten wir einfach Nomad.
Die Installation der HashiCorp-Tools ist sehr einfach: Tatsächlich verschieben wir die Binärdatei einfach in das bin-Verzeichnis, konfigurieren die Konfigurationsdatei des Tools und erstellen die Servicedatei.
Laden Sie die Consul-Binärdatei herunter und entpacken Sie sie in das Home-Verzeichnis des Benutzers:
root@consul-livelinux-01:~
Jetzt haben wir eine vorgefertigte binäre Konsulendatei zur weiteren Konfiguration.
Um mit Consul arbeiten zu können, müssen wir mit dem Befehl keygen einen eindeutigen Schlüssel erstellen:
root@consul-livelinux-01:~
Fahren wir mit der Konfiguration des Konsuls fort und erstellen das Verzeichnis /etc/consul.d/ mit der folgenden Struktur:
/etc/consul.d/ ├── bootstrap │ └── config.json
Das Bootstrap-Verzeichnis enthält die Konfigurationsdatei config.json - darin werden die Consul-Einstellungen festgelegt. Sein Inhalt:
{ "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"] }
Lassen Sie uns die wichtigsten Richtlinien und ihre Bedeutung getrennt untersuchen:
- Bootstrap : wahr. Wir aktivieren das automatische HinzufĂĽgen neuer Knoten, wenn diese verbunden sind. Ich stelle fest, dass wir hier nicht die genaue Anzahl der erwarteten Knoten angeben.
- Server : wahr. Schalten Sie den Servermodus ein. Der Konsul auf dieser virtuellen Maschine wird derzeit der einzige Server und Master sein, VM Nomad wird Clients sein.
- Rechenzentrum : dc1. Geben Sie den Namen des Rechenzentrums an, um einen Cluster zu erstellen. Es muss auf Clients und Servern identisch sein.
- verschlĂĽsseln : Ihr SchlĂĽssel. Ein SchlĂĽssel, der auch eindeutig sein und auf allen Clients und Servern ĂĽbereinstimmen muss. Wird mit dem Befehl consul keygen generiert.
- start_join . In dieser Liste geben wir die Liste der IP-Adressen an, zu denen die Verbindung hergestellt werden soll. Im Moment hinterlassen wir nur unsere eigene Adresse.
An diesem Punkt können wir den Konsul über die Befehlszeile starten:
root@consul-livelinux-01:~
Dies ist ein guter Weg, um jetzt zu debuggen. Die fortlaufende Verwendung dieser Methode funktioniert jedoch aus offensichtlichen GrĂĽnden nicht. Erstellen Sie eine Servicedatei fĂĽr die Verwaltung von Consul ĂĽber systemd:
root@consul-livelinux-01:~
Der Inhalt der Datei 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
FĂĽhren Sie Consul ĂĽber systemctl aus:
root@consul-livelinux-01:~
Wir ĂĽberprĂĽfen: Unser Dienst sollte gestartet werden, und durch AusfĂĽhren des Befehls der Konsulmitglieder sollten wir unseren Server sehen:
root@consul-livelinux:/etc/consul.d
Der nächste Schritt: Installieren von Nginx und Einrichten des Proxys, http-Autorisierung. Installieren Sie nginx über den Paketmanager und erstellen Sie die Konfigurationsdatei consul.conf im Verzeichnis / etc / nginx / sites-enabled mit den folgenden Inhalten:
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"; } }
Vergessen Sie nicht, eine .htpasswd-Datei zu erstellen und einen Benutzernamen und ein Passwort dafür zu generieren. Dieser Artikel ist erforderlich, damit das Webpanel nicht jedem zugänglich ist, der unsere Domain kennt. Bei der Konfiguration von Gitlab müssen wir dies jedoch aufgeben. Andernfalls können wir unsere Anwendung nicht für Nomad bereitstellen. In meinem Projekt befinden sich sowohl Gitlab als auch Nomad nur im grauen Netzwerk, daher gibt es kein solches Problem.
Installieren Sie auf den beiden anderen Servern die Consul-Agenten gemäß den folgenden Anweisungen. Wiederholen Sie die Schritte mit der Binärdatei:
root@nomad-livelinux-01:~
In Analogie zum vorherigen Server erstellen wir ein Verzeichnis fĂĽr die Konfigurationsdateien /etc/consul.d mit folgender Struktur:
/etc/consul.d/ ├── client │ └── config.json
Der Inhalt der Datei 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 } }
Wir speichern die Ă„nderungen und fahren mit der Konfiguration der Servicedatei und ihres Inhalts fort:
/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
Wir starten den Konsul auf dem Server. Nach dem Start sollte der konfigurierte Dienst nun in nsul-Mitgliedern angezeigt werden. Dies bedeutet, dass er als Client erfolgreich eine Verbindung zum Cluster hergestellt hat. Wiederholen Sie dies auf dem zweiten Server. Danach können Sie Nomad installieren und konfigurieren.
Eine detailliertere Installation von Nomad ist in der offiziellen Dokumentation beschrieben. Es gibt zwei traditionelle Installationsmethoden: Herunterladen einer Binärdatei und Kompilieren aus dem Quellcode. Ich werde die erste Methode wählen.
Hinweis : Das Projekt entwickelt sich sehr schnell, häufig werden neue Updates veröffentlicht. Möglicherweise wird eine neue Version veröffentlicht, wenn dieser Artikel fertiggestellt ist. Daher empfehle ich, vor dem Lesen die aktuelle Version von Nomad zu überprüfen und herunterzuladen.
root@nomad-livelinux-01:~
Nach dem Auspacken erhalten wir eine Nomad'a-Binärdatei mit einem Gewicht von 65 MB - sie muss nach / usr / local / bin verschoben werden.
Erstellen Sie ein Datenverzeichnis für Nomad und bearbeiten Sie dessen Servicedatei (diese wird höchstwahrscheinlich am Anfang nicht vorhanden sein):
root@nomad-livelinux-01:~
FĂĽgen Sie dort folgende Zeilen ein:
[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
Wir haben es jedoch nicht eilig, nomad auszufĂĽhren - wir haben die Konfigurationsdatei noch nicht erstellt:
root@nomad-livelinux-01:~
Die endgĂĽltige Verzeichnisstruktur lautet wie folgt:
/etc/nomad.d/ ├── nomad.hcl └── server.hcl
Die Datei nomad.hcl sollte die folgende Konfiguration enthalten:
datacenter = "dc1" data_dir = "/opt/nomad"
Der Inhalt der Datei 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 }
Vergessen Sie nicht, die Konfigurationsdatei auf dem zweiten Server zu ändern. Dort müssen Sie den Wert der http-Direktive ändern.
Das letzte in dieser Phase ist die Konfiguration von Nginx zum Proxying und Festlegen der http-Autorisierung. Der Inhalt der Datei 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"; } }
Jetzt können wir über ein externes Netzwerk auf das Webpanel zugreifen. Wir verbinden uns und gehen zur Serverseite:
Abbildung 1. Liste der Server in einem Nomad-Cluster
Beide Server werden erfolgreich im Bedienfeld angezeigt. Dies wird auch in der Ausgabe des Befehls nomad node status angezeigt:
Bild 2. Die Ausgabe des Nomadenknotenstatusbefehls
Was ist mit Konsul? Mal sehen. Wechseln Sie zum Consul-Kontrollfeld zur Knotenseite:
Abbildung 3. Liste der Knoten im Consul-Cluster
Jetzt haben wir Nomad in Zusammenarbeit mit Consul vorbereitet. In der letzten Phase werden wir mit dem interessantesten beginnen: Wir werden die Lieferung von Docker-Containern von Gitlab an Nomad konfigurieren und auch ĂĽber einige seiner anderen Besonderheiten sprechen.
Erstellen Sie Gitlab Runner
Für die Bereitstellung von Docker-Images für Nomad verwenden wir einen separaten Runner mit der darin enthaltenen Nomad-Binärdatei (hier kann übrigens eine weitere Funktion von Hashicorp-Anwendungen erwähnt werden - einzeln sind sie die einzige Binärdatei). Laden Sie es in das Runner-Verzeichnis herunter. Erstellen Sie für ihn die einfachste Docker-Datei mit den folgenden Inhalten:
FROM alpine:3.9 RUN apk add --update --no-cache libc6-compat gettext COPY nomad /usr/local/bin/nomad
Erstellen Sie im selben Projekt .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 Ergebnis haben wir ein zugängliches Image des Nomad-Läufers in der Gitlab-Registrierung. Jetzt können wir direkt zum Projekt-Repository gehen, eine Pipeline erstellen und den Nomad-Job Nomad konfigurieren.
Projekteinrichtung
Beginnen wir mit der Jobdatei fĂĽr Nomad. Mein Projekt in diesem Artikel wird ziemlich primitiv sein: Es wird aus einer Aufgabe bestehen. Der Inhalt von .gitlab-ci lautet wie folgt:
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
Hier erfolgt die Bereitstellung im manuellen Modus, Sie können sie jedoch so konfigurieren, dass der Inhalt des Projektverzeichnisses geändert wird. Die Pipeline besteht aus zwei Phasen: von der Montage des Images und seiner Bereitstellung bis zum Nomaden. In der ersten Phase sammeln wir das Docker-Image und verschieben es in unsere Registrierung. In der zweiten Phase starten wir unseren 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" {} } } } } }
Bitte beachten Sie, dass ich eine private Registrierung habe und mich für einen erfolgreichen Docker-Image-Pool anmelden muss. Die beste Lösung in diesem Fall ist die Eingabe eines Logins und eines Passworts in Vault mit der anschließenden Integration in Nomad. Nomad unterstützt Vault von Haus aus. Aber zuerst installieren wir in Vault selbst die erforderlichen Richtlinien für Nomad. Sie können sie herunterladen:
Nachdem wir die erforderlichen Richtlinien erstellt haben, fĂĽgen wir die Integration mit Vault in den Taskblock in der Datei job.nomad ein:
vault { enabled = true address = "https://vault.domain.name:8200" token = "token" }
Ich verwende die Berechtigung per Token und schreibe sie direkt hier. Es besteht auch die Möglichkeit, das Token als Variable anzugeben, wenn der Nomad Agent ausgeführt wird:
$ VAULT_TOKEN=<token> nomad agent -config /path/to/config
Jetzt können wir die Schlüssel mit Vault verwenden. Das Funktionsprinzip ist einfach: Wir erstellen im Nomad-Job eine Datei, in der die Werte von Variablen gespeichert werden, zum Beispiel:
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 }
Mit diesem einfachen Ansatz können Sie die Lieferung von Containern an den Nomad-Cluster konfigurieren und in Zukunft damit arbeiten. Ich werde sagen, dass ich bis zu einem gewissen Grad mit Nomad sympathisiere - es ist besser für kleine Projekte geeignet, bei denen Kubernetes zusätzliche Schwierigkeiten verursachen kann und sein Potenzial bis zum Ende nicht ausschöpft. Darüber hinaus ist Nomad perfekt für Anfänger - es ist einfach zu installieren und zu konfigurieren. Beim Testen einiger Projekte stoße ich jedoch auf das Problem früherer Versionen - viele Grundfunktionen existieren einfach nicht oder funktionieren nicht richtig. Trotzdem glaube ich, dass sich Nomad weiterentwickeln und in Zukunft alle notwendigen Funktionen übernehmen wird.
Gepostet von Ilya Andreev, bearbeitet von Alexei Zhadan und Live Linux Team