> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devinenterprise.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Containerisierung
> In diesem Tutorial zeigen wir Ihnen, wie Devin einen Docker-Container konfigurieren kann, um die Entwicklungsumgebung Ihres Teams zu standardisieren.
## Erstellen eines Docker-Containers
Da Devin Zugriff auf ein Terminal hat und Software auf seinem eigenen Server konfigurieren und ausführen kann, ist das Einrichten eines Docker-Containers für ihn problemlos möglich.
Unsere Beispielanwendung ist ein Go-Projekt mit MongoDB als Datenspeicher. Diese Sitzung ist Devins Version eines Pull Requests, den ein echter Entwickler zu einem Open-Source-Projekt eingebracht hat. Verfolge die Live-Ausführung [hier](https://app.devin.ai/sessions/379eb9a40ff2433db49e51c95c7d9bc1?ts=1729908167981).
#### Mit einem GitHub-Issue beginnen
Wir starten mit dem ursprünglichen GitHub-Issue:
Als Nächstes können wir einen einfachen Prompt für Devin formulieren, basierend darauf, was in diesem Issue gefordert wird. Wir weisen Devin an, das oben stehende GitHub-Issue für zusätzlichen Kontext zu lesen, geben ihm aber auch unsere eigene Zusammenfassung der vorgeschlagenen Lösung und der Ergebnisse, die Devin erzeugen soll.
#### Untersuchung der Codebase
Devin beginnt mit einem Untersuchungsschritt, in dem es unser verlinktes GitHub-Issue liest und den eigentlichen Code sowie die Konfigurationsdateien des Projekts nach erforderlichen Abhängigkeiten [durchsucht](/de/release-notes#repo-knowledge).
Nachdem die Analyse abgeschlossen ist, installiert Devin Docker auf seiner lokalen Maschine und erstellt anschließend unser erstes Dockerfile, die docker-compose.yml und die .dockerignore, damit es mit dem Testen des Container-Setups beginnen kann. Außerdem konfiguriert es unsere .env-Datei, sodass die Anwendung mit dem neu konfigurierten Container-Backend ausgeführt werden kann.
#### Testen der Container
Devin testet anschließend jeden Container, beginnend mit unserem MongoDB-Server und danach unserer Go-Umgebung. Sobald die Container laufen, fährt Devin damit fort, die Anwendung selbst zu testen. Beim Durchsehen von Devins [Command History](/de/work-with-devin/devin-session-tools#shell-command-history) sehe ich, dass Devin unsere Swagger-API-Definition gefunden und sie im integrierten [Browser](/de/work-with-devin/devin-session-tools#interactive-browser) geladen hat, um nachzuvollziehen, wie die Backend-API funktioniert.
Anschließend hat Devin eine curl-Anfrage zusammengestellt, um zu testen, dass die Backend-API läuft und Ergebnisse wie in der Design-Spezifikation vorgesehen zurückgibt.
#### Debugging
Da wir einen Verbindungsfehler **Connection refused** erhalten, macht sich Devin sofort ans Debuggen und Korrigieren der Docker-Konfiguration. Dies ist ein häufiges Muster, bei dem Devin Fehler im Verlauf einer Sitzung selbst korrigieren kann. Devin behebt das Konfigurationsproblem schnell, startet den Docker-Container neu und fasst die erledigte Arbeit für uns zusammen.
Wenn wir Devins Arbeit mit dem [PR im eigentlichen Projekt](https://github.com/Ratnesh-Team/Rehabify/pull/137) vergleichen, gibt es einige bemerkenswerte Unterschiede und Verbesserungen:
* Devin richtet zusätzlich zu unserem Dockerfile eine docker-compose.yml-Datei ein. Das verschafft uns spezifischere Orchestrierungseinstellungen, etwa wie unser Netzwerk funktioniert, wie unsere Volumes konfiguriert sind und welche Dienste voneinander abhängen.
* Devin ändert den Build-Prozess von `go mod tidy` zu einer Methode, mit der wir einige der Abhängigkeiten in unserem Docker-Build cachen können.
* Devin erstellt ein statisch gelinktes Go-Binary statt eines dynamisch gelinkten, was für unseren Docker-Build schlanker sein sollte.
* Devin konfiguriert unsere CA-Zertifikate für HTTPS und ermöglicht uns die Verwendung einer .env-Datei für die Konfiguration, anstatt Umgebungsvariablen direkt zu übergeben.
* Und am deutlichsten: Devin fügt unserer Docker-Konfiguration einen MongoDB-Dienst hinzu, den der PR im Projekt nicht enthält. Dort wird davon ausgegangen, dass bereits eine separate MongoDB-Instanz des Entwicklers läuft.
In 13 Minuten hat Devin erfolgreich unseren Docker-Container für das Backend dieses Projekts nach Best Practices erstellt, getestet und eine umfassende Zusammenfassung seiner Arbeit geschrieben. Probieren Sie noch heute Ihren eigenen Containerisierungs-Prompt auf Ihrer eigenen Codebase aus, indem Sie sich für ein Devin-Konto für Ihr Team [anmelden](https://cognition.com/get-started#company).