Go

Docker & Containerization

Dockerfile, multi-stage build, ottimizzazione delle immagini, docker-compose, orchestrazione dei container

20 domande da colloquio·
Senior
1

Qual è il motivo principale per usare un multi-stage build per un'applicazione Go?

Risposta

Il multi-stage build separa l'ambiente di compilazione dall'immagine finale. Lo stage di build contiene l'intero SDK Go (diverse centinaia di MB), mentre l'immagine finale contiene solo il binario compilato. Questo riduce drasticamente la dimensione dell'immagine (da ~800MB a pochi MB) e minimizza la superficie di attacco eliminando gli strumenti di build non necessari in produzione.

2

Quale immagine di base è consigliata per un'applicazione Go in produzione per minimizzare dimensione e superficie di attacco?

Risposta

L'immagine scratch è un'immagine vuota senza sistema operativo. Go compila in binari statici che non necessitano di libc o altre dipendenze di sistema, rendendo scratch utilizzabile. Questo produce le immagini più piccole possibili (pochi MB) e offre la migliore sicurezza poiché non ci sono strumenti o shell sfruttabili. Distroless e alpine sono alternative valide ma meno ottimali.

3

Quali flag di compilazione Go sono necessari per creare un binario compatibile con un'immagine scratch?

Risposta

CGO_ENABLED=0 disabilita cgo, forzando Go a usare implementazioni pure Go per package come net e os/user. Senza questo, il binario avrebbe dipendenze dinamiche da libc. GOOS e GOARCH specificano la piattaforma di destinazione. Questi flag combinati producono un binario completamente statico senza dipendenze esterne, ideale per scratch.

4

Come ottimizzare il caching dei layer Docker durante il build di un'applicazione Go?

5

Qual è il vantaggio di usare le immagini Google Distroless per Go rispetto a scratch?

+17 domande da colloquio

Padroneggia Go per il tuo prossimo colloquio

Accedi a tutte le domande, flashcards, test tecnici, esercizi di code review e simulatori di colloquio.

Inizia gratis