Go

Docker & Containerization

Dockerfile, Multi-Stage-Builds, Image-Optimierung, docker-compose, Container-Orchestrierung

20 Interview-Fragen·
Senior
1

Was ist der Hauptgrund für die Verwendung eines Multi-Stage-Builds für eine Go-Anwendung?

Antwort

Der Multi-Stage-Build trennt die Kompilierungsumgebung vom finalen Image. Die Build-Stage enthält das vollständige Go-SDK (mehrere hundert MB), während das finale Image nur die kompilierte Binärdatei enthält. Dies reduziert die Image-Größe drastisch (von ~800MB auf wenige MB) und minimiert die Angriffsfläche, indem unnötige Build-Tools in der Produktion entfernt werden.

2

Welches Basis-Image wird für eine Go-Anwendung in der Produktion empfohlen, um Größe und Angriffsfläche zu minimieren?

Antwort

Das scratch-Image ist ein leeres Image ohne Betriebssystem. Go kompiliert zu statischen Binärdateien, die kein libc oder andere Systemabhängigkeiten benötigen, wodurch scratch nutzbar wird. Dies erzeugt die kleinstmöglichen Images (wenige MB) und bietet die beste Sicherheit, da es keine ausnutzbaren Tools oder Shells gibt. Distroless und alpine sind gültige, aber weniger optimale Alternativen.

3

Welche Go-Kompilierungsflags sind erforderlich, um eine mit einem scratch-Image kompatible Binärdatei zu erstellen?

Antwort

CGO_ENABLED=0 deaktiviert cgo und zwingt Go, reine Go-Implementierungen für Pakete wie net und os/user zu verwenden. Ohne dies hätte die Binärdatei dynamische Abhängigkeiten zu libc. GOOS und GOARCH geben die Zielplattform an. Diese kombinierten Flags erzeugen eine vollständig statische Binärdatei ohne externe Abhängigkeiten, ideal für scratch.

4

Wie optimiert man das Docker-Layer-Caching beim Build einer Go-Anwendung?

5

Was ist der Vorteil der Verwendung von Google-Distroless-Images für Go im Vergleich zu scratch?

+17 Interview-Fragen

Meistere Go für dein nächstes Interview

Zugang zu allen Fragen, Flashcards, technischen Tests, Code-Review-Übungen und Interview-Simulatoren.

Kostenlos starten