Doconut in verteilter Serverkonfiguration verwenden

Wenn Sie PDFs, Office‑Dateien, CAD‑Zeichnungen oder Bilder von einem Cluster aus ASP.NET Core‑Knoten aus bereitstellen müssen, ermöglicht der distributed mode von Doconut, dass jeder Knoten dieselben Seiten‑Artefakte von einem gemeinsamen Speicherort liest. Das Ergebnis ist ein horizontal skalierbarer, sicherer Viewer, der hinter einem Load Balancer ohne Sticky‑Sessions funktioniert.

Warum der verteilte Modus wichtig ist

• Skalierbarkeit – Jeder Knoten kann Seiten zu einem UNC‑ oder Cloud‑Share veröffentlichen; jeder andere Knoten kann sie sofort bereitstellen.
• Sicherheit – Artefakte werden verschlüsselt im gemeinsamen Ordner gespeichert; der Viewer prüft jede Anfrage gegen das ASP.NET‑Session‑Token.
• Keine Office‑Abhängigkeit – Das Converter‑Plugin läuft serverseitig und konvertiert Word, Excel, PowerPoint, CAD und Bilder zu PDF oder Bildern, ohne Microsoft Office zu installieren.

Diese Eigenschaften ermöglichen es Unternehmens‑DMS, CRM‑ oder E‑Learning‑Portalen, die Dokumentenverarbeitung im .NET‑Backend zu behalten und gleichzeitig auf Dutzende von Containern zu skalieren.

Gemeinsamer Speicher für den verteilten Modus

Im verteilten Modus erwartet Doconut, dass die Seiten‑Artefakte (PDF‑Seiten, Bildkacheln usw.) in einem Speicherort geschrieben werden, der von jedem Knoten der Farm erreichbar ist – ein Netzwerk‑Share, Azure‑Blob‑Container, S3‑Bucket oder jeder andere gemeinsam genutzte Speicher, der von der Progressive‑Cloud‑Publishing‑Funktion unterstützt wird. Der Viewer sucht automatisch nach dem Artefakt‑Ordner, der dem Sicherheits‑Token des jeweiligen Dokuments entspricht, sodass kein zusätzlicher Code erforderlich ist, abgesehen davon, dass alle Knoten denselben Lese‑/Schreib‑Zugriff auf den gewählten Speicher haben.

Tip: Verwenden Sie denselben UNC‑Pfad (z. B. \\fileserver\doconut) oder Cloud‑URL in der Konfiguration jeder Instanz und halten Sie die Ordnerberechtigungen konsistent. Das Verhalten von UsePerTokenSubfolders ist standardmäßig aktiviert und isoliert die Seiten jedes Dokuments.

Registrierung von Doconut und Session‑Middleware

Doconut nutzt den ASP.NET Core‑Session‑State für die Sicherheit pro Dokument. Ein verteilter Cache wird nur benötigt, wenn Sie ein Minimal‑API‑Projekt verwenden; MVC oder Razor‑Pages fügen bereits einen hinzu.

builder.Services.AddDoconut(options =>
{
    options.LicensePath = "Doconut.Viewer.lic";
});

builder.Services.AddDistributedMemoryCache(); // Session benötigt einen Cache
builder.Services.AddSession();                 // Doconut validiert gegen Session

app.UseSession();               // Muss vor UseDoconut() ausgeführt werden
app.UseDoconutResources();      // Registriert statische Viewer-Assets
app.Map("/doconut", branch => branch.UseDoconut());

Benutzerdefinierte Pfade (optional)

Falls ein anderer Pfad mit /doconut kollidiert, ändern Sie die Pfade einmal und halten Sie den Client BasePath synchron:

builder.Services.AddDoconut(options =>
{
    options.MiddlewarePath = "/docs-engine";
    options.ResourcesPath  = "/docs-assets";
});
app.UseDoconutResources();
app.Map("/docs-engine", branch => branch.UseDoconut());

Fügen Sie niemals einen führenden Schrägstrich zu MiddlewarePath oder ResourcesPath hinzu; der Viewer fügt den Schrägstrich automatisch ein.

Alles zusammenführen: Minimal‑API‑Beispiel

Unten finden Sie ein kompaktes, produktionsreifes Setup, das die Anforderungen an Shared‑Storage, Session‑Handling und Doconut‑Registrierung kombiniert.

var builder = WebApplication.CreateBuilder(args);

// 1️⃣ Core Doconut Registrierung
builder.Services.AddDoconut(options =>
{
    options.LicensePath = Path.Combine(
        AppContext.BaseDirectory, "wwwroot", "Doconut.Viewer.lic");
    options.MiddlewarePath = "/doconut";
    options.ResourcesPath  = "/doconut-res";
});

// 2️⃣ Session und Cache (erforderlich für Sicherheit)
builder.Services.AddDistributedMemoryCache();
builder.Services.AddSession();

var app = builder.Build();

app.UseRouting();
app.UseSession();
app.UseDoconutResources();                     // statisches Viewer-Bundle
app.Map("/doconut", branch => branch.UseDoconut());

app.Run();

Stellen Sie diese Binärdatei in beliebig vielen Docker‑Containern oder Windows‑Diensten hinter einem Load Balancer bereit. Solange jede Instanz den von Ihnen konfigurierten Shared‑Storage‑Ort für Seiten‑Artefakte erreichen kann, ruft der Viewer Seiten von jedem Knoten ab, und Uploads/Konvertierungen überstehen Knoten‑Sprünge.

Bereitstellung hinter einem Load Balancer

1. Gleiche Basis‑URL bereitstellen (z. B. ` on every node.
2. Sticky‑Sessions deaktivieren – Der verteilte Modus von Doconut eliminiert die Notwendigkeit von Session‑Affinity.
3. Gesundheits‑Monitoring sicherstellen prüft einen Basis‑Endpunkt Ihrer Anwendung (z. B. /health), sodass der Balancer den Datenverkehr nur zu aktiven Knoten leitet.
4. Den gemeinsamen Ordner überwachen auf Wachstum; die Standard‑TTL von 30 Minuten begrenzt den Speicher, kann jedoch je nach Compliance‑Anforderungen angepasst werden.

Mit diesen Schritten kann Ihre dokumentenintensive .NET‑Anwendung Tausende von gleichzeitigen Viewern bedienen, jede Seite im Ruhezustand verschlüsselt halten und den Aufwand vermeiden, Office auf jedem Server zu installieren.

Bereit, es auszuprobieren? Holen Sie sich eine kostenlose Testversion von Doconut, starten Sie ein paar Container, richten Sie sie auf einen gemeinsamen UNC‑Pfad aus und beobachten Sie, wie der Viewer ohne ein einziges Sticky‑Session‑Cookie skaliert.