Geteilte Entwicklungsumgebungen auf Kubernetes-Basis, Teil 2 Arbeiten mit GitPod in der Praxis
Von Mirco Lang
Online-Arbeitsplätze nehmen massiv Fahrt auf, die Funktionen klingen super. Aber wie arbeitet es sich in der Praxis damit? In GitPod sehen wir uns einen beispielhaften Workflow an.
Cloud-IDE, Online-Arbeitsplatz, IDE im Browser – die Bezeichnungen sind vielfältig. In der Regel geht es um Container mit einem Betriebssystem, beliebiger Software und eben der eigentlichen IDE (etwa Microsoft Visual Studio Code), in diesem Zusammenhang meist einfach Editor genannt. Zugriff auf diese Container gibt es dann per Browser.
Teilweise können aber auch die Desktop-Varianten der Editoren genutzt werden, wobei immer noch der Online-Container das Arbeitsumfeld stellt. Einige dieser Lösungen haben wir Ihnen bereits nebeneinander vorgestellt, sowie separat GitHubs eigenes Angebot GitHub Codespace
Was genau GitPod leistet und wie es einzuordnen ist, können Sie im kürzlich erschienenen GitPod-Artikel auf Dev-Insider nachlesen. Weitere Informationen gibt es im Artikel zu Eclipse Theia, ein aus den GitPod-Reihen stammendes Framework zum Erstellen eigener IDEs (im Sinne von Editor).
Mit Eclipse Theia lassen sich VS-Code-ähnliche Produkte erstellen, die im Gegensatz zum Microsoft-Vorbild jedoch komplett auf Open-Source-Komponenten setzen. Zwar sollte Theia für GitPod ursprünglich ein browserfreundlicherer VS-Code-Ersatz sein, seit VS Code aber selbst für den Online-Betrieb optimiert wurde, läuft es auch als Standard-Editor in GitPod.
Arbeiten mit GitHub
GitPod arbeitet auch mit GitLab, Bitbucket und individuellen Git-Anbietern zusammen, hier soll es aber exemplarisch rein um GitHub gehen. Der einfachste Weg mit GitPod loszulegen: Besuchen sie eines Ihrer Repositories und setzen Sie das Präfix „gitpod.io/#“ davor, also beispielsweise „gitpod.io/#https://github.com/NUTZERNAME/REPONAME“. Alternativ können Sie die Browser-Erweiterung von GitPod installieren und bekommen dann schlicht an jedem Repo einen zusätzlichen GitPod-Button, um das Repo direkt in einem Workspace zu öffnen.
Etwas verständlicher wird es vielleicht über den„traditionellen“ Weg: Erst bei GitPod anmelden und zwar einfach mit dem GitHub-Account – wie man es von etlichen anderen Services gewohnt ist. Einmal angemeldet, können Sie direkt Workspaces erstellen oder aber zunächst ein Projekt, das lediglich hilft, Workspaces und Einstellungen zu verwalten. Am besten beginnen Sie mit einem Projekt: Sie werden hier lediglich nach dem gewünschten Repo gefragt.
Anschließend wird GitPod in GitHub installiert, sofern Sie mehrere Nutzer oder Organisationen haben, müssen Sie noch den Installations-„Ort“ festlegen und GitPod authorisieren. Diese Einstellungen finden Sie später als üblich unter „Settings/Integrations/Applications“. Hier lässt sich GitPod wahlweise für einzelne oder alle Repos freigeben.
Wenn Sie nun einen ersten Workspace anlegen und starten – sei es über ein Repo oder das GitPod-Dashboard – stehen Sie direkt vor der Wahl: Desktop oder Browser. VS Code Desktop bindet die GitPod-Arbeitsumgebung dann gegebenenfalls per Web-Container an. Zum Testen ist der Browser aber deutlich angenehmer.
Sie landen in der gewohnten VS-Code-Oberfläche mit dem geklonten Repo. Links in der Navigation finden Sie auch einen Punkt „GitHub“, über den Sie Pull Requests und Issues direkt in VS Code verarbeiten können – dafür ist allerdings nochmals ein Login in GitHub notwendig, wofür wiederum erneute eine Rechte-Anfrage startet, um lesend auf das Nutzerprofil zugreifen zu dürfen: Das Recht „read:user“ können Sie auch über die GitPod-Oberfläche im Bereich „Settings/Integrations/GitHub/Edit Permissions“ setzen.
Nun sollten Sie sich Ihre Dateiliste näher anschauen: Sie finden eine noch nicht getrackte Datei „.gitpod.yml“, die beim erstmaligen Erstellen eines Workspaces ausgeliefert wird. Hier können Sie die Umgebung konfigurieren, eine komplette Liste der Optionen in der gitpod-yml-Doku.
Wichtig für das Verständnis: In der Konfiguration gibt es „normale“ Kommandos über den Befehl „command“, die ausgeführt werden, wenn der Workspace gestartet wird – also beispielsweise eine simple Begrüßung mit „echo“ im Terminal, wie auch standardmäßig zu sehen. Befehle, die mit „init“ eingeleitet werden, werden hingegen ausgeführt, sobald Code in das Repository gepusht wird. Diese Funktion nennt sich Prebuild und sorgt schlicht dafür, dass neue Umgebungen deutlich schneller aufgebaut werden können.
Es lohnt sich durchaus, der GitPod-Empfehlung zu folgen und für jede neue Arbeitssitzung und einzelne Aufgaben jeweils neue Workspaces aufzurufen – der Aufbau geschieht meist in Sekunden oder wenigen Minuten und die Commits Dritter und Änderungen in der Umgebung sind stets aktuell. Um die Änderungen in der „.gitpod.yml“ zu aktivieren müssen Sie diese natürlich stagen, committen und pushen, den Workspace schließen und einen neuen öffnen.
In der GitPod-Oberfläche finden Sie noch zwei interessante Optionen unter „Settings“: Im Bereich „Variables“ lassen sich Umgebungsvariablen setzen, beispielsweise Passwörter. Definieren Sie hier etwa „myvar“ als „Hallo Welt“, können Sie im Terminal eines Workspaces mit „echo $myvar“ arbeiten.
Wesentlich interessanter ist aber der Punkt „Preferences/Dotfiles“: Dotfiles meint einfach die üblichen versteckten Linux-Konfigurationsdateien, also beispielsweise „.bashrc“. Sie können hier ein eigenes Repo angeben, das entweder solche Dotfiles direkt beinhaltet oder ein Installationsskript mit einem der vorgegebenen Namen (etwa „install.sh“ oder „bootstrap“). Ohne Installationsskript werden die Dotfiles schlicht im Home-Verzeichnis als Symlinks hinterlegt. Zum Testen bietet sich eine simple Datei „.bash_aliases“ mit einigen Aliassen an.
System-Anpassungen
GitPod, GitHub und VSC lassen sich soweit gut anpassen und bereits nutzen. Was aber, wenn nun ein Programm fehlt? Nehmen wir als Beispiel das omnipräsente „cowsay“. Wenn Sie dieses in jedem Workspace haben wollen, gehen Sie in zwei Schritten vor:
Zunächst fügen Sie folgende Zeilen am Anfang der „.gitpod.yml“-Konfiguration ein:
image:
file: .gitpod.dockerfile
Dann erstellen Sie eben dieses von GitPod zu verarbeitende Dockerfile im Root-Verzeichnis des Repos mit folgendem Inhalt:
FROM gitpod/workspace-fullRUN sudo apt-get update \
&& sudo apt-get install -y \
cowsay \
&& sudo rm -rf /var/lib/apt/lists/*
Auf diese Weise können Sie freilich auch sinnvollere Tools einrichten. „cowsay“ zeigt aber schön eine kleine Besonderheit: Es wird nach „/usr/games“ installiert – was nicht im Systempfad liegt! Insofern produziert in diesem Fall der Befehl „cowsay“ nur eine Fehlermeldung, „whereis cowsay“ zeigt aber die korrekte Installation.
Arbeiten mit GitPod
Der so eingerichtete Test-Workspace startet hier in knapp 20 Sekunden. Eine Real-World-Umgebung wird freilich länger benötigen, da sich auch komplexe Datenbanken, Test-Server, App-Previews, Checks und beliebige Toolchains aufbauen lassen.
Alternativ zum Browser können aber auch Desktop-Editoren wie IntelliJ IDEA, GoLand, PyCharm, PhpStorm und JetBrains genutzt werden – allerdings noch im Beta-Status. Auch die Dotfiles fallen noch unter Beta, entsprechend gibt es auch noch kaum Dokumentation. Zumindest bei einfacheren Test-Configs funktioniert das Feature aber einwandfrei.
Letztlich ist die ganze Konfiguration aber natürlich etwas, um das sich nur ab und an und zentral gekümmert werden muss. Die eigentliche, alltägliche Arbeit mit GitPod ist dann extrem simpel: Ein neuer Mitarbeiter beispielsweise benötigt nur einen GitHub-Account innerhalb der authorisierten Organisation und einen beliebigen Rechner, schon ein Thin Client genügt, und kann sofort loslegen. Das typische „Die IT hat meinen Arbeitsplatz noch nicht fertig.“ dürfte damit zumindest deutlich seltener werden.
Doch auch für Kleinstprojekte, an denen Sie nur allein arbeiten, sind Cloud-IDEs extrem komfortabel, sei es nun GitPod, das (noch immer) kostenpflichtige Codespaces oder GoormIDE aus unserem Übersichtsartikel.
(ID:48097768)
