SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

DeveloperZine(デベロッパージン)- エンジニアの意思決定を支える技術情報メディア ProductZine

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

特集記事

軽くて使いやすい仮想化技術 「Docker」の仕組みと
エンタープライズ開発における4つの活用事例


解決事例②「評価環境利用」

 2つ目の事例は評価環境としてのDocker利用です。当社のCIでは自動でテストが完了するプログラムと、画面からの確認が必要なプログラムがあります。後者の場合はJenkinsがTomcatにデプロイを行い、それを評価者が確認してからマージを行うフローとなります。

JenkinsがTomcatにデプロイし、それを評価者が確認してからマージを行う
JenkinsがTomcatにデプロイし、それを評価者が確認してからマージを行う

 

 これまでは1台のサーバーにTomcatをインストールし、そのサーバーを共有して利用していました。ところが、アプリケーションにバグがあってTomcatへのデプロイに失敗すると、次のデプロイにも影響が出るという問題が発生していました。

 そこで、Jenkinsが1台の物理サーバー上のTomcatへデプロイするのではなく、Tomcatや必要なライブラリがインストールされたDockerコンテナを起動し、そのコンテナにデプロイを行うように変更しました。

Tomcatや必要なライブラリがインストールされたDockerコンテナにデプロイ
Tomcatや必要なライブラリがインストールされたDockerコンテナにデプロイ

 

 さらに、GitLabでマージ完了時やクローズ時にHookするよう変更し、不要となったコンテナを破棄するジョブもJenkinsに追加しました。

GitLabでマージ完了時やクローズ時にHook。不要になったコンテナも破棄
GitLabでマージ完了時やクローズ時にHook。不要になったコンテナも破棄

 

 これにより、誰かが開発したアプリケーションにバグが含まれていても、影響範囲をサーバー全体ではなく限定的なものにできました。また、追加機能ごとに作られる評価環境の削除も行えるため、サーバー内のリソースを有効に使えるようになりました。

解決事例③「開発環境利用」

 前述の通り、当社には開発中の製品や保守の必要なバージョンが多数あります。ただし、開発者が対応の必要な環境をすべて持つことには無駄が多く、他のバージョンの開発環境に不具合を起こすこともあります。

 また、開発内での人材の異動も多く、ある開発環境の破棄や、別の開発環境の用意なども頻繁に行われます。

 なるべく簡単に環境を準備できるようにスクリプトを用意したこともありますが、環境の差異により正常に動作しなかったり、一時的な開発ヘルプのために環境の同居を行った結果、不具合を発生させることがありました。

 この課題も、開発環境をDockerイメージとしてパッケージ化することで解決しました。開発者のPCに環境を用意するときは、Webから必要な環境を見つけてdocker runコマンドを入力するだけです。コンテナ型の仮想化を利用することで処理のオーバーヘッドもなく、開発環境として十分に利用できています。また、DockerのPrivate RegistryはWeb UIを持っていなかったため、「Docker Registry UI」を社内で開発し、対象の製品およびバージョンを見つけやすくしています。こちらはオープンソースとして公開していますので、ぜひ使ってみてください(フィードバックもいただけると幸いです)。

開発環境をDockerイメージとしてパッケージ化し、タグ付けした
開発環境をDockerイメージとしてパッケージ化し、タグ付けした

 

解決事例④「海外拠点とのサーバ環境共有」

 先ほども述べたとおり、当社では1つの製品を複数の国で開発しています。あるとき、東京のデータベースサーバーを参照して開発を行っていた上海拠点の開発者から、上海にも同じデータベースを用意することはできないかという相談を受けました。海外拠点にはサーバー管理を行う社員がいません。また、データベースの運用を東京から行うのは手間がかかるため、積極的に取り組むこともありませんでした。

 しかし、Dockerがあれば運用コストを増やさずに、データベース環境を用意できるのではないかと思い付きました。

 データベースをインストールし、開発で使用しているデータをインポートしたDockerイメージを作成します。東京のデータベースサーバーも、このイメージを使ったDockerコンテナで運用することにすれば、まったく同じ環境が上海でも使用できます。開発中、データベースに不正な入力や変更を行ってしまい、問題が起きた場合も、そのコンテナを破棄し、新しくコンテナを起動し直すだけで復旧できます。また、Dockerイメージに問題が含まれている場合でも東京でイメージに対して修正を行えば、上海ではイメージをPullしなおすだけで復旧できます。

復旧はPullするだけ
復旧はPullするだけ

 

 実は、このケースでDockerを採用した理由として、インフラ環境に依存しないようにするという目的もありました。

 開発者も頻繁にアクセスするデータベースは、なるべく通信遅延の発生しない場所で運用する必要があります。それには、開発に使用するクラウドや開発拠点との地理的な距離などを自由に選べなくてはなりません。

 しかし、東京では開発で使用するクラウドをほぼ自由に選べても、海外拠点ではそうもいきませんでした。

 Dockerコンテナで構築したデータベース環境は、ポータビリティに優れているため、上海拠点でも使用しやすいクラウドを選択して運用できるようになりました。

おわりに

 ここで紹介したように、Dockerを利用することで、様々なアプリケーション環境を簡単に作成し、破棄することができるようになりました。また、Dockerでアプリケーションをパッケージ化することによって、物理サーバーやクラウドなど関係なく移動させることも可能になっています。

 みなさんも、簡単にどこでも使えて軽量なDockerに、一度トライしてみてはいかがでしょうか。

この記事は参考になりましたか?

連載通知を行うには会員登録(無料)が必要です。
既に会員の方はを行ってください。
特集記事連載記事一覧

もっと読む

この記事の著者

遠藤 博樹(エンドウヒロキ)

株式会社ワークスアプリケーションズ Advanced Technology&Engineering Div.所属。製品や社内システムに対するインフラ研究を担当し、製品のクラウド化や開発用システムの分散化など製品の品質向上や開発者の生産性の向上を目的に、インフラからの視点で新しい技術を社内に取...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

秋吉 真衣(アキヨシマイ)

株式会社ワークスアプリケーションズ Advanced Technology&Engineering Div.所属。クラウド運用研究グループにて自社の新サービスである「CCMS」の開発・導入支援を担当。クラウド上での自社製品の運用の汎用化・自動化を進める中で、自動化ツールの開発や周辺技術の調査・検証な...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

CodeZine(コードジン)
https://codezine.jp/article/detail/7894 2014/07/24 16:46

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー