NETWAYS Blog

CoreOS – Cluster Discovery

von Blerim Sheqa | Jan 20, 2016 | Linux, DevOps, Technology, Web Services, Network, Container

Bei der Einrichtung eines neuen CoreOS Clusters muss man sich für eine Variante entscheiden, mit der sich die einzelnen Server untereinander bekannt machen. In Wirklichkeit ist es auch kein CoreOS-, sondern ein etcd-Cluster. Der Key-Value Store, etcd genannt, ist die Kernkomponente die dazu genutzt wird, Informationen über mehrere Server hinweg zu speichern. Im ersten Schritt müssen diese Nodes aber davon in Kenntnis gesetzt werden, dass sie zusammengehören. Wissen sie erst mal voneinander, finden sie auch den weg zueinander. Etcd besitzt mehrere Mechanismen, um diesen ersten Kontakt herzustellen. Bekanntermaßen werden die einzelnen CoreOS Dienste in der cloud-config konfiguriert. Diese Datei wird beim Start geladen und umgesetzt. Meine unten aufgeführten Beispiele stellen keine vollständige cloud-config dar, lediglich die relevanten Teile einer solchen.

Initial Cluster State

Viel Frust kann man sich sparen, indem man die Option initial-cluster-state richtig verwendet. Wird ein neues etcd-Cluster erstellt, muss diese Einstellung auf new gesetzt sein. Fügt man hingegen eine Node einem Cluster hinzu, ist der Wert zwingend auf existing einzustellen. Andernfalls wird der neue Server trotz Discovery Mechanismen versuchen ein neues Cluster zu initiieren.

Statische Konfiguration

Bei einer statischen Konfiguration werden alle Nodes in der cloud-config fest eingetragen. Kommen Server hinzu oder fallen sie weg, muss die Konfiguration ebenfalls angepasst werden.

#cloud-config
coreos:
  etcd2:
    listen-client-urls: http://0.0.0.0:2379
    listen-peer-urls: http://$private_ipv4:2380
    initial-cluster: srv1=http://10.0.0.1:2380,srv2=http://10.0.0.3:2380,srv3=http://10.0.0.3:2380

Diese Art der Konfiguration bietet sich an, wenn alle Nodes dieselbe cloud-config laden. Die Anzahl der Server sollte sich nicht oft ändern, da man sonst viel Zeit mit dem Umbau der Konfiguration verbringt. Durch die festen Einträge geht viel von der Dynamik verloren, die CoreOS so charmant macht. Mal eben Server dazu zu stellen oder abbauen ist nicht mehr ohne Weiteres möglich.

etcd.io Discovery Service

Die Macher von etcd haben einen Service im großen weiten Internet stehen, so wie sich das für ein anständiges Tool in der heutigen Zeit nun mal gehört. Bei diesem Service lassen sich unter einer eindeutigen ID die eigenen CoreOS/Etcd Nodes eintragen und verwalten. Das muss nicht manuell gemacht werden, sondern geschieht automatisch nach Angabe bestimmter Parameter.
Das ganze funktioneirt so:

Man erstellt eine neue, eindeutige ID. Unter dieser werden die eigenen Einträge dann gespeichert.
```
curl 'https://discovery.etcd.io/new?size=3'
```
Die URL die man geliefert bekommt, wird dann in der cloud-config hinterlegen. Somit weis etcd beim Start automatisch wo er sich anzumelden hat. Zusätzlich bekommt er dort Informationen über bestehende Nodes.

#cloud-config
coreos:
  etcd2:
    listen-client-urls: http://0.0.0.0:2379
    listen-peer-urls: http://10.0.0.1:2380
    discovery: https://discovery.etcd.io/e8bd58c845d69485b1d0767541bc72bd

DNS Discovery

Hier kommt mein persönlicher Favorit. Es ist quasi eine Kombination aus den zwei genannten Variationen. Bei der DNS Discovery werden unter einer festgelegten Subdomain DNS SRV Einträge gesetzt. Jeder Host der Teil des etcd-Clusters ist, wird eingetragen. Beim Start eines Servers fragt er selbstständig die hinterlegte Subdomain ab und erfährt somit die Hostnamen aller im Cluster vorhandenen Server.

~> dig -t SRV +short _etcd-server._tcp.coreos.netways.de
0 100 2380 node1.coreos.netways.de.
0 100 2380 node2.coreos.netways.de.
0 100 2380 node3.coreos.netways.de.
0 100 2380 node4.coreos.netways.de.
0 100 2380 node5.coreos.netways.de.

Die cloud-config muss entsprechend konfiguriert werden.

#cloud-config
coreos:
  etcd2:
    discovery-srv: coreos.netways.de
    listen-client-urls: http://0.0.0.0:2379
    listen-peer-urls: http://node1.coreos.netways.de:2380

Blerim Sheqa

COO

Blerim ist seit 2013 bei NETWAYS und seitdem schon viel in der Firma rum gekommen. Neben dem Support und diversen internen Projekten hat er auch im Team Infrastruktur tatkräftig mitgewirkt. Hin und wieder lässt er sich auch den ein oder anderen Consulting Termin nicht entgehen. Inzwischen ist Blerim als COO für Icinga tätig und kümmert sich dort um die organisatorische Leitung.

Lies mehr von Blerim und triff unser Team

Logging mit Docker

von Blerim Sheqa | Aug 18, 2015 | DevOps, Elastic Stack, Linux

Wir beschäftigen uns bei Netways viel mit den Themen Logging, Log Management und der Visualisierung eben dieser. Kein Wunder, gehört Logging doch mit zu den essenziellen Teilen eines jeden guten Monitorings. Logs sind seit jeher sowohl für Entwickler auch als auf Adminitratoren wichtig, also quasi total devops. So zieht sich dieses Thema mit der Zeit durch alle Techniken während immer weiter neue Lösungen entwickelt und alte verbessert werden. Es ist also keine Überraschung das es auch in Bezug auf Docker, dem größten Hype überhaupt in letzter Zeit, nicht zu vernachlässigen ist. Wir werden oft gefragt, was denn jetzt nun die richtige Lösung ist um an die Logs der geliebten Docker Container zu kommen. Nun, eine pauschalte Antwort darauf gibt es wohl nicht, ich kann aber einen Überblick geben.
Wenn wir über Docker und Logs reden ist es wichtig zu wissen, das es dabei (meist) ausschließlich um den Standard-Output des jeweiligen Containers geht. In der Regel besteht ein Container aus einem einzigen Prozess der die gewünschte Applikation startet und nichts weiter. Ein Syslog Daemon ist also nicht vorhanden und somit gibt es innerhalb des Containers auch kein richtiges Logging. Man könnte jeden Container aufblähen und ihm ordentliches Logging verpassen mit einem ordentlichen Syslog Daemon, der kategorisieren und an weitere Syslogs Server schicken kann. Die bevorzugte Variante ist jedoch alles nach stdout und sdterr zu schicken, da man darauf auch von außerhalb des Containers zugreifen kann.
Überblick
Docker unterstützt verschiedene Driver für das Logging. Anhand eines gewählten Drivers beim Start des Cointainers lässt sich steuern wohin Logs weitergeleitet werden. Zu jedem Driver gibt es Optionen die mitgegeben werden können.

   docker run --log-driver=... --log-opt ...

Immer wieder kommen mit neuen Docker Versionen neue Features oder gar neue Driver hinzu. Neben den verschiedenen Log Drivern lässt sich auch none einstellen, um das Logging komplett zu deaktivieren.
Der Standard
Zugegeben, Logging war zu Beginn nicht gerade ein priorisiertes Thema im Docker Projekt. Dennoch gibt es schon lange eine rudimentäre Stütze zum auslesen von Logs. Standardmäßig wird alles in json-Dateien geschrieben. Auslesen kann man diese dann am einfachsten mit dem docker logs Kommando.

   docker run -d ubuntu bash -c "while true; do echo `uptime`; sleep 10; done"
   docker logs 1a2e14a58c75
     10:53:34 up 4 days, 13:29, 4 users, load average: 0.38, 0.33, 0.35
     10:53:34 up 4 days, 13:29, 4 users, load average: 0.38, 0.33, 0.35

Der Alleskönner
Syslog ist der Alleskönner unter den Docker Logging Drivers. Unter Verwendung des Syslog Standards werden Logs an entfernte Daemons weitergeleitet. Das macht es lohnenswert diese für die weitere Verarbeitung und Analyse an Logstash zu schicken.

   docker run -i -t --log-driver=syslog --log-opt syslog-address=udp://logstash.netways.de:514 ubuntu bash -c "while true; do echo `uptime`; sleep 10; done"

Zusätzlich zum Syslog Server lassen sich auch ein paar weitere Optionen setzen:

   --log-opt syslog-facility=daemon
   --log-opt syslog-tag="myContainer"

Der Neue
Mit der Docker Version 1.8 verzeichnete das Projekt Graylog einen Erfolg in der Zusammenarbeit mit Docker. Ihr bekanntes Format GELF (Graylog Extended Log Format) wurde mit aufgenommen und ist seitdem als eigener Log Driver verfügbar. Da sich das Format nicht nur mit dem dazugehörigen Prodokut Graylog benutzen lässt, sondern auch von Logstash unterstützt wird, ist es eine echte alternative zum klassischen Syslog.

   docker run -i -t --log-driver=gelf --log-opt gelf-address=udp://logstash.netways.de --log-opt gelf-tag="myContainer" ubuntu bash -c "while true; do echo `uptime`; sleep 10; done"

Die Anderen
Die genannten Möglichkeiten sind nicht alle, es gibt auch Log Driver für FluentD und journald, dazu aber ein anderes Mal mehr.

Blerim Sheqa

COO

Lies mehr von Blerim und triff unser Team

Puppetcamp '15

von Blerim Sheqa | Apr 28, 2015 | DevOps, Puppet, PuppetCamp

Vergangenen Donnerstag ging für mich zum ersten mal das alljährliche Puppetcamp bereits am Abend vor dem eigentlichen Camp los. Gemeinsam mit Achim hatten wir die ehrenvolle Aufgabe eine „Kickstart Introduction“ über Puppet zu halten. Bereits hier haben wir schon einen guten Eindruck von dem breit gefächerten Publikum des Puppetcamps bekommen. Vom Anfänger bis zum Mehrjährigen User waren alle Vertreten.
Die Keynote wurde dann von Nigel Kersten gehalten. Der CIO von Puppetlabs hat mit allgemeinen Informationen und Neuerungen rund um das Produkt Puppet und Puppetlabs schon Stimmung auf mehr gemacht. Selbst während den Fragerunden anderer Voträge konnte man immer wieder gut erleben, welches Fachwissen Nigel zu bieten hatte. Der daruaf folgenden Redner, Sebastian Reitenbach, hatte eine Geschichte zu erzählen wie sie jeder schon erlebt hatte der Puppet produktiv einsetzt und die jeden interessieren würde der das noch vor sich hatte. Vor gut einem Jahr hatte Sebastian nämlich noch überhaupt kein Configuration Management eingeesetzt. Nun konnte er aus dieser Einführungsphase von Puppet quasi noch ganz frisch erzählen was es heist die gesamte Arbeitsweise zu ändern. Viele Tipps und Tricks waren besonders an Einsteiger gerichtet und sollten so den Beginn vereinfachen.
Nach einer kurzen Verschnaufpause ging es auch schon direkt weitere mit dem nächsten Speaker, Pedro Pessoa. Der konnte mit guten Anschaungsmaterial darstellen auf welche Weise Puppet bei seinem Arbeitgeber Server Density einesetzt wird. Das Unternehmen hat sich auf Hosted Server und deren Monitoring spezialisiert und arbeitet mit einer bereits 4 Jahre alten Codebasis, wobei sie sich immer mehr auf Module aus dem Puppet Forge stützen möchten. Im darauf folgenden Talk teilte Rajesh Sivaraman seine Erfahungen die er gemacht hatte bei der Integration von Puppet in CI (Continuous Integration) Umgebungen. Eindrucksvoll erklärte er in wenigen Minuten wie er lernte Jenkins für seine Zwecke zu nutzen um bestimmte Tasks verschiedenste Technologien wie Virtuelle Maschinen und auch Docker Container zu verteilen. Das ganze geschah natürlich mithilfe von Puppet.

Nur wenige Tage vor dem diesjährigen Puppetcamp in Berlin war das neue Puppet 4 erschieden. Natürlich waren allle ganz heiß darauf zu erfahren, welche Änderungen und Verbesserungen es geben würde. Das nahm Martin Alfke dann zum Glück auch zum Anlass und zeigte alle wichtigen Änderungen in der neuen Version. Trotz all der neuen Features und Performance Verbesserungen stellten am Ende doch alle ernüchternd fest das ein wechsel vom alten Puppet vermutlich nicht so einfach und schnell geschehen könnte, dennoch war die Motivation hoch die Ärmel hochzukrempeln und die Migration anzugehen. Puppetmodule im Forge werden zudem in Zukunft die Kompatibilität zu verschiedenen Puppet Versionen anzeigen, damit es da nicht zu Verwechslungen kommt. Fast selbstverständlich hatte Nicholas Corrarello dann auch eine Live Demonstration von Puppet Enterprise zu bieten. Das Tool wird auch in naher Zukunft mit Puppet 4 umgehen können.
Nach einer letzten Pause ging es dann auf zum Endspurt, und der hatte es in sich. Felix Frank, der bereits sein eigenes Buch über Puppet veröffentlicht hatte, zeigte auf warum es so wichtig ist Puppet Code zu testen. Doch dabei belies es der erfahrenen Puppet Anwender nicht. Mit vielen Kniffen und Tricks konnte man bei ihm lernen wie einfach Testing und Debugging sein konnte. Die Wichtigkeit dieser Techniken bleibt unumstritten. Den Abschluss des Puppetcamps bot Andrea Giardini. Der CERN Mitarbeiter erklärte nicht nur in groben Zügen die gesamte CERN Umgebung, sondern ging auch in Details in deren Puppet Umgebung ein. Die Erkenntnis „Die Kochen ja auch nur mit Wasser“ war aber nicht das Einzige was man aus diesem Vortrag mitnehmen konnte. In derart großen Umgebungen ist man plötzlich völlig anderen Herausforderungen gegenüber gestellt. Wie deren Lösung aussehen kann, konnte Andrea an diesem Tag sehr gut erklären.
Nachdem die Vorträge alle vorbei waren, haben sich viele der Teilnehmen zum weiteren sogenannten „socializen“ in der Hoteleigenen Bar eingefunden. Natürlich, der gesamte Input des Tages wollte ja auch erst mal verdaut und besprochen werden und welche besser Möglichkeit gäbe es dazu als mit gleichgesinnten bei einem kühlen Berliner Bier.

Blerim Sheqa

COO

Lies mehr von Blerim und triff unser Team

Kibana 4

von Blerim Sheqa | Mrz 24, 2015 | Linux, DevOps, Technology, Elastic Stack

Vergangenen Februar war es endlich so weit, Kibana 4 wurde nach mehreren Beta Versionen und Release Candidates endlich final released. Weil wir es selbst kaum erwarten konnten, hatte ich bereits bei Erscheinung der ersten Beta in unserem Blog über die neuen Funktionen und Arbeitsweisen berichtet.
Viel hat sich seitdem dann auch nicht mehr geändert. Das primäre Ziel bleibt weiterhin die Visualisierung der Daten in mehreren Dimensionen. So lassen sich Balken und Kreisdiagramme beliebig oft schachteln und in Dashboards mit anderen Darstellungen wie Liniendiagrammen oder Weltkarten verknüpfen. Die Entwickler von Elastic haben stark an der Stabilität der einzelnen Features gearbeitet. Hier und da wurden kleine visuelle Unstimmigkeiten und überflüssige Schaltflächen bearbeitet oder ganz entfernt.
Diese kleinen Änderungen machen aber den Unterschied, insbesondere bei der täglichen Arbeit mit dem Tool macht sich das stark bemerkbar. Ebenfalls hinzu gekommen ist die Integration für das vor kurzem vorgestellte “Shield” Produkt, welches die Benutzer- und Zugriffsverwaltung eines Elastic Clusters erlaubt. So geht es mit der neuen Webanwendung mit immer größeren Schritten in Richtung “Enterprise” Anwendung und liefert damit eine echte Konkurrenz zu anderen, meist sehr teuren, Alternativen. Ans Ausruhen denkt offensichtlich aber keiner, denn die Version 4.1 ist schon in Arbeit und lässt auf weitere Features und Bugfixes hoffen.

Blerim Sheqa

COO

Lies mehr von Blerim und triff unser Team

Kibana im neuen Gewand

von Blerim Sheqa | Dez 9, 2014 | DevOps, Technology, Elastic Stack, Linux

Einige Zeit war es relativ ruhig im Bereich Log Management mit Elasticsearch, Logstash und Kibana (ELK Stack). Jetzt tut sich jedoch was und wir können uns auf tolle neue Features freuen. Neben dem Update von Elasticsearch auf die Version 1.4.1 wird aktuell auch viel an der Visualisierungskomponente Kibana gearbeitet. Mit einer nicht vor allzu langer Zeit erschienenen Beta Version erhalten wir einen Blick in einen kompletten Rewrite der Browserbasierten Applikation. Kibana4 verfolgt ein neues Konzept und öffnet die Türen für neue Features.
Browserbasiert? Nicht nur!
Während Kibana sich in der aktuellen Version 3 selbst zum Elasticsearch Cluster verbindet, muss bei der neuen Version ein Daemon auf dem Server gestartet werden. Dieser kümmert sich um die Verbindung zum Elasticsearch und fungiert somit als eine Art Proxy. Das ist insbesondere in Hinsicht auf zukünftige Authentifizierungs und Authorisierungs-Plugins wichtig. Die Schnittstelle für Plugins bringt das neue Kibana nämlich auch gleich mit. Mit dem, kurz vor dem Release stehenden Security-Plugin für Elasticsearch, Shield, nähern wir uns mit großen Schritten einem mandantenfähigen und sicheren Log Management System.
Discover
Das neue Konzept verfolgt eine Aufteilung in verschiedene Ebenen der Visualisierung. Die Unterste, bzw. erste, ist die Suche. In einem simplen Interface kann man seine Query verfassen und sichtbare Felder auswählen. Das Histogram fasst die Anzahl der gefundenen Logs zusammen und bietet einen Überblick. Wie gewohnt lassen sich einzelne Logs aufklappen und Filter auf einzelne Felder anwenden. Diese Ansicht dient dazu tatsächliche Log Meldungen zu suchen und zu verfolgen und hat noch wenig mit Visualisierung zu tun.
Visualize
In diesem Bereich wird es schon bunter. Die vorher durchgeführten Suchen können gespeichert und als Basis für die Visualisierung verwendet werden. Das ist jedoch nicht zwingend, es kann auch eine komplett neue und leere Suche benutzt werden. Der Visualisierungsteil verfolgt den Ansatz, Grafiken Schritt für Schritt zu erstellen. Das wird schon zu Beginn deutlich, indem man auswählen muss welche Art der Grafik man erstellen möchte und welcher Index dafür angezogen werden soll. In meinem Fall erstelle ich ein Kuchendiagramm. Im nächsten Schritt teile ich die Kuchenstücke nach dem „program“ Feld auf. Die eigentliche Neuerung zeigt sich im zweiten Schritt. Das erstellte Diagramm kann jetzt nämlich noch weiter behandelt werden. So lassen sich die Kuchenstücke ein weiteres Mal aufteilen. Bei Barcharts und den anderen Visualisierungsarten funktioniert das ebenfalls.

Dashboards
Die erstellten Graphen werden in Dashboards gesammelt dargestellt. Am oberen Ende steht, wie gewohnt, ein Query Feld und der Timepicker um die Darstellung einzuschränken.
Installation
Die Installation gestaltet sich sehr einfach. Nach dem Download steht schon alles Bereit was benötigt wird. Wie wir es von Logstash schon kennen, ist auch das neue Kibana in jRuby gepackt und setzt eine aktuelle Java Instalaltion voraus. Der Elasticsearch Cluster wird in der yaml-Formatierten Datei config/kibana.yaml konfiguriert, es wird mindestens eine Version 1.4 von Elasticsearch vorausgesetzt. Kibana muss dann nur noch mit bin/kibana gestartet werden und ist standardmäßig auf dem Port 5601 erreichbar.
Fazit
Das neue Kibana4 ist definitiv noch nicht reif für den Produktivbetrieb, aber das sagt ja das „Beta“ im Namen schon. Die Idee der Aufteilung in verschiedene Ebenen finde ich sehr gelungen, auch wenn es mehr Verständnis erfordert und insbesondere in den Visualisierungsteil noch viel Arbeit gesteckt werden muss. Das Webinterface wirkt insgesamt aufgeräumter und macht durch die hellen Farben einen sanfteren Eindruck. Die Anordnung der Graphen ist deutlich verbessert worden, da die Größen immer einheitlich sind. Auch wenn es hier und da noch ein paar Bugs gibt und noch einige Feature Requests offen sind, so lohnt sich ein kurzer Blick auf jeden Fall. Neue Beta Versionen sind schon in Vorbereitung und lassen auf noch mehr Stabilität, Bugfixes und Features hoffen. Wann ein endgültiges Release geplant ist, lässt sich zum aktuellen Zeitpunkt noch nicht sagen.