DockerでWebサーバコンテナを作る時に気をつけること
単純にイメージを作ってしまった時に、これはまずいと思ったのでその時対処した時のメモ。
基本的にDockerでWebサーバのコンテナを作成するときに、ソースなどをADDをすると思います。 何も気にせずにADDをしてしまうと、イメージのVirtual Sizeが大きくなりすぎてしまいます。 なので.dockerignoreを使用して余計なファイルはコンテナ上には入れないようにします。 .gitとかはいらないと思うので基本的には省いたほうがいいのかなって思ったりします。
dockerfile
内で、git pull github.com/xxxx/web.git
みたいにソースの最新を落としてくるような操作はやめたほうがいいのかなって思ったりしますね。ライブラリとかはいいとは思います。
画像だらけでアプリの.gitが肥大しているものだとちょっとやめたほうがいいかなと思ったりします。
.git*
いらないものを次々減らして行ったら下記のようになりました。 でも1.91GBある。。。
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE <none> <none> 23180c065f92 5 minutes ago 1.91 GB <none> <none> 5a62078ba01c 9 minutes ago 4.558 GB python 2.7 d833e0b23482 20 hours ago 747.9 MB
Webエンジニアの教科書を読んだ
- 作者: 佐々木達也,瀬川雄介,内藤賢司
- 出版社/メーカー: シーアンドアール研究所
- 発売日: 2015/03/26
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (4件) を見る
- CHAPTER-01 Webエンジニアについて
- CHAPTER-02 Ruby on Railsでの開発
- CHAPTER-03 PHPでの開発
- CHAPTER-04 NoSQLデータベース
- CHAPTER-05 フロントエンドの実装
- CHAPTER-06 ログについて
- CHAPTER-07 データの可視化について
- CHAPTER-08 環境構築の自動化
- CHAPTER-09 便利な外部サービス
Webエンジニアの教科書を読んだので少し感想を。
本の対象者が経験2〜3年の人なっているが、幅広い層に有益と思える本でした。
最近のモダンな技術の情報が幅広く載っており一冊である程度は補える。 自分はほとんど知っている内容だったが、良い復習ができたと思っています。
分野が幅広い分、一つ一つはそこまで深くはないので、 これをベースとして自分が進むべき分野を深く知っていくのがいいのかなといいと思います。
Web API: The Good Partsを読んだ
Web API: The Good Partsを読んだのでざっくり感想。
この本は一般に公開されているAPIを例に書かれて、APIのエンドポイントやヘッダのことなど色々網羅されている印象があり、自分が知識が足りない部分を補える感じで良かった。
一番の収穫はヘッダ部分のこととかだった。基本的に余りヘッダの内容など意識しないでAPIとかを書いていたので、意識してちゃんと使っていかないとなと反省した。
エンドポイントの部分とか自分がこうするべきと思っていることと一致していた。 実際には、思っていただけで出来てはいなかったので今年移ったところでは意識するようにしていて基本的にはするようにしている。
実際のところ、HTTPメソッドの使い分けとかはしたいけど、どうしようかってチームの人と話したけどGETとPOSTでやることにした。TwitterもGETとPOSTだけだし。
エンドポイントの作成って難しいなと思ったりする。REST準拠とかいっても単純にはいかない。
複数のリソースにアクセスする処理は絶対存在するし、別々にリクエストを投げるとトランザクションが変わるので整合性が取れない。そういうときのエンドポイントどうしようかなと悩む。こういうことはこの本には書いていないので注意。
上記の例ではないけど、例えばソシャゲで言えばユニットの合成とかのエンドポイントはどうするか。 下記のようなものが考えられる。
POST/PUT /units/:unit_id { "material_unit_ids": {"type": "array", "items": {"type": "integer"}} } POST/PUT /players/:player_id/units/:unit_id { "material_unit_ids": {"type": "array", "items": {"type": "integer"}} } POST/PUT /units/compose { "base_unit_id": {"type": "int"}, "material_unit_ids": {"type": "array", "items": {"type": "integer"}} } POST/PUT /players/:player_id/units/compose { "base_unit_id": {"type": "int"}, "material_unit_ids: {"type": "array", "items": {"type": "integer"}} }
こういうものは普通に沢山ある。 そういうときにどうするべきかは分からないけど、一番大切なのはエンドポイントを見て何が行われるかすぐに理解できることだと思う。
それを意識して書くことが一番大事(だからといってエンドポイントを増やしすぎるのもいけないと思う)。