Go

Docker & Containerization

Dockerfile, multi-stage builds, optimización de imágenes, docker-compose, orquestación de contenedores

20 preguntas de entrevista·
Senior
1

¿Cuál es la razón principal para usar un multi-stage build en una aplicación Go?

Respuesta

El multi-stage build permite separar el entorno de compilación de la imagen final. La etapa de build contiene el SDK completo de Go (varios cientos de MB), mientras que la imagen final solo contiene el binario compilado. Esto reduce drásticamente el tamaño de la imagen (de ~800MB a unos pocos MB) y minimiza la superficie de ataque al eliminar herramientas de compilación innecesarias en producción.

2

¿Qué imagen base se recomienda para una aplicación Go en producción para minimizar el tamaño y la superficie de ataque?

Respuesta

La imagen scratch es una imagen vacía sin sistema operativo. Go compila a binarios estáticos que no necesitan libc ni otras dependencias del sistema, lo que permite usar scratch. Esto produce las imágenes más pequeñas posibles (unos pocos MB) y ofrece la mejor seguridad porque no hay ninguna herramienta ni shell explotable. Distroless y alpine son alternativas válidas pero menos óptimas.

3

¿Qué flags de compilación de Go son necesarios para crear un binario compatible con una imagen scratch?

Respuesta

CGO_ENABLED=0 desactiva cgo, forzando a Go a usar implementaciones pure Go para paquetes como net y os/user. Sin esto, el binario tendría dependencias dinámicas con libc. GOOS y GOARCH especifican la plataforma de destino. Estos flags combinados producen un binario totalmente estático sin dependencias externas, ideal para scratch.

4

¿Cómo optimizar el cache de las layers de Docker al hacer el build de una aplicación Go?

5

¿Cuál es la ventaja de usar las imágenes Google Distroless para Go en comparación con scratch?

+17 preguntas de entrevista

Domina Go para tu próxima entrevista

Accede a todas las preguntas, flashcards, tests técnicos, ejercicios de code review y simuladores de entrevista.

Empieza gratis