Enterprise Resource Planning Blogs by SAP
Get insights and updates about cloud ERP and RISE with SAP, SAP S/4HANA and SAP S/4HANA Cloud, and more enterprise management capabilities with SAP blog posts.
cancel
Showing results for 
Search instead for 
Did you mean: 
andrewgugger
Product and Topic Expert
Product and Topic Expert
14,872

Docker and other virtualization technologies are gaining popularity for their efficacy in development (continuous integration/continuous development) and ease of deployment. In terms of resource utilization, virtualization allows multiple isolated containers or VMs to run on one single server reducing hardware costs. This isolation between containers allows for parallel projects to develop independently of one another, reducing the complexity of synchronizing these changes across multiple development landscapes. In this blog post we will go over the process of installing a SAP S/4HANA 2022 Foundation system inside of a docker container. We will also discuss how customers can reduce project complexity by using Docker as a solution for n+m landscapes and ultimately expedite project timelines. This blog post is the first part in a series, please checkout part two to learn about Deploying SAP S/4HANA Containers with Kubernetes!

Overview


Here is an overview of the topics I will cover in this blog post:

  1. What is Docker?
  2. N+M landscape with Docker
  3. Prepare the OpenSUSE image in which we will install our S/4HANA system into.
  4. Install S/4HANA Foundation in docker container
  5. Resource consumption
  6. Commit Container and Push Image to registry
  7. Conclusion 

What is Docker?


Docker is one of the most popular software tools for containerizing applications. It allows you to run your application inside of an isolated environment so you don’t have to worry about parallel dependencies or applications interfering with it. The concept behind containers is very similar to that of virtual machines where you can run multiple VMs in parallel but the applications that are ran in one VM completely independent and isolated from the applications on other VMs and the host.


Now that you understand that a Docker container Is similar to a VM, it is important to understand how they are different.

 

 

Difference between Docker and VMs 

This diagram above shows how Docker applications will sit on the host OS and run on your computer as just another process. Virtual Machines, however, require you to allocate a set amount of your hosts resources to each VM. VMs are better fitted if you are looking for hardware level virtualization and docker containers are ideal for lightweight, scalable, and flexible deployments.


There are 3 main components that are important to understand when learning how containers are created. The first is the Dockerfile, this file is a set of commands and parameters that act as instructions for how our image should be built and you use a Dockerfile to “build” an image. In Docker, an image is a like a “snapshot” of our application at a particular point in time and we use an image to run multiple containers. Finally, a container is just an instance of an image, and you can run many containers off of one image.

 

N+M Landscapes

 


A typical customer landscape will start with their Production Support Landscape that is regularly pushing code changes and general maintenance updates from DEV to QA through to PRD. In the event that the customer wants to perform an upgrade of their system they will need to create an N+1 to not interfere with their production support landscape. However, there could also be other projects being performed in parallel which could require N+M landscapes. Synchronizing the changes from these different parallel projects can quickly become very difficult and complex. This leads to a slower development process, it impacts project timelines, and ultimately results in higher costs for customers. Our idea is to simplify and expedite the development process by deploying S/4HANA Systems in Docker containers and utilize git to help us better manage the synchronizing of changes across these different parallel projects.


Above, you can see an example of what a customers’ new landscape could look like by using Docker containers as a solution for N+M landscapes. In the top half of the diagram you still keep your production support landscape. The bottom half of the diagram showcases how you can build your S/4HANA image via the SWPM tool and push this image to an image registry. On the right, you can see that developers can spin up multiple containers that are independent of each other. These containers can be deployed rapidly using Kubernetes (K8s), we will discuss how to orchestrate these containers with K8s in a future blog post. Because these lightweight containers are all independent of each other, developers can work on the same objects at the same time and not have to worry about object lock. When new features are ready to be added, the developer can push the code changes to a remote repository where they are then merged and pulled into the DEV system.

Tutorial:

Prepare OpenSUSE Image


The first step in containerizing a S/4HANA system is to create a Dockerfile that we will use to build an image of the operating system that we will ultimately run our S/4 system on. Open a text editor and paste the following lines of code into a file and save it as Dockerfile. Be sure to replace the [hostname] with whatever hostname you would like to use (without the []).

 

 

FROM opensuse/leap:latest LABEL hostname="[hostname]"

RUN zypper --non-interactive install --replacefiles \
     uuid uuidd hostname wget expect tcsh tar which net-tools iproute2 gzip libaio1 vim iputils catatonit curl libgcc_s1 libstdc++6 libatomic1 insserv numactl libltdl7

RUN mkdir /usr/download_files

EXPOSE 8000
EXPOSE 44300
EXPOSE 3300
EXPOSE 3200

 


Use your command line to navigate to the directory where you saved your Dockerfile and execute the below command to build your image. (Please note it can take up to 8 minutes for the image to build).

 

 

docker build ./

 


We can see that a new image was created by running the command:

 

 

docker image ls

 


Make note of your image-ID because we will use this to run the container. Use the command below to run the container but replace the "C:/Path/to/installation/files/" with the actual path to the directory where you stored your installation files for the installation. Make sure to replace [image-id] with your actual image id and the [hostname] with the hostname you want to use (without the []).

 

 

docker run -t -d -v C:/Path/to/installation/files/:/usr/installation_files -p 4237:4237 -p 3200:3200 -p 3300:3300 -p 8000:8000 -p 50000:50000 -p 44300:44300 -p 1129:1129 -p 1128:1128 --hostname [hostname] --privileged [image-id]

 


Once your container has been created, you can view the container with the command:

 

 

docker ps

 


Here you will see a list of all your running containers. The next step will be to connect to the container by running the command:

 

 

docker exec -it [container-id] /bin/bash

 


To exit the container type the command (but for now just stay connected to the container):

 

 

exit

 


Confirm that your installation files are present in the shared directory we specified when running the container by navigating to /usr/installation_files.

Before we can unpack the Software Provisioning Manager Tool (SWPM Tool) and start the installation there are still a few more tasks we need to complete. First, navigate to the /etc directory and make a copy of the os-release file. After this you need to replace everything in the os-release file with the following lines:

 

 

NAME="SLES"

VERSION="15-SP3"

ID="sles"

VERSION_ID="15.3"

PRETTY_NAME="SUSE Linux Enterprise Server 15 SP3"

ANSI_COLOR="0;32"

CPE_NAME="cpe:/o:suse:sles:15:sp3"

 


These changes need to be made so that the when the S/4HANA system checks the compatibility of the operating system, there are no issues. The next step will be to update the password for your root user and make note of your password, you will need it later:

 

 

passwd root

 

 

Install S/4HANA Foundation in Docker Container

Navigate to the /usr/installation_files directory where we stored our installation files and unpack and execute the Software Provisioning Manager (SWPM) tool. Once the SWPM tool is running we can begin the installation by opening a browser and navigate to the link provided by the SWPM tool. You will have to replace the [hostname] of the container with the hostname or IP of the host you are running the container in.

https://[hostname]:4237/sapinst/docs/index.html

Enter root as the user and the password that you created for the root user in the earlier step to login. Select SAP S/4HANA Foundation 2022 > installation > Application Server ABAP > Standard System > Standard System and click Next.
Continue through the steps of installing your S/4HANA system with the SWPM tool just like normal.

Resource Consumption (optional)

Once your system is up and running you can return to the OS of your host by entering the command exit in your container’s OS. Docker also has a very useful command that allows you to monitor the resource consumption of all your running containers.

Resource consumption of a S/4HANA system in a container.

The recommended minimum amount of memory for running a S/4HANA system is about 128 GB, but ideally you have more than this. With the docker stats command you can see we are able to run S/4HANA on around ~36 GB of memory.

Commit Container and Push Image to Registry

When all necessary configurations to your system are complete and you are ready to ship your image, there are a few quick steps to complete. First shutdown the S/4HANA system entirely and then exit from the container. Next we will be taking a “snapshot” of our container and save the changes we made in this container to an image so that we can spin up instances of this image in the future. To commit the changes made run this command below (enter the container-id and repository:tag without the []:

 

 

docker commit [container-id] [repository]:[tag]

 


If we want to share this image with our friends and colleagues, we can setup a remote image repository. Commit this image to a remote repository with the below command:

 

 

docker push [repository]:[tag]

 

 

Conclusion

In this blog post we’ve explored the remarkable world of Docker and the potential it has in the way we handle SAP S/4HANA systems. This is a project that myself as well as my teammates are still exploring but it is evident that there are many different applications for deploying S/4HANA systems in docker containers. Docker offers a level of isolation and flexibility that allows multiple containerized systems to be ran on a single server without any conflict. This not only simplifies the development process, but also expedites project timelines and drastically reduces the complexity of synchronizing changes within n+m landscapes. If you enjoyed this blog post, please check out the second part in our series Deploying SAP S/4HANA Containers with Kubernetes! Please stay tuned for other topics my team members and I will be covering next including configuring and installing ABAPGit in a containerized system. This is a project that my colleagues Maxim Shmyrev, Griffin McMann, and I have been working on for a little while now and we are excited about the possibilities this creates for our customers. If you have questions about this blog post or the tutorial, let me know in the comments below!

*It should be noted that SAP does not officially support containerizing S/4HANA systems for PROD and QA. We have only containerized DEV and learning environments. 

7 Comments
craigyu
Explorer
Thank you, Andrew, for this detailed information.

 

Just want to confirm, is this only for deploying a S/4HANA foundation (The ABAP Platform),

or is it possible to deploy a whole S/4HANA ERP as a docker container?

We only found a docker image of abap-trial on docker hub (sapse/abap-platform-trial - Docker Image | Docker Hub).

And we did not find an image available for S/4HANA ERP.

 

Thanks again.
andrewgugger
Product and Topic Expert
Product and Topic Expert
Hi Craig, thank you for your question!

Yes, this tutorial is for installing S/4HANA foundation, not a whole S/4HANA ERP in a docker container. To answer your question, it is possible to install a whole S/4HANA ERP in a docker image, however, the image and container size will  be huge. This might not make it feasible to run the system in a container, but it could depend on your use case. This is not something we have tried yet.

Hope you found the article helpful,

Andrew
craigyu
Explorer
Thank you, Andrew.

Really appreciate for this detailed explanation.
andrewgugger
Product and Topic Expert
Product and Topic Expert

Hi @craigyu I just wanted to update you that we have tested containerizing full SAP S/4HANA (not just foundation) and it works! We have also performed a backup and restore of DEV systems in the container and deployed them on Kubernetes. Although the images are quite large with real business data, the solution is very viable.

0 Kudos

Dear AndrewGugger,

Thank you for sharing this insightful post! It's an exciting development, and I understand we are still in the early stages of this journey with many more steps ahead before we can use this idea in our daily routines. But I would like some clarifications, if possible.

In terms of the N+M DEV/QAS/PROD landscape suggested above, what could be realistic/ideal applications for containers in contrast to VMs? I mean, in terms, of High Availability for Systems and some Components (Router, WebDispatcher etc) as well Scalable/On-Demand launch of new Instances is a common use. But what about resources and customer data?

Can we really achieve a lightweight S/4HANA ERP DEV System? What you show above with the DEV instances could be done with Non-ERP Systems, as is the case of the Docker ABAP Development Trial appliance (~32GB), but with a fulll S/4HANA ERP System with hundreds of GB of memory requirement is it really doable to launch N instances of a DEV System? Especially considering the cost per minute of an AWS instance, for example?

You mentioned using SWPM to create new/updated images. How would that work in practice for existing Systems with loads of data in terms of SPS and Release Upgrades? Could we see a case where SAP would use SWPM to create and publish new base images, that the customers could then use to create their own images with SWPM and/or SUM? What about the persistence layers, and the compatibility of image upgrades with persisted customer Data?

Since right now SGEN and Customer Data share the same DB, Could we see a case where we have split DBs, one for system and one for customer data, where updated SGEN DBs could be continuously delivered via images, leaving the customer DB always untouched? Is Data migration a more viable alternative in this case? Or would gCTS be ultimately responsible for orchestrating the integration of new images into existing SAP Systems?

Do you know of any other blog posts with a more in-depth discussion on how this could be optimally performed? 

I appreciate any further thoughts you (or any other member) can provide on these points. Thank you again for your valuable insights.

Best regards,

Eloi Bermejo

maximshmyrev
Product and Topic Expert
Product and Topic Expert

Hello @EloiBermejo_ElooooIT !
Thank you for your good questions; I will try to answer some of them.

When comparing VMs and containers I would suggest using containers for stateless scenarios such as:

  • Lightweight development environments, where you can bring the repository/dictionary to an ABAP system using git tools like gCTS or abapGit.
  • Test systems, where you can restore a DB dump for regression testing and test automation.
  • Agile development, where automated testing (ABAP or UI5) is a priority, and the test runtime could be containerized.

As you mentioned, for HA/DR scenarios or horizontal scalability, containers can be a viable option, but an orchestrator like Kubernetes is required. However, I don't see the option for PRD system containerization due to performance concerns (a system in a container will be slower compared to hardware or VMs). Similarly, DB containerization is not recommended for the same performance reasons.

Regarding lightweight S/4HANA dev system - we should define what is "lightweight". It is possible to run an empty S/4HANA system (full) with 85GB RAM in a container. However, if you need a full copy of your current DEV system, the requirements will be much higher. In terms of cost, I have personal experience running two Kubernetes clusters with eight S/4HANA 2022 containers in Azure for six months. This solution was cheaper compared to running VMs in an on-premise data center, but this might have been a specific case.

For upgrades the situation is similar to upgrading on-prem systems.I don’t think it would be feasible to build images that work for all customers, and I can see 2 options:

  • Upgrade of development system (or any system in the landscape) and database export / import into container with a freshly installed S/4HANA system
  • Generate a new stack XML and perform the upgrade directly within the container

For persistence layer you can mount a DB directory (e.g., /hana) so that all changes remain available even after a container rebuild. However, this approach breaks the stateless principle. Alternatively, you can connect the container to a separate DB instance.

For other resource you can check this article or Deploying SAP S/4HANA Containers with Kubernetes (second part of Andrew's story). Also, feel free to describe scenarios you think could be useful and we will try to build it in our environment.

Regards,
Maxim

0 Kudos

Thanks Maxim, your answer gave a lot of clarity on the topic!