Einsatz von Docker-Container-Technologie mit Produkten und Services von F5

Zusammenfassung

Die sich wandelnden Anforderungen an die IT und das Aufkommen agiler Entwicklungs- und Bereitstellungsstrategien haben zur Entstehung der „Containerisierung“ geführt. Dabei handelt es sich um eine Alternative zur vollständigen Maschinenvirtualisierung, bei der eine Anwendung zusammen mit ihrer eigenen Betriebsumgebung in einem Container gekapselt wird. Die Containerisierung ist eine attraktive Lösung, die Entwicklern schnellere Iterationen ermöglicht. Darüber hinaus bietet sie weitere Vorteile, die den mit virtuellen Maschinen verbundenen Mehraufwand reduzieren und eine höhere Ressourcenauslastung im softwaredefinierten Rechenzentrum (SDDC) ermöglichen.

Obwohl die Containerisierung kein neues Konzept ist, gilt das von Docker, Inc. entwickelte Docker aufgrund seiner breiten Unterstützung in der Branche, seiner Standardisierung und seines umfassenden Funktionsumfangs weithin als bevorzugte Implementierung. Nach Aussage des Unternehmens ist Docker „eine offene Plattform zum Erstellen, Bereitstellen und Ausführen verteilter Anwendungen. Sie stellt Programmierern, Entwicklungsteams und Betriebsingenieuren einen gemeinsamen Werkzeugsatz zur Verfügung, mit dem sie die verteilte und vernetzte Struktur moderner Anwendungen optimal nutzen können.“ Docker vereinfacht somit die Verwaltung des Anwendungslebenszyklus von der Entwicklung bis zur Bereitstellung und ermöglicht die Portabilität von Anwendungen. Diese Vereinfachung ist für Unternehmen von entscheidender Bedeutung, da für eine Anwendung mehrere Hosting-Optionen zur Verfügung stehen – entweder in der Public Cloud oder in einer Private-Cloud-Infrastruktur.

Dieses Dokument beschreibt die Ausrichtung von F5 hinsichtlich des Einsatzes von Containern innerhalb der F5-Technologie sowie der Unterstützung von Docker für die Anwendungsbereitstellung und -sicherheit. Bevor wir diese Strategie erörtern, ist es wichtig, die Herausforderungen in Rechenzentren zu verstehen und zu erkennen, warum diese Technologien für die Anwendungsbereitstellung in Unternehmen der nächsten Generation von entscheidender Bedeutung sind.

Hinweis: Dieses Dokument richtet sich an IT-Entscheidungsträger, Architekten und Entwickler. Es wird vorausgesetzt, dass die Leser über Vorkenntnisse in den Bereichen Virtualisierungstechnologie, Softwareentwicklung und Release-Lebenszyklus verfügen.

Herausforderungen bei der Rechenzentrumsinfrastruktur

Mehrere aktuelle Studien zu den Herausforderungen bei der Rechenzentrumsinfrastruktur haben übereinstimmend eine Reihe von Anforderungen für die Weiterentwicklung des Rechenzentrums ermittelt:

• Schnellere Methoden zur Anwendungsbereitstellung
• Ein verbesserter Prozess für das Workflow-Management
• Höhere Verfügbarkeit und Auslastung von Rechenressourcen
• Mehr Flexibilität bei der bedarfsgerechten Verlagerung von Workloads

Mit dem Aufkommen neuer Trends in der Anwendungsentwicklung richten Unternehmenskunden ihr Verständnis des Modells für das Application Lifecycle Management wie folgt neu aus:

• Anwendungen der nächsten Generation werden zunehmend nach dem Prinzip „Cloud First“ entwickelt.
• Linux hat sich zum De-facto-Betriebssystem für die Cloud-Entwicklung entwickelt.
• Cloud-Anwendungen der nächsten Generation:
  • Sind zustandslos konzipiert und nutzen eine lose gekoppelte Microservice-Architektur.
  • Nutzen Frameworks, die es ermöglichen, Services unabhängig voneinander und ohne Abhängigkeiten von Softwareversionen oder anderen Services zu erstellen.
• Unternehmen setzen zunehmend auf Automatisierung und nutzen dazu Konfigurationsmanagement-Tools (wie Puppet, Chef und Ansible) sowie DevOps-Orchestrierung, um Software flexibler veröffentlichen zu können.
• Wenn Unternehmen neue Anwendungen entwickeln und bestehende Anwendungen in Public Clouds migrieren, ist Portabilität entscheidend, um eine Anbieterabhängigkeit zu vermeiden. Obwohl die Technologie virtueller Maschinen (VM) eine gewisse Abstraktion ermöglicht, implementiert jeder Hypervisor seine Umgebung anders und ist daher nicht vollständig portabel.

Docker versucht, diese Herausforderungen zu bewältigen, und hat sich daher als eine führende und überzeugende Technologie für die Virtualisierung der Infrastruktur etabliert.

Docker-Übersicht

Container ermöglichen die Virtualisierung auf Betriebssystemebene, indem sie jede Anwendung als eigenen Betriebssystemprozess isolieren. Dieses Konzept existiert bereits in verschiedenen Formen in Betriebssystemen wie BSD mit Jails, Oracle Solaris mit Zones und seit Kurzem auch Linux mit LXC. Docker baut auf LXC auf und bietet eine besonders einfache Möglichkeit, mit der Entwickler Anwendungen erstellen, paketieren und in Cloud-Infrastrukturen bereitstellen können, ohne dass dafür ein Hypervisor erforderlich ist.

Die folgenden Funktionen unterscheiden Docker von anderen Container-Technologien:

• Eine schlanke Abstraktionsschicht (die Docker-Engine) auf dem Betriebssystem zur Verwaltung der Isolation und Vernetzung zwischen Anwendungen.
• Eine dokumentierte Programmierschnittstelle (API), die die Bereitstellung Linux-basierter Anwendungen vereinfacht.
• Die Docker Registry zum Teilen von Anwendungen mit anderen Benutzern und Entwicklern.
• Portabilität von Anwendungen zwischen Docker-fähigen Hosts, unabhängig davon, ob diese physisch, virtuell oder in der Cloud gehostet sind.
• Ein Union-Dateisystem, das allen Docker-Containern ein gemeinsames Dateisystem bereitstellt.
• Ein Ökosystem aus Partnerunternehmen, die Mehrwertdienste und Software anbieten und so eine nahtlose Integration von Docker in eine Vielzahl von Entwicklungsabläufen ermöglichen.

Was ist ein Union-Dateisystem?

Ein Union-Dateisystem ermöglicht es jedem Container, seine eigenen containerspezifischen Dienste bereitzustellen, selbst wenn der zugrunde liegende Pfad und Dateiname mit einer vorhandenen Datei kollidieren. Beispielsweise benötigt ein Container möglicherweise Version 2.6 einer Python-Bibliothek, während ein anderer eine neuere Version erfordert. Das zugrunde liegende Dateisystem stellt möglicherweise Version 2.6 bereit, sodass die Anforderungen des einen Containers erfüllt sind. Der Container, der die neuere Version benötigt, kann diese jedoch als Teil seines Container-Images bereitstellen. Dadurch verringert sich der Speicherbedarf von Container-Images, da sie nur das enthalten müssen, was für ihre Ausführung unbedingt erforderlich ist.

Zusammenfassung der Docker-Containerisierung und der Technologie virtueller Maschinen

Das Diagramm in Abbildung 1 veranschaulicht die Komponenten, die bei der Bereitstellung von Anwendungen mit virtuellen Maschinen und Docker zum Einsatz kommen. Beachten Sie, dass der VM-Ansatz in diesem Beispiel zwei Gastbetriebssysteme benötigt, um zwei Anwendungen zu unterstützen. Im Vergleich dazu benötigt Docker nur ein Hostbetriebssystem, um dieselbe Anwendungsdichte zu erreichen, und verursacht dabei natürlich einen geringeren Overhead.

Abbildung 1: Vergleich von virtuellen Maschinen und Docker-Containern auf einem einzelnen Host.

Die folgende Tabelle zeigt einen Vergleich der Funktionen von VMs und Docker.

Docker auf virtuellen Maschinen

Wie bereits erwähnt, besteht das Hauptziel von Docker darin, die Verwaltung des Anwendungslebenszyklus zu vereinfachen. Docker direkt auf physischer Hardware zu betreiben, ist zwar durchaus eine attraktive Option, doch auch der Betrieb von Docker auf Hypervisoren bietet Vorteile. Dazu gehören die Möglichkeit, Snapshots zu erstellen, sowie die Live-Migration eines vollständigen Gastsystems – beides kann eine zentrale Voraussetzung für die Notfallwiederherstellung sein, ohne den aktuellen Verarbeitungszustand zu verlieren.

Führende Lösungen für Infrastrukturmanagement und Orchestrierung wie VMware vRealize Suite und OpenStack sowie öffentliche Clouds wie AWS und Azure unterstützen Docker auf der jeweiligen Hypervisor-Variante, stellen dem Docker-Container jedoch eine einheitliche Umgebung bereit. Dadurch bleiben Anwendungen unabhängig von der Umgebung portierbar. Mit einem solchen heterogenen Bereitstellungsmodell können Kunden Docker einsetzen und von schnelleren Iterationszyklen profitieren, ohne die zugrunde liegende Infrastruktur ändern zu müssen.

Durch die Umstellung auf eine einzige VM und ein einziges Betriebssystem pro Host profitieren Kunden auch von einer besseren Ressourcennutzung, da die VM nicht mit anderen virtuellen Maschinen um Ressourcen konkurrieren muss. Diese Effizienzsteigerung ergibt sich daraus, dass Arbeitsspeicher und lokaler Festplattenspeicher vollständig diesem einen Betriebssystem zugewiesen werden können, während der Hypervisor nicht mehr zwischen mehreren Betriebssystemen vermitteln muss.

Technischer Überblick über Docker-Netzwerke

Mit der Netzwerkfunktion können Sie in Docker Engine virtuelle Netzwerke erstellen, die sich über mehrere Hosts erstrecken. Container können unabhängig von ihrem Standort mit diesen Netzwerken verbunden werden. Dadurch haben Sie die vollständige Kontrolle über die Netzwerktopologie und darüber, welche Container mit welchen anderen Netzwerkelementen kommunizieren können. Darüber hinaus lässt sich das zugrunde liegende Netzwerksystem durch ein Plug-in ersetzen, sodass Sie jedes gewünschte Netzwerksystem integrieren können, ohne die Anwendung ändern zu müssen.

Um eine hohe Container-Dichte auf einem Host zu ermöglichen, ist es wichtig, den Mechanismus zu verstehen, über den die einzelnen Container dem Netzwerk beitreten. Standardmäßig weist Docker jedem Container eine private Adresse zu, die nur von einem anderen Container auf demselben Host direkt erreichbar ist.

Damit Dienste einen Container von einem anderen Host aus erreichen können, müssen sie über die iptables-basierte Network-Address-Translation-Funktion (NAT) von Docker weitergeleitet werden. Ein Beispiel ist in Abbildung 2 dargestellt.

Abbildung 2: Dienste werden über die iptables-basierte NAT-Funktion von Docker weitergeleitet, um einen Container auf einem anderen Host zu erreichen.

Die Host-Schnittstelle (Eth0) ist über eine weitere Adresse erreichbar (in diesem Fall eine weitere RFC1918-Adresse, 192.168.10.10). Jedem Docker-Container wird beim Start automatisch eine Adresse aus dem Adressraum 172.x.x/16 zugewiesen. Damit ein Container bidirektional mit Entitäten außerhalb seines Hosts kommunizieren kann, muss ihm über iptables ein expliziter Regelsatz zugewiesen werden.

In dem in Abbildung 2 gezeigten Beispiel wurden die Regeln so konfiguriert, dass die Container über eine IP- und Portzuordnung kommunizieren können. Dabei ist Container A unter 192.168.10.10/Port 80 und Container B unter 192.168.10.10/Port 81 erreichbar. Container C kann jedoch nur über die Adressierung 172.17.0.x mit den beiden anderen Containern kommunizieren.

Docker unterstützt auch IPv6 und ermöglicht die Verwendung vollständig routingfähiger Adressen. Dadurch können Container mit anderen Containern auf verschiedenen Hosts kommunizieren, ohne dass eine Adresszuordnung erforderlich ist. Dies funktioniert jedoch nur mit IPv6 und ist daher in manchen Umgebungen möglicherweise nur eingeschränkt einsetzbar.

SDN und Docker

Viele softwaredefinierte Rechenzentren nutzen das Konzept des Software-Defined Networking (SDN), um ihre Gastsysteme flexibel bereitzustellen. Mit SDN lassen sich isolierte Netzwerktunnel für unabhängige Mandanten auf derselben physischen Hardware konfigurieren. Zudem kann SDN dazu dienen, innerhalb eines Cloud-Rechenzentrums, das ansonsten vollständig geroutet wäre, einen getunnelten Layer 2 bereitzustellen. Die Docker-Netzwerkarchitektur basiert auf dem Konzept der Docker Bridge, die mit einem Open vSwitch verbunden werden kann, um die Interoperabilität mit Technologien wie VXLAN oder GRE zu ermöglichen.

Durch den Einsatz von Open vSwitch auf diese Weise lassen sich Layer-2-Netzwerke für mehrere Mandanten voneinander trennen und Verbindungen zu anderen virtualisierten Umgebungen herstellen. So ist es beispielsweise wahrscheinlich, dass ein Rechenzentrum, das Docker einsetzt, weiterhin virtuelle Maschinen für zentrale Dienste verwendet, für die fest zugewiesene Ressourcen reserviert werden müssen. Dabei kann es sich um Dienste zur Anwendungsbereitstellung oder um Hochleistungsressourcen wie Datenbanken und Verarbeitungsknoten handeln. Diese Ressourcen können über Technologien wie VXLAN oder GRE mit dem Netzwerk verbunden werden, sodass der Datenverkehr eines Mandanten für andere Mandanten nicht sichtbar ist.

Die Skalierung von Anwendungen in einer solchen Umgebung erfordert ADC-Dienste, die auch nativ an den Tunneling-Protokollen teilnehmen können. F5 bietet mandantenfähige VXLAN- und GRE-Funktionen, sodass Dienste wie Lastverteilung, SSL-Offloading, Firewalling, Anwendungssicherheit, NAT und DNS den Clients im Netzwerk über einen Tunnel bereitgestellt werden können. Darüber hinaus ermöglicht F5 die Interoperabilität zwischen verschiedenen Tunnelkapselungstypen, einschließlich 802.1Q-VLANs.

Abbildung 3: F5 ermöglicht die Interoperabilität zwischen verschiedenen Tunnelkapselungstypen, einschließlich 802.1Q-VLANs.

In dem in Abbildung 3 dargestellten Beispiel können sich zentrale Anwendungsebenen wie etwa eine Datenbank in einem anderen Bereich des Rechenzentrums befinden als die Ressourcen, auf denen Docker-Instanzen gehostet werden. In einem solchen Fall kann das Mandantennetzwerk GRE oder VXLAN verwenden, um die beiden ansonsten physisch getrennten Subnetze voneinander zu isolieren und miteinander zu verbinden.

Eine BIG-IP-Lösung lässt sich nahtlos auf Mandantenebene in das Netzwerk integrieren, indem auf der BIG-IP-Instanz ein VXLAN-Tunnelendpunkt (VTEP) erstellt wird. Sie wird dadurch Teil des Mandantennetzwerks und kann eine Verbindung zu den Docker- und virtuellen Maschineninstanzen herstellen.

Ab Version 1.7 bot Docker einige experimentelle Funktionen an, die die grundlegenden Netzwerkfunktionen von Docker um SDN-Konzepte erweitern. Die Plug-in-Architektur eröffnet eine vielversprechende Möglichkeit, Netzwerk- und Anwendungsbereitstellungsdienste von F5 für eine Vielzahl neuer Anwendungsfälle zu integrieren, darunter Firewalls der nächsten Generation mit anwendungsorientierten Containern, die Analyse von Container-Datenströmen und die Durchsetzung von Richtlinien sowie die Datenverkehrssteuerung auf Datenstromebene.

F5-Strategie zur Docker-Containerisierung

F5 bietet eine Reihe von Produkten zur Unterstützung der Virtualisierung an. Als Marktführer im ADC-Bereich mit dem branchenweit umfassendsten Portfolio an Anwendungsbereitstellungs- und Sicherheitsdiensten für L4–L7 erforscht F5 kontinuierlich innovative Technologien und weitet deren Einsatz auf BIG-IP Plattformen aus, da sie alle auf einem gemeinsamen Framework basieren. Abbildung 4 zeigt das Spektrum der Produktangebote von F5 – von kundenspezifischer Hardware bis hin zu vollständigen cloudbasierten As-a-Service-Angeboten für L4-L7-Dienste. Die BIG-IP Plattform ist bestens dafür geeignet, Anwendungen zu unterstützen, die in Docker-Containern ausgeführt werden.

Abbildung 4: F5 bietet über eine einheitliche Plattform ein umfassendes Spektrum an Diensten für die Anwendungsbereitstellung und -sicherheit.

Weiterentwicklung der F5-Plattform mit Docker

Wie bereits erwähnt, erkennt F5 die Vorteile von Docker für verschiedene Anwendungsfälle. Die Bereitstellung in containerisierten Infrastrukturen steckt jedoch noch in den Kinderschuhen, und für die Serviceerkennung (etwa Consul, etcd und Mesos-DNS), die Orchestrierung sowie die Verwaltung des Lebenszyklus von Containerdiensten (unter anderem Mesos, OpenStack, Kubernetes, Docker und Cloud Foundry) stehen zahlreiche Optionen zur Verfügung. Netzwerkdienste sind zwar ein entscheidender Bestandteil dieses Ökosystems, doch eine enge Integration in die Orchestrierungsumgebung ist wichtig, um eine reibungslose Bereitstellung zu gewährleisten. Eine solche Integration ist außerdem unerlässlich, damit L4-L7-Dienste für Benutzer, die auf Microservices basierende Anwendungen in einer containerisierten Infrastruktur bereitstellen, verfügbar und transparent sind. Der Ansatz von F5 zielt darauf ab, sowohl bei den Diensten als auch bei der Visualisierung eine einheitliche Benutzererfahrung über Bare-Metal-, virtualisierte und containerisierte Bereitstellungen hinweg zu bieten.

Der erste Schritt zur Lösung des Problems besteht darin, Netzwerkdienste für den Nord-Süd-Datenverkehr (N-S) bereitzustellen (also für den Datenverkehr der „clientseitig ausgerichteten Microservices“). Die meisten führenden Orchestrierungsplattformen übernehmen die Bereitstellung und Skalierung containerisierter Dienste und machen deren Verbindungen nach außen zugänglich. Durch die enge Integration mit führenden Plattformen zur Container-Orchestrierung stellt F5 sicher, dass N-S-Microservices automatisch von BIG-IP-Systemen erkannt werden, die anschließend den Datenverkehr für diese Dienste verwalten können. Mesosphere Marathon und Kubernetes bieten beispielsweise die Möglichkeit, Dienste mit „Labels“ zu versehen. Mithilfe dieser Labels können clientseitig ausgerichtete Dienste erkannt werden, wenn sie gestartet, beendet oder skaliert werden, und automatisch als Pool-Mitglieder zum BIG-IP-System hinzugefügt werden.

Der oben beschriebene Ansatz mit BIG-IP-Hardware oder virtuellen Editionen (VEs) ermöglicht die Zentralisierung kritischer Funktionen mit Hardwarebeschleunigung, wie zum Beispiel:

• SSL-Offloading mit zentralisierter Zertifikatsverwaltung.
• Beschleunigung durch Komprimierung, TCP-Optimierung und SPDY/HTTP2.
• Fortschrittliche Firewall-Funktionen mit DoS-Schutz.
• Anwendungsverständnis zur Abwehr von Angriffen auf der Anwendungsebene.
• Transparenz für alle ein- und ausgehenden Netzwerkverbindungen.
• Deutlich verbesserte Fehlerbehebung durch intelligente Protokollierung und Anomalieerkennung.

F5 und IPv4-zu-IPv6-Übersetzung mit DNS-Unterstützung

F5-Lösungen ermöglichen die Skalierung containerisierter Anwendungen sowie die IPv4-zu-IPv6- und DNS-Übersetzung zwischen der Docker-Infrastruktur und dem externen Netzwerk. Um eine vollständig routingfähige Docker-Container-Infrastruktur nutzen zu können, benötigen Unternehmen nicht nur eine effiziente Netzwerkfunktion für die Übersetzung von IPv4 zu IPv6, sondern auch Unterstützung bei der Übersetzung von DNS-Anfragen. Die Docker-Container-Infrastruktur kann ausschließlich mit IPv6 betrieben werden und vollständig von IPv4 isoliert sein, während gleichzeitig eine nahtlose Verbindung zu IPv4 gewährleistet bleibt.

Abbildung 5: BIG-IP-Systeme führen sowohl DNS64 als auch NAT64 aus, um IPv6-zu-IPv4-Konnektivität zu ermöglichen.

In dem in Abbildung 5 gezeigten Beispiel wurden NAT64- und DNS64-Dienste bereitgestellt (wiederum in beliebiger physischer oder virtueller Form). Der Docker-Container versucht, eine Verbindung zu www.example.com herzustellen, wofür in diesem Beispiel keine IPv6-Adresse vorhanden ist.

Das BIG-IP-System ist als DNS-Resolver für die Docker-Plattforminstallation konfiguriert. Es verfügt über eine IPv6-Adresse für den DNS-Resolver selbst sowie über eine spezielle IPv6-Präfixadresse (rot dargestellt) für die Übersetzung von IPv4 in IPv6.

Sobald das BIG-IP-Gerät die IPv6-DNS-Abfrage empfangen hat, führt es zunächst eine rekursive Abfrage durch, um festzustellen, ob eine IPv6-Adresse verfügbar ist. In diesem Beispiel antwortet der autoritative DNS-Server für www.example.com jedoch mit einem leeren Datensatz auf die AAAA-Anfrage. Anschließend führt das BIG-IP-Gerät eine IPv4-Abfrage durch und erhält daraufhin einen DNS-A-Eintrag. Es stellt der IPv4-Adresse die spezielle Präfixadresse voran und sendet das Ergebnis an den Docker-Client zurück.

Der Docker-Client hat die Adresse nun aufgelöst und baut eine TCP-Verbindung auf. Da Docker das spezielle Präfix verwendet, erkennt die NAT64-Funktion, dass eine Übersetzung von IPv6 in IPv4 erforderlich ist.

Die NAT64-Funktion erstellt eine Zuordnung für die Verbindung zwischen der Docker-IPv6-Adresse, der mit einem speziellen Präfix versehenen NAT64-Adresse für diesen IPv4-Server und dem IPv4-Server. Die Verbindungsanfrage wird an den IPv4-Server gesendet. Alle Antworten dieses Servers, der über IPv4 antwortet, werden von der NAT64-Funktion übersetzt, um die Verbindung zwischen dem Docker-Container und dem IPv4-Server zu ermöglichen.

F5 und Ost-West-Datenverkehrsflüsse

Der nächste entscheidende Schritt für eine enge Integration besteht darin, Dienste für den Ost-West-Datenverkehr (O-W) bereitzustellen, also für Daten, die zwischen Microservices übertragen werden und ADC-Dienste benötigen. Angesichts der Notwendigkeit, Dienste innerhalb von Sekunden bereitzustellen, und der Kurzlebigkeit von Microservices setzt F5 auf einen schlanken ADC. (Für erweiterte Dienste wie Authentifizierung oder Anwendungsschutz auf Layer 7 wird der Datenverkehr an die BIG-IP-Instanz am Nord-Süd-Netzwerkrand umgeleitet.)

Die Anzahl der containerisierten Dienste in einer Microservices-Architektur ist wesentlich höher als in einer herkömmlichen Architektur, wobei es mehrere Kommunikationspfade zwischen den Microservices gibt. Eine wahrscheinliche Begleiterscheinung dieser Architektur ist eine höhere Komplexität, die die Behebung von Leistungsproblemen erschwert. Wenn beispielsweise eine Anwendung eine geringe Leistung aufweist, ist eine durchgängige Transparenz über verschiedene Dienste hinweg bis zum N-S-Edge wichtig. Daher ist ein zentralisierter Visualisierungsansatz, der die Datenverkehrsmuster zwischen dem BIG-IP-System in der N-S-Domäne und dem schlanken ADC in der E-W-Domäne korrelieren kann, für die Fehlerbehebung von entscheidender Bedeutung.

Instanzen von F5 BIG-IP-Lösungen können auch zwischen Anwendungen eingefügt werden, um Lastausgleichs- oder Sicherheitsdienste bereitzustellen und so Sicherheitsbedenken beim Ost-West-Datenverkehr auszuräumen. Beispielsweise kann ein Docker-Host so konfiguriert werden, dass der Datenverkehr aus einem Container zur Analyse durch ein BIG-IP-System geleitet wird, bevor er in einen anderen Container gelangt. Dies kann mithilfe von BIG-IP Application Security Manager™ (ASM) erfolgen, der Anwendungen versteht und erkennen kann, ob der betreffende Container angegriffen wird, etwa durch das Ausnutzen einer Schwachstelle.

Der stufenweise Ansatz von F5 zur Bereitstellung von Docker-Diensten

Viele erfolgreiche Implementierungen von F5-Kunden nutzen heute Containerisierung in sehr großem Umfang. Diese Unternehmen sind in zahlreichen Branchen tätig, darunter Finanzdienstleistungen, Telekommunikation und SaaS. F5-Lösungen stellen in diesen Umgebungen derzeit ADC-Dienste bereit, um schnelle, sichere und verfügbare Anwendungen zu gewährleisten. Diese Dienste können so integriert werden, dass Anwendungseigentümer oder DevOps-Teams sie im Self-Service nutzen können – oder sie lassen sich über das Container-Management-System orchestrieren.

F5 plant, diese Services auf die containerisierte Infrastruktur selbst auszuweiten, um Service Discovery, Ost-West-Datenverkehrsmanagement und Sicherheit abzudecken. Darüber hinaus plant F5, die Containerisierung innerhalb seines Produktportfolios zu nutzen, indem das Unternehmen die Technologie auf physischen Plattformen einsetzt, Software-Services in Containern anbietet und die containerisierte Architektur innerhalb der cloudbasierten Serviceplattform F5 Silverline® verwendet.

Die folgende Tabelle gibt einen Einblick in die Bereiche, die F5 derzeit untersucht oder aktiv weiterentwickelt:

Fazit

Docker bietet klare Möglichkeiten, die Effizienz von Rechenzentren zu steigern – unabhängig davon, ob diese physisch oder cloudbasiert sind. Gleichzeitig können Unternehmen, die Docker einsetzen, sicherer sein, dass sich ihre Anwendungen in neue Umgebungen übertragen lassen. Entscheidend ist, dass Docker Anwendungsentwicklern mehr Agilität ermöglicht und sie Anwendungen schneller auf den Markt bringen können. Bei der Weiterentwicklung ihrer DevOps hin zum Docker-Modell nutzen Kunden häufig die Gelegenheit, neue Self-Service-Workflows einzuführen, die auf kleineren standardisierten Diensten basieren, auf denen Entwickler ihre Anwendungen bereitstellen können.

Docker ermöglicht die schnelle Skalierung von Anwendungen durch die Instanziierung schlanker Container, und die Application-Delivery-Produkte von F5 unterstützen solche Umgebungen vollständig. Mit F5 BIG-IP Lösungen können Kunden den gesamten Lebenszyklus einer Anwendung orchestrieren. Dies erfolgt über umfassende REST-APIs für kritische Vorgänge wie die Erstellung und Verwaltung von VIPs, die zentrale SSL-/Zertifikatsverwaltung, Firewall-Dienste und Anwendungssicherheit mit Hochverfügbarkeit in einer mandantenfähigen Architektur.

Docker kann in einer Vielzahl von Modellen eingesetzt werden, darunter Bereitstellungen in öffentlichen und privaten Clouds. F5 nimmt bei der Bereitstellung von Interoperabilität und Unterstützung für diese Umgebungen eine führende Rolle ein und bietet zentrale Funktionen, die speziell auf OpenStack, VMware und große Cloud-Anbieter wie Amazon AWS und Microsoft Azure zugeschnitten sind.

Kunden, die auf ein weiterentwickeltes DevOps-Modell umsteigen, in dem Docker eine zentrale Rolle spielt, wissen, dass die potenziell erzielbaren betrieblichen Verbesserungen von einer Plattform abhängen, die skalierbar, sicher, hochverfügbar und so agil ist, wie es neue Workflows erfordern. Die Produkte und Services von F5 sind darauf ausgelegt, mit dem breitesten Spektrum an Technologien und Technologiepartnern der Branche zusammenzuarbeiten, um das Potenzial der Docker-Vision auszuschöpfen. Das Engagement von F5 für Docker wird durch solide Investitionen in die Produkt-Roadmap und kontinuierliche Produktverbesserungen untermauert. So wird der Erfolg eines Modells sichergestellt, das sich zu einem der vorherrschenden Bereitstellungsmodelle für das softwaredefinierte Rechenzentrum entwickeln wird.

VERÖFFENTLICHT AM 20. JUNI 2016