やりたいこと
ポートフォリオの本番環境でgit pushやgit pullできなくなったので、再びできるようにしたい。
結局どういう手順で解決したのか
長い記事なので先に何をやって解決したのか書いておく。
- 既存のアプリのディレクトリ名をpfc-masterからpfc-master2に変更し、
$ git cloneした。 -
$ git cloneを成功させるためにGithubと連携するペアキーを作り直した。 -
$ git logでいくつかgit上の履歴が消えていることが問題と推測した。 - 消失していると表示されたファイルを
$ git add$ git commit$ git pushしようとしたが、デバイスにスペースが残っていないと言われる。 - デバイスのスペース不足を解消するために、AWSのEC2の既存ボリュームをデタッチ(EC2との接続を解除)し、新しく作ったボリュームとアタッチ(EC2と接続)した。
- デバイスのスペース不足は解消し、
$ git pullは問題なく実行できるようになったが、すでに自動デプロイまで完了していたアプリを、再度unicornによる手動でのデプロイからやり直さなければならなくなった。
問題
naota7118@Naotas-MacBook-Air-6 pfc-master % git pull origin master
error: refs/heads/add-weight-to-graph does not point to a valid object!
error: refs/heads/ajax-comment-function does not point to a valid object!
error: refs/heads/ajax-favorite-function does not point to a valid object!
error: refs/heads/auto-change-backgroud-image does not point to a valid object!
error: refs/heads/automatic-calculation-function does not point to a valid object!
この後も同じようなエラーがえげつないほど大量に出てくる
思い当たる原因は、
.git/objects/packディレクトリ階下にあったpackfileを全て削除してしまったことだ。
そもそもpackfileとはなんだったのか？
考えられる仮説として、packfileはgit log(git上の歴史)をまとめておく貯蔵庫みたいなものな気がする。
てっきりゴミ袋だと思って全部中身を消してしまったのだが、まずかったか・・・。
なぜpackfileの中身を消したのかというと、
.gitの中身が重すぎて自動デプロイができなくなっていたからだ。
packfileを軽量化すれば自動デプロイが通ると考えたのだが、安易に削除してはいけなかったのかもしれない。
対策
既存のアプリケーションディレクトリ名を変更して、Github（リモートリポジトリ）から$ git cloneすることにした。
アプリケーションのコード自体に問題があるわけではなく、あくまでgit上の履歴が消失しているという問題だから、git cloneさえできれば解決すると考えたからだ。
naota7118@Naotas-MacBook-Air-6 projects % git clone git@github.com:naota7118/pfc-master.git
Cloning into 'pfc-master'...
git@github.com: Permission denied (publickey).
$ git cloneしようとしたが、許可が降りなかった。
この記事を参考に、Githubにssh接続するための公開鍵と秘密鍵を作り直した。
GitHubでssh接続する手順~公開鍵・秘密鍵の生成から~
これは復習だが、公開鍵と秘密鍵の作り直しのやり方
・公開鍵をGithubに登録する
・~/.ssh/configで下記の設定を行う
Host github github.com
HostName github.com
IdentityFile ~/.ssh/id_git_rsa #ここに自分の鍵のファイル名
User git
ペアキーを使ってGithubにアクセスできるか確認する方法
・$ ssh -T git@github.comで接続できればOK
こんな文章が出てきたら、うまくいった証拠だ。
`Hi naota7118! You've successfully authenticated, but GitHub does not provide shell access.`
$ git cloneを成功させるために、ペアキーの作成以外に、もう1つエラーを解決した。
naota7118@Naotas-MacBook-Air-6 projects % git clone git@github.com:naota7118/pfc-master.git
fatal: destination path 'pfc-master' already exists and is not an empty directory.
$ git cloneしようとすると「すでにそのpathはあるからダメだよ」と言われた。
既存のアプリ名がpfc-masterだったので、それを既存のアプリのディレクトリ名をpfc-master2に変更してから、再度$ git cloneを行った。
naota7118@Naotas-MacBook-Air-6 projects % git clone git@github.com:naota7118/pfc-master.git
Cloning into 'pfc-master'...
remote: Enumerating objects: 976, done.
remote: Counting objects: 100% (976/976), done.
remote: Compressing objects: 100% (752/752), done.
remote: Total 15480 (delta 173), reused 897 (delta 129), pack-reused 14504
Receiving objects: 100% (15480/15480), 209.06 MiB | 6.06 MiB/s, done.
Resolving deltas: 100% (4950/4950), done.
Updating files: 100% (40100/40100), done.
今度こそ$ git cloneできた。
果たしてこれで解決したのだろうか？
この状態で自動デプロイやったらどうなるんだろう？
ということでやってみた。
naota7118@Naotas-MacBook-Air-6 pfc-master % bundle exec cap production deploy
^C(Backtrace restricted to imported tasks)
cap aborted!
Interrupt:
自動デプロイのコマンドを実行したが、一向に進まない。
何が問題なんだ？
capistrano.logを確認したが、そこにエラー文は表示されていない。
unicornのプロセスがkillされていないのか？
本番環境を確認しに行く。
[naota@ip-10-0-0-32 pfc-master]$ ps -ef | grep unicorn
naota 1057 16769 0 10:50 pts/1 00:00:00 grep --color=auto unicorn
naota 14936 1 0 Oct26 ? 00:00:02 unicorn master -c /var/www/rails/pfc-master/current/config/unicorn.rb -E deployment -D
naota 15004 14936 0 Oct26 ? 00:00:15 unicorn worker[0] -c /var/www/rails/pfc-master/current/config/unicorn.rb -E deployment -D
unicornのプロセスをkillする
Nginxを再起動する
naota7118@Naotas-MacBook-Air-6 log % cat capistrano.log
# Logfile created on 2020-10-30 19:44:51 +0900 by logger.rb/61378
INFO ---------------------------------------------------------------------------
INFO START 2020-10-30 19:44:51 +0900 cap production deploy
INFO ---------------------------------------------------------------------------
DEBUG [f0e5428c] Running [ -d /home/naota/.rbenv/versions/2.5.1 ] as naota@pfcmaster.work
DEBUG [f0e5428c] Command: [ -d /home/naota/.rbenv/versions/2.5.1 ]
INFO ---------------------------------------------------------------------------
INFO START 2020-10-30 19:51:35 +0900 cap production deploy
INFO ---------------------------------------------------------------------------
DEBUG [b39f590f] Running [ -d /home/naota/.rbenv/versions/2.5.1 ] as naota@pfcmaster.work
DEBUG [b39f590f] Command: [ -d /home/naota/.rbenv/versions/2.5.1 ]
仮説①：capistranoではないところで問題がある？
調べた結果：ローカルの開発環境のlogはcapistrano.logしかなかった。
仮説②：ローカルの本番環境でもgit cloneすればいいのでは？
試してみたこと
さっきと同じように既存のアプリの名前をpfc-masterからpfc-master2に変更した。
(デプロイ編①)世界一丁寧なAWS解説。EC2を利用して、RailsアプリをAWSにあげるまで
[naota@ip-10-0-0-32 rails]$ git clone git@github.com:naota7118/pfc-master.git
Cloning into 'pfc-master'...
remote: Enumerating objects: 976, done.
remote: Counting objects: 100% (976/976), done.
remote: Compressing objects: 100% (752/752), done.
remote: Total 15480 (delta 173), reused 897 (delta 129), pack-reused 14504
Receiving objects: 100% (15480/15480), 209.06 MiB | 10.49 MiB/s, done.
Resolving deltas: 100% (4950/4950), done.
error: unable to write file releases/20201029081621/releases/20201026220654/shared/bundle/ruby/2.5.0/gems/libv8-8.4.255.0-x86_64-linux/vendor/v8/out.gn/libv8/obj/libv8_monolith.a
error: unable to write file releases/20201029081621/releases/20201026220654/shared/bundle/ruby/2.5.0/gems/libv8-8.4.255.0-x86_64-linux/vendor/v8/out.gn/libv8/obj/third_party/icu/libicui18n.a
error: unable to write file releases/20201029081621/releases/20201026220654/shared/bundle/ruby/2.5.0/gems/loofah-2.7.0/benchmark/www.slashdot.com.html
error: unable to write file releases/20201029081621/releases/20201026220654/shared/bundle/ruby/2.5.0/gems/loofah-2.7.0/lib/loofah/html5/safelist.rb
※同じエラーがかなりの数続いていく
error: unable to write file l-2.7.1/lib/mail/fields': No space left on device
warning: Clone succeeded, but checkout failed.
You can inspect what was checked out with 'git status'
and retry with 'git restore --source=HEAD :/'
一応最後までgit cloneはできたのだが、その後で大量のエラーが吐き出された。
これらのエラーは何を意味しているんだ？
$ git statusで確認できると言われたので$ git statusしてみよう。
[naota@ip-10-0-0-32 pfc-master]$ git status
On branch master
Your branch is up to date with 'origin/master'.
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
deleted: .DS_Store
deleted: .circleci/config.yml
deleted: .gitignore
deleted: .rspec
deleted: .rubocop.yml
deleted: .rubocop_todo.yml
deleted: .ruby-version
deleted: .zshrc
deleted: Capfile
deleted: Dockerfile
最初はこんな調子でずっとdeleted: ファイル名が続いていく。
仮説①：アプリのディレクトリ名を変えたから？
最後の方でこんな記述が出てきた。
Untracked files:
(use "git add <file>..." to include in what will be committed)
.DS_Store
.circleci/
.gitignore
.rspec
.rubocop.yml
.rubocop_todo.yml
.ruby-version
.zshrc
Capfile
Dockerfile
Gemfile
Gemfile.lock
README.md
Rakefile
app/
bin/
config.ru
config/
current
db/
docker-compose.yml
lib/
log/
package-lock.json
package.json
public/
releases/
これらはcommitする内容に含まれていないと言われる。
$ git add <ファイル名>という形で指定しなさいと言われる。
仮説①：さっきpackfileで消したのは、これらのファイルに関わるgit logだったのかな？
考え①：言われるがままに$ git addする前に本当にこれらのファイルがないのか確かめに行こう
。
調べた結果：Githubでこれらのファイルそのものは消えていないことを確認した（例：Gemfile）。
[naota@ip-10-0-0-32 pfc-master]$ ls
app Capfile config.ru db Dockerfile Gemfile.lock log package-lock.json Rakefile releases
bin config current docker-compose.yml Gemfile lib package.json public README.md
仮説①：存在はしているけれど、Git上の履歴から消えているから、$ git add .する必要がある？
試したこと：$ git add .してみた。
[naota@ip-10-0-0-32 pfc-master]$ git add .
fatal: Unable to create '/var/www/rails/pfc-master/.git/index.lock': No space left on device
deviseにスペースがないと言われた。
そもそも今回のエラーの原因は.git階下のファイルのサイズが大きすぎることだった。
ここにきて最初のエラー原因でつまずくとは…。
ファイルが大きすると言われたので、じゃあどれくらい大きすぎるというんだ？
と気になったので調べた。
ファイルの大きさの調べ方
$ df -h
[naota@ip-10-0-0-32 pfc-master]$ df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 474M 0 474M 0% /dev
tmpfs 492M 0 492M 0% /dev/shm
tmpfs 492M 416K 492M 1% /run
tmpfs 492M 0 492M 0% /sys/fs/cgroup
/dev/xvda1 8.0G 8.0G 324K 100% / ←確かに容量がパンパンだ
tmpfs 99M 0 99M 0% /run/user/1000
試したこと：AWSのEC2で別のボリュームを新たに作り、既存のボリュームをデタッチ(EC2インスタンスとの連携を外し)し、新しく作ったボリュームをアタッチ(EC2インスタンスと連携させる)した。
結果：ボリュームを変更したら、今まで通りと同じやり方ではEC2インスタンスに入れなくなった。
naota7118@Naotas-MacBook-Air-6 .ssh % ssh -i pfcmaster7118.pem ec2-user@176.34.34.208
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:A5jJQB1bPqJnhHWdg7pTRe+lKedYqXWT82QvaiXyK6I.
Please contact your system administrator.
Add correct host key in /Users/naota7118/.ssh/known_hosts to get rid of this message.
Offending ED25519 key in /Users/naota7118/.ssh/known_hosts:2
ECDSA host key for 176.34.34.208 has changed and you have requested strict checking.
Host key verification failed.
ホストキーの検証に失敗したと言われた。
ホストキーはユーザー認証のサーバー版のといったところか？
Add correct host key in /Users/naota7118/.ssh/known_hosts to get rid of this message.
エラーメッセージを取り除くには/Users/naota7118/.ssh/known_hostsに正しいhost keyを付け足せと言われた。
SSH接続で WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! って言われて接続を拒否られるとき
ssh-keygen -R ElasticIPアドレス
これで解決できるらしいので実行した。
naota7118@Naotas-MacBook-Air-6 .ssh % ssh-keygen -R 176.34.34.208
# Host 176.34.34.208 found: line 1
# Host 176.34.34.208 found: line 2
/Users/naota7118/.ssh/known_hosts updated.
Original contents retained as /Users/naota7118/.ssh/known_hosts.old
naota7118@Naotas-MacBook-Air-6 .ssh % ssh -i pfcmaster7118.pem ec2-user@176.34.34.208
The authenticity of host '176.34.34.208 (176.34.34.208)' can't be established.
naota7118@Naotas-MacBook-Air-6 .ssh % ssh-keygen -R 176.34.34.208
公開鍵を作るときのコマンドssh-keygenに-Rを付け足している。
-Rの意味を調べたが、ディレクトリの内容を再帰的に表示するという。
なんかディレクトリの中の1つ1つの処理を永遠にループして行う的な意味らしいが、正直よくわからないな。
ここで再び容量が変化したか確認してみよう。
おお！！確かにさっきのデバイスが容量がめちゃくちゃ減っている！！
サイズが大きすぎる問題は解決した。
[naota@ip-10-0-0-32 ~]$ df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 474M 0 474M 0% /dev
tmpfs 492M 0 492M 0% /dev/shm
tmpfs 492M 404K 492M 1% /run
tmpfs 492M 0 492M 0% /sys/fs/cgroup
/dev/xvda1 10G 1.6G 8.4G 16% /
tmpfs 99M 0 99M 0% /run/user/1000
問題は解決したが、その代償が大きすぎた
代償とは何かというと、再びunicornでのAWSへのデプロイ、Capistranoでの自動デプロイ、Docker-composeの設定、CircleCIの設定をやり直さなければならなくなったことだ。
幸いにしてゼロからやり直すわけではなく、コードは残っているので、多少の変更さえすれば大丈夫だと思うが、本番環境のMySQLのデータはまた1から入力しなければならない。
実はこのポートフォリオ解決でエラー出現などにより今回で4度目のAWSへのデプロイだ。
正直もうお腹いっぱいだ。
MySQLのインストールで少しつまずいたが、この記事のおかげで解決できた。
【AWS】Amazon Linux2環境にMySQLをインストールしようとしてはまった
CentOS7にMySQL公式のyumリポジトリを追加する、というプロセスが必要なことがわかっていなかった。
※CentOSはLinuxの1つ。
$ sudo rpm -ivh http://dev.mysql.com/get/mysql57-community-release-el7-8.noarch.rpm
MySQL公式のyumリポジトリを追加しないと、yum installコマンドでインストールができない。
$ sudo yum install mysql-community-server
ここまでやったところで$ git pullしてみたら、できるようになっていた！！！
（もっと早い時点で確認すればよかった）
[naota@ip-10-0-0-32 pfc-master]$ git pull origin master
remote: Enumerating objects: 7, done.
remote: Counting objects: 100% (7/7), done.
remote: Compressing objects: 100% (1/1), done.
remote: Total 4 (delta 3), reused 4 (delta 3), pack-reused 0
Unpacking objects: 100% (4/4), done.
From github.com:naota7118/pfc-master
* branch master -> FETCH_HEAD
df8fac9..bc13ae6 master -> origin/master
Updating df8fac9..bc13ae6
Fast-forward
config/database.yml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)