Пользовался докером?

Опыт работы с Docker в C# Backend-разработке

Да, я активно использую Docker в C# Backend-разработке на протяжении последних 5+ лет. В моей практике это не просто инструмент для "упаковки" приложений, а фундаментальная часть DevOps-культуры и жизненного цикла разработки.

Ключевые аспекты моего опыта:

1. Контейнеризация ASP.NET Core приложений

# Типичный Dockerfile для ASP.NET Core приложения
FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS base
WORKDIR /app
EXPOSE 8080
EXPOSE 8081

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY ["MyApi/MyApi.csproj", "MyApi/"]
RUN dotnet restore "MyApi/MyApi.csproj"
COPY . .
RUN dotnet build "MyApi.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "MyApi.csproj" -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "MyApi.dll"]

2. Многоступенчатая сборка (multi-stage builds)

• Оптимизация размеров образов (от 2GB до 200MB)
• Разделение сборки и рантайма
• Кэширование зависимостей для ускорения сборок

3. Docker Compose для локальной разработки

version: '3.8'
services:
  api:
    build: .
    ports:
      - "5000:8080"
    environment:
      - ConnectionStrings__Default=Host=db;Database=appdb
    depends_on:
      - db
      - redis
  
  db:
    image: postgres:15
    environment:
      POSTGRES_DB: appdb
      POSTGRES_PASSWORD: securepass
  
  redis:
    image: redis:7-alpine
  
  seq:
    image: datalust/seq:latest
    ports:
      - "5341:5341"

Практические сценарии использования:

1. Унификация сред разработки

• Единая среда для всех разработчиков
• Быстрый онбординг новых членов команды
• Воспроизводимость окружений

2. CI/CD пайплайны

# Пример этапов в GitLab CI
stages:
  - build
  - test
  - deploy

build:
  stage: build
  script:
    - docker build -t myapp:$CI_COMMIT_SHA .
    - docker tag myapp:$CI_COMMIT_SHA registry.mycompany.com/myapp:latest
  
test:
  stage: test
  script:
    - docker-compose -f docker-compose.test.yml up --abort-on-container-exit

3. Микросервисная архитектура

• Изоляция сервисов
• Независимое масштабирование
• Сетевое взаимодействие через Docker networks

Реальные проектные задачи:

Производительность и оптимизация:

• Использование .dockerignore для исключения ненужных файлов
• Настройка layer caching для ускорения сборок
• Оптимизация порядка инструкций в Dockerfile

Безопасность:

• Запуск контейнеров от непривилегированных пользователей
• Регулярное обновление базовых образов
• Сканирование образов на уязвимости (Trivy, Clair)

Orchestration:

• Опыт миграции с Docker Compose на Kubernetes
• Настройка health checks, readiness/liveness probes
• Управление секретами через Docker Secrets

Проблемы и решения:

1. Проблема: Большой размер образов с полным SDK Решение: Многоступенчатая сборка с использованием только рантайма

2. Проблема: Медленная сборка в CI/CD Решение: Кэширование NuGet пакетов через volume mounts

3. Проблема: Отладка в контейнерах Решение: Использование dotnet watch в Development-образе

Интеграция с экосистемой .NET:

• Visual Studio Docker Tools для локальной разработки
• dotnet publish с оптимизацией для контейнеров
• Container Registry в Azure DevOps
• Portainer для визуального управления

Docker стал неотъемлемой частью моего workflow как C# разработчика. Он позволяет создавать предсказуемые, масштабируемые и переносимые среды выполнения, что критически важно для современных cloud-native приложений. Особенно ценю возможность быстро разворачивать сложные зависимости (БД, кэши, message brokers) для локального тестирования и разработки.