2015-05-01

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

2015-04-07

Webエンジニアの教科書を読んだ

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年の人なっているが、幅広い層に有益と思える本でした。

最近のモダンな技術の情報が幅広く載っており一冊である程度は補える。自分はほとんど知っている内容だったが、良い復習ができたと思っています。

分野が幅広い分、一つ一つはそこまで深くはないので、これをベースとして自分が進むべき分野を深く知っていくのがいいのかなといいと思います。

2015-01-12

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"}}
}

こういうものは普通に沢山ある。そういうときにどうするべきかは分からないけど、一番大切なのはエンドポイントを見て何が行われるかすぐに理解できることだと思う。

それを意識して書くことが一番大事(だからといってエンドポイントを増やしすぎるのもいけないと思う)。

2014-12-31

今年のまとめ

今年残り1時間半ってところでブログ作成。

今年を振り返ってみるとなんかあっというまに1年が過ぎていった気がする。

あれやろうこれやろうと思っていたことが先延ばしにしていたけど結局できなかった。

今年は1月はまだ忙しくなかったけど2月の頭にやるのかなって思ったことが現実になり、3月までには出すことに予定がなって2月の中旬から4月の頭までは常にコード書いていて疲れた。1人でフロントのJS部分、サーバ、インフラとの調整などをずっとやっていた。自分の担当(サーバサイド)以外のことでトラブっていて、それの対応していたのが一番多い作業だった気がする。JS触れる人がチームにいなくて(JS書いていた人が他のチーム移動していて)、とりあえず書けないけど自分がやるしかないのかなと必死にcoffeeとにらめっこして解決していた。インフラも環境整理の第1弾ってこともあって色々足りないことがあり自分が調査して伝えて解決していていた。なんとかほぼスケジュール通りに2プラットホームの展開できたので良かったです。それぞれのプラットホームの特長とかあってそれを見れたのは良かったかな。4月の中旬からは忙しかったけど一応休めていたから良かった。色々触り始める時間もできたし。

なんかいきなり話が出てきて7月からチーム移動し、ネイティヴのサーバサイドでapiを作っていましたね。そのチームがやたらとでかくてカオスっていて辛かった。サーバサイドの開発改善を何度も試みるがうまくいかないので苦しんでいましたね。他の人がなんか改善意識が薄い(自分のことは考えているかもしれないけど、チームとして改善)くて無理なんだろうなって思ってしまった(こういうのってどうすればいいんだろう?)。一応無事にアプリがリリースされたので良かったですね。リリースされてからが色々トラブっていて、これもどうなおそうとか考えていたけど解が見つからず。でもなんとか最近トラブルが減っていたので少しは改善はしているのかな。極力自分に属人的なものはないようにはしてきたつもりだけど何か重いタスクがあれば自分担当になっていたのは辛い。今年でチーム離れるのであとは頑張っていただきたい。そこまで今のチームに何も残せなかったのが悔やみますね。

仕事以外ではずっとvagrantととか環境周りのことをしていた気がする。chefにansibleにitamaeとかプロビジョニングツールを触っていたり、goを触っていたりしてました。

来年の目標

- チームビルディング

・ここ数日で思ってきました。今の会社で別にコードを書くメリットがそこまでないので(なんか刺激がない)。

- 今年はvagrantだったのでdockerを

- 何かしらアプリを作る

上記を目標に頑張っていこうと思います。

良いお年を