Gitlab behind a reverse proxy

I am using GitLab for private projects. GitLab is run using the Docker image provided by GitLab. I can access my instance from outside via a reverse proxy (Apache).

The setup is simple:

  • GitLab Docker container is running on NUC and listens on port 7080 for HTTP connections
  • NUC is connected via OpenVPN to the server on AWS
  • Apache as a reverse proxy listening on port 443 for HTTPS
  • Apache terminates SSL: incoming requests are HTTPS, but forwarded as HTTP to GitLab
  • Apache forwards incoming requests to GitLab on Docker

Standard setup of GitLab in Docker with Apache as reverse proxy will give access to GitLab without problems. Start GitLab container, configure Apache, done. You can access GitLab from the internet, create repositories, clone, push, etc.

While the setup will work out of the box, you need to carry out additional configuration for GitLab to really make it work with SSL terminating. What is not working correctly is:

  • The external URL is not configured, so the URL in the repository clone dialog is not using HTTPS.
  • You cannot upload attachments in the Wiki
  • You cannot add pictures in the Wiki via copy & paste from the clipboard
  • Uploading files / images may work in the issues dialog, but not in the wiki, as the wiki is using different upload service.

Attaching an image from clipboard fails.

Problem

My external URL is https://gitlab.itsfullofstars.de. Setting this value as external URL in gitlab.rb. You configure GitLab by setting the parameters in the file gitlab.rb and then reconfigure GitLab.

## GitLab URL
##! URL on which GitLab will be reachable.
external_url 'https://gitlab.itsfullofstars.de'

Run reconfigure to enable the configuration.

gitlab-ctl reconfigure

Accessing gitlab.itsfullofstars.de:

This will set all parameters in all involved components of GitLab based on the values set in gitlab.rb. You can see the new value by looking at the automatically generated configuration file for the internal web server.

## GitLab settings
gitlab:
## Web server settings (note: host is the FQDN, do not include http://)
  host: gitlab.itsfullofstars.de
  port: 443
  https: true

The problem is: GitLab thinks it is running standalone, with direct access to the internet. There is not a specific parameter to inform that the requests are coming from a reverse proxy with SSL termination. Setting the values in gitlab.rb will result in an erroneous configuration:

  • SSL for internal GitLab web server (nginx) is enabled
  • Nginx is not listening on port 80, only on 443
  • My Apache reverse proxy is configured to connect to nginx port 80. Hence the Service Unavailable error.

Port 80 is not working any longer. Accessing GitLab directly via 192.168.x.x:7443 on HTTPS port (Docker mapping 7443 to 443).

Access will work. GitLab tries to get a new TLS certificate during the reconfiguration process, but fails, therefore the self signed certificate.

Attaching an image won’t work

Because of the external_url value, GitLab will redirect to gitlab.itsfullofstars.de. As the reverse proxy is not able to connect, it’s a 503 error.

Configuring the external GitLab URLs results in:

  • An incorrect HTTPS configuration due to wrong certificate
  • Adjustment of Apache reverse proxy: no longer SSL termination

I do not want to take of managing GitLabs internal TLS certificate. I want to access it via HTTP only and use Apache for SSL termination.

Solution

The solution is to configure the external URL and to let the internal nginx run on port 80 and no HTTPS.

Gitlab.rb

Configure a value for external_url.

vim config/gitlab.rb
external_url 'https://gitlab.itsfullofstars.de'
nginx['listen_port'] = 80
nginx['listen_https'] = false
gitlab-ctl reconfigure

GitLab HTTP server

Check the configuration for the internal GitLab web server. The server should be gitlab.itsfullofstars, the port 80 and protocol HTTP.

more data/gitlab-rails/etc/gitlab.yml
## GitLab settings

gitlab:
## Web server settings (note: host is the FQDN, do not include http://)
  host: gitlab.itsfullofstars.de
  port: 80
  https: false

Optional: Restart

Running reconfigure restarts the services, but if you want to be sure, restart GitLab.

gitlab-ctl restart

Apache configuration

My Apache configuration. Maybe not all parameters are needed, but it works.

<VirtualHost *:443>
  ServerName gitlab.itsfullofstars.de
  ProxyPreserveHost On
  ProxyRequests Off
  SSLProxyEngine on
  SSLEngine on
  SSLHonorCipherOrder on
  <Location />
    RequestHeader unset Accept-Encoding
    RequestHeader set Host "gitlab.itsfullofstars.de"
    RequestHeader add X-Forwarded-Ssl on
    RequestHeader set X-Forwarded-Proto "https"
    ProxyPass http://nuc:7080/
    ProxyPassReverse http://nuc:7080/
    Order allow,deny
    Allow from all
  </Location>
</VirtualHost>

Result

After executing the above steps, your configuration should be:

An external request is now for server gitlab.itsfullofstars.de. Apache does SSL termination, and nginx is accepting the request without either blocking it or trying to redirect to HTTPS.

Attaching an image to GitLab Wiki by pasting it from the clipboard


Links

Some resources I found while solving the issue for myself.

https://gitlab.com/gitlab-org/gitlab-ce/issues/27583

https://docs.gitlab.com/omnibus/settings/nginx.html#supporting-proxied-ssl

https://gitlab.com/gitlab-org/gitlab-ce/issues/52243

Let the world know

Adjust image size of Docker qcow2 file

Short version

Increase image size by 100GB:

qemu-img resize ~/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/Docker.qcow2 +100G

Resize partition:

qemu-system-x86_64 -drive file=~/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/Docker.qcow2  -m 512 -cdrom ~/Downloads/gparted-live-0.30.0-1-amd64.iso -boot d -device usb-mouse -usb

Get an empty Docker.qcow2 image from my GitHub page and make your Docker use it:

https://github.com/tobiashofmann/sap-nw-abap-docker

How to adjust the Docker image size for using large containers like SAP NetWeaver ABAP

Docker uses an image file to store Docker containers. The file is named Docker.qcow2 and is located (on Mac) at:

~/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/Docker.qcow2

By default, the file can grow to a size of 64 GB.

When you first start Docker, the size of this image is around 1.4GB. Adding containers, image, etc and it will grow to 64GB.

The 64GB default size can be seen when using qemu-img info:

qemu-img info ~/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/Docker.qcow2

When this limit is reached, Docker should automatically increase the size of the image, but this isn’t working always. As a result, when the image is at 64 GB, you can get an error message stating that the device is full:

no space left on device

At least with my Dockerfile for SAP NetWeaver ABAP Developer Edition Docker is not increasing the image file dynamically. Because of this I had to split the automatic installation process in two parts: base image setup and installation. I guess that right now the SAP Installation is filling up space faster than Docker can react.

The Docker.qcow2 file is a VM disk. Therefore, it is possible to manipulate it like any other virtual disk: you can increase the disk size and access files within the VM disk when you mount the image in a VM. An easy solution to change the disk size Docker has available to store images and containers is to increase the disk size. This can be done by using Qemu and GParted.

Preparations

Locate qcow2 on your Computer

Click on open in finder. Finder opens at the specified location.

Shut down Docker.

Make a backup of the Docker.qcow2 file.

Install QEMU

To install qemu, use brew on Mac.

brew install qemu

Now Qemu should be installed.

Download GParted

Download the x64 gparted ISO image from their web site: 

https://downloads.sourceforge.net/gparted/gparted-live-0.30.0-1-amd64.iso

Resize Docker.qcow2

Resizing the Docker.qcow2 file to a new size consists of two steps.

  1. Make the disk larger
  2. Adjust the partition

Increase disk size

First, let’s make the disk larger. SAP can occupy some space, make sure you add enough GB to the image. An additional 100 GB should do it.

qemu-img resize ~/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/Docker.qcow2 +100G

Output is a simple status message.

Image resized.

Adjust partition table

To resize the image, start Qemu, use the GParted ISO image as boot file and mount the Docker.qcow2 disk.

qemu-system-x86_64 -drive file=~/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/Docker.qcow2  -m 512 -cdrom ~/Downloads/gparted-live-0.30.0-1-amd64.iso -boot d -device usb-mouse -usb

I got some error messages, but Qemu started.

Starting the virtual machine will take some time. Be patient. Next you’ll have to configure the GParted ISO image.

The default values should be enough. This gives you a keyboard, mouse, English and X. After that, Gparted is started and you should see the Docker.qcow2 disk in the Gparted app.

Select the disk and click on Resize / Move. In the new size (MiB) field, enter the new size of the disk you need. The disk size is allocated dynamically and won’t occupy immediately space on your physical disk. So don’t be shy. Assign all free space to the partition.

Click on Resize/Move and on the Apply button

Last chance to stop. But as you need the new free space for Docker, click again on Apply.

The partition will be resized. In case something goes wrong, please restore the backup of the Docker.qcow2 file you made previously.

After the operation finishes, you can see that the partition is now offering 164GB.

Shutdown the VM. As the Docker.cqow2 file changed was the original one used by Docker, you have only to restart Docker to benefit from the new image size. Now you can use Docker to run SAP NetWeaver ABAP with just one command. As the Docker.qcow2 file is empty, even when the image size is reported as 4 GB, compressed (zipped) it’s just a few MB.

With the new Docker disk file you can even start SAP NetWeaver ABAP without getting the “no space left on device” message.

Image creation works. The space occupied by just the SAP NetWeaver ABAP image is already at 65 GB.

Start a container

docker run -P -h vhcalnplci --name nwabap751 -it nwabap:latest /bin/bash

In Kitematic

Start UUIDD

/usr/sbin/uuidd

Change to user npladm

su - npladm
startsap

Problem with starting SAP

When you log in to your container and run startsap, the program will fail. It will report that no instance profiles were found.

startsap

Take a look at the available profiles.

ls -1 /sapmnt/NPL/profile/

During the installation, the installation script installed the profile files for the container with the dummy name 4f65[…], after starting the container, we specified a specific host name: vhcalnplci. Of course, these do not match and make sapstart fail.

Let’s adjust the instance profile configuration.

  1. Rename files
  2. Substitute references to old hostname to correct one vhcalnplci
mv NPL_ASCS01_4f6e4ee4de40 NPL_ACS01_vhcalnplci
mv NPL_D00_4f6e4ee4de40 NPL_D00_vhcalnplci
sed -i -- 's/4f6e4ee4de40/vhcalnplci /g' *

Now run again sapstart and it should work. If not, stop and start the container and try again.

Let the world know

Connect to NetWeaver ABAP instance running inside Docker

This blog will help you to connect to your SAP NetWeaver ABAP instance running inside a Docker container. For how to get NetWeaver running inside a Docker container, please see my blog Docker for SAP NetWeaver ABAP 7.5x Developer Edition.

SAPGui

Open SAPGui and create a new connection.

Give a name for the connection and click on tab Advanced. I use NPL Docker. Activate expert mode and give the correct connection String. Check to which port the message server port is mapped to by Docker. Inside the container, the port is 3200, and in my case, the external port is 32771. Therefore, the connection String is:

Connection String: conn=/H/localhost/S/32771

Note: the port information is specified when you start the container. As an alternative, you can use Kitematic to see the port mapping.

Save and connect to NetWeaver.

The users and passwords can be found in the readme.html of the extracted SAP NW ABAP 751 download. Standard users are SAP* and Developer.

HTTP Access

You can test if access to your new SAP system is working via HTTP by calling the ping service: http://localhost:32769/sap/public/ping

For this to work, first activate the ping service in SICF.

When you get the response “Server reached.” you can start using the HTTP access.

SAP WebGui

For general WebGui activation, you can see my previous blog “Activation of SAP WebGui”. Here is a short version of this guide. As in the previous HTTP service access, the same procedure must be followed to have access to NPL via WebGui.

Activate the service webgui

To activate the SAP WebGui service, activate the node:

/sap/bc/gui/sap/its/webgui

Activation of public resources

You also need to activate the public service that contains the HTML files (JS, etc):

/sap/public/bc/its

Note

It is not sufficient to only activate the webgui node. The app is using additional resources that are available under /sap/public/bc/its. If this node is not activated, you’ll get an error message when logging in to webgui.

Therefore, for SAP WebGui to load the node /sap/public/bc/its must be activated too.

Activate the node its and its subnodes. Select Activate Service.

Activate with all sub nodes nodes (second Yes).

Result

After activating these two nodes, access to WebGui should work. To test this, call the URL http://localhost:32769/sap/bc/gui/sap/its/webgui After logging in, you should see the SAP Menu.

Let the world know

Dockerfile for SAP NetWeaver ABAP 7.5x Developer Edition

This blog will help you to run your own SAP NetWeaver 7.51 ABAP instance inside a Docker container. This work was inspired by the Dockerfile created by Gregor Wolf and hosted at bitbucket.

The difference is that in Gregor’s version you download the NW ABAP installation files and when the container is build, you go manually through the installation. My Dockerfile assumes that you have downloaded the NW 7.51 ABAP installation files already and will automate the installation. Once you have downloaded the installation files from SAP you can make them locally available and create new Docker images / containers based on these, without having to download almost 16 GB again. And the installation script will run without prompting for user input.

Another differentiation is that you can “easily” change the Dockerfile to install NetWeaver 7.50 of the developer edition.

Pre-requisites

To be able to run the Dockerfile, you need

  • Docker installed
  • Downloaded and extracted installation files of SAP NW ABAP Developer Edition
  • Internet connection

Installation

1 Get the Dockerfile

From my GitHub repository, you can find a Dockerfile that helps you to create a Docker image and container that will install your downloaded NetWeaver version. All you need is the Dockerfile, so a simple download is sufficient. You can also download the file by cloning the GitHub repository: https://github.com/tobiashofmann/sap-nw-abap-docker

2. Download SAP NetWeaver DE installation files

Download your version of SAP NetWeaver ABAP 7.5x Developer Edition from SAP. The files are compressed (RAR).

  1. Un-compress them into a folder named NW751. The folder must be at the same location where your Dockerfile is.
  2. Build the Docker image

Build the Docker image

Command:

docker build -t nwabap .

Sample output

After the build is finished, the last line you should see is

Successfully tagged nwabap:latest

To see the ID and name of the newly created image, run the following command:

docker images

Sample output

The command lists the ID, tag and size of the image. As you can see, it’s a 15 GB Docker image. Using this image, you can start a container and install NW ABAP 7.51 DE inside the container.

Create container from image

You can now create a container from the image. You’ll have to connect to the container and run the installation script run.sh. The file was created during docker build. It will run SAP’s install.sh and fill in the input automatically.

docker run -P -h vhcalnplci --name nwabap751 -it nwabap:latest /bin/bash

This will start the container and log you in. What you’ll get is the bash shell.

bash-4.3#

In case you have Kitematic installed, you can see the running container listed.

The container configuration for the ports is also visible there. The ports are automatically mapped by Docker. The message server port 3200 is accessible through localhost:32771, and the HTTP port 8000 through localhost:32769. This mapping can be changed either inside Kitematic or when the container is started on the command shell.

Run ls to see the content of the current directory. You can see the install.sh file from SAP (feel free to start the installation manually) and the run.sh script that will automate the installation.

Start installation

Run the script run.sh to install SAP NetWeaver ABAP 7.51. The script will enter all information requested by install.sh automatically. The installation will take some time, +/- 20 minutes.

./run.sh

Sample output

[…]

[…]

The installation worked when the script ends and you can see the output:

Installation of NPL successful

 

 

Let the world know

Install SAP Web Dispatcher on Docker using SWMP

SAP Web Dispatcher is an important component in a SAP landscape. While have been treated as optional for many years and found mainly in SAP Portal scenarios, with the increase adoption of Fiori, having a reverse proxy in the landscape is becoming pre-requisite. While it’s possible to choose from a wide range of alternatives of servers for a reverse proxy, SAP`s Web Dispatcher is normally always the best fit in a SAP landscape. A question that sometimes arises is how to install Web Dispatcher.

First you settle on what version of Web Dispatcher (WD) to install. SAP Note 908097 states that you should go for the latest version. “Version 7.49 is the recommended SAP Web Dispatcher version for all backend systems.”

The actual installation gives you two options:

  • easy and
  • recommended.

The easy alternative is to simply un-sapcar the WD SAR file downloaded from Service Marketplace into a directory. To run WD, it`s then just to bootstrap it or run it with a given profile file. This installation method gives you a up and running WD in just one minute. The problem is that the files are all in one directory and not in the “official” directory structure of a normal SAP installation. But you get something like a portable WD installation: zip the directory and you can copy it to another server and can run WD from there.

The recommended alternative ensures that the WD is installed like a normal SAP product: all files follow the normal directory structure, etc. Installation is done using SWPM. Important when you are going to do some advanced configuration like PSE encryption, CryptoLib installation, etc. I`ll try to show how to install SAP Web Dispatcher the recommended way.

Download software

Download the needed software. It`s SWPM, Web Dispatcher, SAPCAR and HOSTAGENT.

SWPM

SAP Web Dispatcher 7.49 PL 112

SAPCAR 7.21

SAP Host Agent 7.21

Result

After you have downloaded all software, you have four files, summing up to almost 900 MB.

In a Unix environment, your WD system won`t have a graphical user interface and access to the system is given by SSH. This kind of environment can perfectly be emulated using Docker. Note: the SAR files need to be copied over to the target host.

Docker

There are several Linux images available for Docker. Let`s use Debian for this.

docker pull debian

For the actual image, see my Docker setup for Web Dispatcher: Dockerfile and docker-compose.yml: https://github.com/tobiashofmann/docker_webdispatcher_swpm

After running the Docker image, you have the files on the Linux system up and running, the Web Dispatcher and sapinst files available. Web Dispatcher is not yet installed. This is done by using sapinst. To run the installation, you`ll have to connect to sapinst using a different computer (most cases: your laptop). Let`s call the Docker container the target, and your computer the client.

Logon

I use Kitematic and to log on to my docker container, I just click on the EXEC button.

Logon to Docker container:

The log on from shell, the command is something like this:

bash -c "clear && docker exec -it dockerwebdispatcher_web_1 sh"

Target

To work properly, sapinst must be started as root. You then connect to it and log on. The logon is done by default with the user id running sapinst. Problem is that with the Docker images you do not know the root password. Same for environments where root access is only provided to a few or via sudo. You need to enable sapinst to run as root, but allow a different user (like <sid>adm) to log on. You achieve this by providing a parameter to sapinst informing the OS user allowed to log on remotely. The process is then:

  • Run sapinst as root (or sudo)
  • Connect to it informing a OS user (wddadm)

Sapinst Parameters

The needed parameter can be retrieved by letting sapinst show all available parameters. More information available in SAP Note 1745524 and at SAPinst central note.

./sapinst –p

Run sapinst in Docker

Provide the <sid>adm user as a property to sapinst.

./sapinst --properties SAPINST_REMOTE_ACCESS_USER=wddadm -nogui

Confirm that you know what you are doing.

Client

Start sapinstgui and connect to the target server on port 21212.

./sapinstgui

Inform the host name or IP address. In my case, it is 192.168.0.16. The port is the default sapinst port 21212.

Accept the fingerprint. You can check the fingerprint with the one printed by sapinst on the target server to be extra sure you are connecting to the right server.

Authenticate. You`ll need to provide the user id and password of the user running sapinst on the target host. In my case, the user is wddadm with password whatever. This is defined in the Dockerfile when the user is created.

sapinst output in Docker:

Logon on using wddadm / whatever

After a successful logon, sapinst will start. Current setup is not supported by SAP. For a production case this is a no-go, for my personal use case this is totally acceptable.

Sapinst shows the list of installable software options available. Web Dispatcher can be found at the end of the list.

Selecting SAP Web Dispatcher will start the installation.

Inform the path on the target server where the SAR files for SAP Web Dispatcher and SAP Host Agent can be found.

The files were copied into the container during the execution of the Dockerfile. All files are located at /home/wddadm.

If all packages are found, validated and added as considered valid for the installation.

Debian in Docker for sure won`t pass all the pre-requirements check build into SWMP. You`ll get a warning message, but SWMP won`t stop the installation. Select No. Seems that inside Docker, checking for the available free space is not working correctly.

Web Dispatcher configuration

Bootstrapping

Don’t worry, the system must not be accessible, yet exist. It’s just informing the bootstrap parameters. In my case, I am using a system that is not available, and it worked. Just be aware that in case the backend system changes, or isn’t even a ABAP system, like SMP3, you need to configure the Web Dispatcher profile manually.

Confirmation

Installation

The last step is to start Web Dispatcher. You can follow this on the console log of sapinst on the target server

If all worked, you get a confirmation message and the installation finishes.

SAPinst on the client host ends and so does it on the target host.

Validate installation

This gives you the time to validate the installation and check if all files are correctly installed.

Users

A new user sapadm was created

Folders

Web Dispatcher is installed under /sapmnt and instance is found in folder /usr/sap

This is perfectly aligned with the default locations of a SAP instance, and way better than simply putting all files into the same folder when unzipping the SAR. Especially when you consider that you may have to open a CSS ticket to SAP in your production environment or have new consultants arriving that expect the files to be located at the default location.

SAP Host Agent

The host agent was started and is running.

Start and stop Web Dispatcher

Starting and stopping Web Dispatcher via stopsap and startsap is working

stopsap

startsap

Admin web interface

The admin port of Web Dispatcher is listening by default on port 44300.

To access the service, the URL is

https://localhost:44300/sap/wdisp/admin/public/default.html

Log on to Web Dispatcher using the user webadm and password informed during installation.

Let the world know

Minimize a Docker image

Docker is great to get you started with a solution or to share your setup. A problem you may not be aware of at the beginning is the size of a Docker image. You start with a small base image like Debian, add your stuff and ready. This works perfectly when you only add a “simple” solution, like one that is available via apt-get. When you install a solution from scratch, with downloading code from GitHub, and do this using a Docker image, your image can grow to a significant large size. You will notice this when using a Dockerfile. Each RUN command creates a new layer. You are adding files to a previous layer, and to have a running Docker image, all layers are needed. This is great when you work intensively with Dockerfiles and images, as you can also revert to a previous layer, but when your resulting product is just having a solution installed and runnable, you can end up having an image too large for your needs.

You can see the different layers of an image when you pull it form Docker hub.

In my case, the pulled image had a size of 2.321 GB.

Minimize Docker image

A nice feature of Docker is that each container can also be an image. You can export a container to an image, without its history of layers attached to it. Therefore, this container serves as a minimized Docker image.

Start container

docker run –d –t tobiashofmann/openui5-rt:1.28

Container is started using the image tobiashofmann/openui5-rt:1.28 and the container ID is displayed. Next step is to transform the container to an image. To not type in the ID, I`ll get the human readable name of the container. Note: use option –name when starting the container and you can specify your own name

docker ps –l

Here the name of my running container is modest_lalande. To transform the container to an image, to command docker export is used. To create the image, the output is piped to docker import.

docker export modest_lalande | docker import – tobiashofmann/openui5-rt:1.28-min

The final size of the minimized docker image 2.118 GB. Close to 200 MB less. Not much here, given also to the content of the image and already low number of RUN commands in my Dockerfile. But when you have a human readable Dockerfile with several RUN commands, you can achieve a very good size reduction.

Let the world know

Docker images for OpenUI5

I created a set of Docker images that contain the OpenUI5 runtime library. They are available for download at Docker hub.

Why

Developing UI5 apps means to try out things and to support the final app. You may have the challenge to find out up to which library version your app works or when it is broken. For this, it is necessary to have a range of versions of the UI5 library available. OpenUI5 makes the latest supported version of their library available for download and there is also a CDN with a list of older releases. The CDN is the way to go when you have to do some backward testing as it also contains the SDK. To make use of an older UI5 version, just point to it. Example for 1.28.6: https://openui5.hana.ondemand.com/1.28.6/resources/sap-ui-core.js

To make use of the older releases, you must have internet access. That may not always be the case. In that case, you`ll have to download the resources. From the OpenUI5 project home you can right now download the latest version of 1.26, 1.28, 1.30 and 1.32. You can either download the SDK or runtime version or use the online version. But you`ll depend on what UI5 is offering online. This causes a problem when you have to do offline testing or the library version you need is not made available for download by OpenUI5. Having the libraries on CDN implies that you can access the CDN. Good luck for your CI builds or automated testing when you are behind a corporate proxy. Some CI setups also do DevOps, and when you have to reflect some operational configuration in your web server setup, you`ll have to set up somehow your own OpenUI5 environment. Something a CDN only supports partly.

What to do when you want to have the libraries available locally, in your intranet, on a computer without internet access or for your CI build? Easy: just download the files and host them on a web server like apache. This gives you still just one version of OpenUI5. Repeat this for each new version of OpenUI5 and over the years you`ll get a nice archive. To get a OpenUI5 library repository with all released version, you can make use of the fact that the project is open source and hosted on GitHub. And all versions tagged. It`s easy to build each historic version out of the git repository. Build it, put it into an apache www directory, and you can access it via a browser. This is easy, but takes some time.

To help you out with your OpenUI5 CI projects (or bug hunting, compatibility checks, etc), I created some Docker images. These images contain a set of OpenUI5 libraries and can be used in your CI setup or to try out OpenUI5 in a simple and easy way without having to install something besides Docker.

Docker image: openui5

Contains the latest released OpenUI5 library. The image is automatically build using my Docker file hosted on GitHub.

  • Size: 212 MB
  • Get image: docker pull tobiashofmann/openui5
  • Start container: docker run –d –p 50000:80 –t tobiashofmann/openui5 /usr/sbin/apache2ctl –D FOREGROUND
  • Access to libraries:
    • 1.32.9 (latest): http://<your docker server>:50000/resources
    • 1.30.11: http://<your docker server>:50000/1.30.11/resources
    • 1.28.25: http://<your docker server>:50000/1.28.25/resources
    • 1.26.16: http://<your docker server>:50000/1.26.16/resources

Docker image: openui5-sdk

Contains the latest OpenUI5 SDK. Compared to the above image, you get also the documentation, samples, etc, as well as the latest stable library.

  • Size: 165 MB
  • Get image: docker pull tobiashofmann/openui5-sdk
  • Start container: docker run –d –p 50000:80 –t tobiashofmann/openui5-sdk /usr/sbin/apache2ctl –D FOREGROUND
  • Access to libraries:

Docker image: openui5-rt.

Contains all openui5 library versions. The images is automatically build using my Docker file hosted on GitHub. Contains ALL OpenUI5 versions. You get >70 versions accessible via Apache. Each version is hosted under /<version>/resources. Example: /1.34.2/resources.

I had to face some Docker hub build restrictions, which impaired me to offer just one image. Right now I have one image for each minor tagged version (1.26, 1.28 -> 1.34). The images are cumulative. 1.26 gives you the version from 1.25 to 1.26, while 1.34 comes with all version from 1.25 up to 1.34. I guess in the near future I`ll also create images that only contain the versions of each minor release (only 1.28.*, but not 1.26.*).

  • Size: 1.34: 877 MB
  • Get image: docker pull tobiashofmann/openui5-rt:<tag>
  • Start container: docker run –d –p 50000:80 –t tobiashofmann/openui5-rt
  • Access to libraries:
    • 1.32.9 (latest): http://<your docker server>:50000/1.32.9/resources
    • 1.32.8: http://<your docker server>:50000/1.32.8/resources
    • 1.32.7: http://<your docker server>:50000/1.32.7/resources
    • You get the idea.
    • Oldest version: 1.25.0
Let the world know