Using production like development mode

Contents

1. About
2. Create cluster
3. Build cluster components
4. Deploy cluster
5. Test cluster
6. One-liner for impatient developers
7. Next steps

About

We are now having all the REANA source code repositories cloned on our system. This page describes how to build REANA cluster from the sources in production-like mode, exactly as it would be deployed in production clusters. This mode is therefore especially suitable for integration testing.

Create cluster

We start by creating Kubernetes-in-Docker cluster, taking advantage of reana-dev helper script again. At the same time, we'll create and mount local directory /var/reana into the Kind cluster. This will be the place where REANA will store all the user workflows in the Kind cluster, and mounting a local directory there will facilitate its inspection.

$ sudo mkdir /var/reana
(reana) $ reana-dev cluster-create -m /var/reana:/var/reana

Note that you can also deploy the cluster in a mode that would disable Kind networking by supplying an option --disable-default-cni to the above command. This is useful for working with network policies. You will have to install another CNI provider such as Calico:

$ kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.24.2/manifests/tigera-operator.yaml
$ kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.24.2/manifests/custom-resources.yaml

Build cluster components

Now that cluster is created, let's build all the cluster component docker images:

(reana) $ reana-dev cluster-build

This may take considerable amount of time the first time. It'll be speedier once your local Docker cache is populated with previous layers.

To save some time, you can also build multiple Docker images in parallel:

(reana) $ reana-dev cluster-build --parallel 8

Most of the time, you do not need the following 3 images during development: r-a-krb5,r-a-vomsproxy,r-a-rucio.

Therefore, you can exclude them when building the cluster.

(reana) $ reana-dev cluster-build --exclude-components=r-a-krb5,r-a-vomsproxy,r-a-rucio --parallel 8

Deploy cluster

The cluster is created and the components build; we can proceed to deploying the cluster. Let's use [email protected] as the cluster administrator email address and mysecretpassword as the administrator password:

(reana) $ reana-dev cluster-deploy --admin-email [email protected] --admin-password mysecretpassword

This should complete the cluster deployment.

Test cluster

We can now set up environment variables with proper REANA_SERVER_URL and REANA_ACCESS_TOKEN corresponding to the deployed cluster administrative account by doing:

(reana) $ eval $(reana-dev client-setup-environment)

After which we can run our first example using reana-dev:

(reana) $ reana-dev run-example -c r-d-helloworld

Or, use reana-client CLI tool and one of the demo examples:

(reana) $ reana-client run -w helloworld-demo

For more details on reana-client, check our user documentation.

One-liner for impatient developers

Note that the above steps can be fully automatise and run in a human non-assisted way by using the following one-liner:

(reana) $ reana-dev run-ci -m /var/reana:/var/reana \
            -c r-d-helloworld \
            --exclude-components=r-a-krb5,r-a-vomsproxy,r-a-rucio \
            --admin-email [email protected] \
            --admin-password mysecretpassword

This command is helpful to use from time to time as a general CI integration test, or to bootstrap a local REANA development instance rapidly.

Next steps

Note that the reana-dev command has intensive --help description that shows a lot of commands to use in the production-like oriented environments. You may use them later when testing pull requests. Please read the help page:

(reana) $ reana-dev --help

to familiarise yourself with what options are typically possible. You don't have to test them all in detail; you'll simply use them progressively later on during the REANA developer journey.

Would you be interested in seeing how you can change the code and rebuild and redeploy and retest the cluster? This is also easily possible in production-like development mode, and is covered elsewhere. However, it is usually preferred to deploy the cluster in another, more developer-friendly mode, described in Using live-code-reload and debug mode.