Question
How to point Nginx to serve Capistrano deployment location (/home/rails/apps/appname/current) on Rails one click application?
- Posted on November 4, 2018
- Ruby on RailsNginxUbuntu 18.04
Asked by LProof
Hello,
I have set up a Rails one click application and have configured Capistrano to deploy to /home/rails/apps/appname/current. All of the files are present and there are no errors during deployment. Before I setup Capistrano I explored the Nginx files in /etc/nginx/sites-enabled and /etc/nginx/sites-available. Following this tutorial (https://www.digitalocean.com/community/tutorials/deploying-a-rails-app-on-ubuntu-14-04-with-capistrano-nginx-and-puma), I have created a symlink to an nginx.conf file stored at /home/rails/apps/appname/current/config.nginx.conf to exist at /etc/nginx/sites-enabled/sites-enabled/appname. However, when I visit my site via its IP or domain, I get a simple “connected refused” error, telling me that the nginx server isn’t pointing to the right place.
My question is this: given that the Rails one click app originally launches using /etc/nginx/sites-enabled/rails (the configuration there is what makes the example Rails app work), is this somehow interfering with the symlink to the nginx.conf file I’ve created with Capistrano? I am quite confident that everything is correct on the Capistrano side (it is an exact copy of the nginx.conf from the tutorial linked above with my app and server details in the relevant places) and that the issue is with the pre-popualated files at various places within /etc/nginx/*.
There is another issue which I think might play a role: the Rails one click app boots via /etc/systemd/system/rails.service, and within that file there’s a call to puma. Is this a case of nginx not recognising or reading the .conf file defined within the app I’ve deployed, an issue with rails.service pre-defined by the one-click app, or something else? In short, I am wondering whether the defaults setup in the one-click are taking precedence over the Capistrano files I’ve deployed.
Many thanks for any help.
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.
Get our biweekly newsletter
Sign up for Infrastructure as a Newsletter.
Hollie's Hub for Good
Working on improving health and education, reducing inequality, and spurring economic growth? We'd like to help.
Become a contributor
Get paid to write technical tutorials and select a tech-focused charity to receive a matching donation.
Update: it turns out I needed to reboot the droplet and puma. I ran
sudo rebootwhilst SSHed into the droplet, followed bycap production puma:restartlocally, and my site suddenly appeared. I couldn’t find this information related to my question so I’ll leave it here in case it helps anyone else.It seems the combination of restarting the droplet and puma is what is needed to allow the new nginx configuration to take hold.
For clarity, these are the steps I took to move from the default installation one-click Rails application with the example app at /home/rails/example to a capistrano-based deployment running from /home/rails/apps/appname, where appname is your app:
sudo ln -nfs "/home/rails/apps/appname/current/nginx.conf" "/etc/nginx/sites-enabled/appname". (Apparently it’s important to use the absolute path for this.)sudo rebooton the droplet.cap production puma:restartlocally.This should allow you to deploy from Capistrano locally with
cap production deployand not have to fiddle with the nginx files on the droplet. This workflow is compiled from probably a dozen different tutorials and posts elsewhere, so I hope this helps someone trying to deploy a Rails app to production on DigitalOcean using Capistrano.