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
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を設定しています。
.
.
# 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
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の部分で読み込むファイルを設定しています。
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はその名の通り、ステージングの情報です。
こちらも元のコードは全削除で大丈夫です。
# 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のタスクなどを記述します。
# 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
#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を作成し、ファイルのパスなどを設定します。
中身は以下のように記述してください。
#ワーカーの数
$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インストール編