> ## Documentation Index > Fetch the complete documentation index at: https://docs.abbyy.com/llms.txt > Use this file to discover all available pages before exploring further. # Azure > Bereitstellung von Vantage 3.0 selbstgehostet auf Azure Kubernetes Service mit Azure Key Vault, dem Secrets Store CSI driver und Azure Workload Identity. 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](/de/vantage/self-hosted/v3.0/secrets-and-keyvault#kubernetes-secrets-provider) und [benutzerdefinierten Speicher](/de/vantage/self-hosted/v3.0/api-reference#vantagespecstoragecustom).
## Voraussetzungen
Bevor Sie diese Seite durcharbeiten, stellen Sie sicher, dass die [Plattformvoraussetzungen](/de/vantage/self-hosted/v3.0/prerequisites) 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](#database-connection-strings). | | 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](#image-pull-access). | | 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](#storage-account-connection-strings). | | 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](https://azure.github.io/secrets-store-csi-driver-provider-azure) | 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](/de/vantage/self-hosted/v3.0/secrets-and-keyvault#service-accounts-and-identity-scope). | | AKS KEDA Add-on (optional, empfohlen) | `2.17.3-5` | Erforderlich für die Unterstützung der automatischen Skalierung mit [KEDA](https://keda.sh/). | 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](#connect-argocd-to-your-oci-registry) und [Image-Pull-Zugriff](#image-pull-access).
## 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](#install-variables)) muss **Lesezugriff** auf jedes unten aufgeführte Secret haben. Das vollständige Alias-Verzeichnis (Platform, Storage, Databases, OAuth) ist unter [Secrets und Key Vault](/de/vantage/self-hosted/v3.0/secrets-and-keyvault#secret-aliases) 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](/de/vantage/self-hosted/v3.0/secrets-and-keyvault).
## 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](https://argo-cd.readthedocs.io/en/stable/user-guide/private-repositories/) in der ArgoCD-Dokumentation. Unter Azure ist die empfohlene Methode [Azure Workload Identity](https://argo-cd.readthedocs.io/en/stable/user-guide/private-repositories/#azure-container-registryazure-repos-using-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`](https://learn.microsoft.com/azure/aks/cluster-container-registry-integration) 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](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/)) 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](#step-1-install-the-vantage-operator). | | 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](#step-2-install-vantage). | | Vantage-Workloads | Fügen Sie das Pull-Secret zu den `imagePullSecrets` des ServiceAccount hinzu, der in `vantage.serviceAccountName` angegeben ist. Siehe [Schritt 2](#step-2-install-vantage). | 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: ```bash theme={null} 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](#image-pull-access)), fügen Sie Folgendes an: ```bash theme={null} --set "manager.imagePullSecrets[0].name=my-pull-secret" ``` Weitere Werte, die Sie angeben können, finden Sie in den [Werten des `vantage-operator`-Charts](/de/vantage/self-hosted/v3.0/helm-chart#vantage-operator).
## 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: ```bash theme={null} 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](#image-pull-access)), fügen Sie die Pull-Konfiguration für die Vantage-Workloads und den Migrationsjob hinzu: ```bash theme={null} --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: ```bash theme={null} --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: ```bash theme={null} --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](/de/vantage/self-hosted/v3.0/secrets-and-keyvault#identity-modes). Die obigen `--set`-Flags entsprechen direkt den Feldern in der [Vantage Custom-Resource](/de/vantage/self-hosted/v3.0/api-reference) und im [`vantage-selfhosted`-Chart](/de/vantage/self-hosted/v3.0/helm-chart).
## Schritt 3: Installationsfortschritt überwachen
Warten Sie, bis die Vantage-Custom-Resource den Status `Ready` meldet: ```bash theme={null} 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: ```bash theme={null} 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: ```bash theme={null} 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](#step-3-monitor-installation-progress).
## 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](/de/vantage/self-hosted/v3.0/monitoring/azure-managed). * **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](/de/vantage/self-hosted/v3.0/secrets-and-keyvault#identity-modes).
## Wie es weitergeht
So funktioniert das Operator-, ArgoCD- und CRD-Muster. Azure Monitor Workspace + Managed Grafana mit einem In-mesh Prometheus. Manueller Upgrade-Workflow für den Wechsel zwischen Vantage 3.0-Versionen. Häufige Probleme mit dem Operator, ArgoCD, Istio und Key Vault.