Docker for Mac OS Xが便利すぎるので、SDI構築環境をSDI化してみた件。

DockerCon16でパブリックベータになったDocker for Mac OS Xを早速使ってみています。これ、すこぶる便利。いろいろ触ってみて、何ができるかな、と考えていたのですが・・・クライアント（デスクトップ）環境のポータビリティに使えそうかな、と思った件。

Docker for Mac OS X

これまでMacでDockerを動かす場合、KitematicとVirtualBoxを導入して、VirtualBox上で動作するboot2docker環境をdocker-machineからホストに使うのが通常の構成だったと思います。そんな中、DockerCon16で公式版のDocker for Mac OS Xがパブリックベータになったので、早速入れてみました。

Dockerのサイトから、普通にインストールパッケージがダウンロードできますので、これで何も考えずにインストールすれば、Dockerサービスが動き出します。非常にお手軽です。

稼働するDocker hostは、xhyve上のLinuxです。これはOS Xのネイティブhypervisorを使う仮想マシンで、リソースモニタで見ても、VirtualBoxなんかに比べるとかなり軽い印象です。ホストOSは確かarchLinuxだったような気がしましたが、どうやって調べたか忘れました・・・。

パブリックベータだけあって、バージョンは1.12のRCです。新しいって素敵です。

使用感と、SDI開発環境としてデスクトップで使う試み

入ってしまえば、普通にdockerコマンドで操作できます。イメージをpullして、runして、detachして、attachして、とか、この辺の使用感は全く普通のdockerです。

一つ、この調査の過程で、「detachKeys」が1.10以降、使えるようになったことが分かりました。これはinteractiveセッションをdetachするときのキーアサインを、標準の「Ctrl-p,p」から変更できる設定です。これでシェルでヒストリ手繰る時、Ctrl-pがhookされてムキーってなることが無くなります。

ということは、docker環境がコンソール環境として使いやすくなったということです。

そこで、今、dockerをコンソールの開発環境にする、というのを試しています。Macで例えばansibleを使うとか、AWSやAliyunのクライアント環境を作る場合、HomeBrew等でアプリをインストールして使うという方法がありますが、HomeBrewの環境って本体のバージョン上げたりすると結構環境がしっちゃかめっちゃかになったり、そもそもMacに標準外の方法でアプリ入れたくなかったり、python等のツールのバージョンの制限があったり、と、デスクトップ環境についても、サーバー環境と同様に、環境依存・環境汚染のリスクがあることを感じていました。

なので、日常的には、「踏み台サーバー」を作って、そこにログインしてtmux（ターミナルマルチプレクサ）で作業する、というのが通例化していたわけですが、これだと、「踏み台サーバー」の環境を維持する必要があり、じゃぁこの「踏み台サーバーの構成管理はどうする」とか、どうやってアクセス環境を維持するのか、という、ニワトリタマゴみたいな話が出てきます。

Mac本体で仮想サーバーを動かすという方法もあります。踏み台サーバーを仮想サーバーでローカルに立てて、例えばvagrant sshするという形です。これはこれで悪くはないのですが、VirtualBoxはやっぱり重いので、ちょっと気兼ねがありました。

というわけで、Docker for Mac OS Xを、普段使いのコンソール環境の開発環境にすることで、クリーンな端末環境を維持できないか、と思ったわけです。DaaS環境的な使い方、とでも言えば良いですかね。

いきなり結果です。サンプルはこちら→　https://github.com/tkshimada0912/aliyuncli

このサンプルは、dockerコンテナ内にaliyuncliとansibleの環境を作り上げて、AlibabaCloudのサーバー構築環境を、コンテナ内で、実現するものです。クラウドサーバー構築作業をこのコンテナ内で行う、という試みになります。

この構成のポイントは、「SDI構築環境をSDI化する」というところ。なんだそれ、って感じですが、作業環境自体を、runしてrmしてしまうと。メリットは、サーバー環境を操作する環境自体がimmutableになるため、例えばヒストリに依存した操作や（苦笑）、undocumentedな、「環境構築」用環境の汚染を抑止することができるということ。

またこのgitリポジトリは要するにdotfilesみたいな状態なので、どこのマシンでも、このコンテナを展開すれば、同じ作業環境が実現できます。当たり前といえば当たり前なんですが、意外にこれは便利です。いわゆるアプリ開発環境の考え方を、基盤担当者の作業環境に適応しています。当然、python等のツール環境はコンテナ内に隔離されていますので、元となっているMacの環境に変更は入っていません。

実際使ってみると、このコンソール環境の仮想化は、なんだかいろんなことができそうで楽しい感じです。

Dockerでのimmutableコンソールは意外に使える・・・かも？

そんな訳で、Docker for Mac OS Xは、便利だよ、という話。コンソール環境のコンテナ化みたいな使い方も面白そうですので、いろいろ試してみたいと思います。もしかしたら、「最高のコンソール環境」の定義が、iTerm2＋tmux＋zsh＋docker、になるんじゃないか、と密かに思っています。

・・・あ、という訳で、当然の如く、次はdotfilesですね。