genonymous

GenestreamのTechブログ

進撃のデプロイ

こんにちは、開発チームの太田です。 先週末に進撃の巨人の劇場版が始まりましたね。

僕は1年前ぐらいから進撃の巨人にハマりだして、一気に単行本とアニメを読み尽くしました。 劇場版も見に行こうと思っていたのですが、友達を誘ったら「え?アニメの短いバージョンでしょ?意味なくね?」なーんて言われて「やーい!バーカ!バーカ!もう絶対誘わないもんね!」とか思っていじけ気味です。

そんな進撃の巨人ですが、最近進撃の巨人的な出来事に出くわしました。 壁です。ウォールです。「ウォール・SSHkiterror」的なアレです。

え?前提条件がないから全然話がつかめない?そうですよね。 話が前後しますが僕の状況を説明しますね。

状況

過去の僕のエントリーを見てくださった方々はだいたい知ってると思うので読み飛ばしてください。 今年の10月にジェネストリームに入社していきなりチームコラボレーションサービスの責任者をいきなり任せられまして、「ちょwwwうれしいけどrailstutorialしかやったことないですけどwww」とか思いながら、プルリクなどなどで諸先輩方からの指摘をもらいつつ、日夜もくもくとrailsと格闘しながら開発をしてます。

話をもとに戻すと…

で、壁です。ウォールです。 総称「ウォール・デプロイ」です。

いやー、参りましたよ。 アプリできたったー!とかぬか喜びしてたら、ウォール・デプロイが漫画的に書くと「バババババアアァァァンッ!!!!!!」って何層にも渡って出てくるんだもん。

(´・ω・`)

(´・ω・`)

(´・ω・`)

(´・ω・`)

(´・ω・`)

って感じです。 で何を書こうと思ったら一瞬忘れかけたのですが、今回のエントリーでは進撃の巨人的な感じで「進撃のデプロイ」ということでデプロイで遭遇した壁たちと、それをどのように突破したか(安心してください。「鋼の巨人的なタックルで…」とかは書きません。まじめに書きます。)を書いていきたいと思います。

「太田、いろんなツールに手を出す」編

第1の壁「ウォール・ansible」

今考えれば、ただのSSHの問題だったんじゃねーかとめっちゃ思いますが。。。 一番最初は、@kgmyshinのこの記事を読みながら、モダンにansibleを使って既に立ち上げ済みのEC2インスタンスにまとめてデプロイしちゃえ!とか思いました。「これできたらちょー楽勝じゃん!」みたいな。

んで、魔法使いになった気分でansible-playbook playbook-productionn.ymlってやっても返ってくる答えはいつもFAILED => SSH encountered an unknown error during the connection. We recommend you re-run the command using -vvvv, which will enable SSH debugging output to help diagnose the issueばっかり。

結果

それで諦めました。インスタンスの立ち上げから1年以上離れていて、かつrails環境のデプロイを一度もしたことのない俺氏にとってはその時はハードルが高かったのかな〜と。

第2の壁「ウォール・自作からのアップロード」

これも今考えればSSHの問題でしたね。きっとそう。 一晩かけてこの記事とか参考にしながらいろいろインスコったんですけど、最後にsshでアプリケーションをアップロードするところで「あれ?どうやるの?」みたいな。

cyberduckとかfirezillaとかFTPソフトを使って接続しようとしてもエラー、エラー、エラーで。その時は解決策が見つからなくてこれも「スキル・諦める」を選んで

結果

やめました。

「太田、capistranoで頑張る」編

第3の壁「ウォール・SSHKitError」

最終的に今いろいろやってるのがこのcapistranoです。 一晩かけて上の2つをやって朝方「詰んだ(´・ω・`)」ってなってた時に先輩エンジニアの徳山が「capistano使ったらどうっすか?」みたいなことを言ってくれたのがきっかけでしたね。

徳山が持っている「パーフェクトRuby on Rails」にもcapistranoのやり方が書かれていたので「これはいい!」と思って実装したのですが、「あれ?」みたいな。何度bundle exec cap staging deployやっても、出てくるエラーはSSHKit::Runner::ExecuteErrorばっかり。

「てめー!言うこと聞けや!」とか思っても、プログラムなんで出てくるエラーが変わるわけもなく。それで泣きそうになりながら徳山に聞いたら、「configファイル見せてください」と。で「このホスト名変えたらどうですか?」って言われて修正したらこれがヒット。すんなり通りました。それが以下のとおり。

Host hogehoge #アプリ名
  HostName ec2-xx-xx-xxx-xxx.ap-xxxxxxxxx-x.compute.amazonaws.com
  User fugafuga
  Port 00
  UserknownHostsFile /hoge/hoge
  StrictHostKeyChecking no
  PasswordAuthentication no
  IdentityFile ~/.ssh/id_rsa.pem
  IdentitiesOnly yes
  ForwardAgent yes
Host ec2-xx-xx-xxx-xxx.ap-xxxxxxxxx-x.compute.amazonaws.com
  HostName ec2-xx-xx-xxx-xxx.ap-xxxxxxxxx-x.compute.amazonaws.com
  User fugafuga
  Port 00
  UserknownHostsFile /hoge/hoge
  StrictHostKeyChecking no
  PasswordAuthentication no
  IdentityFile ~/.ssh/id_rsa.pem
  IdentitiesOnly yes
  ForwardAgent yes

わかります?一番上のHostをHostnameと同じにしてます。 これでSSHKit突破したぜー!と思ったら早速第4の壁が出てきました。

第4の壁「ウォール・permission denied」

capistranoってコマンドを仕込んでおけば勝手にdirectoryとか作ってくれるんですが、そこで起きたのがたしか「permission denied」。これが出たらスマートなやり方ではないんですが、サーバーに入って手動でchown -p fugafuga:fugafuga /var/wwwってやっていけたと思います。

第5の壁「ウォール・permission denied2」

次に出てきたのが、capistranoがbundle installしてくれてる時だったと思います。こちらもうろ覚えです。ごめんなさい。そんな時はこちらも同じくスマートではありませんがサーバー側でmysqlのユーザーとDBを作ってあげればおkです。

「太田、nginxを使ってみる」編

第6の壁「ウォール・directive error」

capistranoがうまくいってもnginxの設定ファイルは作ってくれないんですよね。こういうところも自動化したいのであればやっぱりvagrantとchefを使った方がいいんじゃないかと思いますけど、今回はそういう時間もなかったので手動でnginx.confを作りました。

nginxの設定ファイルになるとネット上に情報が点在しまくってて、いろんなページを参考にしていましたが、最終的に代表の秋貞におねだりして買ってもらったこの本が一番役に立った気がします。pixivさん最高!

そうそう、表題のdirective errorですが、httpの外にserverの設定ファイルを書いたりするのがnginxの規約上NGらしく。emergeとか怒られました。とは言いながらもeventは外に書けるんですけどね。でこれは簡単でserverの情報をhttpの中に入れてあげるだけ。nginxについては日常的に使うことになりそうなので、本を一冊買ったほうがいいかもしれないと思ってます。

結論

とまあ気づいたら4000文字も書いてしまって、しかも進撃の巨人風に書こうと思ったら、サザエさん的な要素もぶっこんじゃって読者のみなさんにはいろいろと混乱をさせてしまったかもしれませんが、まあこんな感じで僕は進撃の巨人になったつもりで、デプロイの壁を諦めたり、時にはちゃんと突破しに行ったよっていう話です。

qiitaじゃないんでかなりストーリー的になってしまい、実務で調べるっていうシチュエーションでは可読性がめっちゃ低いものになってますが、いつかきっとqiitaにもまとめる日が来ると思うので、qiitaにまとめたら見てみてください。

ちなみに僕のアカウントはこちらです。

http://qiita.com/keisukeohta

http://qiita.com/keisukeohta

それではここらへんで。