> ## 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.
# Architecture
> Comment l’opérateur Kubernetes Vantage, la ressource personnalisée Vantage et ArgoCD fonctionnent ensemble pour installer, configurer et mettre à jour Vantage 3.0 auto-hébergé.
Vantage 3.0 auto-hébergé s’articule autour de trois composants : un opérateur Kubernetes, une ressource personnalisée unique exposée à l’utilisateur (`Vantage`) et ArgoCD. Vous appliquez un objet `Vantage` qui décrit l’installation souhaitée ; l’opérateur réconcilie automatiquement l’état de l’installation avec la ressource, en déléguant à ArgoCD la synchronisation de chaque composant. Cette page présente ces différents éléments d’un point de vue conceptuel. Pour plus de détails au niveau des champs, consultez la [référence API](/fr/vantage/self-hosted/v3.0/api-reference).
## Pourquoi cette approche
Vantage 2.7 auto-hébergé s’appuyait sur des playbooks Ansible fournis par ABBYY et des scripts Azure CLI qui installaient à la fois l’application et l’infrastructure associée en une seule fois. Ce modèle n’est pas pris en charge dans la version 3.0. L’opérateur 3.0 sépare les responsabilités :
* **Infrastructure** : provisionnée par vos soins, hors du périmètre de l’opérateur. ABBYY ne fournit pas d’automatisation du provisionnement pour la version 3.0.
* **Application** : décrite de manière déclarative dans la ressource `Vantage`. L’opérateur gère la résolution des dépendances pour les composants Vantage Core, la migration des artefacts et la réconciliation via ArgoCD.
Les logiciels tiers sur lesquels Vantage s’appuie, comme ArgoCD, votre maillage de services et votre contrôleur d’ingress, votre intégration des secrets et votre stack de monitoring, ne relèvent d’aucun de ces deux périmètres : vous devez les installer vous-même avant d’installer Vantage.
Résultat : les mises à niveau s’effectuent en installant les nouvelles versions correspondantes des charts Helm `vantage-operator` et `vantage-selfhosted`.
## La ressource personnalisée `Vantage`
La CRD est enregistrée sous `vantage.abbyy.com/v1alpha1`. Une ressource minimale se présente ainsi (à titre d’illustration ; voir la [référence API](/fr/vantage/self-hosted/v3.0/api-reference) pour la spécification complète) :
```yaml theme={null}
apiVersion: vantage.abbyy.com/v1alpha1
kind: Vantage
metadata:
name: vantage
namespace: vantage
spec:
dnsRecord: vantage.example.com
mailFrom: noreply@example.com
platformAdminEmail: admin@example.com
vantageVersion: "3.0.x"
secrets:
azure:
keyVaultName: mykeyvault
tenantId: 00000000-...
clientId: 00000000-... # ID client de l'UAMI avec accès en lecture au Key Vault
identityMode: workloadIdentity # workloadIdentity (default) | podIdentity | vmManagedIdentity
smtp:
host: smtp.example.com
port: 587
workloads:
configMap: vantage-workloads
metadataTemplateKey: metadata
secretsKey: secrets
workloadsKey: workloads
```
`spec.secrets` est obligatoire, et un seul fournisseur (`azure` ou `kubernetes`) doit être spécifié. `spec.smtp` est facultatif ; omettez-le pour utiliser le fournisseur de messagerie SendGrid par défaut (fournissez une `sendgridApiKey` via votre fournisseur de secrets). Voir [Secrets and Key Vault](/fr/vantage/self-hosted/v3.0/secrets-and-keyvault) pour connaître les fournisseurs pris en charge.
En pratique, vous définissez la plupart de ces valeurs via le chart Helm `vantage-selfhosted`. Voir [Azure](/fr/vantage/self-hosted/v3.0/providers/azure) ou [Kubernetes autogéré](/fr/vantage/self-hosted/v3.0/providers/self-managed).
## Concepts clés
### ConfigMap des charges de travail
`spec.workloads` indique à l’opérateur une `ConfigMap` contenant le manifeste des charts et des images qui composent une version de Vantage. L’opérateur lit ce manifeste, effectue la migration OCI pour copier les artefacts dans votre registre, puis génère des manifestes ArgoCD `Application` pour chaque composant. La ConfigMap est générée et publiée par ABBYY pour chaque version de Vantage.
### Secrets et certificats
L’opérateur ne stocke pas directement les secrets. Deux fournisseurs de secrets sont pris en charge (Azure Key Vault via le Secrets Store CSI driver, et des ressources Kubernetes `Secret` préexistantes), et un seul est configuré pour chaque installation. Voir [Secrets and Key Vault](/fr/vantage/self-hosted/v3.0/secrets-and-keyvault) pour connaître les fournisseurs pris en charge, les modes d’identité et l’inventaire complet des alias.
### Migration OCI
`spec.ociMigration` déclare un job ponctuel qui copie des artefacts depuis un ou plusieurs registres sources configurés vers votre registre de destination avant l’installation. Une fois la migration terminée, tous les téléchargements ultérieurs de composants se font depuis votre propre registre. ArgoCD récupère les charts des composants depuis ce registre via une connexion au dépôt que vous configurez vous-même. L’authentification du registre de destination prend en charge l’absence d’authentification, l’authentification basique ou Azure Workload Identity avec Azure RBAC. Les charges de travail doivent également disposer d’un accès de pull via des Secrets Kubernetes d’extraction d’images ou, sur Azure, de l’autorisation `AcrPull` accordée à l’identité managée AKS. Voir [Accès de pull d’images Azure](/fr/vantage/self-hosted/v3.0/providers/azure#image-pull-access) ou [accès au registre autogéré](/fr/vantage/self-hosted/v3.0/providers/self-managed#configure-registry-access).
### Installation des Skills
Les Skills sont installés par un job Kubernetes distinct dans le namespace d’installation, et non par l’une des applications ArgoCD générées par l’opérateur. ArgoCD n’affiche donc pas la progression de l’installation des Skills. La ressource `Vantage` peut indiquer l’état `Ready` alors que le job est toujours en cours d’exécution, et Vantage reste utilisable entre-temps. Les commandes de surveillance figurent dans [Cycle de vie](/fr/vantage/self-hosted/v3.0/lifecycle#skill-installation-runs-separately).
## Contrat du Runtime
Le contrat du Runtime de l’opérateur (la façon dont il traite la ressource `Vantage`, les conditions qu’il renvoie et la manière de forcer une nouvelle tentative) est documenté séparément de cette présentation conceptuelle. Voir [cycle de vie](/fr/vantage/self-hosted/v3.0/lifecycle).
## Pour la suite
Référence détaillée de chaque propriété de spec et de status.
Phases de réconciliation, conditions de status et forçage d’une nouvelle tentative.
Référence de chaque valeur Helm acceptée par l’opérateur et les charts Vantage.
Diagnostic des problèmes courants liés à l’opérateur, à ArgoCD, aux secrets, à la base de données, à l’ingress et au maillage.