Docker Experimental Features を有効化すると使える docker build の --squash オプション

Docker コンテナを本番運用する場合，コンテナイメージのサイズをできる限り小さくすることを意識すると思う．具体的には「レイヤー」を意識することにより，Dockerfile に記述する RUN を減らしたり，一時ファイルを消す場合に同じ RUN で rm をする．最近だと「multi-stage builds」を使うこともできる．Dockerfile のベストプラクティスは，以下の公式ドキュメントに載っているし，最近では「Container Build Meetup」といったイベントもある．

docs.docker.com

docker build --squash とは？

Docker には「Docker Experimental Features」と呼ばれる仕組みがあり，有効化すると「実験的機能」を使えるようになる．現在だと「計6種類」の実験的機能があり，その中に docker build で使える --squash オプションがある．--squash オプションを使うと，自動的に「レイヤー」を1個に統合してくれるため，コンテナイメージのサイズを小さくできる．今回は --squash オプションを試すことにした．

• cli/experimental at master · docker/cli · GitHub
• docker build | Docker Documentation

Docker Experimental Features を有効化する

Docker for Mac の場合は Preferences の Daemon 画面から Experimental Features を有効化できる．

一般的な Linux 環境の場合は /etc/docker/daemon.json に以下の JSON を定義し，Docker プロセスを再起動すると有効化できる．

{
    "experimental": true
}

有効化したら docker version コマンドで確認できる．有効化せずに --squash オプションを使うとエラーになる．

$ docker version -f '{{.Server.Experimental}}'
false

$ docker build --squash  .
"--squash" is only supported on a Docker daemon with experimental features enabled

$ docker version -f '{{.Server.Experimental}}'
true

検証 1 : Alpine をビルドする

まず，alpine:3.9 を FROM に指定した Dockerfile を作成する．

FROM alpine:3.9

kakakakakku/playground:v1 として docker build をすると，5.53MB になる．

$ docker build -t kakakakakku/playground:v1 .

$ docker images | egrep 'REPOSITORY|kakakakakku/playground' | sort
REPOSITORY                                                                  TAG                 IMAGE ID            CREATED             SIZE
kakakakakku/playground                                                      v1                  055936d39205        5 weeks ago         5.53MB

検証 2 : 一時ファイルを作成する

次に，dd で 30MB の一時ファイルを作成する手順を追加した Dockerfile を作成する．

FROM alpine:3.9
RUN dd if=/dev/zero of=file bs=1M count=30

kakakakakku/playground:v2 として docker build をすると，37MB になる．

$ docker build -t kakakakakku/playground:v2 .

$ docker images | egrep 'REPOSITORY|kakakakakku/playground' | sort
REPOSITORY                                                                  TAG                 IMAGE ID            CREATED             SIZE
kakakakakku/playground                                                      v1                  055936d39205        5 weeks ago         5.53MB
kakakakakku/playground                                                      v2                  57c261ac2dd3        11 seconds ago      37MB

検証 3 : 一時ファイルを別レイヤーで削除する

「検証 2」の Dockerfile に一時ファイルを削除する手順を追加する．

FROM alpine:3.9
RUN dd if=/dev/zero of=file bs=1M count=30
RUN rm file

kakakakakku/playground:v3 として docker build をすると，同じく37MB になる．

$ docker build -t kakakakakku/playground:v3 .

$ docker images | egrep 'REPOSITORY|kakakakakku/playground' | sort
REPOSITORY                                                                  TAG                 IMAGE ID            CREATED             SIZE
kakakakakku/playground                                                      v1                  055936d39205        5 weeks ago         5.53MB
kakakakakku/playground                                                      v2                  57c261ac2dd3        42 seconds ago      37MB
kakakakakku/playground                                                      v3                  c54d6c94941b        10 seconds ago      37MB

docker history でレイヤーを確認すると，一時ファイルを作成するレイヤーと一時ファイルを削除するレイヤーが異なっている．よって，コンテナイメージのサイズは減らずに 37MB となる．

$ docker history kakakakakku/playground:v3
IMAGE               CREATED              CREATED BY                                      SIZE                COMMENT
c54d6c94941b        About a minute ago   /bin/sh -c rm file                              0B
57c261ac2dd3        2 minutes ago        /bin/sh -c dd if=/dev/zero of=file bs=1M cou…   31.5MB
055936d39205        5 weeks ago          /bin/sh -c #(nop)  CMD ["/bin/sh"]              0B
<missing>           5 weeks ago          /bin/sh -c #(nop) ADD file:a86aea1f3a7d68f6a…   5.53MB

検証 4 : 一時ファイルを同じレイヤーで削除する

今度は dd と rm を同じ RUN の中で実行することにより，レイヤーを1個にした Dockerfile を作成する．

FROM alpine:3.9
RUN dd if=/dev/zero of=file bs=1M count=30 && \
    rm file

kakakakakku/playground:v4 として docker build をすると，一時ファイルが消えたことにより 5.53MB に戻った．ベストプラクティスに載っている方法と言える．

$ docker build -t kakakakakku/playground:v4 .

$ docker images | egrep 'REPOSITORY|kakakakakku/playground' | sort
REPOSITORY                                                                  TAG                 IMAGE ID            CREATED              SIZE
kakakakakku/playground                                                      v1                  055936d39205        5 weeks ago          5.53MB
kakakakakku/playground                                                      v2                  57c261ac2dd3        About a minute ago   37MB
kakakakakku/playground                                                      v3                  c54d6c94941b        43 seconds ago       37MB
kakakakakku/playground                                                      v4                  0d9323b479c5        7 seconds ago        5.53MB

検証 5 : --squash オプションを使う

最後に --squash オプションを試すため，「検証 3」と同じ Dockerfile を作成する．

FROM alpine:3.9
RUN dd if=/dev/zero of=file bs=1M count=30
RUN rm file

kakakakakku/playground:v5 として docker build --squash をすると，なんと 5.53MB になっている！

$ docker build --squash -t kakakakakku/playground:v5 .

$ docker images | egrep 'REPOSITORY|kakakakakku/playground' | sort
REPOSITORY                                                                  TAG                 IMAGE ID            CREATED              SIZE
kakakakakku/playground                                                      v1                  055936d39205        5 weeks ago          5.53MB
kakakakakku/playground                                                      v2                  57c261ac2dd3        About a minute ago   37MB
kakakakakku/playground                                                      v3                  c54d6c94941b        About a minute ago   37MB
kakakakakku/playground                                                      v4                  0d9323b479c5        45 seconds ago       5.53MB
kakakakakku/playground                                                      v5                  46bf29424020        16 seconds ago       5.53MB

docker history でレイヤーを確認すると，COMMENT に merge とあり，レイヤーが1個になっている．確かに --squash されている．

$ docker history kakakakakku/playground:v5
IMAGE               CREATED              CREATED BY                                      SIZE                COMMENT
46bf29424020        50 seconds ago                                                       0B                  merge sha256:c54d6c94941b40e8f54833c0404791482f541deebdad37fcc50456bd279562f6 to sha256:055936d3920576da37aa9bc460d70c5f212028bda1c08c0879aedf03d7a66ea1
<missing>           About a minute ago   /bin/sh -c rm file                              0B
<missing>           2 minutes ago        /bin/sh -c dd if=/dev/zero of=file bs=1M cou…   0B
<missing>           5 weeks ago          /bin/sh -c #(nop)  CMD ["/bin/sh"]              0B
<missing>           5 weeks ago          /bin/sh -c #(nop) ADD file:a86aea1f3a7d68f6a…   5.53MB

まとめ

• 「Docker Experimental Features」を有効化すると「実験的機能」を使えるようになる
• docker build で使える --squash オプションを試した
• 一時ファイルの削除などを別レイヤーにしていても docker build のときにレイヤーを1個に統合できる

Redis で特定のコマンドを無効化できる設定「rename-command」

最近 Redis の公式ドキュメント「Redis Security」を読んでいたら「Disabling of specific commands」というトピックを発見した．簡単に表現すると redis.conf に rename-command という設定を定義すると，特定のコマンドを無効化したり，別名のコマンドに変更することができる機能と言える．例えば FLUSHALL や FLUSHDB など，もし運用上不要なコマンドがあれば，誤って実行してしまうことを防止することができる．rename-command は今まで使ったことがなく，試してみることにした．

redis.io

検証環境

今回は Mac に brew でインストールした Redis 5.0.5 を使う．

$ redis-server --version
Redis server v=5.0.5 sha=00000000:0 malloc=libc bits=64 build=31cd6e21ec924b46

$ redis-cli --version
redis-cli 5.0.5

CONFIG GET コマンドを実行する

まず，設定値を取得する CONFIG GET コマンドを通常通りに実行する．以下のように port と save の設定値を取得できた．

127.0.0.1:6379> CONFIG GET port
1) "port"
2) "6379"

127.0.0.1:6379> CONFIG GET save
1) "save"
2) "3600 1 300 100 60 10000"

CONFIG コマンドを無効化する

次に，公式ドキュメントに書いてある通りに redis.conf を修正する．

rename-command CONFIG ""

すると，CONFIG GET を実行しても unknown command となり，無効化されていた．

127.0.0.1:6379> CONFIG GET port
(error) ERR unknown command `CONFIG`, with args beginning with: `GET`, `port`,

127.0.0.1:6379> CONFIG GET save
(error) ERR unknown command `CONFIG`, with args beginning with: `GET`, `save`,

CONFIG コマンドを別名に変更する

次も，公式ドキュメントに書いてある通りに redis.conf を修正する．今度は CONFIG コマンドを推測不可能な別名に変更している．

rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52

すると，今度は b840fc02d524045429941cc15f59e41cb7be6c52 コマンドを使って，設定値を取得できた．

127.0.0.1:6379> b840fc02d524045429941cc15f59e41cb7be6c52 GET port
1) "port"
2) "6379"

127.0.0.1:6379> b840fc02d524045429941cc15f59e41cb7be6c52 GET save
1) "save"
2) "900 1 300 10 60 10000"

KAKKUSET コマンドと KAKKUGET コマンドを作る

運用上使うことはないけど，例えば KAKKU というプレフィックスを付けたコマンドを作ることもできる．同様に redis.conf を修正する．

rename-command SET KAKKUSET
rename-command GET KAKKUGET

すると，KAKKUSET コマンドと KAKKUGET コマンドを使えるようになる．

127.0.0.1:6379> KAKKUSET mykey "Hello"
OK
127.0.0.1:6379> KAKKUGET mykey
"Hello"

まとめ

• Redis の公式ドキュメント「Redis Security」を読んでいたら「Disabling of specific commands」というトピックを発見した
• redis.conf に rename-command という設定を定義すると，特定のコマンドを無効化したり，別名のコマンドに変更することができる

Shell で「テンプレートエンジン」のような仕組みを実現できる envsubst コマンド

少し前に envsubst コマンドの存在を知った．envsubst コマンドを使うと，変数展開など，Shell で「テンプレートエンジン」のような仕組みを実現できる．例えば，設定ファイルを生成するときなどに使える．なぜ今まで知らなかったんだろう！と思うけど，今回は envsubst の紹介記事を書きたいと思う．

準備

例えば Amazon Linux 2 など，環境によって，最初から envsubst コマンドが使える場合もある．もしインストールする場合は gettext パッケージに含まれているため，yum などを使ってインストールする．

$ yum install -y gettext
$ which envsubst
/usr/bin/envsubst

Mac なら brew を使ってインストールできる．インストール後に brew link を実行することを忘れずに！

$ brew install gettext
$ brew link --force gettext
$ which envsubst
/usr/local/bin/envsubst

なお envsubst コマンドの help を確認すると「環境変数の値を代入する」と記載されていた．

$ envsubst --help
Usage: envsubst [OPTION] [SHELL-FORMAT]

Substitutes the values of environment variables.

echo と envsubst を組み合わせる

まず，以下のように名前を ${NAME} として環境変数にした文字列を作成し，echo で標準出力をすると，そのまま出力される．

$ echo 'Hello ${NAME}'
Hello ${NAME}

次に，export で環境変数を設定して，標準出力を envsubst に流すと，${NAME} の部分が変数展開される．これは便利！

$ export NAME=kakakakakku
$ echo 'Hello ${NAME}' | envsubst
Hello kakakakakku

テンプレートファイルと envsubst を組み合わせる

検証用のテンプレートファイル profile.yaml.template を作成する．name と blog と github を Key とし，Value に環境変数を指定したシンプルな YAML ファイルにする．

name: ${NAME}
blog: ${BLOG_URL}
github: ${GITHUB_URL}

検証用のテンプレートファイルを cat で標準出力をすると，そのまま出力される．

$ cat profile.yaml.template
name: ${NAME}
blog: ${BLOG_URL}
github: ${GITHUB_URL}

次に，先ほどと同様に export で環境変数を設定して，検証用のテンプレートファイルを envsubst に流すと，Value の部分が変数展開される．環境ごとに異なる設定ファイルを生成できるようになった．これは便利！

$ export NAME=kakakakakku
$ export BLOG_URL=https://kakakakakku.hatenablog.com
$ export GITHUB_URL=https://github.com/kakakakakku

$ cat profile.yaml.template | envsubst
name: kakakakakku
blog: https://kakakakakku.hatenablog.com
github: https://github.com/kakakakakku

なお，ファイルと組み合わせる場合は cat を使わずに，直接流し込むこともできる．

$ envsubst < profile.yaml.template
name: kakakakakku
blog: https://kakakakakku.hatenablog.com
github: https://github.com/kakakakakku

まとめ

• envsubst コマンドを使うと，Shell で「テンプレートエンジン」のような仕組みを実現できる
• 設定ファイルを生成するときなどに使えて便利！

文化である DevOps の誤解を紐解こう /「Effective DevOps」を読んだ

先週から「Effective DevOps」を読んでいた．去年出版されたときにパラパラと気になる箇所を読んだけど，書評記事を書いていなかったこともあり，改めて読み直すことにした．本書は「DevOps」をテーマにしつつ，その本質としてはサブタイトルにもある「4本柱による持続可能な組織文化の育て方」となる．よって，タイトルだけを見て「DevOps の技術面」を学べるのかなと期待すると，ある意味期待を裏切られる可能性もあり，まず目次を見てみると良いかと．そのためにも目次を載せておく．

Effective DevOps ―4本柱による持続可能な組織文化の育て方

目次

• 第 Ⅰ 部 : devopsとは何か
  • 1章 : 大局を見る
  • 2章 : devopsとは何か
  • 3章 : devopsの歴史
  • 4章 : 基本的な用語と概念
  • 5章 : devopsに対する誤解とアンチパターン
  • 6章 : 効果的なdevopsのための4本柱
• 第 Ⅱ 部 : コラボレーション
  • 7章 : コラボレーション:ともに仕事をする個人たち
  • 8章 : コラボレーション:誤解と問題解決
• 第 Ⅲ 部 : アフィニティ
  • 9章 : アフィニティ:個人からチームへ
  • 10章 : アフィニティ:誤解と問題解決
• 第 Ⅳ 部 : ツール
  • 11章 : ツール :エコシステムの概要
  • 12章 : ツール:文化を加速させるもの
  • 13章 : ツール:誤解と問題解決
• 第 Ⅴ 部 : スケーリング
  • 14章 : スケーリング:変曲点
  • 15章 : スケーリング:誤解と問題解決
• 第 Ⅵ 部 : devops文化への架け橋
  • 16章 : devopsの4本柱を使って架け橋をつくる
  • 17章 : devops文化への架け橋:ストーリーから学ぶ
  • 18章 : devops文化への架け橋:人と人のつながりを育てる
  • 19章 : まとめ
  • 20章 : さらに深く学習するために

DevOps と devops

本書のタイトルは「Effective DevOps」だし，僕が今までブログ記事や発表資料に書いてきた表記も「DevOps」だけど，本書（タイトルを除く）では「devops」に統一されている．本書の冒頭に「Dev と Ops の対立ではなく，ビジネスを持続可能に進めていく手法」として，意図的に小文字表記にしたと書かれていた．とは言え，個人的に見慣れた表記は「DevOps」なので，本記事では「DevOps」に統一する．

誤解と問題解決

本書全体を通して興味深いのは，DevOps に対する「誤解」を問題提起し「問題解決」のために「誤解」を紐解くという観点でまとまっているところで，ある意味「アンチパターン集」としても活用できる．逆に言うと「こうすると DevOps である」という明確な定義はなく，そこは組織ごとに考える必要がある．

DevOps に対する誤解

本書には，よく聞く「DevOps の誤解」がまとまっていて，読みながら何度も頷いてしまった．その一部を以下に紹介する．

• DevOps はチームである
• DevOps は肩書だ
• DevOps はウェブ系のスタートアップだけの問題だ
• DevOps はツールの問題だ
• DevOps とは自動化のことだ

確かに最近だと「DevOps = 自動化」というコンテキストの発表も多いけど，正確には「自動化も重要だけど，組織の透明性やコラボレーションを意識しないと，自動化が未知のリスクになる」と書いてあり，考えさせられる．また，僕自身も2017年に一時期「DevOps エンジニア」と自己紹介をしていた時期もあり，恥ずかしくもある．

4本柱

本書では「DevOps とは何か？」という概論と歴史の紹介に続き，サブタイトルにもある「4本柱」の解説があり，以下のように定義されている．記事の冒頭にも書いた通り，文化面の話が中心になっている．それぞれ紹介していこうと思う．

• コラボレーション
• アフィニティ
• ツール
• スケーリング

4本柱「コラボレーション」

4本柱の1個目「コラボレーション」は，メンバー同士うまく協力することを意味している．協力とは言え，内容は幅広く，コミュニケーションの手段（即時性／負担／コンテキストなど）を適切に選んだり，傾聴を通じて共感と信頼を育てたり，双方向メンタリングを行うなども紹介されている．

特に「人それぞれ異なる目標（モチベーション）を持っている」という話は，今までも意識してきたものの，改めて考えさせられた．具体的には，現在のキャリアを重要視している人もいれば，カンファレンス参加などのネットワーキングを重要視している人もいれば，収入のための仕事であると割り切っている人もいる．エンジニアリングマネージャーやプロジェクトリーダーにも役立つ内容になっている．

なお，コミュニケーションの手段としては，即時性の観点で「雑談」も入っていたらもっと良さそうだなと思う．僕自身は「雑談」を大切にしていて，以下のような内容を発表したこともある．

kakakakakku.hatenablog.com

4本柱「アフィニティ」

4本柱の2個目「アフィニティ」は，チーム間の関係を築き，チーム目標の違いを乗り越えることで，4本柱の1個目「コラボレーション」の延長線上にあるとも言える．

「アフィニティの誤解」の中に「運用エンジニアは企業にとって開発者ほど役に立たない」という内容があるが，過去の経験として，運用エンジニアに限らず，特定のチームの価値を正しく理解できず，必要性を疑ってしまったこともある．今になって，うまく関係を築けていなかったなと反省している．心理的安全性という言葉でまとめるのが適切かどうかはわからないけど，チーム間の相互理解に悩みがあれば，読んでみるのが良いと思う．

4本柱「ツール」

4本柱の3個目「ツール」で，やっと技術面の話だ！と思うかもしれないけど，文化を改善するために目的意識を持ってツールを選定しようという内容になっている．DevOps を支える技術の詳細に興味があれば，例えば「Infrastructure as Code」などを合わせて読むと良さそう．

Infrastructure as Code ―クラウドにおけるサーバ管理の原則とプラクティス

読み進めていたら「ツールの選定」という内容に興味を持った．ツールを選定するときに，機能の有無や予算だけではなく，以下を考慮するべきと書かれていた．確かに「バージョンアップの頻度」や「プルリクエストの滞留具合」などは気になるし，日本語の解説記事なども，少なければ積極的に書くモチベーションには繋がるけど，ツールを選定する立場になると，コミュニティの健全性もしくは浸透度を考える必要もありそう．

• 製品の開発状況
• コミュニティの健全性
• 内部でのカスタマイズの可能性

また，自動化に対するスタンスとして「残りものの原則」という表現が紹介されている．「自動化に適切ではないタスクもある」という納得できる話なんだけど，引用元の論文タイトルに笑った．「Automation Should Be Like Iron Man, Not Ultron」ってもう．

queue.acm.org

4本柱「スケーリング」

4本柱の4個目「スケーリング」は，もしかしたら「インフラストラクチャのスケーリング」をイメージするかもしれないけど，組織変革など，組織が成長していくことを意味している．育成や採用，報酬やカルチャーフィットなど，どんな組織規模でも悩む内容がまとまっていて，一読の価値がある．

また「スケーリングの誤解」の中には「改革を始めるためには経営陣の全面的な支持が必要だ」という内容もあり，本書にも書いてある通り，裁量を与えてもらうべき場面と経営陣を巻き込むべき場面があり，適材適所に判断するのが良いと思う．個人的にも似た経験があり，以下にリンクを載せておく．全ては組織規模とフェーズによって異なると思う．

developers.cyberagent.co.jp

kakakakakku.hatenablog.com

まとめ

• 「Effective DevOps」を読んだ
• 本書は「DevOps」をテーマにしつつ，本質的には「DevOps の文化面」を事例と共に深く学べる内容になっている
• 特に「誤解」と「問題解決」という観点でまとまっているのは過去の経験を想起しながら読むことができて非常に良かった

Effective DevOps ―4本柱による持続可能な組織文化の育て方

コマンド失敗時に Mackerel にアラートを通知できる mkr wrap を試した

今年2月頃にリリースされた mkr コマンドの新機能 mkr wrap を試した．mkr wrap を使うと，指定したコマンドの失敗時に Mackerel にアラートを通知できるようになり，Worker プロセスなどのモニタリングに役立つ．詳細は以下の公式ドキュメントに載っている．

mackerel.io

今回は Amazon Linux 2 を検証環境として，最新バージョンの mkr を使う．事前設定が必要な mackerel-agent.conf などは割愛する．

$ mkr --version
mkr version 0.37.0 (rev:5789f43)

サンプルコード

今回はサンプルコードとして，正常時に終了コード 0 を返す，以下の check.sh を使う．

#!/bin/sh

echo 'Success!'

エラー時は終了コード 1 を返す．ブログ記事用にシンプルな実装にした．

#!/bin/sh

echo 'Error!' && exit 1

--name オプション

--name オプションを使うと，任意の監視名を設定できる．デフォルトだと mkrwrap-xxx-yyy というフォーマットの監視名になり，エラー発生時に判別しにくくなる可能性もあるので，--name オプションは基本的に使うと良さそう．今回はサンプルとして shell-checker とした．

$ mkr wrap --name shell-checker -- ~/check.sh
Error!
command exited with code: 1

実際にエラーを発生させると，Mackerel 側にアラートが通知された．監視名も正しく shell-checker になっている．

--auto-close オプション

実装によっては，次回実行時に正常終了になれば自動復旧と判断できる場合もあると思う．Mackerel の仕様として，通知されたアラートを意図的に終了する必要があるけど，--auto-close オプションを使うと，自動的にアラートを終了できるようになる．必要に応じて，使うと良さそう．実際に試したところ，自動的に終了されていた．

$ mkr wrap --name shell-checker --auto-close -- ~/check.sh
Success!

なお，公式ドキュメントに記載がある通り，--auto-close オプションを使うと一時領域に実行結果ファイルを保存し，次回実行時に参照する仕組みになっている．今回の検証環境だと /tmp/mkrwrap-shell-checker.json に実行結果ファイルがあった．なお，mkr コマンドの実装を確認したところ，一時領域の取得は os.TempDir() になっていた．

github.com

--notification-interval オプション

通知されたアラートを定期的に再送する場合は --notification-interval オプションを使う．オプション引数としては 10m や 1h など，再送間隔を指定する．個人的にはアラートが通知された後に指定した間隔で自動的に再送されるのかなと予想したけど，実際に動作確認をしてみると，2回目以降のエラーが発生したときに指定した間隔を超えている場合に再送されるようだった．

$ mkr wrap --name shell-checker --auto-close --notification-interval 10m -- ~/check.sh
Error!
command exited with code: 1

なお，試していたら公式ドキュメントに誤記を発見したため，プルリクエストを送っておいた．既に merge してもらっている．

github.com

Mackerel 関連のドキュメントは今年3月頃に OSS 化されている．気になる誤記などがあれば，積極的にプルリクエストを送ると良さそう！

mackerel.io

まとめ

• mkr wrap を試した
• 指定したコマンドの失敗時に Mackerel 側にアラートを通知できるようになる
• 多くのオプションがあり，他にも今回紹介しなかった --detail オプションや --note オプションもある

「Mackerel アンバサダー」として，積極的にアウトプットをしていくぞ！