Our Journey with SAP ERP DevOps Part 2/2

This blog post is part 2 of a 2 part series on our journey with SAP ERP DevOps. Part 1 focuses on the functional aspect of our process, and part 2 focuses on the technical challenges.

Disclaimer: SAP does not yet support running ERP or S/4 on containers.

Docker Challenges

Getting SAP ERP to run inside a container took a great deal of persistence along with trial and error. We developed a procedure to perform an unattended SAP install but still had to keep careful notes of several manual steps of the post-install process. To complicate our effort, Docker’s default configuration is not compatible with this use case. For example, Docker assigns randomly-generated hostnames to each container build step, but SAP requires the hostname to be a fixed value. We have to employ some Linux tricks to convince the SAP installation process that our container has the expected hostname.

Another issue we ran into was a limitation on the “base device size” (by default, Docker’s dm.basesize is 10GB). Our image turned out to be over 100GB. Remember that you will also have to upload this image to the cloud (we are using GCP’s Container Registry). If your internet connection isn’t up to the task of uploading 100GB, you may have to run the entire docker build process inside a VM in the cloud.

We also experienced strange behavior getting SAP to start in our completed image – the container would hang for several minutes when starting the database. After hours of investigation, we realized that Docker’s default overlay2 storage driver uses file-level copy-on-write. The first time you write to any file inside the docker image, the file has to be copied out of the image so that the local writes can be tracked. The SAP main database file was 88GB, and it was taking so long to copy the file that the SAP start script timed out and assumed something had gone wrong. This problem was tricky to solve. We found an alternative docker storage driver that handled SAP’s large DB files more efficiently, but it wasn’t supported by GCP’s managed Kubernetes service. Ultimately we placed SAP’s database files in volumes and used volume snapshots to give each container instance fresh copies of SAP’s huge database files.

Results

Ultimately we built a docker container running SAP ERP. We can spin up a fresh instance in about 3 minutes. Almost half of this time is spent restoring volume snapshots for SAP’s DB, and the other half is starting the SAP database and application server. Although we’d still like to reduce the container start time (we believe reducing testing iteration time increases efficiency), this solution enables the DevOps workflows we need.

The Future of ABAP Development

Although SAP is working towards supporting modern development techniques and tools (S4/Hana express edition is available as a docker container image), it appears that SAP ERP is largely being left out of the official efforts. With years to go before the current 2027 end-of-life target for SAP ERP 6.0, we will be developing new software for ERP for years while customers start to make long-term plans to upgrade. We believe connecting web services through an API provides an improvement in the customer’s experience using their current SAP ERP instance today. 

The ABAP open-source community is still small compared to other modern languages but is gaining in strength. I believe we can attribute this acceleration to the increased accessibility offered by the foundational abapGit package, which has finally made it practical to share ABAP code online. ABAP development workflows will always lag behind workflows for modern languages like python and javascript, but hopefully, we’ll continue to gain access to essential tools that currently do not integrate with SAP.