System level management utilities

[campb303]

The API is separate from the from the frontend and at this time needs to be managed separately. Starting, stopping and restarting the API could be achieved by one of the following options:

1. Apache Control Script: Using the same control script presented to a user running web services on Templeton for controlling Apache, the API could be managed with the same commands and the Apache server it runs on. This has a benefit of being a unified interface and a drawback of requiring both services to be started, stopped and restarted at the same time.

2. User Level Cronjob: The API could be started by a cronjob run as the same user who controls the Apache web server with an @reboot job. This has a benefit of being automatic and a drawback of no subsequent control as the PID is lost.

3. Init System Hook: Templeton uses the SysV init system. The API could have its own service file for starting, stopping and restarting itself. This has a benefit of a decoupled yet accessible control interface and a drawback of permission restrictions. The web user would need to be given access to that service file.

[campb303]

After the initial webqueue2 demo, @cs and I discussed running the API on pier instead of templeton because the item files are actually stored on pier and the filesystem is exported to templeton just for webqueue. This could allow for significant performance increases. Additionally, pier has a more up to date version of Python and runs on CentOS 7 whereas templeton runs on CentOS 6.

This could work but will require the API to have a dedicated port on pier and a reverse proxy through Apache on templeton.

[campb303]

#45 is related to this.

[campb303]

A SystemD unit file should be written to start, stop, restart and monitor the API and docs site. The UI should be handled via Apache directly, though the unit file could launch the Apache instance for webqueue2

[campb303]

This depends on #121

[campb303]

This item should be used to track system level tooling. Below is a list of all things needed and what we have:

• Deployment script
  • Installation ability
  • Update ability
  • Build latest API docs
  • Build latest frontend docs
  • Generate .env file
  • .htaccess for API reverse proxy
• Init system integration
• Virtual environment manager
  • Virtual environment manager docs
• Consistent logging facilities
  • Sharable logging config
  • Integration with platform logging

[campb303]

Deployment scripts and consistent logging facilities should be next.

[campb303]

Updated list of things to do for installation/management utilities:

• Installer
  • Build latest frontend
  • Build latest frontend docs
  • Place built sites in production directory
  • Pull and run API
• Updater
  • Redo installer overwriting files

Second revision to include:

• Customized settings with persistence
• System init integration for API

[campb303]

The API has moved to its own repo and can be managed via pip. This issue now only tracks frontned deployment. Need to research frontend deployment methods. Fallback can be scripting the dev environment setup and build process with a bash script.

[campb303]

After looking at the Create React App deployment docs it seems there is no standard way to deploy a CRA based application. Potential options are:

• Create a script (Python or bash) to:
  1. Checks for the project requirements (node, npm and git)
  2. Pull latest git master branch
  3. Installs node modules
  4. Builds the frontend
  5. Move the frontend to a specified directory
  6. Configure the webserver (?)
• Leave instructions for doing all of the above manually

This can be left for a last step.

[campb303]

This will be addressed by build steps being placed in the project readme.