More than 5 years have passed since last update.

Docker導入のための、コンテナの利点を解説した説得資料

Posted at 2017-02-28

1 / 29

何がしたいのか

最近はDockerを導入したサービスがガンガン出てきている一方、現場でのDocker導入に足踏みをしているところもあると思います。
今回はDockerを導入するために、「コンテナを利用するとこんなに便利!!」という主張を展開することで、現場でのDocker導入の推進をしたいと思います！

まあ、スライドモードを使いたかったんですよ

TL;DR

コンテナと仮想環境は別物だよ
コンテナでの運用するといいことがたくさんあるよ
- どんな環境でも同じように動かせる
- デプロイ・ロールバックが簡単
- システムが簡単に把握できる
- あいのり環境もいける

コンテナとは

コンテナ ≒ VM ??

Docker導入しようって言うとこんな話を聞くことがある

コンテナってVMみたいなもんでしょ？
VMの上にまたVM作るの?
AMI使ってるから、わざわざコンテナにする必要がない

コンテナ != VM

VMとコンテナが比較されることが多い( 例えばこんな記事 )ため、よく勘違いされるが、コンテナとVMはまるで別物

VMは一つのPCの電源をつけてから消すまでをまるごとシミュレートするが、コンテナはその中で動く一つ一つの処理、例えばservice httpd start のような一つのコマンドのみをシミュレートする

こんな感じ

コンテナとは何か

コンテナを簡単に説明するなら、以下の通り

「ある前提となる状態のもとで、あるコマンドを叩いたときに発生する処理の内容を再現するもの」

例

以下のDockerfileを見る

FROM centos:6.5

RUN yum install -y httpd

CMD ["cat", "/etc/httpd/conf/httpd.conf"]

これは、「CentOS 6.5で、yum経由でhttpdをインストールし、
cat /etc/httpd/conf/httpd.confとコマンドを打ったときの処理」を再現する。

コンテナ運用の利点

どの環境でも同じように動く

コンテナのもつ再現性

コンテナが「ある前提となる状態のもとで、あるコマンドを叩いたときに発生する処理の内容を再現するもの」と述べたが、この「ある前提となる状態」にはLinux ディストリビューションの情報も含まれている
つまり、例えば「CentOS6.5上でyumでインストールしたhttpdを動かしている」コンテナはUbuntuだろうがDebianだろうがScience LinuxだろうがMac、Windowsだろうが、どこでも全く同じように動作するということである

こんな変な環境でも、少なくともコンテナの部分だけは同じように動いてくれる ( 作れとは言ってない )

デプロイ・ロールバック

Dockerのコンテナイメージはリポジトリ管理できるので ( Docker Registry )、デプロイは一番新しいイメージからコンテナを起動すればよいし、ロールバックは今より古いバージョンのイメージからコンテナを起動すればいい。

コードデプロイとの違い

コンテナは動作状態自体が含まれているため、ロールバックを確実に行うことが可能
コードのみのデプロイだと、サーバの状態がデプロイ前後で変わっている可能性を考慮してロールバックする必要がある
代わりにコンテナを利用したデプロイの場合はイメージを作成するというひと手間がかかる

システムの把握を簡略化

とあるシステム

問題点

そもそもこういう構成になっているというのを調べたり引き継ぎしたりしなければならないのが大変
リクエストルートが凝っていて、追跡が大変
ディストリビューションにバンドルされたhttpdなどを使っているため、年月がたってもサーバを更新できない
何をしているのかわからないものがある

Dockerだと

構成は?
- HostサーバはDockerさえ入っていればよい。アプリの構成は動いているコンテナをdocker psで調べるか、手元のDockerfileを参照するなどすれば把握できる
バージョンは?
- イメージビルドの時点でバージョンなどは任意に指定できるので、Hostのパッケージ管理システムに依存しない。好きなものを使おう
リクエストルートを凝るのは難しいかもしれない...がswarmmodeを使えば実現できるかも？