Rechenzentrum in Deutschland

Die BDE-SYSTEMHAUS GmbH hat eine eigene BDE-Cloud-Infrastruktur entwickelt, die wir selbst betreiben. Statt vorgefertigte Services der großen Cloud-Anbieter zu mieten, die als „Blackbox“ arbeiten, sind wir einen eigenen Weg gegangen. So vermeiden wir die Abhängigkeit von einem einzelnen Anbieter und halten unsere Kernkompetenz im eigenen Unternehmen.

Wir haben unsere Software JUMBO auf Basis der Docker Linux-Container-Technologie entwickelt. Unsere BDE-Software JUMBO wird in mehreren, miteinander vernetzen Docker-Containern als moderne Microservice-Architektur betrieben. Die Bereitstellung der Software erfolgt über einen Continuous-Integration-Prozess, den wir ebenfalls selbst entwickelt und auf eigenen Servern implementiert haben.

Auf diese Weise wird sowohl unser JUMBO-Cloud-Service im Hetzner Datacenter-Park Falkenstein mit Software-Updates versorgt, als auch unsere Instanzen in Kunden-Clouds oder bei On-Premises Installationen vor Ort gewartet.

Durch die verwendete Technologie ist es möglich, auf Wunsch einen redundanten Betrieb sicherzustellen. So könnte man einen Parallelbetrieb von JUMBO-Cloud-Service und On-Premises Installation realisieren, um die Vorteile von standortübergreifendem Datenzugriff und lokalem Backup zu vereinen.

Eine weitere herausragende Möglichkeit durch unsere Container-Technologie ist ein skalierbarer Betrieb. Es ist möglich bei entsprechend großen Datenmengen (Big Data) die Software auf mehreren Servern gleichzeitig laufen zu lassen, um diese Datenmengen händeln zu können (Cloud Ready).

Unsere JUMBO-Container können sich in jedem Rechenzentrum, in jeder Cloud und auf jedem Server „einmieten“.

Hetzner Datacenter-Park
Hetzner Datacenter-Park
Container-Technologie
Container-Technologie
Betriebssystem Linux
Betriebssystem Linux

Definitionen ... 1. Docker 2.Linux 3. Microservice 4. Continous Intergation ... nach Wikipedia (DE)

1. Docker (Software)

 
Docker (container engine) logo.svg
Basisdaten
EntwicklerDocker, Inc.
Erscheinungsjahr13. März 2013[1]
Aktuelle Version20.10.11[2][3] (18. November 2021)
BetriebssystemLinux[4], Microsoft Windows[5], macOS[6], Unix-ähnliches System
ProgrammierspracheGo
KategorieSandboxing
LizenzApache-Lizenz, Version 2.0[7][8], proprietäre Lizenz
www.docker.com

Docker ist eine Freie Software zur Isolierung von Anwendungen mit Hilfe von Containervirtualisierung.

Docker vereinfacht die Bereitstellung von Anwendungen, weil sich Container, die alle nötigen Pakete enthalten, leicht als Dateien transportieren und installieren lassen. Container gewährleisten die Trennung und Verwaltung der auf einem Rechner genutzten Ressourcen. Das umfasst laut Aussage der Entwickler: Code, Laufzeitmodul, Systemwerkzeuge, Systembibliotheken – alles was auf einem Rechner installiert werden kann.[9]

Grundlagen

 

Docker kann verschiedene Schnittstellen verwenden, um auf Virtualisierungsfunktionen des Linux-Kernels zuzugreifen.

Docker basiert auf Linux-Techniken wie Cgroups und Namespaces, um Container zu realisieren. Während anfänglich noch die LXC-Schnittstelle des Linux-Kernels verwendet wurde, haben die Docker-Entwickler mittlerweile eine eigene Programmierschnittstelle namens libcontainer entwickelt, die auch anderen Projekten zur Verfügung steht. Als Speicher-Backend verwendet Docker das Overlay-Dateisystem aufs, ab Version 0.8 unterstützt die Software aber auch btrfs.[10]

Prinzipiell ist Docker auf die Virtualisierung mit Linux ausgerichtet. Docker kann allerdings auch mittels Hyper-V (Standard)[11] oder VirtualBox auf Windows und HyperKit[12] oder VirtualBox auf macOS verwendet werden. Da die Ressourcentrennung alleine mit den Docker zugrunde liegenden Techniken wie Namespaces und Cgroups nicht völlig sicher ist, hat das Unternehmen Red Hat Unterstützung für die sicherheitsrelevante Kernel-Erweiterung SELinux implementiert, welche die Container auf der Ebene des Host-Systems zusätzlich absichert.[13]

Begriffe

Image
ein Speicherabbild eines Containers. Das Image selbst besteht aus mehreren Layern, die schreibgeschützt sind und somit nicht verändert werden können. Ein Image ist portabel, kann in Repositories gespeichert und mit anderen Nutzern geteilt werden. Aus einem Image können immer mehrere Container gestartet werden.
Container
als Container wird die aktive Instanz eines Images bezeichnet. Der Container wird also gerade ausgeführt und ist beschäftigt. Sobald der Container kein Programm ausführt oder mit seinem Auftrag fertig ist, wird der Container automatisch beendet.
Layer
ein Layer ist Teil eines Images und enthält einen Befehl oder eine Datei, die dem Image hinzugefügt wurde. Anhand der Layer kann die ganze Historie des Images nachvollzogen werden.
Dockerfile
eine Textdatei, die mit verschiedenen Befehlen ein Image beschreibt. Diese werden bei der Ausführung abgearbeitet und für jeden Befehl wird ein einzelner Layer angelegt.
Repository
ein Repository ist ein Satz gleichnamiger Images mit verschiedenen Tags, zumeist Versionen.
Registry
eine Registry, wie zum Beispiel Docker Hub oder Artifactory, dient der Verwaltung von Repositories.
libcontainer
eine Schnittstelle zu den Grundfunktionen von Docker.
libswarm
eine Schnittstelle, um Docker-Container zu steuern.
libchan[14]
ermöglicht eine einfache („light weighted“) Kommunikation zwischen Prozessteilen und Prozessen.

 

[…]

 

Funktionen

Neben der grundsätzlichen Funktionalität, Container mit virtuellen Betriebssystemen zu erstellen, bietet Docker noch weitere Werkzeuge, um die Arbeit mit Containern zu vereinfachen.

Docker Hub

Docker Hub ist ein Onlinedienst, der eine Registry für Docker-Images und Repositories beinhaltet. Die Registry teilt sich in einen öffentlichen und einen privaten Teil auf. Im öffentlichen Teil kann jeder Nutzer seine selbst erstellten Images hochladen und damit anderen Nutzern zur Verfügung stellen. Außerdem gibt es mittlerweile offizielle Images, z. B. von Linux-Distributoren. Im privaten Teil von Docker Hub können Benutzer ihre Docker-Images hochladen und dadurch einfach z. B. firmenintern verteilen, ohne dass diese damit öffentlich auffindbar sind.[27]

Die Registry-Software wurde von Docker Inc. als Open-Source-Software veröffentlicht, sodass man die Vorteile dieser nun auch nutzen kann, ohne die eigenen Images auf die Server von Docker laden zu müssen.[28]

Mittels von Docker bereitgestellter APIs lassen sich Images auch automatisch aus Repositories von GitHub oder Bitbucket erstellen.[29]

Missbrauch von Docker-Images

Im Sommer 2018 wurde bekannt, dass es Unbekannten gelungen war, Docker-Container mit einer Hintertür zu versehen, die es ihnen ermöglichte, die Kryptowährung Monero zu schürfen. Die 17 infizierten Pakete wurden alle vom Benutzer docker123321 hochgeladen und insgesamt 5 Millionen Mal heruntergeladen. Insgesamt wurden so von den Nutzern 58.000 Euro geschürft.[30]

Erste Meldungen von infizierten Images gab es bereits im Juli 2017,[31] jedoch gab es von Seiten des Docker Hubs keine Reaktion und die Images wurden erst entfernt, als die Sicherheitsfirma Kromtech einen Bericht dazu veröffentlichte.[32]

Im Sommer 2020 wurde ein weiterer Fall bekannt, bei dem Unbekannte infizierte Pakete hochluden. Diese wurden 2 Millionen Mal heruntergeladen und es wurden etwa 36.000 US-Dollar der Kryptowährung Monero geschürft.[33]

Datenleck

Wie am 27. April 2019 bekannt wurde, sollen Unbekannte Zugriff auf eine interne Datenbank des Dockerhubs mit vertraulichen Informationen gehabt haben. Betroffen seien rund 190.000 Konten. Neben Usernamen und gehashten Passwörtern waren unter den betroffenen Daten auch Github- und Bitbucket-Tokens für Autobuilds, diese seien bei betroffenen Usern zurückgezogen worden.[34]

Versionsverwaltung

Docker bietet eine eingebaute Versionsverwaltung. Diese erlaubt es, den aktuellen Stand des Containers in ein Image zu sichern, dieses auf das Docker Hub zu laden, die Unterschiede zwischen dem aktuellen Zustand des Containers und dem ursprünglichen Image sowie die sehr grobe Historie eines Images anzuzeigen.[35] Ein Image selbst wird in Schichten eingeteilt, die als Layer bezeichnet werden. Jeder Layer beschreibt einen Unterschied zu dem vorherigen Layer und zeigt so, welche Programme oder Daten in dem Image hinzugefügt oder entfernt wurden.[36] Die einzelnen Layer sind schreibgeschützt und können nicht manipuliert werden. Der Container selbst schreibt in einem Writeable-Layer und ermöglicht es, dass mehrere Container auf einem Image basieren und sich lediglich der Writeable-Layer unterscheidet.

Auch wenn diese Versionsverwaltung von der Syntax her an Git angelehnt ist und auch mit diesem verglichen wird, unterscheidet sie sich stark von ihrem Vorbild.

 

Sicherheitsaspekte

Docker-Container werden durch einen Daemon erzeugt, der in der Vergangenheit zwingend root-Rechte haben musste, ab Version 19.03[37] unter bestimmten Umständen aber auch unprivilegiert sein kann. Läuft der Daemon mit root-Rechten, bedient man sich oft einer eigenen Nutzergruppe, um auch unprivilegierten Nutzern die Erzeugung neuer Docker-Container zu erlauben.[38] Ein möglicher Fallstrick besteht darin, dass alle unprivilegierten Nutzer, die Mitglied einer solchen Nutzergruppe sind, indirekt über volle root-Rechte auf dem Host-System verfügen.[39][40]

Im Unterschied zu einer Virtuellen Maschine teilen sich Container und Host einen gemeinsamen Betriebssystem-Kernel. Dies verbessert einerseits die Leistung erheblich, vergrößert andererseits aber auch das Risiko, dass erfolgreiche Angriffe gegen den Kernel auch den Host kompromittieren.

Bei richtiger Konfiguration sind selbst root-Rechte innerhalb eines Docker-Containers nicht dazu geeignet, um den Host anzugreifen. Insbesondere sollte dazu ein neuer User Namespace erzeugt und der root-Benutzer des Containers auf einen unprivilegierten Benutzer des Hosts abgebildet werden.[41]

 

Siehe auch

 

Weblinks

 

2. Linux

Tux, der Linux-Pinguin

Als Linux (deutsch [ˈliːnʊks] anhören?/i) oder GNU/Linux (siehe GNU/Linux-Namensstreit) bezeichnet man in der Regel freie, unixähnliche Mehrbenutzer–Betriebssysteme, die auf dem Linux-Kernel und wesentlich auf GNU-Software basieren. Die weite, auch kommerzielle Verbreitung wurde ab 1992 durch die Lizenzierung des Linux-Kernels unter der freien Lizenz GPL ermöglicht. Einer der Initiatoren von Linux war der finnische Programmierer Linus Torvalds. Er nimmt bis heute eine koordinierende Rolle bei der Weiterentwicklung des Linux-Kernels ein und wird auch als Benevolent Dictator for Life (deutsch wohlwollender Diktator auf Lebenszeit) bezeichnet.

Das modular aufgebaute Betriebssystem wird von Softwareentwicklern auf der ganzen Welt weiterentwickelt, die an den verschiedenen Projekten mitarbeiten. An der Entwicklung sind Unternehmen, Non-Profit-Organisationen und viele Freiwillige beteiligt. Beim Gebrauch auf Computern kommen meist sogenannte Linux-Distributionen zum Einsatz. Eine Distribution fasst den Linux-Kernel mit verschiedener Software zu einem Betriebssystem zusammen, das für die Endnutzung geeignet ist. Dabei passen viele Distributoren und versierte Benutzer den Kernel an ihre eigenen Zwecke an.

Linux wird vielfältig und umfassend eingesetzt, beispielsweise auf Arbeitsplatzrechnern, Servern, Mobiltelefonen, Routern,[2] Notebooks, Embedded Systems, Multimedia-Endgeräten und Supercomputern.[3] Dabei wird Linux unterschiedlich häufig genutzt: So ist Linux im Server-Markt wie auch im mobilen Bereich eine feste Größe, während es auf dem Desktop und Laptops eine noch geringe, aber wachsende Rolle spielt. Im Januar 2022 war es in Deutschland auf 4,19 % der Systeme installiert.[4]

Linux wird von zahlreichen Nutzern verwendet, darunter private Nutzer, Regierungen, Organisationen und Unternehmen.[5][6]

Geschichte

 
[…]
 

Der Kernel

Struktur des Linux-Kernels im Detail

 
Technik

Die Bezeichnung Linux wurde von Linus Torvalds anfänglich nur für den Kernel genutzt, dieser stellt der Software eine Schnittstelle zur Verfügung, mit der sie auf die Hardware zugreifen kann, ohne sie genauer zu kennen. Der Linux-Kernel ist ein in der Programmiersprache C geschriebener monolithischer Kernel, wobei einige GNU-C Erweiterungen benutzt werden. Wichtige Teilroutinen sowie zeitkritische Module sind jedoch in prozessorspezifischer Assemblersprache programmiert. Der Kernel ermöglicht es, nur die für die jeweilige Hardware nötigen Treiber zu laden. Weiterhin übernimmt der Kernel auch die Zuweisung von Prozessorzeit und Ressourcen zu den einzelnen Programmen, die auf ihm gestartet werden. Bei den einzelnen technischen Vorgängen orientiert sich das Design von Linux stark an seinem Vorbild Unix.

Der Linux-Kernel wurde zwischenzeitlich auf eine sehr große Anzahl von Hardware-Architekturen portiert. Das Repertoire reicht von eher exotischen Betriebsumgebungen wie dem iPAQ–Handheld-Computer, Navigationsgeräten von TomTom oder gar Digitalkameras bis hin zu Großrechnern wie IBMs System z und neuerdings auch Mobiltelefonen wie dem Motorola A780 sowie Smartphones mit Betriebssystemen wie Android oder Sailfish OS auf dem Jolla. Trotz Modulkonzept blieb die monolithische Grundarchitektur erhalten. Die Orientierung der Urversion auf die verbreiteten x86–PCs führte früh dazu, verschiedenste Hardware effizient zu unterstützen und die Bereitstellung von Treibern auch unerfahrenen Programmierern zu ermöglichen. Die hervorgebrachten Grundstrukturen beflügelten die Verbreitung.

Kernel-Versionen

Auf kernel.org werden alle Kernel-Versionen archiviert. Die dort zu findende Version ist der jeweilige Referenzkernel. Auf diesem bauen die sogenannten Distributionskernel auf, die von den einzelnen Linux-Distributionen um weitere Funktionen ergänzt werden. Eine Besonderheit stellt dabei das aus vier Zahlen bestehende und durch Punkte getrennte Versionsnummernschema dar, z. B. 2.6.14.1. Es gibt Auskunft über die exakte Version und damit auch über die Fähigkeiten des entsprechenden Kernels. Von den vier Zahlen wird die letzte für Fehlerbehebungen und Bereinigungen geändert, nicht aber für neue Funktionen oder tiefgreifende Änderungen. Aus diesem Grund wird sie auch nur selten mit angegeben, wenn man beispielsweise Kernel-Versionen vergleicht. Die vorletzte, dritte Zahl wird geändert, wenn neue Fähigkeiten oder Funktionen hinzugefügt werden. Gleiches gilt für die ersten beiden Zahlen, bei diesen müssen die Änderungen und neuen Funktionen jedoch drastischer ausfallen. Ab Version 3.0 (August 2011) wird auf die zweite Stelle verzichtet.

Entwicklungsprozess

Die Entwicklung von Linux liegt durch die GPL und durch ein sehr offenes Entwicklungsmodell nicht in der Hand von Einzelpersonen, Konzernen oder Ländern, sondern in der Hand einer weltweiten Gemeinschaft vieler Programmierer, die sich in erster Linie über das Internet austauschen. In vielen E-Mail-Listen, aber auch in Foren und im Usenet besteht für jedermann die Möglichkeit, die Diskussionen über den Kernel zu verfolgen, sich daran zu beteiligen und auch aktiv Beiträge zur Entwicklung zu leisten. Durch diese unkomplizierte Vorgehensweise ist eine schnelle und stetige Entwicklung gewährleistet, die auch die Möglichkeit mit sich bringt, dass jeder dem Kernel Fähigkeiten zukommen lassen kann, die er benötigt. Eingegrenzt wird dies nur durch die Kontrolle von Linus Torvalds und einigen speziell ausgesuchten Programmierern, die das letzte Wort bei der Aufnahme von Verbesserungen und Patches haben. Auf diese Weise entstehen täglich grob 4.300 Zeilen neuer Code, wobei auch täglich ungefähr 1.800 Zeilen gelöscht und 1.500 geändert werden (Angaben nach Greg Kroah-Hartman als Durchschnitt für das Jahr 2007). An der Entwicklung sind derzeit ungefähr 100 Verantwortliche („maintainer“) für 300 Subsysteme beteiligt.

[…]

Distributionen

 

Da der Linux-Kernel alleine nicht lauffähig bzw. bedienbar wäre, muss man ihn mit Hilfssoftware zusammen verteilen, beispielsweise den GNU Core Utilities und vielen anderen Anwendungsprogrammen. Solch eine Zusammenstellung nennt man „Linux-Distribution“, sie ist eine Zusammenstellung verschiedener Software, die je nach Bedingung unterschiedlich sein kann. Die so entstehenden Distributionen unterscheiden sich teilweise sehr deutlich. Der Herausgeber einer Linux-Distribution ist der Distributor.

Geschichte der Linux-Distributionen

Die Notwendigkeit von Linux-Distributionen ergab sich durch das Entwicklungsmodell von Linux nahezu sofort. Die Werkzeuge des GNU-Projekts wurden zügig für Linux angepasst, um ein arbeitsfähiges System bereitstellen zu können. Die ersten Zusammenstellungen dieser Art waren 1992 MCC Interim Linux, Softlanding Linux System (SLS) und Yggdrasil Linux. Die älteste heute noch existierende Distribution, Slackware von Patrick Volkerding, folgte 1993 und stammt von Softlanding Linux System ab.

Mit der Ausbreitung der Linux-Distributionen bekamen mehr Menschen die Möglichkeit, das System zu testen, des Weiteren wurden die Distributionen immer umfangreicher, so dass ein immer größerer Einsatzbereich erschlossen werden konnte, was Linux zunehmend zu einer attraktiven Alternative zu Betriebssystemen etablierter Hersteller werden ließ. Im Laufe der Zeit änderte sich auch der Hintergrund der Distributionen: Wurden die ersten Distributionen noch der Bequemlichkeit halber und von Einzelpersonen oder kleinen Gruppen geschrieben, gibt es heutzutage teilweise sehr große Gemeinschaftsprojekte Freiwilliger, Unternehmens-Distributionen oder eine Kombination aus beidem.

Moderne Distributionen

Bestandteile einer Linux-Distribution

Hinter den meisten, vorrangig kleinen Distributionen stehen über das Internet koordinierte Projekte Freiwilliger. Die großen Distributionen werden eher von Stiftungen und Unternehmen verwaltet. Auch die Einsatzmöglichkeiten der einzelnen Distributionen differenzierten sich mit der Zeit stark. Vom Desktop-PC über Server-Installationen und Live-CDs bis hin zu Distributionen zu technischen Forschungszwecken ist alles vertreten. Die Zusammensetzung einer üblichen Linux-Distribution für den Desktop-PC umfasst eine große Zahl von Softwarekomponenten, die das tägliche Arbeiten ermöglichen. Die meisten Distributionen werden in Form fertiger CD- oder DVD-Images im Internet bereitgestellt oder mit Support-Verträgen oder Handbüchern verkauft.

Für besondere Anwendungsgebiete existieren oft keine direkt installierbaren Distributionen. Hier werden Frameworks wie OpenEmbedded z. B. für Router oder Handys verwendet, um eine Distribution für den Einsatz auf dem Gerät vorzubereiten.

[…]

Einsatzbereiche

 

Der Linux-Kernel wird auf unterschiedlichster Hardware eingesetzt und wird von einer großen Menge von sowohl freier als auch proprietärer Software unterstützt. Die Mängel der bisher verfügbaren Fenstersysteme, möglicherweise die mangelnde Einheitlichkeit der zahlreichen grafischen Shells und definitiv das Fehlen von Gerätetreibern behindern die weitere Verbreitung.

 

Die Einsatzgebiete von Linux sind seit der ersten Version stetig erweitert worden und decken heutzutage einen weiten Bereich ab.

[…]

Server

Die LAMP-Distribution basiert auf Linux

[…]

Aufgrund der Kompatibilität von Linux mit anderen unixoiden Systemen hat sich Linux auf dem Servermarkt besonders schnell etabliert. Da für Linux schon früh zahlreiche häufig verwendete und benötigte Serversoftware wie Webserver, Datenbankserver und Groupware kostenlos und weitgehend uneingeschränkt zur Verfügung stand, wuchs dort der Marktanteil stetig.

Da Linux als stabil und einfach zu warten gilt, erfüllt es auch die besonderen Bedingungen, die an ein Server-Betriebssystem gestellt werden. Der modulare Aufbau des Linux-Systems ermöglicht zusätzlich das Betreiben kompakter, dedizierter Server. Außerdem hat die Portierung von Linux auf verschiedenste Hardwarekomponenten dazu geführt, dass Linux alle bekannten Serverarchitekturen unterstützt.

Eingesetzt wird es dabei für praktisch alle Aufgaben. Eines der bekanntesten Beispiele ist die Linux-Server-Konfiguration LAMP, bei der Linux mit Apache, MySQL und PHP/Perl (manchmal auch Python) kombiniert wird. Auch proprietäre Geschäftssoftware wie SAP R/3 ist mittlerweile auf verschiedenen Distributionen verfügbar und hat eine Installationszahl von über 1.000 Systemen erreicht. Das Linux Terminal Server Project ermöglicht es, sämtliche Software außer dem BIOS der Clients zentral zu verwalten.

Da Linux auf einer Vielzahl von verschiedenen Hardwaretypen betrieben werden kann, ist auch die für Linux-Server genutzte Hardware ähnlich umfangreich. Auch moderne Hardware wie die von IBMs eServer p5 wird unterstützt und ermöglicht dort das parallele Ausführen von bis zu 254 Linux-Systemen (Modell p595). Auf IBM-Großrechnern der aktuellen System-z-Linie läuft Linux wahlweise nativ, mittels PR/SM in bis zu 30 LPARs oder in jeder davon unter z/VM in potenziell unbegrenzt vielen, real einigen zehntausend virtuellen Maschinen.

Im Januar 2017 wurden mindestens 34 %[22] aller Websites mittels eines Linux-Servers verfügbar gemacht. Da nicht alle Linux-Server sich auch als solche zu erkennen geben, könnte der tatsächliche Anteil um bis zu 31 Prozentpunkte höher liegen. Damit ist ein tatsächlicher Marktanteil von bis zu etwa 65 % nicht auszuschließen.[22] Der Marktanteil von verkauften Linux-Server-Systemen lag im zweiten Quartal 2013 bei 23,2 %.[23] Da bei Servern nicht selten von einem Kunden selbst ein anderes Betriebssystem installiert wird, gibt diese Zahl nur bedingt Auskunft über die effektive Verwendung von Linux auf Server-Systemen.

Smartphone- und Tablet-Systeme

Galaxy Nexus mit Android

Für Smartphones und Tablets gibt es speziell optimierte Linux-Distributionen. Sie bieten neben den Telefonie– und SMS-Funktionen diverse PIM-, Navigations– und Multimedia-Funktionen. Die Bedienung erfolgt typischerweise über Multi-Touch oder mit einem Stift. Linux-basierte Smartphonesysteme werden meist von einem Firmenkonsortium oder einer einzelnen Firma entwickelt und unterscheiden sich teilweise sehr stark von den sonst klassischen Desktop-, Embedded- und Server-Distributionen. Anders als im Embedded-Bereich sind Linux-basierte Smartphonesysteme aber nicht auf ein bestimmtes Gerät beschränkt, vielmehr dienen sie als Betriebssystem für Geräte ganz unterschiedlicher Modellreihen und werden oft herstellerübergreifend eingesetzt.

[…]

Supercomputer

IBM Blue Gene

Da Linux beliebig angepasst und optimiert werden kann, hat es sich auch in Rechenzentren stark verbreitet, in denen speziell angepasste Versionen auf Großrechnern, Computerclustern (siehe Beowulf) oder Supercomputern laufen.

[…]

(Automobil-)Industrie

Linux setzt sich aus vielfältigen Gründen auch immer mehr in der Industrie, speziell in der Automobilindustrie, durch. Das weltweit erste von Linux betriebene Infotainment-System wurde von General Motors in Kooperation mit Bosch entwickelt.[32] Die GENIVI Alliance definiert Anforderungen an eine Linux-Distribution speziell für Infotainment-Systeme in Fahrzeugen.[33] Die größte Marktdurchdringung hat Linux in Japan. Zu den bekannten Unternehmen, die Linux verwenden, gehören: Ashisuto, Aisin AW, JVC KENWOOD Corporation, NTT DATA MSE und Turbo Systems.[34]

Weitere Einsatzbereiche

Ferner können auch NAS-Speichersysteme oder WLAN-Router Linux als Betriebssystem nutzen. Vorteil ist, dass eine sehr aktive Entwickler-Community besteht, auf deren Ressourcen (der Kernel mit den Schnittstellen-, Speicherverwaltungs- und Netzwerkfunktionen, aber z. B. auch umfangreiche Entwicklerprogramme, bereits bestehender Code wie die Benutzeroberflächen OPIE oder GPE Palmtop Environment, Erfahrung etc.) die Hersteller dabei zurückgreifen können.

[…]

Siehe auch

3. Microservices

Microservices sind ein Architekturmuster der Informationstechnik, bei dem komplexe Anwendungssoftware aus unabhängigen Prozessen generiert wird, die untereinander mit sprachunabhängigen Programmierschnittstellen kommunizieren. Die Dienste sind weitgehend entkoppelt und erledigen eine kleine Aufgabe. So ermöglichen sie einen modularen Aufbau von Anwendungssoftware.[1][2]

Philosophie und Details

Der Gedanke hinter Microservices entspricht weitgehend dem der Unix-Philosophie („Do One Thing and Do It Well“, frei übersetzt: „Erledige nur eine Aufgabe und erledige sie gut“). Die Dienste sollten üblicherweise die folgenden Eigenschaften haben:

  • Die Services können einfach ersetzt werden.
    • Der Umfang eines Microservices sollte für jedes Teammitglied überschaubar sein.
    • Ein Microservice sollte vom zuständigen Team (üblicherweise 5 bis 7 Entwickler) mit vertretbarem Zeitaufwand (z. B. innerhalb eines Monats) neu erstellt und ersetzt werden können.
  • Ein Microservice sollte einen Bounded Context im Sinne von Domain-driven Design implementieren.
    • Die Dienste haben eine einzige Geschäftsfunktion. Sie können beispielsweise einen Bestellvorgang, die Registrierung oder die Rechnungserstellung umfassen, jedoch nicht mehrere dieser Dinge.
  • Der Nutzen für den Benutzer steht im Mittelpunkt.
    • Die Kernfunktionalität sollte frühzeitig ausgeliefert werden, um einen möglichst frühen Nutzen bereitzustellen.
    • Schnittstellen sollten, z. B. über Humane Registries, selbstdokumentierend sein. Beispielsweise Swagger für JSON-basierte REST-Services.
    • Nach der Bereitstellung einer neuen Version des Services muss die alte Version des Endpunktes für eine bestimmte Zeit weiter bereitgestellt werden.
  • Ein Microservice wird nur von einem Team entwickelt. So sorgt das Gesetz von Conway dafür, dass die Architektur auch durch organisatorische Maßnahmen abgesichert wird. Ebenso kann ein Team für mehrere fachlich zusammenhängende Microservices verantwortlich sein.
    • Kommunikationsoverhead und Interessenskonflikte zwischen Teams werden vermieden.
  • Die Schnittstellen verstecken Implementierungsdetails.
    • Es werden dabei bevorzugt Standardverfahren mit geringem Overhead, wie REST, eingesetzt.
    • Es sollte nicht ersichtlich sein, mit welcher Architektur ein Service implementiert wurde.
    • Datenbanken werden nicht von mehreren Services verwendet, sondern immer nur von einem einzigen Service. Dies betrifft auch Zugriffe über Views und Stored Procedures.
  • Microservices werden gegenüber anderen Services isoliert.
    • Jeder Microservice kann eine andere Programmiersprache, Datenbank oder einen ganz anderen Technologie-Stack nutzen.
    • Jeder Microservice kann unabhängig von anderen Microservices in Produktion gebracht werden. Dies erleichtert einen hohen Automatisierungsgrad und ermöglicht Continuous Delivery.
    • Objekte, welche in mehreren Bounded Contexts vorkommen, werden in jedem Service getrennt implementiert. Beispielsweise wird derselbe Kunde in einem Authentifizierungssystem, einem Bestellsystem, einem Logistiksystem und einem Rechnungssystem jeweils durch unterschiedliche Objekte repräsentiert, da an die Objekte unterschiedliche Anforderungen gestellt werden.
    • Microservices werden in getrennten OS-Containern, virtuellen Maschinen oder Servern ausgeliefert. Dies sichert den Service gegenüber einer Überlastung des Host-Systems durch einen anderen Service.
  • Wie alle Services müssen auch Microservices sicher sein:

Die Größe eines Microservices wird hierbei dadurch nach unten begrenzt, dass die Netzwerkkommunikation zwischen Microservices ressourcenintensiv ausfallen kann und für jeden Microservice ein eigenes Deployment vorgesehen werden muss.

Typische Bestandteile einer Microservice-Architektur

Microservices benötigen sehr viel Infrastruktur, welche durch jeweils eigenständige Services implementiert wird.

Für die Lastverteilung externer HTTP-Anfragen von Clienten kommen Load-Balancer zum Einsatz. Statische Inhalte werden mittels eines Content Delivery Network ausgeliefert.

Die für die Geschäftsanforderungen zuständigen Services werden durch eine Reihe von Plattform- oder Infrastruktur-Services unterstützt. Diese übernehmen zentrale Aufgaben wie das Anwendungs- und Service-Monitoring, Logging-Webservices, Operations-Datenbanken, Konfigurationsmanagement, Verschlüsselung, Autorisierung und Authentifizierung, sowie Autoscaling, Softwareverteilung, A/B-Testing und Fault-Injection-Testing (FIT). Zudem gibt es zentrale Routingdienste, welche sich um die Zuordnung von URLs zu Instanzen mit den jeweiligen Diensten kümmern.

Hierzu kommen noch Dienste für die Datenpersistierung, insbesondere Caching, relationale Datenbanken und NoSQL-Datenbanken, sowie BLOB-Speicher für beliebige Dateien.

Abgrenzung zu SOA

Sowohl SOA (Serviceorientierte Architektur) als auch Microservices nutzen Dienste als Architektur-Elemente.

SOA nutzt Dienste, um verschiedene Anwendungen zu integrieren. Die Kombination der Dienste erfolgt durch Orchestrierung oder Choreografie, und Portale können eine gemeinsame Benutzerschnittstelle (UI) für alle Dienste bieten.

Microservices strukturieren eine Anwendung durch Dienste. Jeder Microservice kann eine Benutzerschnittstelle enthalten und Geschäftsprozesse implementieren, wie sie bei SOA in der Orchestrierung zu finden sind.

Vorteile

  • Weil Microservices unabhängig voneinander verteilt und entwickelt werden können, können Teams unabhängig voneinander arbeiten. Das ermöglicht die Skalierung agiler Entwicklungs-Prozesse, ohne viel Kommunikations- und Koordinationsaufwand zu erzeugen.
  • Microservices sind klein. Dadurch bleiben sie übersichtlich und leicht weiterentwickelbar. Bei Bedarf können sie, mit kleinem bis überschaubaren Aufwand, durch eine Neuimplementierung ersetzt werden.
  • Oft schleichen sich bei Systemen ungewollte Abhängigkeiten ein und irgendwann geht die ursprüngliche Architektur vollständig verloren. Die Architektur des Microservices-Systems bleibt stabil, weil Abhängigkeiten zwischen Microservices über die API eingeführt werden müssen. Das ist aufwändig und passiert nicht aus Versehen.
  • Weil die Microservices wartbar bleiben und auch die Architektur des Gesamtsystems erhalten bleibt, erlauben Microservices auch langfristig eine produktive Entwicklung des Systems.
  • Microservices können unabhängig voneinander skaliert werden.
  • Microservice-Systeme können gegen den Ausfall anderer Services abgesichert werden, so dass das Gesamtsystem robust ist.
  • Continuous Delivery ist aufgrund der Größe der Microservices einfacher.
  • Jeder Microservice kann mit einer anderen Technologie implementiert werden. Das vereinfacht Experimente mit neuen Technologien und verhindert das Veralten des Technologie-Stacks.
  • Microservices können auch dazu genutzt werden, um Legacy-Systeme zu erweitern, ohne dabei zu viele Änderungen an der alten Code-Basis vornehmen zu müssen.
  • Wenn Schlüsseldienste identifiziert wurden, können im Falle einer Überlastung unkritische Services reduziert oder abgeschaltet werden, um Ressourcen für kritische Services frei zu machen.

Nachteile

Microservices werden wegen einiger Merkmale kritisiert:

  • Die verteilte Architektur erzeugt zusätzliche Komplexität, vor allem Netzwerk-Latenzen, Lastverteilung oder Fehlertoleranz (siehe dazu auch: Fallacies of Distributed Computing).
  • Da es mehr Systeme gibt die ausfallen können als bei monolithischen Services, steigt auch die Wahrscheinlichkeit, dass mindestens eine Komponente ausfällt. Hierbei ist zu beachten, dass der Ausfall eines Microservices sich nicht auf das Gesamtsystem auswirkt, was diesen Nachteil im Normalfall kompensiert.
  • Die Vielzahl an Services macht die Softwareverteilung und das Testen komplexer.
  • Der Aufwand für die Migration bestehender Systeme ist beträchtlich und bedeutet in der Regel auch eine Anpassung der Kommunikationskultur in den beteiligten Organisationen.[3]
  • Das Logging und Monitoring wird komplexer, da mehrere Systeme involviert sind, welche ggf. unterschiedliche Logging- und Monitoringtechnologien einsetzen. Es sollten daher, zusätzlich zu dezentralen Logging- und Monitoringlösungen, zentrale Logging-, Monitoring- und OpsDB-Dienste eingesetzt werden.
  • Da es sich um ein potenziell weltweit verteiltes System handelt, müssen nicht nur unterschiedliche Zeitzonen der Client-Anwendungen, sondern auch unterschiedliche Zeitzonen der Hosts berücksichtigt werden. Eine Zeitsynchronisierung zwischen den Hosts (z. B. mittels NTP oder noch besser PTP) und die Verwendung passender Zeit-Bibliotheken (z. B. Joda Time oder Noda Time) wird damit zwingend notwendig.[4][5]
  • Da es sich bei Microservices um eine verteilte Architektur handelt, muss aufgrund des CAP-Theorems zwischen Verfügbarkeit der Anwendung und der Datenkonsistenz gewählt werden. Dem steht allerdings gegenüber, dass ein monolithischer Service im Fehlerfall, etwa bei einer Überlastung, ebenfalls nicht immer verfügbar ist. Zudem kann für Daten, sobald sie dem Nutzer angezeigt wurden, ebenfalls keine Konsistenz garantiert werden.
  • Da die Services in unterschiedlichen Programmiersprachen und Software-Stacks implementiert werden können, erhöhen sich die Anforderungen an die Entwicklungswerkzeuge und das Plattform-Management. Zudem muss die Funktionalität von Bibliotheken teilweise dupliziert werden.

Beispiele

Von folgenden Internetdiensten ist bekannt, dass sie Microservices benutzen:

Implementierungen

Jeder Microservice kann in einer anderen Programmiersprache mit einer anderen Technologie entwickelt werden. Also ist die Technologie für die Implementierung der einzelnen Microservices bei weitem nicht so wichtig wie die übergreifenden Technologien für die Integration und Kommunikation.[15]

Neuere Entwicklungen

Inzwischen werden auch Abwandlungen dieses Architekturmusters beispielsweise in Form von Macroservices diskutiert.[16] Ziel ist es, hierüber Nachteile vom Microservices zu kompensieren, ohne die Nachteile eines Monolithen in Kauf nehmen zu müssen.

Siehe auch

4. Kontinuierliche Integration

Kontinuierliche Integration (auch fortlaufende oder permanente Integration; englisch continuous integration, CI) ist ein Begriff aus der Software-Entwicklung, der den Prozess des fortlaufenden Zusammenfügens von Komponenten zu einer Anwendung beschreibt. Das Ziel der kontinuierlichen Integration ist die Steigerung der Softwarequalität. Typische Aktionen sind das Übersetzen und Linken der Anwendungsteile, prinzipiell können aber auch beliebige andere Operationen zur Erzeugung abgeleiteter Informationen durchgeführt werden. Üblicherweise wird dafür nicht nur das Gesamtsystem neu gebaut, sondern es werden auch automatisierte Tests durchgeführt und Softwaremetriken zur Messung der Softwarequalität erstellt. Der gesamte Vorgang wird automatisch ausgelöst durch Einchecken in die Versionsverwaltung.

Eine Vorstufe der kontinuierlichen Integration ist der Nightly Build (nächtlicher Erstellungsprozess). In der Praxis trifft man auch auf kontinuierliche Integration, gepaart mit einem Nightly Build, um die Vorteile beider Systeme zu kombinieren. In der Methode DevOps wird diese Automatisierung auch Pipeline genannt, da die einzelnen Schritte sequentiell abgearbeitet werden. Die Pipeline ermöglicht hier, die Entwicklungsgeschwindigkeit zu erhöhen, denn schon nach wenigen Minuten erhält der Entwickler Rückmeldung, ob die Qualitätsansprüche erreicht wurden oder nicht.

Eine Weiterentwicklung der kontinuierlichen Integration stellt die Continuous Delivery (CD) dar. Dabei wird in bestimmten Zeitabständen oder bei Erreichen einer bestimmten Qualitätsmetrik eine neue Version der Software ausgeliefert.

Grundsätze

Spätestens seit das Konzept der permanenten Integration von Kent Beck im Rahmen von Extreme Programming populär gemacht wurde, ist der Begriff der kontinuierlichen Integration an sich bekannt, für die erfolgreiche Einführung müssen allerdings einige Grundsätze (vgl. „Continuous Integration“[1] von Martin Fowler) befolgt werden:

Gemeinsame Codebasis
Um innerhalb einer Arbeitsgruppe sinnvoll integrieren zu können, muss eine Versionsverwaltung existieren, in die alle Entwickler ihre Änderungen kontinuierlich integrieren können.
Automatisierte Übersetzung
Jede Integration muss einheitlich definierte Tests wie statische Code-Überprüfungen durchlaufen, bevor die Änderungen integriert werden. Dafür ist eine automatisierte Übersetzung notwendig.
Um Testergebnisse von den Arbeitsumgebungen unabhängig zu machen, empfiehlt sich der Einsatz von separaten Test-Umgebungen. Damit können auf diesen Rechnern auch gezielt Verfahren implementiert werden, um die Testlaufzeit zu minimieren.
Kontinuierliche Test-Entwicklung
Jede Änderung sollte möglichst zeitgleich mit einem dazugehörigen Test entwickelt werden (beispielsweise mittels testgetriebener Entwicklung). Mit Hilfe von kontrollflussorientierten Testverfahren (Analyse der Code-Überdeckung, engl.: „Code Coverage Analysis“) kann diese Vorgehensweise dokumentiert und kontrolliert werden.
Häufige Integration
Jeder Entwickler sollte seine Änderungen so oft wie möglich in die gemeinsame Code-Basis integrieren. Mit kurzen Integrations-Intervallen reduziert man das Risiko fehlschlagender Integrationen und sichert gleichzeitig den Arbeitsfortschritt der Entwickler in der gemeinsamen Code-Basis (Datensicherung, engl.: „backup“).
Integration in den Hauptbranch
Jeder Entwickler sollte seine Änderungen in den Hauptbranch des Produktes integrieren, wo dann automatisch ein Build- und Testzyklus gestartet wird. Dieser Build wird der kontinuierliche Integrationsbuild genannt.
Kurze Testzyklen
Der Test-Zyklus vor der Integration sollte kurz gehalten sein, um häufige Integrationen zu fördern. Mit steigenden Qualitätsanforderungen für die einzelnen Integrationen steigt auch die Laufzeit zur Ausführung der Test-Zyklen. Die Menge der vor der Integration durchgeführten Tests muss sorgfältig abgewogen werden, weniger wichtige Tests werden dann nur nach der Integration durchgeführt.
Gespiegelte Produktionsumgebung
Die Änderungen sollten in einem Abbild der realen Produktionsumgebung getestet werden.
Einfacher Zugriff
Auch Nicht-Entwickler brauchen einfachen Zugriff auf die Ergebnisse der Software-Entwicklung. Dies müssen nicht notwendigerweise Quellen sein, sondern kann beispielsweise das in das Testsystem gespielte Produkt für Tester, die Qualitäts-Zahlen für Qualitäts-Verantwortliche, die Dokumentation oder ein fertig paketiertes Abbild für Release Manager sein.
Automatisiertes Reporting
Die Ergebnisse der Integrationen müssen leicht zugreifbar sein. Sowohl Entwickler als auch andere Beteiligte müssen leicht Informationen darüber bekommen können, wann die letzte erfolgreiche Integration ausgeführt wurde, welche Änderungen seit der letzten Lieferung eingebracht wurden und welche Qualität die Version hat.
Automatisierte Verteilung
Jede Version sollte leicht in eine Produktionsumgebung (oder ein Abbild derselbigen) überführt werden können. Hierfür sollte die Softwareverteilung automatisiert sein.

Kontinuierliche Integration kann auf jedem Rechner mit Zugang zum Quellcode durchgeführt werden. Es ist insbesondere möglich, die Integration gleichzeitig auf unterschiedlichen Systemen (etwa verschiedenen Betriebssystemen) durchzuführen.

Vorteile

  • Integrations-Probleme werden laufend entdeckt und behoben (gefixt) – nicht erst kurz vor einem Meilenstein.
  • Frühe Warnungen bei nicht zusammenpassenden Bestandteilen.
  • Sofortige Unittests entdecken Fehler zeitnah. Im Idealfall kann so beispielsweise direkt bemerkt werden, wenn ein Commit einen Fehler einführt.
  • Ständige Verfügbarkeit eines lauffähigen Standes für Demo-, Test- oder Vertriebszwecke.
  • Die sofortige Reaktion des Systems auf das Einchecken eines fehlerhaften oder unvollständigen Codes „erzieht“ die Entwickler im positiven Sinne zu einem verantwortlicheren Umgang und kürzeren Checkin-Intervallen. Der Merge-Aufwand wird immer größer, je länger man mit der Integration wartet.

Software

Beispielhafte Werkzeuge für kontinuierliche Integration:

Weblinks