You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 5, 2019. It is now read-only.
Looks like we'll use Capistrano for Rails deployment. Remaining questions:
What web server stack should we use? Apache / unicorn / puma / Passenger etc.?
Which port should the Rails web UI run on, and should it be public?
Which port should the Rails API (including online API docs) run on, and should it be public?
Should we aim to make more than just the React frontend available from port 80?
Should we set up a api.ministersundertheinfluence.co.uk vhost for the API?
Acceptance Criteria
This story can be considered done when the following is satisfied:
Given the DigitalOcean server is configured, When I visit http://ministersundertheinfluence.co.uk Then I get the React frontend UI, showing live data from the Rails backend
The text was updated successfully, but these errors were encountered:
@Greatlemer I'm still not sure about the Apache / unicorn / puma / Passenger / whatever decision. I've just emailed @JohnSmall who probably knows more about this, so hopefully he'll respond soon.
I found the OneClick Rails app provided by Digital Ocean to be very tied into a specific way of doing things specifically
It assumes you're going to be deploying via SFTP or a single main branch from a Git repo
RVM was setup for the system, not for the rails user. Which causes some irritations when installing gems
The configuration for nginx and unicorn is spread over many configuration files and bash scripts and quite tricky to modify it to work with a different directory that's using Capistrano deployment.
After a full weekend messing around with the configuration a few weeks ago. I threw my hands in the air and set up a trial system using Nginx and Phusion Passenger on a bare bones DO droplet, in less than an hour.
I created a script and by running it on many bare DO droplets I've refined it into a gist to be run against a DO droplet which configures everything just right to accept a Capistrano deployment from the /src/ruby/meetings directory.
And I've also got a snapshot of the droplet I created I can send to you and you can replace the droplet with the new configuration. It has a functioning Rails app running on it and can be updated via
`cap production deploy`
I'll be checking in the branch I used for to get Capistrano working with this, and create a PR for it.
Description
We now have http://ministersundertheinfluence.co.uk up and running, with a Rails droplet deployed; however we haven't deployed any of our code on it yet.
Comments, Questions and Considerations
Looks like we'll use Capistrano for Rails deployment. Remaining questions:
api.ministersundertheinfluence.co.uk
vhost for the API?Acceptance Criteria
This story can be considered done when the following is satisfied:
Given the DigitalOcean server is configured,
When I visit http://ministersundertheinfluence.co.uk
Then I get the React frontend UI, showing live data from the Rails backend
The text was updated successfully, but these errors were encountered: