Go

Docker & Containerization

Dockerfile, multi-stage builds, image-optimalisatie, docker-compose, container-orkestratie

20 gespreksvragen·
Senior
1

Wat is de belangrijkste reden om een multi-stage build te gebruiken voor een Go-applicatie?

Antwoord

De multi-stage build scheidt de compilatieomgeving van het uiteindelijke image. De build-stage bevat de volledige Go SDK (enkele honderden MB), terwijl het uiteindelijke image alleen de gecompileerde binary bevat. Dit verkleint de image-grootte drastisch (van ~800MB naar enkele MB) en minimaliseert het aanvalsoppervlak door onnodige build-tools in productie te verwijderen.

2

Welk base image wordt aanbevolen voor een Go-applicatie in productie om de grootte en het aanvalsoppervlak te minimaliseren?

Antwoord

Het scratch-image is een leeg image zonder besturingssysteem. Go compileert naar statische binaries die geen libc of andere systeemafhankelijkheden nodig hebben, waardoor scratch bruikbaar is. Dit levert de kleinst mogelijke images op (enkele MB) en biedt de beste beveiliging omdat er geen exploiteerbare tools of shell zijn. Distroless en alpine zijn geldige maar minder optimale alternatieven.

3

Welke Go-compilatieflags zijn vereist om een binary te maken die compatibel is met een scratch-image?

Antwoord

CGO_ENABLED=0 schakelt cgo uit en dwingt Go om pure Go-implementaties te gebruiken voor packages zoals net en os/user. Zonder dit zou de binary dynamische afhankelijkheden van libc hebben. GOOS en GOARCH specificeren het doelplatform. Deze gecombineerde flags produceren een volledig statische binary zonder externe afhankelijkheden, ideaal voor scratch.

4

Hoe optimaliseer je Docker-layercaching bij het bouwen van een Go-applicatie?

5

Wat is het voordeel van het gebruik van Google Distroless-images voor Go in vergelijking met scratch?

+17 gespreksvragen

Beheers Go voor je volgende gesprek

Krijg toegang tot alle vragen, flashcards, technische tests, code review-oefeningen en gespreksimulatoren.

Begin gratis