Go

Docker & Containerization

Dockerfile, multi-stage builds, optymalizacja obrazów, docker-compose, orkiestracja kontenerów

20 pytań z rozmów·
Senior
1

Jaki jest główny powód stosowania multi-stage build dla aplikacji Go?

Odpowiedź

Multi-stage build oddziela środowisko kompilacji od finalnego obrazu. Etap budowania zawiera pełny SDK Go (kilkaset MB), podczas gdy finalny obraz zawiera tylko skompilowany plik binarny. To drastycznie zmniejsza rozmiar obrazu (z ~800MB do kilku MB) i minimalizuje powierzchnię ataku, eliminując zbędne narzędzia budowania w produkcji.

2

Który obraz bazowy jest zalecany dla aplikacji Go w produkcji, aby zminimalizować rozmiar i powierzchnię ataku?

Odpowiedź

Obraz scratch to pusty obraz bez systemu operacyjnego. Go kompiluje się do statycznych plików binarnych, które nie potrzebują libc ani innych zależności systemowych, co umożliwia użycie scratch. Powstają najmniejsze możliwe obrazy (kilka MB) i zapewnia to najlepsze bezpieczeństwo, ponieważ nie ma żadnych narzędzi ani powłoki możliwych do wykorzystania. Distroless i alpine to prawidłowe, ale mniej optymalne alternatywy.

3

Które flagi kompilacji Go są wymagane do utworzenia pliku binarnego kompatybilnego z obrazem scratch?

Odpowiedź

CGO_ENABLED=0 wyłącza cgo, zmuszając Go do używania implementacji pure Go dla pakietów takich jak net i os/user. Bez tego plik binarny miałby dynamiczne zależności od libc. GOOS i GOARCH określają platformę docelową. Te połączone flagi tworzą w pełni statyczny plik binarny bez zewnętrznych zależności, idealny dla scratch.

4

Jak zoptymalizować buforowanie warstw Docker podczas budowania aplikacji Go?

5

Jaka jest zaleta używania obrazów Google Distroless dla Go w porównaniu ze scratch?

+17 pytań z rozmów

Opanuj Go na następną rozmowę

Uzyskaj dostęp do wszystkich pytań, flashcards, testów technicznych, ćwiczeń code review i symulatorów rozmów.

Zacznij za darmo