Railsアプリケーションをデプロイした時の手順まとめ第３弾です。
Railsアプリ〜デプロイへの道〜はこの記事でいったん完結します。

今回はnginxのインストールからCapistrano3の設定、デプロイまで一気に紹介するので、
今までよりボリュームが多いです。
てんこ盛りです。

前回、前々回同様こちらの記事がベースとなっています。 
https://qiita.com/ryo2132/items/f62690f0b16ec11270fe

これまでの記事同様、この記事は基本的に手順を記したものなので（僕の理解が不十分であることも否めませんが）、詳しい説明は省いています。
背景などを理解したい方は、ぜひ引用元の記事（リンク先記事）をご覧ください。

〈関連記事〉
Railsアプリ〜デプロイへの道〜その①リモートサーバーへのSSH接続編
 Railsアプリ〜デプロイへの道〜その②Ruby・MySQLインストール編

##開発環境
・Mac OS
 ・Rails 5.2.3
 ・Ruby 2.5.1 
・ConoHa VPS
 ・CentOS 7.6
 ・Capistrano3 
・Nginx
 ・Unicorn

##Nginx
WebサーバーNginxのインストールおよび設定を行います。
〈参考〉
https://koooza.net/post-382
https://qiita.com/glvty83/items/abd99a6b712e4e006af1

###1.インストール
yumで一発です。
サーバー

$ cd ~
$ sudo yum install nginx
#確認。バージョン出ればOK
$ nginx -v

###2.設定ファイルの編集
〈参考〉
https://qiita.com/naoki_mochizuki/items/657aca7531b8948d267b

リクエストの処理方法、webアプリのディレクトリ設定等を行います。 
まずファイルを作成。

$ cd /etc/nginx/conf.d/
$ sudo vi hoge_app.conf # 名前は任意。webアプリの名前など

続いてファイルの中身を以下のように修正してください。
 hoge_appの部分は任意の名称に、serer_nameの部分はconohaのipアドレスに変えてください。

#各種ログのディレクトリ設定
  error_log  /var/www/hoge_app/current/log/nginx.error.log;
  access_log /var/www/hoge_app/current/log/nginx.access.log;
#処理を受け取る最大許容量
  client_max_body_size 2G;
  upstream app_server {
# 連携するunicornのソケットのパス
    server unix:/var/www/hoge_app/current/tmp/sockets/.unicorn.sock fail_timeout=0;
  }
  server {
    listen 80;
    server_name xxx.xxx.xxx.xxx; # conohaのipアドレス
#次のリクエストが来るまでの待ち時間（秒
    keepalive_timeout 5;
#静的ファイルを読みに行くディレクトリ
    root /var/www/hoge_app/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 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/hoge_app/current/public;
    }
  }

/var/www/hoge_app/フォルダはのちほど作成します。

###3.ファイアウォールのポート開放

ファイアウォールの80番ポートを解放します。
ファイアウォールのポートの開放をしないと、httpでの通信ができません。

なぜ80番ポートなのかと言うと、80番ポートがhttp通信用のポートだからです。

〈参考〉
http://inaba.hatenablog.com/entry/2017/02/26/040218

####アクティブなゾーンを確認
ファイアウォールは「事前に定義されたゾーンに対して、指定されたルールの通信を通す。」という事をしています。 なので、まずはどのゾーンへのファイアウォールが動いているかを確認します。

$ firewall-cmd --get-active-zones
public
  interfaces: eth0

--get-active-zonesというオプションをつけると、現在アクティブなゾーンが表示されます。
上記だとpublicというゾーンがアクティブだとわかります。
アクティブなゾーンが複数ある場合は、eth0が外部公開されているインタフェースなので、eth0が定義されているゾーンが外部向けポートを追加する対象です。

####許可されているポートの確認
次は先程確認したアクティブなゾーンのpublicについて、現在許可されているポートを確認します。

$sudo firewall-cmd --info-zone public
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: eth0
  sources:
  services: dhcpv6-client ssh
  ports:
  protocols:
  masquerade: no
  forward-ports:
  sourceports:
  icmp-blocks:
  rich rules:

servicesには定義されているサービス(ルールのような物)が表示されます。
上の例だとservicesにdhcpv6-clientとsshが設定されています。

次のコマンドでサービスの内容を確認できます。

$ sudo firewall-cmd --info-service dhcpv6-client

詳しくはこちらの記事をお読みください。
http://inaba.hatenablog.com/entry/2017/02/26/040218

 portsにはサービスとは別に開放されているポートが表示されます。
 今回はportsには何も表示されていませんが、例えば8080番ポートが開放されていると、ports: 8080/tcpのように表示されます。

####定義されているサービスを確認
サービスの一覧は—get-servicesオプションで確認できます。

$ firewall-cmd --get-services
RH-Satellite-6 amanda-client amanda-k5-client bacula bacula-client ceph ceph-mon dhcp dhcpv6 dhcpv6-client dns docker-registry dropbox-lansync freeipa-ldap freeipa-ldaps freeipa-replication ftp high-availability http https imap imaps ipp ipp-client ipsec iscsi-target kadmin kerberos kpasswd ldap ldaps libvirt libvirt-tls mdns mosh mountd ms-wbt mysql nfs ntp openvpn pmcd pmproxy pmwebapi pmwebapis pop3 pop3s postgresql privoxy proxy-dhcp ptp pulseaudio puppetmaster radius rpc-bind rsyncd samba samba-client sane smtp smtps snmp snmptrap squid ssh synergy syslog syslog-tls telnet tftp tftp-client tinc tor-socks transmission-client vdsm vnc-server wbem-https xmpp-bosh xmpp-client xmpp-local xmpp-server

結構量が多いのですが、この中にhttpというサービスがあります。

httpサービスの内容を確認します。

$sudo firewall-cmd --info-service http
http
  ports: 80/tcp
  protocols:
  source-ports:
  modules:
  destination:

 80番ポートがルールとして定義されています。

####サービスをゾーンに追加
httpサービスが80番ポートを開放するサービスという事がわかったので、publicゾーンにhttpサービスを追加します。

$sudo firewall-cmd --permanent --zone public --add-service http
success
$sudo firewall-cmd --reload
success

--permanentは設定の永続化。(無いと再起動時に設定が消えます。)
 --zone publicはゾーンの指定。 --add-service httpは追加するサービスの指定です。
--add-serviceだけでは設定が反映されないので、設定をした後に--reloadでファイアウォールに設定を反映させます。

設定が反映されているか確認します。

$sudo firewall-cmd --info-zone public
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: eth0
  sources:
  services: dhcpv6-client http ssh
  ports:
  protocols:
  masquerade: no
  forward-ports:
  sourceports:
  icmp-blocks:
  rich rules:

設定が反映されました。

###4.自動起動設定

サーバーの再起動の際にもNginxが自動的に起動するよう設定します。

$ chkconfig nginx on

自動起動確認

$ systemctl is-enabled nginx
enabled

###nginx基本コマンド
〈参考〉
https://qiita.com/MuuKojima/items/afc0ad8309ba9c5ed5ee

起動
$ sudo systemctl start nginx
停止
$ sudo systemctl stop nginx
再起動
$ sudo systemctl restart nginx
再起動しても設定ファイルが反映されない場合など
$ sudo nginx -s reload
状態の確認
$ sudo systemctl status nginx

##Githubの公開鍵登録

capisatranoでは、直接ローカルからファイルを送るのではなく、githubなどのホスティングサービスを経由します。
なので、サーバー側からgithubへsshで接続できるようにキーペアの作成・登録を行います。

〈参考〉
https://qiita.com/shizuma/items/2b2f873a0034839e47ce

###1.キーの作成
サーバー

$ cd ~/.ssh/
$ mkdir github
$ cd github
# キーペアの作成
$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/hoge/.ssh/id_rsa): /home/hoge/.ssh/github/id_rsa # 先程作成したフォルダを指定
Enter passphrase (empty for no passphrase): # Enter
Enter same passphrase again: #Eneter

$ cat id_rsa.pub
# 出力をコピーして、githubのコンソールより公開鍵を登録

# 設定ファイルを作成
$ sudo vi ~/.ssh/config
# 以下を記述
Host github github.com
  Hostname github.com
  User git
  IdentityFile ~/.ssh/github/id_rsa

※Host名に注意してください。
❌Host github
⭕️Host github github.com

githubだけではエラーが発生しました。

###2.公開鍵をGitHubにアップする

以下のリンクから公開鍵をGithubにアップできます。（GitHubに登録していることが前提条件です）
https://github.com/settings/ssh

手順はこちらの記事でご確認ください。
＞＞https://qiita.com/shizuma/items/2b2f873a0034839e47ce

接続確認

$ ssh -T github
#確認はyes
#以下のような文章が出力されればOK
You've successfully authenticated, but GitHub does not provide shell access.

##Rails
###1.データベースの設定
本番環境用のデータベースの設定をします。
Rails

config/database.yml

default: &default
  adapter: sqlite3
  pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>
  timeout: 5000

development:
  <<: *default
  database: db/development.sqlite3

test:
  <<: *default
  database: db/test.sqlite3

# ここから変更
production:
  adapter: mysql2
  encoding: utf8mb4
　charset: utf8mb4
  pool: 5
  database: hoge_app_production
  username: root
  password: root # その1で設定したサーバー側のmysqlのパスワード
  socket: /var/lib/mysql/mysql.sock

###2.Gemfile修正
groupでくくられていないgem ’sqlite3’をコメントアウトし、developmentのグループのなかに’sqlite3’を追加します。
さらにproductionのグループを追記し、そちらにmysql2を設定しています。

Gemfile

.
.

# Use sqlite3 as the database for Active Record
# gem 'sqlite3' コメントアウト
.
.

group :development, :test do
  # Call 'byebug' anywhere in the code to stop execution and get a debugger console
  gem 'byebug', platforms: [:mri, :mingw, :x64_mingw]
  # Adds support for Capybara system testing and selenium driver
  gem 'capybara', '~> 2.13'
  gem 'selenium-webdriver'
  # 追加
  gem 'sqlite3'
end
.
.
# 以下追加
group :production, :staging do
  gem 'mysql2'
end

インストール

$ bundle install

###3.Githubでのバージョン管理開始
CapistranoではGithubを介したデプロイを行うので、githubのremoteリポジトリの登録とpushを行います。

# 変更履歴のコミット
$ git add . && git commit -m 'first commit'

# リモートリポジトリの登録（事前にご自身のgithubでリポジトリを作っておいてください）
# リポジトリ追加の際に表示される案内に従ってコマンドを入力
$ git remote add origin git@github.com:[ユーザID]/[リポジトリ].git

# リモートへのアップ
$ git push -u origin master

##Capistrano

Capistranoとは、Ruby製のデプロイ自動化ツールです。
アプリケーションのファイルをサーバーにアップしてインターネット上に公開し、ユーザーが使える状態にするデプロイ作業を自動で行ってくれます。

Capistranoがデプロイを自動化するツールなら、ここまでの作業はなんだったのか？？
デプロイの準備作業ということになりますね。

実を言うと、僕は手動デプロイをしたことがないのですが、手動デプロイには引き継ぎや再利用がしづらいといったデメリットがあるようです。

Capistranoは保守性が高く、再利用もしやすいと言ったメリットがありますが、それでも設定する項目が多く複雑です。

仕組み部分の理解がこれまで以上に重要になってきます。

設定に入る前に、こちらの記事に目を通すことを強くお勧めします。
https://labs.gree.jp/blog/2013/12/10084/

〈参考〉
https://qiita.com/naoki_mochizuki/items/657aca7531b8948d267b

###1.インストール
Railsアプリにcapistranoおよびunicornのgemをインストールします。

Rails

Gemfile

group :development do
  # Access an IRB console on exception pages or by using <%= console %> anywhere in the code.
  gem 'web-console', '>= 3.3.0'
  gem 'listen', '>= 3.0.5', '< 3.2'
  # Spring speeds up development by keeping your application running in the background. Read more: https://github.com/rails/spring
  gem 'spring'
  gem 'spring-watcher-listen', '~> 2.0.0'
  # 以下追記
  gem 'capistrano'
  gem 'capistrano-bundler'
  gem 'capistrano-rails'
  gem 'capistrano-rbenv'
end

group :production, :staging do
 gem 'mysql2'
 # 以下追記
 gem 'unicorn'
end

ローカル

$ bundle install

###2.capistranoの設定ファイル生成
新たにcapコマンドが使えるのでそれでcapistranoの設定ファイルを作成します。

$ bundle exec cap install

以下のようなファイルが生成されます。
hogeapp
├─ Capfile
├─ config
│ ├─ deploy
│ │ ├─production.rb
│ │ └─staging.rb
│ └─deploy.rb
└─ lib
└─capistrano
└─tasks

###3.capistranoの基本設定
Rails
capistranoの設定ファイルを編集します。 
まず、何を読み込むかを、Capistranoでどのような動作を行うかに合わせて決めます。

最初に記載されている内容は削除で大丈夫です。
 今回は下の用に設定しましょう。
 require hogehogeの部分で読み込むファイルを設定しています。

capfile

require "capistrano/setup"
require "capistrano/deploy"
require "capistrano/rbenv"
require "capistrano/bundler"
require "capistrano/rails/assets"
require "capistrano/rails/migrations"
require "capistrano/scm/git"

install_plugin Capistrano::SCM::Git

# taskを記述したファイルを読み込む用に設定。
# なおデフォルトでは *.rakeとなっているのでもとの記述をそのまま使う場合は注意!！
Dir.glob("lib/capistrano/tasks/*.rb").each { |r| import r }

###4.productionの環境設定
生成したconfig/deploy配下にあるprouction.rbにサーバーの情報を記述します。
ちなみにstaging.rbはその名の通り、ステージングの情報です。

こちらも元のコードは全削除で大丈夫です。

config/deploy/production.rb

# conohaのサーバーのIP、ログインするユーザー名、サーバーの役割
# xxxの部分はサーバーのIPアドレス
# 10022はポートを変更している場合。通常は22
server 'xxx.xxx.xxx.xxx', user: 'hoge', group: "wheel", roles: %w{app db web}, port: 10022 

#デプロイするサーバーにsshログインする鍵の情報。サーバー編で作成した鍵のパス
  set :ssh_options, {
    keys: %w(~/.ssh/id_rsa),
    forward_agent: true,
    auth_methods: %w(publickey)
  }

次にproductionとstaging共通の設定について、deploy.rbに記述します。

こちらも最初の記述は全削除で。
 ※ capistranoのバージョンを確認して、以下記述のバージョンを調整してください。 
rubyのバージョンからアプリケーション名、デプロイで送るgithubのリポジトリ、capistranoのタスクなどを記述します。

config/deploy.rb

# capistranoのバージョン固定
lock "~> 3.10.1"

# デプロイするアプリケーション名
set :application, 'hoge_app'

# cloneするgitのレポジトリ
# 1-3で設定したリモートリポジトリのurl
set :repo_url, 'git@github.com:hogehoge/hoge_app.git'

# deployするブランチ。デフォルトはmasterなのでなくても可。
set :branch, 'master'

# deploy先のディレクトリ。
set :deploy_to, '/var/www/hoge_app'

# Default value for :pty is false
 set :pty, true

# シンボリックリンクをはるファイル
# Default value for :linked_files is []
 append :linked_files, "config/master.key"
# シンボリックリンクをはるフォルダ
# Default value for linked_dirs is []
 append :linked_dirs, "log", "tmp/pids", "tmp/cache", "tmp/sockets", "vendor/bundle", "public/system"

# 保持するバージョンの個数(※後述)
set :keep_releases, 5

# rubyのバージョン
# rbenvで設定したサーバー側のrubyのバージョン
set :rbenv_ruby, ‘2.5.1’

# 出力するログのレベル。
set :log_level, :debug

# デプロイのタスク
namespace :deploy do

  # unicornの再起動
  desc 'Restart application'
  task :restart do
    invoke 'unicorn:restart'
  end

  # データベースの作成
  desc 'Create database'
  task :db_create do
    on roles(:db) do |host|
      with rails_env: fetch(:rails_env) do
        within current_path do
                # データベース作成のsqlセット
                # データベース名はdatabase.ymlに設定した名前で
                  sql = "CREATE DATABASE IF NOT EXISTS hoge_app_production;"
                # クエリの実行。
                # userとpasswordはmysqlの設定に合わせて
                execute "mysql --user=root --password=root -e '#{sql}'"

        end
      end
    end
  end

  after :publishing, :restart

  after :restart, :clear_cache do
    on roles(:web), in: :groups, limit: 3, wait: 10 do
    end
  end
end

各パラメータの内容は、次の参考記事で詳しく説明してくれています。
こちらも一読することをオススメします。
 (Capistrano編)世界一丁寧なAWS解説。EC2を利用して、RailsアプリをAWSにあげるまで - Qiita 

###5.master.keyの設定
Railsで設定しているmaster.keyの内容をサーバーにコピーします。
Rails5.2からはmaster.keyはcredentials.yml.encファイルで設定します。
詳しくは次の参考記事をお読みください。
〈参考〉
https://qiita.com/yuuuking/items/53a37a2e998972be32b8
https://qiita.com/katsu105/items/88675da5119762d73d92

まず必要なディレクトリを作成します。
サーバー

$ cd /var
$ sudo mkdir -p www/hoge_app/shared/config
# 所有者を設定
$ sudo chown -R hoge www
# ファイルの作成
$ cd www/hoge_app/shared/config

shared/configにmaster.keyを作ります。

$sudo touch /var/www/hoge_app/shared/config/master.key

作成したmaster.keyを編集します。

$sudo vim /var/www/hoge_app/shared/config/master.key

ローカルのmaster.keyの内容をコピーし、本番環境のmaster.keyにコピーします。

〈メモ〉
mkdir -p

-pオプション（--parentsオプション）を指定することで、ディレクトリが存在していてもエラーメッセージを表示せず、現在あるディレクトリはそのままにして新規に作成することはなく子ディレクトリを作成する。
また、親ディレクトリが存在しなくてもエラーメッセージを表示せずに親ディレクトリと子ディレクトリを作成する。

参考:https://eng-entrance.com/linux-command-mkdir

〈メモ〉
chown -R

指定したディレクトリとそのディレクトリ以下のファイルやディレクトリの所有権を再帰的に変更

参考:https://webkaru.net/linux/chown-command/

###unicornのセットアップタスク
unicornのセットアップタスクを記述します。
unicornはアプリケーションサーバーで、Railsアプリケーションを制御します。

〈参考〉
https://qiita.com/naoki_mochizuki/items/657aca7531b8948d267b

Rails

lib/capistrano/tasks/unicorn.rb


#unicornのpidファイル、設定ファイルのディレクトリを指定
namespace :unicorn do
  task :environment do
    set :unicorn_pid,    "#{current_path}/tmp/pids/unicorn.pid"
    set :unicorn_config, "#{current_path}/config/unicorn/production.rb"
  end

#unicornをスタートさせるメソッド
  def start_unicorn
    within current_path do
      execute :bundle, :exec, :unicorn, "-c #{fetch(:unicorn_config)} -E #{fetch(:rails_env)} -D"
    end
  end

#unicornを停止させるメソッド
  def stop_unicorn
    execute :kill, "-s QUIT $(< #{fetch(:unicorn_pid)})"
  end

#unicornを再起動するメソッド
  def reload_unicorn
    execute :kill, "-s USR2 $(< #{fetch(:unicorn_pid)})"
  end

#unicronを強制終了するメソッド
  def force_stop_unicorn
    execute :kill, "$(< #{fetch(:unicorn_pid)})"
  end

#unicornをスタートさせるtask
  desc "Start unicorn server"
  task start: :environment do
    on roles(:app) do
      start_unicorn
    end
  end

#unicornを停止させるtask
  desc "Stop unicorn server gracefully"
  task stop: :environment do
    on roles(:app) do
      stop_unicorn
    end
  end

#既にunicornが起動している場合再起動を、まだの場合起動を行うtask
  desc "Restart unicorn server gracefully"
  task restart: :environment do
    on roles(:app) do
      if test("[ -f #{fetch(:unicorn_pid)} ]")
        reload_unicorn
      else
        start_unicorn
      end
    end
  end

#unicornを強制終了させるtask
  desc "Stop unicorn server immediately"
  task force_stop: :environment do
    on roles(:app) do
      force_stop_unicorn
    end
  end
end

####killの種類
kill -QUIT : 停止
kill -HUP : 再起動
kill -USR2 : 緩やかな停止

###6.unicornの設定ファイル
unicornの設定ファイルproduction.rbを作成し、ファイルのパスなどを設定します。
中身は以下のように記述してください。

config/unicorn/production.rb

#ワーカーの数
  $worker  = 2
#何秒経過すればワーカーを削除するのかを決める
  $timeout = 30
#自分のアプリケーション名、currentがつくことに注意。
  $app_dir = "/var/www/hoge_app/current"
#リクエストを受け取るポート番号を指定。後述
  $listen  = File.expand_path 'tmp/sockets/.unicorn.sock', $app_dir
#PIDの管理ファイルディレクトリ
  $pid     = File.expand_path 'tmp/pids/unicorn.pid', $app_dir
#エラーログを吐き出すファイルのディレクトリ
  $std_log = File.expand_path 'log/unicorn.log', $app_dir

# 上記で設定したものが適応されるよう定義
  worker_processes  $worker
  working_directory $app_dir
  stderr_path $std_log
  stdout_path $std_log
  timeout $timeout
  listen  $listen
  pid $pid

#ホットデプロイをするかしないかを設定
  preload_app true

#fork前に行うことを定義
  before_fork do |server, worker|
    defined?(ActiveRecord::Base) and ActiveRecord::Base.connection.disconnect!
    old_pid = "#{server.config[:pid]}.oldbin"
    if old_pid != server.pid
      begin
        Process.kill "QUIT", File.read(old_pid).to_i
      rescue Errno::ENOENT, Errno::ESRCH
      end
    end
  end

#fork後に行うことを定義
  after_fork do |server, worker|
    defined?(ActiveRecord::Base) and ActiveRecord::Base.establish_connection
  end

##githubへのpush

今までの変更をgithubへpushします。
capistranoはgithubを介してサーバーにファイルを送るためです。

ローカル

# 変更履歴をステージング
$ git add .
# コミット
$ git commit -m 'config complete'
# githubへ送信
$ git push origin master

##デプロイ
いよいよデプロイを行います。

###1.データベース作成
デプロイ前に本番用のデータベースを作成します。

サーバー

$ sudo mkdir /var/www/hoge_app/current
#サーバー側でディレクトリの作成

次にローカル側のデプロイするアプリのディレクトリで以下のコマンドを実行します。

$ bundle exec cap production deploy:db_create

どうやら一度きり実行するものはcap deploy時にtask名を明示してあげないといけないみたいなので、初回のみDBを作成するtaskを明示してあげないといけないようです。

最後に先程作成したサーバー側のcurrentディレクトリを削除します。
サーバー

$ sudo rm -r /var/www/hoge_app/current

なぜこのような手順を追うかと言うと、先ほどのデータベース作成時にはcurrentがないと、デプロイ時にはcurrentがあるとエラーが発生することがあるみたいです。
もっといいやり方があるかもしれません。

〈メモ〉
rm -r
rmコマンドは、オプションを設定しなければ、ディレクトリを削除の対象としない。
ディレクトリも削除の対象とする場合は、-rオプションを指定する。
参考：https://eng-entrance.com/linux_command_rm#-r--recursive

###2.デプロイの実行
ついにやってまいりました。
デプロイのお時間です！！！

ローカルで次のコマンドを入力してください。

$ bundle exec cap production deploy

###3.Nginxの起動
デプロイがうまくいったら、サーバーにアクセスしてnginxを起動してください。

サーバー

$ sudo service nginx start

###4.サイト確認
それではサイトにアクセスしてください。

$ open http://xxx.xxx.xxx.xxx # conohaのipアドレス

無事に表示されればデプロイ成功です！

お疲れ様でした！！

##おまけ

ここからはおまけになりますが、一応読んでおいてください。

僕はデプロイが完了した後、いったんConoHaサーバーを停止し、また起動させました。
すると、

We're sorry, but something went wrong.
If you are the application owner check the logs for more information

というエラーメッセージが表示され、アプリが表示されなくなってしまいました。

色々といじるも解決せず、デプロイし直したら、今度はデプロイまでエラーが発生してしまいました。

SSHKit::Runner::ExecuteError: Exception while executing as fukaya@150.95.204.25: kill exit status: 1
kill stdout: kill: sending signal to 5001 failed: そのようなプロセスはありません
kill stderr: Nothing written

unicorn.pidを削除することでデプロイ時のエラーは解決しました。

$ cd /var/www/hoge_app/current/tmp/pids
$ sudo rm -r unicorn.pid

〈参考〉
http://movieman.hatenadiary.com/entry/2017/01/26/010635

再デプロイ後にnginxを起動させたら、きちんとアプリが表示されました。

何が言いたいかというと、

いったんデプロイしたら、不用意にConoHaサーバーを停止しないようにしましょう！！！

ということです。

##まとめ

いかかがでしたか？？

スムーズにデプロイできましたか？？

僕もそうでしたが、初めてのデプロイだとなかなかスムーズにはいかないと思います。

ですが、試行錯誤しながら苦労してデプロイをしたことで、確実にデプロイ前より成長しているはずです。

ちなみに僕は初デプロイの時に途中で詰まり、色々とイジっていたら収拾がつかなくなったので、
最初からデプロイし直しました。

１からやり直したことでいい復習になり、結果的に理解も深まりました。

どうしようもなくなったら、思い切って最初からやり直すのもアリだと思います。

僕もまだまだわからないことばかりで、偉そうなことは言えないので、
これからもっと精進していきたいと思います。

初デプロイ達成、おめでとうございます！！

〈関連記事〉
Railsアプリ〜デプロイへの道〜その①リモートサーバーへのSSH接続編
 Railsアプリ〜デプロイへの道〜その②Ruby・MySQLインストール編