Seth Tucker

This could be a few things--but first, did you make sure to include the bundler plugin for Capistrano? It should be fetching all of your gems for you on the server during deployment. It's part of the setup instructions, so as long as you copied what was in the setup steps then you should be fine.

Do you have the gem 'did_you_mean' in your gemfile as only needed in Development or just not available in production?

Correct, every time you want to update your application in production you will have to run the command cap production deploy

Capistrano is not an automated deployment solution in the sense that just pushing updates to git will trigger a deployment.

I use Passenger's pre-start feature. You have to define it OUTSIDE of a server block, like this:

server {
    listen 433 ssl http2;
    server_name www.example.com;

   [other NGINX server block code goes here]...
}

passenger_pre_start https://www.example.com;

Now every time Nginx restarts, it'll also restart the www.example.com site. This works pretty well for the single server setup in the deploying to production guide. It's more tricky if you have a cluster and/or are using the proxy_protocol.

This video came out at the perfect time--I just started splitting up my public/private controllers to lighten up the assets required to view amd interact with my website, and I was having a hard time splitting things up correctly. Thank you for the clarity!

I'm leary about updating the latest version of Ruby so quickly. I did this early last when I was just learning, but I've found out that each version has it's own quirks and it's a lot better to stay slightly behind, unless you've got a really good scenario where the latest and greatest updates really help you. When I looked at the updates to 2.7 vs 2.6.5, it wasn't enough to make me jump on doing a ruby upgrade.

FYI the answer is because all environment variables get loaded, even if it's not in that environment. You're better off using the secrets.yml for easier credential management.

You might get the same error message as before until you run bundle install

Since it looks like you're also upgrading your rails version, I highly suggest you stick with the version you had and figure out why bundler is having an issue. I've had a few situations where the bundler version gets stuck on the previous version. When I run bundler -v I actually get Bundler version 2.02. Just make sure what you see on your local machine matches what appears on your server.

Typo on my part, it should be ruby-2.6,1 should go into a .ruby-version file.

You are only using rbenv or rvm and not both at the same time, correct?

No, you need to gem update --system to update bundler. The bundler message is not an error, it's just a warning. I get this often but everything works. I think your Gem::LoadError is something else like mismatched ruby versions.

Your post shows Ruby 2.6.1, is that the same version that's installed on your local machine? Have you also set it in the gem file by adding ruby 2.6.1 and have you also created a .ruby-version file and added ruby-2-6-1 to make everything match?

The Postgres error looks like the service isn't running on the server. You can check the status by running sudo service postgresql status on the server. It should print out a bunch of lines, one will say something like 'Active: active (exited) since Tue 2019-06-25 18:12:36 UTC; 1 months 21 days ago'

I've solved this before by just logging into the server and updating the gems, then trying to deploy.

It says the host IP address is "1.2.3.4" so that looks like a misconfiguration in your deploy.rb or the development/production.rb file

Here's a good explanation for both the CLI and web interface way to add environment variables to protect your API key: https://devcenter.heroku.com/articles/config-vars

Always protect API keys! :) Especially so they don't end up on Github and possibly exposed to the world.

Well, use an environment variable to store keys so they aren't in your code anywhere. You can do this with Heroku or a Digital Ocean droplet very easily. Easier to do on Heroku thank a droplet.

As far as when the app itself is communicating with Shopify, use an SSL connection if they have one available (which I'm pretty sure they do). The key itself has to be available in the request for you to authenticate the request and I don't think encrypting it outside of SSL will allow you to work with the API.

@leopauld The service is probably already running. Did you try running the systemctl status nginx to see if it's already running and what the output is?

Have you checked the table to see if the 'environment' key has been set? This is a fail-safe for Rails apps to make sure that you aren't wiping out a production database by accident.

I had an interesting thing happen after following this. The instructions were PERFECT because I could not get Nginx or Apache to work with Puma on the production server after from DigitalOcean. So thank you very much for this guide!

Now I have an interesting issue. After successfully going through this guide, I tried running 'rails s' locally and kept getting the error: (erb):18:in fetch': key not found: "DATABASE_USER" (KeyError)

I thought that was strange, because it looks like it's trying to use my production database values rather than the development. I did confirm in my puma.rb file that it's set for the development environment.

I tried commenting out my DB username and pw fields as shown below but I was still getting the same error.

Here's my database.yml file:

# SQLite version 3.x
#   gem install sqlite3
#
#   Ensure the SQLite 3 gem is defined in your Gemfile
#   gem 'sqlite3'
#
default: &default
  adapter: postgresql
  pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>
  timeout: 5000

development:
  <<: *default
  database: db/development
  username: seth
  password: 

# Warning: The database defined as "test" will be erased and
# re-generated from your development database when you run "rake".
# Do not set this db to the same as development or production.
test:
  <<: *default
  database: db/test

production:
  adapter: postgresql
  pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>
  timeout: 5000
  #username: <%= ENV.fetch("DATABASE_USER") %>
  #password: <%= ENV.fetch("DATABASE_PW") %>
  database: consumer_law

For now I've just deleted the username and password lines from the file and I'm able to successfully run 'rails s' and get Puma working locally again. It does explicitly show in the startup output that it's set to use the development environment settings.

Any ideas why it's trying to use my production username and password fields in development?

Yes it does, but I think adding the Trix gem to rails 5.2.2 may solve the problem.

Haven't tried it though, all of my apps have been upgraded to 6.0.0RC1 so far.