Vorbereiten der Container-basierten Installation

Als Systemadministrator führen Sie einige Schritte aus, bevor Sie Ihr Container-basiertes System installieren.

Tipp! Dieser Abschnitt enthält Informationen, die für Container-basierte Systeme relevant sind. Informationen für manuell installierte Systeme vor Ort finden Sie unter Vorbereitung der manuellen Installation.

Hinweise:

Diese Seite beinhaltet Folgendes:

TLS/SSL-Implementierung – Übersicht

Das nachstehende Diagramm zeigt den für die TLS/SSL-Implementierung erforderlichen Prozess und hilft Ihnen, nicht nur die beteiligten Komponenten, sondern auch den Prozess selbst zu verstehen.

Klicken Sie auf das Bild, um es zu erweitern.

Upgrade-Ablauf aus der TLS-Perspektive

Die Kommunikation zwischen der Automation Engine und den verschiedenen Komponenten verwendet TLS/SSL über ein sicheres WebSocket (WSS). Diese Komponenten richten eine Verbindung zum Java-Kommunikationsprozess (JCP) und/oder dem REST-Prozess (REST) ein, die vertrauenswürdige Zertifikate verwenden, um ihre Identität gegenüber anderen Kommunikationspartnern nachzuweisen, wie beispielsweise Agenten.

Deshalb müssen Sie entscheiden, welche Art von Zertifikaten Sie verwenden werden, um die Kommunikation in Ihrem System zu sichern. Diese Entscheidung muss sorgfältig durchdacht werden, da sie nicht nur bestimmt, wie sicher die Verbindungen sind, sondern auch die Zeit und den Aufwand, die Sie in die Erneuerung und Bereitstellung der Zertifikate investieren müssen.

Wichtig! TLS/SSL-Agenten (in Containern und vor Ort) sowie das TLS Gateway, wenn sie für die Automic Automation Kubernetes Edition verwendet werden, stellen eine Verbindung zu einem Ingress-/HTTPS-Load-Balancer her, der zur Authentifizierung ein Zertifikat anfordert.

Stellen Sie sicher, dass die Adresse des Load Balancers auf beiden Seiten definiert ist: in der Automation Engine und auf dem Agenten/TLS Gateway, und dass Ihr HTTPS-Load-Balancer die erforderlichen Zertifikate zur Nutzung besitzt. Weitere Informationen finden Sie unter Eine Verbindung zum AWI, die JCP- und REST-Prozesse über einen Ingress herstellen.

Verwandte Themen:

Systemübersicht

Klicken Sie auf das Bild, um es zu erweitern.

Grafik, die die Container-Installation darstellt

Das Automic Automation Kubernetes Edition-Angebot herunterladen

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.

Um das Angebot herunterzuladen, gehen Sie wie folgt vor:

  1. Loggen Sie sich bei https://downloads.automic.com/ mit Ihren Broadcom-Zugangsdaten ein und wählen Sie Automic Automation Kubernetes Edition aus.

    Laden Sie auf der Download-Seite das AAKE-Angebot herunter und fordern Sie Zugriff auf die öffentliche Docker-Registrierung von Automic an.

  2. Sobald Sie Zugriff auf das GCP Service-Konto Ihres Unternehmens haben, laden Sie die Datei automic-image-pull-secret.json herunter und erstellen Sie den geheimen Schlüssel mit dem bereitgestellten Befehl.

    Damit kann Ihre Container-Plattform Images aus unserem kennwortgeschützten Repository ziehen.

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.

Das Automic Automation Helm-Plug-in installieren

Sie müssen das Automic Automation Helm-Plug-in installieren, um den Aktualisierungsprozess zu verwalten und zu überwachen. Sie können es auch während der ersten Installation verwenden. Das Automic Automation Helm-Plug-in erfordert den Helm Kubernetes PackageManager.

Verwenden Sie die folgenden Befehle, um das Helm-Plug-in zu installieren:

tar zxvf automic-automation-plugin-<version>.tgz

helm plugin install automic-automation-plugin-<version>

Mit den folgenden Befehlen können Sie den Status der Aktualisierung prüfen:

  • update zeigt, dass die Instanz im aktuellen Namespace aktualisiert wurde
  • status zeigt den Status der Instanz im aktuellen Namespace an
  • logs zeigt die Logs des Operators an

Beispiel

Um die Installation zu überwachen, verwenden Sie das Plug-in mit dem folgenden Befehl:

$ helm automic-automation status

Sobald die Installation abgeschlossen ist, ist der Status bereitgestellt, und die Ziel- und aktuellen Versionen sollten mit der gewünschten Version übereinstimmen. Wenn dies nicht der Fall ist, überprüfen Sie den Abschnitt "Fehlerbehebung" in der Datei README.md im Helm Chart.

Hinweis: Dieses Helm-Plug-in funktioniert mit Linux und kann von einem Linux-CLI aus verwendet werden. Wenn Sie ein Windows-CLI verwenden, können Sie möglicherweise nicht alle Befehle zur Aktualisierung von dort aus ausführen und müssen sie möglicherweise direkt unter Linux ausführen.

Weitere Informationen finden Sie unter Automic Automation Helm-Plug-in.

Konfigurieren von Kubernetes-spezifischen Komponenten vor der Bereitstellung

Es gibt eine Reihe von spezifischen Einstellungen von Kubernetes, die Sie vor der Installation definieren müssen oder können.

Dimensionierung, Anforderungen und Grenzwerte

Stellen Sie sicher, dass Sie alle Dimensionierungsvorgaben berücksichtigt haben und dass Sie alle notwendigen Anforderungen und Grenzwerte definiert haben, um die Ressourcen zu definieren, die jedem Pod zugeordnet sind. Weitere Informationen finden Sie unter Dimensionierung von Automic Automation Kubernetes Edition.

Vorbereiten der Ingress- und TLS/SSL-Zertifikate

Stellen Sie sicher, dass Sie alle erforderlichen Zertifikate für die TLS/SSL-Kommunikation besitzen.

In Automic Automation Kubernetes Edition richten die TLS/SSL-Agenten, die Automic Web Interface und die REST-Clients über einen Ingress/HTTPS-Load-Balancer eine Verbindung zum eine Verbindung zum Kubernetes-Cluster ein. In diesem Fall müssen die erforderlichen Zertifikate für den Ingress/Load Balancer vorhanden sein.

Ingresse enthalten die Konfiguration und die Regeln, die externe (HTTP- oder HTTPS-)Komponenten verwenden müssen, um Dienste innerhalb des Kubernetes-Clusters zu erreichen. Ingress-Controller aus Cloud-basierten Diensten wie AWS, Azure oder Google Cloud Platform verwenden die Informationen im Ingress und die zugehörigen Dienste, um einen Load Balancer (HTTP oder HTTPS) zu erstellen und ihn entsprechend zu konfigurieren.

Vor der Installation müssen Sie entscheiden, welche Art von Ingress erforderlich ist. Sie können automatisch generierte Ingresse oder andere Ingresse verwenden.

Mehr Informationen:

Verwendung automatisch generierter NGINX-Ingresse und entsprechender Zertifikate

Sie können die Datei values.yaml anpassen, um den Ingress zu aktivieren (enabled: true), um einen Anwendungs-Hostnamen bereitzustellen und um ein TLS/SSL-Geheimnis bereitzustellen, das für alle von Ihnen erstellten Ingresse verwendet wird. Der Anwendungs-Hostname ist normalerweise eine öffentliche Adresse oder ein Domänenname, die verwendet werden, um den Ingress/Load Balancer von außerhalb des Clusters zu erreichen.

Sie müssen den privaten Schlüssel und das Zertifikat erstellen, bevor Sie AAKE bereitstellen.

Weitere Informationen über die verschiedenen Zertifikattypen und Beispiele, wie sie erstellt und verwendet werden können, finden Sie unter Welche Art von Zertifikaten sollte ich für Automic Automation v21 verwenden?

Wichtig! Beachten Sie, dass dies nur Beispiele sind, keine Anforderung für Automic Automation darstellen und nicht dafür gedacht sind, die Produktdokumentation zu ersetzen.

Wenn Sie entschieden haben, welche Art Zertifikat verwendet werden soll, und Sie einen privaten Schlüssel und ein Zertifikat haben, stellen Sie sicher, dass Sie auch das entsprechende TLS-Geheimnis erstellen, z. B.:

kubectl create secret tls certificate-tls-secret --key private_key.pem --cert certificate.pem

Sie müssen das TSL-Geheimnis in der Datei values.yaml vor der Bereitstellung konfigurieren.

Die TLS-Agenten verwenden diesen Anwendungs-Hostnamen, um eine Verbindung zum Ingress/Load Balancer herzustellen und die TLS-Hostnamenverifizierung durchzuführen.

Wenn Sie den Ingress aktivieren (enabled: true), werden Ingresse für die AWI, den JCP- und den REST-Prozess standardmäßig erstellt und für einen NGINX-Controller konfiguriert.

Wichtig!

  • Wenn Sie einen anderen Ingress-Controller verwenden möchten, aktivieren Sie nicht den Ingress (enabled: false) in der Datei values.yaml und stellen Sie Ihre eigenen Ingresse bereit. Weitere Informationen finden Sie unter .

  • Bei Problemen beim Hochladen großer Dateien/Pakete in die AWIkann die Ursache möglicherweise eine Netzwerkeinschränkung durch eine Drittanbieter-Softwarekomponente (wie zum Beispiel NGINX) zur Verarbeitung Ihrer Daten sein.

Beispiel 

ingress:
  enabled: true
  applicationHostname: <your-domain.example.com>
  secretName: certificate-tls-secret

Diese Parameter erstellen die Ingress-Regeln, um das Automic Automation, JCP REST und JCP WS bereitzustellen:

  • awi. your-domain.example.com> für das Automic Web Interface

  • jcp-rest.<your-domain.example.com> für den JCP REST-Prozess

  • jcp-ws.<your-domain.example.com> für den Java WS-Kommunikationsprozess

Wenn Sie einen NGINX Ingress Controller mit AAKE verwenden, wird die Verbindung standardmäßig nach 5 Minuten getrennt, was zu einer Zeitüberschreitung des AWI führt. Um das Websocket-Timeout für das AWI zu erhöhen, legen Sie den Parameter worker-shutdown-timeout in der ConfigMap des Ingress Controllers fest.

Beispiel

Die folgende Einstellung lässt die AWI Websocket-Verbindung eine Stunde lang geöffnet:

data:
  worker-shutdown-timeout: 3600s

Wichtig! TLS/SSL-Agenten (in Containern und vor Ort) sowie das TLS Gateway, wenn sie für die Automic Automation Kubernetes Edition verwendet werden, stellen eine Verbindung zu einem Ingress-/HTTPS-Load-Balancer her, der zur Authentifizierung ein Zertifikat anfordert.

Stellen Sie sicher, dass die Adresse des Load Balancers auf beiden Seiten definiert ist: in der Automation Engine und auf dem Agenten/TLS Gateway, und dass Ihr HTTPS-Load-Balancer die erforderlichen Zertifikate zur Nutzung besitzt. Weitere Informationen finden Sie unter Eine Verbindung zum AWI, die JCP- und REST-Prozesse über einen Ingress herstellen.

Wenn Sie die automatisch generierten NGINX-Ingress in Ihrem System verwenden möchten (enabled: true), müssen Sie einen HTTPS Load Balancer installieren und sicherstellen, dass Sie die folgenden Aspekte abdecken:

  • Erstellen eines Zertifikats für den Load Balancer und das entsprechende KubernetesTLS/SSL-Geheimnis, damit der Agent eine Verbindung zum Load Balancer herstellen kann.

  • Konfigurieren des Ingress, um die IP-Adresse des Load Balancers unter Verwendung des Parameters applicationHostname: zu verwenden.

  • Konfigurieren des Ingress, um dieses Zertifikat unter Verwendung des Parameters secretName: zu verwenden.

  • Definieren des Parameters JCP_ENDPOINT der Variablen UC_SYSTEM_SETTINGS, da dies der Endpunkt ist, den der Agent verwendet, um eine Verbindung zum Load Balancer herzustellen

  • Definieren des Parameters connection= im Abschnitt TCP/IP der INI-Datei des betreffenden TLS/SSL-Agenten und oder des TLS Gateway

Wenn ein Agent unter Verwendung des im Parameter connection= definierten Werts gestartet wird, erhält er alle Einträge aus der Variablen JCP_ENDPOINT und speichert die Informationen im Abschnitt JCPLIST seiner Konfigurationsdatei (INI). In diesem Fall enthält die Liste die Adressen aller verfügbaren Load Balancer. Der Agent kann dann einen verfügbaren Endpunkt aus der Liste auswählen, wenn er das nächste Mal startet oder erneut eine Verbindung zur Automation Engine herstellt.

Mehr Informationen:

Andere Ingresse und entsprechende Zertifikate

Sie können Sie den Ingress deaktiviert lassen (enabled: false), wenn beispielsweise nur ein Ingress verwendet werden soll, oder wenn Sie einen anderen Ingress-Controller verwenden möchten. In diesem Fall müssen Sie Ihre eigenen Ingresse bereitstellen.

Verwaltete Kubernetes-Dienste, zum Beispiel die von AWS, Azure oder Google Cloud Platformbereitgestellten, verwenden unterschiedliche Ingress-Controller und erfordern möglicherweise zusätzliche Anmerkungen in der Datei values.yaml für die vorhandenen Dienste. Weitere Informationen finden Sie unter .

Wenn Sie Cloud-basierte Dienste wie AWS, Azure oder Google Cloud Platform verwenden, befolgen Sie deren Richtlinien.

Beispiele

  • Für Google Cloud Platform können Sie ein verwaltetes Zertifikat erstellen und im Ingress entsprechend konfigurieren:

    kind: Ingress
metadata:
  name: aake-ingress
  annotations:
    kubernetes.io/ingress.global-static-ip-name: aake-static-ip
    networking.gke.io/managed-certificates: aake-cert-default

  • Für AWS können Sie den AWS Load Balancer-Controller mit dem Ingress verwenden.

    In diesem Fall wird das Zertifikat vorab erstellt und auf den AWS Certificate Manager hochgeladen. Nach dem Hochladen wird die Zertifikat-ARN erstellt und Sie können sie verwenden, um den Ingress nach Bedarf zu konfigurieren.

    kind: Ingress
metadata:
  name: aake-ingress
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS": 443}, {"HTTPS":8443}]'
    alb.ingress.kubernetes.io/backend-protocol: HTTPS
    alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:eu-central-1:<aws account>:certificate/<certificate arn>

Wenn Sie einen Cloud-Anbieter verwenden und einen Ingress bereitstellen, werden ein HTTPS Load Balancer und das entsprechende Zertifikat automatisch erstellt. Sie müssen den Ingress konfigurieren, um das Zertifikat und die Adresse des Load Balancers zu verwenden. Diese Adresse ist der Endpunkt, den der Agent, die AWI und/oder der REST-Client verwenden, um eine Verbindung herzustellen, und sie wird im Parameter JCP_ENDPOINT oder REST_ENDPOINT der Variablen UC_SYSTEM_SETTINGS konfiguriert. Der JCP_ENDPOINT ist auch der im Parameter connection= im Abschnitt [TCP/IP] der INI-Datei des betreffenden TLS/SSL-Agenten und/oder des TLS Gateway definierte Wert.

Wenn Sie Ihren eigenen Ingresse verwenden, und nicht automatisch generierte Ingresse, können Sie vor der Installation definieren, wo die JCP- und REST-Prozesse erreicht werden sollen, wenn Folgendes zutrifft:

  • Sie kennen die relevanten JCP- und REST-Adressen, die vor der Installation verwendet werden sollen.

  • Sie haben keinen Ingress aktiviert (ingress: false)

In diesem Fall können Sie die Umgebungsvariablen JCP_WS_EXTERNAL_ENDPOINT und JCP_REST_EXTERNAL_ENDPOINT in der Datei values.yaml verwenden, um die URLs hinzuzufügen.

Beispiel

JCP_WS_EXTERNAL_ENDPOINT: "https://jcp-ws.<your-domain.example.com>:443"

Wenn Sie diese Endpunkte vor der Installation über die Datei values.yaml setzen, werden sie beim Deployment automatisch als JCP_ENDPOINT und REST_ENDPOINT in der Variablen UC_SYSTEM_SETTINGS konfiguriert. Andernfalls müssen Sie sie nach der Installation manuell festlegen.

Mehr Informationen:

Dienstkonten

Ein Standarddienstkonto wird erstellt und automatisch in allen Pods im Namespace bereitgestellt. Dies könnte ein Sicherheitsrisiko darstellen. Deshalb wird empfohlen, die automount -Funktion für das Standarddienstkonto zu deaktivieren. Dazu setzen Sie den Parameter automountServiceAccountToken auf false.

Beispiel 

apiVersion: v1
kind: ServiceAccount
metadata:
  name: automic
automountServiceAccountToken: false

Nur der Operator benötigt ein Dienstkonto für die Installation von AAKE. Deshalb müssen Sie den Namen des dedizierten serviceAccount, der vom Operator verwendet wird, im Abschnitt operator: der Datei values.yaml definieren. Stellen Sie sicher, dass Sie das Dienstkonto mit den relevanten Berechtigungen im Namespace erstellen.

Beispiel 

operator:
  serviceAccount:
    create: true
    name: automic-operator-sa

Anmerkungen zum Dienst

Verwaltete Kubernetes-Dienste, wie beispielsweise von AWS, Azure oder Google Cloud Platform bereitgestellt, verwenden unterschiedliche Ingress-Controller und könnten zusätzliche Anmerkungen in der Datei values.yaml für die Dienste operator, awi, jcp-rest und jcp-ws benötigen:

Beispiele

Die Anmerkung GKE für den AWI-Dienst festlegen:

awi:
  service:
    annotations:
      cloud.google.com/neg: '{"ingress": true}'

Die Anmerkung AWS für den JCP-Dienst festlegen:

jcp-ws:
  service:
    annotations:
      service.beta.kubernetes.io/aws-load-balancer-backend-protocol: https

Die AE- und Analytics-Datenbanken für die Container-Installation vorbereiten

Wenn Sie Ihre Automation Engine- und Analytics-Datenbanken auf eine Container-Installation vorbereiten, haben Sie die folgenden Optionen:

  • Sie können ein Backup einer vorhandenen Datenbank verwenden.

  • Sie können verwaltete Datenbanken verwenden, die auf Plattformen wie AWS, Azure und Google Cloud Platform zur Verfügung gestellt werden.

  • Sie können eine neue leere Datenbank vorbereiten, wenn Sie ein neues AAKE-System einschließlich einer Analytics-Bereitstellung installieren möchten.

Ausführliche Anweisungen zum Vorbereiten Ihrer AE- und Analytics-Datenbanken für ein Container-System finden Sie unter Die AE- und Analytics-Datenbanken für die Container-Installation vorbereiten.

Sie können auch entscheiden, Analytics nicht bereitzustellen, siehe .

Angabe alternativer Datenbank-Tablespaces

Wenn Sie Cloud-gehostete Datenbanken verwenden, haben Sie möglicherweise nicht die erforderlichen Berechtigungen, um Tablespaces zu erstellen oder umzubenennen. In diesem Fall können Sie die für die AAKE-Installation bereitgestellten Standard-Tablespaces als alternative Tablespaces in der Datei values.yaml festlegen.

Beispiel

databases:
  automationEngine:
    ...
    dataTablespaceName: <AE-Daten-Tablespace-Name> 
    indexTablespaceName: <AE-Index-Tablespace-Name> 
    ...
  analytics:
    ...
    dataTablespaceName: <Analysedaten-Tablespace-Name> 
    indexTablespaceName: <Analyseindex-Tablespace-Name> 
    ...

Die Analytics-Installation deaktivieren

Alle erforderlichen Komponenten für die Installation und Aktualisierung Ihres Systems werden als vorgefertigte Container-Images zur Verfügung gestellt, die automatisch vom Install Operator installiert werden. Weitere Informationen finden Sie unter Container-basierte Installation - Automic Automation Kubernetes Edition.

Analytics ist eine dieser Komponenten. Sie können jedoch festlegen, dass es nicht installiert werden soll.

Dazu müssen Sie den relevanten Parameter in der Datei values.yaml vor der Installation deaktivieren:

analytics:
  enabled: false

Wichtig! Wenn bereits eine Automic Automation Kubernetes Edition-Instanz mit Analytics ausgeführt wird, deaktivieren Sie sie nicht.

Konfigurieren Ihres Automic Automation-Systems vor der Bereitstellung

Es gibt eine Reihe von spezifischen Einstellungen, die Sie vor der Installation definieren müssen oder können.

Wichtig! Berücksichtigen Sie bei der Konfiguration von Containern, dass auf dem Datenträger gespeicherte Dateien kurzlebig sind. Sie gehen verloren, wenn Container oder Pods anhalten und neu starten. Um Ressourcen im Cluster zu speichern und darauf zu verweisen (z. B. auf Dateien wie Logs, Traces, Bilder usw.), müssen Sie zuerst die Namen der entsprechenden Persistent Volumes (pv) und Persistent Volume Claims (pvc) in den entsprechenden Abschnitten der Datei values.yaml definieren. Weitere Informationen zu Volumes in Kubernetesfinden Sie in der offiziellen Kubernetes Produktdokumentation.

Umgebungsvariablen festlegen

In einer AAKE-Umgebung verwenden Sie Umgebungsvariablen, um Einstellungen für die Automation Engine und das Automic Web Interface zu definieren oder zu ändern. Mit diesen Umgebungsvariablen können Sie nicht nur Werte in der INI-Datei von AE oder in den AWI-Konfigurationsdateien ersetzen, sondern auch System- und andere Einstellungen definieren.

Sie können Umgebungsvariablen unter Verwendung der Datei values.yaml festlegen, bevor oder nachdem Sie Ihr System installieren bzw. installiert haben. Stellen Sie sicher, dass Sie eine Helm-Aktualisierung durchführen, um Ihre Änderungen zu übernehmen. Die ae- und awi-Pods werden automatisch neu gestartet.

Hinweis: Stellen Sie sicher, dass Sie beim Definieren von Umgebungsvariablen das richtige Format verwenden.

Nachdem die Installation zur Verfügung gestellt wurde, können Sie die ConfigMap auch verwenden, um Umgebungsvariableneinstellungen im Zusammenhang mit der INI-Datei und den AWI-Konfigurationsdateien zu ändern.

Mehr Informationen:

Umgebungsvariablen für Automation Engine

Jede Umgebungsvariable für die AE verwendet das Syntaxmuster ${PREFIX_SECTION_KEY:DEFINITION}:

  • PREFIX: AUTOMIC

    Konstantes Präfix für diese Umgebungsvariablen.

  • SECTION:

    Definiert den Abschnitt der INI-Datei, in der sich der Schlüssel befindet, den Sie definieren möchten.

  • KEY:

    Gibt den Schlüssel an, den Sie ersetzen möchten.

  • DEFINITION:

    Der Wert, den Sie für den Schlüssel definieren möchten.

Die Konfiguration der Automation Engine-Serverprozesse wird in der INI-Datei (ucsrv.ini) von AE definiert, die alle relevanten Parameter enthält, die in verschiedenen Bereichen organisiert sind. In einer AAKE-Umgebung können Sie die Datei values.yaml verwenden, um diese Einstellungen vor und nach der Bereitstellung zu ändern.

Hinweise:

  • Nur der Systemadministrator sollte Parameterwerte in den Konfigurationsdateien (INI) ändern, da diese Art von Änderungen sich gegenseitig beeinflussen und eine große Auswirkung auf das Automation Engine-System haben.

  • Sie können ganze Schlüssel der INI-Datei ersetzen, aber keinen vollständigen Abschnitt.

Beispiel

${AUTOMIC_GLOBAL_SYSTEM:AUTOMIC}

Diese Umgebungsvariable legt AUTOMIC als Wert des Schlüssels system= im Abschnitt [GLOBAL] der INI-Datei der Automation Engine fest.

Sie können auch Umgebungsvariablen verwenden, um System- und andere Einstellungen festzulegen, die nicht Teil der INI-Datei der AE sind.

Vor der Bereitstellung können diese Variablen nur in der Datei values.yaml definiert werden. Sobald das System bereitgestellt wurde, können Sie sie auch im Automic Web Interface ändern.

Beispielsweise können Sie sie verwenden, um die Parameter JCP_ENDPOINT und REST_ENDPOINT der Variablen UC_SYSTEM_SETTINGS zu füllen. Dazu definieren Sie die jeweiligen URLs in den Umgebungsvariablen JCP_WS_EXTERNAL_ENDPOINT und JCP_REST_EXTERNAL_ENDPOINT in der Datei values.yaml.

Beispiel

JCP_WS_EXTERNAL_ENDPOINT: "https://jcp-ws.<your-domain.example.com>:443"

Mehr Informationen:

Umgebungsvariablen für AWI

Alle AWI-Einstellungen verwenden das Syntaxmuster ${PREFIX_KEYNAME:DEFINITION}:

  • PREFIX: AUTOMIC

    Konstantes Präfix für alle AWI-Einstellungen.

  • KEYNAME:

    Entspricht dem in den Dateien configuration.properties.xml und corlors.properties.xml definierten Eigenschaftsnamen. Der KEYNAME wird in Großbuchstaben geschrieben, und Punkte werden durch Unterstriche ersetzt. Beispiel: Die Eigenschaft session.colors wird zu AUTOMIC_SESSION_COLORS.

  • DEFINITION:

    Der Wert, den Sie für den Schlüssel definieren möchten

AWI hat obligatorische und optionale Konfigurationsdateien, die Sie ändern müssen/können. In einer AAKE-Umgebung können Sie die Datei values.yaml verwenden, um diese Einstellungen vor und nach der Bereitstellung zu ändern.

Beispiel

  • Umgebungsvariablenschlüssel: AUTOMIC_SSO_SAML_ENABLED

    Wert: Gibt an, ob Single Sign-on (SSO) für das AWI-Login verwendet werden kann

    Beispiel: true

Sie können auch Umgebungsvariablen verwenden, um Einstellungen zu definieren, die nicht Teil der AWI-Konfigurationsdateien sind.

Vor der Bereitstellung können diese Variablen nur in der Datei values.yaml definiert werden. Sobald das System bereitgestellt wurde, können Sie sie auch im Automic Web Interface ändern.

Beispielsweise können Sie die Umgebungsvariable AUTOMIC_LOGO_BASE64 verwenden, um den Text einzugeben, der dem AWI-Logo im BASE64-Format entspricht.

Mehr Informationen:

Für die Migration relevante Umgebungsvariablen

Wichtig! Wenn Sie auf ein Container-basiertes System migrieren, stellen Sie sicher, dass Sie Umgebungsvariablen verwenden, um alle INI-Parameter und AWI-Konfigurationseinstellungen zu definieren, die Sie für Ihr lokales System definiert haben und die Sie in Ihrer AAKE-Umgebung behalten möchten.

Verwenden Sie die entsprechenden Umgebungsvariablen, um die Namen Ihrer vorhandenen Automation Engine- und Automic Web Interface-Instanzen in der Datei values.yaml zu definieren:

  • Umgebungsvariablenschlüssel: AUTOMIC_GLOBAL_SYSTEM

    Wert: Name des AE-Systems

    Beispiel: AUTOMIC

  • Umgebungsvariablenschlüssel: AUTOMIC_SYSTEM_NAME

    Wert: Name des Automic Web Interface-Systems

    Beispiel: AUTOMIC

Hinweis: Bei neuen Installationen können Sie auswählen, wie diese Variablen definiert werden sollen. Stellen Sie für Migrationen sicher, dass Sie die richtige Definition verwenden.

Logs und Traces einstellen

Alle AE-, Analytics- und AWI -Prozesse schreiben standardmäßig ihre Aktivitäten (Logs und Traces) auf die Konsole. Sie können jedoch auch eine Datei konfigurieren, in die Logs, Traces und Dumps geschrieben werden können. Wenn Sie Logs und Traces in eine Datei schreiben möchten, stellen Sie sicher, dass Sie eine Datei für jede Komponente (jcp-rest, jcp-ws, jwp, cp, wp, analytics, awi, initialdata) definieren.

Wenn Sie eine Datei anstelle der Konsole (Standard) verwenden möchten, muss der Name des Persistent Volume Claims (pvc-Name) definiert werden, in den Sie Log-/Trace-Dateien schreiben möchten.

Hinweis: Stellen Sie sicher, dass die Zugriffsknoten des verwendeten PV und PVC auf ReadWriteMany gesetzt sind, wenn die Pods, die darauf zugreifen, auf verschiedenen Knoten ausgeführt werden. Wenn alle Pods auf einem einzelnen Knoten ausgeführt werden, können Sie sie auch auf ReadWriteOnce setzen.

Beispiel 

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-logging
spec:
  storageClassName: manual
  capacity:
    storage: 4Gi
  accessModes:
    - ReadWriteMany
  hostPath:
    path: /home/luf/helm/log
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-logging
spec:
  storageClassName: manual
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 2Gi

Weitere Informationen und Beispiele zu Persistent Volumes und Persistent Volume Claims finden Sie in der offiziellen Kubernetes Dokumentation.

Ändern Sie in der Datei values.yaml die Definition der Parameter log und trace von console in file, um das Log und die Trace in die entsprechende pvc zu schreiben.

Beispiel 

logging:
    pvc:   pvc-logging
    log:   file
    trace: file

Stellen Sie sicher, dass Sie eine Helm-Aktualisierung durchführen, um Ihre Änderungen zu übernehmen. Die ae- und awi-Pods werden automatisch neu gestartet.

Standardmäßig werden Log- und Trace-Dateien bei jedem Neustart des Systems überschrieben. Um ältere Dateien für die spätere Verwendung zu behalten, können Sie die Anzahl der Trace-Dateien angeben, die beibehalten werden sollen, indem Sie die Trace-Ebene im entsprechenden Abschnitt der Datei values.yaml ändern.

Die Verlaufsdateien werden mit 01, 02 usw. benannt und bei jedem Neustart verschoben. Die älteste Datei (mit der höchsten Nummer) wird gelöscht und alle anderen Dateien werden umbenannt (die Nummer wird um 1 erhöht).

Mehr Informationen:

Einrichten von Single Sign-On

Als Systemadministrator können Sie Single Sign-On für das Automation Engine-System einrichten, sodass sich Benutzer nur einmal anmelden und die Anmeldeinformationen nicht immer wieder erneut eingeben müssen. Automic Automation Kubernetes Edition unterstützt das Protokoll Security Assertion Markup Language 2.0 (SAML 2.0).

Sie müssen Single Sign-On aktivieren, um das SAML-Protokoll zu verwenden. Wenn Sie dies vor der Installation tun möchten, setzen Sie die Umgebungsvariable AUTOMIC_SSO_SAML_ENABLED in der Datei values.yaml auf true.

Mehr Informationen:

Die JCP- und REST-Endpunkte erreichen

Wenn Sie Ihren eigenen Ingresse verwenden, und nicht automatisch generierte Ingresse, können Sie vor der Installation definieren, wo die JCP- und REST-Prozesse erreicht werden sollen, wenn Folgendes zutrifft:

  • Sie kennen die relevanten JCP- und REST-Adressen, die vor der Installation verwendet werden sollen.

  • Sie haben keinen Ingress aktiviert (ingress: false)

In diesem Fall können Sie die Umgebungsvariablen JCP_WS_EXTERNAL_ENDPOINT und JCP_REST_EXTERNAL_ENDPOINT in der Datei values.yaml verwenden, um die URLs hinzuzufügen.

Beispiel

JCP_WS_EXTERNAL_ENDPOINT: "https://jcp-ws.<your-domain.example.com>:443"

Weitere Informationen zum Erreichen der Endpunkte nach der Installation und/oder zur Verwendung eines Ingress finden Sie unter Eine Verbindung zum AWI, die JCP- und REST-Prozesse über einen Ingress herstellen.

Den CP-Endpunkt erreichen

Eine neue AAKE-Umgebung benötigt keine Kommunikationsprozesse (CPs). Wenn Sie jedoch eine Verbindung zu Nicht-TLS-/SSL-Agenten oder OS CallAPIs herstellen möchten und das TLS Gateway nicht verwenden können, benötigen Sie einen CP.

Die CP-Replikas sind standardmäßig auf Null eingestellt. Wenn Sie einen CP benötigen, stellen Sie sicher, dass Sie die CP-Replikas so festlegen, dass Ihr Deployment wie erforderlich skaliert wird. Weitere Informationen finden Sie unter Deployments skalieren.

Wenn Sie die relevante Adresse vor der Installation kennen, können Sie die Umgebungsvariable CP_EXTERNAL_ENDPOINT in der Datei values.yaml verwenden, um die URL hinzuzufügen.

Weitere Informationen finden Sie unter Eine Verbindung zum CP herstellen.

Optionale Konfigurationseinstellungen

Es gibt eine Reihe zusätzlicher, optionaler Einstellungen, die Sie für Ihr Automic Automation Kubernetes Edition-System einrichten können:

  • Sie können LDAP für Ihr AAKE-System einrichten.

  • Sie können die Verbindung zwischen Ihrer lokalen Analytics-Umgebung und AAKE konfigurieren.

Mehr Informationen:

Siehe auch: