Merge pull request #504 from Suse-KevinKlinger/main

Change EIC annotations

Author: chabowski

adoc/SAP-EIC-General.adoc

@@ -8,13 +8,6 @@ https://help.sap.com/docs/integration-suite?locale=en-US and search for the "Edg
 
 
 
-# tag::disclaimer-annotation[]
-NOTE: In this guide, we use $ and # for shell commands, where # means that the command needs to be executed as a root user and
-$ means that the command can be run by any user.
-
-# end::disclaimer-annotation[]
-
-
 # tag::disclaimer-production-versions[]
 IMPORTANT: If you want to use different versions of {slem} or {slm}, {rancher}, {rke}, or {lh}, make sure to check the support matrix for the related solutions you want to use:
 https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/ +
@@ -36,7 +29,7 @@ The following excerpt provides an example of how to create a CA with a passphras
 
 [source, bash]
 ----
-$ openssl req -x509 -sha256 -days 1825 -newkey rsa:2048 -keyout rootCA.key -out rootCA.crt -passout pass:<ca-passphrase> -subj "/C=DE/ST=BW/L=Nuremberg/O=SUSE"
+openssl req -x509 -sha256 -days 1825 -newkey rsa:2048 -keyout rootCA.key -out rootCA.crt -passout pass:<ca-passphrase> -subj "/C=DE/ST=BW/L=Nuremberg/O=SUSE"
 ----
 
 This will generate the files _rootCA.key_ and _rootCA.crt_.
@@ -45,7 +38,7 @@ The following excerpt shows how to create such a CSR:
 
 [source, bash]
 ----
-$ openssl req -newkey rsa:2048 -keyout domain.key -out domain.csr -passout pass:<csr-passphrase> -subj  "/C=DE/ST=BW/L=Nuremberg/O=SUSE"
+openssl req -newkey rsa:2048 -keyout domain.key -out domain.csr -passout pass:<csr-passphrase> -subj  "/C=DE/ST=BW/L=Nuremberg/O=SUSE"
 ----
 
 Before you can sign the CSR, you need to add the DNS names of your Kuberntes Services to the CSR.
@@ -65,7 +58,7 @@ You can now use the previously created files _rootCA.key_ and _rootCA.crt_ with
 The example below shows how to do that by passing the extension file (here called _domain.ext_):
 [source, bash]
 ----
-$ openssl x509 -req -CA rootCA.crt -CAkey rootCA.key -in domain.csr -out server.pem -days 365 -CAcreateserial -extfile domain.ext -passin pass:<ca-passphrase>
+openssl x509 -req -CA rootCA.crt -CAkey rootCA.key -in domain.csr -out server.pem -days 365 -CAcreateserial -extfile domain.ext -passin pass:<ca-passphrase>
 ----
 
 This creates a file called _server.pem_, which is the certificate to be used for your application.
@@ -75,15 +68,15 @@ Your _domain.key_ is still encrypted at this point, but the application requires
 To decrypt it, run the provided command, which will generate the _server.key_.
 [source, bash]
 ----
-$ openssl rsa -passin pass:<csr-passphrase> -in domain.key -out server.key
+openssl rsa -passin pass:<csr-passphrase> -in domain.key -out server.key
 ----
 
 Some applications (like Redis) require a full certificate chain to operate.
 To get a full certificate chain, link the generated file _server.pem_ with the file _rootCA.crt_ as follows:
 
 [source, bash]
 ----
-$ cat server.pem rootCA.crt > chained.pem
+cat server.pem rootCA.crt > chained.pem
 ----
 
 # end::self-signed-certificates[]
@@ -96,7 +89,7 @@ For an example of uploading your certificates to Kubernetes, see the following e
 
 [source, bash]
 ----
-$ kubectl -n <namespace> create secret generic <certName> --from-file=./root.pem --from-file=./server.pem --from-file=./server.key
+kubectl -n <namespace> create secret generic <certName> --from-file=./root.pem --from-file=./server.pem --from-file=./server.key
 ----
 
 NOTE: All applications are expecting to have the secret to be used in the same namespace as the application.
@@ -174,10 +167,10 @@ spec:
 Apply the yaml file to your kubernetes cluster.
 [source, bash]
 ----
-$ kubectl apply -f selfsigned-issuer.yaml
-$ kubectl apply -f my-ca-cert.yaml
-$ kubectl apply -f my-ca-issuer.yaml
-$ kubectl apply -f application-name-certificate.yaml
+kubectl apply -f selfsigned-issuer.yaml
+kubectl apply -f my-ca-cert.yaml
+kubectl apply -f my-ca-issuer.yaml
+kubectl apply -f application-name-certificate.yaml
 ----
 
 When you deploy your applications via Helm Charts, you can use the generated certificate. 

adoc/SAP-EIC-Harvester-main.adoc

@@ -35,7 +35,7 @@ It will guide you through the steps of:
 * Deploying mandatory components for {eic}
 // * Deploying {eic} into your {rke}
 
-include::SAP-EIC-General.adoc[tags=disclaimer-EIC-sizing;disclaimer-annotation]
+include::SAP-EIC-General.adoc[tags=disclaimer-EIC-sizing]
 
 ++++
 <?pdfpagebreak?>
@@ -110,6 +110,10 @@ While the VMs for the {rancher} cluster must be created directly in {harvester},
 The {eic} will need to run in a dedicated Kubernetes cluster.
 For an HA setup of this cluster, we recommend using three Kubernetes control planes and three Kubernetes worker nodes.
 
+++++
+<?pdfpagebreak?>
+++++
+
 For a graphical overview of what is needed, take a look at the landscape overview:
 
 image::SAP-EIC-Harvester-Architecture.svg[title=Architecture EIC Cluster,scaledwidth=99%,opts=inline,Embedded]
@@ -121,6 +125,7 @@ image::SAP-EIC-Harvester-Architecture.svg[title=Architecture EIC Cluster,scaledw
 
 We will use this graphic overview in the guide to illustrate what the next step is and what it is for.
 
+NOTE: If you want to test upgrades of {harvester}, we recommend setting up an additional {harvester} cluster and seperate the production {eic} instances from the development and test instances.
 
 Starting with installing {harvester}, we will walk you through all the steps you need to take to get a fully set-up Kubernetes landscape for deploying {eic}.
 

adoc/SAP-EIC-ImagePullSecrets.adoc

@@ -15,8 +15,9 @@ Using `kubectl` to create the imagePullSecret is quite easy.
 Get your user name and your access token for the {rac}.
 Then run:
 
+[source, bash]
 ----
-$ kubectl -n <namespace> create secret docker-registry application-collection --docker-server=dp.apps.rancher.io --docker-username=<yourUser> --docker-password=<yourPassword>
+kubectl -n <namespace> create secret docker-registry application-collection --docker-server=dp.apps.rancher.io --docker-username=<yourUser> --docker-password=<yourPassword>
 ----
 
 As secrets are namespace-sensitive, you need to create this for every required namespace.

adoc/SAP-EIC-LoginRegistryApplicationCollection.adoc

@@ -10,7 +10,7 @@ This needs to be done with the Helm client.
 To log in to the {rac}, run:
 [source, bash]
 ----
-$ helm registry login dp.apps.rancher.io/charts -u <yourUser> -p <your-token>
+helm registry login dp.apps.rancher.io/charts -u <yourUser> -p <your-token>
 ----
 
 end::general-login[]

adoc/SAP-EIC-Main.adoc

@@ -20,7 +20,7 @@ It will guide you through the steps of:
 * Deploying mandatory components for {eic}
 // * Deploying {eic} into your {rke}
 
-include::SAP-EIC-General.adoc[tags=disclaimer-EIC-sizing;disclaimer-annotation]
+include::SAP-EIC-General.adoc[tags=disclaimer-EIC-sizing]
 
 ++++
 <?pdfpagebreak?>
@@ -35,7 +35,7 @@ The support matrix below shows which versions of the given software we will use
 |Product | Version
 
 |{slem} | {slem_version}
-|{rke} | 1.28     
+|{rke} | 1.31     
 |{rancher} | {rancher_version}
 |{lh} | {lh_version}
 |{cm} | {cm_version}
@@ -174,7 +174,7 @@ You must log in to {rac}. This can be done as follows:
 
 [source, bash]
 ----
-$ helm registry login dp.apps.rancher.io/charts -u <yourUser> -p <your-token>
+helm registry login dp.apps.rancher.io/charts -u <yourUser> -p <your-token>
 ----
 
 

adoc/SAP-EIC-Metallb.adoc

@@ -16,8 +16,10 @@ Make sure to have one IP address available for configuring {metallb}.
 
 Before you can deploy {metallb} from {rac}, you need to create the namespace and an imagePullSecret.
 To create the related namespace, run:
+
+[source, bash]
 ----
-$ kubectl create namespace metallb
+kubectl create namespace metallb
 ----
 
 [#metalIPS]
@@ -41,7 +43,7 @@ imagePullSecrets:
 Then install the metallb application.
 [source, bash]
 ----
-$ helm install metallb oci://dp.apps.rancher.io/charts/metallb \
+helm install metallb oci://dp.apps.rancher.io/charts/metallb \
 -f values.yaml \
 --namespace=metallb \
 --version 0.14.7
@@ -58,7 +60,7 @@ $ helm install metallb oci://dp.apps.rancher.io/charts/metallb \
 Create the configuration files for the {metallb} IP address pool:
 [source,bash]
 ----
-$ cat <<EOF >iprange.yaml
+cat <<EOF >iprange.yaml
 apiVersion: metallb.io/v1beta1
 kind: IPAddressPool
 metadata:
@@ -73,7 +75,7 @@ EOF
 Create the layer 2 network advertisement:
 [source,bash]
 ----
-$ cat <<EOF > l2advertisement.yaml
+cat <<EOF > l2advertisement.yaml
 apiVersion: metallb.io/v1beta1
 kind: L2Advertisement
 metadata:
@@ -86,6 +88,6 @@ Apply the configuration:
 
 [source,bash]
 ----
-$ kubectl apply -f iprange.yaml
-$ kubectl apply -f l2advertisement.yaml
+kubectl apply -f iprange.yaml
+kubectl apply -f l2advertisement.yaml
 ----

adoc/SAP-EIC-PostgreSQL.adoc

@@ -22,7 +22,7 @@ The {pg} chart can be found at https://apps.rancher.io/applications/postgresql.
 First, create a namespace and the *imagePullSecret* for installing the {pg} database onto the cluster.
 [source, bash, subs="attributes"]
 ----
-$ kubectl create namespace {pg_app_name}
+kubectl create namespace {pg_app_name}
 ----
 
 [#pgIPS]
@@ -89,7 +89,7 @@ podSecurityContext:
 To install the application, run:
 [source, bash, subs="attributes"]
 ----
-$ helm install {pg_app_name} oci://dp.apps.rancher.io/charts/{pg_app_name} -f values.yaml --namespace={pg_app_name}
+helm install {pg_app_name} oci://dp.apps.rancher.io/charts/{pg_app_name} -f values.yaml --namespace={pg_app_name}
 ----
 
 

adoc/SAP-EIC-Redis.adoc

@@ -29,7 +29,7 @@ To create the namespace, run:
 
 [source, bash, subs="attributes"]
 ----
-$ kubectl create namespace {app_name}
+kubectl create namespace {app_name}
 ----
 
 [#redisIPS]
@@ -80,7 +80,7 @@ tls:
 To install the application, run:
 [source, bash, subs="attributes"]
 ----
-$ helm install {app_name} oci://dp.apps.rancher.io/charts/{app_name} \
+helm install {app_name} oci://dp.apps.rancher.io/charts/{app_name} \
 -f values.yaml \
 --namespace={app_name}
 ----

adoc/SAP-EIC-SLEMicro.adoc

@@ -28,11 +28,13 @@ For information that goes beyond the scope of this section, refer to the inline
 To register {slem} with SUSE Customer Center, run `transactional-update register` as follows:
 [source, bash]
 ----
-$ transactional-update register -r REGISTRATION_CODE -e EMAIL_ADDRESS
+sudo transactional-update register -r REGISTRATION_CODE -e EMAIL_ADDRESS
 ----
 To register with a local registration server, additionally specify the URL to the server:
+
+[source, bash]
 ----
-$ transactional-update register -r REGISTRATION_CODE -e EMAIL_ADDRESS \
+sudo  transactional-update register -r REGISTRATION_CODE -e EMAIL_ADDRESS \
 --url "https://suse_register.example.com/"
 ----
 Do not forget to replace
@@ -47,8 +49,10 @@ Find more information about registering your system in the {slem} {slem_version}
 === Updating your system
 
 Log in to the system. After your system is registered, you can update it with the `transactional-update` command.
+
+[source, bash]
 ----
-$ transactional-update
+sudo transactional-update
 ----
 
 === Disabling automatic reboot
@@ -58,7 +62,7 @@ Disable it with the following command:
 
 [source, bash]
 ----
-$ systemctl --now disable transactional-update.timer
+sudo systemctl --now disable transactional-update.timer
 ----
 
 === Preparing for {lh}
@@ -69,20 +73,20 @@ The size of the second disk will depend on your use case.
 Install some packages as a requirement for {lh} and Logical Volume Management for adding a file system to {lh}.
 [source, bash]
 ----
-$ transactional-update pkg install lvm2 jq nfs-client cryptsetup open-iscsi
+sudo transactional-update pkg install lvm2 jq nfs-client cryptsetup open-iscsi
 ----
 
 After the required packages are installed, you need to reboot your machine. 
 [source, bash]
 ----
-$ reboot
+sudo reboot
 ----
 
 Now you can enable the `iscsid` server.
 
 [source, bash]
 ----
-$ systemctl enable iscsid  --now
+sudo systemctl enable iscsid  --now
 ----
 
 ==== Creating file system for {lh}
@@ -92,42 +96,42 @@ The next step is to create a new logical volume with the Logical Volume Manageme
 First, you need to create a new physical volume. In our case, the second disk is called _vdb_. Use this as {lh} volume.
 [source, bash]
 ----
-$ pvcreate /dev/vdb
+sudo pvcreate /dev/vdb
 ----
 
 After the physical volume is created, create a volume group called _vgdata_:
 [source, bash]
 ----
-$ vgcreate vgdata /dev/vdb
+sudo vgcreate vgdata /dev/vdb
 ----
 
 Now create the logical volume; use 100% of the disk. 
 [source, bash]
 ----
-$ lvcreate -n lvlonghorn -l100%FREE vgdata
+sudo lvcreate -n lvlonghorn -l100%FREE vgdata
 ----
 
 On the logical volume, create the XFS file system. You do not need to create a partion on top of it.
 [source, bash]
 ----
-$ mkfs.xfs /dev/vgdata/lvlonghorn
+sudo mkfs.xfs /dev/vgdata/lvlonghorn
 ----
 
 Before you can mount the device, you need to create the directory structure.
 [source, bash]
 ----
-$ mkdir -p /var/lib/longhorn
+sudo mkdir -p /var/lib/longhorn
 ----
 
 Add an entry to _fstab_ to ensure that the mount of the file system is persistent:
 [source, bash]
 ----
-$ echo -e "/dev/vgdata/lvlonghorn /var/lib/longhorn xfs defaults 0 0" >> /etc/fstab
+sudo echo -e "/dev/vgdata/lvlonghorn /var/lib/longhorn xfs defaults 0 0" >> /etc/fstab
 ----
 
 Finally, you can mount the file system as follows:
 [source, bash]
 ----
-$ mount -a
+sudo mount -a
 ----
 

adoc/SAP-EIC-Variables.adoc

@@ -2,15 +2,15 @@
 :sles4sap: SUSE Linux Enterprise Server for SAP applications
 :slm: SUSE Linux Micro
 :slem: SUSE Linux Enterprise Micro
-:slem_version: 5.4
+:slem_version: 6.0
 :sles_version: 15 SP5
 
 
 :sle_ha: SUSE Linux Enterprise High Availability
 :lh: Longhorn
-:lh_version: 1.5.5
+:lh_version: 1.7.2
 :rancher: SUSE Rancher Prime
-:rancher_version: 2.8.3
+:rancher_version: 2.10.1
 :rancher4SAP: Rancher for SAP applications
 :rke: Rancher Kubernetes Engine 2
 :rac: Rancher Application Collection