Schlagwort-Archive: docker

ZABBIX Monitoring Network

Server und Application Monitoring mit Docker

Je nachdem in welchem Umfeld du unterwegs bist, sammelst du über die Zeit mehrere Server an. Ob diese nun virtualisiert sind oder nicht ist dabei nicht entscheidend. Die Frage die du dir stellen solltest: Wie kannst du den Überblick behalten?

Ich habe beispielsweise einen ganzen „echten“ Server nur zur Sicherung der Daten meiner anderen Server. Dies realisiere ich mittels der Open Source Software BackupPC (ich blogge hierzu gerne, wenn es interessant ist – einfach Kommentar hinterlassen). Auf dieses System greife ich natürlich nicht täglich zu, sondern nur im Notfall. Doch wie häufig prüfe ich, ob das System überhaupt läuft? Du ahnst es schon: Gar nicht! Ohne Witz, ich denke an diesen Backupserver nur genau einmal im Monat: Wenn die Rechnung kommt.

Und hier ist der Knackpunkt: Mit steigender Anzahl an Systemen, sinkt die Motivation, wirklich alle Systeme im Blick zu behalten. Bei meiner Cloud oder der Piwik-Instanz werde ich schon merken wenn die ausfällt, auch wenn es sicherlich einige Stunden dauert, aber bei Systemen die halt „einfach da sind“ kann es Tage oder Wochen dauern. Daher sollte ich hier nun endlich mal ein Monitoringsystem aufsetzen.

Definition von Monitoring

Im Monitoring (zumindest für mich) geht es mir darum, eine beliebig große Anzahl an Servern und auch Applikationen zu überwachen. Und zwar in einem Intervall, den ich selbst nicht leisten kann, sprich: „Alle X Sekunden“ oder „Alle X Minuten“. Die ermittelten Daten werden gespeichert und können rückwirkend ausgewertet werden.

Innerhalb dieser Intervalls werden dann verschieden viele Parameter abgefragt. Je nach Ergebnis der Abfrage und je nach Parameter sowie eben auch möglicher anderer Parameter können dann verschiedene Ereignisse ausgelöst werden sodass ich bspw. eine E-Mail erhalte, wenn ein Server abstürzt oder wenn der verfügbare Speicherplatz einer Festplatte nahezu aufgebraucht ist. Aber eben auch die Verfügbarkeitsprüfung von Applikationen ist wichtig, bei dem angesprochenen Backupsystem bspw. ist es zwar nett zu wissen, dass der Server läuft, aber dadurch weiß ich ja noch lange nicht, ob die Applikation auch verfügbar ist.

Na toll, dann musst du halt den ganzen Tag in dieses Monitoring-System glotzen oder was?“ Fragst du mich jetzt vielleicht…. nein 😉

Die oben erwähnten Ereignisse können genutzt werden um mich über gewisse Situationen informieren zu lassen. Bspw. währe ein wichtiges / kritisches Ereignis, wenn ein Server ausfällt. Und ich habe für mich entschieden, dass ich bei kritischen Ereignissen definitiv sofort benachrichtigt werden, bspw. in Form einer E-Mail.

So einfach geht’s: ZABBIX Monitoring Server einrichten

netcup.deIch habe mir bei netCup einen ganz kleinen Server geholt, der bei mir nun ausschließlich das Monitoring ausführen wird. Damit ich mich nicht um die Installation bzw. Migration der Monitoring-Anwendung kümmern muss, werde ich -wiedermal- Docker einsetzen.

Server-System vorbereiten

Dazu habe ich ein Debian Wheezy aufgesetzt (musst du nicht genau so machen), mit diesem Startpunkt ergibt sich erstmal die Installation von Docker und nginx auf dem Server:

Nun habe ich alle Pakete aktualisiert und nginx installiert (brauche ich später mal). In meinem Setup muss ich nun noch das kernel-update auf eine Version > 3.10 vornehmen.

Nachdem der neuere Kernel installiert ist, kann ich mit der Installation von Docker fortfahren. Hierzu muss ich erstmal die passenden Software-Repositoriys im System hinterlegen:

Unter Debian Wheezy muss ich in "/etc/apt/sources.list" nun noch die Zeile "deb-src [arch=amd64] https://download.docker.com/linux/debian wheezy stable" auskommentieren.

Nun kann ich den Paketmanager aktualisieren lassen und dann Docker in der Community Edition installieren:

ZABBIX Server als Docker-Container aufsetzen

Ich habe mich für ZABBIX als Monitoring-Server entschieden. Das System hatte ich vor einigen Jahren schon mal für einen Anwendungsfall im Einsatz und kenne zumindest noch einige Grundlagen. Außerdem habe ich damit später noch etwas vor (mehr dazu in den kommenden Beiträgen). ZABBIX benötigt eine Datenbank. Und im Sinne von Docker benötigen wir also zwei Container: Einmal der Monitoring-Server und einmal dann halt die Datenbank.

Zum Einsatz kommt hier ZABBIX Version 3.2.4 und eine MariaDB. Beide Images stammen vom monitoringartist. Die Container werden jeweils als „deamon“ (-d Parameter) gestartet, laufen also im Hintergrund und Docker wird außerdem angewiesen, die Container sofort neuzustarten, falls sie Abstürzen (--restart unless-stopped Parameter).

Damit die DB zwischen den Starts korrekt persistiert wird und backups gezogen werden können, werden zwei Ordner als Volumes gemounted. Außerdem wird localtime als Read-Only eingebunden. Ich habe mich hier überwiegend an die Anleitung gehalten.

Neben der DB brauche ich dann noch die eigentliche Server-Applikation. Hierzu nehme ich vom monitoringartist das ZABBIX XXL-Image. Hier geben wir ebenfalls localtime als Read-Only rein. Ansonsten gibt es keine weiteren Volumes, da der Server keine eigenen Daten persistiert (nur die DB). Ich verlinke dann noch die Datenbank und gebe zwei Ports frei damit von außen mit der Applikation kommuniziert werden kann (hier kommt später nginx zum Einsatz).

Damit Zugangsdaten und einige Konfigurationen passen, setze ich noch verschiedene Environment-Variablen.

Nun läuft der ZABBIX Server, bis das Web-Interface erreichbar ist, kann es wohl 60 Sekunden dauern, also nicht erschrecken. Du kannst darauf zugreifen, dazu benötigst du die IP / URL deines Server und hängst da den Port (in diesem Fall 8090) hinter, also bspw.: http://server-ip:8090

ZABBIX DashboardDie Standard-Login-Daten sind „admin“ als Benutzername und „zabbix“ als Passwort.

Tipp: Das Passwort solltest du sofort ändern.

Ersten Server ins Monitoring aufnehmen

Der erste Server der im Monitoring überwacht werden sollte, ist der Monitoring-Server. Zugegeben, das hört sich sinnfrei an, wenn der Monitoring-Server abstürzt kann er dich darüber schließlich nicht informieren. Ich mache es dennoch. Zum einen möchte ich genau jetzt wissen, ob Daten erfasst werden können, zum anderen möchte ich die Daten für rückwirkende Analysen erfassen.

Du gehst dazu über den Menüpunkt „Configuration > Hosts“ und dort siehst du den „Zabbix Server“. In rot steht „deactivated“ dort, wenn du darauf klickst, aktivierst du die Aufzeichnung.

Weitere Server ins Monitoring aufnehmen

Von hieran geht es unglaublich schnell, weitere Server ins Monitoring aufzunehmen. Ich habe inzwischen auf allen Servern Docker laufen da ich künftig jegliche Applikationen jeweils in einem Docker-Container betreiben möchte. Daher setze ich nun auch auf den zu überwachenden Servern einen Zabbix-Agent im Docker-Container ein. Mein Vorteil: Ich führe ein einziges Kommando aus und der Server ist im Monitoring.

Hierzu setze ich, ebenfalls vom monitoringartist, das Image dockbix-agent-xxl-limited in der neusten Version ein. Wichtig hierbei ist, dass der --net=host Parameter verwendet wird, sodass der Docker-Container im selben Netzwerk-Stack läuft wie der Host. Außerdem muss der Container mit dem --privileged Parameter gestartet werden, da er auf viele Systemeigenschaften zugreifen muss, die überwacht werden sollen. Das gesamte Filesystem muss gemountet werden, zusätzlich muss /var/run in den Container (auf selben Pfad) gelegt werden. Auf diese Weise kann der ZABBIX-Agent im Container alles überwachen.

Über die zwei Environment-Variablen ZA_Server und ZA_ServerActive wird die Verbindung zum Monitoring-Server festgelegt.

An diesem Punkt kam ich ins Grübeln: Keinerlei Autentifizierung findet hier statt. Keine Tokens, keine Zugangsdaten, nix… Was, wenn jemand meine ZABBIX-Url herausfindet und mich mit Daten überflutet? Nachdem ich den ersten Versuch startete merkte ich aber schnell, dass eine Authentifizierung hier nicht notwendig sein wird.

Der Agent startet und Fragt vom Angegebenen Monitoring-Server ab, was er alles überwachen soll (dies kann pro Server variieren). Der Monitoring-Server schaut anhand des Anfragenden Hostname in der Konfiguration. Solange ich also in ZABBIX einen Server nicht eintrage, bekommt dieser „nichts“ zurück. Denn ZABBIX möchte von diesem Server dann keine Daten haben.

Damit der Agent also irgendwas übermittelt, muss ich erstmal den Server anlegen und konfigurieren. Dies erfolgt über den Menüpunkt „Configuratino > Hosts“. Hier siehst du eine Liste aller Hosts und kannst auch einen neuen Host anlegen.

ZABBIX Host anlegenIn der ersten Ansicht gibst du den Host-Name (der Hostname des Server), den Visible-Name (mit diesem Namen zeigt ZABBIX dir den Server an) und die IP Adresse des Servers an.

Im Tab „Templates“ wählst du dann noch Templates, ich wähle hier überwiegend nur „Template OS Linux“. Über die Templates werden die verschiedenen Parameter definiert, die überwacht werden sollen (bspw. CPU Auslastung, Festplattenspeicher, …).

ZABBIX: GLIBC-Error beheben

Ich hatte beim Start des ZABBIX-Agent auf einigen Servern Probleme. GLIBC war wohl nicht in der korrekten Version vorhanden. Dies lässt sich fix beheben:

Danach unbedingt den eingefügten (letzten) deb-Eintrag auskommentieren. Jetzt noch den Docker-Container vom Zabbix Agent löschen und neu anlegen.

TeamSpeak Server in unter 5 Minuten [teamspeak] [docker]

TeamSpeak Server in unter 5 Minuten. Alles was man dafür benötigt ist irgendeinen (v)Server, da können auch bereits andere Applikationen drauf laufen.

Um mit anderen Applikationen nicht in Konflikt zu kommen empfehle ich den Einsatz von Docker. Ich selbst nutze Docker immer mehr, da es die einzelnen Applikationen eines Servers kapselt sodass sie sich gegenseitig nicht beeinflussen.

Mit folgenden zwei Zeilen startet ihr euren Server:

Ihr könnt euch dann direkt per Client auf euren Server verbinden und mit der finalen Konfiguration beginnen.

Die wichtigen Dateien wie die sqlite-DB oder die Logs werden dabei unter /srv/docker/teamspeak abgelegt.

Docker statt vServer – Wie ich 770GB verloren habe

Ich habe vServer gemietet. Das ist eine tolle Sache. Dort kann ich tun und lassen was mir beliebt. Doch nicht für jeden Anwendungsfall muss gleich ein vServer her. Denn es gibt inzwischen Docker, dort entfällt eine Menge overhead, den so ein vServer mit sich bringt.

Ich habe ja den ein oder anderen Server und auch ein paar vServer. Damit ich vor Datenverlusten geweiht bin, habe ich einen Server dafür gemietet, sich um Backups zu kümmern. Die Anforderungen an diesen Backup-Server: Massiv Speicherplatz, möglichst günstig. Und so endete es in einem Server der mit 100Mbit Anbindung nicht der schnellste, aber mit 2x2TB (bewusst ohne RAID) viel Speicher hatte und günstig war. Da ich für Kunden ebenfalls Server sichern wollte habe ich mich vor über einem Jahr auf diesem Server dazu entschieden, zwei vServer aufzusetzen. Beide lediglich mit Backuppc ausgestattet. Und jeder vServer hatte seine eigene Festplatte. So konnte ich den Speicherbedarf gut regeln. Ich behaupte nicht dass dies die einzige Lösung ist/war aber es ging schnell und funktionierte.

Nun hat eine Festplatte defekte Sektoren bekommen und musste getauscht werden. Ich habe also den betroffenen vServer gestoppt und seine VDI auf einen anderen Server übertragen, was bei 770GB und der schwachen Anbindung etwa 30 Stunden dauerte. Dann wurde die Festplatte getauscht und ich habe die VDI wieder zurückgespielt (also nochmal etwa 30 Stunden). Resultat: Der vServer ließ sich nicht mehr booten. Die Datei ist beschädigt gewesen, sicherlich folgend aus den kaputten Festplattensektoren. Demnach: 770GB Datenmüll. Es ist nicht dramatisch, es handelte sich lediglich um ein Backup anderer Daten, die ja weiterhin auf ihrem Server lagen und funktionierten.

Ich hatte schon länger darüber nachgedacht, die zwei vServer zu deaktivieren und hier Docker in den Einsatz zu nehmen um beide Backuppc-Instanzen zu betreiben und auf die zwei verschiedenen Festplatten zu schreiben. Ich hatte nur nie einen Anlass dazu. Nun hatte ich bedarf und habe mich rangesetzt.

Fazit: Es läuft prima. Doch was ist jetzt der Unterschied?

Docker vs. Virtualisierung

Ich möchte darauf hinweisen, dass ich kein Virtualisierungs-Profi bin. Ebenso bin ich auch kein Docker-Profi. Ich habe konkrete Anwendungsfälle und benutzte dann eine passende Technik. Sobald es läuft und ich die Situation als „stabil“ einschätze, bin ich zufrieden.

Für mich gibt es zwischen Docker und Virtualisierung in dem obigen Beispiel einen gravierenden Unterschied: Durch das defekte VDI-File, habe ich nun 770GB Daten verloren. Mit Docker hätte ich sicherlich auch Daten verloren, aber eben nur jene, die in den entsprechenden Sektoren gespeichert wurden. Es ist davon auszugehen, dass ein Großteil der Daten erhalten geblieben wäre.

Ein weiterer Punkt ist das Thema Sicherheit: Ich habe natürlich quasi nie die vServer aktualisiert. Auch den Host nicht. Ich hatte einfach schiss, dass dann vbox nicht mehr startet oder irgendwas auf den vServern nicht mehr läuft. Demnach hatte ich einen Host und zwei vServer die potenziell angreifbar wären oder um die ich mich hätte potenziell kümmern müssen.

Nun mit Docker habe ich nur noch den Host. Die Container haben keine Möglichkeit den Host anzugreifen und die Container sind von außen lediglich über einen einzigen Port erreichbar. Mit jedem Update von Backuppc wird ein neues Image bereitgestellt, welches wiederum auf einem aktualisierten Linux-Image beruht und somit werden „Systemupdates“ implizit mit dem aktualisieren des Images eingespielt. Den Host werde ich fortan aktualisieren, ich betreibe einige Docker-Hosts und habe bisher noch nie erlebt, dass es zu einem Problem innerhalb eines Docker-Container kam, dadurch dass ich den Host aktualisiert hätte…

Einfache Wartung: Ich habe ein Script geschrieben welches beide Docker-Instanzen gleichzeitig verwaltet. Ich gebe in dem Script das Basis-Image und einige weitere Parameter an. Und dann kann ich mein Script aufruren und ein Update ausführen, die Container stoppen / starten oder in die Logs schauen. Alle Aktionen werden dann auf beiden Containern ausgeführt. Das ist praktisch und spart Zeit.

ownCloud – „from source“ in Docker Container [owncloud] [docker]

Die eigene Cloud-Lösung dank ownCloud ist eine tolle Sache. Ich habe ja so einige Server. Sowohl im „Managed Service“, also bei denen sich professionelle Serveradmins um das System kümmern als auch einige andere, bei denen ich mich selbst drum kümmere (eigene Systeme wie bspw. ownCloud, bei denen es sich aus kostengründen so ergibt).

Ich betreibe unter anderem eine ownCloud Instanz auf einem der Server die ich halt selbst verwalte. Und noch andere Systeme. Was immer wieder schwierig für mich ist: Zugriffsrechte. Ich habe mich damit anscheinend noch nicht ausgiebig genug bei Linux beschäftigt. Daher hat es eine ganze Weile gedauert, bis die ownCloud wie gewünscht lief.

Nun habe ich etwas Sorge gehabt, als ein anderes System auf dem Server PHP 5.6 brauchte. Da ich nicht weiß, wie ich mehrere PHP Versionen parallel betreibe, habe ich einfach von PHP 5.4 auf PHP 5.6 umgestellt. Eben mit der Sorge, dass dadurch andere Systeme ggf. Schwierigkeiten bekommen.

Um solche Sorgen nicht mehr zu haben, möchte ich schon seit langem alle Anwendungen dieses Servers in eigene Docker Container umziehen. Mit Docker habe ich mich hier auf dem Blog schon beschäftigt. Ich finde die Idee von Docker genial und habe ja auch seid kurzem meine eigene private Docker Registry.

Docker Container einrichten

Bevor ich groß mit Dateien hantieren wollte, habe ich die Docker Container aufgesetzt. Dazu schreibe ich mit immer ein anwendung.sh-Bash-Script, also in dem Fall owncloud.sh

Nun vergesse ich nie wieder wie ich diese container konfiguriert habe. Kommt eine neue Version von ownCloud, kann ich einfach oben den Image-Namen ändern und das Script erneut ausführen. Praktisch!

Ich habe das Script ausgeführt und auf meine neue Cloud per http://host:81 zugegriffen. Ich wollte sehen, ob alles funktioniert. Der Installations-Wizard war zu sehen, demnach: Läuft.

Datenbank einspielen

Ein spannender Punkt. Denn ich habe ja, wie oben im Script zu erkennen, einen Docker Container für MySQL eingerichtet. Wie bekomme ich da jetzt also die Datenbank rein?

Ich habe mich dazu entschieden, ein SQL-File zu exportieren und dieses in das Docker Volume zu schieben sowie die Berechtigungen richtig zu setzen.

Nun konnte der Datenbankimport stattfinden, vorher muss natürlich erst eine neue DB angelegt werden. Beides geht in jeweils einem einzigen Aufruf:

Konfiguration übernehmen

Nachdem nun die Datenbank steht, muss natürlich die neue ownCloud-Installation mit der Datenbank verbunden werden bzw. generell die ganze Konfiguration übertragen werden.

Damit allerdings nicht getan, die Konfiguration muss geprüft werden. Denn es hat sich zumindest der Datenbank-Host geändert. Die Datenbank findet man nun nicht mehr auf „localhost“, sondern über den Host „mysql“ (siehe Docker Link im Installationsscript).

Daten übernehmen

Tja und als letzter Schritt fehlt nur noch, die Daten zu übernehmen.

Nun ist meine neue ownCloud-Installation Testbereit.

ownCloud umschalten

Nach den Tests kann ich den vHost im Apache des Server einfach als Redirect auf den Port 81 (siehe Port-Mapping im Docker-Script) konfigurieren. Dann ist automatisch meine schöne URL nutzbar, der Apache fungiert in dem Moment einfach als Proxy.

In meinem Fall ist wie gesagt ein Apache im Einsatz, das ganze lässt sich natürlich mit nginx auch realisieren. Diesen habe ich allerdings noch nicht oft eingesetzt und habe hier also zu einem vertrauten Mittel gegriffen.

Und schon kann ich meine Cloud über den Browser aufrufen und bedienen.

docker login: x509: certificate signed by unknown authority [Docker] [Registry]

Ich wollte mich per docker login auf meiner privaten Docker Container Registry einloggen. Doch ich erhielt folgende Meldung:

Gestern hatte ich auf einem anderen Server das selbe Problem und habe aber vergessen, was ich getan habe um es zu lösen. Damit ich es nicht vergesse und ich dir vielleicht auf diesem Notizzettel auch helfen kann, schreibe ich also fix einen Blogbeitrag.

Meine Registry ist unter lw-scm.de:5500 erreichbar. Wenn deine Registry auf einer anderen URL verfügbar ist, musst du im folgenden Code also deine Adresse eintragen.

Docker kennt die CA nicht

Grund für die Meldung ist, dass das Docker-System den Zertifikatsaussteller nicht kennt / verifizieren kann. Daher musst du das öffentliche Zertifikat des jeweiligen CA (Certificate Authority) für den Docker-Client ablegen.

In meinem Fall handelt es sich um ein Login SSL Zertifikat von COMODO, also ein „echtes“ und ich habe es vor kurzem gekauft. Beim Kauf des Zertifikates habe ich eine .ca-bundle-Datei bekommen. Diese Datei muss ich nun in den passenden Docker-Zertifikats-Ordner legen, in meinem Fall /etc/docker/certs.d/lw-scm.de:5500. Ich habe sie bei mir in ca.crt umbenannt.

So nun existiert der Ordner und jetzt kann ich die Datei kopieren.

Nun kann direkt der Login erneut ausgeführt werden.

Ich will mich dennoch umschauen warum die CA nicht akzeptiert wird, denn COMODO ist eigentlich ziemlich verbreitet.