よく寝てよく寝る

寿司と猫と布団が好きです

インフラ研修中に戦ったエラー トップ3

この記事はGMOペパボ Advent Calendar 2018の17日目の記事です。

12月に入った途端、諸事情で自宅のインターネットが途絶えてしまい、ちょっと遅刻してしまいました。
新卒1年目でアドベントカレンダー遅刻とか過去にいるんですかね?よくない歴史を生み出してしまった気がします。

気を取り直して、今回は「インフラ研修中に戦ったエラートップ3」をご紹介したいと思います。

研修について

私は今年の4月に新卒8期生としてペパボに入社しました。
4月から6月まで職種合同の新卒研修を受け、現在は配属先の部署でOJTっぽい感じのエンジニア研修を受けています。

エンジニア研修は3つの分野にわかれており、「Web開発研修」「インフラ研修」「モバイル開発研修」に順番に取り組みます。
部署に配属された6月中旬よりWeb開発研修に取り組み始め、半年ほど経過した今日、やっとインフラ研修を終えることができました。次はモバイル研修で、iOSアプリ開発を学びます!
ペパボの新卒エンジニア研修について、詳しくはテックブログの「2018年度新卒エンジニア研修を受けました!」をご覧ください(宣伝)

インフラ研修では、配属されたサービスでの開発業務をこなすために必要な知識・技術を習得します。
私のインフラ研修では、「Web開発研修時にRailsで作ったTodoアプリを、OpenStackを使った自社のプライベートクラウドである「Nyah」にデプロイし、アプリケーションを動かすこと」がゴールです。 そのためにサーバーにインスタンスを立てたり、設定して環境構築したり、を1人でやっていきます。

ちなみに、Nyah って何?という方は、こちらのスライドをご覧ください。

www.slideshare.net

さて、このゴールに到達するためには、以下のような作業をしなければなりません。

  • ローカルに vagrant でテスト用の VM を立てる。
  • サーバーに、ミドルウェアのインストールおよび実行に必要な環境を設定する puppet manifest を書いて、 VM に適用する。
  • capistrano で、Todoアプリを VM にデプロイする。
  • 正常に動作していることが確認できたら、Nyah に Terraform でインスタンスを立てる。( Security Group の設定なども)
  • capistrano で、 puppet manifest を Nyah のインスタンスにデプロイする。
  • Nyah のインスタンスに、puppet manifest を適用する。
  • capistrano で、Todoアプリを Nyah にデプロイする。

実際、プロジェクトでもテスト環境に vagrant を使っていたり構成管理に puppet を使っていたりするので、
できるだけ業務の開発環境と同じ環境でやるようにしています。
というか最初はテスト環境作ったりなどの予定は(自分の中では)なかったのですが、
やっていくうちに「これもやったほうがいいよね」みたいな感じでどんどんプロジェクトの開発環境に近づいていきました。
きっと数カ月後の私は、「あのときやっておいてよかったなあ」と思うことでしょう。

ちなみに、私自身の話をしますが、学生の頃は社会学部で人文学系の研究をしていました。
授業の一部&ゼミで簡単なプログラミングを体験してから「プログラミングでものづくりするのって楽しいな〜」と思い、趣味でWebアプリをつくっていました。なのでWebはとても好きです!
ただし、情報系の専攻の学生が当たり前に持っている基礎知識的なものは無ですし、もちろんサーバーを立てたことなんてありません。初めてインターネットを使ったのは高校入学してからで、当時は同級生がみんなスマホmixi を見ていたのを覚えています。
そんな私にとって、インフラ研修は未知の領域なのでとってもハードルが高く感じました。ですがエンジニア研修の中で一番楽しみにしていたものでもあります。

と、若さをアピールしたところで本題に入りたいと思います!

インフラ研修中に戦ったエラートップ3

長くなってしまいましたが、いよいよトップ3をご紹介します。
先に言っておきますが、全然難しいエラーじゃありません。前述のとおり、私には情報系の専攻の学生が当たり前に持っている基礎知識がないので、要するに初心者がぶち当たりがちなものにぶち当たっていただけです。
結構ネタな感じで面白く読めると思います。
(本人は真剣なので温かい目で見守ってください・・・)

3位:Authentication failed

これは、サーバーに ssh しようとしたときによく遭遇したエラーです。
普通に ssh するときもそうなんですが、 cap deployのさいに capistranossh する、という認識が欠けていて「なんで?」となることがありました。
原因は、

  • .ssh/configに書いている秘密鍵のパスが間違っていた
  • 踏み台用のサーバーを経由して ssh するための設定の書き方が間違っていた
  • SGの設定が間違っていた

などがありました。
これに遭遇しまくったおかげで、「ssh に失敗したら /var/log/secureを見る」を覚えました。
ただ、このエラーに出会うたびに、拒絶された気持ちになって悲しかったです。

2位: MySQL2::Error::ConnectionError

サーバーにTodoアプリをデプロイして、 rails sしたときに遭遇したエラーです。
テスト環境(vagrant)でも本番環境(Nyah)でも、アプリケーション用とDB用とでロールごとにホストを分離していたのですが、これのおかげで原因がどこにあるのか探しにくくなって苦しめられました。
今まではローカルマシンで rails sしたら(アプリケーション側の設定に問題がなければ)ちゃんと繋がったので困ることがあまりなかったのですが、今回は

  • アプリケーション用のホスト内での Railsmysql client が繋がらないのか?
  • アプリケーション用のホストの mysql client と DB用のホストの mysql server が繋がらないのか?
  • アプリケーション用のホストとDB用のホストが繋がらないのか?
  • 接続先(DB用のホスト)のIPアドレスが間違っているのか?

など、原因がありそうな場所がたくさんあり、解決までに時間がかかりました。
mysql client と mysql server があることを初めて知ったのでした。お恥ずかしながら。

1位: Permission denied

堂々の1位は、ローカルでもリモートでも発生したPermission deniedです。

  • capistrano や puppet に実行権限がなかった
  • ユーザーが違った(そのユーザーが変更を加える権限がなかった)
  • sudo をつけ忘れた

などしてこのエラーに出会っていました。体感的に一番多く遭遇した気がする。
誰のどんな権限がないの?というのを特定しないといけなかったので毎回推理ゲームみたいになってました。
でも、ログを見ながら「このコマンドはちゃんと実行できてる」「このコマンドが正常に実行できてない」とひとつずつ確認したり検証したりしながら原因を探すのは面白いです。

ユーザー切り替えてコマンド実行とかしたことがなかったので、これに遭遇しまくったおかげで「誰が(そのコマンドを)実行するのか?」を意識するようになりました。

まとめ

1年目なので、新卒にしか書けない研修のお話について書こうと思ったのですが、結局初心者が躓くあるあるエラー紹介するだけみたいな感じになっちゃいました…。

戦ったエラーたちは、どれも「原因がどこにあるのか?」の切り分けをするのが難しかったです。
目に見えないし(当たり前)、未知の領域なので何がダメなのか全然予想ができない〜という状態が長く続いたのが(精神的に)結構つらかったです。
が、最初はなんでもそうだと思うので強く生きていきます。

社の先輩方は、何か間違った理解をしている箇所がありましたらこっそりご指摘くださると嬉しいです。
最後までお読みいただきありがとうございました:)