DockerのImageサイズがどこで肥大化したか調べる方法

このエントリーをはてなブックマークに追加
docker history <イメージ名> で、イメージがどのようにビルドされてどの段階で肥大化したかを調べることができます。

手元のPerlアプリで調べてみたらこんな感じでした。
$ docker history dqneo/perllwpstarmans3exif
IMAGE               CREATED             CREATED BY                                      SIZE
24ad7cae95e0        7 weeks ago         /bin/sh -c cpanm Class::Accessor::Fast     &&   75.36 kB
a374089b9a87        7 weeks ago         /bin/sh -c cpanm Digest::HMAC_SHA1     && rm    38.26 kB
bb9668879cfe        7 weeks ago         /bin/sh -c cpanm URI::Escape     && rm -rf /r   70 B
d9e0f852db62        7 weeks ago         /bin/sh -c cpanm MIME::Base64     && rm -rf /   61.99 kB
18e7699f4f14        7 weeks ago         /bin/sh -c cpanm Config::Tiny     && rm -rf /   24.82 kB
d0585c3c8a70        7 weeks ago         /bin/sh -c cpanm JSON::XS     && rm -rf /root   291.8 kB
98528ff0b06b        7 weeks ago         /bin/sh -c cpanm Image::ExifTool     && rm -r   13.99 MB
ba92c61189cd        7 weeks ago         /bin/sh -c yum install -y openssl openssl-dev   15.67 MB
a65d10337ea9        7 weeks ago         /bin/sh -c #(nop) MAINTAINER DQNEO              0 B
ec2f7d4b2dbd        7 weeks ago         /bin/sh -c cpanm Starman     && rm -rf /root/   904.9 kB
7979b8bc0215        7 weeks ago         /bin/sh -c cpanm Plack     && rm -rf /root/.c   1.126 MB
8a70ddccac6d        7 weeks ago         /bin/sh -c cpanm HTTP::Body@1.19     && rm -r   604.8 kB
dee1341f353a        7 weeks ago         /bin/sh -c #(nop) MAINTAINER DQNEO              0 B
3b4d67b029f9        7 weeks ago         /bin/sh -c cpanm LWP::UserAgent     && rm -rf   921.8 kB
81e34aa11cdf        7 weeks ago         /bin/sh -c cpanm URI HTTP::Date HTTP::Request   713.5 kB
6de75ba6702d        7 weeks ago         /bin/sh -c #(nop) MAINTAINER DQNEO              0 B
7a77c29cea2f        7 weeks ago         /bin/sh -c #(nop) CMD [perl -v]                 0 B
4e0c822ae517        7 weeks ago         /bin/sh -c #(nop) WORKDIR /root                 0 B
4fa97c05dec4        7 weeks ago         /bin/sh -c cpanm Carton     && rm -rf /root/.   1.529 MB
94ea5cc2cb87        7 weeks ago         /bin/sh -c (curl -L http://cpanmin.us | perl    2.262 MB
6ab72950d8e8        7 weeks ago         /bin/sh -c #(nop) ENV PATH=/opt/perl/bin:/usr   0 B
1b546ba48396        7 weeks ago         /bin/sh -c curl -SL https://cpan.metacpan.org   48.65 MB
b0e272cb9d2f        7 weeks ago         /bin/sh -c #(nop) ENV PERL_PREFIX=/opt/perl     0 B
a922dd15ecf2        7 weeks ago         /bin/sh -c #(nop) ENV PERL_ARCHIVE=perl-5.20.   0 B
c31d221ee4b9        7 weeks ago         /bin/sh -c #(nop) ENV PERL_VER=5.20.1           0 B
330c7693bbe8        7 weeks ago         /bin/sh -c #(nop) WORKDIR /usr/src/perl         0 B
9347191a7cc6        7 weeks ago         /bin/sh -c mkdir /usr/src/perl                  0 B
43839d3d2df7        7 weeks ago         /bin/sh -c yum -y install tar bzip2 gcc make;   70.3 MB
f8dc005bb3c6        7 weeks ago         /bin/sh -c yum -y update; yum clean all         147.5 MB
1c3055bdb2d6        7 weeks ago         /bin/sh -c #(nop) MAINTAINER DQNEO              0 B
8efe422e6104        10 weeks ago        /bin/sh -c #(nop) ADD file:3aa368f7652ffed32e   210 MB
5b12ef8fd570        5 months ago        /bin/sh -c #(nop) MAINTAINER The CentOS Proje   0 B
511136ea3c5a        21 months ago                                                       0 B
下が始点で上が終点です。
順番に見ていくと、

下から3行目のADDで210MB増えてます。これは、FROMで指定したベースイメージ(centos:latest)のビルド過程と思われます。

次に下から5行目の yum update で147MB増えてます。これは・・う〜ん悩ましい。

次に、下から12行目の "curl -SL https://cpan.metacpan.org.." で48MB増えてます。
これはPerl本体のインストールです。

とまあこんな感じで、イメージ肥大化した犯人を突き止めて、そこを改善していけば効率よくダイエットできるかと思います。

今回のケースだと yum updateが一番重かったので、yum updateの対象をちゃんと指定して絞り込めばよいかもしれません。
もしくは、ベースイメージをCentOS(210MB)ではなくDebian(85MB)にするのがよさそうです。

yum updateでkernelを除外する方法

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

コマンドラインで指定する方法

yum -y update --exclude=kernel*
とすればkernel関係がアップデートされるのを防ぐことができます。

一瞬、「この書き方だとワイルドカードがファイル一欄に展開されてしまうのでは?」という気がするのですが、この書き方で大丈夫です。

/etc/yum.confで指定する方法

exclude=kernel*

と記述すればOKです。

git pull, git rebaseはシェルスクリプトで実装されていた

このエントリーをはてなブックマークに追加
こちらの記事
git pullは、fetchしてmergeするのと同じなのか? | GMOメディア エンジニアブログ
git pullの正体:
実は git pull はC言語で実装されていません。git-pull.shというシェルスクリプトです。
を見て、ええっ?と思って確認してみたら本当にそうでした。

確認してみた

gitのサブコマンドのうち、スクリプト言語で実装されているものをリストアップしてみました。
(gitはMac OSXにhomebrewでいれたやつです)

MongoDB2.6でdb.upgradeCheckAllDBsという便利コマンドが登場してた

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

要約

upgradeCheckAllDBsを使うと、v2.4 → v2.6のアップグレード前のチェックができます。

使い方

MongoDBのクライアントv2.6から、db.upgradeCheckAllDBs()というコマンドが実装されており、バージョンアップグレード前のデータ不整合チェックができます。

Movable Type Open Source (MTOS)の提供はまだ続いている

このエントリーをはてなブックマークに追加
誤解してる人が多いようなので書いておきます。

今北産業

  • MTOS(MT5.2.x)の開発は今も続いている。
  • MTOS(MT5.2.x)の開発は、2015年10月まで行われる。
  • 2015年10月以降に開発が停止した後も、MTOS(MT5.2.x)はGithub上で公開され続け、誰でも利用することができる。

公式サイトより引用

MTOSのセキュリティサポートは続くのでしょうか?

はい、続けます。MTOSの最終バージョンはMT 5.2xとなりますので、MT5.2xと同じライフサイクルポリシーに基づいて、セキュリティ対応を続けます。MT6は2013年10月のリリースを予定しているため、MTOS を含めた MT 5.2xは2015年10月まで、重大な問題に対するセキュリティフィックスを続けます。

ライフサイクルポリシーについては、こちらのページをご覧ください。

5.2のリポジトリは、Githubで継続公開されますか?

はい、継続して公開を続けます。Githubには、MTのリリースバージョンごとに「タグ」と呼ばれるバージョンごとのレポジトリデータが存在します。

http://www.movabletype.jp/blog/mtos_support.html

Githubを見ると開発が続いていることがわかる

実際にGithubを見てみると、現時点(2014/12)でも5.2.11の開発が続いており、ライセンスファイル(COPYING)にGPL v2と明記されていることがわかります。

https://github.com/movabletype/movabletype/tree/mt5.2.11

「MTOSを捨ててMT6に移行しなければならない」なんてことはないので、引き続きMTOSを使い続けるという選択肢も当然ありです。
このブログはMTOSで動いており、私は今後もしばらくはMTOSを使い続けるつもりです。

printfでバイナリhello world

このエントリーをはてなブックマークに追加
Linux/Unixでprintfを使うと、バイナリ(16進数)でHello Worldできます。

文字コードの調査をしたいときや、バイナリファイルの読み書きをしたいときにこれを覚えておくと大変便利です。
$  printf "\x61\n"
a
こんな感じで "\x" の後に続けて16進数を書きます。
$  printf "\x68\x65\x6c\x6c\x6f\n"
hello
ちなみに zshだとechoでもこれができます。
(bashのechoではできませんでした。)
$ echo "\x68\x65\x6c\x6c\x6f"
hello

printfで日本語を表示

UTF-8の「あ」を表示
$ printf "\xE3\x81\x81\n"
ぁ
EUC_JPの「あ」
$ printf "\xA4\xA1\n"
Shift_JISの「あ」
$ printf "\x82\x9F\n"

vagrant global-status --pruneでゾンビ仮想マシンを削除する

このエントリーをはてなブックマークに追加
消したはずの仮想マシンが vagrant global-status で表示されてしまう場合、--pruneオプションをつければゴミ掃除してくれます。

vagrant global-status は、存在しない仮想マシンを表示してしまうことがある。

$  vagrant global-status
id       name    provider   state    directory
-------------------------------------------------------------------------
55f191d  default virtualbox poweroff /Users/DQNEO/hoge/kitchen
8486738  default virtualbox running  /Users/DQNEO/hoge/kitchen2
2aa592d  default virtualbox running  /private/tmp/chef-repo
97b443d  default virtualbox poweroff /Users/DQNEO/vagrants/emacs
4a39c61  default virtualbox poweroff /Users/DQNEO/vagrants/hhvm
e440391  default virtualbox running  /Users/DQNEO/vagrants/kqui-kitchen

The above shows information about all known Vagrant environments
on this machine. This data is cached and may not be completely
up-to-date. To interact with any of the machines, you can go to
that directory and run Vagrant, or you can use the ID directly
with Vagrant commands from any directory. For example:
"vagrant destroy 1a2b3c4d"
仮想マシンが6個も表示されていますが、本当はこのうち3個はサクジョ済みなので実在しないのです。

vagrant global-status --pruneでゴミ掃除

$  vagrant global-status --prune
/Users/DQNEO/vagrants/hhvm/Vagrantfile:5: warning: already initialized constant VAGRANTFILE_API_VERSION
/Users/DQNEO/hoge/kitchen2/Vagrantfile:5: warning: previous definition of VAGRANTFILE_API_VERSION was here
/Users/DQNEO/vagrants/kqui-kitchen/Vagrantfile:5: warning: already initialized constant VAGRANTFILE_API_VERSION
/Users/DQNEO/vagrants/hhvm/Vagrantfile:5: warning: previous definition of VAGRANTFILE_API_VERSION was here
id       name    provider   state    directory
-------------------------------------------------------------------------
8486738  default virtualbox running  /Users/DQNEO/hoge/kitchen2
4a39c61  default virtualbox poweroff /Users/DQNEO/vagrants/hhvm
e440391  default virtualbox running  /Users/DQNEO/vagrants/kqui-kitchen
ゾンビマシンが消えて、ちゃんと3個になりました!

cdせずに任意のgitレポジトリを操作する-Cオプションの紹介

このエントリーをはてなブックマークに追加
例えば、git pullとかするときはcdしてからgit pullする人が多いと思います。

たとえばrbenvをアップデートしたいとき、
$ cd ~/.rbenv
$ git pull
$ cd ~/.rbenv/plugins/ruby-build
$ git pull
なんてしますよね。
でもいちいち cd するの面倒くさいと思いませんか?

実はgitには -C オプションというのがあって、これを使うと cd せずにレポジトリの場所を指定することができます。
git -C <レポジトリの場所> サブコマンド
という風に使います。

なので、さっきの rbenvを更新する例はこのように書けます。
$ git -C ~/.rbenv  pull
$ git -C ~/.rbenv/plugins/ruby-build  pull
シェルスクリプとかcrontabから git を実行するときは大変便利です。

改行に置換するためのワンライナー集(tr/sed/perl)

このエントリーをはてなブックマークに追加
ある文字を改行「に」置換する方法を紹介します。

事例:$PATHの中身が長くて見にいので、":"を改行に置換したい

$ echo $PATH
/Users/DQNEO/.rbenv/bin:/Users/DQNEO/.rbenv/shims:/Users/DQNEO/.plenv/bin:/Users/DQNEO/.plenv/shims:/usr/local/opt/coreutils/libexec/gnubin:/usr/local/bin:/Users/DQNEO/bin:/usr/bin:/bin:/usr/sbin:/sbin
横に長いので、改行で区切りたい!

trで置換

こういう場合は、trコマンドを使うのが一番簡単です。
$ echo $PATH | tr ':' '\n'
/Users/DQNEO/.rbenv/bin
/Users/DQNEO/.rbenv/shims
/Users/DQNEO/.plenv/bin
/Users/DQNEO/.plenv/shims
/usr/local/opt/coreutils/libexec/gnubin
/usr/local/bin
/Users/DQNEO/bin
/usr/bin
/bin
/usr/sbin
/sbin

sedで置換

$ echo $PATH | sed 's/:/\n/g'
ただしMacOSX のsedの場合、これでは動きません。GNU sedを使いましょう。
"Homebrew を使って OSX に GNU sed を入れる - おともだちティータイム"

Perlで置換

PerlならMac / Linux などOS関係なく同じ挙動なので安心です。
$ echo $PATH | perl -pe 's/:/\n/g'

Emacsのshell,iTerm2,zshの組み合わせで変な制御文字が表示されてしまうバグ

このエントリーをはてなブックマークに追加
emacs-shell-iterm2-bug.png

Emacsのshell (M-x shell) をMax OSXのiTerm2で使うとこのような変な制御文字が表示されてしまいました。
^[]2;echo hello^G^[]1;echo^Ghello

原因が皆目検討がつかないので見て見ぬふりをしていたのですが、この制御文字があまりにもウザくて、いつの間にか M-x shell を使わなくなっている自分がいました。

これではいかんと一念発起して解決するまでの一部始終です。

Linuxでは発生しない?

まず、詳しそうな友人に聞いてみたところ、「僕のLinuxでは発生しない」とのことでした。
確かにLinuxでは発生しませんでした。
友人いわく、「zshかscreenかiTerm2が、ウィンドウのタイトルを自動設定しようとしているのが原因じゃないか」とのこと。

iTerm2のときだけ発生する

Mac OSXの標準のターミナルでは発生しませんでした。iTerm2のときだけ発生しました。

Zshを使うと発生する

M-x shellしたあとに、"bash"と入力してインタラクティブシェルをbashに切り替えると直りました。
どうやらzshが原因のようです。

ここまでで、「MacのiTerm2でEmacsのshellでzshを使った時に発生する」ということがわかりました。

ただ、ここで行き詰まってしまいました。

.zshrcに原因がある

はてな人力検索で質問してみたら、「私の環境では再現しない」とのコメントをいただきました。
なるほど?これはもしかして .zshrcの内容に原因があるかもしれないと思いました。
.zshrcにごちゃごちゃ設定を書いていたので、「.zshrcを消して素のzshを起動するとどうなるだろう」とやってみたところ、現象が直りました。

そこで、.zshrcの真ん中あたりに"return"を書いてみて、二分探索の手法でどこで不具合が起きるのかを調べました。

oh-my-zshが原因だった

oh-my-zshを外してみたら直りました。どうやら oh-my-zshを使っているのが原因でした。

テーマを変更しても発生する

oh-my-zshのテーマが悪いのかと思いテーマをいろいろ変更してみましたが、どのテーマでも発生しました。
どうやらテーマに関係なくoh-my-zsh自体に原因がありそうです。

DISABLE_AUTO_TITLE="true"にしたら直った!!

oh-my-zshの設定を見ていると、下記の設定があることに気づきました。
# Uncomment following line if you want to disable autosetting terminal title.
# DISABLE_AUTO_TITLE="true"
こ、これは・・・!!
冒頭で友人が言っていたことと関係がありそうです。

というわけでこのコメントを消して DISABLE_AUTO_TITLE="true" を有効にしたところ、見事に解決しました!!

よかったよかった。
購読する

最近の人気記事

人気記事