Skip to content
Snippets Groups Projects

How app sharing works

Last edited by Eric Franz

1. Apps are launched from the dashboard

Go to https://apps.awesim.org/devapps and you'll see a list of apps grouped by the Provider (white background). These are all shared apps.

  • the username of each provider is displayed in parentheses - all shared apps are shared by user accounts at OSC
  • the shared apps are deployed to the provider's home directory under $HOME/awesim_shared_apps; so for example, "ANSYS Workbench" is shared by awe0011 and is deployed to /nfs/12/awe0011/awesim_shared_apps/ansys_workbench

2. Each user has a dedicated Apache server

Shared apps run as that user using their own Apache server, so multiple users use can use the same application code but with their own data.

A. One code base, multiple web servers

Each user has her own Apache server (running as her) and it serves:

  • the dashboard for launching apps
  • each app a user launches through the dashboard

B. Separate data per user

Shared apps follow the http://12factor.net/config convention of moving configuration into the environment. The RAILS_DATAROOT environment variable stores the path to the directory where user data for that app is located. This path is different for each user due to the fact that by default $RAILS_DATAROOT is set to $HOME/awesim_data/$PROVIDER/$APP where $PROVIDER is the user who shared the app and APP is the app's directory name. Shared apps use `RAILS_DATAROOT` to know where to write data to.

$RAILS_DATAROOT is set in .env.production file in the root directory of the shared app. This is created when running awesim setup and the awesim_rails gem enables accessing this value via AwesimRails.dataroot for ease of use. This is why the dotenv-rails and dotenv gems are required.

In the future we will use this same mechanism of setting configuration in the environment to support shared data for groups of users.

3. Launching an app first initializes the user's database

When a user clicks on the link to a shared app in the dashboard, the request is made to the dashboard to open the app:

  1. Dashboard verifies app exists and user has access to it
  2. Initializes access to app (via symlinks, etc. required) if this hasn't been done
  3. Runs the app's bin/setup-production script if it exists and displays error page if script exits with error code (at this point the user could still go to the app but they would see a warning first)
  4. Redirects the user to the application end point, which starts the Passenger app

For shared Rails apps with a database, the default bin/setup-production:

  • creates the data root if it doesn't exist
  • creates the sqlite3 database if it doesn't exist
  • checks an existing sqlite3 database and it's migration status against the migrations of the app's code