Ruby Applikationen testen mit RSpec und WebMock

Das Testen von Software begleitet mich von Projekt zu Projekt. Bei bisherigen Entwicklungen habe ich immer wieder auf RSpec zurück gegriffen, ein tool zum testen von Ruby Applikationen. Es zeichnet sich durch eine relativ einfache Handhabung aus und eine Ausdrucksweise die an die menschliche Sprache angelehnt ist. Auch wenn nicht jeder mögliche einzutretende Fall getestet werden kann, tests geben Entwicklern Sicherheit wenn Änderungen am Code vorgenommen werden.

WebMock

WebMock ist eine Library die es einem ermöglich HTTP requests auszudrücken und Erwartungen an diese zu setzen. In Verbindung mit RSpec lässt sich WebMock verwenden um eine Ruby Anwendung zu testen die HTTP Requests ausführt, beispielsweise an eine API. Oft sind diese Requests nicht starr sondern werden dynamisch anhand von Parametern zusammen gesetzt. WebMock/RSpec hilft dabei unterschiedliche Fälle zu simulieren, Erwartungen zu definieren und diese mit zu prüfen.

WebMock ist als Gem verfügbar, die Installation ist daher relativ einfach:

user@localhost ~ $ gem install webmock

Als Beispiel verwende ich eine sehr simple Ruby Klasse. Deren einzige Methode ‘request’ sendet einen GET request an die URL ‘https://wtfismyip.com’. Abhängig vom Parameter ‘option’ wird die IP entweder in Textform oder als JSON abgefragt:

require 'net/http'
require 'uri'

class ApiCaller
  def self.request(option)
    uri = URI.parse("https://wtfismyip.com/#{option}")
    http = Net::HTTP.new(uri.host, uri.port)
    http.use_ssl = true
    request = Net::HTTP::Get.new(uri.request_uri)
    http.request(request)
  end
end

Mein Test beinhaltet den Aufruf der ‘request’ Methode. Der HTTP request wird simuliert und die Erwartung das ein Request an eine bestimmte URL stattfinden soll wird auch definiert.

require 'api_caller'
require 'webmock/rspec'

describe ApiCaller do
  describe '.request' do
    context 'given json parameter' do
      it 'requests json url' do
        stub_request(:get, 'https://wtfismyip.com/json')
        expect(ApiCaller.request('json')).
          to have_requested(:get, 'https://wtfismyip.com/json').once
      end
    end

    context 'given text parameter' do
      it 'requests text url' do
        stub_request(:get, 'https://wtfismyip.com/text')
        expect(ApiCaller.request('text')).
          to have_requested(:get, 'https://wtfismyip.com/text').once
      end
    end
  end
end

Beim testen sieht das nun folgendermaßen aus:

user@localhost ~ $ rspec --format documentation

ApiCaller
  .request
    given json parameter
      requests json url
    given text parameter
      requests text url

Finished in 0.00557 seconds (files took 0.37426 seconds to load)
2 examples, 0 failures
Blerim Sheqa

Autor: Blerim Sheqa

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. Mittlerweile kümmert sich Blerim hauptsächlich im Icinga Umfeld um die technischen Partner und deren Integrationen in Verbindung mit Icinga 2.

Icinga 2 – Multi-Zonen Notifications

Komplexe Monitoring Umgebungen mit Icinga 2 kennt man ja schon und auch was sich alles mit den Satelliten und zus. Zonen-Mastern anstellen lässt. Aber wisst ihr auch, dass sich gezielte Benachrichtigungen für einzelne Zonen definieren lassen? Die meisten nutzen wahrscheinlich schlicht nur die Haupt/Master Zone für Notifications; aber gehen wir doch von einem nicht unüblichen Beispiel aus : Der externen Überwachung des eigenen Monitorings.

Wir wollen, dass der externer Satellit uns autark kontaktiert sobald das Monitoring ausfällt und im Sinne des Directors, ebenso wenig eine manuell Konfiguration pflegen. Jetzt muss er die Benachrichtigung nur irgend wie zu uns bekommen. Das Wissen über die Objekte sollte bei solchen Setups vorhanden sein, daher werde ich keine Screens oder Config-Auszüge einfügen, sondern nur das Vorgehen beschreiben.

Wie einfach das Ganze mit Zonen-Verzeichnissen und einem Parameter realisiert werden kann, zeigt sich wie folgt. Wir generieren das entsprechende Notification-Command für den Satelliten und stellen sicher, das er es, sowie die betreffenden Kontakte, in seiner Zone finden kann. Anschließend folgt auch schon das Notification Objekt, welches a.) einfach mit in das Zonen-Verzeichnis des Satelliten geschoben, oder b.) global um den Parameter “zone” erweitert wird. Und schon kann es los gehen.

All das lässt sich übrigens auch wunderbar in einem NWS Satelliten abbilden. Probiert es einfach mal aus.

Ronny Biering

Autor: Ronny Biering

Vor NETWAYS arbeitete Ronny bei einem der großen deutschen Internet- und Hosting Provider. Hier betreut er zusammen mit seinen Kollegen aus dem Bereich Managed Services die Plattformen unserer Kunden. Im Gegensatz zu dem üblichen Admin-Cliche, gehört Fitness zu einer seiner Lieblingsfreizeitbeschäftigung.

WLAN in deutschen ICEs

WIFIinICE

WLAN im Zug

Seit Anfang diesen Jahres wurde die Angebotspalette in den deutschen ICE Zügen um ein kostenloses WLAN in allen Klassen erweitert. Das kommt den viel reisenden Kollegen von Netways zu gute, welche oft im Zug unterwegs sind. Sei es jetzt unser Consulting Team, der Vertrieb auf dem Weg zum Kundentermin oder unsere Event Abteilung unterwegs zum nächsten Highlight.

Wir wollen das Ganze aber mal etwas genauer unter die Lupe nehmen und schauen, warum es besser ist als ein Hotspot per Handy oder Tablet mit seinem eigenen Mobil-Provider. Hintergrund ist die Technik, welche mit dem Partner Icomera aus Schweden zum Einsatz kommt. Sie koppelt sich parallel zu den 3 großen Anbietern (Telekom, Vodafone, Telefónica) um eine stabile und dauerhafte Verbindung herzustellen und zu gewährleisten. Damit werden Unterbrechungen auf ein Minimum reduziert und treten meist nur in langen Tunnelfahrten auf. Man bleibt aber verbunden und kann im Anschluss sofort weiter surfen.

Zu erwähnen ist noch ein Datenvolumen von 200 MB pro Tag in der 2. Klasse. Ist das Volumen aufgebraucht, wird die Geschwindigkeit reduziert, damit alle Passagiere eine gleichbleibenden Qualität nutzen können. Die Geschwindigkeit nach der Drosselung ist aber noch höher als man sie von Mobilanbietern kennt. Jedoch sollten 200 MB in den meisten Fällen pro Fahrt für eine normale Nutzung ausreichen. Es ist daher zu empfehlen, die WLAN Verbindung als ‘getaktet’ zu markieren um Hintergrundaktivitäten seiner Geräte zu mindern. Unnötige Downloads, Updates oder Streams sollten ebenfalls vermieden werden.

Werfen wir noch einen Blick auf die Sicherheit. Dabei kommen viele moderne Umsetzungen und bekannte Technologien wie z.B. die Client Isolation zum Einsatz. Jedoch ist das ganze immer noch ein HotSpot Angebot und ein Abfangen von Informationen kann nicht grundsätzlich ausgeschlossen werden. Nutzern mit sensiblen Daten wird daher die Verwendung einer VPN Verbindung und das surfen per HTTPS empfohlen.

Als Schlusswort kann ich die Nutzung nur empfehlen und begrüße das neue WLAN in den ICEs. Da ich selbst jede Woche sehr oft 5-6 Stunden pro Fahrt unterwegs bin, kann ich so mein Büro mitnehmen und die Zeit sinnvoll nutzen.

Bei weiterem Interesse, kann man sich auf den Portalen der Deutschen Bahn informieren (hier und hier)

Ronny Biering

Autor: Ronny Biering

Vor NETWAYS arbeitete Ronny bei einem der großen deutschen Internet- und Hosting Provider. Hier betreut er zusammen mit seinen Kollegen aus dem Bereich Managed Services die Plattformen unserer Kunden. Im Gegensatz zu dem üblichen Admin-Cliche, gehört Fitness zu einer seiner Lieblingsfreizeitbeschäftigung.

Monitoring Plugins in Go

Auf Twitter hat Jan Schaumann vor Kurzem begonnen eine Liste aufzustellen mit Dingen, die jeder Sysadmin in seinem Leben schon mindestens ein mal getan hat. Darunter zählen Sachen wie einen Parser für den ifconfig Befehl zu schreiben oder unvollständige Regexes für IP Adressen zu basteln. Beim Durchgehen dieser Liste habe ich mich immer wieder selbst ertappt. Es ist erschreckend, wie viele von diesen Dingen auf einen selbst zutreffen. Dennoch ist es sehr amüsant zu lesen.

Bei Netways arbeiten wir sehr viel im Bereich Monitoring. So ist es kein Wunder, das ich bei den Dingen die jeder Sysadmin schon mal getan hat, sofort auch an dieses Thema denken musste. Lange muss man da auch nicht überlegen: Jeder Sysadmin hat mindestens schon ein mal in seiner Karriere ein monitoring Plugin geschrieben. Das gehört einfach dazu und selbst DevOps wird uns vermutlich nicht davor bewahren.

Das Schreiben von monitoring Plugins ist auf den ersten Blick ein ziemlich einfaches Thema. So ein Plugin muss einen Rückgabewert von 0, 1 oder 2 liefert und im besten Fall einen Text ausgeben, der den Zustand beschreibt. Damit wären schon mal alle Grundvoraussetzungen gegeben. Weil es eben so einfach ist, gibt es auch so viele von diesen Plugins. Sie werden in nahezu jeder Programmiersprache geschrieben. Manche Plugins sind umfangreich mit vielen Optionen und noch mehr Performance Daten in der Ausgabe. Andere wiederum bestehen nur aus wenigen Zeilen und erfüllen einen einzigen speziellen oder simplen Zweck.

Was mich bei monitoring Plugins schon immer gestört hat, ist das Deployment von jenen. Je nachdem in welcher Sprache das Plugin entwickelt ist, müssen mit cpan, gem, pip, npm, pear, composer oder andern Package Managern Abhängigkeiten nachinstalliert werden. So richtig lästig wird das bei ein paar Hundert Plugins für ein paar Tausend Server mit unterschiedlichen Distributionen. Sind Windows Systeme dabei, … ach davon fang ich garnicht erst an.

Welche Lösung gibt es also dafür? Noch keine fertige, zumindest meiner Meinung nach. Selbst Configuration Management löst das Problem nicht ganz. Um das vernünftig zu machen, müsste man ja seine 3-Zeiler Plugins packetieren und vernünftige Module oder Cookbooks schreiben, die das dann auf die Systeme ausrollen. Bestenfalls natürlich auf jedes System nur die Plugins die dort auch wirklich hin gehören. Seitdem ich mich bezüglich eines Projekts aber mit der Programmiersprache Go auseinander setze, beschäftigt mich ein anderer Ansatz um das Problem zu lösen: was wäre, wenn so ein Plugin gar keine Abhängigkeiten hat?

Go ist eine Programmiersprache, deren Wurzeln bei C liegen. Sie ist dementsprechend auch keine Scriptsprache wie Ruby oder Python, fühlt sich manchmal aber trotzdem so an. Das führt dazu das Leute wie ich, die aus der Scripting Welt kommen, sich sehr schnell wohl fühlen mit Go. Ob Go eine objektorientierte Sprache ist, da scheiden sich die Geister. Objekte im klassischen Sinne gibt es nicht, zumindest werden sie nicht so genannt. Betrachtet man es im Detail, kann man aber nachvollziehen warum es Stimmen gibt, die Go als objektorientiert bezeichnen.

Wie bei anderen Sprachen auch gibt es bei Go viele Libraries die verwendet werden können, sie werden aber Packages genannt. Der in Go geschriebene Code muss kompiliert werden. Ein großer Vorteil dabei ist, dass die entstandenen Binaries standardmäßig statisch gelinkt sind. Das heißt im Umkehrschluss es muss nichts nachinstalliert werden mit gem, pip, cpan usw. Alles steckt schon in dieser einen Binary. Sicherlich lässt sich dasselbe auch mit C, C++ oder anderen Sprachen erreichen. Keine ist aber so einfach und einsteigerfreundlich wie Go. Das zählt für mich als sehr großer Vorteil, schließlich werden diese Plugins oft von Sysadmins entwickelt, deren Hauptbeschäftigung nicht das Programmieren ist.

Statisch gelinkte Binaries könnten also das Problem der Abhängigkeiten lösen. Spinnt man die Idee weiter, könnte man mit einem “monitoring plugin” Package für Go ein Framework schaffen mit dem einheitliche Plugins entwickelt werden. Eine tolle Idee, wenn ihr mich fragt. Das Problem des packetierens lässt sich übrigens wunderbar mit fpm lösen, dazu aber vielleicht ein anderes Mal mehr.

Mein Aufruf an dieser Stelle also: Schreibt eure monitoring Plugins in Go, denn ich möchte mich nicht stundenlang damit Beschäftigen sie zum Laufen zu kriegen!

Blerim Sheqa

Autor: Blerim Sheqa

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. Mittlerweile kümmert sich Blerim hauptsächlich im Icinga Umfeld um die technischen Partner und deren Integrationen in Verbindung mit Icinga 2.

Get ready with NETWAYS

This entry is part 1 of 11 in the series Azubis erzählen

nerd_of_awesome_by_movillefacepalmplz-d5qvmzxGet ready with NETWAYS! Das trifft für mich auf die letzten 3 Jahre zu, in denen ich meine Ausbildung hier bei NETWAYS absolvieren durfte. An meinem ersten Tag, hatte ich keine Ahnung von Linux, Servern geschweige denn von OpenSource. Aber das hat hier niemanden abgeschreckt und mir wurde über die Zeit alles nötige beigebracht um selbstständig arbeiten und lernen zu können. Verschiedene Linux Distributionen, Hardware und Verkabelungen im Rechenzentrum, Pflege der HQ-Infrastruktur, Kundensupport und auch die Entwicklung einiger Automatisierungsskripte waren unter anderem Teil meiner Ausbildung hier. Ich empfand es als großen Vorteil, Teil einer verhältnismäßigen jungen und aufstrebenden Firma zu sein, allein schon deswegen, weil man jeden einzelnen Kollegen beim Namen kennt. Aber auch deswegen, weil eine Firma wie diese, viele neue Produkte testet und versucht sie in den produktiven Einsatz zu überführen. Manchmal erfolgreich, manchmal eher weniger. So bekommt man sehr viel von der “neuen Technik” mit und sieht in manchen Situationen auch wie es nicht geht.

Besonders überrascht war und bin ich teilweise immernoch, über den Umgang miteinander. Es herrscht ein eher freundschaftliches Verhältnis, sodass man auch in der Freizeit oder nach Feierabend mal zusammen einen trinkt, die ein oder andere Feier miterlebt oder eine LAN-Party veranstaltet. Auch Konferenzen und Schulungen in Nürnberg, Berlin, Köln, Düsseldorf, Barcelona oder den USA waren bisher immer ein sehr angenehmes Erlebnis. Soweit also eine Firma, in der man jeden Tag aufs neue gern arbeitet.

Zu jeder Ausbildung gehört am Ende auch eine Abschlussarbeit in Form eines Projektes und dessen Dokumentation. Mein Projekt befasst sich damit, eine Docker-Registry aufzusetzen. In diesem Projekt war sehr viel gefordert. Ich musste mich in kurzer Zeit in ein neues Thema einarbeiten, eine virtuelle Maschine mit entsprechenden Anforderungen aufsetzen, Fehler korrigieren, so viel automatisieren wie möglich und alles anschließend dokumentieren. Als letztes gilt es dieses Projekt im Sommer einem Prüfungsausschuss zu präsentieren und sich deren Fragen zu stellen.

Nach erfolgreichem Abschluss meiner Ausbildung werde ich im Support arbeiten und versuchen unseren Kunden bestmöglich zu helfen. Ich freue mich auf die Arbeit und auch darauf weiterhin zu lernen und Erfahrungen zu machen.

Trotz alledem lernt man nie aus und es ist auch unmöglich alles beigebracht zu bekommen. Aber bei NETWAYS bekommt man eine sehr gute Vorbereitung auf den Alltag in der IT Branche nach der Ausbildung. Für den Fall, dass jemand auf der Suche nach einer geeigneten Firma ist, dann ist er bei uns an der richtigen Stelle!

 

Marius Gebert

Autor:

Marius ist seit September 2013 bei uns beschäftigt. Er hat im Sommer 2016 seine Ausbildung zum Fachinformatiker für Systemintegration absolviert und kümmert sich nun um den Support unserer Hostingkunden. Seine besonderen Themengebiete erstrecken sich vom Elastic-Stack bis hin zu Puppet. Auch an unserem Lunchshop ist er ständig zu Gange und versorgt die ganze Firma mit kulinarischen Köstlichkeiten. Seine Freizeit verbringt Marius gern an der frischen Luft und wandert dabei durch die fränkische Schweiz

Docker-Registry und das Geheimnis des Löschens

DockerLogo

Wenn man sich dazu entschließt, eine Docker-Registry zu installieren und zu konfigurieren, möchte man Images zentral abspeichern und verwalten können. Dies bietet viele Vorteile für den abteilungsübergreifenden Einsatz von Docker, aber auch ein paar Komplikationen im Umgang mit der Registry.
Wenn man mit dieser Registry arbeitet, entsteht irgendwann folgendes Problem. Das Löschen von Images funktioniert nicht wirklich.

Der Server ist fertig konfiguriert und man übermittelt Images an die Registry.
Der Speicherplatz wird zunehmend belegt, es liegen veraltete Images im Storage, die nicht mehr benötigt werden. Laut der Dokumentation von Docker, soll dieses Problem dadurch gelöst werden, dass man über die API Images “ganz einfach” löschen kann:

curl -k -X DELETE https://localhost:5000/v2/$imagename$/manifests/latest

Jedoch werden sich viele dann über diese (oder ähnliche) Fehlermeldung(en) ärgern:

{"errors":[{"code":"INVALID_DIGEST","message":"The digest is invalid"}]}

Laut Dokumentation, kann ein Image über die API nur dann gelöscht werden, wenn es durch den Namen und die Referenz(Tag, zum Beispiel “latest”) identifiziert werden kann, jedoch nur mittels “Digest”.
Ein Digest ist ein Wert um ein Image eindeutig identifizieren zu können. Er wird beim zum Beispiel bei einem Pull oder Push angezeigt. (Achtung! Der Digest ist nicht die Image ID, die beispielsweise bei einem “docker images” Command angezeigt wird.)

docker pull ubuntu
(...)
93f3596230c2: Pull complete
c06698a70f80: Pull complete
b6ea91fdc1f6: Pull complete
a53404c22cd2: Pull complete
Digest: sha256:c9f94277901034f3f40e73c861aee970da33dce9af2c02f13e1a4a72cdc0f8cb

Das Problem ist nun, dass der oben genannte DELETE nicht funktioniert. Eine kritische Alternative hierfür ist, auf der Commandline das Verzeichnis zu löschen

rm -rf ubuntu

Das Problem hierbei wären die Blobs, die als “Leiche” zurück bleiben würden. Wieso dies kritisch ist, möchte ich kurz versuchen zu erklären:
Jedes Image, besteht aus mehreren Layern, wobei die Layer aufeinander aufbauen. Der oberste Layer bekommt einen Tag (zum Beispiel “latest”). Blobs sind “BlobSums” (Digest) für die einzelnen Layer. Die einzelnen Layer sind wie der Digest des kompletten Images bei einem Pull, Push oder einem Api Request ersichtlich.

"schemaVersion": 1,
"name": "ubuntu",
"tag": "latest",
"architecture": "amd64",
"fsLayers": [
{
"blobSum": "sha256:a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4"
},
{
"blobSum": "sha256:a53404c22cd2ac9f68c352d17667ec1a2e36f22ca729983c40e1f24c106def6f"
},
{
"blobSum": "sha256:b6ea91fdc1f68eb0274174fd8c4eeea4baeee4986c942cbc7a21be82778e78b3"
},
{
(etc)

Beim Push in die Registry wird im Verzeichnis “blob” ein Eintrag für jeden Layer angelegt, mit der jeweiligen BlobSum. Löscht man nun ein “Image” aus der Registry, werden nur die Daten des Images gelöscht die im Verzeichnis “v2/repositories/$IMAGENAME” liegen. Auf den ersten Blick ist das Image gelöscht, denn in der Registry wird es nicht mehr als verfügbares Images zum Pull angezeigt. Die restlichen Layer jedoch und somit auch die Blobs, bleiben bestehen, womit sehr viel Speicherplatz mit nicht nutzbaren Daten belegt wird. Auch andere, von Docker erstellte Abhängigkeiten werden so nicht gelöscht. Das Problem ist dann, dass das Pushen des selben Images zurück in die Registry fehlerhaft sein wird, da versucht wird, Layer zu pushen, die schon hinterlegt sind und zu einem Image gehören aber nicht mehr zuordbar sind.

Komplizierter würde es werden, wenn man zum Beispiel nicht nur ein Image löschen möchte, sondern beispielsweise alle “untagged Images”. Dies sind veraltete Images, ohne einen Tag. Dies geschieht beispielsweise bei einem Push eines Images mit dem gleichem Namen.

Will oder kann man die Images nicht über die API löschen bietet “Burnettk” auf GitHub mit einem kleinen Skript eine gute Alternative.
Es handelt sich hier um ein Script, das ein Image anhand des Names identifiziert, und alles dazugehörige löscht. Was hierfür nötig ist, ist eine Environment Variable, die auf das Reporitory gesetzt wird. Als Beispiel:

export REGISTRY_DATA_DIR=/opt/registry_data/docker/registry/v2

Dannach kann das Script als normales Command genutzt werden. Um alle untagged Images zu löschen, kann man mit einer kleinen Schleife arbeiten, die innerhalb des Repoitory Verzeichnisses läuft:

for i in *; do delete_docker_registry_image --untagged --image $i; done;

Wenn man in diesem Verzeichnis, Images in einem weiteren Unterverzeichnis abspeichert, muss das Script kopiert und angepasst werden:

repositories_dir="repositories/$UNTERVERZEICHNIS"

An dieser Stelle bietet es sich auch an, diesen Löschvorgang in Form eines Crons zu automatisieren. Das Problem, dass die Registry zu wenig Speicherplatz frei hat, wäre so gelöst. Vielleicht kommt von Docker in den nächsten Docker-Engine Versionen eine brauchbare Lösung mit, jedoch ist das für mich die bisher beste Lösung.
dockerDocker, Docker, Docker!

Marius Gebert

Autor:

Marius ist seit September 2013 bei uns beschäftigt. Er hat im Sommer 2016 seine Ausbildung zum Fachinformatiker für Systemintegration absolviert und kümmert sich nun um den Support unserer Hostingkunden. Seine besonderen Themengebiete erstrecken sich vom Elastic-Stack bis hin zu Puppet. Auch an unserem Lunchshop ist er ständig zu Gange und versorgt die ganze Firma mit kulinarischen Köstlichkeiten. Seine Freizeit verbringt Marius gern an der frischen Luft und wandert dabei durch die fränkische Schweiz