On-Premises-Installation

AppArch kann vollständig in Ihrer eigenen Infrastruktur laufen. Installationspaket und Lizenz erhalten Sie im Rahmen Ihres Vertrags vom AppArch-Team.

Das brauchen Sie vor der Installation

Element	Wozu es dient
Lizenz	Legt Limits und Laufzeit Ihrer Installation fest und gilt nur für eine Installation. Installationen mit Internetzugang holen sie beim ersten Start automatisch mit Ihren Installationsdaten; abgeschottete Installationen erhalten eine Datei `apparch.lic`, die an ihren Installationscode gebunden ist - siehe Eine Lizenz, eine Installation.
Installations-ID	Der Benutzername für die Anmeldung an der AppArch-Image-Registry.
Installationsschlüssel	Das Passwort für dieselbe Anmeldung. Wird einmalig übergeben.
Installationspaket	Die Konfigurationsdateien, die die Dienste starten, samt Schritt-für-Schritt-Anleitung.

Installations-ID und Schlüssel gehören zu Ihrer Lizenz: Die Images sind nicht öffentlich gelistet und lassen sich nur mit diesen Zugangsdaten laden.

docker login hub.apparch.io -u <installations-id> -p <installationsschlüssel>

Nach erfolgreicher Anmeldung starten Sie die Dienste anhand der Schritte in Ihrem Installationspaket.

Eine Lizenz, eine Installation

Es gibt keine Schlüsseldatei abzulegen: Der Schlüssel, der belegt, dass eine Lizenz von AppArch ausgestellt wurde, ist in die Images eingebaut.

Eine Lizenz gilt für eine Installation. Die erste Installation, die sie online abholt (Installations-ID + Installationsschlüssel), bindet sie an sich; fragt eine andere Installation dieselbe Lizenz an, wird sie mit “Diese Lizenz wird bereits von einer anderen Installation verwendet” abgewiesen.

Eine Installation ist alles, was eine Datenbank teilt: Jeder Pod und jedes Replikat liest denselben Installationscode. Api oder UI auf mehrere Pods zu skalieren läuft daher mit derselben Lizenz und braucht nichts von AppArch.

Abgeschottete Installationen erhalten eine Lizenzdatei, die an ihren Installationscode gebunden ist:

Starten Sie die Dienste.
Öffnen Sie im Einrichtungsassistenten den Lizenzschritt und wählen Sie die Option zum Einfügen einer Lizenzdatei, oder öffnen Sie bei einer bereits eingerichteten Installation Verwaltung → Einstellungen → Lizenz.
Kopieren Sie den dort angezeigten Installationscode und senden Sie ihn an AppArch.
Legen Sie die erhaltene .lic-Datei unter ./license/apparch.lic ab oder fügen Sie ihren Inhalt im Assistenten ein.

Diese Datei funktioniert nur auf dieser Installation.

Umzug auf einen neuen Server: Bitten Sie AppArch, die Lizenz freizugeben, und holen Sie sie dann vom neuen Server aus erneut ab.

Lizenziert bleiben

Eine Online-Installation meldet sich stündlich bei AppArch (https://gateway.apparch.io, ausgehendes HTTPS). Jede Meldung erneuert ihre Lizenz; Sie müssen nichts von Hand tun, aber der Server muss diese Adresse erreichen können.

Eine Lizenz mit Enddatum arbeitet zwei Wochen lang ohne erfolgreiche Meldung weiter, damit eine Firewall-Änderung oder ein Ausfall nichts sofort stoppt. Vergehen zwei Wochen ohne Meldung, hält die Installation an, bis sie AppArch wieder erreicht.
Eine Lizenz ohne Enddatum hängt nicht von der Meldung ab.
Air-gapped-Installationen melden sich nie: Ihre Lizenzdatei gilt bis zu ihrem Enddatum.

Wenn die Installation anhält - die Lizenz wurde widerrufen, die Meldung schlug zwei Wochen lang fehl, oder die Lizenz ist seit mehr als 14 Tagen abgelaufen - zeigt jede Ansicht außer der Verwaltung „Diese Installation ist angehalten” mit dem Grund, und nichts wird analysiert oder gespeichert. CI-Schritte schlagen nicht fehl: Der Collector gibt eine Warnung aus und läuft durch, eine Lizenz blockiert Ihre Merge Requests also nie. Eine gültige Lizenz unter Verwaltung → Einstellungen → Lizenz hebt den Stopp sofort auf, ohne Neustart.

Monatliche Limits. Ihre Lizenz kann ArchScan-Berichte, ArchSecurity-Läufe und ArchPilot-Kommentare pro Kalendermonat für die gesamte Installation begrenzen. Ein Bericht über dem Limit wird nicht gespeichert und der Collector läuft mit einer Warnung durch; ArchPilot zeichnet Reviews weiter auf, schreibt aber keine Kommentare mehr in Merge Requests. Die Limits werden am 1. des Monats zurückgesetzt; die aktuelle Nutzung steht unter Verwaltung → Einstellungen → Lizenz.

Lizenzierte Funktionen. Drei Funktionen hängen von Ihrer Lizenz ab: Single Sign-on (Anmeldung über LDAP), das Audit-Log (Ansicht Verwaltung → Audit; Aktionen werden immer aufgezeichnet) und erweitertes Reporting (Berichtsexporte und geplante Berichts-E-Mails). Welche Ihre Lizenz enthält, zeigt dieselbe Lizenzseite.

Serveranforderungen

Docker Engine 24+ mit Compose-Plugin
PostgreSQL und Redis (im Installationspaket enthalten)
Eine HTTP(S)-Adresse, die Ihre Nutzer erreichen
Online-Installationen: ausgehendes HTTPS zu gateway.apparch.io (stündliche Lizenzprüfung) und hub.apparch.io (Images)

Nach der Installation

Beim ersten Start erscheint der Einrichtungsassistent, in dem Sie das Administratorkonto anlegen.
Das Datenbankschema aktualisiert sich bei jedem Start selbst - Sie führen kein SQL von Hand aus.
E-Mail (SMTP oder Postmark), LDAP-Anmeldung und Lizenzerneuerung verwalten Sie im Bereich Verwaltung in der Anwendung.

On-Premises-Lizenzierung und Preise klärt das Vertriebsteam: apparch.io.

Einen Start beobachten

Die API erzählt ihren Start im Containerlog (docker compose logs -f api): Verbindung zur Datenbank (Host und Port, nie Zugangsdaten), Bootstrap-Sperre, ausstehende Migrationen, Seeden der Referenzdaten, Laden der Lizenz und schließlich Boot complete - accepting requests. Schlägt ein Start fehl, nennt eine einzelne Zeile über dem Stacktrace die gestorbene Phase.

Gesundheitsendpunkte

Beide Container bieten unauthentifizierte Proben:

Endpunkt	Bedeutung
`GET /health/live`	Der Prozess bedient HTTP. Keine Abhängigkeitsprüfung.
`GET /health/ready`	Bereit für Verkehr - die API prüft PostgreSQL und Redis, die UI prüft die API.

Die mitgelieferte docker-compose.yml verdrahtet sie als Container-Healthchecks (die UI wartet auf eine gesunde API, nicht bloß eine gestartete). In Kubernetes: livenessProbe auf /health/live, readinessProbe auf /health/ready, mit großzügigem Startfenster für die API - der erste Start führt Migrationen und Seeding aus.

Berichtsprüfungen

Commit-Prüfung. Jeder ArchScan-, ArchSecurity- und SmartScan-Bericht nennt seinen Commit; die API sucht ihn mit den Zugangsdaten des Projekts in dessen Repository. Ein Commit, den das Repository sicher nicht hat, wird mit 422 report_commit_not_found abgelehnt und der CI-Schritt schlägt fehl: das Projekt-Token wird in der Pipeline eines anderen Repositorys oder auf nie gepushter Arbeit verwendet. Lässt sich der Commit nicht prüfen (keine Zugangsdaten, Anbieter nicht erreichbar), wird der Bericht gespeichert. COMMIT_VERIFICATION=Record protokolliert nur, Off überspringt die Prüfung.
Komprimierte Berichte. Aktuelle Collectoren senden Berichte gzip-komprimiert (ein großer Bericht wird etwa achtmal kleiner); es ist nichts einzustellen.

Upgrades

Image-Tags auf die neue Version zeigen lassen, dann docker compose pull && docker compose up -d. Ausstehende Migrationen laufen der Reihe nach, einzeln, egal wie viele Versionen übersprungen wurden - eine 1.0.0-Installation auf dem Weg zu 1.0.12 wendet beim ersten Start alle zwölf an, unter einer Datenbanksperre, die parallele Replikate serialisiert. Vor dem Upgrade ein Datenbank-Backup ziehen; Migrationen kennen nur vorwärts.

Zuerst die Lizenz prüfen. Das neue Image kann sagen, ob es die Lizenz dieser Installation akzeptiert, bevor es die laufende Version ersetzt. Die Prüfung liest die Datenbank, ändert nichts, und die aktuelle Version läuft weiter:

APPARCH_API_IMAGE=hub.apparch.io/apparch/api:<neue-version> docker compose run --rm --no-deps api --check-license

Sie endet mit Result: safe to upgrade. (Exit-Code 0) oder Result: do not upgrade yet. (Exit-Code 1) und nennt, was fehlt: Eine Online-Installation braucht gesetzte Installations-ID und -Schlüssel und erreichbares AppArch; eine Air-Gapped-Installation eine an ihren Installationscode gebundene Lizenzdatei unter license/apparch.lic. Erst nach bestandener Prüfung upgraden.