質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

90.32%

staging環境を作ったあとに、production環境をデプロイするとstagingのDBを見てしまっている

解決済

回答 1

投稿 編集

  • 評価
  • クリップ 1
  • VIEW 220

ManaKuri09

score 11

解決したいこと

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;
    }
  }

                                                         

  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

回答 1

checkベストアンサー

0

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

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2019/05/05 16:04

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

    キャンセル

  • 2019/05/05 16: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のデプロイ場所を別々にする」のがスマートな解決法かと思います。

    キャンセル

  • 2019/05/08 15:44

    回答ありがとうございます。
    理想はやはりデプロイ先を分ける方であったので、ディレクトリを分けてデプロイすることにしました。

    nginxも、ドメインごとにupstreamで矛先をstaging,productionのファイルを見るように設定を変更したところ、それぞれで正しく反映されました。

    キャンセル

15分調べてもわからないことは、teratailで質問しよう!

  • ただいまの回答率 90.32%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる