OSCAMP #3 | Ansible: Call for Presentations


Configuration in networks can quickly consume a lot of time. The automation tool Ansible helps! You know how to automate things with Ansible and would be open to share your practices with your fellows? Become a speaker at OSCAMP! Open Source Camp is a series of events giving Open Source projects a platform to present themselves to the community. It is a conference format designed bring forward Open Source projects and strengthen their communities.
Its third edition on Ansible takes place right after OSDC‘s lecture program on May 16, 2019, in Berlin. CfP runs until February 28, 2019.
Get on stage! Register as a speaker: opensourcecamp.de/submit-a-talk

#OSCAMP | May 16, 2019 | Berlin
Julia Hornung
Julia Hornung
Marketing Manager

Julia ist seit Juni 2018 Mitglied der NETWAYS Family. Vor ihrer Zeit in unserem Marketing Team hat sie als Journalistin und in der freien Theaterszene gearbeitet. Ihre Leidenschaft gilt gutem Storytelling, klarer Sprache und ausgefeilten Texten. Privat widmet sie sich dem Klettern und ihrer Ausbildung zur Yogalehrerin.

Ice, Ice – Icinga 2 / Puppet – Baby!


Bis vor Kurzem liefen in den Büros die Klimaanlagen oder – wie bei uns – die Tisch- und Standventilatoren auf Hochtouren, um ein halbwegs erträgliches Arbeiten zu ermöglichen. Ach ja: Sommer…  Allmählich normalisieren sich die Temperaturen ja wieder. Letztens las ich auf Twitter gar: “24 Grad nach Gewitter. Kann man schon Glühwein?” Damit ihr trotz des Sommers und allem, was er mit sich bringt – Rekordhitze oder Glühweindurst, einen kühlen Kopf bewahrt, hier ein kurzer Hinweis: Bald ist wieder Winter! Und dann gibt es von uns ein kleines Geschenk: Am 18./19. Dezember findet die erste Ausgabe unseres neuen Icinga 2 / Puppet Workshops statt. Anmelden könnt ihr euch schon jetzt.

Icinga 2 / Puppet ist ein Workshop für Fortgeschrittene.

Ihr lernt, wie ihr mit Puppet eine dezentrale Icinga 2-Umgebung aufbaut und konfiguriert.
Das heißt:

  • Hands-on! Am Ende wisst ihr, wie ihr ein solches Setup mit dem Icinga-2-Puppet-Modul einrichtet, wozu ihr das Role/Profile-Konzept braucht und habt das Ganze selbst einmal durchgespielt. Daneben werdet ihr über Zones und Endpoints diskutieren und euch fortgeschrittene Modul-Funktionen ansehen.
  • Für Fortgeschrittene: Der Workshop richtet sich an erfahrene Administratoren, die bereits Vorwissen mit beiden Projekten haben.
Hier noch einmal die Workshop-Inhalte in der Übersicht
  • Icinga 2 Master mit Icinga Web 2 installieren
  • Einrichten mehrerer Icinga 2 Agenten auf verschiedenen Plattformen (einschließlich Windows)
  • Verwenden einer dedizierten Zertifizierungsstelle, um eingehende Zertifikatsanforderungen automatisch zu signieren
  • Integration eines Icinga 2 Satelliten
  • Aufbau eines halbautomatischen Monitorings von Hosts mit Facts und PuppetDB
  • Verwenden von Git mit r10k für die automatische Bereitstellung unserer Puppet-Module in dynamischen Puppet-Umgebungen

Workshop-Leiter ist Lennart Betz, Open Source Trainer, Senior Consultant bei NETWAYS, Entwickler des Icinga-2-Puppet-Moduls und Autor des Buches „Icinga 2. Ein praktischer Einstieg ins Monitoring.“ Ihr seid neugierig geworden, euch aber nicht sicher, ob ihr das entsprechende Vorwissen mitbringt? Dann checkt doch mal die Inhalte unserer „Fundamentals for Puppet“ und „Icinga 2“-Schulungen, die wir allen Einsteigern ins Thema empfehlen.
Einen kleinen Vorgeschmack, was euch erwartet, bekommt ihr in unserer Blogserie:

Icinga 2 automatisieren mit Puppet

Alle Infos auf netways.de/trainings

Julia Hornung
Julia Hornung
Marketing Manager

Julia ist seit Juni 2018 Mitglied der NETWAYS Family. Vor ihrer Zeit in unserem Marketing Team hat sie als Journalistin und in der freien Theaterszene gearbeitet. Ihre Leidenschaft gilt gutem Storytelling, klarer Sprache und ausgefeilten Texten. Privat widmet sie sich dem Klettern und ihrer Ausbildung zur Yogalehrerin.

OSDC 2018 Recap: The Archive is online


 
Open Source Data Conference| JUNE 12 – 13, 2018 | BERLIN
Hello Open Source Lovers,
as we know all of you are most of the time focused on the things to come: An upcoming release or a future-oriented project you are working on. But as Plato said, “twice and thrice over, as they say, good is it to repeat and review what is good.”

OSDC Archive is online, giving us the occasion to do so.

OSDC 2018 was a blast! Austria, Belgium, Germany, Great Britain, Italy, Netherlands, Sweden, Switzerland, Spain, Czech Republic and the USA: 130 participants from all over the world came to Berlin to exchange thoughts and discuss the future of open source data center solutions.
„Extending Terraform“, „Monitoring Kubernetes at scale“, „Puppet on the Road to Pervasive Automation“ and „Migrating to the Cloud“ were just a few of many, trailblazing topics: We are overwhelmed by the content and quality of speakers, who presented a really interesting range of technologies and use cases, experience reports and different approaches. No matter what topic, all of the 27 high-level speakers had one goal: Explain why and how and share their lessons learned. And by doing so they all contributed to Simplifying Complex Infrastructures with Open Source.
Besides the lectures the attendees joined in thrilling discussions and a phenomenal evening event with a mesmerizing view over the city of Berlin.
A big thank you to our speakers and sponsors and to all participants, who made the event special. We are already excited about next year’s event – OSDC 2019, on May 14 to 15 in Berlin. Save the date!
And now, take a moment, get yourself a cup of coffee, lean back and recap the 2018 conference. Have a look at videos and slides and photos.

Julia Hornung
Julia Hornung
Marketing Manager

Julia ist seit Juni 2018 Mitglied der NETWAYS Family. Vor ihrer Zeit in unserem Marketing Team hat sie als Journalistin und in der freien Theaterszene gearbeitet. Ihre Leidenschaft gilt gutem Storytelling, klarer Sprache und ausgefeilten Texten. Privat widmet sie sich dem Klettern und ihrer Ausbildung zur Yogalehrerin.

Location-Aware Settings With ControlPlane

Part of my “arriving at the office in the morning” ritual involves quitting all my personal applications (e.g. Sonos), re-enabling my work e-mail account and a whole slew of other tiny changes that differentiate my work environment from my home environment. While in itself this isn’t too much of a hassle it does get rather tedious after a while. Especially so if I forget to start certain apps like my Jabber client and don’t realize that until much later.
The ControlPlane application promises to solve this exact problem by running specific actions whenever it detects a location change.
In order to do this you first have to set up “contexts”: These are essentially the locations you want ControlPlane to be aware of. As a starting point I’ve created two contexts “Home” and “Work” for my most-frequently used locations:

The next step involves telling ControlPlane what kind of information it should use to determine where you are. ControlPlane supports a wide variety of so-called evidence sources for this, some of which include:

  • IP address range, nearby WiFi networks
  • Attached devices (screens, USB and bluetooth devices)
  • Bonjour services (e.g. AppleTV)

Once you’ve made up your mind about which evidence sources to use you need to actually configure rules for these sources. An example would be “If my laptop can see the WiFi network ‘netways’ I’m in the ‘Work’ environment.” You also get to choose a confidence rating for each of those rules. This is useful if some of your rules could potentially also match in other, unrelated environments – for example because the IP address range you’re using at work is also commonly used by other companies.

Once you’re sufficiently confident that your location detection rules are working reliably you can set up actions which ControlPlane automatically performs whenever you enter or leave a certain location:

For my personal use I’ve found the built-in library of actions to be quite useful. However, there are a few things that even ControlPlane doesn’t support out of the box – like disabling specific e-mail and Jabber accounts. Luckily it does let you can run arbitrary external applications, including ones you’ve built with macOS’s Script Editor application:

NETWAYS Gebäudeautomation

fhemiconManuelle Schaltungsaufgaben sind einfach nervig und kosten Energie. Vor allem in Büros. Denn nicht jeder denkt an das Abschalten von Kaffeemaschine, Dashboards oder Licht im Allgemeinen. In größeren Gebäuden oder verteilten Räumen ist es auch nicht gleich ersichtlich, dass hier noch eine Heizung abgeregelt werden muss oder das Licht noch brennt.
Besser funktioniert es, wenn Heizungen automatisch geregelt werden oder Verbraucher zentral und zeitlich gesteuert werden. Um die Prozesse bei uns zu vereinfachen setzen wir mittlerweile Komponenten von Homematic in Kombination mit FHEM ein. Homematic kommuniziert bidirektional und verschlüsselt über Funk. Die Möglichkeit zur Sabotage werden damit gering gehalten und die Geräte senden sogar Schaltzustände und Statusinformationen wie Batteriekapazität an die Zentrale zurück. Als Oberfläche und Schnittstelle kommt bei uns FHEM zum Einsatz – ein OpenSource Perl Daemon welcher eine Reihe von Schnittstellen unterstützt (KNX, 1-Wire, FS20, Samsung, usw.) und einen Baukasten zur Gruppierung von Komponenten und zeitlichen Abfolgen bereitstellt.
logo_homematicMittlerweile steuern wir damit unsere Dashboards und Heizkörper (über MAX! Cube Lan-Gateway). Der Taster am Eingang kann sogar dazu genutzt werden um eingehende Essensbestellungen über einen Jabber Bot benachrichtigen zu lassen. Im Moment befindet sich noch alles in den Kinderschuhen aber es bietet Raum für mehr: Füllstand des Briefkastens, Heizungssteuerung per Anwesenheit, Luftgüte in den Büroräumen und vieles mehr. Aber auch für unser Monitoring ergeben sich einige sinnvolle Parameter: Temperaturen, geöffnete Türen und Fenster.
 
 

Marius Hein
Marius Hein
Head of Development

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.

OSDC 2015 – Enterprise integration with open source

Last year’s OSDC already was a huge success and I really enjoyed all the technical presentations as well as – of course – the tasty food & evening event. So why bother joining my colleagues and the conference this year again? Reading through the speakers list unveiled a certainly interesting program fully packed into 2 days with one day full of Vagrant/Docker/Logstash workshops in advance. For what it’s worth, day 1 was already mind-blowing to me.
After Bernds funny-as-we-love-it welcome presentation Nigel Kersten took over in room MOA5 with “In defense of datacenters”. What we learned is definitely that Europe and the US think different with “putting something into the cloud”. While there are still people around being “cloud skeptic”, the presentation also unveiled some changes going on – from “automate all the things” towards “how to integrate your app containers” into.


 
Not only Nigel was taking that into account, Mitchel Hashimoto (I tend to call him “Mr. Vagrant”, life-saver in many Icinga ways) also referred to that later on in his presentation on “Automating the Modern Datacenter: Development to Production”. He also explained how tools at HashiCorp work, and added examples on how to combine open source tools such as Vagrant, Packer, Consul, and Terraform.
Kelsey Hightower did go fast in his presentation towards an awesome live demo on distributed systems with CoreOS, Kubernetes & Fleet. Actually this demo looked pretty easy, I bet everyone can just do that on their notebooks while driving back home from OSDC. And it also made it clear – the cli is becoming important again with all the tools involved. User interfaces are nice, but the real processing happens on the command line, combined with clusters, automation, monitoring, etc.


Entertaining and smiling the noise irritations away, James Fryman gave an awesome insight on why you would want to use #chatops. Some ops stories from GitHub while sharing real world scenarios from his current employer StackStorm, plus the advice to make your bot a human character (“Bob”) let time just go by and we certainly will have to look into Hubot and how they are called 😉 Pricessless answer to “How much does #chatops disturb admins in $dayjob?” – “It saved them a lot of time, let them slack off a bit.”


Jan-Piet Mens started early with G&T time reducing the nervosity level – according to the audience his talk on MQTT for the datacenter was pretty much a blast. And hey, he didn’t mention the “N”-word, but just #icinga 😉


I did know about Apache Mesos a bit as we were evaluating it for package build clusters at NETWAYS a while back. The presentation on “Why the Datacenter Needs an Operating System” by Bernd Mathiske included an introduction into the entire framework with programmable interfaces and orchestration. It’s pretty clear – there is so much going on the near future in the open source world, and so little time to put everything together 😉
Bernd Ahlers gave an introduction into configuration management systems, including Icinga 2 which is – obviously – a personal interest. Other than that it’s also primarly Graylog for log management and putting it all together. As we certainly learnt from many places – APIs all over with enterprise intergration.
Time-series databases have been referenced in many of the talks before so it was really a pleasure listening to David Norton on InfluxDB finishing the first day of OSDC. 1.2 million series & 400k points/seconds sounds pretty impressive for the upcoming 0.9.0 release. And it can be directly hooked into third-party user interfaces such as Grafana which beats sort of Graphite Web vhost and other problems.


Right now we are preparing for the evening event at the Paulaner-“we can’t spell the rest, not important anyways” in Berlin – be sure to follow the #osdc twitter feed for some updates & pictures. If you can’t be here – save the date already for next year – 26.-28.4.2016 – and join us then 🙂 Or, as Nigel Kersten said – convince your boss 😉


Cheers!

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

Icinga-Configmanagement mit Puppet

Puppet ist sehr mächtig und so gut wie grenzenlos erweiterbar. Im Zusammenhang mit Icinga tritt dann früher oder später die Frage auf ob sich diese beiden “Welten” auch miteinander vereinen lassen. Die Antwort darauf ist kurz: “Ja!”.
Der Teufel steckt hier natürlich im Detail. Über die sog. Hauptresourcen bietet Puppet in der Standardinstallation bereits vielfältige Möglichkeiten zur Verwaltung von Monitoringlösungen an. So lassen sich schon mit “file”, “package”, “service” u.a. sehr viele Anwendungszwecke abdecken. Für das Konfigurationsmanagement von Icinga geht das mit zusätzlichen Resourcen wie z.B. “nagios_host” oder “nagios_service” aber noch durchaus eleganter, die Zauberformel heißt hier: Exported Resources.
Mit Exported Resources ist es unter Puppet möglich gesammelte Daten von bestimmten Nodes auf anderen Nodes auszugeben, also dort zu exportieren. Das bedeutet das definierte Daten von bestimmten Hosts, wie z.B. die IP-Adresse, durch den Puppetmaster in einer zentralen Datenbank (PuppetDB) gespeichert werden und auf anderen Hosts gesammelt weiterverarbeitet werden können.
Hier ein Beispiel eines Puppetcodes wie das Einsammeln von Daten zum Erstellen der Icinga-Hostkonfiguration aussehen könnte:

@@nagios_host { "$fqdn":
     ensure => "present",
     alias => "$hostname",
     address => "$ipaddress",
     max_check_attempts => "3",
     use => "generic-host",
}

Wenn einem Node diese exportierte Resource zugewiesen ist, werden die darin enthaltenen Variablen beim Puppetlauf durch hostspezifische Inhalte (sog. Facts) ersetzt und in der zentralen Datenbank des Puppetmasters abgespeichert. In diesem Fall sind das also Full Qualified Domain Name ($fqdn), Hostname ($hostname) und die primäre IP-Adresse ($ipaddress).
Der folgende Puppetcode sorgt dann dafür das die zuvor gesammelten Daten in einer gemeinsamen Konfigurationsdatei auf dem Icingamaster ausgegeben werden:

Nagios_host <<| |>>

Der Eintrag in der Konfigurationsdatei auf dem Icingamaster würde unter Verwendung des vorhergehenden Codes dann für einen Host nach dem Export beispielhaft so aussehen:

define host {
     host_name                      puppetclient01.localdomain
     address                        192.168.56.11
     use                            generic-host
     max_check_attempts             3
     alias                          puppetclient01
}

Natürlich können neben Hosts im Zusammenhang mit Icinga noch weitere Resourcen für Services, Kontakte, Kontaktgruppen, uvm. verwendet werden. Auch bieten die einzelnen Resourcen viele andere Parameter für das Feintuning an. Mit Puppet-Bordmitteln ist es außerdem möglich Berechtigungen und Abhängigkeiten zu steuern, sodass z.B. der Eintrag zum Laden der neuen Konfigurationsdatei in die “icinga.cfg” automatisch erfolgt und auch der Icinga-Dienst im Anschluss von alleine neu geladen wird.

Markus Waldmüller
Markus Waldmüller
Lead Senior Consultant

Markus war bereits mehrere Jahre als Sysadmin in Neumarkt i.d.OPf. und Regensburg tätig. Nach Technikerschule und Selbständigkeit ist er nun Anfang 2013 bei NETWAYS als Lead Senior Consultant gelandet. Wenn er nicht gerade die Welt bereist, ist der sportbegeisterte Neumarkter mit an Sicherheit grenzender Wahrscheinlichkeit auf dem Mountainbike oder am Baggersee zu finden.

Was ist DevOps und was nicht?

Natürlich sagt Euch der Begriff DevOps was, oder? Auf diesem Blog sind nur Profis, IT-Veteranen, Geeks, Nerds oder kurzum die besten Leser der Welt unterwegs. Somit gehe ich also davon aus, dass ihr das Wort DevOps schon mal mehrfach gehört habt und es grob einordnen könnt. Für alle anderen (Herzlich Willkommen) trotzdem ein paar Worte zum Hintergrund. Der Ursprung dieses aus Development und Operations zusammengesetzten und dann gekürzten Hauptworts liegt in Belgien. Neben EU-Richtlinien und erträglichem Bier wurde der Begriff durch die DevOpsDay 2009 in Ghent, genauer Patrick Debois, geprägt. Seitdem gibt es eine wachsende Gruppe von “Hardcore-Hackern”, welche die DevOps Kultur in alle Welt tragen.
Mit dem Wort Kultur ist bereits auch ganz gut beschrieben, was DevOps ist bzw. sein könnte. Dem ein oder anderen Produktmanager und Business-Developer wird es jetzt eiskalt den Rücken runterlaufen. Kein Tool, kein Standard, keine Zertifizierung -> Da kann ich doch zum Quartalsende gar kein Lizenzbundle draus machen. Nun Freunde, ich arbeite lange genug in der IT um Tools dieser Art trotzdem vorauszusagen und vielleicht steht der Oracle DevOps Developer oder Borland DevOps Builder ja schon in den Startlöchern und wird zur nächsten CeBIT 2013 released.
Kommt schon Jungs!
Eigentlich, zumindest verstehe ich es so, ist DevOps nur der Versuch mit dem Kastendenken innerhalb der IT, aber auch innerhalb eines Teams aufzuräumen. Die Knackpunkte sind hier sowohl in der Zusammenarbeit, als auch in den grundsätzlichen Entscheidungsfindungsprozessen.
Das Hin-und-her zwischen Entwicklung und Betrieb ist nicht selten ein etablierter Bestandteil des täglichen Miteinanders in großen IT-Bereichen. Ob nun die Entwickler nicht sauber dokumentiert haben oder der Betrieb einfach nur unfähig ist, die Software zu installieren, lässt dabei meist nicht final klären, sicher ist nur das mehr Energie in Schuldzuweisungen verpufft, als in der Lösungssuche. Hat man vor einigen Jahren noch im Wasserfall-Prinzip und großen Iterationszyklen entwickelt, so geht es heute fast täglich heiß her. Die Anforderungen an eine schnelle und gute Zusammenarbeit zwischen Betrieb und Entwicklung sind daher elementar und vermutlich auch einer der Hauptgründe der DevOps-Bewegung. Konnte man sich früher nach einem unglücklichen Release noch einige Wochen in der Kantine aus dem Weg gehen, steht der Entwickler heute am nächsten Tag schon wieder vor der Tür und will einen Fix einspielen. An das “Schau mal, die Trottel von der Entwicklung” kann ich mich übrigens noch wahrhaftig erinnern, jedoch ist es schon fast 15 Jahre her.
Diese Barriere zu brechen, und das ist wahrlich eine schwierige Herausforderung, wäre eine der größten Leistungen, die DevOps erbringen könnte. Und keine Angst, vielleicht sitzt man hier und dort schon nebeneinander, hat den Admin mit Ruby-Fähigkeiten ins Dev-Team integriert und installiert zusammen das neueste Release. Dann, auch wenn es nicht so genannt wird, seid ihr vielleicht schon Ultra-DevOps!
Was brauch ich und wie geht’s?
Wer bis zu diesem Absatz vorgedrungen ist, hat auf jeden Fall Geduld mitgebracht und vermutlich ist schon lange klar, dass die Frage nach dem “Was brauch ich und wie geht’s?” nicht allgemein beantwortet werden kann. Neben der Bereitschaft, Fehler zu machen und den Möglichkeiten, diese auch schnell zu beheben, gibt es jedoch einige Tools, die es einfacher machen mit schnellen Releasezyklen, vielen Abhängigkeiten und utopischen Anforderungen aus dem Produktmanagement umzugehen. Dies fängt bei Continuous Integration mit bspw. Jenkins an. Nur nur durch permanente Qualitätskontrolle und Review der durchgeführten Änderungen können Fehler auch langfristig zurückverfolgt und im Idealfall vor dem Release identifiziert und beseitigt werden. Darauf aufbauend empfiehlt sich auf jeden Fall ein methodischer Prozess der automatischen Softwareverteilung und Installation mit Puppet, Chef oder CFEngine. Ein ordentlich beschriebener Konfigurationsprozess ist hinzu schon die halbe Doku. Das sind nur ein paar Beispiele und die Tools, die das Leben leichter machen, werden täglich mehr. Leider sind sie dank der Faulheit mancher Entwickler nur durch stundenlanges Rumsuchen auf GitHub zu finden. Arghh, jetzt kommen meine Operations-Wurzeln wieder durch.
Wenn ich es nicht überwachen kann, dann existiert es nicht!

Ein ganz wichtiger Teil der DevOps-Kultur ist aus meiner Sicht das Treffen von Entscheidung auf Basis von Messwerten. Ob die verwendeten Werte hierbei aus traditionellen Tools wie Icinga und Nagios oder neueren Trends wie collectd, logstash, Graylog oder später zur Darstellung Graphite kommen, spielt dafür keine Rolle. Entscheidend ist eben die Arbeit auf Basis von Fehlern, Erkenntnissen und Messwerten und nicht auf Basis von HIPPO*-Decisions.  Dies ist nicht immer einfach, und wenn ein Vorschlag mit der Antwort “Proof it” in Frage gestellt wird, vielleicht auch aufwändig. Am Ende werden regelmäßige Iteration und der ehrliche Umgang miteinander jedoch fast automatisch zum besten Ergebnis führen. Und mal ehrlich, wenn wir ITler nicht in der Lage sind, unsere Entscheidungen auf Basis von Messwerten zu treffen, wer soll es sonst schaffen. Jeder Controller und Unternehmensprüfer, der wochenlang Zahlen aus Ordnern akribisch in Excel-Listen überführen muss, würde sich zwei Finger abhacken, wenn ihm alle Informationen digitalisiert zur Verfügung gestellt würden. Wir sind nur häufig einfach zu faul, was daraus zu machen. An den möglichen Stellen konfigurieren und tunen wir dann so lange ohne Zwischenmessung rum, bis es letztendlich besser läuft als am Anfang. Warum weiß dann eben auch keiner und die Reproduzierbarkeit ist fast unmöglich.
Um was geht es eigentlich?
Man sollte ja eigentlich glauben, dass “To-Be-Online” die übergeordnete Motivation der täglichen Arbeit ist. Kurz also den oder die Services für interne und/oder externe Kunden zur Verfügung zu stellen und damit die Wertschöpfungskette aufrecht zu  erhalten. Kurz gesagt: Womit verdienen wir eigentlich unser Geld. Diese Betrachtung kommt ihm Dickicht der Schuldzuweisungen und bei heissen Diskussionen häufig zu kurz. Kann man seine internen Leitlinien jedoch dem Grundsatz “Service First” unterstellen, verschwinden die unüberwindbaren Grenzen zwischen Development und Operations. Das gemeinsame Ziel der Verfügbarkeit macht es leichter und der ggf. notwendige Rollback geht zusammen mit dem zuständigen Developer mit Sicherheit leichter von der Hand. Die Verantwortung für das Produkt X motiviert dabei auch um Längen mehr, als die Bereitstellung eines WAR-Files in irgendeinem einem Tomcat oder JBoss.
Mein Fazit
Zusammengefasst ist DevOps für mich:

  • Offenheit: Jeder, der kann, darf auch, aber bitte mit Hirn.
  • Automatisierung: Voraussetzung für schnelle reproduzierbare Arbeit mit Korrekturmöglichkeit
  • Entscheidungsklarheit: “Trial and Error” und das auf  Basis von messbaren Informationen
  • Produktsicht: Funktionsfähigkeit kommt vor technischen Unzulänglichkeiten
Dabei sollte an dieser Stelle aber auch nicht unerwähnt bleiben, was DevOps für mich nicht ist:
  • Maßnahmenkatalog: Ich erwarte mit Sorge das erste Zertifizierungsprogramm
  • Stellenbeschreibung: Versucht nicht den Senior DevOps Manager einzustellen
  • Consulting-Packet: Das DevOps Paket für den Mittelstand – Bitte nicht!
Mit zunehmender Popularität wachsen die Misshandlungen an einst nicht kommerziellen Ideen. Es wird nicht so einschlagen wie die CLOUD, aber man wird sich kreativ damit auseinandersetzen und Ideen dazu entwickeln. Der gegenseitige Erfahrungsaustausch und die Bereitschaft Neues zu versuchen sollte genügen um sich einiger Ideen der DevOps Bewegung zu bedienen. Wer dann trotzdem noch Consulting braucht, der kommt dann natürlich zu uns 🙂

* Highest Paid Person Opinion (DANKE KRIS)
(Monitoring-Picture von Noah Sussmann)

Bernd Erk
Bernd Erk
CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startet er das wöchentliche Lexware-Backup und investiert seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinem Sohn.

Updian 0.4

Wir haben ja schon oft über Updian berichet (hier und da). Und seit Ende Juni gibt es wieder etwas neues von RobHost. Zu dem bisherigen Inhalt gibt es an sich nur kleinere Bugfixes, welche nun auch im Github mit verfolgt werden können.
Aber eine der wohl großen Änderungen ist der anfängliche Support von ‘yum’ gestützten Systemen wie CentOS. Nun können also auch Administratoren solcher Systeme auf ein schlichtes und zentralen Update-Tool zugreifen.
Sind wir mal gespannt, was sich dann noch so in der Zukunft ergibt.

Neues von AutoHotkey, V2 und AutoHotkey_L

Wir hatten AutoHotkey ja schon einmal vorgestellt und die reine Grundversion ist seit 2009 stable und wird nicht mehr weiter gepflegt. Es gibt aber in den Projekten wie AutoHotkey_L, welches von Lexikos verwaltet wird oder mit AutoHotkey V2 Anpassungen, welche aufeinander aufbauen und die Bedienbarkeit, sowie die Funktionalität erweitern und verbessern sollen.

AutoHotkey_L bildet dabei die Grundversion und die neue V2 ist ein Fork dessen. Zu beachten ist aber, dass die V2 zur Verbesserung auf die Abwärtskompatibilität verzichtet und derzeit noch im Alphastatus ist.  Man kann also noch gespannt sein, wie es hier weiter geht. Aber die Funktionalität ist auf jeden Fall schon weit über die reine Automatisierung hinweg.

Zus. kann/muss man aber auch die Arbeit in der Community und der Dokumentation loben. Hier wurden die Hilfen und Tutorials sehr überarbeitet und auch in viele Sprachen zur Verfügung gestellt. Das ganze macht die Nutzung und Einarbeitung leichter.