Cloud Development Environments: Devfile und Devcontainer als Konfigurationsstandards

  • Veröffentlicht

Cloud Development Environments (CDEs) sind Arbeitsumgebungen für Entwickler_innen, die remote und oft in der Cloud bereitgestellt werden. Ihr Ziel ist es, die Abhängigkeit der Entwickler von ihren Laptops zu verringern, indem sie eine Umgebung bereitstellen, in der sie an ihrem Code arbeiten und ihre Anwendungen in der Cloud ausführen können.

CDEs sind in den letzten Jahren immer populärer geworden. Viele neue Produkte sind 2023/2024 auf den Markt gekommen. Im August 2023 hat Gartner Cloud Development Environments in ihren “Hype Cycle of Emerging Technologies” aufgenommen. Das zeigt deutlich ein steigendes Interesse, aber auch die mangelnde Reife dieser Produktkategorie.

Ein Zeichen dieser Unreife ist die fehlende Standardisierung über CDE-Produkte hinweg. Es gibt große Differenzen hinsichtlich der Funktionalitäten zwischen den Anbietern. Einen Aspekt gibt es aber, bei dem ein Standard genutzt wird: Bei der Konfiguration.

In diesem Artikel erkläre ich die Standards, die existieren, die Gemeinsamkeiten, wo sie sich unterscheiden und warum manche CDE-Anbieter diese Standards nicht nutzen.

Was sind Devfile und Devcontainer?

Devfile und Devcontainer sind zwei Standards, um Container-basierende Entwicklungsumgebungen zu beschreiben. Beide wurden in einer Zeit entwickeln, in der Container der letzte Schrei waren. Die Idee war, dass Entwicklungsumgebungen mit der Hilfe von Containern standardisiert werden könnten. Zu dieser Zeit war die Idee, lokale Entwicklungsumgebungen zu standardisieren und Container am Laptop der Entwickler_innen auszuführen. Devcontainer hat einige Features, um ein Deployment von Dev-Containern in Remote-Umgebungen zu unterstützen – das war damals aber nicht der primäre Anwendungsfall, als diese Standards konzipiert wurden.

Was kann mit Devfile und Devcontainer konfiguriert werden?

Beide Standards basieren auf Docker, um Container zu deployen. Welche Container deployed werden sollen, wird in einer devfile.yml oder devcontainer.json definiert. Sie können auf Container-Images in einer Registry verweisen, oder docker-compose-Dateien, um Container von Grund auf neu zu erstellen. Sowohl devfile als auch devcontainer erlauben den Verweis auf einen oder mehrere Container.

Zusätzlich zur Referenz von Containern erlauben Devfile und Devcontainer die Spezifizierung von:

  • Der IDE-Konfiguration für einige kompatible IDEs, z.B. Erweiterungen und Source Code Pfadzuordnungen,
  • Skripts und Kommandos, die im Container ausführbar sind, z.B., um Dienste zu starten und Ports weiterzuleiten.

Devfile und Devcontainer spezifizieren beide nicht die Container direkt. Stattdessen referenzieren sie entweder bestehende Container in einer Container-Registry, oder Dockerfiles, oder Docker-Compose-Files von denen aus Containers erstellt werden. Daher bieten devfile und Devcontainer einen zusätzlichen Layer der Konfiguration – und zwar zusätzlich zu Dockerfile und Docker-Compose.

Einige CDE-Plattformen verzichten auf diese zusätzliche Konfigurationsebene und nutzen stattdessen Dockerfile oder Docker-Compose direkt, um auf Container basierende Entwicklungsumgebungen zu beschreiben. Das ist eine Eigenschaft von stärker offenen CDE-Produkte, die Entwickler_innen nicht bei der Wahl der IDE limitieren und mit Devfile oder Devcontainer angepasst werden kann. Ohne die IDE-Individualiserung ist der Nutzen limitiert. Befehle und Skripte, die innerhalb des Containers ausgeführt werden sollen, können auch direkt in Dockerfiles und Docker-Compose-Dateien angegeben werden.

Für eine entwicklungsspezifische Anpassung des Containers sind aber entwicklungsspezifische Dockerfiles oder Docker-compose-Dateien erforderlich, anstatt einen Satz allgemeiner Container-Definitionen zu verwenden und jede entwicklungsspezifische Konfiguration über Devfile oder Devcontainer anzuwenden. Hier gehts zu einem detaillierten Vergleich von Devfile und Devcontainer vs. Dockerfile und Docker-Compose.

Was sind die Vorteile von Devfile und Devcontainer?

Es gibt zwei Vorteile:

  • Es sind offene Standards, die von vielen Tools unterstützt werden. Viele IDEs und CDE-Produkte können diesen Standard interpretieren und Entwicklungsumgebungen basierend auf einem devfile.yml oder devcontainer.json deployen.
  • Als textbasierte Konfigurationsdateien können sie im Quellcode-Repository neben der Codebase aufbewahrt werden, für die sie die Entwicklungsumgebung beschreiben. Dadurch werden die Repositories zur einzigen Informationsquelle, die für die Erstellung einer Entwicklungsumgebung erforderlich ist. Die Idee ist, dass ein Entwickler oder ein Werkzeug wie eine IDE oder CDE-Plattform nur Zugriff auf das Repository benötigt, um eine vollständige Entwicklungsumgebung bereitstellen zu können.

CDE-Plattformen und das genutzte Konfigurationsformat

Anbieter CDE-Konfigurationsformat Anmerkung
Koding
Proprietäres Konfigurationsformat
Eingestellt
Codenvy / Red Hat CodeReady Workspaces / Red Hat OpenShift Dev Spaces
devfile.yml
Eclipse Che
devfile.yml
Dev-Container auf K8s neben einer Multicontainer-Anwendung implementiert
Coder
Terraform, kann Container auf Basis von dockerfile, docker-compose deployen
Codesandbox
Docker- compose, Dockerfile
JetBrains Space
Devfile.yml
Okteto
Proprietäres Okteto.yml
Dev-Container auf K8s neben einer Multicontainer-Anwendung implementiert
Gitpod
Proprietäres Gitpod.yml
Strong Network
GUI
Github Codespaces
Devcontainer.json
DevZero
GUI
Amazon CodeCatalyst
Devfile.yml
GCP Workstationst
Dockerfile
Nimbus
Manuelle Erstellung von VM-Snapshots als Vorlagen
Eingestellt
Microsoft Dev Box
GUI, Windows images
Windows-VMs, Remote-Desktop-Zugriff
Gitlab Workspaces
devfile.yml
Allgemeine Verfügbarkeit seit 01/2024
IDX by Google
Nix package
VM-basierte CDEs, gehen Sie nicht von Containern aus
DevPod by Loft Labs
devcontainer.json
Desktop-Anwendung zur Bereitstellung von Single-Container-CDEs in verschiedenen Umgebungen
Dockerfile, docker-compose für containerisierte Anwendungen, benutzerdefinierte Konfiguration für nicht containerisierte Anwendungen, kann Nix-Pakete deployen
VM-basierte CDEs, gehen Sie nicht von Containern aus
Hocus
Proprietäres hocus.yml
Alpha-Version mit bekannten Fehlern
Daytona
Unklar: devfile.yml oder devcontainer.json oder Nix-Paket
Warteliste

Eigenentwickelte CDE-Konfigurationsformate: Gitpod.yml, Okteto.yml, hocus.ymls vs. devfile.yml und devcontainer.json

Trotz der Vorteile, die Devfile und Devcontainer als bereits bestehende Standards bieten, haben einige CDE-Anbieter ihre eigenen Konfigurationsformate entwickelt. Es gibt unterschiedliche Gründe dafür. Der primäre Grund ist, dass sie viele produktspezifische Konfigurationen haben, die nicht mit Devfile und Devcontainer beschrieben werden können.

Beispielsweise bietet gitpod prebuilds von Repositories an, um das Deployment von CDEs zu beschleunigen. In der gitpod.yml können prebuilds konfiguriert werden. Okteto-Manifeste ermöglichen die Beschreibung von Umgebungen für einen Kubernetes-Cluster und verweisen auf helm-Diagramme und kubectl-Befehle, was weit über den Umfang von devfile und devcontainer hinausgeht.

Unterschiede und Ähnlichkeiten: gitpod.yml, hocus.yml, okteto.yml vs. devfile.yml und devcontainer.json vs. dockerfile und docker-compose

Die Tabelle bietet eine Übersicht, was, wo und wie konfiguriert werden kann. Die Tabelle erhebt keinen Anspruch auf Vollständigkeit: Für die meisten der hier aufgeführten Formate gibt es zusätzliche produktspezifische Konfigurationsmöglichkeiten. In der Tabelle sind nur die wichtigsten Funktionen aufgeführt, die mehrere Formate gemeinsam haben.

# Was ein einziger Container beinhaltet: OS, Software Wie mehrere Container zusammenarbeiten Befehle und Skripte zur Ausführung in einem Container Container, die Teil der Entwicklungsumgebung sind IDE-Konfiguration Port-Konfiguration
dockerfile
x
x
docker-compose
x
x
x
devfile.yaml
x
x (Einige)
x
x
devcontainer.json
x
x (Einige)
x
x
gitpod.yml
x
x (1 Container)
x
x
hocus.yml
x
x (1 Container)
x
x
Okteto.yml
x
x (Einige)
x

Fazit

Viele CDE-Produkte verwenden Devfile und Devcontainer zur Konfiguration von CDEs, die Standards zur Beschreibung containerbasierter Entwicklungsumgebungen sind. Sie bieten jedoch nur eine dünne zusätzliche Konfigurationsschicht über den Containern, die entweder als Container-Images in einer Registry oder über Dockerfile- oder Docker-Compose-Dateien referenziert werden. Einige CDE-Produkte bieten daher die Konfiguration direkt über Dockerfile oder Docker-Compose an. Andere CDE-Produkte haben ihre eigenen Konfigurationsformate entwickelt, die zusätzliche, produktspezifische Konfigurationsmöglichkeiten bieten. Sie wollen mehr über CDE-Anbieter erfahren und Tools vergleichen? Hier entlang -> „Full list of CDE vendors (+feature comparison table)„.

Margot Mückstein

CEO & co-founder von Cloudomation