Go

Docker & Containerization

Dockerfile, multi-stage builds, оптимізація образів, docker-compose, оркестрація контейнерів

20 питань зі співбесід·
Senior
1

Яка основна причина використання multi-stage build для Go-застосунку?

Відповідь

Multi-stage build відокремлює середовище компіляції від фінального образу. Етап build містить повний Go SDK (кілька сотень МБ), тоді як фінальний образ містить лише скомпільований бінарний файл. Це різко зменшує розмір образу (з ~800МБ до кількох МБ) і мінімізує поверхню атаки, усуваючи непотрібні build-інструменти у продакшені.

2

Який базовий образ рекомендується для Go-застосунку в продакшені, щоб мінімізувати розмір і поверхню атаки?

Відповідь

Образ scratch — це порожній образ без операційної системи. Go компілюється у статичні бінарні файли, яким не потрібні libc чи інші системні залежності, що дозволяє використовувати scratch. Це створює найменші можливі образи (кілька МБ) і забезпечує найкращу безпеку, оскільки немає жодних інструментів чи shell, які можна було б експлуатувати. Distroless та alpine — це валідні, але менш оптимальні альтернативи.

3

Які прапорці компіляції Go необхідні для створення бінарного файлу, сумісного з образом scratch?

Відповідь

CGO_ENABLED=0 вимикає cgo, змушуючи Go використовувати чисто Go-реалізації для пакетів на кшталт net та os/user. Без цього бінарний файл мав би динамічні залежності від libc. GOOS та GOARCH визначають цільову платформу. Поєднання цих прапорців створює повністю статичний бінарний файл без зовнішніх залежностей, ідеальний для scratch.

4

Як оптимізувати кешування шарів Docker під час збірки Go-застосунку?

5

Яка перевага використання образів Google Distroless для Go порівняно зі scratch?

+17 питань зі співбесід

Опануй Go для наступної співбесіди

Отримай доступ до всіх питань, flashcards, технічних тестів, вправ code review та симуляторів співбесід.

Почни безкоштовно