Azure - ABBYY Documentation

Azure ist der validierte Provider für Vantage 3.0 selbstgehostet: Azure Kubernetes Service (AKS) mit Azure Key Vault. Diese Seite bietet die vollständige End-to-End-Anleitung für die Installation auf Azure: Voraussetzungen, Einrichtung der Identität, die Helm-Installationsbefehle und Betriebshinweise. Einzelne Komponenten bieten Kubernetes-native Alternativen, sofern die CRD sie unterstützt, etwa den Kubernetes-Secrets-Provider und benutzerdefinierten Speicher.

Voraussetzungen

Bevor Sie diese Seite durcharbeiten, stellen Sie sicher, dass die Plattformvoraussetzungen erfüllt sind: Kubernetes, ArgoCD, Helm sowie die zugrunde liegenden SQL-/Redis-/SMTP-/OCI-Registry-/Objektspeicher-Services. Die unten aufgeführten Azure-spezifischen Elemente kommen zusätzlich hinzu.

Komponente	Getestete Version	Hinweise
Azure Kubernetes Service (AKS)	1.33.6	CRD und Operator-Chart werden im Cluster installiert.
Azure SQL	12.0.2000.8 (compatibility level 170, General Purpose Serverless Gen 5)	Dient als Backend für die Vantage-Datenbanken, eine pro Alias der Verbindungszeichenfolge (derzeit 23). Siehe Datenbank-Verbindungszeichenfolge.
Azure Managed Redis	7.4 (EnterpriseCluster)	Für Cache, Sperren und Client-Cache-Nutzung.
Azure Container Registry	n/a	Ziel-Registry für die OCI-Migration; Ihre Workloads beziehen Vantage-Images von dort. Authentifizierung für die Migration: keine, Basic Auth oder Workload Identity + Azure RBAC. Informationen zum Image-Abruf finden Sie unter Image-Pull-Zugriff.
Azure StorageV2	general purpose v2	Dient als Backend für die fünf Verbindungszeichenfolgen des Speicherkontos (archive, temporary (old), temporary, permanent, standard). Siehe Verbindungszeichenfolge für Speicherkonto.
Azure Key Vault	n/a	Enthält alle Vantage-Secrets (einschließlich der PEM-kodierten TLS-Materialien), wenn der Azure-Secrets-Provider verwendet wird. Die in `identityMode` ausgewählte Identity muss Lesezugriff haben.
AKS Istio Add-on	`asm-1-28`	Ein externes Ingress-Gateway muss bereitgestellt werden.
Azure Key Vault Provider for Secrets Store CSI Driver	1.7.2 (Helm chart 1.7.2)	Das CSI-Provider-Plugin, das Secrets beim Pod-Start abruft.
Azure Workload Identity	n/a	Föderieren Sie das ServiceAccount jedes Vantage-Charts mit einer benutzerseitig zugewiesenen Managed Identity mit Lesezugriff auf die Key-Vault-Aliasse dieses Charts. Der Operator erstellt oder annotiert keine ServiceAccounts. Wird auch vom OCI-Migrationsjob (Workload Identity + Azure RBAC) und von In-mesh Prometheus (Azure Monitor) verwendet. Siehe Secrets and Key Vault.
AKS KEDA Add-on (optional, empfohlen)	`2.17.3-5`	Erforderlich für die Unterstützung der automatischen Skalierung mit KEDA.

Vor der Installation müssen noch zwei weitere Einrichtungsschritte durchgeführt werden. Beide werden weiter unten behandelt, nach den Installationsvariablen, auf die sie sich beziehen: Connect ArgoCD to your OCI registry und Image-Pull-Zugriff.

Azure Key Vault-Secrets

Der Vantage operator referenziert Secrets über Aliasse. Die einfachste Konfiguration in Azure besteht darin, Key Vault-Secrets zu erstellen, deren Namen den einzelnen Aliasen entsprechen. Wenn Ihr Bereitstellungsprozess andere Namen verwendet, geben Sie unter vantage.secrets.azure ein objects-Mapping an, um diese Zuordnung anzupassen. Die über identityMode ausgewählte Identität (siehe Installationsvariablen) muss Lesezugriff auf jedes unten aufgeführte Secret haben. Das vollständige Alias-Verzeichnis (Platform, Storage, Databases, OAuth) ist unter Secrets und Key Vault dokumentiert. Die folgende Liste umfasst dieselben Einträge und ist hier für die Azure-Installation nochmals aufgeführt.

Plattform

Alias	Beschreibung
`sendgridApiKey`	API-Schlüssel für SendGrid. Erforderlich, sofern Sie nicht `spec.smtp` konfigurieren.
`redisConnectionString`	Verbindungszeichenfolge für Redis.
`redisCacheConnectionString`	Verbindungszeichenfolge für Redis-Cache / Sperren / Client-Cache. `redisConnectionString` kann wiederverwendet werden.
`secretStorageUserKeyVaultUri`	URI des Azure Key Vault für die Speicherung von Secrets. Kann derselbe Key Vault oder ein separater sein (ein separater wird empfohlen).

Verbindungszeichenfolgen für Speicherkonten

Alias	Beschreibung
`storageArchiveConnectionString`	Verbindungszeichenfolge des Speicherkontos („Archiv“).
`storageLegacyTemporaryConnectionString`	Verbindungszeichenfolge des Speicherkontos („temporär (alt)“).
`storageTemporaryConnectionString`	Verbindungszeichenfolge des Speicherkontos („temporär“).
`storagePermanentConnectionString`	Verbindungszeichenfolge des Speicherkontos („dauerhaft“).
`storageStandardConnectionString`	Verbindungszeichenfolge des Speicherkontos („Standard“).

Welche Bedeutung die einzelnen Speichertypen haben, finden Sie in der Vantage-Basisdokumentation.

Datenbank-Verbindungszeichenfolgen

Ein Alias pro eindeutiger Datenbank. Die unten aufgeführten Datenbanknamen sind nur Beispiele; verwenden Sie die Namen, die Ihr Bereitstellungsprozess erzeugt, solange die Verbindungszeichenfolge auf die richtige Datenbank verweist.

Alias	Datenbank
`apiRegistryDatabaseConnectionString`	`apiregistry`
`auth2DatabaseConnectionString`	`auth`
`authIdentityDatabaseConnectionString`	`auth-identity`
`cronServiceDatabaseConnectionString`	`cron`
`documentSetStorageDatabaseConnectionString`	`documentset`
`mailDatabaseConnectionString`	`mail`
`securityAuditDatabaseConnectionString`	`security-audit`
`storageDatabaseConnectionString`	`storage`
`workflowDatabaseConnectionString`	`workflows`
`catalogStorageDatabaseConnectionString`	`catalogstorage`
`folderImportDatabaseConnectionString`	`folderimport`
`interactiveJobsDatabaseConnectionString`	`interactive-jobs`
`mailImportDatabaseConnectionString`	`mailimport`
`permissionsDatabaseConnectionString`	`permissions`
`reportingDatabaseConnectionString`	`reporting` (muss Columnstore Indexing unterstützen).
`secretStorageDatabaseConnectionString`	`secretstorage`
`skillInfoDatabaseConnectionString`	`skillinfo`
`skillMonitorDatabaseConnectionString`	`skillmonitor`
`subscriptionDatabaseConnectionString`	`subscriptions`
`tokenManagementDatabaseConnectionString`	`tokenmanagement`
`transactionsDatabaseConnectionString`	`transactions`
`urlShortenerDatabaseConnectionString`	`urlshortener`
`workspaceDatabaseConnectionString`	`workspace`

OAuth

Alias	Beschreibung
`oAuthGoogleClientId`	OAuth Google-Client-ID.
`oAuthGoogleClientSecret`	OAuth Google-Client-Secret.
`oAuthMicrosoftClientId`	OAuth Microsoft-Client-ID.
`oAuthMicrosoftClientSecret`	OAuth Microsoft-Client-Secret.

Azure Key Vault TLS-Secrets

Die folgenden TLS-Materialien im PEM-Format müssen als Secrets im Azure Key Vault gespeichert werden (nicht als Key Vault-Zertifikatobjekte). Die über identityMode ausgewählte Identität muss Lesezugriff auf alle vier Secret-Aliasse haben.

Alias	Beschreibung
`authSigningTlsCrt`	PEM-kodiertes Zertifikat für die Auth-Signierung.
`authSigningTlsKey`	PEM-kodierter privater Schlüssel für die Auth-Signierung.
`authDeactivatedTlsCrt`	PEM-kodiertes Zertifikat für deaktivierte Auth-Token.
`authDeactivatedTlsKey`	PEM-kodierter privater Schlüssel für deaktivierte Auth-Token.

Am einfachsten erstellen Sie zwei selbstsignierte Zertifikate im Key Vault mit den Namen auth-signing und auth-deactivated (Common Name = Wert Ihres Vantage-dnsRecord) und anschließend vier Key Vault-Secrets, deren Namen den obigen Aliasen entsprechen. Wenn Sie andere Namen verwenden, geben Sie in Ihrer Secrets-Konfiguration ein objects-Mapping an. Eine konzeptionelle Beschreibung, wie der Secrets Store CSI driver diese in Pods verfügbar macht, finden Sie unter Secrets und Key Vault.

Installationsvariablen

Halten Sie diese Werte bereit, bevor Sie die Installationsbefehle ausführen:

Variable	Beschreibung
`$operator_namespace`	Namespace, in dem der Vantage Operator installiert wird.
`$install_namespace`	Namespace, in dem Vantage installiert wird. Beliebiger Namespace; häufig `app`.
`$operator_version`	Version des `vantage-operator` Helm-Charts.
`$selfhosted_version`	Version des `vantage-selfhosted` Helm-Charts.
`$charts_uri`	OCI-URI, unter der das Helm-Chart des Vantage Operators gehostet wird.
`$chart_uri`	OCI-URI, unter der das `vantage-selfhosted` Helm-Chart gehostet wird.
`$release_name`	Helm-Release-Name für `vantage-selfhosted`.
`$your_vantage_hostname`	DNS-Hostname, unter dem Vantage erreichbar sein wird.
`$ingress_tls_secret_name`	Name des `kubernetes.io/tls`-Secrets im Namespace des Ingress-Gateways.
`$key_vault_name`, `$tenant_id`, `$client_id`	Azure-Key-Vault-Name, tenant ID und client ID der UAMI mit Lesezugriff auf den Key Vault.
`$your_mailfrom`	Absenderadresse für ausgehende E-Mails.
`$smtp_host`, `$smtp_port`, `$smtp_login`, `$smtp_password`	SMTP-Einstellungen für ausgehende E-Mails. Optional: weglassen, wenn Sie SendGrid verwenden (Standard; geben Sie `sendgridApiKey` über Ihren Secrets-Provider an).
`$your_platformadmin_email`	E-Mail-Adresse des anfänglichen Plattformadministrators.
`$your_oci_host`	OCI-Registry-Host, in den Vantage-Artefakte migriert werden.
`$abbyy_oci_source_host`, `$abbyy_oci_source_repository`	Quell-Registry und Repository für von ABBYY bereitgestellte Artefakte. Die dokumentierten Werte sind `abbyy.jfrog.io` und `abbyy-docker`.

ArgoCD mit Ihrer OCI-Registry verbinden

ArgoCD ruft Vantage-Komponenten-Charts aus Ihrer OCI-Registry ab. Richten Sie daher in ArgoCD eine Verbindung ein, die Zugriff auf diese Registry gewährt. ArgoCD ist Software von Drittanbietern, die Sie selbst installieren und warten. Daher müssen Sie diese Verbindung selbst erstellen, indem Sie die Registry als ArgoCD-Repository registrieren. Siehe Private Repositories in der ArgoCD-Dokumentation. Unter Azure ist die empfohlene Methode Azure Workload Identity, wie in der ArgoCD-Dokumentation beschrieben.

Image-Pull-Zugriff

Ihre Workloads müssen Images aus Ihrer Registry abrufen. Konfigurieren Sie den Zugriff dafür auf eine von zwei Arten. Die Namen my-pull-secret und my-service-account unten sind Beispielnamen; ersetzen Sie sie durch Ihre eigenen. Option 1 (Azure): Weisen Sie der von AKS verwalteten Identität AcrPull zu. Azure-Bereitstellungen lassen sich vereinfachen, indem Sie der von AKS verwalteten Identität (der kubelet-Identität) für Ihre Azure Container Registry AcrPull zuweisen, statt Pull-Secrets zu konfigurieren. In diesem Fall können Sie die Pull-Secret---set-Flags in Schritt 1 und 2 weglassen. Option 2: Kubernetes-Image-Pull-Secrets. Erstellen Sie ein Registry-Pull-Secret (Kubernetes-Dokumentation) und binden Sie es dann pro Komponente ein:

Komponente	Konfiguration
Operator-Pods	`--set "manager.imagePullSecrets[0].name=my-pull-secret"` im Chart `vantage-operator`. Siehe Schritt 1.
OCI-Migrationsjob	Führen Sie den Job entweder mit einem ServiceAccount aus, dem das Pull-Secret zugeordnet ist (`vantage.ociMigration.serviceAccountName=my-service-account`), oder referenzieren Sie das Secret im source-Eintrag (`vantage.ociMigration.sources[0].credentialsRef.name=my-pull-secret`). Siehe Schritt 2.
Vantage-Workloads	Fügen Sie das Pull-Secret zu den `imagePullSecrets` des ServiceAccount hinzu, der in `vantage.serviceAccountName` angegeben ist. Siehe Schritt 2.

Sie erstellen und verwalten die Rollenzuweisungen, ServiceAccounts und Pull-Secrets selbst.

Schritt 1: Installieren Sie den Vantage Operator

Wählen Sie einen Namespace für den Operator aus (er muss nicht app sein) und installieren Sie das Chart:

helm upgrade --install vantage-operator $charts_uri/vantage-operator \
  --version $operator_version \
  --namespace $operator_namespace \
  --wait

Wenn Sie Pull-Secrets anstelle von AcrPull verwenden (siehe Image-Pull-Zugriff), fügen Sie Folgendes an:

  --set "manager.imagePullSecrets[0].name=my-pull-secret"

Weitere Werte, die Sie angeben können, finden Sie in den Werten des vantage-operator-Charts.

Schritt 2: Vantage installieren

Installieren Sie das Chart vantage-selfhosted in Ihrem ausgewählten Namespace und geben Sie dabei die Secrets-Konfiguration sowie die Einstellungen für die OCI-Migration an:

helm upgrade --install $release_name $chart_uri/vantage-selfhosted \
  --version $selfhosted_version \
  --namespace $install_namespace \
  --set "operator.namespace=$operator_namespace" \
  --set "ingress.tls.secretName=$ingress_tls_secret_name" \
  --set "vantage.dnsRecord=$your_vantage_hostname" \
  --set "vantage.mailFrom=$your_mailfrom" \
  --set "vantage.platformAdminEmail=$your_platformadmin_email" \
  --set "vantage.secrets.azure.keyVaultName=$key_vault_name" \
  --set "vantage.secrets.azure.tenantId=$tenant_id" \
  --set "vantage.secrets.azure.clientId=$client_id" \
  --set "vantage.ociMigration.enabled=true" \
  --set "vantage.ociMigration.sources[0].host=$abbyy_oci_source_host" \
  --set "vantage.ociMigration.sources[0].repository=$abbyy_oci_source_repository" \
  --set "vantage.ociMigration.destination.host=$your_oci_host" \
  --wait

Wenn Sie statt AcrPull Pull-Secrets verwenden (siehe Image-Pull-Zugriff), fügen Sie die Pull-Konfiguration für die Vantage-Workloads und den Migrationsjob hinzu:

  --set "vantage.serviceAccountName=my-service-account" \
  --set "vantage.ociMigration.serviceAccountName=my-service-account"

my-service-account ist ein ServiceAccount, den Sie in $install_namespace erstellen und bei dem Ihr Registry-Pull-Secret unter imagePullSecrets aufgeführt ist. Alternativ können Sie für den Migration-Job stattdessen beim Source-Eintrag auf das Pull-Secret verweisen:

  --set "vantage.ociMigration.sources[0].credentialsRef.name=my-pull-secret"

SendGrid ist der Standard-Mail-Provider: Hinterlegen Sie einen sendgridApiKey in Ihrem Key Vault; eine weitere Mail-Konfiguration ist nicht erforderlich. Wenn Sie stattdessen SMTP verwenden möchten, fügen Sie Folgendes an:

  --set "vantage.smtp.host=$smtp_host" \
  --set "vantage.smtp.port=$smtp_port" \
  --set "vantage.smtp.login=$smtp_login" \\      # optional
  --set "vantage.smtp.password=$smtp_password"  # optional

vantage.secrets.azure.identityMode ist standardmäßig auf workloadIdentity festgelegt. Informationen zur Verwendung des veralteten Modells pod-identity oder VM-managed-identity finden Sie unter Secrets und Key Vault.

Die obigen --set-Flags entsprechen direkt den Feldern in der Vantage Custom-Resource und im vantage-selfhosted-Chart.

Schritt 3: Installationsfortschritt überwachen

Warten Sie, bis die Vantage-Custom-Resource den Status Ready meldet:

kubectl -n $install_namespace wait \
  --for=condition=Ready vantages.vantage.abbyy.com/$release_name \
  --timeout=30m

Dies ist das grobgranulare Signal; es zeigt an, dass die Installation von Vantage Core abgeschlossen ist. Die Skill-Installation wird in einem separaten Job nachverfolgt und läuft möglicherweise noch (siehe unten). Für einen detaillierteren Einblick in die Artefaktmigration überwachen Sie den OCI-Migrationsjob separat:

kubectl -n $install_namespace wait --for=create job/$release_name-oci-migration --timeout=2m
kubectl -n $install_namespace wait --for=condition=Complete job/$release_name-oci-migration --timeout=20m

Sobald die Migration abgeschlossen ist, bietet ArgoCD (API oder UI) den besten Einblick in den Synchronisierungsstatus der einzelnen Charts. Die einzige Ausnahme ist die Skill-Installation: Skills werden über einen separaten Kubernetes-Job installiert, der in ArgoCD nicht angezeigt wird. Sie können Vantage verwenden, während die Skill-Installation noch läuft. Überwachen Sie den Job direkt:

kubectl -n $install_namespace wait --for=create job/$install_namespace-skill-installer-job
kubectl -n $install_namespace wait --for=condition=Complete job/$install_namespace-skill-installer-job

Schritt 4: Auf Vantage zugreifen

Sobald die Ressource Ready anzeigt, ist Ihre Vantage-Instanz unter folgender Adresse verfügbar:

https://$your_vantage_hostname

Der Skill-Installationsauftrag wird zu diesem Zeitpunkt möglicherweise noch ausgeführt. Sie können sich anmelden und Vantage verwenden, während die Skill-Installation noch läuft. Überwachen Sie den Auftrag mit den Befehlen in Schritt 3.

Azure-spezifische Betriebshinweise

Überwachung: Auf AKS ist die empfohlene Konfiguration Azure Monitor Workspace + Azure Managed Grafana mit einem In-mesh Prometheus, der Vantage über Istio mTLS abruft. Die vollständige Einrichtung finden Sie unter Azure Managed Monitoring.
Workload Identity: Der Standard-Authentifizierungsmodus für den Secrets Store CSI driver. Außerdem ein unterstütztes Authentifizierungsszenario für den OCI-Migrationsjob (Workload Identity + Azure RBAC) und wird auch vom In-mesh Prometheus verwendet, der per remote-write an Azure Monitor schreibt. Siehe Secrets und Key Vault.

Wie es weitergeht

Architektur

So funktioniert das Operator-, ArgoCD- und CRD-Muster.

Überwachung

Azure Monitor Workspace + Managed Grafana mit einem In-mesh Prometheus.

Upgrade

Manueller Upgrade-Workflow für den Wechsel zwischen Vantage 3.0-Versionen.

Fehlerbehebung

Häufige Probleme mit dem Operator, ArgoCD, Istio und Key Vault.

​Voraussetzungen

​Azure Key Vault-Secrets

​Plattform

​Verbindungszeichenfolgen für Speicherkonten

​Datenbank-Verbindungszeichenfolgen

​OAuth

​Azure Key Vault TLS-Secrets

​Installationsvariablen

​ArgoCD mit Ihrer OCI-Registry verbinden

​Image-Pull-Zugriff

​Schritt 1: Installieren Sie den Vantage Operator

​Schritt 2: Vantage installieren

​Schritt 3: Installationsfortschritt überwachen

​Schritt 4: Auf Vantage zugreifen

​Azure-spezifische Betriebshinweise

​Wie es weitergeht

Architektur

Überwachung

Upgrade

Fehlerbehebung

Voraussetzungen

Azure Key Vault-Secrets

Plattform

Verbindungszeichenfolgen für Speicherkonten

Datenbank-Verbindungszeichenfolgen

OAuth

Azure Key Vault TLS-Secrets

Installationsvariablen

ArgoCD mit Ihrer OCI-Registry verbinden

Image-Pull-Zugriff

Schritt 1: Installieren Sie den Vantage Operator

Schritt 2: Vantage installieren

Schritt 3: Installationsfortschritt überwachen

Schritt 4: Auf Vantage zugreifen

Azure-spezifische Betriebshinweise

Wie es weitergeht