AAKE V24 PoC bei HanseMerkur

[Nils Hesselink]

Hallo Community

ich wollte hier mal einen kleinen Post aufmachen zum Thema AAKE V24.

Wir haben letzte Woche einen PoC durchgeführt, bei dem wir unsere bestehende Automic Sandbox Umgebung nach AAKE V24 migriert haben. 
Berteiligt waren bestblu(Consulting), HanseMerkur Cloud-Kollegen und Automic Admins. 
An den Erkentnissen möchte ich Euch gerne teilhaben lassen und wir würden uns auch über Feedback freuen.

Ausgangsystem:
Automic Sandbox (kleine Umgebung) Automic Version: 21.0.8  
Beriebsystem: Oracle Linux
Datenbank: Oracle 19.23 (bereits UTF8 / single Instance / bei späteren Stages aber mit DataGuard (mehr dazu s.u.)
 
Zielsystem:
Automic Sandbox AAKE Version: V24.3.0 HF2
Eigene Kubernetes Cloud Umgebung (inhouse)
Datenbank: wie gehabt (s.o.)

Wir haben nach der Bereitstellung des pull_secrets mit Hilfe des operators demnach eine Migration von 21.0.8. auf V24 durchgefüht.

Diese Themen waren dabei spannend oder hinderlich

1. Service Account und ClusterRoleBindings auf Cluster Ebene
   Der Operator möchte als erstes auf Cluster Ebene einen Service Account anlegen. Das dürfen bei uns in Unternehmen nur ausgewählte Leute. Die Automic Admins gehören nicht dazu.
   Diese Dinge wurden dann von den Kollegen aus dem Cloud Team (zunächst ausnahmsweise für den PoC) manuell erledigt. Wunsch wäre hier, dass die installation im eigenen Namespace diese hohen Rechte nicht benötigt
   
   
2. JWP_KEYSTORE_PATH
   Es wäre schön, wenn der JWP_KEYSTORE_PATH automatisch gesetzt würde. Der Operator legt alles im Standard hier ab: /usr/server/bin/secrets/jwp-keystore/cacerts 
   Dann sollte auch der Parameter bei einer AAKE Installation automatisch gesetzt werden.
   
   
3. Service cp
   In der values.yaml definiert man über "cpReplicas: 0", dass man keine CPs benötigt. Es werden aber trotzdem Service für die CPs angelegt. Pods werden nicht gestartet.
   Die Service könnte man sich sparen.
   
   
4. Agent Start über SMgr 
   Wir hatten Probleme mit dem SMgr Password, welches in allen SMgr-Konfigurationen und im UC_SMGR_LOGINS steckt. Diese Passwort hat nach der Migration von V21 auf V24 nicht mehr funktioniert.
   Es gab Access Denied Fehler beim Starten von Agents über die Administrative Perspektive. Die Passwörter (L 1-3) mussten neu erstellt werden und L2 in UC_SMGR_LOGINS eingetragen werden.
   
   
5. Data Guard Connection String mit 2 Hostnames
   In den weiterführenden Stages (Test und Prod) benutzen wird Oracle DataGuard. Dort verwenden wir Connection Strings aus der ucsrv.ini. Diese referenzieren auf die tnsnames.ora.
   Über das DB Secret ist es nicht möglich 2 Hostnames mitzugeben. Über die values.yaml haben wir dann die Parameter AUTOMIC_ODBC_SQLDRIVERCONNECT und AUTOMIC_JDBC_SQLDRIVERCONNECT zusammengebaut und mitgegegeben.
   Diese werden allerdings nur beim initial load ordentlich weitergegeben und verwendet. Beim starten der Pods wird dann wiederum auf das Secret zugegriffen.
   Hier wäre es gut, dass wenn die Parameter in values.yaml gesetzt sind, dass diese auch durchgängig verwendet werden.

Grundsätzlich hat also alles einigermaßen geklappt. An der ein oder anderen Stelle muss noch nachgearbeitet werden - sowohl von BroadCom als auch vom Kunden.
Wer hat noch Erfahrungen mit AAKE gemacht? Wir (HanseMerkur) freuen uns auf einen Austausch.

------------------------------
Nils Hesselink
HanseMerkur
------------------------------

[Nils Hesselink]

English Version by ChatGPT:

Hello Community

I wanted to create a small post here about AAKE V24.

Last week, we conducted a PoC (Proof of Concept), where we migrated our existing Automic Sandbox environment to AAKE V24.
Participants included bestblu (Consulting), HanseMerkur Cloud colleagues, and Automic admins.
I'd like to share the findings with you, and we would also appreciate any feedback.

Source System:
Automic Sandbox (small environment)
Automic Version: 21.0.8
Operating System: Oracle Linux
Database: Oracle 19.23 (already UTF8 / single instance / but with DataGuard in later stages, more on that below)

Target System:
Automic Sandbox AAKE Version: V24.3.0 HF2
Own Kubernetes Cloud environment (in-house)
Database: as before (see above)

After providing the pull_secrets with the help of the operator, we performed the migration from version 21.0.8 to V24.

These topics were interesting or problematic:

1. Service Account and ClusterRoleBindings at the Cluster Level
   The operator wants to first create a service account at the cluster level. Only selected people in our company are allowed to do this. The Automic admins are not among them.
   The Cloud Team colleagues then handled this manually (exceptionally for the PoC). Ideally, the installation in our own namespace shouldn't require these high-level permissions.

2. JWP_KEYSTORE_PATH
   It would be nice if the JWP_KEYSTORE_PATH were automatically set. The operator saves everything by default here: /usr/server/bin/secrets/jwp-keystore/cacerts
   The parameter should also be automatically set during an AAKE installation.

3. Service cp
   In the values.yaml, you define "cpReplicas: 0" to indicate that no CPs are required. However, services for the CPs are still created, but the pods are not started.
   It would be better to avoid creating these services.

4. Agent Start via SMgr
   We had issues with the SMgr password, which is stored in all SMgr configurations and in UC_SMGR_LOGINS. After migrating from V21 to V24, this password stopped working.
   We encountered Access Denied errors when starting agents via the Administrative perspective. The passwords (L1-3) had to be recreated, and L2 had to be entered in UC_SMGR_LOGINS.

5. Data Guard Connection String with 2 Hostnames
   In the later stages (Test and Prod), we use Oracle DataGuard. There, we use connection strings from the ucsrv.ini file, which reference the tnsnames.ora.
   It is not possible to include two hostnames through the DB secret. So, we assembled and passed the parameters AUTOMIC_ODBC_SQLDRIVERCONNECT and AUTOMIC_JDBC_SQLDRIVERCONNECT in the values.yaml.
   However, these are only correctly used during the initial load. When starting the pods, the secret is accessed again.
   It would be helpful if the parameters set in values.yaml were consistently used throughout.

Overall, everything worked reasonably well. Some areas still need improvement – both from Broadcom and from the customer.
Who else has experience with AAKE? We (HanseMerkur) are looking forward to exchanging ideas.

------------------------------
Nils Hesselink
HanseMerkur
------------------------------