こんにちは、池田です。

新しいサイトを構築してリリースするのは花形仕事ですが、使っているソフトウェアのバージョンアップや、ちょっとした機能追加、不具合の調査などもウェブサイトを支える重要なイベントです。

シナップでは、こういう時にSaharaというVagrantプラグインやDockerを使ってリセマラをしています。これらを実際に使った事例を交えて紹介してみたいと思います。

Sahara

SaharaはVagrantプラグインの一つです。まずVagrantを説明します。

VagrantはVirtualBoxやVMwereといった様々な仮想マシン用ソフトウェアや、DigitalOceanといったVPSなどを統一的に使えるソフトウェアです。インターフェイスがVagrant専用の設定ファイルとコマンド群に統一されるので、多くの場合、背後で動いている仮想マシン用ソフトウェアの違いを意識しないで済みます。Vagrantその物はクロスプラットフォームで動作するので、Linuxの仮想マシンを動かす時でも、OS X上で行うことができます。

エコシステムが発達しているのがVagrantの大きな特徴で、Debian GNU/LinuxやCentOSなどの公式ベンダーが、Vagrant用の仮想マシンイメージを配布していますし、自分の組織や個人でイメージを作って配布することもできます。例えば、WordPressに必要な各種ソフトウェアをインストールし、適切に設定した状態の物をVagrantのイメージにして社内で共有しておけば、案件ごとに使い回すことができるようになります。

シナップでも、新規サイトを作成する際に、サーバーの設定を試行錯誤する環境として使うなど、日常的に大活躍しています。

ただ、同じイメージを使っていても、今の状態を保存しつつ別の設定を試すためにVagrantを起動すると、その分イメージのコピーが作成されます。コピーの処理に数分待たされてしまうため、「別の設定を試したいから、新しく仮想マシンを作り直す」ということに心理的な抵抗を覚えてしまいます（勿論、比較の問題で、レンタルサーバーなどを契約し直すことに比べれば圧倒的に簡単なので、使い始めた頃は大喜びしました。人間は贅沢な環境にすら慣れていってしまうものです、罪深い......）。

これを見事に解決してくれるのがSaharaです。Vagrantエコシステム発達の例としてイメージの流通を挙げましたが、サードパーティ製のプラグインが数多くあることも特長です。Saharaはそうしたプラグインの一つです。

SaharaはVagrantに「サンドボックスモード」を提供します。サンドボックスモードにしている間に行った変更は、いつでもサンドボックスモード開始時点に巻き戻すことができます。その変更が気に入れば、巻き戻さず「確定」させることもできます。

Vagrant：

Sahara：

少しずつ前に進んでいる様子が分かりますね。このように手戻りのコストが、素のVagrantで仮想マシンを作り直しながら試行錯誤するよりもずっと低いので、CMSの更新や新バージョンの追加など、途中どこかで失敗してしまうかも知れないことの検証には大変役立ちます。

また、MySQLなどデータベースのデータを、何もしないで巻き戻せるというのも、地味ですが心理的に安心できる材料です。データの不整合などの不具合では、様々なデータの組み合わせを試す必要があります。しかし、一度に様々なことを試していては本当の問題が隠れてしまうため、「最初の状態」に立ち返りながら一度に一つ試すのが定石です。原状を保存しておいて、サンドボックスの中で一つずつ試せば、どういったデータの組み合わせが問題なのかはっきりと切り分けられます。

CMSベンダーに不具合報告をする際、「ではこうした場合はどうでしょうか」「このパッチを試してみてください」といったやり取りになるのが普通ですが、それを試す時も原状復帰をすぐに行えるので簡単です。そうでなければ「もう、検証の時に色々とデータを変えてしまったから、データベースのデータをまた入れ直さないといけないな、更にCMSのソースコードもバックアップから戻さないと......」と、億劫になってしまいますし、実際効率も悪くなります。そのためのスクリプトを書いて自動化したりもします。しかし、案件が異なりディレクトリーが違うだけで使い回しにくかったりするので、毎度作成するにも費用対効果の言葉が頭のなかにちらついてしまいます。

シナップの中では、Saharaは仮想マシンの「リセマラ」を可能にするツールとして活躍しています。リセマラをしたくなる気持ち、と言えば、みなさん共感してもらえると思います。

Docker

Dockerは、Linuxの様々な機能をうまく組み合わせて、ホストマシンから隔離された仮想環境を手軽に作れるツールです。この仮想環境（コンテナと呼ばれます）をあるマシンから取り出して別のマシンに移せるのが特徴で、Dockerさえ動いていれば、Ubuntuで作成したコンテナをCentOSで動かすといったことにも問題がありません。また、コンテナはOSの全体を閉じ込めているわけではないので、仮想マシンよりも起動時間がずっと速くなったりもします（一秒未満から数秒程度が殆どです）。

どこで動作させても同じ環境が保たれるということから、開発環境もDockerにして、それをいかに本番環境にデプロイするかというところに注目が集まっているように思います。「開発中は問題なく動作していたのに、本番環境にデプロイしたらエラーになる」といったことを格段に減らせるようになるからでしょう。同じ理由で、Travis CIなどのCIサービスでもDockerを動かせる所が殆どです。プレビュー環境も然りですね。

シナップでもDockerを活用していますが、こういった用途では使っていません。何に使っているかと言うと、Movable Type（MT）プラグインの動作検証です。

シナップサイトのお問い合わせフォーム、採用応募フォームには、MTのMailFormプラグインを使っています。ただ、シナップではMT6の採用経験がこれまでになく、プラグインの方もMT6での動作報告を見付けられなかったため、自分達で動作検証をする必要がありました。上のようにVagrantで検証環境を作ろうかと思っていたところでMTのGitHubリポジトリーにDockerfileを見付けたため、SaharaではなくDockerを使うことにしました。DockerfileはDockerイメージの設計図で、Dockerイメージが配布されていなくても、このファイルを元に自分でDockerイメージを作ることができます。

Dockerはそもそも状態を保存しないのが基本なので、わざわざ「巻き戻し」のことを意識する必要がありません。プラグインの動作検証も、そのMTの状態を保存したいわけではないので、Dockerは適していると言えるでしょう。

DockerはSahara以上にリセマラに適しているツールです。今後もどんどん活用していきたいと思っています。

余談ですが、ウェブサイトやミドルウェアのセットアップもDockerイメージの納品でできるようになると、セットアップ作業をシナップ環境とお客さんの環境で二度実施したり、その際に間違いなく同じバージョンになるよう気を付ける必要もありませんし、その作業に例えば数時間を要するなどということもなくなるので、色々な所が効率化するのではないかと思っています。

受け入れ側も、Docker運用の体勢さえ整っていれば、取引先ごとにインフラチームとの調整や下準備を変える必要なく、いつでも同じようにDockerイメージをデプロイすればよくなるので、運用コストはだいぶ下げられるのではないでしょうか。ぜひ、一度検討してみてください。