AWS S3 その２

前回はバケット作成とセキュリティ対策だったので今回は実際に投稿するところについて書く。詰まるとしたらこっちの方だろし分けた。

 

S3はローカル環境からでも利用できるのでまずは

１　ローカルから画像投稿する

カリキュラムではsecrets.ymlの時代だったからその書き方になってる。まあ両方知ってる方がいいと思うから両方書くか。

ポイントとしては

昔はbashに環境変数書いてたから

vim ~/.bash_profile とかで環境変数のファイル開いてた

今は.zshrcに書いてるので

vim ~/.zshrcとかでファイル開いてこの中に書く

(ちなみにcapistrano使ってるリモートサーバは上の二つの読み込みしてくれないので/etc/environmentsに記述する)

さらにrailsではsecrets.ymlから環境変数読み込む形ではなくて

credentials.ymlに秘密の情報を書くようになったので、結局環境変数は

credentials.ymlに書いてある

（それと地味にPC全体の環境変数っていうよりも。あるアプリのcredentials内に書くようになったんだねぇと思った。それぞれにcredentialsあるからアプリごとに分けるような感じになったんかな？）(それとこのcredentialsの暗号化復号化するのがmasterkeyだから絶対にあげない、無くさないようにね。そしてこいつは直接書くんじゃなくて普通環境変数RAILS_MASTER_KEYに入れといてそれを読み込む形とるからね)

 

なので

secrets.ymlの時とはcarrierwaveの設定ファイルの書き方が異なる。

 

config/initializers/carrierwave.rb

require 'carrierwave/storage/abstract'
require 'carrierwave/storage/file'
require 'carrierwave/storage/fog'

CarrierWave.configure do |config|
  config.storage = :fog
  config.fog_provider = 'fog/aws'
  config.fog_credentials = {
    provider: 'AWS',
    aws_access_key_id: Rails.application.secrets.aws_access_key_id,
    aws_secret_access_key: Rails.application.secrets.aws_secret_access_key,
    region: 'ap-northeast-1'
  }

  config.fog_directory  = 'ここにバケット名を入れます'
  config.asset_host = 'https://s3-ap-northeast-1.amazonaws.com/ここにバケット名を入れます'
end

 

こうじゃなくて

config/initializers/carrierwave.rb（必要なとこだけ）

 

CarrierWave.configure do |config|
config.storage = :fog
config.fog_provider = 'fog/aws'
config.fog_credentials = {
provider: 'AWS',
aws_access_key_id: Rails.application.credentials.aws[:access_key_id],
aws_secret_access_key: Rails.application.credentials.aws[:secret_access_key],
 

こんな感じに書く。rails cでちゃんとその記述で値取れてるか確認するといい感じ

参考記事

https://qiita.com/nakasato_minami/items/0be3dd5efabe812c6282

 

 

AWS デプロイする時に詰まったところ１

やっぱDB関連で詰まるんだなぁと思った。

 

最初は紐付けたはずのElastic IPにアクセスしても接続拒否だった

↓

ポート解放出来てないのかと思ってhttpsの解放もしたけど駄目だった

↓

 http://＜Elastic IP＞:3000/にきちんとアクセスしてなかった

:3000/を指定しないとアプリのルートにならないし、elasticIPの部分は<>つけない

(ただしnginxの設定まで終わったら:3000/の部分はつけない)

↓

the page you're looking for doesn't exit的なページになった

↓

そういやheorkuの時もみたエラーだけど、その時もページが無いんじゃなくてトップページに必要なデータをseedしてないのが原因だったな、と思いseedしようとした

↓

bundle exec rake db:seedでmysqlのソケットがエラーになったり、Access deniedになったりしたので、database.ymlの記述がおかしいのかな？とソケットの記述を書き直したり、passwordがNoになってたので手当たり次第環境変数読み込みの記述したりしてた。ここが一番詰まった。ちょうどsecrets.ymlがcredentials.yml.encになったタイミングで、そのあたりの設定も疑ったりしたが、リモートの環境変数書く場所（/etc/environment）の中には適切な環境変数はあったし、mysqlもmysql -u root -pではちゃんとパスワード求められて、正しく設定できるようだったのでそのあたりはあまり関係なかったっぽい

↓

結論

↓

RAILS_SERVE_STATIC_FILES=1 unicorn_rails -c config/unicorn.rb -E production -D

で起動しただけでmysqlのコマンドも本番環境を指すのかと思ってしまい、

bundle exec rake db:hogehoge でやっていたのが間違い

恐らくそのせいでdatabase.ymlのdefaultの設定を読み込んでいた

正しくは

rails db:create RAILS_ENV=production

と記述しないといけない。つまり本番環境の指定が必要。

他のコマンドもこれで打つ。dropだけはもう一回これつけて打ってみたいなこと求められるが、RAILS_ENV=productionをつけることで普通にrails db:コマンド打てるようになる。

 

 

それと時間経つと忘れそうなことメモ

アプリkillする時はunicornのマスターのプロセスkillする

アセットのプリコンパイルするコマンドは

rails assets:precompile RAILS_ENV=production

 

 これも本番用って感じのコマンドだね。本番モードでは事前にコマンドでアセットプリコンパイルする必要があるので忘れないように。unicorn立ち上げる時の

RAILS_SERVE_STATIC_FILES=1の指定も忘れないようにね。これないとコンパイルされたファイルをunicornが見つけられないらしい。

 

あと普通にlsとか使いながらlogファイルどこにあるか確認してproduction.logとかunicornのlog書き出されるファイルとかをcatとかlessとかで覗きながら、必要ならviで設定編集したりps aux | grepでプロセス探してkillしたりまぁがんばれって感じ

 

あと自動デプロイ設定まで終わってローカルから

bundle exec cap production deploy

 しようとすると,ssh関連のエラー出るから注意

https://qiita.com/aoitrain/items/90036ec9c24f0566711e

まぁ仕様っぽい

 

 

AWS S3

パケット

S3で実際データが格納されるとこ。パケット名はアクセス時のURLとして使用されるのでまだ誰もつけたことがない名前である必要がある。

名前とリージョンを決めるだけで簡単に作成できる

ただしバケットポリシーを使用してセキュリティ設定を行うので

 今回は

パブリックアクセスをすべてブロックのチェックを外し

新しいアクセスコントロールリスト (ACL) を介して付与されたバケットとオブジェクトへのパブリックアクセスをブロックするのチェックを外し

任意のアクセスコントロールリスト (ACL) を介して付与されたバケットとオブジェクトへのパブリックアクセスをブロックするのチェックを外し

新規のパブリックバケットポリシーまたはアクセスポイントポリシーを介して付与されたバケットとオブジェクトへのパブリックアクセスをブロックするにチェックを入れ

あらゆるパブリックバケットポリシーまたはアクセスポイントポリシーを介したバケットとオブジェクトへのパブリックアクセスとクロスアカウントアクセスをブロックするにチェックをいれる

 

 

サクセスしたバケットのページに行き

アクセス権限からバケットポリシーをクリックすると下に入力する箇所が出るので

バケットポリシー

{
    "Version": "2012-10-17",
    "Id": "Policy1544152951996",
    "Statement": [
        {
            "Sid": "Stmt1544152948221",
            "Effect": "Allow",
            "Principal": {
                "AWS": "************①****************"
            },
            "Action": "s3:*",
            "Resource": "arn:aws:s3:::************②**********"
        }
    ]
}

 

の①に作成したIAMユーザーのarnをコピーして貼り付ける。

②にはバケット名をいれる。

これでこのIAMユーザーだけがアクセスできるようになっているはず。

例

{
    "Version": "2012-10-17",
    "Id": "Policy1544152951996",
    "Statement": [
        {
            "Sid": "Stmt1544152948221",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::123456789123:user/upload_user"
            },
            "Action": "s3:*",
            "Resource": "arn:aws:s3:::upload-app-test"
        }
    ]
}

AWS セキュリティ対策

１　二段階認証を使う

Authyとかで二段階認証するようにする

自分のPCとか携帯にいれるauthyみたいなソフトの説明は一旦置いとく。調べて。

AWS側ではヘッダーのアカウント名からマイセキュリティ資格情報をクリックし、Continue to Security Credentialsをクリック

多要素認証（MFA）を有効化する

仮想MFAデバイスで続行すると

QRコードの表示ができるので

スマホでauthyを開き、アカウントを＋で追加してQRコードを読み取る

ワンタイムパスワードが発行されるのでAWSのMFAコードにパスワードを入力

またパスワードが表示されるので入力

MFA割当てで設定終了

 

２　IAMユーザーを使う

最初に作ったユーザーはルートユーザーなので普段のログインで使うのは良くない。

使える機能を制限したユーザーを作成してそのユーザーでログインするようにする。

 

普通にIAMユーザーのサービス検索して個々のIAMユーザー作成からユーザー管理を選び、ユーザーを追加を選択すると設定に入る

 

ユーザー名を入力

プログラムによりアクセスを選んで次へ

既存のポリシーを直接アタッチを選択して

amazonS3を検索して

AmazonS3FullAccessをチェックして次へ

次は何もせず次へ（次のステップ：確認）

情報を確認したらユーザーを作成

忘れずに認証情報をダウンロード（.csvのダウンロード）

IAMユーザーのパスワード設定をする

作成したユーザーをクリックし、認証情報のタブからコンソールのパスワード欄の管理をクリックする

有効化。自動生成パスワードをクリック

ルートユーザーの時と同じように認証情報をダウンロード（.csvファイル）

 

これでIAMでログインできるようになった

csvにはUser nameとPasswordとConsole login linkが書いてあるので

記載されてるURLに記載されてるUser nameとPasswordでログインする感じ

 

 

最後に（これはルートユーザーでやるのでログインし直す）IAMも二段階認証にする

作成したIAMユーザーの認証情報タブからMFAデバイスの割当の部分の管理をクリックして、ルートユーザーの時と同じように二段階認証の設定をする

 

 3 git-secrets

githubに設定したパスワード等が上がらないようにしてくれるツール。pushしようとしたものにチェックに引っかかる物があれば処理を中断してくれる

cd でルートに戻り

brew install git-secretsで導入

設定を適用したいリポジトリに移動して

git secrets --install　で使用できるようにして

git secrets --register-aws --global　でaws関連の秘密情報を設定

一応　git secrets --listで設定確認できる

今後作成される全てのリポジトリでgit -secretsが適用されるように

$ git secrets --install ~/.git-templates/git-secrets
$ git config --global init.templatedir '~/.git-templates/git-secrets'

 

Github Desktopを使っている場合は

sudo cp /usr/local/bin/git-secrets /Applications/GitHub\ Desktop.app/Contents/Resources/app/git/bin/git-secrets

 この時appllicationフォルダ内にgithub desktopがないとだめなのでファインダーとかで確認しとく

そんなんないよってエラーがでたら

sudo cp /usr/local/bin/git-secrets /Applications/GitHub\ Desktop.app/Contents/Resources/git/bin/git-secrets

 

 

 

AWS Capistranoで自動デプロイ

まず普通にローカルでインストールして設定してく

Gemfile

group :development, :test do
  gem 'capistrano'
  gem 'capistrano-rbenv'
  gem 'capistrano-bundler'
  gem 'capistrano-rails'
  gem 'capistrano3-unicorn'
end

 

一回bundle install

次に bundle exec cap install

色々ファイルができるので説明してく

 

１アプリケーション直下にあるCapfile

Capistranoの機能を提供するコードはいくつかのライブラリ(Gem)に分かれています。そのため、Capistranoを動かすにはいくつかのライブラリを読み込む必要があります。Capfileは、Capistrano関連のライブラリのうちどれを読み込むかを指定できます。

require "capistrano/setup"
require "capistrano/deploy"
require 'capistrano/rbenv'
require 'capistrano/bundler'
require 'capistrano/rails/assets'
require 'capistrano/rails/migrations'
require 'capistrano3/unicorn'

Dir.glob("lib/capistrano/tasks/*.rake").each { |r| import r }

require により引数としておかれた文字列が指すディレクトリが読み込まれ、その中にデプロイに際して必要な動作が一通り記述されています。

 

2  config/deploy/以下のproduction.rbとstaging.rb

どっちもデプロイする環境別の設定を記述するファイル

今回は本番環境だけ、つまりproduction.rbだけ弄る

config/deploy/production.rb

 

server '<用意した自分のElastic IP>', user: 'ec2-user', roles: %w{app db web}

 

サーバホスト名、AWSサーバーへのログインユーザー名、サーバーロール、SSHの設定、その他のサーバーに基づく任意の設定を記述していくらしい。

 

 

3.config/以下のdeploy.rb

こっちはproduction,stagingどちらの環境にも当てはまる設定を記述する

アプリケーション名、gitのレポジトリ 、利用するSCM、タスク、それぞれのタスクで実行するコマンドなんかを設定する。

 

 とりあえずこの通りしとこうか

t# config valid only for current version of Capistrano
# capistranoのバージョンを記載。固定のバージョンを利用し続け、バージョン変更によるトラブルを防止する
lock '<自分のアプリのCapistranoのバージョン>'

# Capistranoのログの表示に利用する
set :application, '<自身のアプリケーション名>'

# どのリポジトリからアプリをpullするかを指定する
set :repo_url,  'git@github.com:<Githubのユーザー名>/<レポジトリ名>.git'

# バージョンが変わっても共通で参照するディレクトリを指定
set :linked_dirs, fetch(:linked_dirs, []).push('log', 'tmp/pids', 'tmp/cache', 'tmp/sockets', 'vendor/bundle', 'public/system', 'public/uploads')

set :rbenv_type, :user
set :rbenv_ruby, '<自分のアプリのrubyのバージョン>' 

# どの公開鍵を利用してデプロイするか
set :ssh_options, auth_methods: ['publickey'],
                  keys: ['<ローカルPCのEC2インスタンスのSSH鍵(pem)へのパス（例：~/.ssh/key_pem.pem）>'] 

# プロセス番号を記載したファイルの場所
set :unicorn_pid, -> { "#{shared_path}/tmp/pids/unicorn.pid" }

# Unicornの設定ファイルの場所
set :unicorn_config_path, -> { "#{current_path}/config/unicorn.rb" }
set :keep_releases, 5

# デプロイ処理が終わった後、Unicornを再起動するための記述
after 'deploy:publishing', 'deploy:restart'
namespace :deploy do
  task :restart do
    invoke 'unicorn:restart'
  end
end 

 

補足

set:名前, 値;でDSLみたいに定義してる。fetch名前で値が取り出せる。

desc 'hoge'とかtask: hoge do みたいなのはrequireしたものに加えてcap deploy時に実行されるタスクを追加してる感じ

 

 

自動デプロイ後のアプリのディレクトリ構成。（本番環境の方）

アプリケーション直下に三つディレクトリ増えているので把握しとく

１releasesディレクトリ

デプロイされたアプリを指定した回数分だけ保存しとくとこ。今回は５回分保存してる(set:keep_releasesのとこ)。ここに前のバージョンが入ってるから一つ前に戻す、みたいなことができる。

２currentディレクトリ

releasesの中で一番新しい物がコピーされて入ってる。要は現在のデプロイの内容だと思っていい。

3 sharedディレクトリ

バージョンが変わっても共通で参照されるディレクトリが入ってる。

log,public,tmp,vendorディレクトリとかが入ってる

 

 Capistranoに合わせてunicorn.rbを修正

 capistranoでのデプロイ後は、アプリケーションディレクトリ直下にあるcurrentディクトりが動くことにあるので、実際に動くディレクトリを意味するworking_directoryの部分を修正する。またログやpidの指定をshared以下にするなどの修正をする。

具体的には

もともとのconfig/unicorn.rb

 

app_path = File.expand_path('../../', __FILE__)

worker_processes 1

working_directory app_path
pid "#{app_path}/tmp/pids/unicorn.pid"
listen "#{app_path}/tmp/sockets/unicorn.sock"
stderr_path "#{app_path}/log/unicorn.stderr.log"
stdout_path "#{app_path}/log/unicorn.stdout.log"

を以下のように変更

# ../が一つ増えている
app_path = File.expand_path('../../../', __FILE__)

worker_processes 1
# currentを指定
working_directory "#{app_path}/current"

# それぞれ、sharedの中を参照するよう変更
listen "#{app_path}/shared/tmp/sockets/unicorn.sock"
pid "#{app_path}/shared/tmp/pids/unicorn.pid"
stderr_path "#{app_path}/shared/log/unicorn.stderr.log"
stdout_path "#{app_path}/shared/log/unicorn.stdout.log"

 

そもそもapp_path = File.expand_path('../../../', __FILE__)って何やねん

https://qiita.com/msy-naka/items/43c70e470a63f82b53a7

https://maeharin.hatenablog.com/entry/20130104/p1 

このあたりの記事に参考にして、多分

app_pathがちゃんと（多分）EC2インスタンのトップからのパス返すように../で上の階層に戻ってる感じなんだけど、動くのがcurrentの予定だから一個深くなったので、動く予定のファイルからちゃんと一番上（/var/www/アプリ/current）まで戻った上で__FILE__でファイル名までのパスを返すようにしてるって感じだと思う。この感じだと__FILE__って絶対パス返すもんなのかと思ったけど、必ずしも絶対パスとは限らんらしい。とりあえずこのくらいの理解でいいか。

 

 

Nginxの方もCapistranoに合わせて修正する

こちらも今までvar/www/以下のアプリと連携していたものを、

var/www/アプリ/currentとかshared

と連携するように設定する

webサーバーはEC2のサーバー内にあるのでそちらで

$ sudo vim /etc/nginx/conf.d/rails.conf

開くと現状

rails.conf

upstream app_server {
  server unix:/var/www/<アプリケーション名>/tmp/sockets/unicorn.sock;
}

server {
  listen 80;
  server_name <Elastic IPを記入>;

# クライアントからアップロードされてくるファイルの容量の上限を2ギガに設定。デフォルトは1メガなので大きめにしておく
  client_max_body_size 2g;

  root /var/www/<アプリケーション名>/public;

  location ^~ /assets/ {
    gzip_static on;
    expires max;
    add_header Cache-Control public;
  }

  try_files $uri/index.html $uri @unicorn;

  location @unicorn {
    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;
}

 

こんな感じになってるだろうから、ガッツリ修正して

upstream app_server {
  # sharedの中を参照するよう変更
  server unix:/var/www/<自分のアプリケーション名>/shared/tmp/sockets/unicorn.sock;
}

server {
  listen 80;
  server_name <自分のElastic IPを記入>;

# クライアントからアップロードされてくるファイルの容量の上限を2ギガに設定。デフォルトは1メガなので大きめにしておく
  client_max_body_size 2g;

  # currentの中を参照するよう変更
  root /var/www/<自分のアプリケーション名>/current/public;

  location ^~ /assets/ {
    gzip_static on;
    expires max;
    add_header Cache-Control public;
    # currentの中を参照するよう変更
    root   /var/www/<自分のアプリケーション名>/current/public;
  }

  try_files $uri/index.html $uri @unicorn;

  location @unicorn {
    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;
}

こんな感じに 修正

設定したら再起動

ec2-user@ip-172-31-25-189 ~]$ sudo service nginx reload
[ec2-user@ip-172-31-25-189 ~]$ sudo service nginx restart

 

自動デプロイを開始する

MySQLがたちがってないと失敗するので再起動しとく

[ec2-user@ip-172-31-25-189 ~]$ sudo service mysqld restart
Unicornのプロセスをkillしとく
[ec2-user@ip-172-31-23-189 <リポジトリ名>]$ ps aux | grep unicorn

ec2-user 17877  0.4 18.1 588472 182840 ?       Sl   01:55   0:02 unicorn_rails master -c config/unicorn.rb -E production -D
ec2-user 17881  0.0 17.3 589088 175164 ?       Sl   01:55   0:00 unicorn_rails worker[0] -c config/unicorn.rb -E production -D
ec2-user 17911  0.0  0.2 110532  2180 pts/0    S+   02:05   0:00 grep --color=auto unicorn
  
[ec2-user@ip-172-31-23-189 <リポジトリ名>]$ kill <確認したunicorn rails masterのPID（上記では17877）>
...

 

ローカルのターミナルい戻り以下のコマンドで自動デプロイを実行する

（もちろんローカルの変更はpushしてある状態で）

 アプリケーションのディレクトリで実行する
$ bundle exec cap production deploy

 

エラーが表示されずに終われば成功。ただし、メモリ不足で落ちることもあるみたいなのでもう一度試す。それでもおかしければ不備がないか確認する。

（デフォでsshのエラー出るから注意↓サーバー起動時にssh鍵の設定がおかしくなるっぽい）

https://qiita.com/aoitrain/items/90036ec9c24f0566711e 

 

最後にブラウザからIPアドレスにアクセスして確認終了

以降はローカルの変更をリモートリポジトリにpushした後に

bundle exec cap production deploy

で反映される

 

 

 

 

追記予定

まだ必要かわからんけどとりあえず

https://qiita.com/tanakayo/items/9d5e091ce5ce52bbdc9a

とか読むことになりそうな気がする

AWS Webサーバーの設定

Nginxを使う

まずインストール

[ec2-user@ip-172-31-25-189 ~]$ sudo yum -y install nginx

 

設定ファイルの編集をする

[ec2-user@ip-172-31-25-189 ~]$ sudo vim /etc/nginx/conf.d/rails.conf

 

注目すべきはsudoでvim開いてるとこetcファイルは権限が強くないと弄れないのでsudoでやってるetcファイルは

UNIXやPOSIX準拠OS(Linux等)で、もっぱら、そのコンピューター用のシステム設定ファイルなどを格納するために使われるディレクトリ。

くらいに考えとくかな

開いたら

rails.conf

upstream app_server {
  # Unicornと連携させるための設定。アプリケーション名を自身のアプリ名に書き換えることに注意。
  server unix:/var/www/<自分のアプリケーション名>/tmp/sockets/unicorn.sock;
}

# {}で囲った部分をブロックと呼ぶ。サーバの設定ができる
server {
  # このプログラムが接続を受け付けるポート番号
  listen 80;
  # 接続を受け付けるリクエストURL ここに書いていないURLではアクセスできない
  server_name <自分のElastic IP>;

  # クライアントからアップロードされてくるファイルの容量の上限を2ギガに設定。デフォルトは1メガなので大きめにしておく
  client_max_body_size 2g;

# 接続が来た際のrootディレクトリ
  root /var/www/<自分のアプリケーション名>/public;

# assetsファイル(CSSやJavaScriptのファイルなど)にアクセスが来た際に適用される設定
  location ^~ /assets/ {
    gzip_static on;
    expires max;
    add_header Cache-Control public;
  }

  try_files $uri/index.html $uri @unicorn;

  location @unicorn {
    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;
}

 こんな感じに編集

 

設定が終わったら権限変更

[ec2-user@ip-172-31-25-189 ~]$ cd /var/lib
[ec2-user@ip-172-31-25-189 lib]$ sudo chmod -R 775 nginx

データやファイルをサーバに送るためにPOSTを許可したいから。

 補足

-Rは多分再帰的オプション、ディレクトリがあったらその中身も全部的な

プロキシhttps://cybersecurity-jp.com/security-measures/32171

 

Nginxを再起動して設定ファイルを読み込み

[ec2-user@ip-172-31-25-189 lib]$ cd ~
[ec2-user@ip-172-31-25-189 ~]$ sudo service nginx restart

 

Unicornを修正する 

nginxを介して処理するようローカルで修正

unicorn.rb

listen 3000

↓以下のように修正

listen "#{app_path}/tmp/sockets/unicorn.sock" 

 

pushしてgithubのマスターを修正

EC2でpull（cd/var/www/アプリ名 に移動してgit pull origin master）

 

[ec2-user@ip-172-31-23-189 <リポジトリ名>]$ ps aux | grep unicorn

 

で起動中のunicornのプロセスID確認してkillして再起動

ec2-user@ip-172-31-23-189 <リポジトリ名>]$ RAILS_SERVE_STATIC_FILES=1 unicorn_rails -c config/unicorn.rb -E production -D

 

何か色々オプションついてるのは前に書いたと思うが

RAILS_SERVE_STATIC_FILES=1は、値がないとアセット読み込んでくれないからとりあえず１入れてるらしい↓

https://numb86-tech.hatenablog.com/entry/2018/11/10/002439

 

 

unicorn一箇所修正しただけでこの手間が掛かっているので手動でデプロイするのは非常にめんどい。おさらいすると

ローカルで修正してgit push

EC2にSSH接続

EC2でpull

アセットコンパイル

Unicorn再起動

って流れ。これをやりたくないからCapistranoで自動デプロイの設定をする

環境変数とcredentials

credentialsは普通には編集出来ないし何書いてるかもわかんないので

EDITOR="vi" bin/rails credentials:edit
とかEDITORを指定して開く。
.bash_profileなどに環境変数: EDITORを指定しておけば指定は不要になる
https://qiita.com/NaokiIshimura/items/2a179f2ab910992c4d39
まぁとにかく上のコマンドで開ける

仮にspecial_cool_secret: hogehoge

とかアホな環境変数設定したとして

rails cして

Rails.application.credentials[:special_cool_secret]とかしたら

hogehogeが表示される

注意点としてはyamlファイルのインデントには意味があるので適当な書き方しない

aws:

  access_key_id: 123

  secret_access_key: 345

とかcredentialsの中身に書いてあるとしたらインデントに注意。

あと上みたいなネストだったら

Rails.application.credentials[:aws][:access_key_id

って感じで取り出す 

動画が一番わかり易いかな

https://www.youtube.com/watch?v=BHgvPPr2nLE

 

master.key

バレたらヤバイ。

環境変数に設定する時は

export RAILS_MASTER_KEY=（コピーしたマスターキー）

とする。注意点として

マスターキーとして使用する環境変数はRAILS_MASTER_KEYだと決まっていること

=の前後にはスペースを入れないこと

 

 

本番環境の環境変数にマスターキーをセットする

まずEC2にログインして

[ec2-user]$ sudo vim /etc/environment

で環境変数書くファイル開いて

RAILS_MASTER_KEY='ローカルでコピーしたmaster.keyの値'

 確認は一度ログインし直してからする

[ec2-user]$ exit
$ ssh -i ~/.ssh/（pemファイル名） ec2-user@（EC2のElastic IP）
[ec2-user]$ env | grep RAILS_MASTER_KEY

 

これでマスターキーをpushせずに環境変数でリモートのサーバーに設定出来た。

データベースのpasswordとかsecret_key_baseは前に書いたやつ参考にすべし。本番環境での環境変数の設定の仕方は書いたはず。

 

 

 

参考記事

https://qiita.com/yuichir43705457/items/7cfcae6546876086b849

https://qiita.com/scivola/items/cc06ddbfd94d3118f693

https://qiita.com/yamamoto_shuji/items/5afd9ffe13f36ff29677

 

追記予定