Docker環境におけるバックアップ用ハザードマップの紹介


 皆さんはDockerを利用する上で、イメージやコンテナのバックアップを行っていますでしょうか。

 Dockerを検証環境や開発環境として利用している分には、更新データの管理はユーザ責任で行うという運用で大丈夫そうなので、バックアップは特に必要ない、という意見もあると思います。

 しかし、Dockerを使用して、ユーザにサービスを提供する常駐システムを作る場合は、バックアップが必要な場面が必ず出てくると思います。例えば、フロントエンドのWebサービスなどで、コンテナ内では完全に静的なコンテンツのみ扱う運用にしたとしても、単純にログファイルの管理を行う必要があると思います。コンパイルだけしか行わないコンテナでも、コンパイラの中間的な出力情報は保存しておきたいということがあるかもしれません。

 こんな記事を書いている私ですが、最初のころはバックアップなんて全く眼中になく、必要になってから慌てて調べまくったという経緯があります。

 ここで軽くDockerにおけるバックアップの考え方について整理してみたいと思います。

 

Docker環境における更新データのあぶり出し

 まず以下の図を見てください。Dockerに関わる全てのコンポーネントにおけるデータの危険度マップ(以下ハザードマップと呼ぶ)になります。

docker-dengarmap

 ハザードマップ内の各データの簡単な説明になります。

Docker(bin,lib)
 Dockerシステムのバイナリ(dockerやdockerdの実行ファイルやライブラリなど)
Docker設定ファイル
 Dockerシステムの定義ファイル(systemdなどでオプションを指定するファイルなど)
Dockerイメージ構成ファイル
 自作のDockerイメージを作成するために必要なファイル(Dockerfileや定義ファイルなど)
コンテナ構成ファイル
 コンテナを作成および起動するためのファイル(docker-compose.ymlや定義ファイルなど)
データボリューム
 コンテナにマウントするデータボリュームの実データ
Dockerイメージ
 Dockerイメージの実データ
コンテナレイヤ―
 コンテナ内の更新データ

 

 障害は、以下の3つを想定します。

  • Dockerホストの全損(OSは別システムにて初期状態に戻すこととして考慮外とする)
  • /var/lib/docker(※)の全損
  • コンテナの全損

また、Dockerホストと他ホストとのネットワーク障害は考慮外とします。

※/var/lib/dockerは、Dockerシステムの全データが格納されているディレクトリのデフォルトの場所です。「docker info」コマンドの「Docker Root Dir」の値で確認できます。

 図内の×印と△印についてですが、×印は復元不可能であることを、△印は機械的な作業を行えば短時間で復元可能であること示してます。また、×印と△印の色ですが、黒がDockerホスト全損時ピンクが/var/lib/dockerパーティションの全損時水色がコンテナの全損時を表しております。

 これを踏まえた上で、各データのバックアップの考え方を書いていきたいと思います。

■ 本記事の目次に戻る ■

Dockerのバイナリファイルのバックアップについて

 ハザードマップ内のDocker(bin,lib)の部分のデータについての記述になります。

 ハザードマップによると、Dockerホスト全損時に復旧手順があれば良いことになります。Dockerのインストール手順書を準備することでバックアップ対応は不要と考えます。

 Dockerのインストール手順はネット上にいっぱいありますので、良いサイトを参考にして、手順書を作成しましょう。

 ちなみに本サイトでも、別記事「CentOSのインストール」について書かせていただいておりますので、もし宜しければご利用ください。

 

Docker設定ファイルや各種構成ファイルのバックアップについて

 ハザードマップによると、Dockerホスト全損時に備えれば良いことになります。

 念のため、Docker設定ファイルや各種構成ファイルの具体例を挙げておきます。

Docker設定ファイル

  • systemdによるDocker起動時に指定するパラメータファイル(デフォルトでは/etc/systemd/system/docker.service.d/下のconfファイル(CentOS7の場合))

Dockerイメージ構成ファイル

  • イメージを作成するためのDockerfileファイル
  • Dockerfileに定義されているファイル(例えば、パッケージのインストールファイル、定義ファイルなど)
  • イメージを作成するコマンドが記述されているシェルスクリプトなど
  • その他Dockerイメージを作成するために必要なファイル

コンテナ構成ファイル

  • コンテナを起動するコマンドが記述されているシェルスクリプトなど
  • docker-composeを利用している場合は、docker-compose.ymlファイル
  • コンテナ内にコピーするファイル(シェルスクリプトや定義ファイルなど)
  • その他コンテナを作成するために必要なファイル

 これらのファイルは、tarなどでまとめてDockerホスト外にバックアップすれば問題ありません。

 また、各構成ファイルは、Dockerイメージ単位やコンテナ単位にディレクトリを作成し、その中に作成していると思いますが、そのディレクトリ単位にバックアップすることをおすすめします。

 docker-composeをご利用されている場合は、docker-compose.ymlファイルが存在するディレクトリ単位にバックアップすることをおすすめします。

■ 本記事の目次に戻る ■

Dockerイメージのバックアップについて

 ハザードマップによると、/var/lib/dockerとDockerホストの全損時に備えれば良いことになります。

 /var/lib/docker全損時の対応が△印になってますが、これは、Dockerイメージ構成ファイルは影響を受けずに残ってますので、それを使用してDockerイメージを作成することが可能だからです。

 Dockerホスト全損時は、Dockerイメージ構成ファイルの復元が完了すれば、Dockerイメージも復元可能になります。

 よって、Dockerホスト全損時対策が整っていることを前提にすれば、Dockerイメージ作成手順があればバックアップは不要になるということになります。

 また、「docker save」コマンドでDockerイメージをtarファイルにコピーすることが可能ですので、環境によっては、こちらの方が良い場合もあるかもしれません。但し、こちらの方法ですと、バックアップに必要なリソース量が大きくなる可能性があります。Dockerイメージ構成ファイルのバックアップはほとんどがテキストファイルですのでリソース量は大したことありません。

 

 

データボリュームのバックアップについて

 ハザードマップによると、/var/lib/dockerとDockerホストの全損時に備えれば良いことになります。

 ここに格納されているデータは、Dockerコンテナ内で稼働しているサービスの生データになりますので、システム的にも最重要で、確実にバックアップする必要があります。

 コンテナにマウントするデータボリュームは、コンテナによって様々ですので、各コンテナがマウントしているデータボリューム情報を自動的に取得して、その情報を使用してバックアップするような機能が欲しいところです。

 ネットを探しまくった結果、良いツールが見つかりましたのでご紹介したいと思います。DockerHUB(※)上にDockerイメージで提供されてました。

 そのDockerイメージの名前は「boombatower/docker-backup」です。

 このツールは、コンテナ起動時のコマンド「docker run」のオプションとして「- -volumes-from」を使っているのですが、ここがこのツールのポイントになります。このオプションの後にコンテナID若しくはコンテナ名を指定するのですが、指定したコンテナにマウントされているデータボリュームを自分のコンテナにマウントしてしまうオプションなのです。

 つまり、バックアップ対象のコンテナがマウントしているデータボリュームを、このツールのコンテナにマウントして、データボリューム内のデータのバックアップを行います。

 更に、バックアップしたファイルを指定して、リストアも可能です。

 よって、コンテナ内のデータボリュームのバックアップは、このツールを利用するか、バックアップ用のコンテナを「- -volumes-from」オプション付きで起動して、そのコンテナ内でマウントされているデータボリュームを手動にてバックアップし、コンテナの外にコピーしてバックアップを行う方法が良いと思います。

 尚、このツールの件につきましては、お手数をお掛けしますが、別記事「dockerのバックアップの考え方とその方法について」で紹介しておりますので、そちらをご参照ください。

 またこのツールは、tarによるバックアップであるため、データ量によっては非常に時間を要する可能性があります。商用データベースなど、莫大な量のDBのバックアップを行う場合などは、運用的に無理と思われます。本ページの内容は、tarでバックアップ運用が可能なレベルのシステムを対象とさせてください。

※DockerHUBは、Docker社の公式レジストリサーバです。様々なDockerイメージが公開されてます。

 

コンテナレイヤーのバックアップについて

 コンテナレイヤーとは、コンテナ内に存在する更新可能なイメージレイヤーのことです。このイメージレイヤーとDockerイメージがコピーオンライト機能によって融合されて一つのコンテナのディスクイメージになります。

 ハザードマップによると、想定した3つ全部の障害に備える対応が必要です。

 また、コンテナの障害は、他の2つの障害に比べて発生する確率は高いです。

 さらに、「docker export」コマンドなどでコンテナをtarファイルに出力すると、共有情報であるDockerイメージの部分まで出力されてしまいます。

 私の考えとしてはただ1つです。コンテナレイヤーはバックアップしない!です。「コンテナ構成ファイル」からコンテナを再作成する手順書があれば良いと思います。

 つまり、コンテナ内で更新が発生する部分は全てデータボリュームにしてしまうということになります。

 実際、コンテナ内で保管が必要な更新が発生している部分を調べるのは大変だと思います。しかし、その努力は必ず報われると思います。

 というわけで、コンテナレイヤーの更新情報は、全てデータボリュームに出力する対応を行い、バックアップを不要にするのが良いのではないかと考えます。

■ 本記事の目次に戻る ■

まとめ

 本ページの内容を各データ別に簡単にまとめてみます。

Docker(bin,lib)

 Dockerホスト全損時に備えたDockerのインストール手順書の整備

Docker設定ファイル

 Dockerホスト全損時に備えたDockerホスト外への退避

Dockerイメージ構成ファイル

 Dockerホスト全損時に備えたDockerホスト外への退避

コンテナ構成ファイル

 Dockerホスト全損時に備えたDockerホスト外への退避

データボリューム

 データボリューム領域をアーカイブしてコンテナ外にコピーした後、そのアーカイブファイルをバックアップ

Dockerイメージ

 Dockerホスト全損時に備えた「Dockerイメージ構成ファイル」のDockerホスト外への退避、及びDockerイメージ作成手順書の整備

 環境によっては「docker export」でイメージをtarファイルにする方法も有り

コンテナレイヤ―

 コンテナのバックアップは無し。必要な更新データはデータボリューム内に配置する。

 Dockerホスト全損時に備えた「コンテナ構成ファイル」のDockerホスト外への退避、及びコンテナ作成手順書の整備

 

以上です。

 コンピュータシステムにとって、バックアップ及びリストアは最重要ポイントの1つです。

 しっかり設計して安心できるシステムを構築するためのお役にほんの少しでも立てたらうれしいです。

 また、本ページの内容は、あくまでも私の個人的な考えですので、もしDockerのバックアップについてなにかお考えをお持ちの方がいらっしゃいましたら是非コメントをよろしくお願いいたします。

 最後までお読みいただきありがとうございました。

■ 本記事の目次に戻る ■


コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です