Bereits Kunde? Jetzt einloggen.
Lesezeit ca. 7 Min.

Container-IDE mit Cloud-Anschlussl: Für jeden etwas


Linux Magazin - epaper ⋅ Ausgabe 10/2019 vom 05.09.2019

Klassische integrierte Entwicklungsumgebungen (IDEs) bringen gewöhnlich einen Editor, einen Compiler und einen Debugger mit. Gitpod setzt hingegen auf jüngere Technologien wie Docker und Eclipse Theia, um individuelle Entwicklungsumgebungen für Github-Projekte zu servieren.


Artikelbild für den Artikel "Container-IDE mit Cloud-Anschlussl: Für jeden etwas" aus der Ausgabe 10/2019 von Linux Magazin. Dieses epaper sofort kaufen oder online lesen mit der Zeitschriften-Flatrate United Kiosk NEWS.

Bildquelle: Linux Magazin, Ausgabe 10/2019

© rawpixel, 123RF

Wer kennt das nicht: Das frisch entdeckte und durchaus spannende Projekt liefert zwar eine ausführliche Dokumentation mit, aber schon für den Buildprozess braucht der Entwickler die Bibliotheken A, B und C sowie einige zusätzliche Tools. Und das natürlich auch noch in Versionen, welche die eigene Distribution nicht ...

Weiterlesen
epaper-Einzelheft 5,99€
NEWS 14 Tage gratis testen
Bereits gekauft?Anmelden & Lesen
Leseprobe: Abdruck mit freundlicher Genehmigung von Linux Magazin. Alle Rechte vorbehalten.

Mehr aus dieser Ausgabe

Titelbild der Ausgabe 10/2019 von News. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
News
Titelbild der Ausgabe 10/2019 von Zahlen & Trends. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Zahlen & Trends
Titelbild der Ausgabe 10/2019 von 25 Jahre Linux-Magazin mit Gewinnspiel: Geschenkt!. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
25 Jahre Linux-Magazin mit Gewinnspiel: Geschenkt!
Titelbild der Ausgabe 10/2019 von Großes Gewinnspiel:. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Großes Gewinnspiel:
Titelbild der Ausgabe 10/2019 von Ein kurzer Rückblick auf das Jahr des ersten Linux-Magazins: W3C und Eurofighter. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Ein kurzer Rückblick auf das Jahr des ersten Linux-Magazins: W3C und Eurofighter
Titelbild der Ausgabe 10/2019 von Das Linux-Magazin und seine Konkurrenten: Umkämpftes Treppchen. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Das Linux-Magazin und seine Konkurrenten: Umkämpftes Treppchen
Vorheriger Artikel
Ein Grundlagenwerk zur Webanalyse, ein Einsteigertitel für D…
aus dieser Ausgabe
Nächster Artikel C++ Core Guidelines – Folge 48: Klassisches Rezept
aus dieser Ausgabe

Wer kennt das nicht: Das frisch entdeckte und durchaus spannende Projekt liefert zwar eine ausführliche Dokumentation mit, aber schon für den Buildprozess braucht der Entwickler die Bibliotheken A, B und C sowie einige zusätzliche Tools. Und das natürlich auch noch in Versionen, welche die eigene Distribution nicht bereitstellt. Hier droht dem Entwickler dann entweder eine Installationsorgie oder er muss zu einer virtuellen Maschine oder zumindest einem Docker- Image greifen.
Was für einzelne Entwickler noch funktionieren mag, klappt in Teams aber weniger gut. Unternehmen rollen die Entwicklungsumgebungen meist zentral aus, damit sie einheitlich sind. Lokale Installationen auf Entwickler-PCs laufen früher oder später auseinander. Und zentrale Testserver einzurichten, um die Unterschiede der Entwicklungsumgebungen wieder einzufangen, bringt eigene Probleme mit sich. Daher kümmern sich Sysadmins lieber um Produktions- als um Testsysteme. Eine geteilte Nutzung erfordert auf Entwicklerseite zudem Umsicht. Andernfalls zerstört ein Kollege womöglich einen sorgsam aufgebauten Testdatensatz eines anderen in der gemeinsam benutzten Datenbank.
Docker-Instanzen taugen hier als ein möglicher Lösungsweg. Docker startet und konfiguriert seine Images reproduzierbar auf Basis von Konfigurationsdateien. Stecken diese ebenfalls im Versionsverwaltungssystem des Projekts, sollten rein theoretisch alle Entwickler eigene, aber identische Softwarestacks erhalten. Allerdings ist das Hantieren mit Docker nicht das Kerngeschäft eines Entwicklers. Aber nimmt ihm die Entwicklungsumgebung diese Arbeit ab, bleibt Zeit für Wichtigeres.

Ein Pod, ein Wort

An dieser Stelle kommt Gitpod[1] ins Spiel. Die Software-as-a-Service (SaaS) stellt eine integrierte Entwicklungsumgebung mit Editor plus beliebigen Laufzeitumgebungen bereit. Der Entwickler ruft sie nur über den Browser auf und muss sich um die technischen Hintergründe nicht weiter kümmern.
Die Technik hinter Gitpod greift relativ neue Entwicklungen der Open-Source- Szene auf. Neben Docker bedient es sich beim Editor Eclipse Theia[2] . Die besondere Leistung der Macher von Gitpod besteht darin, das Ganze zu einem einfach nutzbaren Paket zu schnüren.

Abbildung 1: Wer ein Github-Projekt mit Gitpod öffnen möchte, hängt einfach die URL des Projekts an.


Anmeldung

Die Anmeldung erfolgt über[1] und setzt auf die Github-ID, denn Gitpod erfindet das Rad nicht neu. Als Versionsverwaltungssystem ist Github[3] notwendig, ein Gitlab-Support[4] ist in Arbeit. Die Firma hinter Gitpod bietet drei Preismodelle an: Open Source, Personal und Unlimited. Die erste Variante kostet nichts. Sie lässt sich aber nur in Kombination mit öffentlichen Repositories verwenden. Außerdem beschränkt Gitpod die Laufzeit der Docker-Container auf 100 Stunden im Monat.
Die Personal-Variante erlaubt auch private Repositories, allerdings nur für nicht kommerzielle Zwecke. Die Zeitbeschränkung bleibt bestehen, an Kosten fallen etwa 8 Euro im Monat pro Person an. Auch die letzte Stufe ohne Beschränkungen ist mit knapp 35 Euro pro Monat und Person nicht wirklich teuer. Studenten erhalten sie sogar für rund 8 Euro. Insgesamt sind das faire Konditionen, erlauben doch die ersten beiden Stufen schon drei Stunden Arbeit am Tag mit Gitpod. Es bleibt abzuwarten, ob dieses Preismodell für die Firma aufgeht.

Erste Schritte

Nach dem Anmelden ruft der Anwender die Github-URL seines Projekts nicht direkt, sondern mit dem Präfix »https://gitpod.io/#Github‑Projekt‑URL « auf (Abbildung 1 ). Noch einfacher geht es mit einer Browser-Extension für Chrome oder Firefox, die einen »Gitpod«-Button in die Github-Seiten einblendet (Abbildung 2 ). Direkte Links zu den Add-ons stehen in der Online-Dokumentation unter[5] . Die Erweiterungen lassen sich bei den Browsern wie üblich installieren.

Das Beispiel verwendet ein beliebiges öffentliches Github-Repository. Der Anwender muss nicht selbst Besitzer des Repository sein. Gitpod funktioniert mit jedem Projekt, auf das er Zugriff hat und das zu seinem Preismodell passt. Mit dem Aufruf der URL erzeugt Gitpod einen so genannten »Workspace« und öffnet, falls vorhanden, die »README«-Datei.

Das geht überraschend schnell. Der Standard- Workspace unterstützt automatisch eine Vielzahl gängiger Programmiersprachen. Optisch unterteilt er sich in drei Bereiche: Links erscheint die Verzeichnisstruktur des Projekts, den rechten Bereich teilen sich oben ein Editor-Fenster und unten ein Terminal. Neben dem standardmäßig eingestellten dunklen Theme steht außerdem eine inverse helle Variante zur Wahl.

Workspaces

Workspaces sind in der Gitpod-Welt ein zentraler Begriff. Technisch handelt es sich um Docker-Container. Sie bilden die Arbeitsumgebung für das Programmieren und Testen. Gitpod erzeugt Workspaces automatisch und stoppt sie wieder nach 30 Minuten Inaktivität oder fünf Minuten nach dem Schließen des Browsers. Da laufende Workspaces das Konto belasten, schont dieser Automatismus auch die Ressourcen. Über das Icon oben rechts in der Ansicht und den Menü-Eintrag »Stop Workspace« leitet der Entwickler den Vorgang auch manuell ein.
Änderungen im Workspace, etwa Code- Anpassungen oder ein Update von Konfigurationsdateien, sichert Gitpod im Hintergrund selbsttätig. Sie landen aber ohne expliziten Commit nicht auf Github. Gitpod löscht auch gestoppte Workspaces nie. Das so genannte Dashboard, das der Entwickler auch über das oben erwähnte Menü erreicht, zeigt eine Liste aller vorhandenen Workspaces an (Abbildung 3 ). Hier lassen sich alte Workspaces wieder starten, archivieren oder explizit und unumkehrbar löschen.
Workspaces basieren auf Docker. Im Gegensatz zu Dockers Philosophie, die ein Docker-Image pro laufendem Programm vorschlägt, umfasst ein Workspace alle benötigten Services. Bietet ein Programm etwa eine Webschnittstelle, dann öffnet Gitpod bei Bedarf den entsprechenden Port auch für das Internet. Details dazu stehen in der Dokumentation[5] .

Der Editor

Statt einen neuen Editor zu programmieren, verwenden die Gitpod-Macher einfach Theia. Das ist die Webversion von Visual Studio Code (VS Code,[6] ). Wer hier an Microsofts klassische IDE denkt, liegt nicht ganz falsch, denn der komplett als Open Source entwickelte Editor kommt tatsächlich ursprünglich von Microsoft. Selbst der Autor, ein jahrzehntelanger Xemacs-Nutzer, greift inzwischen lieber zu VS Code.

Abbildung 2: Browser-Extensions blenden auf Github einen Gitpod-Button ein.


Abbildung 3: Im Dashboard listet Gitpod Workspaces auf, die es nur auf Befehl hin löscht.


Abbildung 4: Der Editor mit einer kontextsensitiven Hilfe.


Ein Killerfeature von VS Code sind die zahlreichen verfügbaren Plugins, die Nutzer in Sekundenschnelle per Knopfdruck installieren. Im Unterschied zu einem lokalen VS Code geht das bei Theia noch nicht, aber die Gitpod-Entwickler arbeiten hart daran.
Auf alle Fälle ist es von Vorteil, wenn sich das Look & Feel des Webeditors und des lokalen Editors ähneln. Theia (respektive VS Code) erlaubt eine weitgehende Konfiguration. Insbesondere auch die Tastenbelegung passen Entwickler an die eigenen Vorlieben an.
Der Editor bietet für viele Sprachen Syntax- und Stilchecks sowie kontextsensitive Hilfe für Funktionen (Abbildung 4 ). Auf Tastendruck vervollständigt er den Code oder fügt Codemuster ein. Insgesamt erhöht das schon beim Eintippen die Qualität des Codes deutlich.

Github-Integration

Wie in der Einleitung demonstriert, startet der Entwickler die Gitpod-IDE immer in Bezug auf ein Github-Projekt. Die Integration geht aber noch weiter. Denn außer einem Projektpfad erlauben es das Gitpod-Präfix oder der Button auch, eine Datei, ein Problem (»Issue«) und einen Pull Request zu öffnen.
Im ersten Fall öffnet die IDE gleich die entsprechende Datei im Editor. Im zweiten erzeugt Gitpod einen lokalen Branch mit Namen »GH‑Problemnummer «, außerdem bereitet Gitpod gleich eine entsprechende Commit-Message vor. Im letzten Fall, dem mit dem Pull Request, öffnet Gitpod eine speziell für die Codereview geeignete View.
Neben dieser Integration auf Projektbasis unterstützt Gitpod auch die Arbeit mit dem Backend der Versionsverwaltung in diversen Fenstern. Gitpod markiert Änderungen sowohl im Explorer, indem es Verzeichnisse und Dateien mit einem »M« für „modified“ versieht (Abbildung 5 ), als auch im Code selbst (bei geänderten Zeilen).
Die eigentliche Git-View führt die modifizierten Dateien noch einmal auf. Über die Icons rechts neben den Dateien führt der Entwickler die üblichen Git-Operationen wie »add« oder »commit« aus (Abbildung 6 ). Natürlich geht das alles auch per Kommandozeile im Terminalfenster.

Abbildung 5: Git-Integration: Die IDE markiert alle am Code vorgenommenen Änderungen.


Anpassungen

Der Standard-Workspace von Gitpod bietet umfassende Unterstützung für mehrere Programmiersprachen. Trotzdem deckt das referenzierte Docker-Image nicht alle Bedürfnisse ab. Bei einem Projekt des Autors war zum Beispiel das Paket »python3‑bottle« unabdingbar, das in der Ubuntu-Umgebung des Standard- Workspace fehlt. In einer solchen Situation muss sich der Entwickler doch ein wenig mit Docker beschäftigen und den Workspace anpassen. Einfach ein Paket nachinstallieren klappt nicht, weil dem Standarduser »gitpod« im Workspace die Rootrechte fehlen.
Als zentrales Element in so einem Szenario entpuppt sich die Konfigurationsdatei ».gitpod.yml«. Diese verweist auf ein Docker- File, quasi der offiziellen Bauanleitung für das Docker- Image, sowie auf andere Konfigurationseinstellungen für den Workspace. Dazu gehört zum Beispiel ein Kommando, das Gitpod nach dem Erzeugen des Workspace aufrufen soll.
Listing 1 zeigt eine sehr minimalistische Version von ».gitpod. yml«. Diese definiertdas Docker-File des Projekts, wobei sich dessen Name frei wählen lässt. Das erlaubt auch ohne Docker-Kenntnisse und spezielle Klimmzüge Anpassungen am Standard-Workspace. Einer der einfachsten Schritte ist das Nachinstallieren projektspezifischer Pakete,Listing 2 zeigt ein passendes Beispiel.

Abbildung 6: Git-Operationen über die Oberfläche.


Der erste Start eines Workspace mit eigenem Image dauert etwas länger, denn Docker muss das Image erst bauen. Wer als Basis nicht den Standard, sondern ein beliebiges öffentliches Docker-Image aus dem Docker-Hub verwendet, sollte zusätzliche Zeit einplanen, denn die Gitpod- Infrastruktur muss das Basis-Image ja erst aus dem Internet ziehen.
Gitpod bietet ergänzend noch eine Github‑App an. Diese baut den Workspace bei Änderungen am Projekt im Hintergrund umgehend neu. Das spart Entwicklern wertvolle Zeit beim ersten Aufruf. Wer sein Projekt optimal auf Gitpod vorbereiten möchte, sollte den Blogbeitrag[7] lesen, der die „Gitpodifizierung“eines Projekts näher beleuchtet.

Fazit

Gitpod bietet mit einem Editor, einer Kommandozeile und Github-Anschluss alles, was ein Entwickler für die produktive Arbeit braucht. Dafür muss er sich lediglich einmalig bei dem Projekt registrieren, das weitere Installieren von Software auf seiner Entwicklungsmaschine entfällt.
Dieses Szenario funktioniert allerdings nur in der Onlinewelt. Mit kurzen Funklöchern kommt Gitpod zwar ordentlich zurecht, da der Browser die Session behält, aber ein Offline-Arbeiten ist nicht möglich. Wer also unterwegs programmieren will, braucht ein gutes Mobilnetz oder zumindest eine rudimentäre Entwicklungsumgebung. Dafür bietet sich natürlich die Kombination aus Git, VS Code und Docker an.
Die Entwickler von Gitpod arbeiten ständig an Verbesserungen. Aktuell stehen die Themen Gitlab-Integration, Plugins für den Editor und Gitpod Enterprise auf der To-do-Liste. Letztere Lösung ist für Firmen gedacht, die zwar die Vorteile von Gitpod nutzen, ihren Quellcode samt Testdaten aber nicht einem Cloudsystem anvertrauen möchten.(kki)

Infos

[1] Gitpod:[https://www.gitpod.io]
[2] Eclipse Theia:[https://www.theia‑ide.org]
[3] Github:[https://github.com]
[4] Gitlab:[https://gitlab.com]
[5] Online-Dokumentation zu Gitpod:[https://www.gitpod.io/docs]
[6] Visual Studio Code:[https://code.visualstudio.com]
[7] „Gitpodifying – The Ultimate Guide“:[https://www.gitpod.io/blog/gitpodify/]

Der Autor

Bernhard Bablok ist langjahriger Linux-Magazin- Autor und arbeitet bei der Allianz Technology SE als SAP-HR-Entwickler. Wenn er nicht gerade Musik hort oder mit dem Radl oder zu Fus unterwegs ist, beschaftigt er sich mit Themen rund um Linux, Programmierung und Kleincomputer. Er ist per Mail unter [mail@bablokb. de] zu erreichen.