Jak vytvořit vlastní poskytovatele konfigurace v ASP.NET Core 9?

V rámci vývoje aplikací v ASP.NET Core 9 je často nezbytné získávat a spravovat konfigurace z různých zdrojů, jako jsou soubory, databáze nebo environmentální proměnné. ASP.NET Core 9 nabízí robustní framework pro správu konfigurací, ale někdy se může stát, že aplikace vyžaduje integraci s vlastním poskytovatelem konfigurace. Tento proces zahrnuje vytvoření třídy, která definuje způsob, jakým se konfigurace načítá a poskytuje aplikaci.

K tomu, abyste vytvořili vlastní poskytovatele konfigurace v ASP.NET Core 9, musíte rozumět několika klíčovým principům. Začněme tím, jak ASP.NET Core nativně zajišťuje správu konfigurace a jak lze tento proces přizpůsobit pro vlastní potřeby.

ASP.NET Core 9 nabízí několik vestavěných poskytovatelů konfigurace, jako jsou AddEnvironmentVariables() pro získávání konfigurace z environmentálních proměnných nebo AddCommandLine() pro načítání parametrů příkazové řádky. Tyto metody jsou součástí frameworku a umožňují aplikacím jednoduše získávat konfiguraci z různých zdrojů. Nicméně pro složitější scénáře, jako je připojení k vlastní databázi nebo cloudovým službám, může být nutné vytvořit vlastní poskytovatele konfigurace.

Vytváření vlastního poskytovatele konfigurace

Abychom vytvořili vlastní poskytovatele konfigurace, potřebujeme implementovat dvě hlavní třídy: ConfigurationSource a ConfigurationProvider.

Třída ConfigurationProvider, která dědí od abstraktní třídy ConfigurationProvider, se stará o samotné načítání a poskytování dat. Je zodpovědná za to, jak jsou data čtena, cachována a zpřístupněna aplikaci.

Příklad implementace CustomConfigurationSource může vypadat takto:

csharp
Copy code
using Microsoft.Extensions.Configuration;

public class CustomConfigurationSource : IConfigurationSource

{
    public IConfigurationProvider Build(IConfigurationBuilder builder)
    {
        return new CustomConfigurationProvider();
    }
}

Tato třída má pouze jednu metodu Build(), která vrací instanci poskytovatele konfigurace. Tento design nám umožňuje mít čistý a snadno rozšiřitelný kód, protože se zde oddělují odpovědnosti za získávání a načítání dat.

Pokud jde o samotné načítání dat, třída CustomConfigurationProvider by mohla vypadat následovně:

csharp
Copy code
using Microsoft.Extensions.Configuration;

using System.Collections.Generic;
public class CustomConfigurationProvider : ConfigurationProvider
{

    public override void Load()

    {
        var data = new Dictionary<string, string>
        {
            { "MyCustomSetting:Key1", "Value1" },
            { "MyCustomSetting:Key2", "Value2" }
        };
        Data = data;
    }
}

Po implementaci vlastního poskytovatele je nutné přidat tento poskytovatel do aplikace pomocí metody Add() v souboru Program.cs:

csharp
Copy code
builder.Configuration.Add(new CustomConfigurationSource());

Pro získání hodnoty z nové konfigurace pak stačí použít metody jako GetValue(), které jsou součástí rozhraní IConfiguration:

csharp
Copy code
string key1 = _configuration.GetValue<string>("MyCustomSetting:Key1");

string key2 = _configuration.GetValue<string>("MyCustomSetting:Key2");

Možnosti rozšíření a silně typovaná konfigurace

I když je tento příklad poměrně jednoduchý, lze vlastní poskytovatele konfigurace rozšířit a připojit je k různým trvalým úložištím, jako jsou databáze nebo cloudová úložiště. Tento flexibilní přístup k poskytovatelům konfigurace umožňuje vývojářům přizpůsobit aplikaci specifickým potřebám.

Výhody a flexibilité poskytovatelů konfigurace

Poskytovatelé konfigurace v ASP.NET Core 9 jsou skvělým nástrojem pro práci s dynamickými a externími konfiguracemi. Umožňují aplikacím být flexibilní, protože poskytovatel může snadno přistupovat k různým externím zdrojům konfigurace. Ať už se jedná o cloudové prostředí, API třetích stran nebo vlastní formáty souborů, vlastním poskytovatelem lze implementovat libovolný způsob načítání a poskytování konfigurace.

Jak generovat balíčky pro publikování aplikace v ASP.NET Core 9?

Generování balíčků pro publikování aplikace je jedním z klíčových kroků při přípravě na nasazení a hostování aplikace. K tomu, abyste pochopili, jak tento proces funguje, použijeme příklad aplikace, který jsme již stáhli z GitHubu a který budeme využívat po celou dobu této kapitoly.

Příkaz dotnet publish poskytuje několik možností, které nám umožňují nastavit parametry výstupu publikovaného balíčku. Některé z těchto možností jsou:

• -c, --configuration: Určuje konfiguraci sestavení (například Debug nebo Release). Konfigurace Debug je optimalizována pro ladění, zatímco Release je určena pro produkční nasazení a je optimalizována pro výkon.

• -f, --framework: Určuje cílový rámec aplikace, například net8.0.

• -r, --runtime: Určuje, pro jakou platformu bude aplikace publikována (například win-x64 nebo linux-x64).

• -o, --output: Určuje adresář, do kterého budou umístěny publikované soubory.

• --self-contained: Publikuje aplikaci jako samostatně spustitelnou, včetně .NET runtime, což znamená, že na cílovém serveru není nutné mít nainstalován .NET SDK nebo runtime.

• --no-restore: Zakazuje obnovení závislostí při publikování, což je užitečné například při použití CI/CD pipeline.

Chcete-li vygenerovat balíček pro aplikaci UrlShortener, stačí otevřít terminál nebo Bash, přejít do složky s aplikací a spustit následující příkaz:

bash
Copy code
dotnet publish UrlShortener.csproj -c Release -o ./published

Tento příkaz vygeneruje balíček v adresáři ./published, který bude připraven pro nasazení. Pokud se podíváme na obsah tohoto adresáře, uvidíme nejen soubory konfigurace, ale také všechny závislosti aplikace – různé .dll soubory, které aplikace používá, a statické soubory, jako jsou obrázky, CSS a JavaScript, umístěné v adresáři wwwroot. Takto připravený balíček je připraven k nasazení na server.

Po publikování můžeme aplikaci spustit z terminálu příkazem:

bash
Copy code
dotnet UrlShortener.dll

Tento soubor UrlShortener.dll je spustitelný soubor pro aplikaci ASP.NET Core 9, který lze spustit na vývojovém stroji, kde je nainstalováno .NET SDK. Na serverech, které budou aplikaci hostovat, však není potřeba mít nainstalován .NET SDK, ale pouze .NET Runtime.

Pokud se rozhodneme aplikaci publikovat do cloudového prostředí, musíme také zohlednit několik dalších aspektů. V dnešní době je téměř nemožné vynechat cloudové prostředí při nasazování aplikací. Cloudové prostředí nabízí obrovské výhody, jako je snadná škálovatelnost, vysoká dostupnost a integrované nástroje pro správu a monitorování aplikací.

Připravenost aplikace na nasazení je důležitým krokem, který zahrnuje nejen generování publikovatelného balíčku, ale i rozhodnutí o tom, jakým způsobem bude aplikace hostována a jak bude zajištěn její výkon a dostupnost v reálném prostředí.

Pokud máte aplikaci připravenou pro publikování a hosting, je dalším krokem automatizace tohoto procesu pomocí CI/CD, což vám umožní efektivně spravovat nasazení a aktualizace aplikace v produkčním prostředí. Tento přístup si podrobněji probereme v dalších kapitolách, kde se budeme věnovat DevOps přístupu a automatizaci pomocí CI/CD pipeline.

Jak správně vytvořit a nasadit Docker kontejner pro .NET aplikaci

Pro nasazení aplikace v Dockeru používáme tzv. multi-stage build, což znamená, že celý proces výstavby aplikace probíhá v několika krocích. Každý z těchto kroků využívá jiný základní obraz, což vede k optimalizovanému výsledku. Tento přístup pomáhá odstranit všechny nepotřebné soubory a nástroje, které by mohly zvětšit velikost finálního obrazu. V následujícím textu si popíšeme, jak se tento proces realizuje v praxi.

Prvním krokem je vytvoření fáze Build, která bude zodpovědná za kompilaci aplikace. Začíná se vybráním obrazu, který obsahuje .NET SDK, v tomto případě verze 8.0, z repozitáře MCR (Microsoft Container Registry). Tato fáze definuje pracovní adresář a následně kopíruje projektové soubory do kontejneru. Poté následuje příkaz pro obnovení závislostí aplikace (dotnet restore), aby bylo možné pokračovat v dalším kroku – samotné kompilaci aplikace.

Poslední fází je Final stage, která používá výsledky z předchozích fází pro vytvoření obrazu, který bude skutečně nasazen na server. Tento obraz obsahuje pouze nezbytné součásti pro běh aplikace – samotný běhový prostředek a všechny související knihovny, ale žádné nástroje pro kompilaci nebo jiné nepotřebné soubory. Tento krok se soustředí na minimalizaci velikosti obrazu a maximalizaci výkonu.

dockerfile
Copy code
FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS base
WORKDIR /app
EXPOSE 8080
COPY ./published .
ENTRYPOINT ["dotnet", "UrlShortener.dll"]

Tento přístup je však vhodný pouze v případě, že máme jistotu, že naše aplikace bude vždy správně zkompilována před tím, než vytvoříme Docker image.

Jakmile máme připravený Dockerfile, můžeme přistoupit k samotnému procesu generování Docker obrazu. K tomu slouží příkaz docker build, který spustí definovaný proces podle instrukcí v Dockerfile. Příkaz vypadá takto:

bash
Copy code
docker build -t urlshortener:1.0 .

Tento příkaz spustí kompilaci obrazu s názvem urlshortener:1.0. Je důležité si uvědomit, že tagování obrazu verzí (v tomto případě 1.0) je doporučeno, protože umožňuje lepší správu verzí a kontrolu nad nasazovanými verzemi aplikace. Po úspěšném vytvoření obrazu lze pomocí příkazu docker images zkontrolovat, jaké obrazy jsou k dispozici v místním repozitáři.

Následuje fáze, kdy musíme spustit kontejner na základě vygenerovaného obrazu. K tomu slouží příkaz:

bash
Copy code
docker run -d -p 8899:8080 localhost/urlshortener:1.0

Tento příkaz spustí kontejner na pozadí (-d) a mapuje porty, což znamená, že aplikace běžící na portu 8080 uvnitř kontejneru bude dostupná na portu 8899 na hostitelském počítači. Tento přístup umožňuje snadné testování aplikace v izolovaném prostředí.

Pokud budeme mít více verzí aplikace, můžeme jednoduše přidělovat různé tagy pro každý vygenerovaný obraz, což nám umožní mít přehled o jednotlivých verzích a jejich nasazení. Je důležité si uvědomit, že kontejnery jsou neměnné objekty. Jakákoliv změna aplikace si vyžádá vygenerování nového obrazu s novým tagem, což je zásadní pro udržení konzistence a správu verzí.