Seite wählen

NETWAYS Blog

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
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.

Profiling your application with Valgrind Callgrind: Icinga2

We are using a variety of tools to ensure that our applications do not leak memory, suffer from performance issues or actually trigger unwanted behavior. This tool stack changes over time, and it is also different for web, script and binary applications. Next to the Icinga bits I am responsible for the LConf Backend and other Perl foo here at NETWAYS – I’ve already written about profiling Perl. During Icinga 1.x and 2.x development we’ve come around a couple of tools for profiling memory consumption with Massif or using the Google perftools.
One of our specialties at NETWAYS Development is further that we’re capable of identifying and resolving issues directly – be it performance, memory, locking, race conditions, etc. aside from the code we’re developing and running at customers.

The perfect code vs performance

While the perfect code does not exist, it’s always interesting and also required to refactor your own code parts based on current conditions and requirements. The code in 2.2.4 had one function interface being called, namely AddObject(). This function is merely doing the following for ‚repository add‘ and ’node update-config‘:

  • Get all the object names from `repository.d` and checking if the added object already exists
  • Create a new object by attributes and run it against the Icinga 2’s config validation
  • Check if the change already exists by reading the `changes` directory
  • Add the change to the changelog (for calling ‚commit‘ later on)

This is perfectly fine for keeping the same functionality shared among several occasions where this code is used. But we’ve run into severe performance issues with like 20000 calls to AddObject() inside one ’node update-config‘ run.

How to tackle the problem

Valgrind provides a tool named callgrind which tracks the function calls and time of a specific binary being run. While this is a bit slower than the Google perftools, it provides more detailed data. The ‚callgring.out.PID‘ file can then be visualized in KCacheGrind.
Install Valgrind alongside with KcacheGrind. I’m using Fedora 21, other distributions use similar package names.

# yum install valgrind kcachegrind graphviz

In order to profile Icinga 2 with all debug symbols included, I’m compiling Icinga 2 with debug symbols enabled: -DCMAKE_BUILD_TYPE=Debug (Note: Using Icinga 2 packages you’ll get a separate package).
Valgrind requires a bunch of parameters which are easier being modified in a small script. I’m also running the direct debug build binaries instead of the installed binary here. Generating some sort of huge debug config inside the Icinga 2 cluster and node inventory is left to the reader’s imagination 😉 (I’ll write a different blog post for that sooner or later).

# vim callgrind_icinga2
#!/bin/bash
valgrind \
-v \
--trace-children=yes \
--tool=callgrind \
--simulate-cache=yes \
--collect-jumps=yes \
--dump-instr=yes \
--dump-line=yes \
/home/michi/coding/icinga/icinga2/debug/Bin/Debug/icinga2 node update-config
# sudo ./callgrind_icinga2

If you want to enforce a manual dump before the program ends, you can invoke the following command:

# callgrind_control -d

 

Visualize and analyze the bottlenecks

Opening the callgrind.out file(s)

$ sudo kcachegrind callgrind.out.16903

unveiled that there were certain unnecessary calls to generic functions.

  • Getting objects/changes on each AddObject() call is useless
  • ’node update-config‘ would cause AddObject() to validate each object. But we know already we’re right not parsing user’s input from the cli arguments.

Solve the problem

Refactoring the code and allowing to pass one-time collected objects/changes as well as suppressing configuration validation solved the problem in the end. Still it unveiled that you should sometimes stop feature development and profile your own application 🙂

Icinga 2 – More than just code

training_icinga2Icinga 2 ist ja ein riesengroßes Thema, nicht nur bei uns Entwicklern, die sich täglich mit Icinga 2 beschäftigen dürfen (Willkommen, Jean-Marcel!), sondern eigentlich auch fast schon überall. Da versteht es sich eigentlich von selbst, dass man als Entwickler auch mal über den Tellerrand schnuppert, und was Neues erleben mag.
Die Webinare mit Christian und mir dauern meist keine angesetzte halbe Stunde, sondern 1+ Stunde(n), weil ich gerne über Icinga 2 aus dem Entwickler-Nähkästchen plaudere, oder mal eben schnell ein Icinga 1.x Check Command ohne Vorbereitung in Icinga 2.x und schön migriere. Wo andere schon den altbekannten „Overflow“ haben, fängt der Spass mit Icinga 2 doch erst richtig an! Weil ich ja eigentlich stundenlang über Icinga 2 und wie mans macht reden kann, und dazu neige, Benutzern nicht die Lösung auf den (Forums)Teller zu knallen, sondern gemeinsam den Lösungsweg zu erarbeiten, kam die erste Icinga 2 Schulung wie gerufen 🙂
20140909_131938Von der Grundinstallation – die dank Paketen sehr einfach über die Bühne geht – bis hin zu den ersten Gehversuchen mit Gruppen und Service Apply Regeln war am ersten Tag alles dabei. Natürlich immer mit Hinweisen gespickt, wie es doch mal in Nagios oder Icinga 1.x gemacht worden ist. Nach der wohlverdienten Mittagspause ab in die (Un)Tiefen von Notifizierungen und Abhängigkeiten anhand von „magischen“ Apply Regeln – bis es auch jeder verstanden hat. Beim gemeinsamen Abendessen wurden dann schon erste Pläne geschmiedet wie man das eigene Setup denn nun optimal migrieren könnte – untermalt mit herrlichem Nürnberger Bier.
20140910_095616Am zweiten Tag gabs dann auch gleich den Radikaleinstieg in die Welt von verteilten Umgebungen, und was der Icinga 2 Cluster mit Lastverteilung und Hochverfügbarkeit denn nun schönes kann. Der etwas theoretische Einstieg hat sich allerdings schnell in die Praxis gewandelt, indem eigene Clusterszenarien diskutiert wurden, und man sich erst dann ans Eingemachte herangewagt hat: Die schon funktionierenden Icinga 2 Cluster VMs mal eben umbauen.
Eigene SSL Zertifikate generieren, Endpoints und Zonen Objekte verstehen lernen, und als Bonus obendrauf mit einem aktuellen Development Snapshot von Icinga Web 2 spielerisch erkennen, wie der Cluster tickt (bzw. nicht tickt, wenn man eine Instanz stoppt ;)). Weil das aber langweilig wäre, haben wir gemeinsam mit Dirk’s Hilfe am Beamer den Master-Slave Cluster in einen hochverfügbaren HA Cluster umgebaut. Weils einfach geht, und schön zu beobachten ist, wie die Checks und Notifizierungen im Cluster verteilt werden, und DB IDO in einem Failover-Szenario dann automatisch schwenkt.
icinga_web_2_snapshot_20140917Das wirklich schöne an dieser Schulung ist – neben magischem Apply und dem HA Cluster – man kann das erlernte Fachwissen mitnehmen, und auch ohne Schulungsnotebooks mit den Vagrant VMs aus dem Icinga Projekt das erlernte Wissen zu Hause ausprobieren. So schliesst sich der Kreis, dass eine Demo für Netways ins Icinga Projekt überführt wurde, und es jeder bei uns sowohl für Schulungen und Demos einsetzen kann. Das gesammelte Feedback fließt in Fixes und Features ein – wie eben gelernt „Bau den Master-Checker in ein HA Setup um“ mit wo liegt die Config, Gesundheitschecks sollen lokal laufen & globaler Zone für Templates.
icinga2_memeDem einen oder anderen Schulungsteilnehmer wird das sicherlich bekannt vorkommen – vielen Dank für das Feedback an dieser Stelle, es war mir ein Volksfest! 🙂
Was an dieser Stelle nicht unerwähnt bleiben sollte – das Herz eines Entwicklers geht auf, wenn das gezeigte gefällt, und der „Oh“, „Ah“ & „Wow“ Counter/Minute exponenziell zunimmt. Dieser Tweet und das Meme dazu sprechen wohl Bände, und hat uns alle besonders gefreut! 🙂
icinga_camp_san_francisco_smallDiese wunderbaren Impressionen nehme ich mal fix mit, wenns am Freitag ab nach San Francisco geht (Icinga Camp am 25.9. wo wir stark vertreten sind & ein kleiner Roadtrip gen Süden). Oder wie der Österreicher in mir zu sagen pflegt – I gfrei mi wia a klans Kind. Danke, Bernd & Julian, danke Netways 🙂
See you in The City!
 
Wer es nicht erwarten kann bis zum nächsten Icinga 2 Webinar / zur nächsten Icinga 2 Schulung / zur OSMC 2014 / zur CeBit 2015 / …:
Vagrant, Virtualbox installieren wie hier beschrieben und dann ein herzhaftes:

$ git clone https://github.com/Icinga/icinga-vagrant.git && cd icinga-vagrant/icinga2x-cluster && vagrant up

Servas, Icinga 2!

Reminder für das morgige Icinga 2 Webinar

Icinga 2 Wie immer vor einem Webinar, möchte ich die Gelegenheit nutzen um noch einmal alle Monitoring interessierten auf das morgige Thema Icinga 2: Enterprise Monitoring der nächsten Generation aufmerksam zu machen.
Gemeinsam mit Michi wollen wir die neuen Funktionsweisen und Unterschiede zu Icinga aufzeigen. Eine Registrierung ist natürlich bis morgen Früh noch möglich!
Wer es bis morgen nicht erwarten kann, dem sei unser Webinar-Archiv nahegelegt. Hier sind bereits einige Webinare zu den damaligen Dev-Releases von Icinga 2 und anderen Open Source Lösungen wie Puppet und OpenNebula verfügbar.
Bis morgen um 10:30 Uhr!

Christian Stein
Christian Stein
Manager Sales

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Manager Sales 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".

Reminder für das morgige Foreman / OpenNebula Webinar

opennebula_foreman Ich möchte noch einmal alle auf das morgige Webinar zum Thema Foreman: OpenNebula orchestrieren aufmerksam machen. Dabei wollen wir neben dem von NETWAYS entwickelten Modul Foreman-One auch auf Foreman und OpenNebula eingehen.
Ziel wird es aber sein zu demonstrieren, wie über das Foreman-Webinterface eine virtuelle Maschine erzeugt werden kann.
Wer sich für das Webinar noch registrieren will hat bis morgen Früh um 10:30 Uhr noch Gelegenheit dazu. In unserem Webinar-Archiv finden sich bereits einige Webinare zum Thema OpenNebula und Foreman (im Zusammenspiel mit Puppet).
Bis morgen früh um 10:30 Uhr!

Christian Stein
Christian Stein
Manager Sales

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Manager Sales 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".