|
|
|
### 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
|
|
|
|
|
