🐳 Как уменьшить размер контейнера

Приготовили два практичных профиля для запуска: минимальный размер для утилит и микросервисов без тяжёлой динамики, и быстрый старт для веб-API.

Никаких хаков — только поддерживаемые фичи .NET 8.

Рецепт 1 — Минимальный размер

Шаги:
• Включите тримминг и сборку в один файл.
• Соберите self-contained бинарь.
• Упакуйте в chiseled/runtime-deps образ.

csproj:

<PropertyGroup>
  <TargetFramework>net8.0</TargetFramework>
  <RuntimeIdentifier>linux-x64</RuntimeIdentifier>
  <SelfContained>true</SelfContained>
  <PublishSingleFile>true</PublishSingleFile>
  <PublishTrimmed>true</PublishTrimmed>
  <TrimMode>link</TrimMode>
  <InvariantGlobalization>true</InvariantGlobalization>
  <StripSymbols>true</StripSymbols>
</PropertyGroup>

Dockerfile:

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY . .
RUN dotnet publish -c Release -o /out

FROM mcr.microsoft.com/dotnet/runtime-deps:8.0-jammy-chiseled AS final
WORKDIR /app
COPY --from=build /out ./
USER 10001
ENTRYPOINT ["./YourApp"]   # self-contained бинарь

Важно: триммер удаляет неиспользуемый код. При рефлексии используйте атрибуты DynamicallyAccessedMembers, DynamicDependency или дескриптор ILLink.Descriptors.xml. InvariantGlobalization=true экономит место, но отключает локали ICU.

Рецепт 2 — Быстрый старт

Шаги:
• Включите ReadyToRun.
• Соберите framework-dependent (меньше JIT при старте).
• Упакуйте в chiseled ASP.NET образ.

csproj:

<PropertyGroup>
  <TargetFramework>net8.0</TargetFramework>
  <PublishReadyToRun>true</PublishReadyToRun>
  <RuntimeIdentifier>linux-x64</RuntimeIdentifier>
  <SelfContained>false</SelfContained>
  <StripSymbols>true</StripSymbols>
</PropertyGroup>

Dockerfile:

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY . .
RUN dotnet publish -c Release -o /out

FROM mcr.microsoft.com/dotnet/aspnet:8.0-jammy-chiseled AS final
WORKDIR /app
COPY --from=build /out ./
USER 10001
ENTRYPOINT ["dotnet", "YourApp.dll"]

Холодный старт:

docker run -p 8080:8080 app:test &
curl -w '\nTime: %{time_total}s\n' -s http://localhost:8080/health/ready -o /dev/null

Мини-усиление безопасности в Dockerfile:

# после COPY и USER
VOLUME ["/app/data"]
ENV ASPNETCORE_URLS=http://0.0.0.0:8080
# файловая система только для чтения
READONLY rootfs

Два профиля покрывают 80% кейсов: минимальный образ для утилит/микросервисов без тяжёлой динамики и быстрый старт для веб-API. Дальше — NativeAOT, если нужен экстремальный старт и размер.

🐸Библиотека шарписта

#буст

Откопал мощный плагин для веба и SEO-оптимизации

Это расширение находит за вас ошибки на страницах, битые ссылки, косячные мета-теги и всякие другие мелочи, которые мешают сайту выбиться в топ. Плюс — сразу даёт рекомендации, как улучшить позиции сайта в поиске.

Вещь реально полезная, так что обязательно сохраняйте 🍷

🖥 Большинство .NET разработчиков никогда с этим не сталкиваются.

Но это делает отладку в 10 раз проще.

Стандартный вид при отладке:

{Namespace.ObjectName}

Никакого контекста. Много путаницы.

Но всего одной строкой кода?

Теперь окно наблюдения показывает:

Order ORD-2025-002: Bob Evans - 89.50
Order ORD-2025-003: Maria Lee - 1200.00

В чём фишка?

Используйте DebuggerDisplay.

Добавляете этот атрибут в начало класса, чтобы контролировать, как будет отображаться информация о классе при отладке.

В следующий раз, когда будете смотреть на {Namespace.ObjectName}, помните: так не обязательно должно быть.

🖥 Полезная фишка в C#, о которой никто не знает

Этот прием позволяет создавать высокопроизводительные .NET-приложения.

Разработка надёжных, масштабируемых и быстрых .NET-приложений во многом зависит от того, как вы организуете конкуренцию и обработку данных.

Во время разработки .NET-приложений часто возникает необходимость передавать данные из одной части кода в другую.

Ранее для этого использовали такие конструкции, как Queue<T>, ConcurrentQueue<T> или BlockingCollection<T>.

Эти очереди оборачивали в классы и применяли для управления потоками данных.

Однако у таких решений есть существенный минус — сильная связанность кода. 💊

Channels в C# это малоизвестная, но мощная фишка, которая предлагает современный способ построения безопасных, асинхронных и высоконагруженных .NET-приложений.

Они реализуют паттерн "производитель-потребитель": один класс создаёт данные, другой их потребляет - при этом оба ничего не знают друг о друге.

Ключевым архитектурным моментом при работе с каналами является выбор между ограниченными и неограниченными каналами.

В этом гайд, где узнаете:

🟠Что такое C# Channels?
🟠 Ограниченные vs. неограниченные каналы
🟠 Фоновая обработка через Channels
🟠 Применение каналов в боевом ASP.NET Core-приложении
🟠 Лучшие практики и советы по работе с Channels