はじめに
Qiita夏祭り企画参加の記事です。
テーマページ②:システム開発における過去の失敗と乗り越えた方法について共有しよう！
こちらのテーマに参加します。
アプリケーション詳細
Rails製の本番稼働しているアプリがありました。
そのアプリは.envファイルに本番で使っている環境変数が定義されていました。
.envファイルは本番の接続情報を持っているためgit管理対象外となっていました。
ローカルに環境構築をする用に.env.exampleはgit管理で用意されていました。
中身は以下のようなもの
# Railsの設定
RAILS_ENV=development
# Bitbucket APIの設定
BITBUCKET_KEY=XXXXXXXXXXXXXXXXXX
BITBUCKET_SECRET=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Bitbucketと連携するためにAPIキーが設定されていました。
環境構築時には以下コマンドを実行してください、というのがREADMEに書いてありました。
cp .env.example .env
.env.exampleをコピーして.envファイルを作成し任意のAPIキーに上書きしてテストする、というようなもの。
何をしたか
本番環境の設定ファイルをふっ飛ばしました。
本番デプロイ時に寝ぼけていたのか
cp .env.example .env
これを実行し本番の設定ファイルがexampleに置き換わり、本番で設定していたAPIキーが分からなくなりました。
デプロイ作業中は気付かず、デプロイした部分の動作確認をして「なんか動かないなー」となってハッと気が付き、血の気が引きました。
このアプリケーションは元々自分が作ったものではなく、どのユーザーの何のAPIキーを使っていたのかも知りませんでした。
当時本アプリを作った担当者はもう退職済みで確認も取れない状況でした。
解決方法
過去の情報を必死に引っ張り出しましたがどこにも情報は残っていませんでした。
必死に調査したところ、うまく動いているところと動いていないところがあることが発覚。
本アプリはwebとバッチに分かれており、バッチの方のみ再起動したため、バッチの方は上書きしてしまった.envを参照しwebの方は上書き前の.envを参照しているようでした。
webのソースの方にログを吐く処理を追加しダンプ
p ENV['BITBUCKET_KEY']
p ENV['BITBUCKET_SECRET']
そうしたところ前の.envの設定値が出力された。
私は急いでそれをメモし.envファイルに適用、バッチの再起動を実施。
無事にバッチも動き出しました。
おわりに
教訓: 寝ぼけながらデプロイしない
やってしまったとしても焦らず解決策を探す。
今回の場合は仮に前の値が見つからなかったとしても、新しくbotユーザーを作成しそのユーザーのAPIキーを設定すればうまくいくだろうし、必ずしも復旧させる必要はなかったかもしれません。
肝が冷えたお話でした。