開発環境のみ記述

RoR アプリケーション
Jsでwebpackを利用している
ディスクのOSイメージはCentOS6

やってよかったこと

Sprocketsからwebpackに移行した

assets配下のディレクトリを全て削除し、frontendという名前のディレクトリを作り、そこでjsなりscssを管理した。サーバーで特に目立ったり店はあまり見当たらなかったが、今後railsじゃ無くなるフロントエンド側の実行環境をrailsから切り離すことに意味があった。また、開発環境にてforemanを利用したことにより自動的にリロードしてくれるようになり、css変更時にリロードする必要がなくなったためスピードが上がった。

ES6対応を早めにした

開発初期は特にサーバー側にyarnをインストールしてなかったためES2015しか利用できなかった。(ES6でデプロイするとcompileエラーになる)ただ、nvm経由のnpmでyarnを入れ、installするだけだったので思った以上に難しくなかったため初めから入れとけばよかったと思っている。

詰まったこと

root権限で作業することは基本的にないと思ったほうがいい。(例外を除き)

root権限で作業してsshでgitをcloneすると、セッションが切れた際に誰も入れなくなった。個人的に厄介だったのが、root権限でsshしてgit cloneをしてしまうと、個々人で作った秘密鍵をssh時に利用してしまうことになるので誰もインスタンスにログインできなくなってしまう可能性が高い。実際に ssh_exchange_identification: read: Connection reset by peer感じのエラーが立て続けに起きて、誰も入れなくなってしまった。

dbを構築するときは`言語`(mysql, psgl)としてのことか、`DB`としてのことかを理解しながら作ると詰まらなさそう

よくあるのがutf8->utf8mb4に変更するときdb自体を変更する時にrailsの機能を使うとか。つまり、railsの機能->dbに設定してるので、言語云々の話ではない。ただ、Access denied for user ''@'localhost'みたいなのはmysql側で変更してあげる必要があるとか。centOSにデフォルトでmysqlが入ってて、それ消さないと他のバージョンのMySQL入れたい時に競合するとか。こういった一つ一つの問題の主語を間違わないように気をつける。

後悔したこと

ディスクのOSイメージの違いがあまり理解してない中でstaging環境とproduction環境を作ったこと

CentOs7, CentOs6, Debianなどなど、それぞれデフォルトのコマンドが違うとか、積んであるものが違うとかしか理解してなかったが、もっと吟味して選ばないとすぐに後悔することになりそう。GCPかAWSかHerokuかみたいなのと似てる気がする。もっというと、将来的には「Docker + GCP + k8s」が理想だけれども（←なんで？）状況的に考えて、GAE for rubyかherokuにしてDBだけGCPの使おうとかをもっと吟味したほうが良さそう。

属人性を防ぎたいがインフラできる人が多くない場合に、できるだけ2人目の権限は最小にすべきだった

もしちょっとかじった人が2人目でインフラを触った時に、killコマンドとか、ridgepoleを本番で実行するとかそういうのを可能にしちゃうととんでもない大惨事が起こる可能性が出ると感じた。もちろん環境ごとにrakeタスクを回させて、コマンドを打たせないとかは大切だと思うけど、全部が全部rakeタスク作ればいいというとそんな時間もないし...万が一最小にするのも面倒であればcapistranoとか利用してslackのprivate channelとかからコマンドでデプロイできる環境作って、そこに入れる人で管理するのも一ついい案だなと思った。

最後に

まだまだ運用してみてボロを経験できてないので、もっと大きく後悔することとか、つまるところがあるかと思います。
そういった際はまた追加していこうと思ってます...