Container-basierte Systeme installieren und migrieren

Als Systemadministrator installieren und/oder migrieren Sie die Automic Automation und andere Komponenten, die erforderlich sind, um Ihr System zum Laufen zu bringen.

Tipp! Dieser Abschnitt enthält Informationen, die für Container-basierte Systeme relevant sind. Informationen über manuell installierte lokale Systeme finden Sie unter Installation der Automation Engine (AE)).

Das Container-basierte Modell verwendet Kubernetes und Helm Charts und kann für Deployments auf selbst-gehosteten Kubernetes-Clustern und verwalteten Kubernetes-Services wie von AWS, Azure und Google Cloud Platform verwendet werden.

Das Automic Automation Kubernetes Edition (AAKE)-Angebot umfasst alle Kern- und Container-spezifischen Komponenten, die bereitgestellten Installationsanpassungen für Automic Automation und Automic Intelligent Remediation sowie einige standardmäßig geladene Action Packs. Sie können das Angebot von https://downloads.automic.com/herunterladen, wo Sie auch den vollständigen Inhalt des Angebotes sehen.

Die ZIP-Datei des Angebots umfasst Folgendes:

Alle Automic Automation-Komponenten
Automic Automation Helm Chart

Enthält die Datei values.yaml, die Sie verwenden können, um das AAKE-Deployment bzw. die Installation anzupassen.
Automic Automation Helm-Plug-in

Wird verwendet, um den Status der AAKE-Installation zu überwachen und eine Helm-Aktualisierung für eine vorhandene AAKE-Installation auszuführen.

Hinweis: Sie können das Automic Automation Helm-Plug-in verwenden, um den Fortschritt einer Installation und/oder einer Aktualisierung zu überwachen. Weitere Informationen finden Sie unter Automic Automation Helm-Plug-in.

Diese Seite beinhaltet Folgendes:

Installationsübersicht

Klicken Sie auf das Bild, um es zu erweitern.

Installieren eines AAKE-Systems

Sie beginnen mit einer neuen, leeren AE-Datenbank, wenn Sie Ihr (v21) AAKE-System von Grund auf neu installieren.

Stellen Sie sicher, dass Sie alle Voraussetzungen erfüllen, bevor Sie mit der Migration beginnen. Weitere Informationen finden Sie unter Vorbereiten der Container-basierten Installation.

Wenn Sie Analytics nicht installieren möchten, stellen Sie sicher, dass Sie die Installation in der Datei values.yaml vor der Installation deaktivieren. Weitere Informationen finden Sie unter .

Installationsschritte

Die folgenden Schritte führen Sie durch die Container-basierte Systeminstallation.

Falls noch nicht erledigt, laden Sie das AAKE-Angebot herunter und erstellen Sie Ihr Pull-Geheimnis. Weitere Informationen finden Sie unter .
Falls noch nicht erledigt, installieren Sie das Automic Automation Helm-Plug-in. Weitere Informationen finden Sie unter .
Passen Sie bei Bedarf die Datei values.yaml aus dem Helm Chart an.
Automic Automation Kubernetes Edition installieren

Beispiel

helm install aake automic-automation-<version>.tgz -f values.yaml
- aake: Name der Helm-Installation. Sie können den Namen Ihrer Helm-Installation frei wählen.
- -f values.yaml: Stellt die zu verwendende Helm Chart-Konfiguration zur Verwendung
Optional können Sie -n <Namespace> verwenden, um einen Namespace zu definieren.
Verwenden Sie das Helm-Plug-in, um den Fortschritt der Installation zu überprüfen:

$ helm automic-automation status

Sobald die Installation abgeschlossen ist, ist der Status bereitgestellt, und die Zielversionen und die aktuellen Versionen sollten mit der gewünschten Version übereinstimmen. Ist dies nicht der Fall, lesen Sie im Abschnitt "Fehlerbehebung" der Datei README.md im Helm Chart nach, siehe Automic Automation Helm-Plug-in.
Optional können Sie die Protokolle des Installationsoperators überprüfen, um den Installationsstatus zu prüfen.

Auf dieAutomic Web Interface zugreifen

Die neue Installation stellt automatisch zwei Automic Automation-Mandanten zur Verfügung: Mandant 0 und Mandant 100. Die jeweiligen Benutzer und Zugangsdaten werden ebenfalls automatisch erstellt. Die Zugangsdaten werden in geheimen Kubernetes-Schlüsseln im Namespace gespeichert, in dem Helm Chart installiert wurde:

client0-user: Geheimer Name für Client 0
client100-user: Geheimer Name für Client 100

Hinweis: Warten Sie, bis Ihre Instanz bereitgestellt ist, bevor Sie die Zugangsdaten abfragen, da diese möglicherweise noch nicht generiert wurden.

Um den Benutzernamen und das Kennwort für die Konten zu erhalten, die erstellt werden, führen Sie den folgenden Aufruf aus:

echo "Client 0 User: $(kubectl get secrets client0-user -o jsonpath={$.data.user} | base64 -d)"
echo "Client 0 Password: $(kubectl get secrets client0-user -o jsonpath={$.data.password} | base64 -d)"
echo "Client 100 User: $(kubectl get secrets client100-user -o jsonpath={$.data.user} | base64 -d)"
echo "Client 100 Password: $(kubectl get secrets client100-user -o jsonpath={$.data.password} | base64 -d)"

Migration auf ein AAKE-System

Mithilfe einer Sicherung Ihrer vorhandenen Datenbank (12.3) können Sie Ihr vorhandenes AAKE-System vor Ort auf eine höhere Version migrieren. Auf diese Weise können Sie Ihre aktuelle Systemkonfiguration wie Mandanten, Benutzer, Gruppen, Objektdefinitionen usw. behalten. Das heißt, Sie müssen nicht von Grund auf neu beginnen und eine neue Installation durchführen.

Wichtig! Ab Version 21.0 verwendet auch der Proxy TLS/SSL für die Kommunikation mit der Automation Engine. Wenn Sie den Proxy verwenden möchten, um Ihre Agenten zu verbinden, und Sie ihn bereits verwenden, führen Sie noch kein Upgrade durch.

Checkliste vor der Migration

Bevor Sie mit der Migration beginnen, sollten Sie die folgenden Punkte durchgehen und sicherstellen, dass alle Voraussetzungen erfüllt sind:

Für die Automation Engine unterstützt Automic Automation Kubernetes Edition nur PostgreSQL- und Oracle-Datenbanken.

Stellen Sie sicher, dass Sie die Datenbankverbindung zur vorhandenen AE-Datenbank konfiguriert haben.

Beispiel AE DB - PostgreSQL

$ kubectl create secret generic ae-db-postgres \
--from-literal=host=external-postgres.location \
--from-literal=vendor=postgres \
--from-literal=port='1521' \
--from-literal=user=username \
--from-literal=db=POSTGRESDB.localdomain \
--from-literal=password=S3cret \
--from-literal=data-tablespace-name=ae_data \
--from-literal=index-tablespace-name=ae_index \
--from-literal=additional-parameters="connect_timeout=10 client_encoding=LATIN9"

Stellen Sie sicher, dass Sie den vorhandenen Systemnamen für die Automation Engine und die Automic Web Interface unter Verwendung der jeweiligen Umgebungsvariablen in der Datei values.yaml festgelegt haben.
- AUTOMIC_GLOBAL_SYSTEM für die Automation Engine
- AUTOMIC_SYSTEM_NAME für die Automic Web Interface
  
  Weitere Informationen finden Sie unter .
Erstellen Sie ein Kubernetes-Geheimnis, das die Administrator-Anmeldeinformationen für den vorhandenen Mandanten 0 enthält. Das Geheimnis muss in dem Namespace erstellt werden, in dem das AAKE-System installiert ist.

Beispiel
```
kubectl create secret generic client0-user \
  --from-literal=client='0' \
  --from-literal=user='ADMIN' \
  --from-literal=department='ADMIN' \
  --from-literal=password='UC4'
```
Setzen Sie den Parameter operator.migrate in der Datei values.yaml auf true.

Stellen Sie außerdem sicher, dass Sie alle anderen Voraussetzungen erfüllen, bevor Sie mit der Migration beginnen. Weitere Informationen finden Sie unter Vorbereiten der Container-basierten Installation.

Analytics im Migrationskontext

Bei der Migration auf ein AAKE-System ist Analytics nie im AAKE-Cluster installiert. Wenn Sie Analytics in der Version installiert haben, die Sie aktualisieren möchten, bleibt es lokal.

Informationen zum Konfigurieren der Verbindung zwischen Ihrer lokalen Analytics-Installation und der Automic Automation Kubernetes Edition finden Sie unter Konfigurieren der Verbindung zwischen Analytics lokal und AAKE.

Migrationsszenarien

Aus Netzwerksicht verwenden Sie beim Migrieren auf Automic Automation Kubernetes Edition eine völlig neue Instanz, die sehr wahrscheinlich in einer anderen Umgebung ausgeführt wird. Dies ist besonders relevant, wenn die Agenten von Ihrem aktuellen System getrennt wurden und sie erneut mit Ihrer neuen AAKE-Instanz verbunden werden, insbesondere dann, wenn Ihr System über eine große Anzahl an Agenten verfügt.

Hinweis: Beachten Sie, dass Ihre Agenten zu diesem Zeitpunkt noch nicht aktualisiert wurden und noch einen Kommunikationsprozess (CP) benötigen, zu dem sie eine Verbindung herstellen können.

Es gibt drei mögliche Migrationsszenarien:

Anpassen der INI-Dateien Ihrer Agenten

In diesem Fall ändern Sie die INI-Datei Ihrer Agenten, um eine Verbindung zum Cluster herzustellen. Um den CP im Cluster zu erreichen, müssen Sie die Verbindung über einen TCP Load Balancer herstellen.
Verwendung des Proxy, um Ihre Agenten zu verbinden

Wenn Sie den Proxy verwenden, müssen Sie nur die Agenten-Verbindung in der INI-Datei des Proxy anpassen. Damit vermeiden Sie, die INI-Datei jedes Agenten ändern zu müssen. Der Proxy muss auch die Verbindung zum CP im Cluster über einen TCP Load Balancer herstellen.

Wichtig! Ab Version 21.0 verwendet auch der Proxy TLS/SSL für die Kommunikation mit der Automation Engine. Wenn Sie den Proxy verwenden möchten, um Ihre Agenten zu verbinden, und Sie ihn bereits verwenden, führen Sie noch kein Upgrade durch. Wenn Sie den Proxy noch nicht verwenden, ihn aber in diesem Szenario verwenden möchten, stellen Sie sicher, dass Sie v12.3 des Proxy installieren, nicht v21.0.
Verwendung des TLS Gateway als CP-Port, um Ihre Agenten zu verbinden

In diesem Fall konfigurieren Sie das TLS Gateway, um einen CP-Port für Ihre Agenten zur Verfügung zu stellen. Sie müssen Ihre Agenten so konfigurieren, dass eine Verbindung zu, TLS Gateway hergestellt wird, der dann über einen HTTPS Load Balancer eine TLS/SSL-Verbindung zum neuen Java-Kommunikationsprozess (JCP) im Cluster herstellt.

Mehr Informationen:

Migrationsschritte

Dieser Abschnitt führt Sie durch den Prozess der Migration auf ein Container-basiertes System in allen drei Migrationsszenarien.

Migration durch Anpassung der INI-Dateien des Agenten

Wichtig!

Da eine neue AAKE-Instanz standardmäßig keinen Kommunikationsprozess (CP) benötigt, müssen Sie Ihr AAKE-Deployment so skalieren, dass ein Kommunikationsprozess (CP) enthalten ist. Weitere Informationen finden Sie unter Deployments skalieren.
Sie müssen einen TCP-Load Balancer haben, um die Verbindung zwischen dem Agenten und dem CP im Cluster herzustellen. Die Verbindung muss auf beiden Seiten definiert sein: Automation Engine und Agent, siehe Eine Verbindung zum CP herstellen.

Die folgenden Schritte führen Sie durch die Migration durch Anpassung der INI-Dateien Ihrer Agenten:

Beenden Sie in Ihrem lokalen System die AE-Serverprozesse.
Stellen Sie sicher, dass alle Ihre Agenten im ServiceManager noch ausgeführt werden. Die Agenten werden weiter ausgeführt, sind aber nicht mit einem Kommunikationsprozess (CP) verbunden.
Automic Automation Kubernetes Edition installieren

Wichtig! Stellen Sie sicher, dass der Parameter operator.migrate in der Datei values.yaml auf true gesetzt ist.
1. Falls noch nicht erledigt, laden Sie das AAKE-Angebot herunter und erstellen Sie Ihr Pull-Geheimnis. Weitere Informationen finden Sie unter .
2. Falls noch nicht erledigt, installieren Sie das Automic Automation Helm-Plug-in. Weitere Informationen finden Sie unter .
3. Passen Sie bei Bedarf die Datei values.yaml aus dem Helm Chart an.
4. Automic Automation Kubernetes Edition installieren
  
  Beispiel
  
  helm install aake automic-automation-<version>.tgz -f values.yaml
  - aake: Name der Helm-Installation. Sie können den Namen Ihrer Helm-Installation frei wählen.
  - -f values.yaml: Stellt die zu verwendende Helm Chart-Konfiguration zur Verwendung
  Optional können Sie -n <Namespace> verwenden, um einen Namespace zu definieren.
5. Verwenden Sie das Helm-Plug-in, um den Fortschritt der Installation zu überprüfen:
  
  $ helm automic-automation status
  
  Sobald die Installation abgeschlossen ist, ist der Status bereitgestellt, und die Zielversionen und die aktuellen Versionen sollten mit der gewünschten Version übereinstimmen. Ist dies nicht der Fall, lesen Sie im Abschnitt "Fehlerbehebung" der Datei README.md im Helm Chart nach, siehe Automic Automation Helm-Plug-in.
6. Optional können Sie die Protokolle des Installationsoperators überprüfen, um den Installationsstatus zu prüfen.
Skalieren Sie Ihr AAKE-Deployment, sodass es eine CP-Replika enthält, siehe Deployments skalieren.
Konfigurieren Sie die Verbindung in der INI-Datei jedes Agenten, siehe INI-Dateien von Agenten.

Beachten Sie, dass Sie die Verbindung mit dem TCP Load Balancer und nicht mit dem CP direkt herstellen müssen, siehe Eine Verbindung zum CP herstellen.
Stellen Sie sicher, dass die Agenten erneut eine Verbindung zum Server/System herstellen.

Migration unter Verwendung des Proxy

Wichtig!

Da eine neue AAKE-Instanz standardmäßig keinen Kommunikationsprozess (CP) benötigt, müssen Sie Ihr AAKE-Deployment so skalieren, dass ein Kommunikationsprozess (CP) enthalten ist. Weitere Informationen finden Sie unter Deployments skalieren.
Sie müssen einen TCP-Load Balancer haben, um die Verbindung zwischen dem Agenten und dem CP im Cluster herzustellen. Die Verbindung muss auf beiden Seiten definiert sein: Automation Engine und Agent, siehe Eine Verbindung zum CP herstellen.

Ab Version 21.0 verwendet auch der Proxy TLS/SSL für die Kommunikation mit der Automation Engine. Wenn Sie den Proxy verwenden möchten, um Ihre Agenten zu verbinden, und Sie ihn bereits verwenden, führen Sie noch kein Upgrade durch. Wenn Sie den Proxy noch nicht verwenden, ihn aber in diesem Szenario verwenden möchten, stellen Sie sicher, dass Sie v12.3 des Proxy installieren, nicht v21.0. Weitere Informationen finden Sie unter Den Proxy – v.12.3 installieren.

Die folgenden Schritte führen Sie durch die Migration unter Verwendung des Proxy:

Beenden Sie in Ihrem System vor Ort die AE-Serverprozesse sowie den Proxy-Client und Proxy-Server, wenn Sie bereits einen Proxy verwenden.
Stellen Sie sicher, dass alle Ihre Agenten im ServiceManager noch ausgeführt werden. Die Agenten werden weiter ausgeführt, sind aber nicht mit einem Kommunikationsprozess (CP) verbunden.
Automic Automation Kubernetes Edition installieren

Wichtig! Stellen Sie sicher, dass der Parameter operator.migrate in der Datei values.yaml auf true gesetzt ist.
1. Falls noch nicht erledigt, laden Sie das AAKE-Angebot herunter und erstellen Sie Ihr Pull-Geheimnis. Weitere Informationen finden Sie unter .
2. Falls noch nicht erledigt, installieren Sie das Automic Automation Helm-Plug-in. Weitere Informationen finden Sie unter .
3. Passen Sie bei Bedarf die Datei values.yaml aus dem Helm Chart an.
4. Automic Automation Kubernetes Edition installieren
  
  Beispiel
  
  helm install aake automic-automation-<version>.tgz -f values.yaml
  - aake: Name der Helm-Installation. Sie können den Namen Ihrer Helm-Installation frei wählen.
  - -f values.yaml: Stellt die zu verwendende Helm Chart-Konfiguration zur Verwendung
  Optional können Sie -n <Namespace> verwenden, um einen Namespace zu definieren.
5. Verwenden Sie das Helm-Plug-in, um den Fortschritt der Installation zu überprüfen:
  
  $ helm automic-automation status
  
  Sobald die Installation abgeschlossen ist, ist der Status bereitgestellt, und die Zielversionen und die aktuellen Versionen sollten mit der gewünschten Version übereinstimmen. Ist dies nicht der Fall, lesen Sie im Abschnitt "Fehlerbehebung" der Datei README.md im Helm Chart nach, siehe Automic Automation Helm-Plug-in.
6. Optional können Sie die Protokolle des Installationsoperators überprüfen, um den Installationsstatus zu prüfen.
Skalieren Sie Ihr AAKE-Deployment, sodass es eine CP-Replika enthält, siehe Deployments skalieren.
Falls noch nicht geschehen, installieren Sie den Proxy-Client und den Proxy-Server.

Wichtig! Da Ihre Agenten noch nicht aktualisiert wurden, stellen Sie sicher, dass Sie Version 12.3 des Proxy installieren. Weitere Informationen dazu finden Sie unter Den Proxy installieren – v.12.3.
Konfigurieren Sie die Agentenverbindung in der INI-Datei des Proxy. Beachten Sie, dass Sie die Verbindung mit dem TCP Load Balancer und nicht mit dem CP direkt herstellen müssen, siehe Eine Verbindung zum CP herstellen.

Hinweis: Wenn Sie zuvor den Proxy verwenden,, stellen Sie sicher, dass Sie den Eintrag im Abschnitt CP_LIST der INI-Datei löschen. Andernfalls verwendet der Proxy diese Definition, um sich mit dem alten Server zu verbinden, siehe Proxy INI-Datei.
Starten Sie die Proxy-Prozesse.
Stellen Sie sicher, dass die Agenten erneut eine Verbindung zum Server/System herstellen.

Migration unter Verwendung des TLS Gateway als CP-Port

Wichtig! Die Kommunikation zwischen der Automation Engine und dem TLS Gateway verwendet TLS/SSL. In der AAKE richtet das TLS Gateway eine Verbindung zu einem HTTPS Load Balancer ein, der erreichbar sein muss und ein Zertifikat zur Authentifizierung benötigt. Die Adresse des Load Balancers muss auf beiden Seiten definiert werden: für die Automatisierungs-Engine und das TLS Gateway.

Voraussetzungen: Sie müssen das TLS Gateway installiert und konfiguriert haben, damit es als CP-Port verwendet werden kann. Sie müssen auch die erforderlichen Zertifikate bereitstellen, damit das TLS Gateway die Verbindung mit dem HTTPS Load Balancer herstellen kann, und nicht direkt mit dem JCP.

Mehr Informationen:

Die folgenden Schritte führen Sie durch die Migration unter Verwendung des TLS Gateway als CP-Port:

Beenden Sie in Ihrem lokalen System die AE-Serverprozesse.
Stellen Sie sicher, dass alle Ihre Agenten im ServiceManager noch ausgeführt werden. Die Agenten werden weiter ausgeführt, sind aber nicht mit einem Kommunikationsprozess (CP) verbunden.
Automic Automation Kubernetes Edition installieren

Wichtig! Stellen Sie sicher, dass der Parameter operator.migrate in der Datei values.yaml auf true gesetzt ist.
1. Falls noch nicht erledigt, laden Sie das AAKE-Angebot herunter und erstellen Sie Ihr Pull-Geheimnis. Weitere Informationen finden Sie unter .
2. Falls noch nicht erledigt, installieren Sie das Automic Automation Helm-Plug-in. Weitere Informationen finden Sie unter .
3. Passen Sie bei Bedarf die Datei values.yaml aus dem Helm Chart an.
4. Automic Automation Kubernetes Edition installieren
  
  Beispiel
  
  helm install aake automic-automation-<version>.tgz -f values.yaml
  - aake: Name der Helm-Installation. Sie können den Namen Ihrer Helm-Installation frei wählen.
  - -f values.yaml: Stellt die zu verwendende Helm Chart-Konfiguration zur Verwendung
  Optional können Sie -n <Namespace> verwenden, um einen Namespace zu definieren.
5. Verwenden Sie das Helm-Plug-in, um den Fortschritt der Installation zu überprüfen:
  
  $ helm automic-automation status
  
  Sobald die Installation abgeschlossen ist, ist der Status bereitgestellt, und die Zielversionen und die aktuellen Versionen sollten mit der gewünschten Version übereinstimmen. Ist dies nicht der Fall, lesen Sie im Abschnitt "Fehlerbehebung" der Datei README.md im Helm Chart nach, siehe Automic Automation Helm-Plug-in.
6. Optional können Sie die Protokolle des Installationsoperators überprüfen, um den Installationsstatus zu prüfen.
Falls noch nicht geschehen, installieren Sie das TLS Gateway und konfigurieren es, damit es als CP-Port verwendet werden kann und damit es eine Verbindung zum HTTPS Load Balancer herstellen kann.

Mehr Informationen:
Konfigurieren Sie die Agentenverbindung in der INI-Datei des TLS Gateway, siehe TLS Gateway.

Tipp: Stellen Sie sicher, dass die Parameter hostname= und cp_port= im Abschnitt [TCP/IP] der INI-Datei des TLS Gateway die CP-Verbindung darstellen, die Ihre Agenten derzeit verwenden. Damit vermeiden Sie, die INI-Datei jedes Agenten ändern zu müssen.
Stellen Sie sicher, dass die Agenten erneut eine Verbindung zum Server/System herstellen.

Deployments skalieren

Durch Ändern der Anzahl von Replikas für eine neue Installation oder vor/nach einer Aktualisierung können Sie Ihre Deployments für AWI, JCP, REST, JWP, CP und WP. Sie können die Anzahl von Replikas in der Datei values.yaml im Helm Chart festlegen. Achten Sie darauf, dass Sie die für Ihre Installation relevanten Größenrichtlinien befolgen.

Beispiel

Das folgende Beispiel zeigt die values.yaml-Dateikonfiguration für einen Standard-Namespace:

spec:
  version: "21.0.0"
  awiReplicas: 2
  cpReplicas: 0
  jcpRestReplicas: 2
  jcpWsReplicas: 2
  jwpReplicas: 2
  wpReplicas: 6

Standardmäßig sind die CP-Replikas auf null gesetzt, weil für eine neue AAKEUmgebung keine CPs erforderlich sind. Wenn Sie jedoch eine Verbindung zu anderen als TLS-/SSL-Agenten und/oder CallAPIs herstellen möchten, benötigen Sie einen CP. Weitere Informationen finden Sie unter Eine Verbindung zum CP herstellen.

Verwenden Sie die Helm-Aktualisierung, um die Replika-Änderungen anzuwenden:

helm upgrade aake automic-automation.tgz --install -f values.yaml

Sie können Deployments auch mithilfe von kubectl-Befehlen skalieren. Jedoch bleiben diese Werte nach einer Aktualisierung oder einer Änderung der Konfigurationszuordnung nicht erhalten.

Beispiel

kubectl scale deployment awi --replicas=2
kubectl scale deployment jcp-rest --replicas=2
kubectl scale deployment jwp --replicas=3

Der Parameter -- replicas ändert die Anzahl der laufenden Pods für das entsprechende Deployment, sodass Sie Ihre Automation Engine skalieren können.

Mehr Informationen:

Mehrere Automation Engine-Instanzen in einem Kubernetes-Cluster

Sie können mehrere Automation Engine-Instanzen in einem Kubernetes-Cluster ausführen. Wenden Sie dazu das Image Pull Secret an, das in jedem Namespace bereitgestellt ist, in dem Sie das Helm Chart installieren. Stellen Sie außerdem sicher, dass Sie den Namespace im Helm-Installationsaufruf angeben.

Beispiel

Dieses Beispiel erstellt den Namespace automic-demo-01 und installiert das Helm Chart in diesem Namespace.

helm install aake automic-automation-<version>.tgz -n automic-demo-01 --create-namespace kubectl apply -n automic-demo-01 -f values.yaml -f gcr-image-pull-secret-automic.yaml

Eine AAKE-Installation entfernen

Sie können eine AAKE-Installation entfernen, indem Sie die Helm-Installation deinstallieren.

Beispiel

helm uninstall aake

Stellen Sie sicher, dass Sie den Namen Ihrer Helm-Installation verwenden.

Wichtig! Es wird davon abgeraten, den gesamten Namespace zu löschen, um eine AAKE-Installation zu entfernen, da auf diese Weise alle Ressourcen innerhalb des Namespace sowie der Namespace selbst entfernt werden.

Fehlerbehebung

Benutzerdefinierte Ressourcendefinitionen (CRD) können nicht erstellt werden. Fehler: CRDs konnten nicht installiert werden

Ihr Kubernetes-Benutzer muss die notwendigen Berechtigungen für CRD im Cluster haben. Andernfalls erhalten Sie eine Fehlermeldung, die Ihnen mitteilt, dass CRDs nicht installiert wurden.

Wenn Sie die zum Erstellen von CRDs im Cluster erforderlichen Berechtigungen nicht erhalten können, können Sie die CRD aus dem Helm Chart extrahieren. Führen Sie die folgenden Schritte durch:

Laden Sie das Helm Chart herunter und entpacken Sie es.
Kopieren Sie die Automic Automation-CRD aus crds/broadcom-.com_automicautomations_crd.yaml.
Senden Sie sie Ihrem Kubernetes-Cluster-Administrator, der dann die CRD mit dem folgenden Befehl anwenden kann:

kubectl apply -f broadcom.com _automicautomations_crd.yaml

Siehe auch: