How to Deploy your rDSN applications(Linux version)

In the project of rDSN, all operations, like building and deployment, can be manipulated in one scripts run.sh at the source code's top directory.

As follows, the deployment consists of two major phases:

• Publish -- prepare necessary binary and configuration files of the deployment unit.
• Deployment -- the actual phase of deployment including deployment and undeployment.

Orthogonally, the deployment can be applied in three deployment environments:

• Pure Linux
• Pure Docker over Linux
• Kubernetes over Docker

This tutorial is organized as such:

• Section 1 for Pure Linux
• Section 2 for Docker
• Section 3 for Kubernetes

And in each section, it is organized according to the two major phases--Publish and Deployment.

All below are tested on Ubuntu 14.04 successfully.

To publish the deployment unit, just type

run.sh publish -b <build directory> -t <target directory> -d <deployment name>

• build directory is the directory you build the whole project, which by default is builder in the top directory.
• target directory is the directory you want to publish in. The directory is an important input for deployment in the next step.
• deployment name the name of deployment unit. For every deployment unit, you can write a specific scripts in the name form of publish.<deployment name>.sh, which specify the binary and configuration files needed for deploy on the remote machine and the specific start.sh scripts for the start commandline to be run on the remote machine. In the source code, we got an example scripts for simple_kv in scripts/linux/publish.simple_kv.sh

There is another subcommand republish with the sames options whose function is republish literally without changes to machinelist files and configuration files if already existed.

Before deploy your deployment units, you need to write some machine list file to specify at what machines running what app. machine list files are files in the name form of {app name}list. In it, there are lines of machine ip in the form of username@hostname. And you put these files in the directory of target directory mentioned in the previous step.

To deploy the deployment unit, just type

run.sh deploy|start|stop|clean -s <source directory> -t <target directory> -d <deployment name>

The subcommand are divided into two groups:

• 1. deployment
• deploy transfer the directory as a whole to the target remote machine according to machine list files
• start start the start.sh on the remote machine, which start your binary in self-contained manners.
• 2. undeployment
• stop stop the application using scripts stop.sh on the remote machine.
• clean clean the files transferred before.

All below are tested on Ubuntu 14.04 successfully.

run.sh publish_docker -b <build directory> -t <target directory> -d <deployment name>

• build directory is the directory you build the whole project, which by default is builder in the top directory.
• target directory is the directory you want to publish in. The directory is an important input for deployment in the next step.
• deployment name the name of deployment unit. For every deployment unit, you can write a specific scripts in the name form of publish_docker.<deployment name>.sh, which specify the binary and configuration files needed and build a Docker image named in the form of <docker_repo>/<deployment name> from them, and the specific start.sh scripts for the start commandline to be run docker container on the remote machine. In the source code, we got an example scripts for simple_kv in scripts/linux/publish_docker.simple_kv.sh.

There is another subcommand republish_docker with the sames options whose function is republish literally without changes to machinelist files and configuration files if already existed.

the same as Section 1.2

the same as Section 2.1

After Setting up a Kubernetes Cluster and put the kubectl in the PATH, just type

run.sh k8s_deploy|k8s_undeploy -s <source directory> -i <instance name> 

• source directory, where subcommand [re]publish publish the deployment unit

• instance name, since one deployment unit can be deploy multiple times, resulting in multiple instances to one deployments. We thus need one instance name to distinguish among them

• image is the Docker image name we get in the previous step of publish_docker