Wenn Sie einen meiner vorigen Blogbeiträge über unseren Weg zu einer Git-basierten ABAP-Entwicklung gelesen haben, werden Sie wissen, dass wir im Rahmen unserer Untersuchungen auch herausfinden wollten, ob Container uns dabei eine Hilfe sein können.

Alles begann mit unserem Proof of Concept, der abapGit-Demo, die wir auf der TechEd 2019 zeigten (falls es Sie interessiert, finden Sie hier eine Aufzeichnung). Bis dahin hatten sich meine Erfahrungen mit Containern auf die Ausführung einer ABAP-Versuchsinstanz auf meinem Laptop unter Verwendung der Skripte von Jakub Filak beschränkt. (Inzwischen habe ich meine eigenen Skripte veröffentlicht.)

Zur Erklärung: Ein Container ist eine Gruppe von Prozessen, die von den anderen Prozessen isoliert sind. Deshalb wirkt ein Container fast wie eine eigenständige virtuelle Maschine (VM). Er braucht aber viel weniger Ressourcen (im Leerlauf belegt meine ABAP-Testversion rund 1 GB RAM; zum Vergleich: bei einer VM sind es mindestens 4 GB) und lässt sich sehr schnell starten, stoppen, erstellen, löschen und sichern. In diesem Blogbeitrag erfahren Sie mehr zum allgemeinen Hintergrund von Containern.

Jetzt aber zurück zu meinen Erfahrungen mit Containern.

Warum

Soweit ich weiß, unterstützt SAP die Ausführung von NetWeaver in Containern nicht, dies kann man allerdings umgehen. Mit einer einfachen Befehlszeile lässt sich ein Container starten, der eine exakte Nachbildung des letzten Snapshots ist. Auf meinem Laptop dauert das ungefähr 10 bis 15 Minuten.

Daraus ergeben sich viele interessante Anwendungsfälle:

• Automatisierte Tests
• Verteilte Entwicklung mit abapGit
• Demos und Schulungen

(Nebenbei bemerkt: Container sind eigentlich ein Unix-/Linux-Ding. Inzwischen gibt es Windows-Container, aber soweit ich weiß, ähnelt der Versuch, Container unter Windows oder Mac zu verwenden, ein bisschen dem Versuch, mit MS Office unter Linux zu arbeiten: Es funktioniert meistens, aber nicht ohne Gefrickel. Aber wie die Überschrift bereits impliziert, bin ich ein Neuling und liege da vielleicht falsch.)

Docker-Images

Ein Container wird immer auf der Basis eines Images erstellt, das mit einem Blueprint Ihres Systems vergleichbar ist. Docker ist ein beliebtes Tool, mit dem Anwendungen in Containern einfacher erstellt, bereitgestellt und ausgeführt werden können.

Wenn ich also ein System-Image mit der Bezeichnung netweaver01 habe und zum Beispiel einen Befehl wie diesen eingebe:

docker run netweaver01

wird

• ein neuer Container mit einem Zufallsnamen wie precious_linx erstellt,
• darin eine neue NetWeaver-Instanz gestartet,
• die Datenbank oder jede andere Datei kopiert, die während der Ausführung modifiziert wird.

Diesen Vorgang können Sie beliebig oft wiederholen, solange Ihnen ausreichend Speicherplatz oder gültige Lizenzen zur Verfügung stehen.

Dadurch erhalten Sie eine dynamische IP-Adresse, eine dynamische MAC-Adresse und einen dynamischen Hardwareschlüssel (außer auf meiner AWS-Instanz; warum, dies so ist, verstehe ich nicht ganz). Deshalb sollten Sie möglicherweise mit einem etwas komplexeren Befehl arbeiten, z. B.:

docker run -d -h netweaver01 --dns-search abap.local--name netweaver_01 -p 3200:3200 -p 3300:3300 --stop-timeout 1200 --mac-address="01:22:aa:01:00:04" netweaver01 tini /usr/local/bin/startinstance

Auf diese Instanz können Sie so zugreifen, als ob sie auf dem Host ausgeführt wird, und einen stabilen Containernamen (netweaver_01), eine MAC-Adresse und eine Hardware-ID angeben.

Dann können Sie den Container über die Befehlszeile starten, stoppen und löschen.

Erstellen eines Images

In einer Docker-Umgebung empfiehlt es sich, den gesamten Image-Erstellungsprozess in einer Docker-Datei zu skripten.

Das übersteigt sowohl bei Docker- als auch bei SAP-Installationen meine Kenntnisse als Neuling, in erster Linie aus zwei Gründen:

• NetWeaver setzt einen stabilen Hostnamen voraus, Docker hingegen nutzt einen dynamischen Hostnamen, der während der Installation nicht erzwungen werden kann (eigentlich schon, aber nur mit einem ziemlich hässlichen Hack).
• Die Installation muss unbeaufsichtigt sein. Ich vermute, es ist eigentlich ganz einfach, wenn man weiß, wie es geht; leider bin ich aber ein Neuling!

Was ich gemacht habe, war ziemlich stümperhaft, hat aber einen großen Vorteil: 
Es funktioniert. Um das umzusetzen, müssen Sie Folgendes tun:

1. Sie führen einen neuen Container aus, der auf Ihrer bevorzugten Linux-Distribution basiert, und erzwingen den gewünschten Hostnamen.
2. Sie erstellen ein Skript, das einige kleine Änderungen an /etc/hosts und /etc/resolv.conf vornimmt, und führen es aus.
3. Sie starten eine reguläre manuelle SAP-Installation.
4. Wenn Sie aufgefordert werden, eine Verbindung mit einem Browser herzustellen, ersetzen Sie den Hostnamen durch die (temporäre) IP Ihres Containers.
5. Sie stoppen die Instanz.
6. Sie erstellen mit einem Docker-Commit ein Image.

Wie gesagt, sind hier viel mehr manuelle Schritte notwendig als beim Best-Practice-Ansatz. Wenn Sie es also besser können, nur zu. Ihnen sollte aber bewusst sein, dass es praktikable Alternativen zu den Best Practices gibt.

Beibehalten von Daten

Container sind nur für die vorübergehende Nutzung gedacht, und viele Tools erstellen und löschen sie ohne große Rücksichtnahme nach Belieben.

Wie bereits erwähnt, erstellt ein neuer Container standardmäßig eine Kopie der Datenbank und löscht diese wieder, wenn er selbst gelöscht wird. Für viele Anwendungsfälle (Demos, Tests) ist das ideal, für andere hingegen nicht (z. B. wenn Sie Container für ein selten verwendetes Entwicklungs- oder Schulungssystem verwenden möchten).

Das können wir durch Verwendung von Volumes erreichen. Ein Volume ist ein teil- permanenter Speicher, den Sie in Ihren Container einbinden und mit TAR-Dateien problemlos sichern oder wiederherstellen können.

Wenn Ihre Daten nicht gelöscht werden sollen, stellen Sie sicher, dass sie sich in einem Volume und nicht im Container befinden.

Großer Lernbedarf

Wie auch bei unseren abapGit-Experimenten hat sich herauskristallisiert, dass wir noch viel darüber lernen müssen, wie sich Container in einer SAP-Umgebung am besten einsetzen lassen. Wir wissen aber auch, dass es hier ein großes Potenzial gibt.

Wir wollen an der Sache dranbleiben, um herauszufinden, ob Container für unsere Entwicklungs- und/oder Testteams ein fester Bestandteil des Workflows sein sollten. Über unsere Fortschritte werde ich in einem kommenden Blogbeitrag berichten.

Wenn Sie in der Zwischenzeit wissen möchten, was wir bisher gelernt haben, welches Feedback wir von unseren Kunden bekommen haben und wie unsere Automatisierungstools mit containerisierten Systemen funktionieren, können Sie sich gerne an uns wenden.