Select Page

NETWAYS Blog

Warum wir in den NETWAYS-PostgreSQL-Trainings eigentlich nur “psql” nutzen

Wieder einmal PostgreSQL-Trainings (Fundamentals und Advanced) durchgeführt.
Wieder einmal wurde nach GUIs gefragt.
Wieder einmal haben wir uns dann letztlich doch fast auf psql beschränkt.

Warum ist das so?

 

GUI vs. TUI – the eternal battle

GUIs werden i. A. als “benutzerfreundlicher” dargestellt.

Ich persönlich wiederum finde es ganz schrecklich, dauernd zur Maus greifen zu müssen, um irgendeine Aktion auszulösen, für die die Entwickler keinen oder einen grauenhaften Shortcut konfiguriert haben… für mich sind GUIs also eher weniger benutzerfreundlich.

Mir ist auch klar, dass es beileibe nicht jedem Menschen so geht, und die Gewöhnung spielt dabei sicher auch eine enorme Rolle.

“The usual suspects”: die üblicherweise genannten Gründe pro GUI/TUI

GUI:

  • intuitiver zu bedienen
  • “gewohnte” Optik
  • bessere Übersicht über Ergebnisse von Queries

TUI:

  • steht vom Funktionsumfang dem GUI kaum nach
  • funktioniert auch bei langsamer Verbindung (“Zug”)
  • kann gescriptet werden

Es gibt aber einige durchaus schwerwiegende Gründe, warum ich bei Trainings so einen großen Wert auf psql lege.

“The killer arguments”: warum psql elementar ist

Die Lernschwelle ist bei GUIs unnötig hoch

  • Jedes GUI sieht letztlich (ein wenig) anders aus und es gibt einfach zu viele
  • Um eine erste Verbindung herzustellen, muss im GUI erst ein Server definiert werden, mit jeder Menge Parametern, u.a. einer Netzwerkverbindung
    • dafür muss aber erst ein Konfigurationsparameter (listen_addresses=) gesetzt werden, was wiederum erst deutlich nach dem ersten “Reinschnuppern” behandelt wird…
    • Im Terminal hingegen (wo ich ja gerade den DB-Server installiert habe) komme ich per psql direkt an die DB (wenn ich der OS-User postgres bin…)
  • Objekte anschauen (“Erste Schritte”):
    • TUI: nach Eingabe von psql kann ich einfach z.B. \dt eingeben und bekomme alle Tabellen gelistet, \d nachnamen zeigt mir instant die Tabellenstruktur, dazu Indexe, Primär-/Fremdschlüssel etc. an
    • in allen GUIs muss ich dafür erst durch einen Baum klicken, in pgAdmin4 z.B. Servergruppe -> Server -> Datenbank -> Schemas -> ‘public’ -> Tabellen

Die (online-)Trainings-VMs sind nur per ssh und Webinterface erreichbar

  • um da per GUI dranzukommen, müssten also die Teilnehmer erstmal Software auf ihren (privaten oder dienstlichen) PCs installieren…

Viel entscheidender ist aber m.E.:

psql ist für den PostgreSQL-DBA, was vi für den U\*\*X-Admin ist:

  • auf jeder PostgreSQL-Maschine verfügbar
  • minimalistisch, aber gleichzeitig unglaublich leistungsfähig
  • ich muss das sowieso zu nennenswerten Teilen beherrschen, z.B.
    • für den Fall, dass mir die Firewall einen Streich spielt
    • wenn ich mal als Superuser in die DB will/muss (max_connections= ausgeschöpft)
    • um Dinge zu scripten

Wenn mir jemand erzählt, er oder sie sei UNIX-Admin, dann aber einen nano benutzt, bin ich sofort (zurückhaltend ausgedrückt) skeptisch.

Ähnlich ist es mit psql. Ich muss (als DBA) sowieso wissen, wie ich damit z.B. Objekte anzeigen, DDL einspielen, ggfs. mal eine Stored procedure umschreiben etc. pp. kann. Wenn ich die Software also sowieso (halbwegs) beherrschen muss, kann ich sie doch auch gleich benutzen? Ich sehe nur wenige Szenarien, in denen ein(e) DBA von einem GUI profitieren würde.

Ein(e) AnalystIn hingegen wird die DB wahrscheinlich eher direkt an ein Reporting-Tool oder M$ Excel anbinden wollen.

Bleibt der/die (SQL-) EntwicklerIn. Ja, fair enough, da sehe auch ich gewissen Charme (üblicherweise F5 drücken, um das SQL im Fenster (erneut) laufen zu lassen). Auf der anderen Seite ist derselbe Effekt in psql durch Eingabe von \e zu erreichen, und da kommt ein vi. Der ist ja bekanntlich minimalistisch, aber… 😉

Und ob man DDL jetzt per GUI erzeugen sollte, darüber scheiden sich ja auch die Geister… IMHO eher nicht.

Fazit:

“I never leave the house without it!”

psql ist der vi(m) der PostgreSQL-Welt. Unfassbar flexibel und leistungsfähig, immer verfügbar und dadurch absolutes “Pflichtprogramm”.

P.S.

Ich habe mal jemanden kennengelernt, der eine U\*\*X-Consulting-Firma betrieb und lt. eigener Aussage nur Menschen anstellte, die den ed beherrschen. So weit würde ich dann auch nicht gehen… 😉

P.P.S.

Vielleicht hat die Abneigung gegen TUIs was mit Oracles SQL*Plus (TM) zu tun? Wäre absolut nachvollziehbar, das fasse ich auch nur mit der Kneifzange an…

 

Über den Author:

Gunnar “Nick” Bluth hat seine Liebe zu relationalen Datenbanken Ende des letzten Jahrtausends entdeckt. Über MS Access und MySQL 3.x landete er sehr schnell bei PostgreSQL und hat nie zurückgeschaut, zumindest nie ohne Schmerzen. Er verdient seine Brötchen seit beinahe 20 Jahren mit FOSS (Administration, Schulungen, Linux, PostgreSQL). Gelegentlich taucht er auch tiefer in die Programmierung ein, so als SQL-Programmierer bei der Commerzbank oder in App-Nebenprojekten.
Philipp Dorschner
Philipp Dorschner
Developer

Philipp hat im Jahr 2017 die Ausbildung zum Fachinformatiker – Systemintegration bei NETWAYS Professional Services begonnen. Während der Ausbildung bekam er ein immer größeres Interesse am Programmieren. Das führte dazu, dass Philipp nach erfolgreich bestandener Ausbildung die Kollegen aus Professional Services nicht nur als Consultant sondern auch als Entwickler tatkräftig unterstützt. Neben seinem Interesse an der Informationstechnologie, macht er Sport im Freien oder liest bei schlechtem Wetter auch gerne mal ein Buch zu Hause.

Entwicklerazubis: Jahr 1, das Projekt

Man bekommt nicht immer das, was man will… außer, man ist bei NETWAYS Azubi!

 

Mein erstes Jahr bei NETWAYS ist fast vorüber, und meine jugendlichen Ambitionen haben den Wunsch in mir erweckt, mit den beiden anderen Dev-Azubis meines Jahres, Loei und Niko, ein eigenes Projekt zu übernehmen, um unsere erlernten Fertigkeiten zu prüfen, eine Übersicht davon zu bekommen, auf welchem Stand wir alle sind, den ein oder anderen Trick voneinander aufzuschnappen und eigenverantwortlich und kooperativ ein Projekt zu vervollständigen. Und alles, was es gebraucht hat, um diesen Wunsch zu erfüllen, war diese Idee zu pitchen und klar und deutlich zu vermitteln, warum dieses Interesse besteht, und was wir uns davon erhoffen. Meine Vorgesetzten scheinen von der Idee zumindest angetan genug gewesen zu sein, dass wir drei Wochen eingeräumt bekommen haben, um uns um dieses Projekt zu kümmern. Danke, NETWAYS!

Die Aufgabe klingt einfach, hat es aber doch durchaus in sich – aus Berichten in Icinga sollen PDFs generiert werden. Die Funktionalität ist schon vorhanden – unsere Aufgabe ist es, den Benutzern mehr Features zur Verfügung zu stellen, damit man eigene Anpassungen an dem Aussehen der PDFs vornehmen kann. Das Schöne an dieser Aufgabe ist die Breite der Elemente und Bereiche, welche eine Rolle dabei spielen. Icingaweb, PHP, HTML, CSS, Google Chrome… es ist in gewisser Art und Weise eine große Reise in das Unbekannte, und natürlich können wir alle drei uns nicht sicher sein, welche Probleme und Hürden sich uns in den Weg stellen werden, und wie die zündenen Ideen kommen, die uns helfen, diese Hürden zu überwinden.

 

Boo

Much better

Und zündende Ideen gab’ es bereits! Ein Beispiel: Google Chrome baut sich aus HTML-Code die PDFs zusammen, lässt sich es aber nicht nehmen, automatisch generierte Header und Footer anzufügen, mit Seitenzahl und Datum. Das ist natürlich ein Element, welches wir gerne unter Kontrolle hätten! Der erste Hack, mit dem ich mich über diese Hürde bewegt habe, ist ein CSS-Styleelement an den übergeben HTML-Code anzufügen. Das ist in seinem momentanen Zustand natürlich noch etwas unschön gelöst, wenn einfach nur der HTML-Code um ein fest eingebautes Codeelement erweitert wird, aber wir haben einen Einstiegspunkt, einen Ansatz, mit der wir weiterbauen und -basteln können.

 

Scheue Dich vor Fragen nicht!

Auch wenn der Kerngedanke dieses Projekts natürlich daraus besteht, dass wir uns selbst beweisen, spricht natürlich Nichts dagegen, bei Fragen, die aufkommen, einen der zahlreichen Experten die NETWAYS hat zu involvieren. Was Benutzeroberflächen angeht, ist bei uns UX-Designer Florian der Ansprechpartner Nummer 1. Wir haben uns zusammengesetzt und konnten ihm live beim Bauen eines Mockups in Sketch zusehen. Eine Gelegenheit, durch die großen Augen, die wir gemacht haben, auch etwas über grundlegende Designansätze in Icingaweb zu lernen, und Grundsätze bezüglich Design. Mit diesem Wissen können wir erstmal diesen Pfad weiter selbst beschreiten, aber natürlich werden wir viel Rücksprache führen. Nur weil man bisher nicht dazu kam, sich extensive Kenntnisse in einem Bereich selbst anzueignen, heißt das nicht, dass man dieses Wissen, wenn es einem zur Verfügung steht, nicht nutzen kann. Und immer schön dran denken, selbst den Fundus an Talenten zu erweitern.

A mockup of things to come…

 

Kooperatives Kodieren

Einer der in meiner Einleitung angesprochenen Tricks, den ich einfach für neat halte, und sehr dem Spirit dieses Projektes entspricht, ist die Möglichkeit in git Co-Authoren einzutragen. Dafür muss man in der commit message einfach

 Co-authored-by: Name <e-mail>

angeben, und git verlinkt automatisch zwei Autoren für diesen commit. In diesem Fall meine beiden Kollegen bei diesem Projekt. Gute Arbeit, Jungs!

Da kann man ruhig mal klatschen! ?

 

Willst Du uns vielleicht nächstes Jahr bei dem nächsten Entwicklungsprojekt behilflich sein? Dann raus mit Deiner Bewerbung an NETWAYS! Wir freuen uns schon auf dich!

Henrik Triem
Henrik Triem
Junior Developer

Henrik is Anwendungsentwickler in Ausbildung, verhindeter Rockstar, kaffeegetrieben und Open Source-begeistert. Zuhause lässt er es auch mal ruhiger mit Tee angehen, entspannt an Klavier oder Gitarre, erkundet neue Musik oder treibt sich mit seinen Freunden in Deutschland herum.

HAProxy und SQL Grants

In diesem kurzen Beitrag will ich auf einen Fallstrick im Bezug von HAProxy und SQL Backends wie MySQL oder MariaDB eingehen. Speziell geht es um Grants und die damit verbunden Quell Hosts. Diese werden bei einem Standard Setup mit HAProxy durch die IP des Proxys ersetzt. Solange man sich in dem selben Netz wie die DB Server und dem Proxy befindet und die Host-Beschränkungen nicht all zu streng sind, kann es gut sein, das man dieses Szenario nicht erreicht. Sobald die Verbindungen aber Netz übergreifend erfolgen und die Grants damit umso wichtiger sind, kommt das Detail zum Tragen und stellt einen vor neue Herausforderungen. Dafür gibt es an sich schon etwas länger das Proxy Protokoll, welches aber erst nach und nach in mögliche Backend Software implementiert wurde/wird. Bei MariaDB war es mit der 10.3.1 z.B. erst Ende letzten Jahres soweit.
Die Arbeitsweise des Protokolls beschreibt sich einfach gesagt so, dass mit dem Aufbau der Verbindung zuerst ein zus. Header geschickt wird, in dem die IP des Quell Hosts bekannt gegeben wird. Dazu muss das Backend jedoch von der IP des HAProxys das Proxy Protokoll erlauben. Das Ganze drum rum kann mit Seiten über weitere Details und Sicherheit befüllt werden. Damit verschone ich Euch aber und weise nur auf eine schlichte Zusammenfassung im Blog von HAProxy hin.

Gnocchi und Archiv Policies

Gnocchi ist eine time series database die aus dem OpenStack Projekt hervorgegangen ist. Da Gnocchi erst 2014 entstanden ist, wurde versucht die Schwächen vorhandener Lösungen zu umgehen. Im Vergleich fallen mir vor allem folgenden Features auf:

  • Mandantenfähigkeit
  • Skalierbarkeit
  • Hochverfügbarkeit
  • REST Interface (HTTP)
  • Unterstützung moderner Backends wie Ceph (librbd), Swift und S3
  • OpenSource

Ein weiters Feature ist die Unterstützung von archive policies. Diese legen fest wie lange und in welcher Granularität Metriken vorgehalten werden. Zusätzlich kann auch die Art der Aggregation definiert werden. Sendet man den unten stehenden json Text per HTTP an /v1/archive_policy wird z.B. eine Policy angelegt die Metriken mit einer Granularität von 5 Minuten für 62 Tage speichert und dafür 17856 Punkte benötigt (12 Metriken je Stunde * 24 Stunden * 62 Tage = 17856). Zusätzlich werden die Metriken in aggregierter From  für 365 und 3650 Tage gespeichert.
 

{
  "name": "router-metriken",
  "back_window" : 0,
  "definition" : [
    {
      "points" : 17856,
      "granularity" : "00:05:00",
      "timespan" : "62 days, 0:00:00"
    },
    {
      "points" : 8760,
      "granularity" : "1:00:00",
      "timespan" : "365 days, 0:00:00"
    },
    {
      "points" : 3650,
      "granularity" : "24:00:00",
      "timespan" : "3650 days, 0:00:00"
    }
  ],
  "aggregation_methods" : [
    "min",
    "max",
    "mean",
    "sum"
  ]
}

 
Welche archive policy für einzelne Metriken angewendet wird kann über rules bestimmt werden. Neue Metriken werden per Regex geprüft und ggf. einer Policy zugewiesen. Treffen mehrer Regeln greift der längste Regex. Mit der folgenden Regel werden alle Metriken die mit router beginnen zu der oben definierten Policy hinzugefügt.
 

{
  "archive_policy_name": "router-metriken",
  "metric_pattern": "router.*",
  "name": "router-metriken"
}

 
Mein erster Eindruck von Gnocchi ist durchaus positiv und mit den genannten Features kann sich die OpenStack Lösung von der Konkurrenz abheben. Aktuell ist Gnocchi wohl am besten für die Bedürfnisse von OpenStack ausgelegt. Es gibt aber auch Integrationen zu collectd, statsd, Icinga und Grafana.

Achim Ledermüller
Achim Ledermüller
Lead Senior Systems Engineer

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.

Filter for Multiple Group Memberships in SQL

In the upcoming Icinga Web 2 release the filter functionality becomes even more powerful.
Version 2.6.0 introduces the possibility to exclude hosts and services that are member of specific groups.
You now filter for hosts that are not part of the production host group for example.
You want to filter for hosts that are member of the host groups linux and database? That will be possible as well.
I’d like to show you how the latter is done with an example. We have a database with user groups, users and their group
memberships:

CREATE TABLE user_group (
  id int(10) unsigned NOT NULL AUTO_INCREMENT,
  `name` varchar(64) NOT NULL COLLATE utf8mb4_unicode_ci,
  PRIMARY KEY (id),
  UNIQUE KEY group_name (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE utf8mb4_bin;
CREATE TABLE user_group_membership (
  user_id int(10) unsigned NOT NULL,
  group_id int(10) unsigned NOT NULL,
  PRIMARY KEY (user_id,group_id),
  CONSTRAINT user_group_membership_user FOREIGN KEY (user_id) REFERENCES `user` (id),
  CONSTRAINT user_group_membership_group FOREIGN KEY (group_id) REFERENCES user_group (id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE utf8mb4_bin;
INSERT INTO user VALUES (1,'john'),(2,'marc'),(3,'peter');
INSERT INTO user_group VALUES (1,'admins'),(3,'dev'),(2,'support');
INSERT INTO user_group_membership VALUES (1,1),(2,2),(2,3),(3,2);

User john is part of the group admins. Marc is member of the groups dev and support while Peter is part of the dev
group only. We now have the task to filter for users that are at least part of the groups dev and support. In this example
it’s easy of course because we only have three users and know the result without executing any queries.
But anyway how would you achieve this with SQL? Easy, let’s just JOIN the tables and add a WHERE IN condition:

SELECT * FROM `user` u INNER JOIN user_group_membership m ON m.user_id = u.id
INNER JOIN user_group g ON g.id = m.group_id WHERE g.name IN ('dev', 'support');
+----+-------+---------+----------+----+---------+
| id | name  | user_id | group_id | id | name    |
+----+-------+---------+----------+----+---------+
|  2 | marc  |       2 |        3 |  3 | dev     |
|  2 | marc  |       2 |        2 |  2 | support |
|  3 | peter |       3 |        2 |  2 | support |
+----+-------+---------+----------+----+---------+

The result is not surprising. Because of the WHERE IN condition we also get peter who is only part of the dev group.
So, we have to filter for users that produce two or more rows. For this aggregation, HAVING helps:

SELECT * FROM `user` u INNER JOIN user_group_membership m ON m.user_id = u.id
INNER JOIN user_group g ON g.id = m.group_id WHERE g.name IN ('dev', 'support')
HAVING(COUNT(group_id) >= 2);
+----+-------+---------+----------+----+------+
| id | name  | user_id | group_id | id | name |
+----+-------+---------+----------+----+------+
|  2 | marc  |       2 |        3 |  3 | dev  |
+----+-------+---------+----------+----+------+

Looks good! It’s best to move this to a subquery in order to be flexible if the query becomes more complex later on:

SELECT * FROM `user` u WHERE EXISTS (
  SELECT 1 FROM user_group_membership m
  INNER JOIN user_group g ON m.group_id = g.id
  WHERE m.user_id = u.id AND g.name IN ('dev', 'support')
  HAVING COUNT(*) >= 2
);
+----+-------+
| id | name  |
+----+-------+
|  2 | marc |
+----+-------+

Bonus question: how to filter for users that are member of dev and support but no other groups?

Eric Lippmann
Eric Lippmann
Head of Development

Eric kam während seines ersten Lehrjahres zu NETWAYS und hat seine Ausbildung bereits 2011 sehr erfolgreich abgeschlossen. Seit Beginn arbeitet er in der Softwareentwicklung und dort an den unterschiedlichen NETWAYS Open Source Lösungen, insbesondere inGraph und im Icinga Team an Icinga Web. Darüber hinaus zeichnet er für viele Kundenentwicklungen in der Finanz- und Automobilbranche verantwortlich.

Veranstaltungen

Tue 27

GitLab Training | Online

October 27 @ 09:00 - October 28 @ 17:00
Tue 27

Graylog Training | Online

October 27 @ 09:00 - October 28 @ 17:00
NETWAYS Headquarter | Nürnberg
Nov 04

Vorstellung der Monitoring Lösung Icinga 2

November 4 @ 10:30 - 11:30
NETWAYS Headquarter | Nürnberg
Nov 24

Elastic Stack Training | Online

November 24 @ 09:00 - November 26 @ 17:00
Dec 01

Foreman Training | Nürnberg

December 1 @ 09:00 - December 2 @ 17:00
NETWAYS Headquarter | Nürnberg