Bursting und Throtteling in OpenStack

Wir haben die vergangenen Monate genutzt, um eine neue Cloud mit OpenStack aufzubauen. Im Zuge dessen, mussten wir eine Möglichkeit finden, die IOPS sowie die Bandbreite, die VMs zur Verfügung haben, zu limitieren.
Das Limitieren der Bandbreite sowie der IOPS erfolgt in OpenStack in sogenannten Flavors. In einem deutschsprachigen Interface von OpenStack werden diese “Varianten” genannt. Flavors werden hier als VM-Templates genutzt, mit denen sich VMs starten lassen. Es werden hier Ressourcen geregelt wie RAM, CPU und Firewallregeln aber eben auch die Limitierungen. Gesetzte Werte können nicht in laufenden VMs überschrieben werden. Möchte man diese ändern, muss die VM gelöscht und neu gebaut werden, nachdem die neuen Werte im Flavor angepasst wurden. Ein Rebuild reicht hier nicht aus.
Hier gibt es jedoch eine Ausnahme. Durch den Einsatz von beispielsweise libvirtd, können jene Beschränkungen mittels “virsh” angepasst werden.

Was sind IOPS und Bandbreite?

Bandbreite und IOPS geben an, wieviel Datendurchsatz sowie Lese und Schreiboperationen einer VM zugeteilt sind. Per Default sind diese unlimitiert, was unter gewissen Umständen zu Problemen führen kann.

Wieso sind Limitierungen sinnvoll?

In einer Cloud mit mehreren Virt-Systemen laufen mehrere VMs. Sind keine Limitierungen gesetzt, kann jede VM soviel Traffic und IOPS erzeugen, wie sie gerade braucht. Das ist natürlich für die Performance entsprechend gut, jedoch verhält es sich dadurch so, dass andere VMs auf dem gleichen Virt entsprechend unperformanter werden. Limitierungen werden daher dazu genutzt ein gleiches Niveau für alle VMs zu schaffen.

Bandbreite

Average

  1. quota:vif_inbound_average
  2. quota:vif_outbound_average

Wie der Name schon sagt, beschränkt man hier inbound (eingehenden) sowie outbound (ausgehenden) Traffic durch einen durchschnittlichen Wert, den diese beiden nicht überschreiten dürfen.

Peak

  1. quota:vif_inbound_peak
  2. quota:vif_outbound_peak

Die Bandbreite kann man auch mit Peak sowie Burst begrenzen. Peak gibt hierbei an, bis zu welchem Limit die Bandbreite genutzt werden darf, als absolutes Maximum. Dieser Wert funktioniert aber nur in Zusammenarbeit mit “Burst”.

Burst

  1. quota:vif_inbound_burst
  2. quota:vif_outbound_burst

Burst gibt nämlich an, wie lange die Bandbreite im Wert “Average” überschritten werden darf. Gemessen wird hier in KB. Setzt man also den Burst auf 1.048.576 KB, darf der Peak Wert solange genutzt werden, bis 1GB (1.048.576 KB) an Daten übertragen wurden. Zu Beachten ist aber, dass dieser Wert für jeden Zugriff neu gilt. Führt man also 3 Kommandos hintereinander aus (3x wget mit && verknüpft) greift der Burst für alle 3 gleichermaßen. Führt man die gleichen Kommandos ebenfalls hintereinander aus, aber verknüpft diese mit einem Sleep, greift der Burst für jedes Kommando neu.
 

IOPS

Throttle

  1. quota:disk_read_iops_sec
  2. quota:disk_total_iops_sec
  3. quota:disk_write_iops_sec

Die lesenden und schreibenden Prozesse der VMs können natürlich auch begrenzt werden. Hier gibt es zwei Möglichkeiten:

  • Limitierung von lesenden sowie schreibenden Prozessen separat
  • Limitierung auf absoluten Wert

Beides in Kombination geht nicht. Es nicht möglich zu konfigurieren, dass es 300 lesende, 300 schreibende und 700 insgesamte IOPS geben soll, würde aber auch keinen Sinn machen. Zu beachten ist, wenn alle 3 Werte gesetzt werden, können diese in einen Konflikt geraten und gegebenenfalls gar nicht greifen.

Burst

  1. quota:disk_write_iops_sec_max
  2. quota:disk_write_iops_sec_max_length

Durch das Bursting auf den Festplatten direkt, kann angegeben werden, mit welcher maximalen Anzahl an IOPS (quota:disk_write_iops_sec_max)eine VM die oben gesetzten Werte, für wie lange (quota:disk_write_iops_sec_max_length) überschreiten darf. Sinnvoll wäre dies, wenn bekannt ist, dass gewisse Prozesse kurzzeitig mehr IOPS benötigen, als freigegeben ist.

Beispiele

Um Limitierungen zu setzen, wird zunächst ein Flavor benötigt. Im Anschluss können die Werte gesetzt werden. Die Dokumentation zum Anlegen von Flavors gibts hier
openstack flavor set {$flavor} --property quota:{$param}={$value}
quota:disk_read_iops_sec='200'
(quota:disk_total_iops_sec='1000')
quota:disk_write_iops_sec='200'
quota:vif_inbound_average='10240'
quota:vif_inbound_burst='20480'
quota:vif_inbound_peak='15360'
quota:vif_outbound_average='10240'
quota:vif_outbound_burst='20480'
quota:vif_outbound_peak='15360'
quota:disk_write_iops_sec_max_length='10'
quota:disk_write_iops_sec_max='1000'
In diesem Beispiel würde man zum Beispiel die lesenden Prozesse auf 200 (quota:disk_read_iops_sec='200') beschränken, ebenso die schreibenden, bei einer eingehenden Brandbreite von 10MB(quota:vif_inbound_average='10240'). Peak liegt bei 20MB und darf für 15MB erreicht werden. Das ist natürlich ein sehr unrealistisch minimalistisches Begrenzungsbeispiel, jedoch sollte die Art und Weise wie es funktioniert verdeutlich worden sein.

Marius Gebert
Marius Gebert
Systems Engineer

Marius ist seit 2013 bei NETWAYS. Er hat 2016 seine Ausbildung zum Fachinformatiker für Systemintegration absolviert und ist nun im Web Services Team tätig. Hier kümmert er sich mit seinen Kollegen um die NWS Plattform und alles was hiermit zusammen hängt. 2017 hat Marius die Prüfung zum Ausbilder abgelegt und kümmert sich in seiner Abteilung um die Ausbildung unserer jungen Kollegen. Seine Freizeit verbringt Marius gerne an der frischen Luft und ist für jeden Spaß zu...

Ceph Training opensourced

 
Besides several other trainings, such as gitlab, foreman or graphite/grafana we’re happy to announce our newest member in the NETWAYS OpenSource training community.
You might have guessed it after reading the headline, we’ve published a ceph training.
 

This training is designed as a two days hands-on training introducing Ceph, its basics, cluster setup and many best practices.
The training participants will get an in-depth insight into the Ceph basics and configuration. They also learn about Ceph Cache Tier, Rados Gateway, RBD, CephFS, Monitoring and Sizing.

– README.md

As ceph is a project with huge momentum, not only regarding spreading but also development, changes are certain to happen.
The training right now is not very specific regarding OpenStack-Integration, so this will be in the focus in the next iteration.
Commits to the trainings are always welcome!
When you’re interested in a training with more interactivity and personal discussion, feel free to get an overview here.

Tim Albert
Tim Albert
System Engineer

Tim kommt aus einem kleinen Ort zwischen Nürnberg und Ansbach, an der malerischen B14 gelegen. Er hat in Erlangen Lehramt und in Koblenz Informationsmanagement studiert, wobei seine Tätigkeit als Werkstudent bei IDS Scheer seinen Schwenk von Lehramt zur IT erheblich beeinflusst hat. Neben dem Studium hat Tim sich außerdem noch bei einer Werkskundendienstfirma im User-Support verdingt. Blerim und Sebastian haben ihn Anfang 2016 zu uns ins Managed Services Team geholt, wo er sich nun insbesondere...

Modern open source community platforms with Discourse

Investing into open source communities is key here at NETWAYS. We do a lot of things in the open, encourage users with open source trainings and also be part of many communities with help and code, be it Icinga, Puppet, Elastic, Graylog, etc.
Open source with additional business services as we love and do only works if the community is strong, and pushes your project to the next level. Then it is totally ok to say “I don’t have the time to investigate on your problem now, how about some remote support from professionals?”. Still, this requires a civil discussion platform where such conversations can evolve.
One key factor of an open source community is to encourage users to learn from you. Show them your appreciation and they will like it and start helping others as you do. Be a role model and help others on a technical level, that’s my definition of a community manager. Add ideas and propose changes and new things. Invest time and make things easier for your community.
I’ve been building a new platform for monitoring-portal.org based on Discourse in the last couple of days. The old platform based on Woltlab was old-fashioned, hard to maintain, and it wasn’t easy to help everyone. It also was closed source with an extra license, so feature requests were hard for an open source guy like me.
Discourse on the other hand is 100% open source, has ~24k Github stars and a helping community. It has been created by the inventors of StackOverflow, building a conversation platform for the next decade. Is is fast, modern, beautiful and both easy to install and use.
 

Setup as Container

Discourse only supports running inside Docker. The simplest approach is to build everything into one container, but one can split this up too. Since I am just a beginner, I decided to go for the simple all-in-one solution. Last week I was already using the 1.9.0beta17, running really stable. Today they released 1.9.0, I’ll share some of the fancy things below already 🙂
Start on a fresh VM where no applications are listening on port 80/443. You’ll also need to have a mail server around which accepts mails via SMTP. Docker must be installed in the latest version from the Docker repos, don’t use what the distribution provides (Ubuntu 14.04 LTS here).

mkdir /var/discourse
git clone https://github.com/discourse/discourse_docker.git /var/discourse
cd /var/discourse
./discourse-setup

The setup wizard ask several questions to configure the basic setup. I’ve chosen to use monitoring-portal.org as hostname, and provided my SMTP server host and credentials. I’ve also set my personal mail address as contact. Once everything succeeds, the configuration is stored in /var/discourse/container/app.yml.
 

Nginx Proxy

My requirement was to not only serve Discourse at /, but also have redirects for other web applications (the old Woltlab based forum for example). Furthermore I want to configure the SSL certificates in a central place. Therefore I’ve been following the instructions to connect Discourse to a unix socket via Nginx.

apt-get install nginx
rm /etc/nginx/sites-enabled/default
vim /etc/nginx/sites-available/proxy.conf
server {
    listen 443 ssl;  listen [::]:443 ssl;
    server_name fqdn.com;
    ssl on;
    ssl_certificate      /etc/nginx/ssl/fqdn.com-bundle.crt;
    ssl_certificate_key  /etc/nginx/ssl/fqdn.com.key;
    ssl_protocols TLSv1.2 TLSv1.1 TLSv1;
    ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA;
    ssl_prefer_server_ciphers on;
    # openssl dhparam -out /etc/nginx/ssl/dhparam.pem 4096
    ssl_dhparam /etc/nginx/ssl/dhparam.pem;
    # OCSP Stapling ---
    # fetch OCSP records from URL in ssl_certificate and cache them
    ssl_stapling on;
    ssl_stapling_verify on;
    location / {
        error_page 502 =502 /errorpages/discourse_offline.html;
        proxy_intercept_errors on;
        # Requires containers/app.yml to use websockets
        proxy_pass http://unix:/var/discourse/shared/standalone/nginx.http.sock:;
        proxy_set_header Host $http_host;
        proxy_http_version 1.1;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
    }
}
ln -s /etc/nginx/sites-available/proxy.conf /etc/nginx/sites-enabled/proxy.conf
service nginx restart

Another bonus of such a proxy is to have a maintenance page without an ugly gateway error.
The full configuration can be found here.
 

Plugins

Installation is a breeze – just add the installation calls into the app.yml file and rebuild the container.

# egrep -v "^$|#" /var/discourse/containers/app.yml
templates:
  - "templates/postgres.template.yml"
  - "templates/redis.template.yml"
  - "templates/web.template.yml"
  - "templates/web.ratelimited.template.yml"
expose:
params:
  db_default_text_search_config: "pg_catalog.english"
env:
  LANG: en_US.UTF-8
  DISCOURSE_HOSTNAME: fqdn.com
  DISCOURSE_DEVELOPER_EMAILS: 'contact@fqdn.com'
  DISCOURSE_SMTP_ADDRESS: smtp.fqdn.com
  DISCOURSE_SMTP_PORT: 587
  DISCOURSE_SMTP_USER_NAME: xxx
  DISCOURSE_SMTP_PASSWORD: xxx
volumes:
  - volume:
      host: /var/discourse/shared/standalone
      guest: /shared
  - volume:
      host: /var/discourse/shared/standalone/log/var-log
      guest: /var/log
hooks:
  after_code:
    - exec:
        cd: $home/plugins
        cmd:
          - git clone https://github.com/discourse/docker_manager.git
          - git clone https://github.com/discourse/discourse-akismet.git
          - git clone https://github.com/discourse/discourse-solved.git
run:
  - exec: echo "Beginning of custom commands"
  - exec: echo "End of custom commands"
./launcher rebuild app

Akismet checks against spam posts as you know it from WordPress. We’ve learned that spammers easily crack reCaptcha, and the only reliable way is filtering the actual posts.
The second useful plugin is for accepting an answer in a topic, marking it as solved. This is really useful if your platform is primarily used for Q&A topics.
 

Getting Started

Once everything is up and running, navigate to your domain in your browser. The simple setup wizard greets you with some basic questions. Proceed as you like, and then you are ready to build the platform for your own needs.
The admin interface has lots of options. Don’t fear it – many of the default settings are from best practices, and you can always restore them if you made a mistake. There’s also a filter to only list overridden options 🙂

Categories and Tags

Some organisation and structure is needed. The old-fashioned way of choosing a sub forum and adding a topic in there is gone. Still Discourse offers you to require a category from users. Think of monitoring – a question on the Icinga Director should be highlighted in a specific category to allow others to catch up.
By the way – you can subscribe to notifications for a specific category. This helps to keep track only for Icinga related categories for example.
In addition to that, tags help to refine the topics and make them easier to search for.

Communication matters

There are so many goodies. First off, you can start a new topic just from the start page. An overlay page which saves the session (!) is here for you to edit. Start typing Markdown, and see it pre-rendered live on the right side.
You can upload images, or paste an URL. Discourse will trigger a job to download this later and use a local cache. This avoids broken images in the future. If you paste a web link, Discourse tries to render a preview in “onebox”. This also renders Github URLs with code preview.
Add emotions to your discussion, appreciate posts by others and like them, enjoy the conversation and share it online. You can even save your draft and edit it amongst different sessions, e.g. after going home.

 

Tutorials, Trust Level and Rewards

Once you register a new account (you can add oauth apps from Twitter, Github, etc.!), a learning bot greets you. This interactive tutorial helps you learning the basics with likes, quotes, urls, uploads, and rewards you with a nice certificate in the end.
New users don’t start with full permissions, they need to earn their trust. Once they proceed with engaging with the community, their trust level is raised. The idea behind this is not to have moderators and admins regulating the conversation, but let experienced members to it. Sort of self healing if something goes wrong.
Users who really engage and help are able to earn so-called badges. These nifty rewards are highlighted on their profile page, e.g. for likes, number of replies, shared topics, even accepted solutions for questions. A pure motivation plaything built into this nice piece of open source software.

 

Wiki and Solved Topics

You can change topics to wiki entries. Everyone can edit them, this way you’ll combine the easiness of writing things in Markdown with a full-blown documentation wiki.
Accepting a replay as solution marks a topic as “solved”. This is incredibly helpful for others who had the same problem.

 

Development

As an administrator, you’ll get automated page profiling for free. This includes explained SQL queries, measured page load time, and even flame graphs.
If you ever need to reschedule a job, e.g. for daily badge creation, admins can access the Sidekiq web UI which really is just awesome.
Plugin development seems also easy if you know Ruby and EmberJS. There are many official plugins around which tested before each release.

Discourse also has a rich REST API. Even a monitoring endpoint.
 

Maintenance

You can create backups on-demand in addition to regular intervals. You can even restore an old backup directly from the UI.

 

Conclusion

Discourse is used by many communities all over the world – Graylog, Elastic, Gitlab, Docker, Grafana, … have chosen to use the power of a great discussion platform. So does monitoring-portal.org as a #monitoringlove community. A huge thank you to the Discourse team, your software is pure magic and just awesome 🙂
My journey in building a new community forum from scratch in just 5 days can be read here 🙂
monitoring-portal.org running Discourse is fully hosted at NETWAYS, including SSL certificates, Puppet deployment and Icinga for monitoring. Everything I need to build an awesome community platform. You too?
 

Michael Friedrich
Michael Friedrich
Senior Developer

Michael ist seit vielen Jahren Icinga-Entwickler und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach Nürnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den süchtig machenden Dragee-Keksi und der Linzer Torte. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht in der Community helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst...

NodeJS HA mit PM2…

ich hatte in Vergangenheit bereits einen Blog Post über NodeJS in Verbindung mit dem NodeJS ‘Cluster’ Modul geschrieben ( siehe hier ), nun möchte ich euch zeigen wie Ihr eure NodeJS Anwendung auch ohne Programmierarbeit (also als reine Ops Tätigkeit) zum Cluster umfunktioniert und wie ihr diese anschließend verwalten könnt.
nodejs-logo-2015
Legen wir los, wir benötigen hierzu NodeJS, am besten 4.4 LTS und 4 zusätzliche Module/Helper, fangen wir also mit der Installation an…

$ npm install -g pm2
$ npm install -g express-generator
$ mkdir ~/project && cd project
$ npm install --save express
$ npm install --save sleep

…nun generieren wir das Express Anwendungsgerüst…

$ express -f .
   create : .
   create : ./package.json
   create : ./app.js
   create : ./public
   create : ./public/javascripts
   create : ./public/images
   create : ./public/stylesheets
   create : ./public/stylesheets/style.css
   create : ./routes
   create : ./routes/index.js
   create : ./routes/users.js
   create : ./views
   create : ./views/index.jade
   create : ./views/layout.jade
   create : ./views/error.jade
   create : ./bin
   create : ./bin/www
   install dependencies:
     $ cd . && npm install
   run the app:
     $ DEBUG=project:* npm start
$

… danach löschen wir in der Datei app.js alles von Zeile 13 bis 58, wir benötigen nur das Gerüst selbst und ein paar Zeile selbst geschriebenen Code, um diesen kommen wir leider nicht herum, da wir ja auch was sehen wollen.
Fügt nun ab Zeile 14 folgenden Code hinzu…

var crypto = require( 'crypto' );
var util = require( 'util' );
var sleep = require( 'sleep' ).sleep;
function getRandHash() {
    var current_date = (new Date()).valueOf().toString();
    var random = Math.random().toString();
    return crypto.createHash('sha1').update(current_date + random).digest('hex');
}
var myID = getRandHash();
app.get( '/', function( req, res ) {
    sleep( Math.floor( (Math.random() * 3) + 1 ) );
    res.send({
        "ID": myID,
        "PID": process.pid,
        "ENV": process.env
    });
});

…nun starten wir die App über PM2 im Cluster Mode, hier bitte dem Parameter ‘-i’ nur einen Wert gleich der Anzahl der CPU Cores mitgeben. Dann testen wir das Ganze doch gleich mal…

$ cd project
$ pm2 start bin/www -i 4

…ihr solltet nun folgende Ausgabe zu sehen bekommen…
pm2-start-www-cluster
…ihr könnt eure Anwendung auch auf Fehler überprüfen, dafür gibt euch PM2 einen Parameter ‘logs’ mit, der wiederum einige Flags kennt. Wenn ihr nur ‘pm2 logs’ eingebt dann bekommt ihr die Standardausgabe unserer Anwendung zu sehen, wenn ihr zusätzlich das Flag ‘–err’ mit angebt, bekommt ihr die Standard Fehlerausgabe, was für das Debugging recht hilfreich ist.
pm2-logs-examine
So, nun könnt ihr in eurem Browser mal die Anwendung aufrufen. Der Listener der Anwendung horcht auf dem Port 3000. Ein Aufruf auf http://127.0.0.1:3000 sollte ein JSON liefern, ähnlich zu dieser Ausgabe hier…
pm2-cluster-test1
Da wir in unserem Code eine künstliche Verzögerung eingebaut haben, könnt ihr nun mit 2 direkt Aufeinander folgenden Browser Reload sehen das sich die ID u. PID Werte gelegentlich ändern, dies bedeutet, dass unsere Cluster Anwendung funktioniert.
pm2-logo
Ich hoffe ich konnte euch nun zum Spielen und Experimentieren animieren. PM2 wird von der Firma Kissmetrics als OpenSource Project stetig weiter entwickelt und hat noch so viel mehr zu bieten, ganz findige unter euch werden die Monitoring API zu schätzen wissen und diese vmtl. in Icinga2, Graphite, Kibana und anderen Lösungen integrieren wollen.
Dann bis demnächst 🙂

Sync Git repositories to GitHub

GitHub-Mark-120px-plusWhile we still have our own repositories located at https://git.netways.org it’s reasonable to sync the existing repositories to GitHub targetting a wider audience (and not everyone likes the gitorious web interface either). There are certain requirements syncing git repositories in general:

  • create, update and delete branches
  • create and delete tags
  • don’t always clone the repository but fetch local changes

Aside from that, you’ll need

  • a shell user, e.g. github on a box running the sync
  • ssh key for pushing remote origin
  • small sync script
  • a cronjob for that sync script, e.g. every 5 minutes
  • git binary >= 1.7.10 providing the –prune option

If you are planning to push your local repository (in our example, git.netways.org) to github.com, you’ll also need the following

  • add the public ssh key to your github user at https://github.com/settings/ssh
  • ensure that this user is allowed to push your company’s repositories (make it a team member)

The sync script part is easy thanks to the possibilities git already provides. An older version of the sync script is used for syncing the Icinga Github repositories in a similar fashion. For Icinga, it’s most important to sync the git tags, making the release tarballs available on Github.

#!/bin/bash
REPO_HOME="/data/scm/sync"
declare -A REPOS
# syntax is [github_repo]="netways_repo"
REPOS=([ingraph]="ingraph/ingraph" [lconf]="lconf/lconf" [lconf-icinga-module]="lconf/icinga-module" [lconf-web]="lconf/lconf-web")
cd $REPO_HOME
for REPO_GITHUB in "${!REPOS[@]}"
do
	REPO_LOCAL=${REPOS[$REPO_GITHUB]}
        echo "### Processing repo $REPO_LOCAL"
        if [ ! -d $REPO_LOCAL ]; then
                git clone --bare --mirror git://git.netways.org/$REPO_LOCAL.git $REPO_LOCAL
        fi
        (cd $REPO_LOCAL; git fetch --prune; git push --prune git@github.com:NETWAYS/$REPO_GITHUB.git +refs/heads/*:refs/heads/* +refs/tags/*:refs/tags/*)
done

git {fetch,push} –prune ensures that deleted branches/tags on the source repository are also deleted on the target repository.
Saving the sync script as /data/scm/sync/create_and_sync allows you to add the following cron job every five minutes:

# su - github
$ crontab -e
# Sync repos to github
*/5 * * * * /data/scm/sync/create_and_sync > /dev/null 2>&1

Ynetways_githubou can check the result watching the development branches at https://github.com/netways for LConf and inGraph – if you’re looking for your own custom git integration, don’t hesitate to contact us 🙂
PS: Another cool way of syncing github repositories is the Icinga Exchange integration!

Michael Friedrich
Michael Friedrich
Senior Developer

Michael ist seit vielen Jahren Icinga-Entwickler und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach Nürnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den süchtig machenden Dragee-Keksi und der Linzer Torte. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht in der Community helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst...

Letzter Aufruf für das Icinga Web 2 Webinar

icinga_logo_200x69 Nachdem letzte Woche erfolgreich die Open Source Monitoring Conference (OSMC) stattgefunden hat und aufgrund der vielen Info-Blogposts der ein oder andere vielleicht den Webinar-Reminder übersehen hat, möchte ich natürlich kurz vor dem Icinga Web 2 Webinar noch einmal darauf aufmerksam machen.
Morgen um 10:30 Uhr wollen wir die aktuelle Version von Icinga Web 2 inkl. der eingebauten Features und den Installer vorstellen. Eine Registrierung ist natürlich bis morgen Früh noch möglich.
Wer sich für die nächsten Webinare in diesem Jahr noch interessiert, kann sich natürlich auch gleich registrieren:

Webinar Thema Termin und Registrierung
Puppet: Windows Configuration Management 12. Dezember 2014 – 10:30 Uhr
NETWAYS: Jahresrückblick 2014 18. Dezember 2014 – 10:30 Uhr

In unserem Webinar-Archiv findet man auch noch die bisherigen Webinare, um die Wartezeit zu überbrücken.
Bis morgen!

Christian Stein
Christian Stein
Lead Senior Account Manager

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

JMeter für Lazy Tester – Proxy

jmeter-logoMittlerweile ist das Testen an jeder Ecke, man testet dies, man testet das, es gibt für jeden Einsatzzweck ein eigenes Tool und trotzdem machen alle das gleiche und zwar testen, testen und wieder testen. Manche Tools machen das Leben einfacher andere wiederum schwerer, sobald die Menge an Tests einen erschlägt und man nicht mehr den Code refactored sondern die Tests, vllt. wird es irgendwann soweit kommen, dass man Tests für die Tests anfängt zu schreiben 🙂
Na ja, wie auch immer, heute will ich euch den JMeter näher bringen, wie man mit seiner Hilfe, ganz einfache Tests für eine bestehende Webanwendung schreiben kann, ohne viel Aufwand dafür aufbringen zu müssen.
Zunächst besorgen wir uns JMeter Binaries, nachdem wir es entpackt haben, führen wir die ( jmeter.sh | jmeter.bat ) im Ordner /bin aus, in wenigen Sekunden sollten wir vor unseren Augen die GUI zu sehen bekommen:
Apache-JMeter-Testplan
Als Erstes, wechseln wir die Sprache von Deutsch auf Englisch unter Optionen > Wählen Sie eine Sprache > English, gleich danach mit einem geschickten Maus-Rechtsklick auf den Testplan > Add > Threads (Users) > Thread Group und belasen alles so wie es ist.
Nun folgt ein weiterer Maus-Rechtsklick, diesmal aber auf den WorkBench > Add > Non-Test Elements > HTTP(S) Test Script Recorder und jetzt ändern wir hier ein paar Sachen ab:

  • Global Settings > Port = 8090
  • Test plan content > Target Controller = Testplan > Thread Group
  • URL Patterns to Include > Add = .*

Wir sind fast soweit, wir brauchen jetzt nur noch einen View Results Tree – Listener, also wieder Maus-Rechtsklick auf den Testplan > Add > Listener > View Results Tree.
Das Ganze sieht am Ende dann so aus:
Apache-JMeter-2
Als letzten Schritt müssen wir jetzt nur noch den Proxy im Browser eintragen als Host: localhost und Port: 8090 und die Tests-Aufzeichnung kann beginnen, sobald wir auf den Start Button klicken beim HTTP(S) Test Script Recorder.
Was wollen wir aber testen? Nun, ich habe mich für Icinga Web 2 entschieden, wegen den vielen Requests die im Hintergrund so passieren und folgendes kleines Szenario überlegt:

  • aufrufen der Startseite
  • anmelden
  • nach test-flap-10 suchen
  • test-flap-10 Host aufrufen
  • System Configuration aufrufen
  • History Notifications aufrufen
  • Dashboard Landingpage aufrufen
  • abmelden

Jetzt drücken wir auf den Start Button und rufen im Browser http://localhost:8080/icingaweb auf und gehen das Szenario durch und wenn wir fertig sind, können wir die Test-Aufzeichnung im JMeter über den Stop Button beenden.
Das wars auch schon, die Thread Group wurde mit allen Requests gefüllt die so alles entstanden sind während der Test-Aufzeichnung und können nun auch von JMeter abgespielt werden.
Apache-JMeter-3
Die Requests Ergebnisse können nach dem Abspielen im View Results Tree ausgewertet werden.
Apache-JMeter-4
Sollte kein Request fehlgeschlagen haben, so können wir davon ausgehen, dass die Kommunikation zwischen dem Front- und Backend funktioniert.
Im Großen und Ganzen wie man sieht, lässt sich mit JMeter sehr schnell und einfach ein Test aufzeichnen, abspielen und auswerten und jetz kommt das ABER …
… dafür gibt’s weiter unten die Kommentare 😉
P.S. Humor …

Webinar-Video zum Puppet-Webinar vom 17.10.2013 ist nun online

logo_PuppetWie bereits gestern im Webinar versprochen, haben wir uns um einen schnellen Schnitt und eine rasche Konvertierung des Webinar-Videos gekümmert. Das Video vom Puppet-Webinar ist ab sofort auf YouTube und unserer Webinar-Archivseite zu sehen. Außerdem haben wir die Präsentationsfolien auf slideshare zur Verfügung gestellt.
Alles beides zusammen gibt’s schön aufgeräumt auf unserer Webinar-Seite.

Jetzt schon für die nächsten Webinare registieren:

  • Graphite – 06.11.2013 – 14:00 Uhr
  • Icinga 2 – 13.11.2013 – 14:00 Uhr
Georg Mimietz
Georg Mimietz
Lead Support Engineer

Georg kam im April 2009 zu NETWAYS, um seine Ausbildung als Fachinformatiker für Systemintegration zu machen. Nach einigen Jahren im Bereich Managed Services ist er in den Vertrieb gewechselt und kümmerte sich dort überwiegend um die Bereiche Shop und Managed Services. Seit 2015 ist er als Teamlead für den Support verantwortlich und kümmert sich um Kundenanfragen und die Ressourcenplanung. Darüber hinaus erledigt er in Nacht-und-Nebel-Aktionen Dinge, für die andere zwei Wochen brauchen.

Nicht vergessen! Donnerstag findet unser Puppet Webinar statt

logo_PuppetAuch diese Woche werden wir unsere Interessenten wieder mit einem Webinar von unseren Produkten überzeugen. Am Donnerstag, 17.10.2013 findet um 14:00 Uhr unser Webinar zum Thema Puppet statt. Wir werden dabei sowohl auf die Open-Source als auch auf die Enterprise-Lösung eingehen. Die Teilnahme am Webinar ist natürlich für Jedermann kostenfrei möglich. Weitere Details und die Registrierungseite sind auf der NETWAYS-Seite unter Webinare zu finden.
Das Webinar wird von Markus Waldmüller und Georg Mimietz geführt.
Übrigens: In 3 Wochen, am 06.11.2013 findet unser GraphiteWebinar statt. Also nicht verpassen und gleich registrieren.

Georg Mimietz
Georg Mimietz
Lead Support Engineer

Georg kam im April 2009 zu NETWAYS, um seine Ausbildung als Fachinformatiker für Systemintegration zu machen. Nach einigen Jahren im Bereich Managed Services ist er in den Vertrieb gewechselt und kümmerte sich dort überwiegend um die Bereiche Shop und Managed Services. Seit 2015 ist er als Teamlead für den Support verantwortlich und kümmert sich um Kundenanfragen und die Ressourcenplanung. Darüber hinaus erledigt er in Nacht-und-Nebel-Aktionen Dinge, für die andere zwei Wochen brauchen.