Seite wählen

NETWAYS Blog

Cleanup your Docker Environment

von | Jul 25, 2019 | ,

Using Docker is pretty common meanwhile and a very good idea for development. Using many versions of your favourite language without messing up your host system, different types of deployments (e.g. web servers) or just testing production environment without operational support. The only drawback is that normally you don’t have a clue what’s going on behind the scenes. If you run out of disk space for the first time, you’re exactly at that point.

To apply first aid, you will be advised to use some curious cli hacks to clean up your system. Breaking fingers between grep, sed and awk works out well but is not very helpful – Especially if you want to remember what you did 3 months before 😉

Since Docker Api version 1.25 you have a couple of high level cli commands available doing exactly this job:

Minimal Cheat Sheet:

[bash light=“false“]
$ # Claimed disk space
$ docker system df
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 59 5 10.74GB 9.038GB (84%)
Containers 6 1 991kB 991kB (99%)
Local Volumes 216 1 5.876GB 5.876GB (100%)
Build Cache 0 0 0B 0B

$ # Cleanup disk space
$ docker system prune
WARNING! This will remove:
– all stopped containers
– all networks not used by at least one container
– all dangling images
– all dangling build cache
Are you sure you want to continue? [y/N] Y
Deleted Containers:
02401e1555e8e752d36198d982b5e4114d0999c7cca34a2353e8dc332faa4db5
997eac76d4a46515797027103967c61b46219ff8c70f6e0bb39bc2b975297fa5
23983ed8abaa60198b497e4b3788bb6de7d39d03f171f43e4ee865c0df318ab8
65bb90b9e7edcd2d13da3129664f8b74a72b011d56136cb28c687f1f8dd8e473
5218788bff77cc0c0cc03f79888ea61c3e27bf3ef0003e41fc231b8b6ecdcdc2

Deleted Images:
deleted: sha256:dccdc3cf7d581b80665bad309b66ba36d88219829e1ade951912dc122b657bfc
[…]
[/bash]

There is also an equivalent for images only:

[bash light=“false“]
$ docker image prune
[/bash]

You should definitely take a deeper look into the CLI commands. There are a lot of things that helps you to solve your every day problems!

Marius Hein
Marius Hein
Head of IT Service Management
Marius Hein ist schon seit 2003 bei NETWAYS. Er hat hier seine Ausbildung zum Fachinformatiker absolviert und viele Jahre in der Softwareentwicklung gearbeitet. Mittlerweile ist er Herr über die interne IT und als Leiter von ITSM zuständig für die technische Schnittmenge der Abteilungen der NETWAYS Gruppe. Wenn er nicht gerade IPv6 IPSec Tunnel bohrt, sitzt er daheim am Schlagzeug und treibt seine Nachbarn in den Wahnsinn.
Lies mehr von Marius und triff unser Team

Lokale Time Machine Snapshots blockieren Speicherplatz

von | Okt 17, 2018 | , ,

Kürzlich hatte ich den Plan, ein ca. 100GB iPhone Backup zwischenzeitlich auf dem Mac anzufertigen. Meinem Plan stand nach einem kurzen Blick auf den freien Diskspace des Finders eigentlich nichts im Wege, denn dieser zeigte noch 120 GB freien Speicherplatz an. Nachdem sich das Backup aber mit einem bisher unbekannten Fehler verabschiedete, machte ich mich einmal auf die Suche, was mein Mac denn so eigentlich macht.
Ein Kurzer Blick im Terminal bestätigte mir allerdings viel weniger freien Platz auf der Platte, als der Finder es tat. So waren hier nur noch 55 GB frei. Wie kann das sein?
Zunächst einmal öffnet ihr euer Terminal im Mac und gebt folgendes Kommando ein

df -h

Der Mac zeigt nun in aller Regel in der ersten Zeile die Informationen der Mac-Festplatte (Gegenkontrolle Anhand der Size-Spalte) an. In der Spalte Available steht der noch zur Verfügung stehende Speicherplatz. Sollten sich diese Werte im Finder und im Terminal erheblich unterscheiden, macht es Sinn, die Snapshots unter die Lupe zu nehmen.
Warum Snapshots?
Sollte das Time Machine Backup Volume (z. B. wenn man im Urlaub ist) nicht verfügbar sein, fertigt der Mac lokale Snapshots an. Ein solcher Snapshot schützt zwar nicht vor Datenverlust bei einem Hardwareschaden, wohl aber bei unbeabsichtigten Löschen – also die haben schon Ihre Daseinsberechtigung und fertigen zuverlässig auch ohne Backupvolume im Hintergrund eine Art Sicherung an. Normaler Weise gibt der Mac nach und nach die Snapshots frei, wenn er merkt, dass der Platz benötigt wird. Das ist wahrscheinlich auch der Grund, warum der Finder die Snapshots von der Kalkulation des freien Speicherplatzes excludiert.
Habe ich auch Snapshots?
Sofern ein Time Machine Backup läuft, wird diese Funktion aktiviert. Allerdings tritt sie nur in Kraft, wenn das Backup-Volume nicht verfügbar ist. Am besten prüft man das kurz über das Mac-Terminal mittels Eingabe des folgenden Kommandos. Es listet alle vorhandenen Snapshots der Primärplatte auf.

tmutil listlocalsnapshots /

Möchte man nun einmal solche Snapshots entsorgen, so lässt sich das mit folgendem Kommando erledigen

sudo tmutil thinLocalSnapshots / 10000000000 4

Kurze Erklärung hierzu: / Bezieht sich wieder auf das soeben ermittelte Volume (also die primäre Festplatte, das braucht man in aller Regel nicht ändern), 10000000000 bezieht sich auf den „purgeamount“ also die Menge, in diesem Beispiel sind das 10 GB. Um mehr freizugeben, Zahl auf beliebigen Wert in Byte erhöhen, oder Kommando mehrfach ausführen. Die 4 steht für die „urgency“, also die Dringlichkeit. 1 ist hier die höchste, aber 4 reicht eigentlich auch zum Löschen.
Nachhaltig verhindern, lassen sich lokale Snapshots auf den Apple-Geräten mit folgendem Kommando:

sudo tmutil disablelocal

Alternativ Time Machine nicht mehr nutzen, oder dafür sorgen, dass die Backupvolumes immer verfügbar sind.

Bursting und Throtteling in OpenStack

von | Aug 8, 2018 | , , , , ,

Wir haben die vergangenen Monate genutzt, um eine neue Cloud mit OpenStack aufzubauen. Im Zuge dessen, mussten wir eine Möglichkeit finden, die IOPS sowie die Bandbreite, die VMs zur Verfügung haben, zu limitieren.
Das Limitieren der Bandbreite sowie der IOPS erfolgt in OpenStack in sogenannten Flavors. In einem deutschsprachigen Interface von OpenStack werden diese „Varianten“ genannt. Flavors werden hier als VM-Templates genutzt, mit denen sich VMs starten lassen. Es werden hier Ressourcen geregelt wie RAM, CPU und Firewallregeln aber eben auch die Limitierungen. Gesetzte Werte können nicht in laufenden VMs überschrieben werden. Möchte man diese ändern, muss die VM gelöscht und neu gebaut werden, nachdem die neuen Werte im Flavor angepasst wurden. Ein Rebuild reicht hier nicht aus.
Hier gibt es jedoch eine Ausnahme. Durch den Einsatz von beispielsweise libvirtd, können jene Beschränkungen mittels „virsh“ angepasst werden.

Was sind IOPS und Bandbreite?

Bandbreite und IOPS geben an, wieviel Datendurchsatz sowie Lese und Schreiboperationen einer VM zugeteilt sind. Per Default sind diese unlimitiert, was unter gewissen Umständen zu Problemen führen kann.

Wieso sind Limitierungen sinnvoll?

In einer Cloud mit mehreren Virt-Systemen laufen mehrere VMs. Sind keine Limitierungen gesetzt, kann jede VM soviel Traffic und IOPS erzeugen, wie sie gerade braucht. Das ist natürlich für die Performance entsprechend gut, jedoch verhält es sich dadurch so, dass andere VMs auf dem gleichen Virt entsprechend unperformanter werden. Limitierungen werden daher dazu genutzt ein gleiches Niveau für alle VMs zu schaffen.

Bandbreite

Average

  1. quota:vif_inbound_average
  2. quota:vif_outbound_average

Wie der Name schon sagt, beschränkt man hier inbound (eingehenden) sowie outbound (ausgehenden) Traffic durch einen durchschnittlichen Wert, den diese beiden nicht überschreiten dürfen.

Peak

  1. quota:vif_inbound_peak
  2. quota:vif_outbound_peak

Die Bandbreite kann man auch mit Peak sowie Burst begrenzen. Peak gibt hierbei an, bis zu welchem Limit die Bandbreite genutzt werden darf, als absolutes Maximum. Dieser Wert funktioniert aber nur in Zusammenarbeit mit „Burst“.

Burst

  1. quota:vif_inbound_burst
  2. quota:vif_outbound_burst

Burst gibt nämlich an, wie lange die Bandbreite im Wert „Average“ überschritten werden darf. Gemessen wird hier in KB. Setzt man also den Burst auf 1.048.576 KB, darf der Peak Wert solange genutzt werden, bis 1GB (1.048.576 KB) an Daten übertragen wurden. Zu Beachten ist aber, dass dieser Wert für jeden Zugriff neu gilt. Führt man also 3 Kommandos hintereinander aus (3x wget mit && verknüpft) greift der Burst für alle 3 gleichermaßen. Führt man die gleichen Kommandos ebenfalls hintereinander aus, aber verknüpft diese mit einem Sleep, greift der Burst für jedes Kommando neu.
 

IOPS

Throttle

  1. quota:disk_read_iops_sec
  2. quota:disk_total_iops_sec
  3. quota:disk_write_iops_sec

Die lesenden und schreibenden Prozesse der VMs können natürlich auch begrenzt werden. Hier gibt es zwei Möglichkeiten:

  • Limitierung von lesenden sowie schreibenden Prozessen separat
  • Limitierung auf absoluten Wert

Beides in Kombination geht nicht. Es nicht möglich zu konfigurieren, dass es 300 lesende, 300 schreibende und 700 insgesamte IOPS geben soll, würde aber auch keinen Sinn machen. Zu beachten ist, wenn alle 3 Werte gesetzt werden, können diese in einen Konflikt geraten und gegebenenfalls gar nicht greifen.

Burst

  1. quota:disk_write_iops_sec_max
  2. quota:disk_write_iops_sec_max_length

Durch das Bursting auf den Festplatten direkt, kann angegeben werden, mit welcher maximalen Anzahl an IOPS (quota:disk_write_iops_sec_max)eine VM die oben gesetzten Werte, für wie lange (quota:disk_write_iops_sec_max_length) überschreiten darf. Sinnvoll wäre dies, wenn bekannt ist, dass gewisse Prozesse kurzzeitig mehr IOPS benötigen, als freigegeben ist.

Beispiele

Um Limitierungen zu setzen, wird zunächst ein Flavor benötigt. Im Anschluss können die Werte gesetzt werden. Die Dokumentation zum Anlegen von Flavors gibts hier
openstack flavor set {$flavor} --property quota:{$param}={$value}
quota:disk_read_iops_sec='200'
(quota:disk_total_iops_sec='1000')
quota:disk_write_iops_sec='200'
quota:vif_inbound_average='10240'
quota:vif_inbound_burst='20480'
quota:vif_inbound_peak='15360'
quota:vif_outbound_average='10240'
quota:vif_outbound_burst='20480'
quota:vif_outbound_peak='15360'
quota:disk_write_iops_sec_max_length='10'
quota:disk_write_iops_sec_max='1000'
In diesem Beispiel würde man zum Beispiel die lesenden Prozesse auf 200 (quota:disk_read_iops_sec='200') beschränken, ebenso die schreibenden, bei einer eingehenden Brandbreite von 10MB(quota:vif_inbound_average='10240'). Peak liegt bei 20MB und darf für 15MB erreicht werden. Das ist natürlich ein sehr unrealistisch minimalistisches Begrenzungsbeispiel, jedoch sollte die Art und Weise wie es funktioniert verdeutlich worden sein.

Icinga 2 Best Practice Teil 3: Services überwachen

von | Jan 27, 2017 | , , ,

Nun in Teil 3 dieser Serie werden wir uns näher damit beschäftigen wie in Icinga 2 Services überwacht werden bzw. wie es zu konfigurieren ist, dass bestimmte Services nur auf bestimmten Hosts überwacht werden. Hier bietet Icinga 2 als Neuerung eine regelbasierte Zuweisung an Host-Objekte die definierten Eigenschaften genügen.

apply Service "ping4" {
  import "generic-service"
  check_command = "ping"
  assign where host.address || host.address6
}

So wird hier ein Service ping4 an alle Hosts „gebunden“, die das Attribut address oder address6 definiert haben. Nach diesem recht einfachem Beispiel wenden wir uns auch gleich etwas komplizierterem zu, der Überwachung von Dateisystemen auf einem Linux-System.

apply Service for (filesystem => config in host.vars.disks) {
  import "generic-service"
  check_command = "disk"
  command_endpoint = host.name
  vars += config
  assign where host.vars.os == "Linux"
  ignore where typeof(config) != Dictionary
}

Da hier über das CheckCommand disk, das Plugin check_disk zur Anwendung gelangt, das lokal auf dem zu überwachenden System laufen muss, wird es via command_endpoint auf genau diesem Endpoint angetriggert (siehe hierzu Teil 1 dieser Serie). Ein Host kann mehrere unterschiedlich Dateisysteme beherbergen, deshalb sind diese im Host-Objekt mit dem Custom-Attribute vars.disks zu definieren. Ausserdem muss zusätzlich, wie in dem assign-Statement gefordert, vars.os auf Linux gesetzt sein.

object Host "host.example.org" {
  ...
  vars.os = "Linux"
  vars.disks["disk /"] = {
    disk_partition = "/"
  }
  vars.disks|"disk /tmp"] = {
    disk_partition = "/tmp"
  }
}

Bekanntlich handelt es sich bei vars um ein Dictionary und vars.disks ist eine Darstellungsform eines Keys in diesem Dictionary. Eine andere Form einen Schlüssel anzusprechen ist der Index mit []-Klammern, wie in vars.disks[„disk /“]. Das heißt wir haben hier ein Dictionary in einem Dictionary. Und um es noch auf die Spitze zu treiben weisen wir den einzelnen Keys als Wert wieder jeweils ein Dictionary zu, Perl lässt grüßen. Wozu nun das Ganze? Mit apply Service for wird der Inhalt von vars.disks durchlaufen. Da es sich hierbei um ein Dictionary handelt, wird hier ein for-each verwendet, zu sehen an filesystem => config. Beides sind hier unsere Laufvariablen für die Schleife. Der Variablen filesystem wird jeweils der Key zu gewiesen, also beim ersten Durchlauf „disk /“ und beim Zweiten „disk /tmp“, in config dann demnach der zugehörige Wert. Diesen Wert, selbst ein Dictionary, kann als Konfigurations-Dictionary bezeichnet werden, der den jeweiligen Pluginaufruf von disk parametrisiert. Die möglichen Parameter für disk sind sehr gut der Online-Dokumentation zu entnehmen. Wie dies funktioniert und warum die Zeile vars += config hierzu eine zentrale Rolle spielt, wird in Teil 4 erklärt werden. Der Name des Services entspricht standardmäßig dem Inhalt von filesystem.
Selbstverständlich besitzt jedes Linux-System ein Root-Dateisystem und sagen wir, bei uns auch ein eigenes für /tmp. Natürlich möchte man nun nicht für alle seine Hosts immer diese obigen 7 Zeilen angeben müssen, deshalb definieren wir mit diesen ein Host-Template mit der Bezeichnung linux-host. Nun haben Regeln die dumme Eigenheit ihre Ausnahmen zu haben, z.B. hat der Host host.example.org im Gegensatz zu allen anderen Hosts eben kein Dateisystem /tmp. Was dann?

object Host "host.example.org" {
  import "generic-host"
  vars.disks["disk /tmp"] = false
}

Hier wird nun für /tmp die Definition aus dem Template nachträglich überschrieben. Das ignore-Statement in unserer Service-Definition sorgt dafür, dass alle Dateisysteme, denen kein Konfiguration-Dictionary zugewiesen ist, auch nicht als Service in unserer Icinga-Konfiguration landen. Bei typeof handelt es sich um eine Funktion, die die Typesierung einer Variablen ermittelt.
Bis zum nächsten Mal, ihr müsst unbedingt schauen wie es weiter geht. In Teil 4 folgt die etwas theoretische Erklärung wie solche Services jeweils einzeln unterschiedlich parametrisiert werden.

Lennart Betz
Lennart Betz
Senior Consultant
Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.
Lies mehr von Lennart und triff unser Team

The Internet On a Disk

von | Aug 31, 2008 |

Julian Hein
Julian Hein
Executive Chairman
Julian ist Gründer und Eigentümer der NETWAYS Gruppe und kümmert sich um die strategische Ausrichtung des Unternehmens. Neben seinem technischen und betriebswirtschaftlichen Background ist Julian häufig auch kreativer Kopf und Namensgeber, beispielsweise auch für Icinga. Darüber hinaus ist er als CPO (Chief Plugin Officer) auch für die konzernweite Pluginstrategie verantwortlich und stösst regelmässig auf technische Herausforderungen, die sonst noch kein Mensch zuvor gesehen hat.
Lies mehr von Julian und triff unser Team

Trainings

Web Services

Events