Nomad 0.5 Konfigurationsvorlagen: consul-template ist tot! es lebe consul-template!

Oder... hat Nomad das Consul-Template-Tool überflüssig gemacht? Wenn Sie Consul oder Vault für die Service-Erkennung oder die Verwaltung von Geheimnissen in Ihren Anwendungen einsetzen, werden Sie die gerade veröffentlichte Version 0.5 des Nomad-Workload-Schedulers lieben: Sie enthält eine neue 'Vorlagen'-Funktion zur dynamischen Generierung von Konfigurationsdateien aus Consul- und Vault-Daten für die von ihr ausgeführten Jobs. Die Bündelung von Consul-template als Sidecar für Ihre Anwendung ist nicht mehr notwendig. Nomad, Consul und Consul-template Vor einem Jahr fügte Nomad 0.2 Unterstützung für die automatische Registrierung von Aufträgen in Consul über einen Dienstkonfigurationsblock hinzu. Die Anwendungen selbst mussten sich jedoch noch um das Lesen von Daten aus Consul kümmern. Hierfür standen Ihnen die folgenden drei Optionen zur Verfügung:

1. Hinzufügen von Code in die Anwendung zur Abfrage der HTTP-API von Consul.
2. Konfiguration der Laufzeitumgebung zur Weiterleitung von Anfragen für *.consul an Consuls DNS-Schnittstelle.
3. Hinzufügen eines Sidecar-Tools zur Bereitstellung, das Consul abfragt und die Ergebnisse über reguläre Konfigurationsdateien an die Anwendung weiterleitet.

Option 1 ist sicherlich effektiv und leichtgewichtig, aber möglicherweise nicht praktikabel, wenn der Quellcode nicht verfügbar ist. Und selbst wenn dies der Fall ist, möchten Sie die Anwendung vielleicht nicht an Consul binden. Option 2 hilft bestehenden Anwendungen, gesunde Endpunkte ohne jegliche Änderung zu erhalten. Sie können einfach endpoint-name.service.consul über DNS abfragen. Dieser Mechanismus unterstützt jedoch nicht den Key-Value-Store von Consul. Er kann auch nicht auf Änderungen dieser Werte oder der Serviceverfügbarkeit reagieren. Aus diesem Grund ist Option 3 mit Consul-template eine beliebte Alternative. Consul-template ist ein Daemon, der auf Änderungen im Key-Value-Store oder Servicekatalog von Consul achtet. Bei einer Änderung (re)rendert er Konfigurationsdateien mit diesen Werten und einer oder mehreren Vorlagen (daher sein Name). Optional wird es dann Anwendungen signalisieren oder neu starten. Ebenso kann er Passwörter und andere Anmeldeinformationen von Vault leasen und in die Konfiguration einfügen. Die Verwendung von Consul-template in 2 Minuten Mit Consul-Template können Sie also die Leistungsfähigkeit von Consul Service Discovery und Health Monitoring sowie die dynamische Geheimnisverwaltung von Vault nutzen, ohne eine einzige Codezeile in Ihrer Anwendung (oder der eines Drittanbieters) ändern zu müssen. Ihre Anwendung weiß nicht einmal, dass sie ihre Konfiguration von Consul und Vault erhält. Betrachten wir als Beispiel eine Vorlagendatei /etc/app.conf.ctmpl, die Folgendes enthält:

{{Bereich Dienst "Backend-Dienst"}}
Server  {{.Name}} {{.Adresse}}:{{.Port}}{{end}}

Und die Ausführung von consul-template als: $ consul-template -template=/etc/app.conf.ctmpl:/etc/app.conf -exec=/bin/my-app -exec-reload-signal=SIGHUP Dann könnte consul-template die Konfiguration von my-app so wiedergeben: server backend1 10.0.0.10:8888 server backend2 10.0.0.20:9999 Und jedes Mal, wenn sich die Konfiguration änderte (z.B. weil neue Backend-Instanzen gestartet wurden oder bestehende Instanzen ungesund wurden), wurde ein HUP-Signal an my-app gesendet. Der Nachteil von Consul-template Großartig, mit Consul-template kann Ihre Anwendung völlig ahnungslos und unabhängig von Consul oder Vault sein. Aber jetzt ist die Bereitstellung Ihrer Anwendung komplizierter geworden: ein neues Tool muss installiert werden, zusammen mit Konfigurationsvorlagen. Glücklicherweise ist dies mit Docker nur allzu leicht zu lösen:

1. fügen Sie die Consul-Vorlage und die Konfigurationsvorlagen zu Ihrem Container-Image hinzu
2. ändern Sie den Einstiegspunkt so, dass consul-template anstelle Ihrer Anwendung ausgeführt wird.
3. fertig!

Stimmt, aber Sie haben das Problem von der Anwendung auf den Container verlagert: Jetzt ist das Docker-Image von Consul abhängig geworden. Können Sie es besser machen? Können Sie das Consul-Template aus Ihren Container-Images heraushalten und die Container anderer Leute ebenfalls ohne Änderungen verwenden? Sicher! Von Consul-unwissenden Anwendungen zu Consul-unwissenden Containern Sie haben es bereits erraten: Machen Sie den Umzug einfach noch einmal. Anstatt die Consul-Integration in das Deployment-Paket (sprich: Docker-Image) zu packen, verschieben Sie sie in das Deployment selbst. Und mit Nomad 0.5 ist das ganz einfach: Fügen Sie einfach einen Vorlagenabschnitt in die Nomad-Job-Spezifikation mit der gleichen, vertrauten Syntax für Vorlagen ein:

job "my" {
  group "app" {
    task "server" {
      template {
        data = "{{range service "backend-service" }}server {{.Name}} {{.Address}}:{{.Port}}n{{end}}"
        destination   = "local/app.conf"
        change_mode   = "signal"
        change_signal = "SIGHUP"
      }
    }
  }
}

Beachten Sie, dass sich app.conf jetzt im lokalen Verzeichnis befindet. Der Grund dafür ist, dass Nomad die Konfigurationsdatei rendert, bevor der Docker-Container startet. Daher existiert das Container-Dateisystem noch gar nicht. Nomads Docker-Treiber hängt das lokale Verzeichnis als /local ein. Wenn Sie also my-app so konfigurieren, dass es /local/app.conf als config liest, ist das Problem gelöst. Bemerkenswert ist auch, dass der gleiche Mechanismus auch mit Exec- und Java-Treiber-Jobs funktioniert. Sie können eine nackte Go-Binärdatei ausführen, ohne Docker überhaupt zu benötigen. Ein Beispiel dafür finden Sie hier: helloworld.nomad at master - bastiaanb/devoxx-2016 - GitHub Wie setzt Nomad dies um? Nomad wurde in der Sprache Go geschrieben. Eine seiner schönen Eigenschaften ist die einfache Wiederverwendung von Quellcode aus anderen Projekten. Anstatt Consul-Template neu zu implementieren, haben die Entwickler von Nomad es daher einfach integriert. Kurz gesagt: "Consul-Template (das Tool) ist tot! Lang lebe Consul-Template (die Bibliothek)"