Практичний посібник з .NET контейнерних образів

💡 Усі статті, обговорення, новини про .NET — в одному місці. Приєднуйтесь до .NET спільноти!

Коли ви витягуєте контейнерний образ з mcr.microsoft.com/dotnet/*, ви отримуєте не лише runtime. Ви отримуєте продумано шарований набір образів, кожен з яких оптимізований для безпеки, легкості та конкретної мети.

Розуміння цих шарів спрощує усунення неполадок, підвищує продуктивність, покращує безпеку та допомагає обирати правильний образ для вашого додатку.

Розуміння сімейств образів .NET

.NET контейнерні образи об’єднані у сімейства, кожне з яких призначене для конкретної ролі: збірка додатків, запуск, хостинг веб-застосунків або база для самостійних додатків.

Кожне сімейство будується на нижчому шарі, додаючи лише необхідне. Ці шари безпосередньо впливають на розмір образу та включені за замовчуванням бібліотеки.

Розмір контейнерного образу vs Сімейство

Розміри образів наведені у незжатому вигляді, отримані за допомогою docker image ls.

Розбір шарів

1. Runtime-Deps Layer

Це базовий шар: мінімальний Linux-образ з достатньою кількістю бібліотек для запуску нативного .NET-бінарника.

Використання:

• Самодостатні додатки, які містять власний runtime
• Додатки з Native AOT (Ahead-of-Time) компіляцією

Включає:

• Системні бібліотеки (наприклад, libc, libssl)
• CA сертифікати для HTTPS

dotnet publish -c Release -r linux-x64 —self-contained true -o ./out

2. .NET Runtime Layer

Додає .NET runtime, щоб додатки, залежні від фреймворку, могли працювати.

Ідеально для:

• CLI інструментів, фонових процесів, gRPC-сервісів
• Невеб-застосунків

Примітка: не включає веб-специфічні бібліотеки та компілятори.

3. ASP.NET Layer

Оптимізований для хостингу ASP.NET Core додатків.

Включає:

• Веб-сервер Kestrel
• Бібліотеки MVC, SignalR

Найкраще для:

• Продакшн веб-API та веб-застосунків

4. SDK Layer

Містить усе необхідне для зборки та тестування .NET-додатків, але не призначений для продакшн.

Включає:

• Компилятори та інструменти збірки (MSBuild)
• Керування пакетами NuGet
• Git

Рекомендація: використовуйте багатоступеневі Dockerfile, щоб отримати легкі продакшн-образи.

dockerfile

# Приклад багатоступеневого Dockerfile

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build

WORKDIR /src

COPY . .

RUN dotnet publish -c Release -o /app

FROM mcr.microsoft.com/dotnet/aspnet:8.0

COPY —from=build /app /app

Анатомія тегу образу

Кожен тег .NET контейнерного образу кодує п’ять ключових параметрів:

1. Версія .NET
2. Базова ОС
3. Варіант дистрибутива
4. Тип runtime
5. Архітектура CPU

Розуміння цих компонентів допомагає робити свідомий вибір щодо розміру, безпеки та сумісності, а не покладатися на значення за замовчуванням.

Варіанти образів

Варіанти налаштовують базовий образ під конкретні потреби. Вони можуть:

• Додавати або прибирати оболонки чи менеджери пакетів
• Підтримувати глобалізацію
• Оптимізувати швидкість старту

Цей вибір впливає на розмір, продуктивність та безпеку образу.

Приклад: «jammy» — кодова назва релізу Ubuntu, що використовується у деяких варіантах.

Composite Variant (-composite)

Composite-образи об’єднують всі спільні бібліотеки фреймворку у один попередньо скомпільований бінарник, зменшуючи час JIT та пришвидшуючи холодний старт.

Переваги:

• Швидкий старт (особливо для serverless чи короткоживучих задач)

Недоліки:

• Більший базовий шар
• Фіксована версія (оновлення потребує повного перезбірки образу)
• Не підходить для плагін-систем, де потрібна заміна окремих DLL

Створення composite-образу:

dotnet publish /p:PublishReadyToRun=true

Distroless Images

Distroless-образи — це мінімалістичні контейнери, що зменшують вразливості та розмір.

Особливості:

• Без shell, без менеджера пакетів, без root-доступу
• Виконання за замовчуванням під користувачем додатку
• Для повної підтримки глобалізації додайте -extra

Примітка: Alpine Linux використовує musl замість glibc. Багато glibc-бінарників не запустяться на Alpine без перекомпіляції або шару сумісності, наприклад, gcompat.

Native AOT Images

Native AOT (Ahead-of-Time) образи компілюють додатки у один нативний бінарник, повністю обходячи CoreCLR та JIT.

Переваги:

• Дуже швидкий старт
• Малий об’єм пам’яті
• Компактний образ (часто <30 МБ)
• Не потрібен .NET runtime

Команда збірки:

dotnet publish -c Release -r linux-x64 /p:PublishAot=true

Використання:

• Build: sdk:*‑aot
• Run: runtime-deps:*‑aot

Безпека

Кожен додатковий пакет підвищує ризик уразливостей. Великі образи часто містять оболонки, компілятори та інструменти відладки, що зручно для розробки, але небезпечно у продакшн.

Перехід від «важкого» Debian ASP.NET образу до легкого Alpine суттєво зменшує кількість пакетів і поверхню атак.

Висновок

Не існує універсально «найкращого» .NET контейнерного образу — є лише той, що підходить для вашого сценарію.

• Повний SDK: зручний для збірки, не ідеальний для продакшн
• Distroless: малий, безпечний, обмежена відладка
• Composite або AOT: оптимізований для швидкого старту та мінімального розміру

Розуміння шарів офіційних образів дозволяє робити свідомий вибір, відповідно до того, як і де працює ваш додаток. Обирайте образи за потребою, а не за звичкою.