Was sind Container?

Container sind eine natürliche Weiterentwicklung virtueller Maschinen zur effizienten Nutzung verfügbarer Hardware-Ressourcen. Da ein Container in vielen Fällen lediglich einen kleinen Teil einer größeren Anwendung enthält (Microservices), braucht es oftmals viele Container, um eine große Anwendung vollständig bereitzustellen. Siehe hierzu auch meinen Beitrag über Docker. Während Docker eine Container-Laufzeitumgebung ist, ist Kubernetes eine Plattform für die Ausführung und Verwaltung von Containern aus vielen Container-Laufzeitsystemen. Es unterstützt zahlreiche Container-Laufzeiten, darunter Docker, containerd, CRI-O und jede Implementierung des Kubernetes CRI (Container Runtime Interface).

Im Betrieb von Container-Anwendungen spielen Verwaltungsaufgaben wie die Bereitstellung, die auf die Anfragelast bezogene automatische Skalierung, sowie das Monitoring der zum Betrieb notwendigen Anwendungscontainer und ihrer Infrastruktur eine wichtige Rolle. Es dient als Werkzeug zur Unterstützung dieser Orchestrierungsaufgaben.

Eingesetzt wird Kubernetes dabei bereits in kleinen und einfachen Containerumgebungen bis hin zu komplexen und verteilten Anwendungsfällen großer Technologieanbieter und ihrer containerbasierten Cloud-Produkte. Einige Beispiele sind hier: Microsofts Azure, IBM Cloud, Red Hat OpenShift, Amazons EKS, Googles Kubernetes Engine und Oracles OCI. Die bekannte Container-Technologie Docker wird ebenfalls unterstützt.

Kurze Zeitreise

Kubernetes (Altgriechisch für „Steuermann“) wurde ursprünglich von Joe Beda, Brendan Burns und Craig McLuckie entwickelt. Kurze Zeit später stießen weitere Google-Entwickler wie Brian Grant und Tim Hockin hinzu. 2014 stellte Google Kubernetes als Open-Source-Projekt der Öffentlichkeit vor.

Version 1.0 wurde am 21. Juli 2015 veröffentlicht. Dabei wurde auch die Gründung der Cloud Native Computing Foundation unter dem Dach der Linux Foundation angekündigt und Kubernetes wurde von Google an diese gespendet.

Was kann Kubernetes?

Kubernetes bietet eine Reihe von Möglichkeiten, die eine Orchestrierung von komplexen Container basierten Anwendungen unterstützt. Einige davon sind:

• Starten von Containern im Bedarfsfall (Ausfall bestehender Container oder hinzufügen neuer Container bei hohem Anfragevolumen).
• Überwachung anhand definierter Faktoren, ob Container noch erwartungsgemäß funktionieren.
• Sinnvolle Verteilung der eingehenden Anfragelast auf die einzelnen Container.
• Unterstützung beim Wechsel auf eine neuere Anwendungsversion.

Wie ist Kubernetes aufgebaut?

Kubernetes-Infrastrukturen können je nach Anwendungsfall hoch komplex sein. Eine Kubernetes-Installation besteht aus dem Zusammenspiel mehrerer Server. Die Server aus diesem Verbund lassen sich in zwei Kategorien einteilen: Zur ersten Kategorie gehören Server, die sich um Verwaltungsaufgaben in diesem Verbund kümmern. Sie werden als „Control Planes“ bezeichnet und führen keinen Container aus, der Teil der betriebenen Anwendung ist.

Die zweite Kategorie, die anwendungsbezogenen Container, werden auf den „Worker Nodes“ ausgeführt. Sie haben keine Verwaltungsaufgaben, sondern dienen lediglich dazu, die eigentliche Arbeitslast der Anwendung abzuarbeiten. Die notwendige Anzahl und Leistung dieser „Worker Node Server“ ermittelt sich anhand der Ressourcenanforderung der Container. Je ressourcenintensiver die Container sind, desto mehr oder performantere Worker Nodes werden benötigt.

Alle Aufgaben eines Kubernetes-Clusters werden redundant auf mehreren Servern betrieben, um die Hochverfügbarkeit auch im Störungsfall aufrechtzuerhalten.

Fazit

Kubernetes bietet als Open-Source-System zur Orchestrierung von Containern viele Vorteile. Besonders lohnt sich der Einsatz bei umfangreichen und hochskalierbaren Cloud-Anwendungen. Wenn man es einsetzt, kommt man schnell zu dem Punkt, an dem es komplex und aufwändig wird. Für ein effektives Management der Plattform brauchen Unternehmen Mitarbeitende mit Spezialwissen. Da diese Experten am Markt schwer zu finden sind und sich der Einsatz meist schon aus Kosten- und Rentabilitätsgründen nicht lohnt, lagern viele Unternehmen, die Kubernetes einsetzen, das Management und den Betrieb an diverse Managed Cloud Solution Provider aus. Man sollte aber nicht unbeachtet lassen, dass sich der Einsatz von Kubernetes nicht in jedem Fall lohnt. Letztendlich ist es immer eine Abwägung der Kosten und Aufwände gegen den Ertrag, den man sich durch den Einsatz erhofft.

Der Beitrag Kubernetes – Die Kunst des Container-Orchestrierens erschien zuerst auf CEOsBay.

Wenn man von einer dezentralen Applikation spricht, meint man eigentlich primär die Speicherung von wichtigen Daten und Zuständen und keine Applikation selbst. Die Anwendung selbst, wird häufig immer noch von zentralen Punkten, Knoten oder Maschinen abgerufen bzw. ausgeführt. Darunter zählen primär der Code oder visuelle Darstellungselemente, die zur Ausführung der Anwendung benötigt sind.

Im Prinzip lässt es sich so darstellen, dass man den Code und die Grafiken beispielsweise von einem Server abruft und die Werte dazu, welche Eigenschaften ein digitales Gut hat, wie von einem NFT, dezentral aus der Blockchain. Folglich ist die DApp nicht von einer einzelnen Person oder Institution zu steuern.

Was zeichnet eine DApp aus

DApps nutzen in der Regel kryptografisch verschlüsselte Token. Es handelt sich dabei um digitale Assets, die eine Kopie eines Datensatzes auf der Blockchain abbilden.

DApps basieren grundsätzlich auf Open Source Software. Was dies genau ist, habe ich in der Vergangenheit bereits erklärt.

Die Ausführung von DApps erfolgt in einer virtuellen Umgebung. Weist ein Smart Contract einen Fehler auf, erfolgt keine Einschränlung der gesamten Blockchain.

DApps können unabhängig von ihrer Umgebung identische Funktionen ausführen.

Dezentralisierte Anwendungen sind in der Lage, kryptografisch verschlüsselte Token generieren zu können.

Und wie bereits angesprochen, sind die Daten von DApps auf einer dezentralisierten Blockchain gespeichert.

Funktionsweise

Ethereum war der Startschuss für DApps. Das Fundament wird von den Smart Contracts geliefert, die sich auf der Ethereum Blockchain befinden. Die DApp kann in jeder beliebigen Programmiersprache, wie JavaScript oder C++ geschrieben sein und besteht immer aus diesen Smart Contracts, die sich auf der Blockchain befinden. Was Smart Contracts sind und wie sie funktionieren, habe ich in dem Beitrag Smart Contracts erklärt.

Welche DApps gibt es?

CryptoKitties – Ein Onlinespiel, bei dem man virtuelle Katzen züchtet. Eines der ersten DApps überhaupt.

Uniswap – Uniswap ist eine Krypto Handelsplattform, die ein dezentrales Netzwerkprotokoll verwendet.

MetaMask – MetaMask ist eine Krypto-Wallet, die alle Arten von Ethereum-basierten Token unterstützt. Dazu gehören auch die NFT basierten Token.

The Sandbox – Habe ich bereits in diesem Beitrag thematisiert. Schaut gerne rein.

Star Atlas – Ein Spiel in der Entwicklung, welches sich mit einem Spiele-Titel wie Elite Dangerous oder Star Citizen vergleichen lässt.

Axie Infinity – Ein Onlinespiel, bei dem man Pokemon-ähnliche Tierchen züchtet und gegeneinander kämpfen lässt.

Bis auf die ersten 3 Beispiele, streben alle erwähnten DApp Projekte die Erstellung bzw. einen Beitrag für ein Metaverse an.

Es gibt noch viel mehr DApps, die ich evtl. in diesem Beitrag erwähne und definitiv in zukünftigen Beiträgen thematisiere. Freunde und ich arbeiten gemeinsam an einigen DApps. Diese füge ich in Zukunft auch nach und nach ein.

Der Beitrag DApp – Sichere und transparente Interaktion mit Anwendungen auf der Blockchain erschien zuerst auf CEOsBay.

Nicht zu verwechseln mit einem Emulator

Als Emulator wird in der Computertechnik ein System bezeichnet, das ein anderes Computer System in bestimmten Teilaspekten nachbildet. Dabei handelt es sich um keine Virtuelle Maschinen 😉

Auch nicht zu verwechseln mit einem Simulator

Ein Simulator wird dazu genutzt um eine Simulation auszuführen. Beispielsweise für die Nachbildung von realen Szenarien zum Zwecke der Ausbildung von Piloten im Flugsimulator. Auch von Ärzten und Pflegepersonal in einem Patientensimulator kommt ein Simulator zum Einsatz. Kriegs- bzw. Gefechtssimulationen bei Einsatzkräften der Polizei oder dem Militär, sind heutzutage auch schon normal. Die Simulation zur Analyse von Systemen, deren Verhalten für die theoretische, formelmäßige Behandlung zu komplex sind, finden ebenfalls Einsatz. Auch wenn diese Art von Simulation sich grundlegend von den vorher genannten unterscheidet. Und dann gibt es natürlich die Simulation in Spielen (Aber diesen Dingen bei späteren Beiträgen mehr).

Der Hypervisor

Man kann sich die Sache mit den Virtuellen Maschinen im Endeffekt so vorstellen wie einen oder mehrere Computer in einem Computer zu betreiben. Spezialisierte Software, die man als Hypervisor bezeichnet, emulieren die CPU- (Central Processing Unit = Prozessor), den Speicher-, die Festplatten-, die Sound-, Netzwerk- und andere Hardwareressourcen des Computers oder Servers vollständig und ermöglicht es virtuellen Maschinen, die Ressourcen gemeinsam zu nutzen oder aber vollkommen zu isolieren.

Der Hypervisor kann mehrere virtuelle Hardwareplattformen emulieren. Diese können voneinander isoliert sein, so dass virtuelle Maschinen zum Beispiel Unix-, Linux– und Windows-Betriebssysteme auf demselben zugrundeliegenden physischen Computer ausführen können. Mit der Virtualisierung kann man beispielsweise auch die Kostensenkung der IT-Infrastruktur erreichen.

Virtuelle Maschinen nutzen die Hardware effizienter, wodurch sich die benötigten Hardwarekomponenten, die damit verbundenen Wartungs- und Instandhaltungskosten, sowie der Energiebedarf sänken lassen. Sie verringern auch den Aufwand der Administration, da sich alles an einem Ort befindet. Auch nutzt sich virtuelle Hardware innerhalb der Virtuellen Maschinen nicht ab und mechanische Fehler sind ausgeschlossen.

Admins (Administratoren = Benutzer mit erweiterten Rechten in IT-Systemen) können die Vorteile virtueller Umgebungen nutzen, um Images (In der Computertechnik ist ein Image ein Systemabbild bzw. eine serielle Kopie des gesamten Zustands eines Computersystems, die in einer nichtflüchtigen Form wie einer Datei gespeichert ist), Backups (Sicherheitskopien), das Einrichten und die Bereitstellung neuer Computersysteme und grundlegende Systemverwaltungsaufgaben zu vereinfachen.

Virtuelle Maschinen erfordern keine spezielle Hardware und sind in der Regel bzw. je nach Anwendungsbereich und den Anwendungen, die ausgeführt werden sollen, nicht sehr ressourcenhungrig. Wobei dies stark von der Menge der ausgeführten Virtuellen Maschinen und der jeweiligen Konfigurationen abhängt. Zu den Vorteilen gehört unter Anderem auch die Flexibilität beim Verschieben der Instanzen zwischen diversen Servern oder Computersystemen.

Administration

Alles in allem sind Virtuelle Maschinen etwas Feines. Zumal jemand, der mehrere Betriebssysteme einer IT-Infrastruktur administrieren, orchestrieren bzw. verwalten muss, die Vorzüge diverser Betriebssysteme auf einem dedizierten System nutzen kann. Nichtsdestotrotz besteht das Risiko, falls systemrelevante Anwendungen plattformübergreifend auf einem dedizierten Server bzw. Computer ausgeführt werden, bei einer Überlastung oder einem Hardwarefehler alle Systeme die darauf abgebildet sind, in Mitleidenschaft zieht. Folglich macht es Sinn, auch Virtuelle Maschinen auf der Hardware-Ebene redundant zu betreiben.

Wozu benötigt man Virtuelle Maschinen?

Virtuelle Maschinen sind vielseitig einsetzbar. Eines der wichtigsten Aspekte ist, wie bereits erwähnt, die synchrone Nutzung unterschiedlicher Betriebssysteme. Diese Art der Nutzung trifft man häufig beim Testen von Software- bzw. Web-Anwendungen an. So ist es beispielsweise möglich, die Tests auf verschieden Systemen mit verschiedenster Hardware-Ausstattung auszuführen und die Resultate bzw. Laufzeitergebnisse auf einem primären System zu evaluieren und zu verwalten. Dies macht auch dann Sinn, wenn es sich um sicherheitsrelevante Anwendungen handelt, die beispielsweise in einer isolierten Umgebung ausgeführt werden sollen/müssen oder wenn man Penetrationstests (Penetrationstest, kurz Pentest(ing), ist der fachsprachliche Ausdruck für einen umfassenden Sicherheitstest einzelner Rechner oder Netzwerke jeglicher Größe) in diversen Netzwerkumgebungen und verschiedenen Betriebssystemen ausführen möchte.

Virtuelle Maschinen und Multi-Boot-Systeme

Als die Virtualisierung noch nicht existierte, musste man ein Computer-System mit mehreren Betriebssystemen immer wieder neu booten (Neustarten), um auf die verschiedenen Betriebssysteme zuzugreifen. Jedes dieser Betriebssysteme konnte zwar sowohl abhängig als auch unabhängig vom Dateisystem agieren, doch sie konnten immer nur einzeln zu einem bestimmten Zeitpunkt verwendet werden. Auch heute macht man dies nach wie vor so. Beispielsweise wenn man Software nutzen will, die ausschließlich auf einem spezifischen Betriebssystem wie MacOS, Windows oder Linux funktionsfähig ist, die Hardware-Ressourcen relativ begrenzt sind und die vollständige Kapazität des Systems für das spezifische Betriebssystem oder die Anwendungen benötigt werden. Nachteile sind hierbei, meiner Erfahrung nach, besonders auf Apple Geräten, die fehlenden oder fehlerhaften Treiber bzw. das geschlossene Ökosystem des Herstellers.

Virtuelle Maschinen und Cloud Computing

Mit dem Aufkommen der Cloud lassen sich die virtuellen Maschinen auch in der Cloud ausführen bzw. umziehen/migrieren. Dieses Thema werde ich aber in einem anderen Beitrag genauer bearbeiten, da ich mich derzeit auch in diesem Umfeld bewege.

Virtuelle Maschinen und Container

Container funktionieren nach einem ähnlichen Prinzip wie Virtuelle Maschinen – Bis auf die Hardware versteht sich. Doch dies habe ich bereits in dem Blog-Beitrag über Docker beschrieben. Hier ist auch der Beitrag über Kubernetes zu empfehlen.

Welche Virtuellen Maschinen gibt es?

Zu den Hauptanbietern gehören wohl VMware, was heute als EMC unter dem Dach von Dell existiert, Oracle, Microsoft und Parallels. Ansonsten sind da noch Open-Source-VM-Lösungen wie Red Hat Virtualization oder ProxMox, die ich zusammen mit Azure auch noch in späteren Beiträgen thematisieren möchte. Nicht zu vergessen Virtual Box von Oracle, was ebenfalls als „Open Source“ zu haben ist.

Der Beitrag Virtuelle Maschinen – Flexibilität und Effizienz durch nahtlose Systemintegration und isolierte Umgebungen erschien zuerst auf CEOsBay.

Installation

Im Grunde genommen, ist es schnell installiert. Einfach den folgenden Code in das Terminal (Das Terminal ist ein CLI aka Command-Line Interpreter bzw. Command-Line Processor welches ein Command-Line Interface nutzt, um Befehle von einem Benutzer in Form von Textzeilen zu empfangen) von macOS kopieren und los geht’s mit einem kurzen Druck auf die Enter Taste.

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Dazu muss man noch sagen, dass es immer noch Systemvoraussetzungen gibt. Homebrew benötigt eine 64-bit Intel CPU (Central Processing Unit aka Prozessor) oder eine Apple Silicon CPU, mindestens macOS Mojave (10.14) und die installierten Xcode Command Line Tools (CLT) die wie folgt installiert werden können:

xcode-select —install

Das Skript erklärt was es tun wird und wartet in der Regel auf Bestätigungen und/oder Befehle, bevor es etwas macht. Mehr Informationen gibt es natürlich auf der Website von Homebrew. Noch genauer, hier.

Wozu man es braucht? Ganz einfach, MacOS ist ein Unix-Betriebssystem – Nur ohne einen Paketmanager ist es so etwas wie ein Greifvogel, dem man die Flügel gestutzt hat. Sicherlich gibt es die Möglichkeit, VM’s (Virtuelle Maschinen zu installieren) oder andere Betriebssysteme nativ über Bootcamp zu installieren „In späteren Beiträgen gerne mehr“, doch wer hat schon Lust, für die einfachsten Anwendungen und Funktionen eine virtuelle Maschine zu installieren geschweige denn hochzufahren.

Im Grunde genommen ist Homebrew ein selbstgemachter Paketmanager für macOS. Linux User kennen Paketmanager, aber auf macOS fehlt dies leider „nativ“. Wer sich jetzt noch nicht über bestimmte fehlende Anwendungen wie z.B. wget auf seinem Mac gewundert hat, hat wahrscheinlich auch keinen Bedarf für einen Paketmanager wie Homebrew. Allen andere möchte ich hier einmal zeigen was geht und vor allem wie es geht.

Wenn man keine Lust mehr auf Homebrew hat und es wieder von seinem System entfernen möchte, macht man dies, wie bereits bei der Installation, mit einem Script:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/uninstall.sh)"

Homebrew installiert über das Skript selbst unter dem bevorzugten Präfix (/usr/local für macOS Intel, /opt/homebrew für Apple Silicon). Homebrew benötigt dann kein Sudo mehr. Man kann es auch ausführen, wenn in /usr/local bereits Inhalte installiert sind. Homebrew installiert keine Dateien außerhalb seines Pfades und man kann den Ort einer Homebrew-Installation frei wählen. So kann man leicht prüfen, ob die Deinstallation alle Daten rückstandslos entfernt hat.

Xcode installieren

Als iOS Entwickler hat man wahrscheinlich bereits Xcode installiert. Falls nicht, gehören die Xcode CLI Tools auch noch zu den Systemvoraussetzungen auf der Software bzw. Tool Ebene. Diese lassen sich automatisch bei der Installation von Xcode über den Apple App Store installieren oder aber man gibt einfach den folgenden Befehl im Terminal ein:

xcode-select —install

Pakete und Befehle

Nach der Installation von Homebrew können weitere Pakete installiert werden. Tatsächlich ist dies nun genauso simpel wie unter Linux.

Mit einem kurzen Befehl lassen sich alle bereits installierten Pakete anzeigen:

brew list

Sollte diese Liste, aus welchem Grund auch immer, zu lang werden, kann man sich die Ausgabe auch mit dem nachfolgenden Befehl in eine Datei umleiten:

brew list > homebrewpackages.txt

Und wenn man mal nicht weiß, wofür das ein oder andere Paket eigentlich dient, kann man mit einem weiteren Befehl mehr Informationen über das spezifische Paket erhalten.

brew info <paketname>

Mit dem nächsten Kommando lässt sich der genaue Standort des Pakets ermitteln:

brew --prefix <paketname>

Standardmäßig sind alle Pakete in allen Versionen von macOS im selben Verzeichnis `/usr/local/Cellar/` installiert. Zusätzlich werden im Verzeichnis `/usr/local/opt/` noch symbolische Links erzeugt. Das folgende Kommando zeigt die Inhalte an:

ls -l /usr/local/opt/

Homebrew und unsere installierten Pakete werden aktualisiert mit

brew update

Was die Pakete betrifft, kann es vor einem Update/Upgrade auch interessant sein zu ermitteln, welche Pakete überhaupt ein Update benötigen. Dies überprüfen wir mit dem folgenden Kommando:

brew outdated

Ein einzelnes individuelles Paket lässt sich mit dem folgenden Befehl aktualisieren:

brew upgrade <paketname>

Und mit

brew upgrade

lassen sich alle aktuallisieren.

Selbstverständlich lassen sich auch alle verfügbaren Pakete anzeigen. Dazu am besten den folgenden Befehl verwenden:

brew search <search_string>

Wenn man beispielsweise auf der Suche nach Paketen für Azure ist, lässt sich dies auch mit einem Befehl umsetzen:

brew search azure

In der Ausgabe lassen sich auf diesem Weg alle Pakete, die für Microsoft Azure (Im Grunde genommen alle Pakete, die den Terminus „azure“ im Namen innehalten) auffinden. Pakete mit einem grünen Häkchen lassen darauf schließen, dass diese bereits installiert sind.

Über Homebrew lässt sich auch ganz hervorragend PowerShell Core auf dem Mac installieren, um Windows Systeme mit Powershell verwalten zu können.

brew install --cask powershell

Sicherlich will man auch hin und wieder das ein oder andere Paket loswerden. Dazu lässt sich dann der nachfolgende Befehl nutzen:

brew uninstall <paketname>

Fazit

Diese Informationen ermöglichen einen kleinen Einblick in Hombrew. Selbstverständlich kann man noch vieles mehr damit anstellen und mehr darüber erfahren. Hierzu einfach in der Dokumentation von Hombrew selbst vorbeischauen.

Der Beitrag Homebrew – Paketmanager für MacOS (oder Linux) erschien zuerst auf CEOsBay.