Dockerのバックアップ戦略――Dockerの何を保護すべきか？：コンテナ時代のバックアップ基礎の基礎

Dockerは多数の抽象化レイヤーから成り、レイヤーごとにバックアップ方法も異なる。まずDockerの何を保護するのかを決めることが、バックアップ戦略のベースとなる。

[Eric Ebert，Computer Weekly]

　Dockerをバックアップする円滑な手順を用意すべき理由はたくさんある。最も分かりやすいのは不測の事態に備えるためだ。サーバに障害が起きると、データセンターは機能停止に追い込まれる。コンテナやボリュームのコピーを確保しておけば、問題が発生しても迅速な対応が可能になる。

　Dockerはその性質上、予測不能な動きをすることがある。バックアップはこうした動きをうまく乗り切るのにも役立つ可能性がある。あるコンテナで異常が発生して通常の対応策が機能しなくなったとしても、バックアップがあれば、機能することが分かっている時点のバージョンに即座に戻すことができる。

　コードベースを以前のバージョンに戻す必要がある場合、コンテナのバックアップがあれば全体のプロセスが明らかにシンプルになり、ビルドを作成し直す手間が掛からない可能性がある。

Dockerバックアップの基礎

　Dockerは、あるレベルでは仮想化を大幅にシンプルにする。だが、そうしたシンプルさが複雑さの大部分を覆い隠してしまう。

　Dockerのバックアップを話題にするときは、話題を正確に絞り込むと分かりやすくなる。Dockerは、抽象化の層を多数重ねた大規模なプラットフォームで、この各抽象化層をバックアップの対象にできる。

　厄介なのは、これらの抽象化レベルがDockerのエディション間で異なる点だ。「Docker Enterprise Edition」（Docker EE）は「Docker Community Edition」と微妙に異なる。そのため本稿ではDocker EEを扱うものとする。

関連記事

• クラウドバックアップの最適解はクラウド→クラウド
• クラウドストレージかテープかを決める境界線
• NAS感覚で使える“テープNAS”で大容量バックアップ問題を解決
• 仮想化時代のバックアップと災害復旧
• テープの無視できないメリットと残念なデメリット

　例として、クラスタ構成、アクセス制御、認証管理などを処理する「Universal Control Plane」（UCP）を考える。これがDockerの中核を成す、適切に調整されたエンジンだと考えると、このバックアップを定期的に取っておきたいのはほぼ間違いないだろう。これを一から再構築するのはお勧めできない。

　次にバックアップを取っておきたいのが「Swarm」だ。SwarmはDockerでクラスタを構築するツールだ。細かくバックアップを取りたい場合は、特定のボリュームやコンテナのイメージを作成することもできる。

　最後に、「Docker Trusted Registry」のバックアップも必要だ。これはSwarmで使われる各種イメージを管理するリポジトリサーバだ。これにも個別のバックアップ手順がある。

　こうした点は、明らかにツールや製品に関わる厄介な問題になる。そして、そうしたツールや製品それぞれに独自の真摯（しんし）なメンテナンスが必要になる。だが、それほど心配することはない。Dockerが優れている点の一つは、重要なコンテナインフラの保全方法をユーザーが管理できる複数の組み込みコマンドラインツールや公開APIが備わっていることだ。

　つまり、さまざまなDockerコンポーネントのバックアップを取るcronジョブを作成し、SSH（Secure Shell）を使ってイメージを仮想専用サーバ（VPS）やオンプレミスサーバと安全にrsyncするだけで済む。

Dockerバックアップ製品

　当然、これで話は終わりではない。Dockerバックアップツールは数多く存在する。そうしたツールは必ずしも必要ではないが、検討する理由も幾つかある。例えば、そうしたツールは洗練されている場合が多い。また、それ以外の方法では独自に開発するしかない機能を搭載している場合もある。

　多様な商用コンテナバックアップソリューションを支持する理由もある。異論があるかもしれないが、最も大きな理由は他の機能も備え、他のITインフラの資産も1つの製品で管理できることが挙げられるだろう。

Bacula SystemsのDocker向け自動バックアップ

　紹介する順序に特に意味はないが、まずはBacula Systemsが提供するDocker向けの自動バックアップ製品を取り上げる。これは出しゃばったところが最も少ないツールの一つだ。Docker APIに直接統合されるモジュールになっていて、エージェントをユーザーが各コンテナにインストールする必要がない。こうしたインストールは時間がかかり、複雑化を招く。

　次に、読み取り専用の層や書き込み可能な層を含めてコンテナ全体をキャプチャーし、単一のイメージとして保存できる。その後、このイメージを使って全く新しいコンテナを自動または手動で稼働させることが可能だ。

Veritas NetBackup

　「Veritas NetBackup」は興味深い製品だ。主に大容量かつ大規模な環境を対象とする紛れもない企業向け製品で、オンプレミス環境、仮想環境、クラウドにまたがって機能する。Dockerに加えて「MongoDB」「MariaDB」「PostgreSQL」など、大量のデータを扱うその他の一般的なアプリケーションもサポートすることを売りにしている。

　Dockerに関してVeritas NetBackupが興味深いのは、データ保存に対して3つの異なるアプローチを用意している点だ。ユーザーは、稼働時間、パフォーマンス、構成の各ニーズに応じて最適な手法を選べる。

　1つ目の手法では、ツールがステージング領域を作成してアプリケーションデータを保存する。これはバッファーとして機能し、ユーザーデータを定期的に安全な場所に転送する。別の手法では、「サイドカー」モデルを使用してVeritas NetBackupをアプリケーションに統合し、アプリケーションデータをバックアップするツールを追加する。最後に、Veritas NetBackupはアプリケーションコンテナ自体に直接統合することもできる。

　これには2つの解釈が可能だ。Dockerバックアップを処理するのに理想的な1つの方法が存在しないか、単純にユーザーのさまざまなニーズでは微妙に異なる方法が時として必要になるということだ。個人的には後者の解釈を支持する。

無視できないオープンソース

　取り上げなければならないことがもう1つある。幅広い魅力的なオープンソースの（言い方を変えると、無料の）アプリケーションがあることだ。こうしたオープンソースアプリケーションは、DockerコンテナやDockerボリュームの保存に関わる手間を要する多くの作業に対応する。

　魅力的なオプションの一つに挙げられるのが、ドイツのミュンヘンを拠点とする開発者ステファン・ブロール氏が開発した「Volumerize」だ。ユーザーが独自にバックアップワークフローのスクリプトを作成できることには既に触れたが、このツールはその際説明した面倒な作業の多くを代行する。例えば、cronジョブでワークフローのスケジューリングをサポートし、SCP（Session Control Protocol）とrsyncを使ってネットワーク全体でファイルを移動できる。「Google Drive」「Dropbox」「Amazon Simple Storage Service」（Amazon S3）など、複数の人気のクラウドストレージ製品もサポートしている。

　この分野には多くの選択肢がある。いずれにせよ、行動を起こす前にDockerのベストプラクティスを一読してほしい。最も悲惨な方法で大失敗するのはあまりにもたやすい。そうなれば、コンテナやボリュームが破損する羽目になり、大変頭の痛い事態を招くだろう。