Running LeApp's stateful containers on OpenShift

It's a common understanding that containers are conceptually stateless. In other words, all the data that has been mutated throughout the container life will be lost once the container is stopped. One of the drawbacks of this approach is that containerized applications must store their data outside the container if it must be persisted.

There are approaches that could be used to persist data in containers, though. The preferred mechanism is using volumes, where external locations can be mapped and accessed from inside the container. Containerized applications can safely persist their data in those shared directories.

However, LeApp macrocontainers don't run only a single application. Since they may be originated from a production system, they might contain several applications that require persisting data. For instance, it's not unusual for a system to contain the complete LAMP stack, where files and the database are frequently mutating.

That being said, the multivolume solution we described in our stateless document can be adjusted to achieve statefulness in macrocontainers. This document describes the additional steps to achieve that.

Please, check out our stateless document if you intend to run containers generated by LeApp in a stateless manner.

Example of stateful applications

• Databases
• File servers
• HTTP and FTP servers

LeApp to OpenShift migration

The overall procedure to get a LeApp stateful container running on OpenShift is as follows. LeApp should be used to migrate a given source machine to a container in a given target machine. Then a helper script should be executed in order to generate the OpenShift template files. After some tweaks in OpenShift, the stateful container can be finally created. Below steps describe this procedure in more details.

Requirements and assumptions

• OpenShift up and running on target machine
• Privileges to create and mount emptyDir and hostPath volumes in target machine
• Single-node OpenShift cluster

Migration process

Step 1) Migrate machine using leapp tool

# leapp-tool migrate-machine --container-name leapp-migrated-container <source-ip-or-hostname> 

Step 2) Generate OpenShift templates

Run this helper tool and generate the OpenShift templates.

Example:

$ sudo ./cli.py stateful \
    --tcp 9022:22 80:80 \
    -c leapp-migrated-container \
    --service-account useroot \
    --load-balancer useroot \
    --dest ~/templates

Storing templates to: ~/templates

$ ls -1 ~/templates

Dockerfile
leapp-migrated-container-pod.yaml
leapp-migrated-container-svc.yaml
leapp-migrated-container-storage.yaml

Step 3) Create OpenShift user and project

The safest approach is to create a separate user and project

oc login -u user
oc new-project demo-project

Step 4) Allow privileged processes in OpenShift

By default, OpenShift doesn't allow any process to run as root within the containers. Containers generated by LeApp need at least to execute the system initializer, e.g., systemd, upstart etc. To overcome this limitation, the following command could be used:

$ oc adm policy add-scc-to-user anyuid -z default

This will relax the default setting that prohibits containers running as root. This, however, will affect the whole cluster configuration. This might not always be desired, so a better approach would be to create a new Service Account and relax the setting only for it:

$ oc create serviceaccount useroot
$ oc adm policy add-scc-to-user anyuid -z useroot

Step 5) Change SELinux security context of macrocontainer files

It's necessary to change the SELinux security context of the files from the macrocontainer generated by LeApp. Otherwise, OpenShift won't be able to start the container.

# chcon -R -t svirt_sandbox_file_t -l s0 /var/lib/leapp/macrocontainers/migrated-container

Step 6) Create and run the container, services and storage

First of all, let's use the system user so we are allowed to create Persistent Storage resources in OpenShift.

$ oc login -u system:admin

The command below creates the Deployment, the Services, PersistentVolumes and PersistentVolumeClaims necessary:

$ oc create -f ~/templates

Step 7) (Optional) Destroy the intermediate container

$ leapp-tool destroy-container leapp-migrated-container

Known issues

For a list of known issues and debugging tips, check the Known issues and Debugging section from our stateless document.