はじめに

当ポートフォリオサイトをVPSサーバーにデプロイしました。念願の独自ドメインも取得し、感無量という感じです。
Herokuにデプロイしていたときとは違い、様々なエラーが頻発してかなり大変な道のりではありましたが、一皮むけて成長できたと思っています。

手順は下記ページを参考にさせてもらいました。

(初心者向け）vpsを契約して、capistrano3でRailsアプリをデプロイするまで [その1 サーバー設定編]
(初心者向け）vpsを契約して、Capistrano3でRailsアプリをデプロイするまで [その2 ローカル設定編]

本記事では上記ページの手順で詰まったところを中心に書いていきます。
上記ページが間違っているというわけではなく、バージョン違いや導入済みGemの違いなど、環境差異が存在するため仕方のないことです。
誰もが本記事のようなエラーが出るとは限らないし、まったく同じエラーが出たとしても本記事の対処法がうまくいくとも限りません。
あらかじめご留意願います。

MySQL:タイムゾーンの設定

「5-4 time-zoneを設定」セクションにおいて、MySQLの設定ファイル「my.cnf」にタイムゾーンの設定を末尾に追加するという記述があります。
しかし、次の手順でMySQLコンソールにログインしようとしたところで以下のようなエラーが表示されました。

$ mysql -u root -p
mysql: unknown variable 'default-time-zone=Asia/Tokyo'

MySQL: setting time_zone in my.cnf options file

>I'm not certain what has changed in Xampp, but this solution only works if you place this line in the proper place.

symbolic-links=0                   # 既存の行
default-time-zone = 'Asia/Tokyo'   # ここに挿入
log-error=/var/log/mysqld.log      # 既存の行

Gemfile.lockによるバージョン固定

ここから先はすべて下記コマンドでデプロイを行ったときに出たエラーになります。

$ bundle exec cap production deploy --trace

「--trace」オプションを付けるとより詳細なメッセージが見れるので付けることをおすすめします。

デプロイ中に出た最初のエラーは、正確なエラーメッセージは失念してしまいましたが、bundlerのバージョンに関するエラーだったと思います。
エラーメッセージで検索するとGemfileの以下の記述を削除すればいいというページがたくさんヒットしました。

BUNDLED WITH
  2.0.2

必要なGemのインストール

これも正確なエラーメッセージは失念してしまいましたが、エラーメッセージと一緒に対処法が書かれていたのでその通り実行しました。
デプロイ対象アプリに導入済みのGemが内部で使用している別のGemがあり、それらのGemをインストールする必要があるということだと思います。

$ sudo yum install libcurl libcurl-devel
$ gem install ovirt-engine-sdk -v '4.3.0' --source 'https://rubygems.org/'

$ sudo yum -y install gcc-c++
$ gem install unf_ext -v '0.0.7.6' --source 'https://rubygems.org/'

node.jsのバージョンアップ

node.js自体は「4 node.jsのインストール」にてインストール済みですが、デプロイ中にnode.jsのバージョンに起因するエラーが出たのでバージョンアップを行いました。

$ curl --silent --location https://rpm.nodesource.com/setup_7.x | bash
$ yum -y remove nodejs
$ yum -y install nodejs

curlコマンドでnode.jsのインストール元を設定した後、インストール済みnode.jsを一旦削除し、再度インストールし直します。

bundlerのインストール

デプロイ先サーバーにbundlerをインストールします。

rbenv exec gem install bundler

環境変数 or Credentialsの設定

画像のアップロード先にAmazon S3を設定していたりActionMailの設定を行っている場合、パスワードなどの値を環境変数、またはCredentialsに設定しているかと思います。
Capistranoを使ったデプロイでは環境変数の扱いが非常に複雑なので、Credentialsに統一することをおすすめします（Rails開発チームも推奨していると思います）。
ローカルでCredentialsの設定が完了していることを前提として、デプロイ先サーバーで以下の手順を行います。

まず、Railsアプリのデプロイ先ディレクトリにmaster.keyを作成します。

$ cd /var/www/Railsアプリの名前/current/config/
$ vi master.key
# ローカルのmaster.keyと同じ内容を記述

情報元によってはcurrent/config/ディレクトリ配下ではなくshared/config/ディレクトリ配下としているところもありますが、私の場合はcurrent/config/ディレクトリ配下でうまくいきました。

次に、環境変数「.bashrc」にSECRET_KEY_BASEを追記し、再読み込みを行います。環境変数「.bash_profile」ではうまくいかないので注意してください。

$ vi ~/.bashrc
...
export SECRET_KEY_BASE=xxxxxxxxxxxxxxxxxxxxxxxxx
$ source ~/.bashrc

SECRET_KEY_BASEの値はローカルで以下のコマンドを行って確認します。

$ EDITOR=vi rails credentials:edit
...
secret_key_base: xxxxxxxxxxxxxxxxxxxxxxxxx

別の確認方法もあるようです。
参考にさせてもらったページをご覧ください。

Railsプロダクション環境のsecret_key_base取得

最後に、config/deploy.rbのシンボリックリンクを張るファイルにmaster.keyを追加します。

set :linked_files, fetch(:linked_files, []).push('config/master.key')

secrets.ymlや環境変数をRails 5.2のEncrypted Credentialsに移行する

デプロイ完了

これにてようやくデプロイを完了することができました。
特に最後の環境変数にかかわるエラーには相当頭を悩まされ、一時は諦めることも頭をよぎりました。
Stack Overflowやteratailに質問を投げてみるも回答はつかず…
結局、独力で自己解決することになりましたが、その分デプロイがうまくいったときは本当に嬉しかったです。

Let's Encryptを使用したWebサーバーのSSL化

RailsでのAjax処理