Masiar Ighani

mighani

Dipl. Informatiker, CEO skillbyte GmbH Java Enterprise Entwickler und Architekt, DevSecOps, DevOps mit Kubernetes und OpenShift, Trainer und Coach https://www.gravitycv.com, https://www.masiar-ighani.de

Digitale Transformation: Microservices – Teil 2

In dem letzen Artikel in dieser Serie haben wir festgestellt, dass es bei der digitalen Transformation im Grunde darum geht Hypothesen aufzustellen, die es zu validieren gilt. Wir brauchen Experimente, die wir für echte Nutzer / Kunden ausrollen und beobachten was die Zielgruppe mit unserer Hypothese anstellt. Aus den Erkenntnissen stellen wir neue Hypothesen auf usw. Das Ziel ist ein Endprodukt welches der Kunde maßgeblich mit beeinflusst hat. Der beste Weg ist also echte Kunden zu nehmen.

An die IT stellt dies besondere Herausforderungen, denn wir müssen in der Lage sein Software schnell in Produktion zu bringen. Lange Release Zyklen sind hier kontraproduktiv. Die meisten Leser werden aber genau diese Probleme kennen. Es dauert zu lange neue Anforderungen umzusetzen und zu releasen. Hat man dann die neuen Features endlich online schlagen andere Dinge fehl, die vorher funktioniert haben. Microservice Architekturen, automatisierte Tests, Container, continuous integration und continuous delivery sind Mechanismen, die uns helfen diesen Prozess agil zu gestalten. Alles weitere Bausteine der digitalen Transformation.

Masiar IghaniDigitale Transformation: Microservices – Teil 2
Mehr

Scrum Wahnsinn – was digitale Transformation wirklich bedeutet – Teil 1

Bei der XYZ GmbH kann kein Projekt starten bevor ein Budget festgelegt worden ist. Bevor die Entwicklung des Projektes starten kann kommen die Business Stakeholder zusammen und legen die Top Prioritäten fest. Es gibt wochenlang wenn nicht monatelang Meetings, Powerpoint Slides mit geschätzten Kosten und ROI Zahlen, um das Projekt zu rechtfertigen und zu belegen warum das Projekt wichtig ist und warum gerade die gewählte Vorgehensweise die bestmögliche für XYZ GmbH ist. Die hohen Kosten und lange Lieferzeiten resultieren meist aus der Menge an Features welches das Projekt alles liefern soll. 

Wenn die Entscheidung einmal gefallen ist legen dann Business Analysten, Designer und Requirement Engineers los, um eine lange Liste an Anforderungen zusammen zu schreiben. Dies dauert Monate bevor die Anforderungen an die Entwicklung zur Umsetzung gehen. In dieser Phase finden Umpriorisierungen statt, Qualitätstests werden definiert und das Ganze für die Produktion optimiert vorbereitet. Am Ende ist das Projekt weder in-time noch in-budget.

Masiar IghaniScrum Wahnsinn – was digitale Transformation wirklich bedeutet – Teil 1
Mehr

Kubernetes und OpenShift Security 1 – Attack Surface

Kubernetes ist ein komplexes Gebilde aus vielen beweglichen Teilen. es ist hinter Linux das aktivste Projekt auf Github. Das Ökosystem mit 3rd Party Produkten, Plugins, Erweiterungen, Anbietern ist gewaltig. Hinzu kommt, dass selbst die Core features ständigen Änderungen unterworfen sind. Das sieht man allein an den API Versionen und Gruppen wie v1alpha1, v2beta3 usw. Leider erwächst aus dieser Komplexität eine gewisse Gefahr was das Thema Security angeht. Man ist froh, dass der Cluster aufgesetzt ist und funktioniert und die Entwickler schon erste Pods deployen und arbeiten können. Doch aus meiner Sicht ist das ein Problem. Denn ist der Cluster einmal aufgesetzt und im Betrieb, sind gewisse Änderungen nicht mehr oder sehr aufwändig zu bewerkstelligen. Komplexität ist kein Grund oder Entschuldigung die Security zu vernachlässigen. Und ich kann versichern, dass das Thema Security an sich ein komplexes Thema innerhalb des Kubernetes (und auch OpenShift) Universums ist. Von daher möchte ich eine Security Artikel Reihe starten die die verschiedenen Angriffs Vektoren und Security Maßnahmen beleuchtet.

Masiar IghaniKubernetes und OpenShift Security 1 – Attack Surface
Mehr

Container OS Vergleich

Seit dem Aufstieg der Container-Community in den letzten drei Jahren sind viele Unternehmen und Projekte entstanden, die wirklich innovative Wege zur Verwaltung von Anwendungen bieten.

Es gibt mehrere Projekte rund um das Thema Management, Netzwerk, Speicherung, Protokollierung, Überwachung und mehr (siehe diese Mind Map des Ökosystems). Die Container-Betriebssysteme spielen in diesem Ökosystem eine besonders wichtige Rolle.

In allen Unternehmen wo ich bisher als Berater unterwegs war gab es eine Frage die sich alle Entwickler stellten: Welches ist das beste Betriebssystem, um Container zu betreiben? Ein komplettes Linux? CoreOS? Was ist mit RedHat? Ich habe auch von etwas namens RancherOS gehört? Und diese ganzen „Atomic“ Systeme?

Masiar IghaniContainer OS Vergleich
Mehr

OpenShift 4 – Neue Features

Das OpenShift 4 Release steht vor der Tür. Zeit die neuen Features zu beleuchten. In diesem Artikel gibt es einen Überblick/Ausblick der neuen Features. In weiteren Artikeln behandeln wir dann die jeweiligen Features etwas genauer.

CoreOS

Das wichtigste zuerst: Wie vielleicht alle interessierten mitbekommen haben hat RedHat die Firma CoreOS übernommen. CoreOS hat einige sehr wichtige Produkte mit ins Boot gebracht, die konsequent von RedHat in OpenShift integriert werden. Im speziellen sind das CoreOS als Container Betriebssystem, Tectonic (die Kubernetes Plattform von CoreOS) und Quay als Container Registry. Alle Drei Produkte werden in OpenShift 4.0 integriert und lösen teilweise OpenShift eigene Konstrukte ab, wie z.B. die Registry. Das Operator Framework war schon in OpenShift 3.11 am Start (hierzu auch später ein Artikel).

Installer

OpenShift 4.0 kommt mit einem Installer, der die Installation in ausgesuchten Clouds wesentlich vereinfachen soll. In der Version 4.0 unterstützt der Installer nur AWS (und on-prem) und übernimmt auch die Infrastruktur Provisionierung eines Best Practice OpenShift Clusters. Ab 4.2 werden auch GKE und Azure unterstützt. Ab 4.1 kann man auch OpenShift auf selbstprovisionierten Infrastrukturen installieren (VmWare, AWS und BareMetal). OpenStack Unterstützung kommt ab 4.3.

Masiar IghaniOpenShift 4 – Neue Features
Mehr

Services und Ingress in Kubernetes und OpenShift 2/2

Im letzten Artikel sind wir die Grundlagen von Services durchgegangen. Diese sind bei Kubernetes und OpenShift gleich. Bei Ingress kommen einige Unterschiede zum Vorschein, aber nur in der Implementierung und bei den verwendeten Tools. Es soll aber das Gleiche erreicht werden.

Was ist Ingress?

Wie wir gesehen haben ist es unpraktisch jeden Service einzeln nach aussen bekannt zu machen. Bei Hunderten von Diensten, die im Cluster laufen sollen und auch von aussen erreichbar sein sollen, muss ein anderer Mechanismus her. Mit Ingress ist allgemein eingehender Traffic ins Cluster gemeint. Man braucht einen Ingress Controller, welches den Entrypoint ins Cluster darstellt und einzelne Ingress Api Objekte , welche beschreiben wie mit dem Traffic umzugehen ist, z.B.: SSL Offload Ja/Nein, zu welchem internen Service soll weitergeleitet werden, etc. Das Konzept klingt bestimmt vertraut. Man denke an Apache oder Nginx als Webserver und einzelne Vhosts als Konfiguration.

Masiar IghaniServices und Ingress in Kubernetes und OpenShift 2/2
Mehr

Services und Ingress in Kubernetes und OpenShift 1/2

Dieser Artikel beschreibt die grundsätzlichen Möglichkeiten eine Anwendung / einen Service welches im Cluster läuft nach aussen verfügbar zu machen. „Aussen“ heisst dabei, dass ein Client / Webbrowser den Service aufrufen kann. Dabei betrachten wir die Möglichkeiten die Kubernetes und OpenShift bieten.

Ein Pod im Cluster erhält eine interne IP, welche nur im Cluster gültig ist. In dem Beispiel Bild kann Pod A mit Pod B kommunizieren und umgekehrt, aber von aussen kommt man so ohne weiteres an die Pods nicht dran.

Masiar IghaniServices und Ingress in Kubernetes und OpenShift 1/2
Mehr

Java Heap Settings in Docker Containern

Entwicklern sollte bewusst sein, dass sich Java Prozesse in Docker Containern anders verhalten als wenn sie direkt auf einem Host ausgeführt werden. Wenn wir z.B. eine Anwendung mit java -jar mypplication-fat.jar” starten, dann passt die JVM einige Parameter selbständig an, um die bestmögliche Performance zu gewährleisten.

Man neigt dazu zu denken, dass Container genau wie virtuelle Maschinen sind, wo wir eine Reihe von virtuellen CPUs und virtuellen Speicher vollständig definieren können. Container sind eher ein Isolationsmechanismus, bei denen die Ressourcen (CPU, Speicher, Dateisystem, Netzwerk, etc.) für Prozesse voneinander getrennt sind. Diese Isolation wird durch eine Linux-Kernelfunktion namens cgroups ermöglicht. Einige Anwendungen, die Informationen aus der Ausführungsumgebung benutzen, wurden jedoch vor der Existenz von cgroups implementiert. Tools wie ‚top‘, ‚free‘, ‚ps‘, und selbst die JVM ist nicht dafür optimiert, innerhalb eines Containers einen stark eingeschränkten Linux-Prozess auszuführen. Schauen wir uns das mal an.

Masiar IghaniJava Heap Settings in Docker Containern
Mehr

ServiceAccount und 3 Secrets

Beim Anlegen eines neuen ServiceAccounts fällt vielleicht auf, dass OpenShift Drei Secret Objekte anlegt. Nachfolgend beschreibe ich die Funktion dieser drei secrets:


Masiar IghaniServiceAccount und 3 Secrets
Mehr

OpenShift Deployment Szenarien

Aus welchen Komponenten besteht eine OpenShift Installation und was sind die gängigen Szenarien für die Verteilung dieser Komponenten in einer hochverfügbaren Umgebung.
OpenShift hat drei wesentliche Komponenten: ein oder mehrere Master, ein oder mehrere Etcd Instanzen und ein oder mehrere Nodes. Das „mehrere“ bezieht sich auf eine Installation in einer produktiven Umgebung wo es um eine hochverfügbare Lösung geht. Der Master ist das „Gehirn“ und übernimmt sämtliche Management Aufgaben des Clusters. Etcd ist ein verteilter key-value store, welches den Cluster Status und Konfiguration persistiert (aktuelle nodes, Secrets, Imagestreams, usw.). Die Nodes verrichten die eigentliche Arbeit. Der Master entscheidet was zu tun ist und welcher Node welchen Container bekommt.

Masiar IghaniOpenShift Deployment Szenarien
Mehr