解決したいこと

railsの環境ごとに正しいDBを参照するように設定をしたいです。

現状、以下に記載したとおりに環境構築を行い、staging環境と本番環境をubuntuに作成しました。
そして、capistranoを使用し、
bundle exec cap production deploy
bundle exec cap staging deploy
コマンドでのデプロイができるようになった状況です。

しかし、productionでデプロイした方のドメインからアクセスすると、staging環境のDBを参照してデータが表示されてしまいます。
DB以外にも、以下のような分岐をapplication.html.hamlに埋め込んで確認したところ、「ステージング環境のテキスト」が表示されます。

- if Rails.env.development?
      開発環境のテキスト
    - elsif Rails.env.test?
      テスト環境のテキスト
    - elsif Rails.env.staging?
      ステージング環境のテキスト
    - elsif Rails.env.production?
      本番環境のテキスト

このとき、production環境では本番用のDB(以下のproduction_db)を参照するように設定を行いたいです。
他にどのような設定が必要なのか？もしくは間違った設定をしている部分があれば、どのように修正すべきかご教授いただきたいです。

初歩的な疑問かもしれず大変恐縮ですが、皆様のお知恵をお貸しいただけますと幸いです。
以下に記載した分以外では追加したファイルはないはずですが、他に必要な情報等がありましたらお教えください。

環境

Ruby on Rails 5.2
Ruby 2.6.2
Capistrano 3
nginx
ubuntu16.04
staging、production用のドメインはそれぞれ取得してhttps化もLetsEncryptで済ませてnginxで設定している。

問題に至るまでの経緯

こちらのリンクの方のデプロイするまで1~2
を参考にcapistranoとunicorn nginx の設定を行っています。（ubuntuのため、一部違う部分がありますが）

その他に、capistranoでstaging環境構築
こちらも参考に以下のように設定ファイルを編集しました。（下記以外は基本的に上記のURLの設定と同じ）
stagingとproduction環境は同じファイルディレクトリを参照しています(var/www/myapp/current)

environment/staging.rb

config.action_mailer.default_url_options = { :host => 'http://staging.com' }(stagingのドメイン)

※他はproductionと一緒

deploy/staging.rb

set :stage, :staging
set :rails_env, 'staging'
server 'staging.com', user: 'aaa', port: '33333',
       roles: %w{web app db}
set :ssh_options, {
    keys: [File.expand_path('秘密鍵のパス)')]
}

deploy/production.rb

set :stage, :production
set :rails_env, 'production'
server 'production.com.', user: 'aaa', port: '33333',
       roles: %w{web app db}
set :ssh_options, {
    keys: [File.expand_path('秘密鍵のパス)')]
}

database.yml

staging:
  <<: *default
  database: staging_db
  username: <%= ENV['DATABASE_NAME'] %>
  password: <%= ENV['DATABASE_PASS'] %>

production:
  <<: *default
  database: production_db
  username: <%= ENV['DATABASE_NAME'] %>
  password: <%= ENV['DATABASE_PASS'] %>

config/secrets.yml

staging:
  secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>

production:
  secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>

ubuntu内
www/myapp/shared/config/secrets.yml

production:
  secret_key_base: 0000~（ランダム数列）

staging:
  secret_key_base: 0123~（ランダム数列）

gemfile

group :production, :staging do
  gem 'unicorn'
end

追加補足

/etc/nginx/conf.d/lcoin.conf

#各種ログのディレクトリ設定
  error_log  /var/www/myapp/current/log/nginx.error.log;
  access_log /var/www/myapp/current/log/nginx.access.log;
#処理を受け取る最大許容量
  client_max_body_size 2G;
  upstream app_server {
# 連携するunicornのソケットのパス
    server unix:/var/www/myapp/current/tmp/sockets/.unicorn.sock fail_timeout=0;
  }
  server {
    listen 443 ssl;
    server_name staging.com;
    ssl_certificate     /etc/letsencrypt/live/staging.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/staging.com/privkey.pem;
#次のリクエストが来るまでの待ち時間（秒
    keepalive_timeout 45;
#静的ファイルを読みに行くディレクトリ
    root /var/www/myapp/current/public;
#キャッシュのディレクトリ
    try_files $uri/index.html $uri.html $uri @app;
    location @app {
      # HTTP headers
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-FORWARDED_PROTO https;
      proxy_set_header Host $http_host;
      proxy_redirect off;
      proxy_pass http://app_server;
    }
#エラーページを設置する場所
    error_page 500 502 503 504 /500.html;
    location = /500.html {
      root /var/www/myapp/current/public;
    }
  }
server {
    listen 443 ssl;
    server_name production.com;
    ssl_certificate     /etc/letsencrypt/live/production.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/production.com/privkey.pem;
#次のリクエストが来るまでの待ち時間（秒
    keepalive_timeout 45;
#静的ファイルを読みに行くディレクトリ
    root /var/www/myapp/current/public;
#キャッシュのディレクトリ
    try_files $uri/index.html $uri.html $uri @app;
    location @app {
 # HTTP headers
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-FORWARDED_PROTO https;
      proxy_set_header Host $http_host;
      proxy_redirect off;
      proxy_pass http://app_server;
    }
#エラーページを設置する場所
    error_page 500 502 503 504 /500.html;
    location = /500.html {
      root /var/www/myapp/current/public;
    }
  }

行動規範の内容に同意します

回答1件

ベストアンサー

stagingとproduction環境は同じファイルディレクトリを参照しています(var/www/myapp/current)

このようにしている意図は何でしょうか？

投稿2019/05/04 11:12

退会済みユーザー

総合スコア0

ManaKuri09

2019/05/04 11:52

意図というよりかは、このサイトのconfig/deploy.rbの記載にあるように、デプロイ先は分けずに環境構築をしていたというのが正直なところです。 https://qiita.com/hayashier/items/606910ceccf7cc782052 もしできるのであれば、デプロイ先(deploy_to)を環境ごとに分けたほうが良いという感じなのでしょうか？

退会済みユーザー

2019/05/04 11:57

同じサーバの同じディレクトリにデプロイしているということは、stagingをデプロイしたらproductionが上書きされる（またはその逆）ということと文章からは読めました。 productionからstagingのデータベースが見られてしまう、ということからもそう感じました。もし上記のようでないとしたら、具体的なサーバの構成を書いていただけると解決につながりやすいと思います。

ManaKuri09

2019/05/05 07:04

こちらの件、状況としてはそのような感じです。デプロイ先はstaging,productionともにvar/www/myapp/currentになっています。ちなみに、nginxは上記に補足で追加しました。具体的なサーバの構成と申しますと、あと、どんな情報があると助かりますでしょうか？

退会済みユーザー

2019/05/05 07:25

nginxやデータベース、そしてRailsアプリケーションはそれぞれ別々のサーバにあるのかどうか、ということです。例えば、192.168.160.1にnginx、192.168.160.2にデータベース、192.168.160.3にRailsアプリがあるというふうにです。ただ、話を伺ったところ、これらは全て一つのサーバにあるようです。そしてstagingとproductionも同居していて、さらにその2つの環境のディレクトリが一緒と推測します。結論としては、productionのデプロイが反映されていない、ということになると思われます。その理由を調べるのもよいかとは思いますが、stagingとproductionのデプロイ先をディレクトリ単位で同じにするということは相当に特殊な例かと思います。一般的には、productionはユーザに常に公開している環境です。 stagingは開発環境やテスト環境で、内部からしかアクセスできないのが一般的です。 stagingに開発中の内容をデプロイし、問題ないことを確かめてproductionにマージしてproductionをデプロイするというのがこれまた一般的かと思います（必ずしもそうではないです）。したがって、直接の原因である「productionのデプロイが反映されていない」原因を探るよりかは、「stagingとproductionのデプロイ場所を別々にする」のがスマートな解決法かと思います。

ManaKuri09

2019/05/08 06:44

回答ありがとうございます。理想はやはりデプロイ先を分ける方であったので、ディレクトリを分けてデプロイすることにしました。 nginxも、ドメインごとにupstreamで矛先をstaging，productionのファイルを見るように設定を変更したところ、それぞれで正しく反映されました。

行動規範の内容に同意します