Experimenting with containers for ABAP development

If you’ve read any of my previous blogs about our journey to Git-based ABAP development you’ll know that part of our exploration was figuring out whether containers would be a useful technology to employ.

It all started with the proof of concept abapGit demo we showed at TechEd 2019 (you can find a recording here if you’re interested). Prior to that my experience with containers was limited to running an ABAP trial instance on my laptop using Jakub Filak’s scripts (I’ve now also released Jakub Filak’s scripts my own).

In case you’re wondering, a container is a group of processes isolated from the others, so that it looks almost like its own virtual machine. It uses far fewer resources though (when idle my ABAP trial uses about 1GB of RAM vs 4GB or more for a VM) and is very quick to start/stop/create/destroy/backup. You can check out this blog for a bit more generic background.

Anyway, back to my experience with containers.

Why

As far as I know SAP doesn’t support running Netweaver in containers, but it does work. With a simple command line one can start a container which is an exact replica of the last time a snapshot was taken. On my laptop this takes around 10 to 15 minutes.

This has a lot of interesting use cases, including:

• Automated testing
• Distributed development using abapGit
• Demos and training

(As an aside, containers are traditionally an Unix/Linux thing. We do have Windows containers now, but as far as I know trying to use containers on Windows or a Mac is a bit like trying to use MS Office on Linux: it mostly works, but is a pain. As the title says though, I’m a novice and might be wrong on this.)

Docker images

A container is always created based on an image, which is like a blueprint of your system. Docker, meanwhile, is a popular tool designed to make it easier to create, deploy, and run applications in containers.

So if I have a system image called netweaver01, for example, a command like the below will:

docker run netweaver01

• create a new container with a random name like precious_linx
• start a new Netweaver instance inside it
• copy the database or any other file that gets modified while running

You can repeat the process as many times as you want until you run out of memory. Or valid licences.

This will get a dynamic IP address, a dynamic MAC address and a dynamic hardware key (except on my AWS instance for some reason I can’t fathom), so you may want to use something a bit more elaborate like:

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

You’ll be able to access this instance as if it was run on the host, and provide a stable container name (netweaver_01), MAC address and hardware ID

You can then start, stop and delete the container from the command line.

Creating an image

The best practice in a Docker environment is to script the whole image creation process in a Dockerfile.

This is above my paygrade as a novice on both Docker and SAP installations, mainly for 2 reasons:

• Netweaver wants a stable hostname but Docker use a dynamic one which can’t be forced during installation (well, it can but only with some rather ugly hack)
• The installation must be unattended. I bet is easy enough if you know what you’re doing, but I’m a noob!

So what I did was quite subpar but has one big advantage: it does work. The steps went as follows:

1. Run a new container based on your favourite Linux distribution, forcing the hostname you want to use
2. Create and run a script to make some small changes to /etc/hosts and /etc/resolv.conf
3. Start a regular, manual SAP installation
4. When asked to connect with a browser, replace the hostname with the (temporary) IP of your container
5. Stop the instance
6. Create an image with Docker commit

As said, this is much more manual than the best practice. If you can do better go ahead. But take note there are viable alternatives to the best practices.

Persisting the data

Containers are supposed to be transient, and lots of tools will rather liberally create and destroy them at will.

As said before, by default a new container will create a copy of the database and then delete it when deleted. This is great for many use cases (demos, testing), but not for others (i.e. you might want to use containers for a rarely used dev or training system).

We can achieve this using volumes. A volume is a bit of permanent storage which you can mount to your container, and can easily be backed up or restored with tar files.

If your data needs to be persisted make sure it lives in a volume and not in the container.

Lots to learn

As has been the case with our abapGit experiments, it’s clear that we have a lot to learn about how best to use containers in an SAP environment but also that there is a lot of potential upside.

We plan to keep investigating to try and figure out whether containers should be a regular part of the workflow for our dev and/or test teams - I’ll share our progress in a future blog.

In the meantime if you’d like to discuss what we’ve learned so far, the feedback we’ve had from our customers and how our automation tools work with containerized systems, please feel free to get in touch.