やりたいこと

ポートフォリオの本番環境で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(-)