リモートのLinux開発用サーバで開発する

今日は夕方から会社の忘年会です。
そして私は明日から年始の仕事初めまで長い休暇に入るので今日が仕事納めになります。

弊社は絶賛社員を募集しておりインターン生をちょくちょく迎えている。
インターンで来られる方はスキルフルな方が多いが、それほどスキルフルでないこれから勉強する、という方もいらっしゃいます。
その方たちの中にコマンドラインでの開発も初めてという方もいらっしゃった。
そういう方にとっては、Dockerをセットアップしたりなどのアプリケーションを作る為の開発環境の構築などはハードルが高い。
実際にアプリケーションを一緒に作ってチームに馴染めるかなどの本質的な素養を見たい、ということで開発環境の構築時間を省くべく、 弊社の佐々木がLinuxリモートサーバで開発できる環境を作った。
当初、そのインターン生の為に作成したリモートサーバの開発環境だったが、私も一緒に使っているうちに色々とたくさんメリットがあることに気付いたので共有したい。

リモートサーバスペックはざっと下記のような感じ。

  • AWS EC2インスタンス
  • t2.medium
  • EBS 100G

セキュリティグループはいい感じに設定する。

ではさっそくメリットから上げていきます。

Dockerのファイル同期が早い

少し前にはてブで話題になっていたこちらの記事にもあるとおり、Docker for Macがとにかく遅い。
MacBook Proを捨ててThinkpad T460sを買ってgentooを入れた

assetsに画像やCSSファイルが結構ある普通のRailsアプリケーションなどの場合、Web画面を表示するのにDocker for Macだとだいたい10秒ぐらい時間がかかっていた。
そういうRailsアプリケーションがLinuxのDocker上だと劇的に早くなる。
LinuxでDockerを使う場合は、なんといってもこれが一番のメリットだと思う。
Docker for Macがこのぐらい早ければなぁ、と本当に残念に思う。

ネットワークスピードが早い

今回はAWSに開発サーバを立てているが、クラウドサーバはだいたいとこでも早いんじゃないかな、と思う。
試しに計測してみると下記のような結果だった。

# speedtest
Retrieving speedtest.net configuration...
Testing from Amazon (xx.xx.xx.)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by Foxcore-LS (Sodegaura) [23.31 km]: 30.408 ms
Testing download speed................................................................................
Download: 246.99 Mbit/s
Testing upload speed....................................................................................................
Upload: 12.51 Mbit/s

計測ツール
https://raw.githubusercontent.com/sivel/speedtest-cli/master/speedtest.py

ダウンロードスピードがやっぱり桁違いに早い。
普通の自宅やコワーキングでは出せない数字である。
Dockerの環境構築時などはイメージをダウンロードするのに時間がかかるので、ダウンロードスピードが早いのはメリットがでかい。

共同で作業できる

リモートなので、tmuxを入れるとリアルタイムで共同で開発出来る。
ローカルだとエラーなどをSlackに貼ってもらって、などで解決に時間がかかったりするが、エラー原因を直接調べることが出来るので解決が早い。
また純粋に、Skypeで話しながらtmuxで一緒にワイワイしながら作業するのが楽しい。
他の人がどんな感じで開発してるのかなども勉強になったりする。

時間のかかる作業を非同期で実行できる

たとえばDocker環境構築は時間がかかる。
そういうときはこのコマンドを打ち込んであとは放置する。

1
$ nohup docker-compose build > out.log &

リモートサーバのいいところはログアウトしても実行していてくれるところ。
Macだと構築時に電源を落とすことは出来ない。

また、リモートサーバで構築しているので、ローカルのMacのCPUやネットワークスピードなどに影響がないのも有難い。

ローカルのストレージを圧迫しない

私のMacのストレージは現在こんな状況である。

空きが一応65Gあるが、Dockerイメージを構築するとすぐに枯渇してしまう。
256GのMacで開発してるのが悪い、と言われればそれまでなのですが。。
開発環境をローカルで作らなくてもいいのであれば、ストレージに余裕が出来るのでとても有難い。

ちなみにMacでDockerのコンテナやイメージを削除しても一向にストレージが減らなかった。
何故かなぁ、と思ったらDockerが利用するDocker.qcow2というファイルのせいだった。

Docker for mac でrmやrmiで消しまくってもストレージが開放されない
Docker for MacでDocker.qcow2のサイズがどんどん大きくなる問題

削除するとストレージが開放されるが、構築したイメージも当然消えてしまうので、ちょっとイケてないですよね。。

常にLinuxサーバ上で開発することで、Linuxに慣れる

Macではコピー&ペーストやファイルの展開など、基本的にGUIでの操作で行うことが出来る。
しかし、リモートのLinuxサーバだとそうはいかない。
すべてコマンドで実行しなければならない。

たまにステージング環境や本番環境のLinuxサーバに直接sshで入って色々操作したりすることがあるが、普段からコピペやファイル展開などの作業も常にコマンドで行う(行わざるを得ない)状況に慣れることによって、ステージングや本番サーバで作業する時に、コマンドの打ち間違えなどのミスが少なくなるのではないかと思う。
実は少し前に、ステージングサーバで少しコマンドの打ち間違えをしてしまって、ファイルを1つ修復出来ない状態にしてしまった経験がありまして。。(;^ω^)
そういう戒めも含めて、もっとLinuxの操作になれておかなければいけないなぁと思う今日このごろです。

以上が私が感じたメリットです。
ではデメリットはないかというと、正直あまり見当たりませんでしたが、以下のようなことがデメリットかなと思います。

必要なファイルをscpで上げないといけない

Macで開発しているとファイルをコピペして必要なディレクトリに持っていけるが、リモートだと毎回scpとかで上げてあげたりしなければいけない。
ちょっと面倒だが、ファイルをアップロードすることがそれほど頻繁にあるわけではないので苦にはならない。

コマンド実行にもたつく場合がある

普通のネットワーク速度なら問題ないと思うが、環境によってはリモートでのコマンド操作がもたつくことがある。
多少もたついてもメリットのほうが今のところは大きいと思っている。


以上つらつらとメリット・デメリットを書いてみました。
結局のところ、Docker for Macがもっと早くなって欲しいということです(笑)。
ちなみにこのブログも開発サーバで書きました。
最近Macでデプロイする時に結構時間がかかっていたので、デーモン化してデプロイ出来るのは有難い。

このエントリーをはてなブックマークに追加