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!
Here is an overview of the topics I will cover in this blog post:
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.
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.
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
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.
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.
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]
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!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
8 | |
7 | |
4 | |
4 | |
4 | |
4 | |
4 | |
3 | |
3 | |
3 |