vimtaku blog

名言

小さいことを積み重ねるのが、とんでもないところへ行くただひとつの道だと思っています。(by イチロー)

はい、がんばりましょう。

はじめに

この記事では Docker について自分なりに理解するために調べたことをまとめる。
Docker の tutorial は command line をブラウザで実際に叩くところまでできるようになっているので、
非常にわかりやすく入門できる。なので、 tutorial に関してはそっちをやったほうが良い。
この記事は Docker ってこんな感じのやつなんだーってのが伝わればばいいなと思う。
(ちなみにまだ Docker 歴は1日)

docker とは

LXC と aufs と github のようなものをうまくくみ合わせて提供される
仮想化ソフトウェアだ。

LXC とは

Linux Container のこと。

http://gihyo.jp/admin/column/01/vm/2011/lxc_containerによれば、

LXCの基本技術となるのが「コンテナ」と呼ばれる一種のリソース管理システムです。ファイルシステムの他，ホスト名やプロセス，ネットワークソケットなどのカーネルが扱うさまざまなリソースの管理テーブルを個々に用意し，これをコンテナごとに管理することで，コンテナごとに独立したOSのように動作させることができます。

とある。
また、カーネルの機能である Cgroups の説明をみれば非常によく理解できた。

aufs, Union FS とは

ここに、 Union mount と Union type file system の資料がある。
非常にわかりやすい説明だった。ここに、 aufs の説明もある。結構古いけど。。
http://www.oreilly.co.jp/community/blog/2010/02/union-mount-uniontype-fs-part-1.html ちょっとだけ簡単に自分用にまとめる。

union mount

filesystem A と filesystem B をマウントして、それぞれが file A, file B を同じディレクトリで持っていたとすると、
union mount をつかったとき、fileA, file B の両方のファイルが見える。

読み込み

open システムコールとかを通して呼ぶと、 union 機能が上から順に読んでいけば、差分的に一番新しいものを読める。
両方のファイルシステムが fileA を持っていて、その内容がちがう場合、filesystem の mount の優先度(レイヤー順?)で
どちらの filesystem の fileA が見えるか変わるんだと思う。

書き込み

なんらかを書き込んで差分ができたとき、上位ディスクとは違うものを保証しなければならないため、
上位ディスクのものをコピーして書き込む。だからコピーオンライト。
でもこの場合は、 copy-up と呼ばれて、プロセス fork でいうそれとは区別されている模様。

削除

ファイルが削除されても、上位ディスクには存在しているため、事実上削除ができない。
なので特別なファイルを作成することで消えたように見せる。(DB で言う論理削除みたいなもんだと認識)
whiteout という。

github 的な要素

index.docker.io レポジトリに image を push できる。
memcached を Dockerfile によって image を作る tutorial があるので、それをやった。
それでできた Dockerfile を使って repository に push した例を以下に示す。
ちなみに、 https://index.docker.io/account/ にあらかじめ登録しておいた。

vagrant@ubuntu-12:~$ docker login
Username: vimtaku
Password:
Email: ******@gmail.com
Login Succeeded

vagrant@ubuntu-12:~$ docker build -t vimtaku/memcached_sample - < Dockerfile

vagrant@ubuntu-12:~$ docker images
REPOSITORY                 TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
vimtaku/memcached_sample   latest              242bd405025e        22 seconds ago      217.1 MB
run_memcached              latest              5f1cda03f61c        17 hours ago        217.1 MB
memcached                  latest              9166d484dda8        17 hours ago        217.1 MB
brand_new_memcached        latest              7bdd82d0abf7        20 hours ago        217.1 MB
memcached_new              latest              c18168a45363        20 hours ago        245.5 MB
ubuntu                     12.10               426130da57f7        7 days ago          127.6 MB
ubuntu                     quantal             426130da57f7        7 days ago          127.6 MB
ubuntu                     10.04               8589d4e9c7c6        7 days ago          139.6 MB
ubuntu                     lucid               8589d4e9c7c6        7 days ago          139.6 MB
ubuntu                     12.04               72e10143e54a        7 days ago          125.9 MB
ubuntu                     latest              72e10143e54a        7 days ago          125.9 MB
ubuntu                     precise             72e10143e54a        7 days ago          125.9 MB
ubuntu                     13.10               721f07d19f96        7 days ago          144.6 MB
ubuntu                     saucy               721f07d19f96        7 days ago          144.6 MB
ubuntu                     13.04               476aa49de636        7 days ago          133.6 MB
ubuntu                     raring              476aa49de636        7 days ago          133.6 MB

vagrant@ubuntu-12:~$ docker push vimtaku/memcached_sample
The push refers to a repository [vimtaku/memcached_sample] (len: 1)
Sending image list
Pushing repository vimtaku/memcached_sample (1 tags)
511136ea3c5a: Image already pushed, skipping 
b74728ce6435: Image already pushed, skipping 
72e10143e54a: Image already pushed, skipping 
28d8e9cef54f: Image successfully pushed 
6be17bb13216: Image successfully pushed 
1b910f3ee9b7: Image successfully pushed 
18e04c08eb9b: Image successfully pushed 
2e32ba041afa: Image successfully pushed 
1cf353d00dd8: Image successfully pushed 
242bd405025e: Image successfully pushed 
Pushing tags for rev [242bd405025e] on {https://registry-1.docker.io/v1/repositories/vimtaku/memcached_sample/tags/latest}

出来上がりイメージ

所感

この記事では、 docker の一番の利点だと感じている、 image を簡単に作って試す、みたいな部分は書いていない。
すごい早さで image を作り出すことができるのには感動した。そこが一番の利点だと思う。
あと、この oreilly の資料は 3回くらい読む価値はありそうだ。

参考文献

http://ja.wikipedia.org/wiki/LXC
http://gihyo.jp/admin/column/01/vm/2011/lxc_container
http://ja.wikipedia.org/wiki/Cgroups
http://www.oreilly.co.jp/community/blog/2010/02/union-mount-uniontype-fs-part-1.html
http://teppeis.hatenablog.com/entry/docker
http://shibayu36.hatenablog.com/entry/2013/12/30/173949
http://2013.8-p.info/japanese/06-22-docker.html

docker

Chef についてのメモ2

chef の libraries を使う場合の今のところの俺の結論

以下に述べる、 1 の方法を使う。

とはいえ一長一短な気がするからどっちがいいって言えない。
ちなみに libraries から node はみたいよね、っていう前提。
あと、自分の環境(chef-solo, v11.8.2)にもよるかも。まぁ参考程度に。
もっといい方法あったら教えて下さい。
(っていうか意外に chef (libraries)のドキュメントって少ない気がする..)

libraries を使う方法

class MyClass みたいなクラスを定義して、 new するときに node 渡すようにして、あとは好きに使うパターン
module MyModule みたいなモジュールを定義して、extend してから、わかりやすいメソッドを呼び出して使うパターン

1. のメリット、デメリット

メリット

呼びたいメソッドを MyClass.method とかけるから、コードが読みやすいのではないだろうかということ。

デメリット

他のレシピからでも MyClass が使える

2. のメリット、デメリット

メリット

名前空間を汚染しない

デメリット

いちいち呼びたい recipe で extend とか書かなきゃいけない
呼び出すときに method_name だけしかないからちょっと読みにくいかも、と思った。 ruby ってそういうもん？

以下駄文メモ

class をつかう場合、名前空間を切って使用すると node が見えないので不便
- class Chef::Recipe にメソッドをはやして node を使えば見れる
- class Chef::Recipe::Hoge からは node はみえない
  - そんならChef::Recipe::Hoge みたいなインスタンスを new するときに node 渡して使えばいいんじゃね?
  - まぁできんことはない
- class Chef::Recipe にメソッド生やすのとかは Recipe が汚れるからやらない方がいい
- 単純に class MyClass みたいなやつを new してそれを使うのが吉かも
- でも libraries に定義しているから他のレシピから使われる可能性があって、閉じたい人的にはアレ
module をつかう場合
- extend Module名を使えば、 node は見えるし、使う場所が限られる
  - いちいち extend するのはめんどい
  - 呼び出すとき method 名だけになるからそれが許容できるならそれでもいいかも

http://vimtaku.github.io/chef/2014/01/24/chef-memo/

chef

一月ももう終わりそう

先週の振り返り

先週は chef と格闘しっぱなしだった。
まぁでも opsworks についての理解もかなり深まったし、
chef の感覚はものすごくつかめたのでよかった。
自分でも新しい recipe 複数かいたし。
でもなんだか仕事が忙しかった気がする。
あと、ブログのアウトプットも増えてきた。
だれに読まれようが関係ない気持ちで書くと案外かけるもんだ。
まぁ, Jekyll で書けるってのがかなり大きいんだけれども。

あ、あと ruby 書くために整理したかったので .vimrc を一新した。
そして今流行の homesick を使うようにした。
各環境で .zshrc とか違っている感があるので、徐々に改善していく。

勉強途中経過

進んだ

rails tutorial 6 までやった

読書途中経過

進んだ

詳解UNIXプログラミング第6章まで読んだ
プログラマの数学 4章まで読んだ
パーフェクトルビー5章まで読んだ
- 手を動かしながら ver

積んでる

オペレーティングシステム 6章まで読んだ
Webエンジニアのためのデータベース技術［実践］入門 7章まで読んだ
ネットワークはなぜつながるのか?
chef-solo 入門 #23 まで読んだ(どっかで手を動かしながらやる)

読み終えた

(2014/1/26)マスタリングTCP/IP 入門第5版とりあえず読み切った
(2014/1/13)読む筋トレ
(2014/1/8)ザ・コーチ最高の自分に出会える「目標の達人ノート」

life

Chef についてのメモ

概要

chef について、現時点でわかっている、知っておいたら役立ちそうなメモを書いておく。いわゆる実際ソース追えばわかるんだけど、まだソース追ってないので段階での現在わかっている挙動まとめ。

attribute の読み込み順について

attributes/default.rb が一番最初に読み込まれる
attributes/hoge.rb などの、attributes ディレクトリの他のファイルが辞書順に読み込まれる
node の値は各ファイルで上書きをすることができる

libraries について

libraries/hoge.rb などに、 Chef::Recipe::Hoge などのクラスを定義して、recipe から呼び出すことができる。
- Hoge.fuga_method として recipe から使用可能。
他のレシピを同時に実行するときでも、Hoge.fuga_method は使用可能。
libraries/mymodule.rb などに、 module MyModule などのモジュールを定義して、 recipe から呼び出すことができる。
- 自分がイマ実行しているレシピのみでモジュールを使用したい場合は、レシピに extend MyModule して特異メソッドとしてメソッドを生やす。
- 他のレシピでもモジュールを使用したい場合は、::Chef::Recipe.send(:include, MyModule) として Chef::Recipe クラスに include することで、my_module_method を呼び出せる。

chef 実行時のレシピについて

各レシピ、例えば first, second っていうレシピがあったとすると、それらは Chef::Recipe インスタンスである。
- chef 実行時に self をみればわかる

chef

Fog っていう Gem で Use_iam_profile があんまうまく行かない件

現象

iam_profile を使うことで、 aws_access_key や aws_access_secret を具体的に指定しなくても、
metadata な endpoint にアクセスして一時的な access_key と secret を取得できるようになっている(できたのは割と最近らしい)。
それなら、iam を使いたいわけなんだけど、 fog v1.18.0 と v1.19.0 で試しても use_iam_profile がうまくいかない。

呼び出しているクライアントライブラリは asset_sync v1.0.0 と elasticsearch v0.3.4 。
どちらも aws_credential fetcher で credential を取得してるみたいだけど、それを使ってないようにみえた。

対処

全部読んでないからわからないけど、俺の予想が合っていれば
credential を撮ってきたものを使用していないのでここが怪しかった。

lib/fog/core/service.rb

-options = options.merge(fetch_credentials(options))
+options = fetch_credentials(options).merge(options)

とりあえずもっと調べなきゃよくわからない。
これがうまくいっていそうなら pull req だしてみよう。

aws

Chef で Opsworks のインスタンス起動時に Cloudwatch の Alarm を作成するためにしたこと

TOC
大まかな流れ
1. IAM の設定
2. SNS のトピックの作成
3. cloud watch の API を cli から叩いてみる
- メトリックの作成 from cli
4. cloud watch での作成確認
5. chef recipe を書く
6. opsworks のレイヤー設定で、 setup ライフサイクルイベントで設定
- おまけ
  - 気をつけること要点
  - 標準出力から入力をし続けるからメモリに確保し続けるコマンド

大まかな流れ

IAM の設定
SNS のトピックの作成(メール送る用)
cloud watch の API を cli から叩いてみる
cloud watch の手動確認
chef recipe を書く
opsworks のレイヤー設定で、 setup ライフサイクルイベントで設定

ではさっそく。

1. IAM の設定

opsworks ではインスタンス生成時にデフォルトで Default IAM instance profile を設定できる。
ここの IAM Role に権限がないと、 aws cli から操作ができないので注意する。この記事では、IAMの設定については詳細に明記しない。

2. SNS のトピックの作成

コマンドラインか AWS Console から、メール送る用にトピックを作成する。
監視しているインスタンスの異常時にメールを受け取るため。
CLI ではこちらが参考になる。
http://exploreaws.doorblog.jp/archives/24701093.html
サブスクリプションを許可しておくと後々のチェックで捗る。
ちなみにこれは、あとで alarm-actions に指定する。

ここではできた topic が、仮に arn:aws:sns:ap-northeast-1:99999999:mogemoga としておく。

3. cloud watch の API を cli から叩いてみる

メトリックの作成 from cli

aws cloudwatch put-metric-alarm
--alarm-name='disk-usage' \
             --alarm-description 'Disk usage alert' \
             --alarm-actions='arn:aws:sns:ap-northeast-1:99999999:mogemoga'   \
             --namespace  'System/Linux'  \
             --metric-name  'DiskSpaceUtilization'   \
             --dimensions='[{"Name": "InstanceId","Value": "i-deadbeaf"},{"Name":"Filesystem","Value": "/dev/xvda1"},{"Name":"MountPath","Value":"/"}]' \
             --statistic  'Average' \
             --period  '300'   \
             --unit 'Percent'
             --threshold  '50'
             --evaluation-periods  '1'
             --region 'ap-northeast-1'
             --comparison-operator 'GreaterThanOrEqualToThreshold'

ここですんなりうまくいくかどうかが別れると思う。
IAM role を使う場合は、権限が許可されていれば問題なく通ると思う。
権限がない場合は、 cli の credential 設定が必要になるかもしれない。
http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/SettingUp_CommandLine.html

4. cloud watch での作成確認

上記のコマンドで成功していれば AWS Console から cloud watch のアラームができているはずなので確認する。

5. chef recipe を書く

あとは、上記 3 を実行する chef のレシピを書いて、 opsworks が取ってくる custom chef recipe のレポジトリに配置すればおｋ．
今回は load average もとりたかったので、
http://aws.amazon.com/code/8720044071969977
のスクリプトを改変して使用することにした。
ソースはこちら -> https://github.com/FumihikoSHIROYAMA/cloud_watch_script.git
disk space をとったりすることができる pl なのですごく便利。

下記の repository は crontab に上記の pl (load average は別) のものを登録するものだ。
https://github.com/alexism/cloudwatch_monitoring

これをフォークして、 load average とれる cron を作る機能と、アラーム登録する奴を書いた。
https://github.com/vimtaku/cloudwatch_monitoring.git
chef 力低めで申し訳なので、アドバイス、pull req など大歓迎。

6. opsworks のレイヤー設定で、 setup ライフサイクルイベントで設定

これはもう、 opsworks に慣れているひとなら問題無いと思う。
5 で作ったものがうまくいっていれば(というか試すときに deploy かどっかで試すと思うんだけど)
それを setup に移動してやるだけだ。

おまけ

気をつけること要点

IAM Role に権限がない場合があるので気をつける
- 参考
  - http://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/UsingIAM.html
  - http://docs.aws.amazon.com/AWSEC2/latest/APIReference/ApiReference-query-CreateVolume.html
opsworks では chef の data_bags が使えないのを頭に入れておく
- 自分はあとから気づいたパターン
  - 詳細は http://docs.aws.amazon.com/opsworks/latest/userguide/workingcookbook-chef11.html
mon-put-metric-alarm の代わりに aws cloudwatch put-metric-aaerm を使用する
- role の設定ができていても credential エラーとかいっぱい言われるため。
alert と alarm が似ているので alerm ってタイポに気をつける

標準出力から入力をし続けるからメモリに確保し続けるコマンド

/dev/null < $(yes)
cat - < $(yes)

aws

俺なりの自炊セットをそろえた

背景

覚悟を決めたので自炊セットを買うことにした。
電子書籍は最近出てくることが多くなったとはいえ、
すべてが電子書籍で販売されている訳ではないからだ。
Nexus7 を存分に生かすために買った自炊セットの
俺なりのベストプラクティスをここに記載する。

とはいえ、家にある本の数は100冊程度なので、
もしかしたら裁断サービスのほうが安く上がるかもしれないが
安値で自炊セットをそろえれば、家の雑多な書類とかも処理できるし
楽なのでそろえることにした。

とにかく安くそろえることを前提とした。

俺なりの結論

スキャナ
- image FORMULA DR-C125
裁断機
- カール事務器ディスクカッターA4サイズ対応丸刃40枚裁断(2往復) ブラック DC-210N

計、約3万円也。。

スキャナの選定

スキャナは実際すごくまよったが、とにかく安くそろえたかったので、
ScanSnap1500 の中古か image FORMULA DR-C125 にしようと思っていた。
結構比較記事があるので、ググってもらえばわかると思うけど、
SS1500は重送とかが結構おこるといわれていたのと、Amazon のレビューの評判が
そこそこよさげだったので、 image FORMULA DR-C125 にした。
安さの観点から、比較対象として SS1300 とか、ハンディスキャナとかがあったけど
SS1500 とのスキャンスピード比較動画が結構えげつない差だったので SS1300 はやめた。
ちなみに、 SS1500 よりも DR-C125 のほうが早い感じらしい。
ScanSnap1500 マジ良いみたいな話で、実際に使ったこと無いから比較できないけど、
DR-C125 はとても良いものだった。ちなみにヤフオクで約2万円で中古を買った。
なんていうか、Mac 用のドライバを普通にインストールして、
すぐにスキャンできた。OCR も効いている。
新品も Amazon で2.7万くらいなので、新品でも良いかもしれない。
アフィは張らない。

裁断機の選定

ローラーカッター(1000円)とカッターマット、定規で行けるかと思っていたんだけど、
分厚い本とか、マジ無理です。絶対無理。
いや、無理ではない、正確には。
でも、自炊とか効率的なことを考える人がやることではない。
カッターでもいい人は、新書とかばかりのひと。
それなら余裕。技術書はたぶん相当に厳しい。
なので、ちょうど今さっき、評判が割と良い DC-210N の裁断機を買った。
約1万円也。
どうなるかわからないが、絶対手動よりはマシだと思う。
それくらい、非現実的だと思う。行けると思っていた俺浅はか。

あとは読むだけ

自炊しっぱなしで読まないみたいなのがありそうだけど、必ず読むよ。
学習し続けることは、尊い。
たゆまぬ努力を続けよう。

自炊

Asset_sync

rails で asset pipeline を使って s3 に上げる手順について(opsworks使用)

参考URL

こちらを参考にした。 http://d.hatena.ne.jp/lettas0726/20130320/1363773153

Gemfile

gem 'uglifier', '>= 1.3.0'
gem 'asset_sync'

を追記。

deploy/before_migrate.rb

template "#{release_path}/config/asset_sync.yml" do
  mode "0644"
  source "asset_sync.yml.erb"
end

bash "precompile_assets" do
  user "deploy"
  cwd release_path
  code 'bundle exec rake assets:precompile RAILS_ENV=production'
end

今回は、 before_migrate で呼ぶことにする。
chef-solo で呼ばれるので resource が使える模様。
カスタム chef リポジトリに asset_sync.yml の template を用意しておく。
template は asset_sync.yml.erb としておいておく感じ。

config/environments/production.rb

hoge.example.com のバケットとしたとき、以下のように追記。

config.action_controller.asset_host = '//s3-ap-northeast-1.amazonaws.com/hoge.example.com'
config.assets.initialize_on_precompile = true

existing_remote_files オプションについて

アセットパイプラインでは、ファイルにおそらく md5 の hash 値がついているのを生成する。
ここで複数の rails インスタンスが非同期(もしくは片方のみ)なので
existing_remote_files: ‘delete’ として
precompile を実行するともともと参照していたファイルが消えてしまうので、
config/asset_sync.yml の中の existing_remote_files を keep にする。
(しかし、ゴミはのこる。対処については要検討。

chef

読む筋トレを読んだ

所感

筋トレのモチベーションが上がったというよりは、なぜ筋トレをするのか考えることにつながった。
自分はダイエットで成功体験があったり、筋トレは結構日常に組み込んでやってたときがあったけど、
仕事で一気に忙しくなったときにその習慣がなくなってしまった。
それをまたやる気にしてくれそうな雰囲気である。
この本では、ボディデザインという概念を提唱している。
ダイエットという引き算の発想から、筋トレをすることで自然に脂肪を減らすというものだ。
この考えには多いに賛成だが、実際のところ好きなものを食べて筋肉バキバキとかはちょっと無理がある。
食べ過ぎた次の日にはいっぱい筋トレして解消するみたいな考え方は確かに素晴らしいけどなぁ。
あと自分を知るということについてもすごく参考にはなる。
こと自分に至っては, 本当にお酒を飲むことがマイナスでしかない。
お酒を飲むとすごく食欲が増してしまってドカ食いしてしまうし。
なので無理せず減らすとかを考えるべきだと思う。

五分でいいから筋トレを日常に組み込むというのはすごく励みになる。
0じゃなく、多くなくてよいから1を繰り返せば 100 になるという発想。
これはかなり良い発想かもしれない。

自分にとっての筋トレの目的

はっきり言って映画トランスポーターに出てくるジェイソンステイサムのようになりたい。
すごく憧れる。俺の中で世界一かっこいいハゲ。
自分のポリシーをはっきりともちつつ、「立っているだけで笑わせる」と言い切る笑いへの価値観。
パーフェクトだ。

この如何ともしがたい理想との乖離を埋めるべく、ジムで筋トレをしようと思う。

leverage_memo

名言

小さいことを積み重ねるのが、とんでもないところへ行くただひとつの道だと思っています。(by イチロー)

TOC

はじめに

docker とは

LXC とは

aufs, Union FS とは

union mount

読み込み

書き込み

削除

github 的な要素

出来上がりイメージ

所感

参考文献

chef の libraries を使う場合の今のところの俺の結論

libraries を使う方法

1. のメリット、デメリット

メリット

デメリット

2. のメリット、デメリット

メリット

デメリット

以下駄文メモ

関連記事

先週の振り返り

勉強途中経過

進んだ

読書途中経過

進んだ

積んでる

読み終えた

概要

attribute の読み込み順について

libraries について

chef 実行時のレシピについて

現象

対処

TOC

大まかな流れ

1. IAM の設定

2. SNS のトピックの作成

3. cloud watch の API を cli から叩いてみる

メトリックの作成 from cli

4. cloud watch での作成確認

5. chef recipe を書く

6. opsworks のレイヤー設定で、 setup ライフサイクルイベントで設定

おまけ

気をつけること要点

標準出力から入力をし続けるからメモリに確保し続けるコマンド

背景

俺なりの結論

スキャナの選定

裁断機の選定

あとは読むだけ

rails で asset pipeline を使って s3 に上げる手順について(opsworks使用)

参考URL

Gemfile

deploy/before_migrate.rb

config/environments/production.rb

existing_remote_files オプションについて

所感

自分にとっての筋トレの目的