Webinare im Mai

NETWAYS Webinare Nachdem der Webinar-Marathon im April fast zuende geht und das Vagrant Webinar kurz bevor steht, möchte ich natürlich gleich auf die nächsten Webinare im Mai hinweisen. Einerseits geht es dann um unsere Cloud-Lösungen welche wir über unsere Rechenzentren anbieten und einmal um das Thema Windows Vorbereitung für Puppet. Bei dem Windows Webinar liegt der schwerpunkt darauf, wie ein Windows-System soweit vorbereitet werden kann, dass sowohl eine automatische Installation über Images aber auch die anschließende Konfiguration mit Puppet möglich ist. Christoph hatte hierzu bereits einen interessanten Blog-Artikel veröffentlicht.

Zusammengefasst noch einmal die Themen, die Termine und Anmeldelinks im Überblick:

Titel Zeitraum Registrierung
Vagrant: Virtualisierungs Wrapper 30. April 2015 – 10:30 Uhr Anmelden
NETWAYS Cloud Lösungen 08. Mai 2015 – 10:30 Uhr Anmelden
Windows: Vorbereitung für Puppet 22. Mai 2015 – 10:30 Uhr Anmelden

Vorab natürlich eine schöne Restwoche!

Christian Stein

Autor: Christian Stein

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Account Manager und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".

Elasticsearch Tribe Node

Elasticsearch hat sich einen Namen damit gemacht, in ungeahnte Grössen zu skalieren, aber manchmal ist ein Cluster einfach nicht genug. Für diese Fälle wurde der Elasticsearch Tribe Node eingeführt, eine spezielle Elasticsearch Instanz, die selber keine Daten hält, sondern mehrere Cluster miteinander verbindet und so den Zugriff auf die Daten der einzelnen Cluster erlaubt, als wären alle Daten in einem einzigen grossen Cluster vorhanden.

Allerdings wird der Tribe Node nicht verwendet, um Grössenbeschränkungen von Elasticsearch Clustern zu umgehen, da die Anzahl von Knoten innerhalb eines Clusters nur durch die zur Verfügung stehenden Ressourcen beschränkt ist. Dabei ist der Bedarf eines einzelnen Knoten so wenig, dass hunderte bis tausende Knoten innerhalb eines Clusters möglich sind.

Übliche Anwendungen des Tribe Node sind:

  • Organisatorische Einschränkungen: Verschiedene Teams sollen Zugriff auf ihren jeweils eigenen Cluster aber nicht auf die Cluster anderer Teams haben. Dennoch soll eine übergeordnete Instanz Zugriff auf alle Daten über eine gemeinsame Schnittstelle haben.
  • Rechtliche Einschränkungen: Wenn Daten in einer bestimmten geographischen Position (z.B. ein bestimmtes Land) gespeichert werden müssen, die Daten jedoch zentral abgefragt werden sollen. (Achtung, ich bin kein Jurist. Ob dieses Konstrukt wirklich solche Einschränkungen erfüllt, ist in den einzelnen Fällen extra zu ermitteln!)
  • Einschränken von Traffic: Besonders bei der Verwendung von Elasticsearch als Teil des ELK Stacks (also mit Logstash) werden oft sehr grosse Datenmengen in die Cluster geschrieben. Wird ein einzelner Cluster verwendet, um alle Daten aus Remote Offices oder verschiedenen Firewallzonen zu sammeln müssen entweder Daten vorgefiltert werden, wodurch auf Events verzichtet werden muss oder die grossen Datenmengen über Firewalls oder WAN Leitungen geschickt werden. Mit dem Tribe Node können die Daten lokal in eigenen Clustern gesammelt und zentral abgefragt werden, wobei nur die Anfrage und die aufbereitete Antwort übertragen werden müssen.

Die Konfiguration des Tribe Node ist denkbar einfach. Man gibt die Namen des Clusters in den folgenden Optionen in der /etc/elasticsearch/elasticsearch.yml an und startet den Dienst. Dabei sollte der Tribe node selbst jedoch keine Daten enthalten.

tribe:
  es1:
    cluster.name: cluster1
    discovery:
      zen:
        ping:
          multicast:
            enabled: false
          unicast:
            hosts:
              - 192.168.23.228:9300
  es2:
    cluster.name: cluster2
    discovery:
      zen:
        ping:
          multicast:
            enabled: false
          unicast:
            hosts:
              - 192.168.69.229:9300

Da sich die Cluster oft in verschiedenen Subnetzen befinden, wurde hier auch gleich multicast discovery deaktiviert und die Verbindungen zu Knoten aus den einzelnen Clustern per unicast htribe-nodeergestellt.

Wichtig ist, dass man am Tribe Node zwar lesen und schreiben, jedoch keine Indices anlegen kann. Will man also Kibana auf so einem Tribe Node nutzen, muss man den von Kibana zu nutzenden Index für eigene Daten (Dashboards, etc.) in einem der im Tribe Node zusammengefassten Cluster selbst anlegen bzw. Kibana erst mit einem der Cluster verbinden und den Index anlegen lassen, bevor man es auf den Tribe Node umleitet.

 

Mehr Info zum Tribe Node gibt’s in der Elasticsearch Dokumentation.

Thomas Widhalm

Autor: Thomas Widhalm

Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 möchte er aber lieber die große weite Welt sehen und hat sich deshalb dem Netways Consulting Team angeschlossen. Er möchte ausserdem möglichst weit verbreiten, wie und wie einfach man persönliche Kommunikation sicher verschlüsseln kann, damit nicht dauernd über fehlenden Datenschutz gejammert, sondern endlich was dagegen unternommen wird. Mittlerweile wird er zum logstash - Guy bei Netways und hält Schulungen und erstellt Schulungsunterlagen zu diesem faszinierenden Tool.

OSDC 2015 – Enterprise integration with open source, day 2

Attending conferences of a certain size always brings the pain of deciding what talks to listen to. I really wished I could listen to all of them live but at least there are the OSDC archives, so I will be able to watch what I’ve missed when the videos will be edited and uploaded. Following are my personal impressions of the talks I chose from the tracks.

Despite being at least a bit tired from attending the OSDC evening event at the Paulaner Bavarian restaurant in Berlin yesterday talks were interesting enough that from the first talk on day 2 of the Open Source Datacenter Conference on the two rooms where talks were given were full of attendees again.

As first talk of day 2 Timo Derstappen used the Pixar movie plot schema “Once upon a time…” to give an introduction into microservices and how orchestrate them using the “ambassador pattern”. He showed with his demo that systemd and fleet on CoreOS can be a real alternative when running multiple containers depending on each other.

After the first coffee break of the day Ingo Friepoertner gave a short overview over the history of databases and why NoSQL databases will not replace relational databases but are the better alternative for many applications. Using the concept of “Polyglot Persistence” you will want to use the right store for the right job, so split data into different databases: Financial data in an RDBMS, user sessions in a KeyValue store and recommendations into a graph database and so on. To avoid getting stuck in a swamp of many different databases from many different vendors you can use multi-model databases to consolidate several of the beforementioned technologies into one product.

In the next talk Matthias Klein showed us how to keep development close to production by creating your own package repositories and copy only selected packages into them. Then use vagrant or Xen and puppet to create test hosts that resemble the production hosts as close as possible to roll out new packages, run tests from Jenkins and, if all went well, deploy the same packages on production systems. One of the most important factors will be to convince everyone that only packages in your repositories are allowed and that every configuration change has to be implemented in puppet so it can be reviewed more easily and tested on test hosts before the same configuration (with just some parameters replaced) goes on production hosts.

After the great lunch John Spray showed us what CephFS is, how it developed lately and what the current state is. Being not so familiar with Ceph like I wished I was, I was glad hearing that CephFS, a distributed filesystem on the Ceph backend, is available now (even if it’s not supported for enterprise use) and CephFS volumes can be mounted simultanousely on different hosts just like a network share. A great “new” feature (which is available for about a year now, which is almost no age for enterprise grade software) is the combination of Cache Tiering and Erasure Coding which basically means having a fast but small pool of disks (preferably SSDs) that handles all of your I/O and a second pool of big, slow disks where data is not replicated like in standard Ceph pools but split like on RAID 5 / 6 / Z systems where automatically “cold” data, which is rarely used, is moved to.

Next was a talk I anticipated a lot, personally. Pere Urbon talked about one of my most favourite toolsets, the ELK stack. He gave a quick explanation about what Elasticsearch, Logstash and Kibana are and what they are used for. Then he dug a bit into some real life examples about scaling the stack, especially by using a broker like Redis or RabbitMQ. In fact, RabbitMQ might be a real alternative to Redis and I will definitely see into the different possibilities, the various brokers have to offer. Not only Redis and RabbitMQ but Apache Kafka and some others. During the talk we learned a bit about the new features of the to-be-released-today Logstash 1.5 and the coming-someday Logstash 2.0. After the talk there was only one question unanswered: How is the Green Lantern Corps logo out of the slides related to the Marvel comic multiverse, Elastic normally gets most of its names out? 😉

The last talk of the day I attended was Bernds talk about why to use Icinga instead of Nagios. Whoever reads this blog should already know that Icinga (2) is way cooler than Nagios so I will not go into detail about his talk. But you should definitely look at the video in the archive when it’s online even if you’re already convinced because Bernd’s talks are always worth the while.

Thomas Widhalm

Autor: Thomas Widhalm

Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 möchte er aber lieber die große weite Welt sehen und hat sich deshalb dem Netways Consulting Team angeschlossen. Er möchte ausserdem möglichst weit verbreiten, wie und wie einfach man persönliche Kommunikation sicher verschlüsseln kann, damit nicht dauernd über fehlenden Datenschutz gejammert, sondern endlich was dagegen unternommen wird. Mittlerweile wird er zum logstash - Guy bei Netways und hält Schulungen und erstellt Schulungsunterlagen zu diesem faszinierenden Tool.

OSDC 2015: Thank you and see you again!

This year’s Open Source Data Center Conference has been a big success! With about
170 attendees from 12 countries we had one of the biggest and most international conferences so far.
We like to thank our sponsoring partners for their support!

Thomas Krenn and Linux Magazin are backing us and our conferences from the very beginning on and were of course part of this year’s OSDC   again.

Linux und TK-Kombi

 

 

We hope you all took the chance to visit Thomas Krenn at their booth and read a lot of issues of LINUX Magazin.

We are also very proud to welcome Attingo Data Rescue and ADMIN Magazine as two new partners and are looking forward to work with them again at future events.
Attingo und ADMIN Kombi
Maybe you already visited Attingo at their booth at the conference or read one of the ADMIN Magazines we distributed.

And of course we like to thank our speakers and attendees! It has been a pleasure to welcome you at the event! We hope to see you again at OSDC 2016!

Eva Häusler

Autor: Eva Häusler

Eva ist bei NETWAYS für das Marketing zuständig. Gerüchten zufolge wurde sie vor etwa einem Jahrzehnt in einer Kiste Braunschweiger Honigkuchen von Niedersachsen nach Franken geschmuggelt und wird seitdem hier in Geiselhaft gehalten. Nach einem Germanistikstudium mit begleitenden Ausflügen in die Nürnberger Literaturszene, hat sie bei NETWAYS in der Eventabteilung angefangen. Inzwischen kommt ihre geballte Wortgewalt im Marketing nutzbringend zum Einsatz.

Gulp und Bower: Automate Webdevelopment

NETWAYS DevelopmentDas Entwickeln von HTML Templates ist normalerweise ein sehr statisches unterfangen. Man braucht nicht viel mehr als einen Texteditor und einen Browser um ein Design zu entwerfen. Integriert man allerdings Gedanken zur Produktion bereits in der Designphase, steigt der Aufwand wesentlich. Denn folgende Dinge gilt es zu bedenken:

  • Kompilieren von Stylesheets wenn in LESS oder SASS geschrieben
  • Aufteilen von Inline-Styles und nachladbare Styles
  • Verwenden von JavaScript Frameworks
  • Optimiertes laden von JavaScript Code
  • Komprimieren von Bildern
  • Komprimieren von Styles oder Scripts

Die Liste ist lässt sich entsprechend fortführen. Um beim Release nichts zu vergessen, etablierten sich in den letzten Jahren einige Tools um einen Buildprozess für clientseitige Webanwendungen bereitzustellen und zu vereinfachen. Zwei davon möchte ich gerne vorstellen:

Bower

Bower

Bower ist ein Open Source Paketverwaltungstool für Webapplikationen. Dadurch können für eine Website oder eine SPA (Single Page Application) softwaretechnische Abhängigkeiten definiert werden. Vorraussetzung zur Installation ist Node.js. Dann bietet Bower allerdings die Möglichkeit, Frameworks auch einfache Art und Weise in der benötigten Version zu installieren. Bekannte Vertreter dieser Art sind z.B. jQuery, AngualarJS oder HTML5 Boilerplate.

Ein einfaches bower.json sieht folgendermaßen aus:

{
  "name": "Website",
  "version": "0.0.9",
  "authors": [
    "Eduart Zimmermann <ez@website.foo.bar>"
  ],
  "description": "Our website",
  "keywords": [
    "website"
  ],
  "license": "GPLv2+",
  "homepage": "https://website.foo.bar",
  "ignore": [
    "**/.*",
    "node_modules",
    "bower_components",
    "test",
    "tests"
  ],
  "directory": "./src/scripts/vendor",
  "dependencies": {
    "jquery": "latest",
    "uikit": "latest",
    "modernizr": "2.8.x"
  },
  "devDependencies": {
    "html5-boilerplate": "latest"
  }
}

Sind die Abhängigkeiten definiert, werden sie mit diesem Aufruf in der Applikation installiert:

# bower install

Gulp

GulpGulp Logo ist nun das eigentlich Build Tool und wird ebenfalls mit Node.js (npm) installiert. Gulp selbst führt dabei nur weitere Tasks aus.

 

Diese Tasks übernehmen dann spezielle Aufgaben, z.B.:

  • Kompilieren, komprimieren, unleserlich machen von Javascript oder Stylesheet
  • Ausführen von Tasks, wenn sich Dateien geändert haben
  • Erstellen von Scripts und Styles aus verschiedenen Dateien
  • Ausführen von Tests

Die Tasks werden in einem gulpfile.js definiert und können ganze Gruppen ausführen (z.B. wie GNU Make) um Tarballs zu erstellen oder die Applikation allgemein für den Produktivbetrieb vorzubereiten. Das alleine haut uns nun nicht wirklich aus den Socken, aber: In Kombination mit Node.js und Verwendung aller hier genannten Techniken bauen wir uns mit 1-2 Anweisungen die komplette Entwicklungsumgebung auf:

  • Node Package Abhängigkeiten installieren
  • Bower Abhängigkeiten installieren
  • Webserver starten
  • Styles und JavaScript nur kompilieren nur wenn sich Dateien verändert haben
  • Per LifeReload im Browser die Seite neu laden wenn Code geändert worden ist

Damit kommt die Kiste dann richtig in Fahrt und Webentwicklung wird wieder zu einer spannenden und dynamischen Geschichte.

Weitere Informationen:

Marius Hein

Autor: Marius Hein

Marius Hein ist schon seit 2003 bei NETWAYS. Er hat hier seine Ausbildung zum Fachinformatiker absolviert, dann als Application Developer gearbeitet und ist nun Leiter der Softwareentwicklung. Ausserdem ist er Mitglied im Icinga Team und verantwortet dort das Icinga Web.