Numeric datatypes as primary key in databases

Most likely primary keys in databases are numbers. But what happens, when an administrator uses the wrong numeric data type? In the worst case, databases can’t write down entries anymore.

For example, if an administrator wants to write customer information into the databases and wants to use the customerID itself as the primary key, then the numeric data type “TINYINT” would cause that only 255 entries can be written. But on the other hand the “BIGINT” numeric data type, could be too large for smaller databases.
So when you are setting up a database, you should think about how many entries will be written the next months/years and think about which datatype is the right one for your setup. Also you should think about if you should use the data types unsigned or not. This value will change the range of the datatypes.

Typ signed unsigned
Min Max Min Max
TINYINT -128 +127 0 255
SMALLINT -32.768 +32.767 0 65.535
MEDIUMINT -8.388.608 +8.388.607 0 16.777.215
INT/INTEGER -2.147.483.647 +2.147.483.646 0 4.294.967.295
BIGINT -263 +263 – 1 0 264 – 1

Another example:
If an administrator wants to store 60000 customer information in the database, he should use at least a “SMALLINT”. Should he use the unsigned version or not? Lets have a look.
With the signed data type he has a range from -32.768 up to +32.767, but no customerID (primary key as mentioned above) has a negative number, so a “unsigned SMALLINT” would be necessary.

The case, that you thought about the questions above but your data type got out of range, could happen. There is a way to change the datatype and to increase the range in a simple way.
*ALTER TABLE tablename MODIFY column MEDIUMINT UNSIGNED;*
But remember: The larger your database is, the longer will it take to do such changes!

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

Clustershell und Foreman-API

i-love-apisForeman bietet die Möglichkeit verschiedene Informationen über die Hosts einzusehen. Dazu gehören der Status, das Betriebssystem, Ressourcen etc. Möchte man nun, auf mehreren Hosts gleichzeitig ein Kommando absetzen, kann man sich auf jedem einzelnen einloggen oder eine Clustershell aufbauen.
Hierfür gibt es verschiedene Tools die dies erlauben. Eine Unbequemlichkeit die hier jedoch schnell aufkommt, ist das kopieren und einfügen der Hostnamen in die Commandline. Aus diesem Grund, habe ich etwas Zeit investiert und ein Ruby Script geschrieben, das es mir ermöglicht, mit festgelegten Filtern nach speziellen Listen von Hostnamen zu suchen und diese als eine einzige Ausgabe zu speichern. Ich habe für das erzeugen von Clustershells “csshX” im Einsatz, welches ich auch direkt mit eingebunden habe.

Das get_hosts Script gibt es als GIST.

In diesem Script wird zunächst eine “config.yml” geladen, in der die Foreman-URL und der Nutzername definiert sind. Eine Passwortabfrage erfolgt in diesem Script direkt auf der Commandline. Anschließend wird die Ausgabe der Foreman-API nach dem Auflisten aller Hostinformationen in JSON geparst und alle verfügbaren Parameter für die Hosts in das entsprechende Array gespeichert. Mit dem Parameter “-s / –server” gibt man einen String an, nachdem speziell gesucht werden soll. Diese Ausgabe wird zusätzlich mit angehängt.

Gefiltert wird nach:
1) Reports enabled
2) OS Ubuntu 14.04 / Debian 8
3) Kein Match auf net-* oder netways.de (Als Beispiel)

Von den selektierten Hosts werden die Hostnamen in einer Commandline-Ausgabe mit einem Leerzeichen getrennt ausgegeben. Verschiedene werden sich eventuell fragen: “Wofür brauche ich das? Wieso sollte ich so ein Script verwenden?”
Die Antwort ist einfach: Bequemlichkeit und live Übersicht, was gerade passiert. Die Suchparameter lassen sich sehr leicht anpassen und die Ausgabe des Scriptes wird etwas an Zeit der administrativen Aufgaben sparen, vorallem dann, wenn man mehr als nur 2 oder 3 Server mit Puppet bespielen lassen möchte.

user@computer ~/Documents/ruby/foreman $ ruby script.rb
Enter password:
[ ] Trying to establish a connection...
[OK] Password correct
[OK] Connection established
[ ] Collecting data...
[OK] Data collected
[RESULTS]
Ubuntu
csshX --login root test1.test.de test2.test.de test34.test.de test19.test.de mail.test.de icinga-001.test.de
Debian
csshX --login root icinga-002.test.de db-003.test.de db-021.test.de
Finished succesfully

Wie bereits erwähnt, ist hierfür noch eine “config.yml” Datei nötig, die gewünschte Parameter enthält. In diesem Fall die URL und den usernamen. Aber auch ein Gemfile, das sich in Ruby um bestimmte Versionen von Gems kümmert. (Mit einem “bundle install” können diese installiert werden)

Die config.yml und das Gemfile gibt es ebenfalls als GIST.

Eingebaute “rescue Execptions” im Script selbst, geben entsprechende Rückmeldung, sollte der Login oder eine der auszuführenden Verarbeitungsschritte fehlschlagen und brechen den Vorgang an dieser Stelle ab.

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

“Multiline” mit Filebeat

simplimages

Das analysieren von Logs mit dem ELK-Stack ist an sich relativ simpel. Ein Problem auf das man hierbei stoßen kann, sind jedoch Logeinträge aus mehreren Zeilen bestehen (“Multiline”).  Das Problem hierbei ist, das Logstash jede dieser Zeilen als einzelne Events versteht und verarbeitet, wodurch das Kibana sehr schnell unübersichtlich werden kann.
Wenn man hierzu etwas recherchiert, kommt man sehr schnell auf eine “Lösung” die wie folgt aussieht:

filter {
multiline {
type => "type"
pattern => "regexpattern"
negate => boolean
what => "previous" or "next"
}
}

Mit dieser Methode, wird am Logstash ein Filter angelegt, der “multiline” erkennt und diese anhand von Regexpattern zusammenfügt. Erfahrungsgemäß funktioniert dies jedoch nicht immer wie gewünscht. Eine wesentlich bessere Methode ist meiner Meinung nach, direkt am Client anzusetzen, der die Logs verschickt. Hierzu kann ich den Einsatz von Filebeat empfehlen.

Die Installation ist sehr simpel:
curl -L -O https://download.elastic.co/beats/filebeat/filebeat_1.3.1_amd64.deb
sudo dpkg -i filebeat_1.3.1_amd64.deb

Alternativ, kann man natürlich auch die Apt-Source mit dem entsprechenden Key lokal hinzufügen und mit dem Paketmanager arbeiten. Nach der Installation steht die Konfiguration aus. Die dafür zuständige Datei ist “/etc/filebeat/filebeat.yml”. Die ist zwar dank vielen Kommentaren sehr lang, doch das wesentliche sieht in einem Beispiel wie folgt aus:

filebeat:
prospectors:
-
paths:
- /var/log/my_multiline_1/*
input_type: log
multiline:
pattern: ^[a-zA-Zä]{3}\ [0-9]{2}\,\ [0-9]{4}
negate: true
match: after
######
-
paths:
- /var/log/my_multiline_2/*
input_type: log
multiline:
pattern: ^[a-zA-Zä]{3}\ [0-9]{2}\,\ [0-9]{4}
negate: true
match: after
######
registry_file: /var/lib/filebeat/registry
######
output:
logstash:
hosts: ["$IP_OF_LOGSTASH:$INPUT_PORT"]
######
logging:
files:
rotateeverybytes: 10485760 # = 10MB

Hierbei werden für verschiedene Logs verschiedene “Prospectors” konfiguriert. Hierzu sind lediglich Informationen über den “input_type”, den Regexpattern nötig und eine Art und Weise wie Logs zusammengefügt werden sollen nötig. In diesem Beispiel würden alle Zeilen, auf die der Regexpattern nicht zutrifft, an die Zeile angefügt, auf die der Regexpattern zutrifft. Mit jeder Änderung am Filebeat, muss der dienst neu gestartet werden.

Damit Logstash aber auch zusätzlich Daten von der neuen Quelle “Filebeat” annimmt und verarbeitet, muss ein neuer “Input” und “Output” definiert werden.

input {
beats {
port => $INPUT_PORT
}
}
output {
redis {
data_type => "list"
key => "logstash"
}
}

Auch hier muss der Logstash natürlich neu gestartet werden. Anschließend können die zusammengefügten Logeinträge im Kibana unter die Lupe genommen werden und im Logstash weiter zerlegt werden.

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

Wissenstransfer bei NETWAYS

Social education communication concept

Oft hat man das Problem, dass Kollegen aus unterschiedlichen Abteilungen bei Gesprächen, nicht nachvollziehen können, über was der jeweils andere redet. Verdutzte Gesichter und Ratlosigkeit gerade aus Abteilungen die wenig mit Technik zu tun haben – kamen vor.  Eine Möglichkeit eben jenem Problem vorzubeugen und das Verständnis der Mitarbeiter zu erweitern, sind Wissenstransfers innerhalb einer Firma. Es wird Wissen über Technik, kaufmännische Themen oder organisatorische Themen ausgetauscht und so der Horizont der Teilnehmer erweitert.

Um eben dies zu erreichen, haben wir bei uns diverse interne Schulungen eingeführt. Diese Schulungen dienen zum einem eben dem Wissenstransfer, aber auch dem Crashkurs neuer Kollegen oder Azubis.
Allein in dieser Woche hatten wir hierzu 2 Schulungen. Eine zweitägige Veranstaltung wurde mit dem Thema “Linux” versehen, in der alle Teilnehmer in den Grundkenntnissen im Umgang  mit einem Linuxsystem geschult wurden, sowie eine eintägige Schulung für die Neuankömmlinge. Thema hier waren sämtliche Tools, interne Workflows und alles Wissenswerte über unser Produkt-Portfolio.

Das Konzept dieser Transfers erfreut sich intern großer Beliebtheit. Kollegen aus “Events&Marketing” aber auch aus Sales, sind beispielsweise nun in der Lage, in vereinfachter Weise mit Linux umzugehen oder gar bei Gesprächen der Kollegen mitzuwirken. Andersherum verstehen die Kollegen aus “Managed Services” Probleme der anderen Abteilungen besser.

Diese Schulungen tragen somit auch wesentlich dazu bei, die Kommunikation intern zu verbessern und auf Probleme andere besser eingehen zu können.

crvcq9hwyaaodyf crqspfaxyaa94zo

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

MesosCon Europe

Dieses Jahr findet die MesosCon Europe in Amsterdam statt. Neben schönem Wetter und einer tollen Stadt erwartet uns ein breites Programm rund um das Apache Mesos Framework.

Mesos selbst ist ein Cluster Framework zur Verwaltung der im Rechenzentrum zur Verfügung stehenden Ressourcen (z.B. CPU, Ram, Storage). Ein Scheduler in Mesos bietet diese Ressourcen verschiedensten Applikationen an und startet diese. Insbesondere im Containerumfeld bietet Mesos in Kombinationen mit Marathon (ein Mesos Plugin) viele Möglichkeiten seine Applikationen zu verwalten.

Die kürzlich veröffentlichte Version 1.0 ist natürlich ein großes Thema. So bietet Mesos jetzt neben einer neuen HTTP API auch einen unified containerizer zum Starten verschiedener Container Formate. Auch im Networking Bereich bietet die neue Version neue Features, vor allem die Möglichkeit eine IP je Container zu vergeben gehört zu den Highlights. Nicht zuletzt wird der Release von einem neuen Autorisierungsmodell abgerundet.

Das breit angelegte Programm bietet in den nächsten zwei Tagen Vorträge zu vermutlich allen Themen rund um Mesos, Marathon, Microservices, Service Discovery, Storage, DC/OS und mehr, aber natürlich geben auch namhafte Firmen wie Twitter und Netflix Einsicht in ihre Setups, bei denen natürlich Mesos die Microservices verwaltet.

Ein Hackathon am Freitag lässt die Konferenz schön ausklingen. Leider geht es für uns vorher schon zurück nach Nürnberg.

Achim Ledermueller

Autor: Achim Ledermueller

Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist unter anderem für die Automatisierung des RZ-Betriebs und der Evaluierung und Einführung neuer Technologien zuständig.

Chef Cookbook Integration Tests mit TestKitchen

Infrastructure as Code ist zu einem der wichtigsten Themen angewachsen mit denen sich Admins und ganze IT Abteilungen beschäftigen. Wie immer wenn es um Code geht, spielt die Qualität von diesem eine wichtige Rolle. Wenn man seine Chef Cookbooks nicht gerade nur für sich selbst schreibt, sondern gern auch veröffentlichen möchte, gehört Qualität zum guten Ton. Eines der Qualitätsmerkmale ist die Anwendbarkeit des Cookbooks auf verschiedene Betriebssysteme und Versionen. Hier beginnt auch schon die Schwierigkeit: Oft wird ein Cookbook für das System geschrieben das man selbst verwendet, schlicht, weil man andere Systeme ja nicht zum Testen hat. Sicherlich ist die Zeit ein wichtiger Faktor dabei, es hat aber auch kaum jemand Lust dazu sich mit der Installation von mehreren VMs zu beschäftigen. Um richtig testen zu können, müssen diese ja auch regelmäßig zurückgesetzt werden. Abhilfe schafft da das Chef Development Kit (ChefDK).

ChefDK
Im Development Kit sind alle Tools enthalten die man braucht zum Cookbooks zu entwickeln, testen und maintainen. Es ist zudem für alle großen Betriebssysteme verfügbar. Mit dem Commandline tool chef kann man die ersten Schritte gehen: Cookbook generieren, templates anlegen etc. Auch mit dem zentralen Server kann man kommunizieren, etwa um Cookbooks zu installieren. Ein Chef Client ist im Kit auch enthalten, mit ihm lassen sich Cookbooks direkt ausführen. Das Chef Ökosystem bietet relativ viel um Cookbooks zu testen, das Wichtigste ist im ChefDK mit drin:

TestKitchen
Nun also zurück zum Problem mit dem testen von verschiednen Betriebssystemen und deren Versionen. TestKitchen zielt genau darauf ab, dieses Problem zu lösen. In einer Yaml Datei (.kitchen.yml) wird eine Testmatrix angelegt die festlegt, was genau getestet werden soll. Dazu gehören die Betriebsysteme, deren Versionen und eine oder mehrere Suites die auf diese angewendet werden sollen. Suites bestehen aus einer Liste von Recipes die ausgeführt werden. Dazugehörige Attribute können ebenfalls gesetzt werden. Beispielhaft sieht das dann so aus:

---
driver:
  name: vagrant

provisioner:
  name: chef_zero

platforms:
  - name: ubuntu-16.04
  - name: centos-7.2
  - name: windows-2012r2

suites:
  - name: icinga2server
  run_list:
    - recipe[icinga2::server]
  attributes:
    icinga2:
      version: '2.4.10-1'

Mit dem CLI Kommando kitchen kann das Cookbook jetzt auf den aufgelisteten Plattformen ausgeführt werden. Voraussetzung in diesem Beispiel ist, dass Vagrant installiert ist. Auch andere Driver können verwendet werden, Beispiele dafür wären Docker, HyperV oder OpenNebula. Eine gesamte liste findet man in der Dokumentation.

kitchen test

Das Kommando führt ein mal den gesamten Ablauf durch: VMs erstellen, Cookbook ausführen, Zustand prüfen und VMs wieder zerstören. Für jede Kombination zwischen Plattform und Suite werden mithilfe von Vagrant virtuelle Maschinen erstellt. Die dazugehörigen Boxen werden Standardmäßig von Bento angezogen. Beim ausführen sollte man aber vorsichtig sein, je nachdem wie viele Tests und Plattformen man aufgelistet hat, kann das zu relativ vielen VMs führen, was dann gerne auch mal dazu führt, dass das eigene System lahmgelegt wird.

Um das Problem zu umgehen können einzelne Instanzen erstellt werden, indem man genau angibt welche Kombination man testen möchte:

kitchen setup server-ubuntu-1604

Dieses Kommando wird eine VM mit Ubuntu 16.04 erzeugen, einen Chef Client auf dieser installieren und das Cookbook ausführen. Im Idealfall steht dann eine VM auf dem das Cookbook erfolgreich ausgeführt wurde. Man kann sich auf dieser dann auch einloggen, um ggf. manuell zu prüfen ob alles glatt gelaufen ist:

kitchen login icinga2server-ubuntu-1604

Eine Liste aller Instanzen bekommt man mit kitchen list

Zu diesem Zeitpunkt hat man zumindest die Gewissheit, dass das besagte Cookbook generell lauffähig ist und keine Fehler wirft. Ob aber tatsächlich der gewünschte Zustand erreicht ist, ist noch unklar. In Kombination mit TestKitchen lässt sich ein Zustand am besten mit ServerSpec ermitteln.

ServerSpec
Mit ServerSpec werden RSpec Tests geschrieben die den tatsächlichen Zustand eines hosts prüfen. Es wird nicht nur in Kombination mit Chef verwendet, sondern auch mit den meisten anderen Configuration Management Tools.

TestKitchen erwartet die ServerSpec Tests im Verzeichnis test/integration. Jede Suite erhält ihr eigenes Verzeichnis in dem die entsprechenden Dateien liegen in denen beschrieben ist was geprüft werden soll:

test
`-- integration
|-- icinga2server
| `-- serverspec
| |-- icinga2server_spec.rb

Beispielhaft könnte eine icinga2server_spec.rb folgenden Inhalt haben:

require 'serverspec'
require 'pathname'

set :backend, :exec
set :path, '/bin:/usr/local/bin:$PATH'

describe package(“icinga2”) do
  it { should be_installed }
end

describe service('icinga2') do
  it { should be_running }
end

Dabei wird geprüft ob auf dem System das Paket icinga2 tatsächlich installiert ist und ob der Service icinga2 läuft. Ausgedrückt werden Tests in einer relativ einfach verständlichen “Sprache”, da Begriffe und Aufbau stark an die menschliche Sprache angelehnt sind.

Aus den vorherigen Schritten sollte mindestens schon eine VM bereit stehen auf der die ServerSpec tests jetzt angewendet werden können:

kitchen verify icinga2server-ubuntu-1604

Im besten Fall ist die Ausgabe positiv

bsheqa@blerims-mbp ~/git/github/chef-icinga2 (feature/testkitchen-12286) $ kitchen verify client-ubuntu-1404
-----> Starting Kitchen (v1.10.2)
-----> Verifying ...
Preparing files for transfer
[…]

Package "icinga2"
should be installed

Service "icinga2"
should be running

Finished in 0.14585 seconds (files took 0.36682 seconds to load)
2 examples, 0 failures

Finished verifying (0m2.89s)

Mit diesem gesamten Workflow nimmt TestKitchen einem sehr viel Arbeit ab, die man sonst verwenden müsste, um virtuelle Maschinen zu pflegen und nachzusehen, ob alles so angewendet wurde, wie es im Cookbook beschrieben ist. Integration Tests selbst helfen dabei ein Gefühl dafür zu bekommen, wie sich das Cookbook als Ganzes unter verschiedenen Umgebungen mit unterschiedlichen Attributen verhält. Mit entsprechenden ServerSpec Tests gewinnt man endgültig die Sicherheit, das alles wirklich so funktioniert, wie es soll.

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.