Какие решал проблемы эксплуатации проекта ASP.NET Core, созданного по шаблону?

Типичные проблемы эксплуатации ASP.NET Core проекта и их решения

Разработка и запуск проекта ASP.NET Core по шаблону (из Visual Studio или через dotnet new) — это лишь начало. При переходе к эксплуатации (deployment, maintenance, scaling) возникает ряд характерных проблем, которые я регулярно решал в своей практике.

Проблема 1: Неправильная конфигурация для разных окружений

Шаблонный проект часто содержит только базовый appsettings.json. В эксплуатации требуются отдельные конфигурации для development, staging, production.

// Program.cs — правильная настройка конфигурации
public static IHostBuilder CreateHostBuilder(string[] args) =>
    Host.CreateDefaultBuilder(args)
        .ConfigureAppConfiguration((context, config) =>
        {
            // Базовый файл
            config.AddJsonFile("appsettings.json", optional: false);
            
            // Файл для конкретного окружения
            config.AddJsonFile(
                $"appsettings.{context.HostingEnvironment.EnvironmentName}.json",
                optional: true
            );
            
            // Переменные среды для Production (например, в Docker)
            config.AddEnvironmentVariables();
            
            // User secrets для Development (не для Production!)
            if (context.HostingEnvironment.IsDevelopment())
            {
                config.AddUserSecrets<Program>();
            }
        })
        .ConfigureWebHostDefaults(webBuilder =>
        {
            webBuilder.UseStartup<Startup>();
        });

Решение:

• Создание appsettings.Production.json, appsettings.Staging.json
• Использование environment variables для секретных данных (паролей DB, API ключей)
• Настройка CI/CD для замены конфигураций при деплое

Проблема 2: Неоптимальные настройки Kestrel сервера

Шаблонный Kestrel конфигурируется минимально. В production нужны тонкие настройки для безопасности и производительности.

// В Program.cs или отдельном конфигурационном классе
webBuilder.UseKestrel(options =>
{
    // Лимиты для защиты от DDoS/перегрузки
    options.Limits.MaxRequestBodySize = 10_000_000; // 10MB
    options.Limits.MaxConcurrentConnections = 100;
    options.Limits.MaxConcurrentUpgradedConnections = 100;
    
    // Время ожидания
    options.Limits.KeepAliveTimeout = TimeSpan.FromMinutes(2);
    options.Limits.RequestHeadersTimeout = TimeSpan.FromSeconds(30);
    
    // Для HTTPS в Production
    if (!context.HostingEnvironment.IsDevelopment())
    {
        options.Listen(IPAddress.Any, 443, listenOptions =>
        {
            listenOptions.UseHttps("certificate.pfx");
        });
    }
});

Проблема 3: Отсутствие корректного health-check мониторинга

Шаблон не включает health checks, что критично для эксплуатации (мониторинг, балансировка нагрузки).

// Startup.cs
public void ConfigureServices(IServiceCollection services)
{
    // Добавление health checks
    services.AddHealthChecks()
        .AddCheck<DatabaseHealthCheck>("database", timeout: TimeSpan.FromSeconds(3))
        .AddCheck<ExternalApiHealthCheck>("external_api", timeout: TimeSpan.FromSeconds(5))
        .AddCheck<MemoryHealthCheck>("memory", timeout: TimeSpan.FromSeconds(1));
}

public void Configure(IApplicationBuilder app)
{
    // Endpoint для health checks
    app.UseEndpoints(endpoints =>
    {
        endpoints.MapHealthChecks("/health", new HealthCheckOptions
        {
            ResponseWriter = async (context, report) =>
            {
                // Кастомный JSON ответ для систем мониторинга
                context.Response.ContentType = "application/json";
                await context.Response.WriteAsync(
                    JsonSerializer.Serialize(new
                    {
                        status = report.Status.ToString(),
                        checks = report.Entries.ToDictionary(e => e.Key, e => e.Value.Status.ToString())
                    })
                );
            }
        });
        endpoints.MapControllers();
    });
}

Проблема 4: Логирование, не адаптированное для production

Шаблонное логирование через ILogger часто пишет только в консоль. Для эксплуатации нужна структурированная система.

// Program.cs — настройка Serilog (популярное решение)
Host.CreateDefaultBuilder(args)
    .UseSerilog((context, configuration) =>
    {
        configuration
            .ReadFrom.Configuration(context.Configuration)
            .Enrich.FromLogContext()
            .WriteTo.File(
                "logs/log-.txt",
                rollingInterval: RollingInterval.Day,
                retainedFileCountLimit: 30
            )
            .WriteTo.Seq("http://seq-server:5341") // Централизованное хранилище логов
            .WriteTo.Console(outputTemplate: 
                "[{Timestamp:HH:mm:ss} {Level:u3}] {Message:lj}{NewLine}{Exception}");
    });

Что мы добавляем для эксплуатации:

• Structured logging (JSON формат для анализа)
• Centralized log storage (ELK, Seq, Azure App Insights)
• Log levels разграничены по окружениям (Debug только в Development, Error/Warning в Production)

Проблема: 5: Недостаточная обработка ошибок и exception middleware

Шаблон дает базовый обработчик ошибок, но для production нужен детальный контроль.

// Кастомный middleware для обработки исключений
public class GlobalExceptionMiddleware
{
    private readonly RequestDelegate _next;
    private readonly ILogger<GlobalExceptionMiddleware> _logger;

    public GlobalExceptionMiddleware(RequestDelegate next, ILogger<GlobalExceptionMiddleware> logger)
    {
        _next = next;
        _logger = logger;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        try
        {
            await _next(context);
        }
        catch (Exception ex)
        {
            _logger.LogError(ex, "Unhandled exception");
            
            // Кастомный ответ вместо стандартного
            context.Response.ContentType = "application/json";
            context.Response.StatusCode = (int)HttpStatusCode.InternalServerError;
            
            await context.Response.WriteAsync(JsonSerializer.Serialize(
                new ErrorResponse
                {
                    Message = "Internal server error",
                    ErrorId = Guid.NewGuid().ToString() // Для отслеживания в логах
                }
            ));
        }
    }
}

// В Startup.cs
app.UseMiddleware<GlobalExceptionMiddleware>();

Проблема 6: Конфигурация базы данных без resilience policies

Шаблонные DB контексты не готовы к сбоям сети/DB в production.

// Startup.cs — добавление resilience
services.AddDbContext<ApplicationDbContext>(options =>
{
    options.UseSqlServer(
        configuration.GetConnectionString("DefaultConnection"),
        sqlOptions =>
        {
            // Retry policy для временных сбоев
            sqlOptions.EnableRetryOnFailure(
                maxRetryCount: 5,
                maxRetryDelay: TimeSpan.FromSeconds(30),
                errorNumbersToAdd: null
            );
            
            // Command timeout
            sqlOptions.CommandTimeout(60);
        }
    );
});

// Или через Polly для любых внешних сервисов
services.AddHttpClient<ExternalServiceClient>()
    .AddTransientHttpErrorPolicy(policy =>
        policy.WaitAndRetryAsync(3, retryAttempt =>
            TimeSpan.FromSeconds(Math.Pow(2, retryAttempt))
        )
    );

Проблема 7: Отсутствие подготовки к горизонтальному масштабированию

Шаблонный проект не учитывает проблемы при запуске нескольких инстансов.

Решаемые вопросы:

• Сессии (переход от in-memory к распределенному хранилищу, например Redis)
• Кеширование (distributed cache вместо memory cache)
• Фоновые задачи (использование Hangfire или Azure Functions вместо BackgroundService)
• Файловые ресурсы (переход от локальных файлов к Azure Blob Storage или AWS S3)

// Пример перехода на distributed cache
services.AddStackExchangeRedisCache(options =>
{
    options.Configuration = configuration.GetConnectionString("Redis");
    options.InstanceName = "MyAppInstance";
});

// Сессии с Redis
services.AddSession(options =>
{
    options.IdleTimeout = TimeSpan.FromMinutes(20);
    options.Cookie.HttpOnly = true;
    options.Cookie.IsEssential = true;
});

Проблема 8: Не настроенная безопасность для production

Шаблон включает базовую безопасность, но требует усиления.

Что добавляем:

• CORS политики строго по доменам production
• HTTPS редирект и HSTS (HTTP Strict Transport Security)
• Детальная авторизация и аутентификация с JWT или IdentityServer
• Rate limiting для API endpoints
• Security headers (X-Content-Type-Options, X-Frame-Options)

// В Startup.Configure
if (!env.IsDevelopment())
{
    app.UseHsts(); // Strict Transport Security
    app.UseHttpsRedirection();
}

app.UseCors(builder => builder
    .WithOrigins("https://myproductiondomain.com")
    .AllowAnyMethod()
    .AllowAnyHeader()
    .AllowCredentials());

Итог

Эксплуатация проекта ASP.NET Core требует глубокой переработки шаблонного решения. Ключевые направления:

1. Конфигурация и управление окружениями
2. Производительность и resilience
3. Мониторинг и логирование
4. Безопасность
5. Подготовка к масштабированию

Каждый пункт требует внедрения дополнительных библиотек, middleware и изменения архитектуры. Это превращает "шаблонный" проект в production-ready приложение, способное работать стабильно под нагрузкой и в различных условиях.