SAP AS ABAP Running Inside Docker. PART I
I think that this article we can consider as a second part about putting SAP products inside Docker container. First one was about SAP HANA in Docker container and it is available via this link. Now let’s talk oh how we can put SAP AS ABAP inside Docker. At the end it will give us a complete landscape that we can fire up in several seconds. I will mainly focus on docker stuff, and will not touch orchestration of the containers with Swarm or K8, however you can already find quite a nice blog about putting ABAP AS inside K8.
This is what we have:
- SAP HANA Docker image
- Custom SLES Image
Nad below is what we want to achieve:
Each SAP system consists of 2 containers: one for the SAP AS ABAP and one for the SAP HANA DB. Since our saphana containers always use the same hostname, we should isolate this containers with bridge adapters – means each system will run in it’s own network namespace. This is only relevant in case we want to run more than one dockerised system per docker host.
Such network configuration can be done with the following docker commands:
docker network create -d bridge -o "com.docker.network.bridge.name=sap-br01" -o "com.docker.network.bridge.enable_icc=true" --subnet 172.20.0.0/24 sap-net docker network create -d bridge -o "com.docker.network.bridge.name=sap-br02" -o "com.docker.network.bridge.enable_icc=true" --subnet 172.30.0.0/24 sap-net02
This will create two docker networks:
From Linux perspective we will have two bridge adapters:
In order to control communication between containers and interfaces, docker will use linux iptables. Linux iptables consist of two tables: filter and nat. In filter table you may find security rules that either allow or deny network communications.
There are several ways on how we can create SAP AS ABAP container, starting from very simple: Install SAP S/4 instance inside container and than execute docker commit, kind of barbarian way 🙂. This command will take a container’s top-level read-write layer and burn it into a read-only layer. Such approach will mutate 🙂 a container (whether running or stopped) into an unchangeable image.
|Very simple way to create docker image||Image update is complicated|
Another way is to prepare Dockerfile, where you should specify instructions, layer by layer:
|You can update and extend image just by adjusting the Dockerfile. And think on running automated builds||More effort to create image. You should take care about all dependencies|
Below we will look on first approach. However for ABAP AS we can combine commit and dockerfile creation way. I will write about this (dockerfile way) approach in next chapter 🙂
First Option: “docker commit”
Firstly, we will prepare docker host.
- Create Docker network
- Spin Docker Containers with prepared SLES image
- Download content for the SAP S/4 Installation from marketplace and copy content inside Docker container
- Run SWPM and install required software
- Persist data and burn the image
Create Docker Network
This one is explained few lines above
Spin Docker Containers
- I’m starting SLES 15.1 image from registry:
docker run -i -d --rm --name sapabap01 --network sap-net --ip 172.20.0.2 --ipc=shareable -t -h saphost2 -p 30100-30199:30100-30199 -p 50100-50199:50100-50199 -p 1128-1129:1128-1129 registry.suse.com/suse/sle15:15.1
- Now I’m starting my prepared HANA image from previous blog:
docker run -i -d --rm --name saphana01 --network sap-net --ip 172.20.0.3 --ipc=shareable --memory=30g -t -h saphost1 sap_hana:latest
Now we have 2 containers running in the same network:
Download Content and Copy it to the Container
The easiest way is to run Maintenance Planner transaction. It will create a list of files that are required for the SAP S/4 Foundation installation. You can download then with SAP Download Manager.
As next step I will login to my SLES container, install dependencies from repo and then I will proceed with installation steps (using SWPM). In order to have installation media I need to copy it from the docker host to the docker container:
Run SWPM and Install Required Software
All is now prepared for the SAP S/4 installation. Let’s do it.
I will skip whole SWPM process of the system installation, as you should follow the wizard. Below you will find some screenshots that I think can be important.
- When you launch SWPM installer you can specify what port should be used to access the installation wizard. That means you can put any mapped port.
- Once SWPM is started you can access it by using hostname of your docker host and port that was mapped when you start your container.
- Proceed with basic SWPM steps. Specify installation media and HANA client distributive.
- You will be asked to provide HANA server host name. This is actually our second container – saphana01 (refer to the landscape image in the very beginning of this article)
- You will receive prerequisites check warning. You can ignore it:
- During installation was running, I was hitting the following resource limits:
- Whole installation took ~15 minutes. At the end I got fully running SAP ABAP S/4 Foundation system distributed between 2 containers:
Persist Data and burn the Image
This is almost last step. System is installed and running. Now it is time to persist data. And this we should do for both containers but in different ways.
For the ABAP we can clean up all installation media and just use docker commit, while for HANA container (since we did not create volumes for SAP HANA DATA files) we should execute full backup (hopefully HANA is doing this very fast) and store it somewhere outside our running container.
Persit ABAP Container
- Clean media folder (BTW it is 9Gb!)
- Clean SWPM installation log from the /tmp (~ 350 MB)
- Uninstall sap host agent (~ 200 MB)
- Stop all SAP services
Actually we can squeeze it even more. For example /sapmnt can also be deleted, and some other files\folders inside /usr/sap/<SID> (This worth of another article, so I will not discuss it right now)
- Time to commit container into image, by executing:
docker commit <IMAGE ID> <NEW IMAGE NAME>
- Lets inspect our freshly created image with dive:
Persit HANA Container
We need to backup both tenants of our HANA 2.0. Firstly let see what we have (just to be sure)
SELECT A.DATABASE_NAME, A.HOST, SUM(B.DATA) AS DATA_GB FROM "SYS"."M_VOLUMES_" AS A INNER JOIN (SELECT VOLUME_ID, DATABASE_NAME, ROUND(DATA_SIZE/1024/1024/1024, 3) AS DATA FROM "SYS"."M_VOLUME_SIZES_" WHERE LOG_SIZE =-1) AS B ON A.VOLUME_ID = B.VOLUME_ID AND A.DATABASE_NAME = B.DATABASE_NAME GROUP BY A.DATABASE_NAME, A.HOST;
Ok, so here we have two tenants that we will backup. Meanwhile most of the questions about HANA backups are answered in the following SAP Note 1642148 – FAQ: SAP HANA Database Backup & Recovery.
And then copy from container:
Finally now we have:
- ABAP AS container
- HANA backup, that we need to restore every time when we start HANA container
However this is not enough. ABAP AS is using hana client and hdbuserstore to communicate with HANA DB server. So, if we will change IP address or container name, or will use another network it will not able to connect to our DB and SAP will not start. That means if we want to start second pair of containers we always should do several adjustments:
- Recover backup into freshly started SAP HANA container
- Adjust ABAP default profile and create new hdbuserstore connection in the ABAP container
Recover HANA DB
- Stop Tenant
alter system stop database BFG;
- Recover Tenant
RECOVER DATABASE FOR BFG UNTIL TIMESTAMP '2021-09-21 15:00:00' USING DATA PATH ('/usr/sap/BFG/HDB01/backup/data/DB_BFG/') USING LOG PATH ('/usr/sap/BFG/HDB01/backup/log/DB_BFG/') CLEAR LOG;
- Start tenant
alter system start database BFG;
Adjust ABAP profile
- Adjust DEFAULT.PFL parameters:
- Recreate hdbuserstore string:
Puhhhh, many manual steps to make it fly:
and here is my final picture with four containers running:
This is my adventure called “Run SAP in Docker”. In the very beginning I noticed that there are at least two options how ABAP container can be created. This blog article touches first option. Most probably I will write another article where will I will use second option. 🙂
Firstly, we need to automate as much as possible:
- Recovery procedure
- Adjustment of the abap profile and many other things….
Secondly, we need to prepare docker compose yml files. This will simplify docker run commands.
And then we can think on how to squeeze images.
My target is to create development infrastructure that will allow to do the following things:
- Usage of gCTS instead of old fashion CTS
- Avoid blocking situations (since we can have many development systems)
- Build CI with Jenkins, that will trigger automatic tests
Unfortunately, we still cannot create full landscape without usage of CTS (too many technical architectural limitations), however we can accelerate (speed up) ABAP feature development and do some ABAP version controlling in Git 🙂
This is it, thank you for reading 🙂