Eclipse & Docker

Docker Tooling in Eclipse: Ran an die Container!

Jeff Johnston, Roland Grunberg

@istock/palau83

Egal, wen man heutzutage nach den wichtigsten Themen aus der Softwarebranche fragt, immer wird das Wort „Container“ fallen. Container sind leichtgewichtige virtuelle Maschinen, die auf Prozesslevel arbeiten. Sie können sehr schnell instanziiert werden und sind leicht zu konfigurieren. Wer in die Welt der Container eintauchen möchte, wird dabei zweifellos über den Namen Docker stolpern. Docker ist einerseits der Markenname eines Unternehmens, wird aber auch als Bezeichnung für dessen Containertechnologie verwendet, die immer mehr zum allgegenwärtigen Standard wird.

Zu Beginn ist ein wenig Terminologie notwendig. Ein Image ist ein Template zur Erstellung eines Containers. Ein Container ist eine Instanz eines Images, in dem sich Prozesse oder Anwendungen zusammen mit einer bestimmten Umgebungsspezifikation befinden. Es gibt eine große Anzahl fertiger Docker Images für verschiedene Betriebssystemen im Netz (z. B. Fedora, Ubuntu, Solaris). Vorhandene Images können modifiziert und als neue Images gespeichert werden, um sie später wiederzuverwenden. Beispielsweise kann ein Fedora 22 Image verwendet werden, um darauf SSH zu installieren. Speichern Sie es als neues Image ab und verwenden Sie es immer, wenn eine Anwendung SSH in einem Container benötigt.

Images werden in einer Registry abgelegt und haben eine ID, die aus einem Repository und einem Tag besteht. Der Name fedora:22 steht beispielsweise für das Fedora 22 OS aus dem Fedora Repository. Um ein Image lokal zu verwenden, muss es zuerst aus einer Registry geladen werden (pull). Um es mit anderen zu teilen, wird es in eine Registry gepusht. Es gibt eine Standard-Docker-Registry namens Docker Hub, wo sich die grundlegenden OS Images befinden. Diese Images sind frei verfügbar. Wer die Images verändern oder eigene erzeugen möchte, muss einen persönlichen Docker-Hub-Account anlegen und die Images in sein persönliches Repository laden. Ein persönliches Repository ist daran erkennbar, dass der Name der Image-ID als Präfix vorangestellt wird, zum Beispiel: jjohnstn/fedora:22. Diese Images können dann auch mit anderen geteilt und modifiziert werden usw. Außerdem können bei Bedarf private Registrys angelegt werden. In diesem Fall muss der Registry-Name als Teil der Image-ID spezifiziert werden: registry/repository:tag bedeutet, dass nicht die Standard-Registry des Docker Hubs verwendet wird.

Vorhandene Images können auf zwei Wegen angepasst werden. Einerseits kann dafür eine spezielle Datei namens Dockerfile verwendet werden, die Informationen darüber enthält, welches Image die Basis darstellt und welche Anpassungen gewünscht sind (z. B. die Installation verschiedener Pakete, Systemkonfigurationen, das Setzen von Umgebungsvariablen etc.). Andererseits können Images modifiziert werden, indem ein Container erstellt wird, der eine Shell startet, über die dann Aktionen im Container ausgeführt werden – etwa die Installation von Paketen, Konfigurationen usw. Sobald alle Modifikationen erledigt sind, wird der Container als neues Image abgelegt.

Um Docker zu verwenden, muss zuerst der Docker daemon gestartet werden. Der Docker daemon kennt den Docker Hub und wird verwendet, um die lokalen Docker Images und Container zu verwalten. Der daemon kann unter Linux so eingestellt werden, dass er als Systemservice startet, kann aber auch manuell über den Befehl docker gestartet werden (bei Befehlen die Kleinschreibung beachten!). Die Anweisung docker wird außerdem verwendet, um verschiedene Tasks für Docker Images und Container auszuführen sowie für den Registry-Support. Unter manchen Systemen, beispielsweise unter Windows, kann der Docker daemon nicht lokal gestartet werden. In diesem Fall kann die Docker Machine benutzt werden, um den Docker daemon in einer virtuellen Maschine zu starten. Die Docker Machine stellt dem Host zudem alle benötigten Zertifikate für die Verbindung mit dem Docker deamon zur Verfügung und exportiert Umgebungsvariablen, die alle zur Kommunikation notwendigen Informationen (z. B. TCP-Adressen) enthalten. Früher hätte man dafür boot2docker verwendet; dieser Weg gilt allerdings als veraltet.

Das Docker-Tooling-Projekt

Seit Herbst 2014 haben Mitglieder des Eclipse Linux Tools Project von Red Hat (Jeff Johnston, Roland Grunberg und Xavier Coulon) Plug-ins für die Verwaltung von Docker Images und Containern innerhalb von Eclipse entwickelt. Damit sollen einige der Funktionen nachgebildet werden, die ansonsten nur über den docker-Befehl zugänglich sind, und über ein robustes UI zugänglich gemacht werden. Um mit dem Docker daemon zu kommunizieren, kommt eine Java API Library zum Einsatz. Zu Beginn des Docker-Tooling-Projekts waren zwei öffentliche Java API Librarys verfügbar: docker-java und docker-client. Doch lediglich docker-client (von Spotify) unterstützte Unix Sockets, die zur Standardkonfiguration des Docker daemon unter Linux gehören. Obwohl der Docker daemon auch das Einrichten von TCP Sockets erlaubt, müsste der Nutzer dafür natürlich eine spezielle Option beim daemon-Start-up hinzufügen, was als zu mühsam abgelehnt wurde. Es muss hier angemerkt werden, dass die andere damals verfügbare Java API Library (docker-java) inzwischen auch eine Unterstützung für Unix Sockets bietet.

Während docker-client also die Unterstützung für Unix bereitstellte, wurde diese aber mit einem Package implementiert, das die nur wenig gebräuchliche unix-socket-factory enthielt, die wiederum die Socket-Funktionalität aus einem anderen schlecht unterhaltenen Package namens junixsocket nutzte. Es wurde deshalb ein Patch eingereicht, um docker-client so anzupassen, um JNR Unix Sockets zu nutzen, der auch sofort angenommen wurde.

Die Docker-Tooling-Plug-ins der Linux Tools wurden erfolgreich mit dem Linux-Tools-4.0-Release ausgeliefert, die in Eclipse Mars im Juni 2015 enthalten waren. Sie wurden als Teil der Linux Tools 4.1 aktualisiert, die mit dem Eclipse Mars Update 1 im September 2015 verteilt wurden.

Der Einstieg

Wenden wir uns nun der Arbeit mit den Docker Tools zu. Unter Linux müssen die entsprechenden Docker Packages auf dem System installiert werden. Unter Windows wird die Docker Machine benutzt, um eine virtuelle Maschine zu starten, in der der Docker daemon läuft. In Eclipse ist zuerst die Installation des Mars Updates 1 von Eclipse notwendig und dann die des Docker Tooling Features, das von der üblichen Mars-Update-Seite bezogen werden kann (HELP| INSTALL NEW SOFTWARE…).

Bevor Eclipse gestartet wird, muss sichergestellt werden, dass der Docker daemon läuft. Wenn Sie danach Eclipse starten, erscheint eine neue Perspektive namens „Docker Tooling“. Wechseln Sie auf diese Perspektive. Sie besteht aus drei neuen Views: Docker Explorer, Docker Images und Docker Container; zusammen mit der Standard-Eclipse-Konsole und den Properties Views. Beim ersten Start Ihres Workspace wird keine Verbindung zum Docker daemon hergestellt, also sollten Sie die in Abbildung 1 gezeigten Einstellungen sehen.

Abb. 1: Docker-Tooling-Perspektive beim ersten Workspace-Start

Abb. 1: Docker-Tooling-Perspektive beim ersten Workspace-Start

Wenn Sie auf die Nachricht klicken, die in der Docker Explorer View angezeigt wird, erscheint der New Connection Wizard (Abb. 2).

Abb. 2: New Connection Wizard

Abb. 2: New Connection Wizard

Der New Connetion Wizard versucht beim Start Standardwerte einzusetzen. Unter Linux testet er, ob /var/run/docker.sock lesbar ist. In diesem Fall setzt er den Unix Socket als Default ein. Andernfalls fragt der Wizard Umgebungsvariablen ab, um die Default-TCP-Einstellungen vorzunehmen: DOCKER_HOST, DOCKER_TLS_VERIFY und DOCKER_CERT_PATH. Der Wizard schlägt einen Namen für die Verbindung vor, den Sie aber ändern können. Der Search-Button wird dazu benutzt, lokal laufende Docker-Machine-Instanzen zu finden. Sie können die Verbindung auch testen, indem Sie den Test-Connection-Button benutzen, um sicherzustellen, dass der daemon läuft und korrekt antwortet. Eine neue Verbindung kann jederzeit über die Toolbar der Docker Explorer View erstellt werden.

Sobald die Verbindung aufgebaut ist, wird sie zur aktiven Standardverbindung. Das Ergebnis sieht wie in Abbildung 3 gezeigt aus.

Abb. 3: Nach geglücktem Verbindungsaufbau

Abb. 3: Nach geglücktem Verbindungsaufbau

Um die aktive Verbindung zu ändern, klicken Sie einfach auf einen der Nodes in der Docker Explorer View. Das Docker Image und die Docker Container Views zeigen dann abhängig von der gewählten Verbindung Inhalte an. Diese Listen sind auch in der Docker Explorer Tree View verfügbar, indem ein Connection Node ausgeklappt wird und entweder Images oder Container angeklickt werden.

Standardmäßig wird die Auflistung der Images und Container gefiltert. Images ohne Tags und „intermediate“ Images sowie gestoppte Container werden nicht angezeigt. Diese Einstellungen können über die Docker Explorer View im Drop-down-Menü CUSTOMIZE VIEW geändert werden.

Pulling Images

Als Nächstes müssen Sie sich Images besorgen, die Sie laufen lassen können. Wenn Sie den Docker daemon erstmalig starten, sind noch keine Images vorhanden. Images müssen aus einer Registry gezogen werden. Der Docker daemon ist standardmäßig auf die Docker Hub Registry ausgerichtet, aber es können auch private Registries verwendet werden.

Um ein Image zu laden, klicken Sie mit der rechten Maustaste auf den Images Node in der Docker Explorer View oder verwenden Sie die Docker Images View Toolbar. Diese enthält folgende Aktionen:

  • – Ein Image aus dem Repository laden (pull)
  • – Ein Image ins Repository pushen
  • – Ein Image laufen lassen und einen Container erstellen
  • – Ein Image aus einem Dockerfile erstellen
  • – Ein Image oder mehrere Löschen (Bestätigung nötig)
  • – Ein Image taggen
  • – Die Image-Liste aktualisieren

Wählen Sie PULL AN IMAGE und spezifizieren Sie den Image-Namen in einer der folgenden Formen:

  • <repository>[:<tag>], wobei <repository> entweder <username/reponame> oder <reponame> sein kann.
  • <registry>:<repository>:<tag>, wobei <registry> entweder ein das Zeichen „.“ enthält oder mit einer Portspezifikation endet (:port).

Sie können außerdem die Docker Hub Registry über den Search-Button durchsuchen. Hier geben Sie für unser Beispiel fedora:latest als Image-Tag an. Private Registries sind bisher allerdings nicht durchsuchbar.

Ein Image zu laden, kann lange dauern. Das liegt daran, dass ein Image mehrere zwischengeschaltete Images nutzen kann, die jeweils recht groß sein können. Das Docker Tooling verfügt über einzelne Statusanzeigen, die den Ladefortschritt der Downloads mehrerer benötigter Images anzeigen, sowie eine Hauptanzeige, um den gesamten Downloadfortschritt zu überwachen. Sobald der Download vollständig ist, werden Docker Explorer View und Docker Images View automatisch aktualisiert.

Images starten

Jetzt haben Sie ein oder mehrere Images geladen und können damit einen Container erstellen und starten. Dazu verwenden Sie die Aktion Run Image. Das ist einerseits über einen Rechtsklick auf das entsprechende Image in der Docker Explorer View möglich, andererseits über die Docker Images Toolbar. Dafür wird das Image fedora:latest in der Docker Explorer View ausgewählt, das wir gerade geladen haben. Wählen Sie nun Run Image aus, nachdem Sie mit der rechten Maustaste auf das Image geklickt haben. Dadurch öffnet sich der Run Image Wizard (Abb. 4).

Abb. 4: Run Image Wizard

Abb. 4: Run Image Wizard

Über die erste Seite des Wizards können einige allgemeine Einstellungen vorgenommen werden:

  • Image: Dieses Feld wird automatisch entsprechend der Auswahl des Nutzers ausgefüllt. Andere Images sind über das Drop-down-Menü verfügbar. Der Nutzer kann auch ein aktuell nicht geladenes Image eingeben und auf den Pull-Image-Link klicken.
  • Name: In dieses Feld kommt der Name des neuen Images.
  • Entry Point: Darüber kann der Container so eingestellt werden, dass er als Executable läuft. Der Entry Point ist ein zu startendes Executable plus Argumente. In der Kommandozeile können zusätzliche Argumente spezifiziert werden.
  • Command: Das ist der Befehl, der im Container ausgeführt werden soll, wenn er startet. Das Feld kann leer gelassen werden, wenn das Image einen Standardbefehl hat, der ausgeführt werden soll.
  • Ports: Der Nutzer kann hier wählen, ob er Ports aus dem Container exponieren möchte (selbsterklärend).
  • Links: Verlinkungen auf andere Container.
  • Keep Stdin Open: Wird verwendet, um Input über die Konsole zu erlauben.
  • Allocate Pseudo-tty: Wird verwendet, um ein TTY für den Container zuzuweisen (notwendig bei der Nutzung einer Shell).
  • Automatically Remove the Container on Exit: Wird verwendet, um Container am Ende zu entfernen.

Die zweite Seite des Wizards zeigt die Einstellungen aus Abbildung 5.

Abb. 5: Seite 2 des Run Image Wizards

Abb. 5: Seite 2 des Run Image Wizards

  • Data Volumes: Der Nutzer kann Host Volumes im Container nutzen oder andere Container Volumes mounten. Das ist nützlich, um Daten vom Host in den Container zu kopieren (z. B. ein Executable).
  • Environment Variables: Ein Weg zur Spezifikation von Umgebungsvariablen, die im Container verwendet werden sollen.
  • Enable Resource Limits: Wird verwendet, um die Arbeitsspeicher- oder CPU-Auslastung für einen Container einzuschränken.

Deaktivieren Sie nun die Optionen tty und interactive und schreiben Sie in die Kommandotextbox:

 echo "!!!Hello World!!!" 

Klicken Sie auf den Finish-Button. Dadurch wird ein Container erzeugt und gestartet. Sobald der Container läuft, werden die Logs in der Console View angezeigt.

Per Default öffnet sich eine neue Konsole, wenn ein Container über den Run Image Wizard des Docker Toolings gestartet wird. Alternativ wird die Aktion Display Log für laufende oder gestoppte Container verwendet – entweder aus der Docker Explorer View oder der Docker Containers View (Abb. 6).

Abb. 6: Container-Logging

Abb. 6: Container-Logging

Jedem Eintrag im Log steht in unserem Beispiel ein Zeitstempel voran. Das ist das Standardverhalten, außer wenn die tty-Option gewählt wird und das Log über WINDOW | PREFRENCES | DOCKER | LOGGING kontrolliert wird. Der Zeitstempel ist bei wiederholten Containerstarts nützlich, um die Logs der verschiedenen Durchläufe zu betrachten. Gehen Sie in die Docker Container View und verwenden Sie das View-Drop-down-Menü, um sicherzustellen, dass alle Container angezeigt werden. Danach suchen Sie den Container, den Sie gerade gestartet haben, wählen ihn aus und klicken auf den Starbutton in der Toolbar. Der Container wird erneut starten, und Sie sehen zwei Nachrichten mit verschiedenen Zeitstempeln.

Jeder Containerlog erhält seine eigene separate Konsole in der Console View. Um eine Konsole zu löschen, verwenden Sie die Kontextmenüaktion Remove Console für den spezifischen Container. Das geht entweder über die Docker Explorer View oder über die Docker Containers View. Das Löschen ist allerdings nicht über die Console View möglich. Die Konsole kann später erneut angezeigt werden, indem die Kontextmenüaktion Display Logs für einen Container benutzt wird, egal ob dieser läuft oder angehalten ist.

Images erstellen

Nehmen wir an, dass das Kommando, das Sie in Ihrem Container ausführen wollen, voraussetzt, dass Valgrind installiert ist. Doch das Standardimage fedora:latest, das Sie oben verwendet haben, enthält Valgrind nicht. Was machen Sie jetzt? Nun, Sie bauen Ihr eigenes Image auf der Basis des fedora:latest Images und installieren Valgrind als Teil des Build-Prozesses.

Um ein neues Image zu erstellen, brauchen Sie ein bestehendes und modifizieren es dann. Typischerweise beinhaltet das Modifizieren eines Images, dass neue Pakete installiert werden. Die Spezifikation des neuen Docker Images wird über eine besondere Datei vorgenommen, die immer Dockerfile heißt.

Es gibt zwei Wege, über die ein Image Build angegangen werden kann. Durch einen Klick auf das Build-Image-Icon startet der Build Image Wizard, wo Sie das Tag des neuen Images und das Verzeichnis spezifizieren können, welches das Dockerfile enthält. Beachten Sie, dass für die Erstellung eines neuen Images der vollständige Lesezugriff auf das Verzeichnis und seine Unterverzeichnisse erforderlich ist. Wenn es nötig ist, ein Dockerfile im Verzeichnis zu editieren oder zu erzeugen, öffnet der Edit-Button im Build Image Wizard einen rudimentären Dockerfile-Editor mit Clipboard-Support (Copy/Cut/Paste) (Abb. 7).

Abb. 7: Dockerfile Editor

Abb. 7: Dockerfile Editor

Alternativ können Image Builds auch über den Dialog RUN| RUN CONFIGURATIONS… erstellt werden. Dort muss doppelt auf die Launch-Kategorie Build Docker Image geklickt werden. Der Main-Tab wird verwendet, um eine Docker-Verbindung zu spezifizieren und einen Quellpfad anzugeben (Workspace oder Dateisystem), an dem sich ein existierendes Dockerfile befindet. Sie können den Standardtexteditor von Eclipse verwenden, um ein solches Dockerfile zu erstellen oder zu modifizieren.

Das Dockerfile enthält selbst eine Reihe von Befehlen zur Erzeugung eines Images. Details zum Erstellen von Dockerfiles finden sich in der Docker-Dokumentation.

In unserem Beispiel haben wir Valgrind über den yum-Befehl installiert. Unter einem anderen Basis-OS kann das etwas anders aussehen (z. B. apt-get). Wir haben außerdem einen Standardbefehl festgelegt. Wenn das Image gestartet wird, kann die Spezifikation eines Kommandos auch weggelassen werden. Der Container würde dann einfach valgrind –v starten, wodurch die installierte Version von Valgrind angezeigt wird.

Das Gleiche kann auch erreicht werden, wenn Sie eine /bin/sh-Shell ausführen, die als Kommando für das Starten des Basisimages fedora:latest definiert wird. Wenn die interactive– und tty-Optionen gewählt werden, wird dadurch eine interaktive Konsole erzeugt. Darüber kann Valgrind dann mit dem oben genannten yum-Kommando installiert werden. Als Letztes wird der Container entweder in der Docker Explorer View oder der Docker Containers View ausgewählt und mit der rechten Maustaste angeklickt. Über die Commit-Container-Option öffnet sich der Commit Container Wizard, worüber dann der Tag-Name eingegeben wird. Der Container mit dem neu installierten Paket wird nun als Image unter dem gerade angegebenen Tag abgespeichert (z. B.: fedora:latest-with-valgrind).

C-/C++-Anwendungen in einem Container starten

Seit Version 8.7.0 der CDT (C/C++ Development Tools) und Version 4.0.0 der Linux Tools in Eclipse Mars ist es möglich, das Binary Target von C-/C++-Projekten in einem Container auszuführen. Um damit zu arbeiten, stellen Sie sicher, dass Sie sowohl die C/C++ Development Tools als auch das optionale C/C++ Docker Container Launch Feature installiert haben. Beide können von der Eclipse-Mars-Update-Seite heruntergeladen werden (HELP| INSTALL NEW SOFTWARE…).

Wechseln Sie über OPEN PERSPECTIVE (neben der Liste der Perspektiven oben rechts) zur C-/C++-Perspektive. Erstellen Sie ein neues C-Projekt (FILE| NEW… | C PROJECT). Dadurch öffnet sich der „New C Project“-Wizard. Öffnen Sie den Executable Node und wählen Sie das Hello World Ansi C Project aus. Rechts muss eine passende Tool Chain ausgewählt werden (beispielsweise Linux gcc, wenn Sie Linux verwenden). Das Projekt nennen Sie helloworld und klicken danach auf Finish.

Öffnen Sie WINDOW | PREFERENCES | C/C++ | DOCKER CONTAINER und geben Sie in das Default Image Window fedora:latest ein. Dadurch wird das fedora:latest-Image standardmäßig vom C/C++ Launcher zum Start eines Containers verwendet. Wenn Sie möchten, dass der Container nach der Ausführung noch existiert, wählen Sie die Option „Keep Container after launch“, dann auf OK klicken und den Preferences-Dialog verlassen.

Wählen Sie nun das neue Projekt über den Projekt Explorer aus und klicken dann auf das Hammericon in der Eclipse Toolbar. Dadurch wird das neue C-Projekt erstellt. Klappen Sie Ihr Projekt im Project Explorer auf und öffnen Sie den dortigen Binaries-Ordner. Es handelt sich dabei um einen virtuellen Ordner, der die Binaries anzeigt, die von Ihrem C-Projekt erstellt wurden. Klicken Sie mit der rechten Maustaste auf die ausführbare helloworld-Datei innerhalb des Binaries-Ordners und wählen Sie dann Folgendes aus: RUN AS | C/C++ CONTAINER APPLICATION. Dadurch läuft die helloworld-Anwendung nun in einem Container auf der Basis des fedora:latestImages.

Wenn Sie besondere Optionen wie interactive brauchen oder Zugriff auf die Daten des Hosts benötigen, können Sie im Dialog RUN | RUN CONFIGURATIONS… eine Launch-Konfiguration für eine C-/C++-Container-Anwendung erstellen (Doppelklick auf die Launch-Kategorie). Im Containertab befinden sich einige Optionen (Abb. 8).

Abb. 8: Optionen in den Run Configurations

Abb. 8: Optionen in den Run Configurations

Hier ist es möglich anzugeben, dass der Container nach dem Start behalten werden oder dass Input über die Konsole möglich sein soll (Support stdin input). Außerdem können Host-Directories spezifiziert werden, auf die die Anwendung zugreifen kann. Diese werden in den Container eingebunden.

Bekannte Probleme

Zum Zeitpunkt der Veröffentlichung dieses Artikels gibt es einige bekannte Probleme in den Docker-Tooling-Plug-ins. Diese sind:

  1. Eine Aktion mit einer langen Wartezeit kann zu einem Time-out führen, sodass kein weiterer Output mehr im Display-Log angezeigt wird. Die Ursache dafür ist, dass der vorgeschaltete Docker-Client keinen notimeout Eine Lösung für dieses Problem wird mit den Linux Tools 4.2.0 ausgeliefert.
  2. Die Angabe von -i und -t im Run Image Wizard kann bei Containern mit kurzer Laufzeit dazu führen, dass kein Output im Display-Log angezeigt wird. Das liegt an einem Problem mit dem zugrunde liegenden Apache Package. Um TTY zu unterstützen, versucht der Docker-Tooling-Code einen neuen Stream zu öffnen. Das ist aber nur möglich, wenn der Container bereits läuft. Dadurch entstehen in machen Fällen Timing-Probleme, wenn der Output schon angezeigt wird. Dieser Bug ist noch ungelöst und wird momentan bearbeitet.
  3. Private Registries können nicht nach Images durchsucht werden. Dabei handelt es sich um ein Problem mit dem zugrunde liegenden Docker Remote API. Um es zu lösen, wurden Verbesserungsvorschläge direkt an Docker eingereicht.
  4. Die abweichenden Releasezyklen von Docker und Eclipse können zu Inkompatiblitäten zwischen docker-client und dem Docker Remote API führen. Unser Docker Tooling wird parallel mit Eclipse veröffentlicht, wovon es bislang ein Hauptrelease pro Jahr sowie jeweils zwei Servicereleases dazwischen gibt. Das Docker Remote API kann sich allerdings alle paar Monate verändern. Da viele Nutzer jeweils auf die neueste Version zugreifen, kann es vorkommen, dass unsere Veröffentlichungen dadurch inkompatibel werden. Darum haben wir Diskussionen angestoßen, um unsere Tools häufiger zu veröffentlichen und uns dem Entwicklungstempo des Remote API anzupassen. Die Unterstützung älterer Versionen des Docker Remote API ist ein weiteres Problem, das in der Zukunft relevant werden könnte, wenn das Tooling von anderen Produkten aufgegriffen wird.

Weitere Informationen

Mehr Details zum Docker-Tooling-Plug-in können entweder in der User-Guide-Dokumentation der Docker Tooling Features (HELP | HELP CONTENTS) oder auf der Docker Tooling Wiki Page nachgelesen werden. Das Entwicklerteam freut sich über jeden konstruktiven Vorschlag zur Verbesserung des Docker Toolings!

Verwandte Themen:

Geschrieben von
Jeff Johnston
Jeff Johnston
Jeff Johnston ist Softwareentwickler für Red Hat in Toronto, Kanada. Dort ist er Projektleiter des Eclipse-Linux-Tools-Projekt, ein Committer für das Eclipse-CDT-Projekt sowie Co-Maintainer der Newlib C-Library. Außerdem übernimmt er das Maintaining für einige der Fedora- und Red-Hat-Enterprise-Linux-Eclipse-Pakete. Zu Jeffs Beiträgen zum CDT zählen unter anderem das Autotools-Plug-in und der Standalone-Debugger. Für Linux hat er des Weiteren das Libhover-Framework geschrieben sowie an den Docker-Tooling-Plug-ins mitgearbeitet. In seiner freien Zeit ist Jeff Leadsänger und Songwriter der Artrock-Gruppe Vermillion Skye.
Roland Grunberg
Roland Grunberg
Roland Grunberg ist Softwareentwickler für Red Hat in Toronto, Kanada. Er ist Committer des Eclipse-Linux-Tools-Projekts und Orbits und hat des Weiteren in zahlreichen Beiträgen das Eclipse-Packaging-Problem angesprochen. Die Beiträge beziehen sich auf die Linux-Verteilungen, einschließlich der Vollendung des p2-Droplet-Supports. Roland’s Beiträge zu Linux-Tools beinhalten das Profiling-Framework, das Perf-Plug-in und auch das Co-Developing des Docker-Tooling-Plug-ins. Des Weiteren verwaltet Roland mehrere Fedora- und Red-Hat-Enterprise-Linux-Eclipse-Pakete und arbeitet derzeit am Eclipse-Vagrant-Support.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: