00:04
はい、ひとなみクラブは、GMOペーパー部ECG用部の2人の高橋が、社内の出来事や最近気になっている技術について話すポッドキャストです。
みなさんこんにちは、くんさんです。
こんにちは、たかぴぃです。
今回で11回目ということで。
11回目ですね。
あとは、今撮ってるのが7月4日なんですけど、ついに7月になって、6月だいぶ暑かったんですけど、
7月入ってからは少し涼しくなったというか、6月待つほどじゃないって感じですね。
そうですね、6月7日みたいな気温でしたからね。
本当にね、大変でしたね。
今は週1か週2ぐらいで多分みんな渋谷に出社してるんですけど、結構暑くてやっぱり大変ですよね。
そうですね。
セルリアンに到着するまでのあの道、下の歩道橋からの道がめちゃくちゃ暑くて大変ですね。
会社に来てしまえばね、会社の中は今は全員出社してるわけじゃないので、割と余裕があったりして涼しいのでいいんですけど。
そうですね。
はい、じゃあ今日のトピックもそれぞれ一つずつ持ってきたので話していこうかなと思うんですけど、じゃあ今日は自分からいきましょうかね。
はい。
最近ホットなワードとしてレベル0生産性ってやつを話してることが多いんですよ。
あれですよね、EC事業部では正義しているというか、もともと前書的にレベル1から3の生産性みたいなのが定義されてたと思うんですけど、それのゼロがあるっていう。
そうですね。もともとこの生産性の話ってEMFMっていうポッドキャストで話されてたレベル1からレベル3までの生産性っていう話が挙げられてて、
ざっくり言うとレベル1の生産性っていうのがいわゆる私たちが生産性って言ったときに一番最初に想像するようなものづくりのスピードというか、そういう生産性っていうのがあるよねっていうところと、
レベル2になると今度は例えばそれが自作がどれくらい効果的だったかとか、作った機能がどれくらい使われてるかとか、そういうところまで見てレベル2、レベル3の生産性っていうのは語っていく必要があるよねっていうような分け方で語られてるんですけど、
それでレベル1の生産性をまず上げていきましょうとか、今レベル1の生産性十分だからレベル2とかレベル3の生産性を上げていくようにしましょうっていう議論ができるようになったのですごくいい整理だと思っているんですけど、
03:00
一方で実はレベル1の生産性、いわゆる私たちが想像するようなGitHubでプルリクエストベースで開発してるんであれば、プルリクのマージ数だったりとかコミットがどれくらいたくさんできてるかとか、変更の行数が多いかどうかみたいなのはちょっと違うかもしれないし、一つ指標としてはそういうものもあったりするようなとかあると思うんですけど、
それよりも手前に結構生産性に影響することってあるんじゃないかなというところで、レベル1の生産性よりも手前の生産性っていうのでレベル0生産性っていうのは今仮で聞けて話したりしてることが多いですね。
具体的にどういうことかっていうと、一番簡単なのはタイピングのスピードみたいな話ですね。
最終的に私たちって多くの場合、キーボードを叩いてコードを書いてアウトプットしていくわけなんですけど、そうなると自分のキーボードが打てる速さより早く物を出すことっていうのができないっていうことだと思うんですよね。
じゃあキーボードが速く打てたらいいのかっていうのはそれもちょっと違うとは思うんですけど、自分の考えがキーボードの打つスピードに邪魔されない程度には速く打てた方が良かろうというのを私は結構思って話したりしてますね。
もう少しレベル1に近づいてくるとツールの使い方とかエディターの使い方とかシェルの使い方とかそういうのがちょっと入ってくるよなと思ってて。
同じ操作をしようとしたときに、ある操作に5手かかる人と2手でそれが済む人だと、そこだけ見ると生産性が2倍ぐらい違うっていうことになってしまうよなというのもちょっと思うんですよね。
だからキーボードの打つスピードみたいな話とか、ツールの使い方だったり、その習熟度みたいなところって、なんか偉派だと思って自分も普段はいるんですけど、一方でレベル1の生産性に結構影響が出てしまうぐらい差がついてしまってることがあるんじゃないかなと最近ちょっと思うようになってきたんですよね。
そのあたりってツールとかエディターとかタイピングとか、その辺の使い方ってタカピーからはどういうふうに見えてますか?
そうですね。やっぱりそこら辺の生産性すごい変わるなとは思っていて、例えば自分で不慣れなツールを使っていた場合とか、そういうのは思うなと思っていて、例えば僕がEmacs使ったらめちゃくちゃ生産性が悪くなると思うんですよ。
06:06
なるほどね。
ってことは、例えばエディターどれもショートカットを覚えてないとか、シェルだったり効率化して動かしてないみたいなところだと、どれもできてないみたいな人がいると、どの手段をとっても高い生産性は生まれないんじゃないかなとは思ってますね。
なるほど、確かに。そうですよね。自分が習熟してないツールを使って何か作ってみようとすると、めちゃくちゃやっぱり時間がかかったり。
そうなんですよね。
これどうやるんだろうってやっぱ思いますもんね。
ええ。
確かに。そうですね。なので、その辺のことを最近ちょっと考えていて、今まではどうやってプログラムを、プログラムじゃないですね。
どっちかっていうと、レベル1から2ぐらいの生産性をどうやって上げようかっていうふうに考えて動いてることも多かったんですけど、実はレベル1とか1の下ぐらいのところにまだまだ実は伸びしろあるのかなって最近思ってきて、
そういうののフォローだったり、うまく組織として上げられるような取り組みとかができないかなっていうのを最近考えてるって感じですね。
なるほど。
最近そんなことを考えながら色々やってるっていうようなお話でした。
はい。
じゃあ私のトピックはそんなとこだったんで、じゃあたかぴーの方に行きましょうか。
私の方はですね、最初ちょっと先日ハマったなんかDockerfileのですね、起動コマンドの命令の部分についてハマったんで、ちょっとそれについて話そうかなと思ったんですけど、
どうも口頭で話せるような内容ではないかなって、口頭で話すの難しいトピックだったので、ちょっともうちょっとライトな話題をしようと思っていて、
Dockerfile関連で、そもそもDockerfileってどう書いてます?みたいなところを、一応自分流みたいなものがあるんで、
はいはい。
それをお話しして、自分はこうやってるみたいな、もしフィードバックがあればお聞きしたいなとは思っていて、
今回は自分はどうやってやってるのかみたいなところをお話しできればなというふうに考えてます。
なるほど。
はい。
それはDockerfileを1から書くときにどういうふうにやってるかって感じですかね?
そうですね。
なるほどなるほど。
じゃあまずはどんなふうにやってるんですか?
そうですね。一応段階としては3フェーズに分かれてまして、まずフェーズとしてお話しすると、
まずあれですよね、そもそも動かしたいアプリケーションってどういう要件で動いてるの?みたいなところは確認した方が良いかなと思っていて、
例えば社内の1つのロールを動かすときにどういう仕組みで動いてるかっていうのは、
09:04
例えばパペットマニフェストだったりとか、あとはテスト環境の設定だったりを見て把握することができるので、
まず第一フェーズとしてはどういう要件があるのかっていうのをまず確認をざっくりですね、確認をしているっていう感じになります。
はい。
なるほど。
はい。で、ちょっと次からは具体的などうやっていくの?みたいな話になるんですけど、一応第二フェーズとしてざっくりとドッカーファイルで、
RANっていう命令があると思うんですけど、それに例えば必要なライブラリだったりとかを雑にインストールしていくっていうか、
なるほど。
その段階でライブラリの細かい、なんていうんですかね、大まかにPHPが必要みたいなところとかはわかると思うんですけど、
PHPのライブラリのうちのどういう拡張があるのみたいなところは結構動かしてみないとわからないところとかあると思うので、
一旦はその雑にインストールしていくっていう感じで、細かい単位でビルドを積み重ねていくっていう感じにやってます。
なるほど。じゃあ、例えばPHPと、なんかPHPのライブラリもう一つ、いわゆるOSのパッケージマネージャーで入れるやつがあったら、
とりあえずPHP入れてみて、これ足りなかったなって言ってまた次を、PHPを入れてビルドしてみて、まだ足りないなって言って、
もう一個足してまたビルドしてみたいな感じで進んでいくってことですね。
そうですね。
なるほど。
具体的に言うと、LAN、YAM、インストール、PHP、FPAみたいなLANを組み重ねていくという感じですね。
なるほど。
本来、それで仕上げてしまうとちょっとイメージが膨れてしまうっていうのがあるので、最終的にはそういった形にはしないんですけど、
一旦そういった形で雑にインストールしていってます。
なるほど。
こういうやり方をしてるかって言うと、うまくキャッシュがされるんですね。
DockerファイルってMILFIU型に上からLANの命令ごとにとか、コピーの命令ごとにみたいな感じでキャッシュされていくんで、
何回もビルドし直すときに、1から上から再度ビルドされないので、途中からビルドされていくことになるので、
イメージの作成が早いんですね。最終的に作られる。
よく見るDockerファイルだと、YAMだったらYAMインストールでいっぱいパッケージを並べてるんだけど、
それと同じような作り方をすると、ビルドのステップが毎回全部インストールし直しみたいになるから、
それよりは個別に試しに書いていってみて、1つ上のレイヤーのキャッシュを利かせて時間短縮するっていうやり方なんですね。
12:00
なるほど、すごい。
なので、なるべくこの普遍なものから重ねていくっていう意識ではやっています。
いいですね、わかりました。ありがとうございます。
上のものを変更すると、下のものを再度ビルドされてる感じになるので、そういった形にしています。
それがステップ2ってことですね。
2ですね。
ステップ2で一通りアプリケーションが動くようになったとして、次に第3フェーズに行くんですけども、
第3フェーズは一通り先ほど言ったようにアプリケーションが動くようになるまでライブラリのビルドを繰り返すっていうやり方でやってるんですけど、
それだとイメージが非大化してしまったりとかっていうところがあるので、
最後ですね、ライブラリをまとめてインストールするようにしたりとか、
Dockerファイルのイメージ、ボリュームを小さくするように、記述を変更するようにするという感じになっています。
この辺はどうすればいいかみたいなところは、
Dockerファイルのベストプラクティスっていうのがあるんですね。
あのDocker公式のドキュメントがあるんですけど、こちらを参考にしつつ進めるようにしています。
なるほど、じゃあそうやってとりあえず動くところまで行ったもののイメージを最後仕上げるっていう感じなんですね。
そうですね。
最近だとその辺がハドーリントっていうですね、Dockerファイルのリンターがあるんですね。
それがこのベストプラクティスに沿って指摘されるようになっているので、最近はそれを使っていますね。
便利ですね、なるほど。
それはめちゃくちゃ便利なのでおすすめですね。
それはじゃあパッケージマネージャーのキャッシュ消してないよとかそういうのを検出してくれるのか。
そうですね。キャッシュ消してないよとか、例えばサイレントインストールするようにしましょうとか。
細かいところまで指定してくれるので、Dockerファイルを作るときはぜひ入れていただけるとすごくはかどるものとなっておりますので、
おすすめなツールとなっています。
面白いですね、そっか。
自分と似てるところもあればちょっと違うなと思ったところもあって、
ちょっと違うなと思ったところというか、自分だとどうやるかっていう話をしたとすると、
作りたいDockerファイルの大きさだったり、どれくらいわかりきってるか。
例えばRubyが動けばいいだけのイメージが必要なってもうわかりきってるなら、
直接Dockerファイルをバシバシ書いて、さっきたかぴーがやってたみたいにやるんですけど、
15:03
これどこまでいるかわからんなとか、例えば今はVMのプロビジョニングツールでパッケージインストールしてるんだけど、
それをDocker化したいみたいなときに、これどこまで最低限必要なんだろうみたいな、わからないこともたびたびあると思うんですよ。
なるほど。
そういうときは自分はアプリケーションをとりあえずマウントするというか、
アドカコピーかマウントして、それが動かし方がわかってるなら、
その中でYAMインストールとかAPTインストールとかしまくって動かせるところまでやるみたいなのを結構やってることが多いですね。
なるほど、先にコンテナの中でライブラリをインストールしていくっていうか。
そうそう、そのヒストリーを持ってきて、これとこれとこれ必要だったねっていうので試しにDockerファイルに書いてみて、
ビルドして、動いた動いたみたいなのをやったりすることもありますね。
なるほど、確かに。
結構たかぴーも工夫してビルドを早くしようっていうのを話してましたけど、
やっぱビルドの時間が大変なので、
とにかくそこをどうやって回数少なくまともな、まともというかちゃんと動くイメージにするかっていうのを
結構工夫のするところというか、みんな苦労してるところだろうなと思いますね。
確かにそうですね。
レイヤーをうまく使ってインストールするっていうのをあんまり自分はやってなかったんでいいなと思いました。
ありがとうございます。結構やり直しみたいなのをするときに手順を見て忘れちゃうんですよね。
なのでそこに書いておくと結構思い出せるじゃないですけど、もう勝手にキャッシュされてるんで、
どこまで戻ればいいとかっていうのがやりやすいって。
確かにそうですね。
そうか、だからこれいらなかったねって言ったら上から消してみたりしたら、
そこまでのキャッシュはちゃんと効くから、またそこから分岐してもうまくキャッシュ効いたイメージが作れたりして良さそうですね。
なるほど、すごい。
他にDocker関連で伝えたいチップスとかは何かあります?
Docker関連、そうですね。
チップス、そうですね。
割とやっぱり推奨と書かれてるものはちゃんと推奨通りやった方がいいっていうのはありますね。
確かにね、そうですよね。
Dockerとかベストプラクティスだったり推奨、こういうのがいいよっていうのをちゃんとドキュメントに書いてくれてるので、
まずそれを眺めるっていうのは確かに大事ですね。
結構やっぱりそれ通りやらないでハマったみたいなの結構あって。
なるほど、ちゃんと公式のドキュメント、ハマった時にでもいいけど、先に読んでこうしたらいいねっていうのを知っといた方がいい。
18:02
そうですね。
推奨されてるやり方をしてない場合はその理由をちゃんと把握しとくっていうのが大事かなと。
確かに。
そうですね、ソフトウェア開発何でもそうだなってちょっと思って。
そうですね。
普通にやったらこれでいいんだけど、それじゃうまくいかなかったっていうところをちゃんとドキュメントにしたり残しておけるといいですね。
そうですね、はい。
じゃあそんなところですかね、今回は。
はい、そんなところですね。
じゃあ今日は私の方からレベルゼロ生産性っていう話と、たかぴーの方からDockerファイルの書き方というかDockerコンテナの作り方みたいな話をさせていただきました。
じゃあ今日は第11回そろそろ終わりにしようと思います。
皆さんご視聴ありがとうございました。
ありがとうございました。
