refactor app startup

[candyhazlett]

Currently, app starts rails with a series of steps that include Apache, Passenger and Capistrano. Ideally, the app starts using Puma (the latest version possible), and startup jobs are handled with Rails' built-in ActiveJob then monitored with Redis.

to do:

• Replace Passenger w/Puma

Review is needed for the following:

• Would this switch impact the app's API-related functions?
  • how distinct is the API functionality from the app? i.e., is it sufficiently distinct that it should be treated as its own app rather than an extension of TAPAS?
  • what is the primary consumer of the API and what is the normal volume of requests?
  • currently Drupal frontend makes the API get requests, and that functionality won't be needed once Rails app replaces Drupal
  • API requests to XML db (BaseX) will still be part of functionality, code exists currently but requires review/refactor
  • what ui/ux event triggers calls?
  • Rails will eventually call BaseX for updated view packages list
  • But for near future, app will send post requests to BaseX almost exclusively
• Explore (potentially) replacing Capistrano scripted tasks with built-in Rails jobs and Redis monitoring
• What specific tasks does Capistrano do?
• If these are all startup related:
  • Is this worth refactoring them as Rails jobs if they work sufficiently well?
  • What’s the maintenance overhead look like?
  • lower maintenance with fewer libraries/dependencies
  • How much work would be required?

[candyhazlett]

to switch from passenger/capistrano -> puma/nginx

• [x] uninstall:
  • [x] passenger
  • [x] capistrano
• [x] install:
  • [x] puma gem
  • [ ] nginx
• [x] configure
  • [x] puma configuration to use env vars as named in AWS
  • [x] ssh into AWS EC2 or use the admin console to locate env vars that will have to be defined in app for puma and nginx

[candyhazlett]

All items completed except for nginx install, as the AWS EC2 instance has it installed already.