サポート検証環境へのDocker活用
現在弊社ではサポート用の検証環境にDockerを活用しています。
ここでは、Dockerのコンバージョン流活用方法について説明します。
Dockerは、コンテナ型仮想化OSSです。
ハイパーバイザ型の仮想化ソフトウェアでは仮想マシン上にそれぞれゲストOSが必要ですが、コンテナ型の仮想化ソフトウェアはコンテナイメージがホストOS上で個別のプロセスとして起動し、カーネル部分を他のコンテナと共有できるため、使用するリソースが少なく、起動も手軽です。
Dockerは2013年3月、dotCloud社という企業によってリリースされました。
dotCloud社は元々、社名と同じ「dotCloud」というPaaSを提供していた企業です。
リリース以来Dockerは急成長し、dotCloud社は2013年10月に社名をdocker社と変えて、以後はDockerを中心とした業務方針に変更することを発表しました。
Docker社となってからもdotCloudのサービス提供は継続して行っていた同社ですが、その後もDockerユーザは増え続けたため、2014年8月、Docker社はdotCloudをドイツのPaaSプロバイダであるcloudControl社に売却し、Dockerビジネスに専念することになりました。
今までの検証環境
今まで弊社の検証環境として多く利用していたのは、HP ML115などのワークステーションタイプのサーバでした。これらを中古業者から安く大量に仕入れ、直接Linux OSをインストールし、そこで多くの検証を行っていました。
この方法ですと、サポートするOSSの増加に伴い、物理的な場所を多く必要とするようになっていきました。そのため、サーバールームにはどんどんとこれらのワークステーションが山積みとなっていったのです。
物理的な場所以外にも問題が発生しました。
どのワークステーションにどんなソフトウェアがインストールされているのか、誰もわからないという状況です。
最初のうちはワークステーションにテプラを貼って、用途を示す運用としていたのですが、時間が経つにつれテプラが剥がれたり、サーバの再インストールをしたりで、ラベルと中身の整合性が取れていないような状況も発生しました。
そこで、まずはESXiのような仮想化基盤の導入を試みました。
仮想化基盤への移行はスムーズにいきました。
というのも、既にワークステーションには何が入っているのかも分からないものが殆どだったので、改めて作り直した方が早かったためです。
仮想化基盤での検証環境は今までのワークステーションでの運用よりも、サーバールームと検証をスマートにしました。
必要な時に必要なリソースを立ち上げる、という検証の仕方によって今までの物理的なスペース問題はほぼ解消しました。
ところが、今度は別の問題が出てきました。
ソフトウェアに更新が入るような検証を行った後で、その前の状態での検証が必要となるときに、すぐに検証に取り掛かれないという問題です。
具体的にはあるOSSのバージョンアップ検証を行ったあとに、元のバージョンでの検証が必要となるときや、検証後に様々なコンフィグが書かれてしまっていて、まっさらな状態で検証を行いたいときなどがそれに該当します。
仮想化基盤側でのスナップショット機能の活用も実際に行ってはいましたが、スナップショットの消し忘れによる共有ディスクの圧迫や、そもそもスナップショットの取り忘れなどもあり、中々ベターな運用ができない状態となっていました。
また、ワークステーション検証環境の時にも発生していた、どの仮想マシンにどんなソフトウェアがインストールされているかわからない、という状況が再び生じました。
そこで、新たな検証環境の構築を考えました。
検証環境へDockerの導入経緯
Dockerについては、以前から調査やサービスへの組み込みの検討をしていたこともあり、ある程度のメリットやデメリットについて理解していました。
そのため他のプロダクトを調査することなく、Dockerを使うことを即決しました。
Dockerを使う上でのメリットとしては以下があります。
- 省リソース
- 一度ローカルホストにpullすると、起動は数秒
- どんなにいじっても、すぐに元の状態に戻せる
- 全員が同じ環境ですぐに検証できる
メリットの中でも3番は弊社の検証環境の問題を解決してくれそうです。また、社内にリポジトリサーバーを持ち、OSSやバージョン毎にコンテナを作成することで、どのマシンにそのソフトウェアがインストールされているかわからない、といった問題も解決できそうです。
逆にデメリットとしては以下があります。
- 管理用GUIがデフォルトでは存在しない
- ホスト間での通信がそのままではできない
- バージョンの足が速い
管理用GUIがないことについては、今現在もそれっぽいものはいくつかありますが、サポートメンバー的には必須というわけではありません。
また、ホスト間通信についても、ホスト側でのルーティングやiptablesの活用でやろうと思えば何とかなります。
バージョンの足が速いことは、ある意味、弊社としても最新の技術を追いかける使命がありますので、そこを後押しする切っ掛けとなってくれそうです。
デメリットについては何とかなりそうな予感がします。
社内への提案を行って、早速導入してみました。
社内検証環境へのDocker導入実践
検証環境はすべて仮想環境へ構築しており、次のようになっています。（2015年9月現在）
- コンテナイメージコミット用Dockerサーバ
| OS | CentOS Linux release 7.1 |
| Hostname | commit-docker |
| Docker | Docker version 1.6.2 |
- コンテナリポジトリサーバ
| OS | CentOS Linux release 7.1 |
| Hostname | registry-docker |
| Docker | Docker version 1.6.0 |
| 利用コンテナ | docker.io/stackbrew/registry:2 |
- コンテナ利用サーバー
各自自由に作成
- Push/Pull利用イメージ
構築方法
コンテナイメージ作成方法
サポートに必要なコンテナイメージの作成を行います。コンテナイメージの作成にはcommit-dockerを利用します。
例えば、以下ではバージョン毎にPostgreSQLのコンテナイメージを作成しています。
現在存在するコンテナイメージを確認します。
# docker images
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
registry-docker.hogehoge.local:5000/centos6/postgresql-8.4.20 latest e949909bdd85 10 weeks ago 275.7 MB新たにコンテナイメージ上にPostgreSQL9をインストールしたコンテナイメージをコミットします。
# docker commit 542a65a4627c registry-docker.hogehoge.local:5000/centos6/postgresql-9.4.4
35266b06881c9cf4e769804f8ecdd041bd0e715c0f4c191da13c3df9c31a2a9a再度、存在するコンテナイメージを確認します。
# docker images
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
registry-docker.hogehoge.local:5000/centos6/postgresql-9.4.4 latest 35266b06881c About a minute ago 295.1 MB
registry-docker.hogehoge.local:5000/centos6/postgresql-8.4.20 latest e949909bdd85 10 weeks ago 275.7 MB作成したコンテナはregistry-dockerサーバへpushします。
# docker push registry-docker.hogehoge.local:5000/centos6/postgresql-9.4.4
The push refers to a repository [registry-docker.hogehoge.local:5000/centos6/postgresql-9.4.4] (len: 1)
35266b06881c: Image already exists
a005304e4e74: Image successfully pushed
fb9cc58bde0c: Image successfully pushed
f1b10cd84249: Image already exists
Digest: sha256:cc026619589b8954824e61df7b167c37d4a7782c0315a92f5969474fc7bc9c16リポジトリサーバーへpushされたことを確認します。
# telnet registry-docker.hogehoge.local 5000
Trying 10.0.0.2...
Connected to registry-docker.hogehoge.local.
Escape character is '^]'.
GET /v2/_catalog HTTP/1.1
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Docker-Distribution-Api-Version: registry/2.0
Date: Thu, 10 Sep 2015 03:15:00 GMT
Content-Length: 284
{"repositories":["centos6/postgresql-8.4.20","centos6/postgresql-9.4.4"]}コンテナイメージ実行方法
利用する際には docker run コマンドにて実行します。
runコマンドを実行すると、ローカルサーバに該当イメージがない場合には、自動的にpullをします。
pullには多少の時間が掛かりますが、起動自体に掛かる時間は数秒です。
# docker run --privileged -d --name postgresql9.4 registry-docker.hogehoge.local:5000/centos6/postgresql-9.4.4 /sbin/init
Unable to find image 'registry-docker.hogehoge.local:5000/centos6/postgresql-9.4.4:latest' locally
latest: Pulling from registry-docker.hogehoge.local:5000/centos6/postgresql-9.4.4
35266b06881c: Already exists
f1b10cd84249: Already exists
fb9cc58bde0c: Already exists
a005304e4e74: Already exists
Digest: sha256:cc026619589b8954824e61df7b167c37d4a7782c0315a92f5969474fc7bc9c16
Status: Downloaded newer image for registry-docker.hogehoge.local:5000/centos6/postgresql-9.4.4:latest
d54414fa3e677f825b7fb9a304294f9476e72e892962ac9259bdd01a0f968e22
Usage of loopback devices is strongly discouraged for production use. Either use `--storage-opt dm.thinpooldev` or use `--storage-opt dm.no_warn_on_loop_devices=true` to suppress this warning.
当然、バージョンの違うPostgreSQLのコンテナイメージを起動することも可能です。
psコマンドでバージョン毎のコンテナイメージが起動していることが確認できます。
# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
e921b7452323 cv-registry.conversion.local:5000/centos6/postgresql-8.4.20:latest "/sbin/init" 3 minutes ago Up 2 minutes postgresql8.4
d54414fa3e67 cv-registry.conversion.local:5000/centos6/postgresql-9.4.4:latest "/sbin/init" 3 seconds ago Up 3 seconds postgresql9.4上記のように一つのサーバー内で簡単に別バージョンのPostgreSQLサーバの検証環境が立ち上がりました。
データベースの移行検証などは、このような環境を利用することで簡単に構築・検証ができます。
課題
弊社での検証環境は、まだDockerホスト間での通信環境が整っていません。
今後はこの通信環境について整えていきたいですね。
