15分で分か(った気になれ)るDocker

  • 16,286 views
Uploaded on

15分で分か(った気になれ)るDocker …

15分で分か(った気になれ)るDocker
2014-03-28 Xtone Ltd.ピザ会
Aki / @nekoruri

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
16,286
On Slideshare
0
From Embeds
0
Number of Embeds
10

Actions

Shares
Downloads
99
Comments
0
Likes
65

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. 15分で分か(った気になれ)る Docker 2014-03-28 Xtone Ltd. ピザ会 Aki / @nekoruri
  • 2. Dockerってなんぞや • アプリケーションコンテナの実行環境 – LXC(Linux Containers) 軽量な仮想化技術 ※ LXCもnamespace,chroot, cgroups等の組み合わせ 参考: Lxc で始めるケチケチ仮想化生活?! http://www.slideshare.net/enakai/lxc-8300191 – AUFS(AnotherUnionFS) 軽量化と再利用の推進 環境別の巨大なディスクイメージ が不要
  • 3. コンテナ?
  • 4. 軽量 移動可能 自己完結 どこでも 動く
  • 5. アプリケーションコンテナ • アプリケーションの実行環境 – OS環境 – ミドルウェア一式とその設定 – コンテナ起動時に実行するコマンドライン – 外部に公開するポート番号 • 「Dockerfile」に記述してビルド ※ Packer等の別のツールも利用できる
  • 6. 「コンテナ」のとらえ方 1. 仮想化におけるディスクイメージの新しい形 – LXCで動かせるディスクイメージ+メタデータ – 実装上は正しい 2. JavaのJARのような実行環境パッケージ – 「置いて実行すれば期待通りの動作をする」 – このイメージの方がユースケースを考えやすい
  • 7. なぜ軽いのか(1) • ハイパーバイザ型仮想化 – VMware、VirtualBox、KVM等 – とりあえずOS一式動かす – 共通化できる部分は端折る (準仮想化:virtio等) • コンテナ(型仮想化) – 1プロセスとして動く – プロセス空間、ファイル空間 を制限しているだけ – オーバヘッドが小さい Dockerが実現する 「コンテナ」とは違う 概念なので注意
  • 8. なぜ軽いのか(2) • AUFS(AnotherUnionFS)で差分を保持 – メモリ上のライブラリ実行イメージ – キャッシュ – ディスク容量
  • 9. 実例(matsuuさんのfc2blog) • でも
  • 10. 徹底した再利用 • BASEによる既存イメージの利用 • Docker indexへの公開 • 「毒入り」の危険はOSS的に 解決されていくはず……
  • 11. 「コンテナ」で何が変わるか • ビルド・デプロイ環境の変化 – Javaと同じように、CI環境でビルドしたコンテナをそのまま持って 行ってProductionにデプロイ – 新しいコンテナを動かして動作確認したら切り替えて古いコン テナをまるごろ削除 ※ Immutable Infrastructure / Disposable Components • サーバ構築作業の大幅省力化 – 「コンテナを作り込む作業」に転嫁 – 綺麗なBASEイメージの上にミドルウェアを入れ設定ファイルを 置くだけなら、Chef等の重量級構成管理ツールも不要?
  • 12. Production環境での課題 • 「一つのコンテナイメージ」に対する課題 – 開発中だけ有効なデバッグ機能 ⇒ Chankoアプローチへのシフト – ログ等 ⇒ fluentd等で送信しサーバをstatelessに保つ – 設定の流し込み ⇒ 環境毎のメモリチューニング等
  • 13. ストレージ等のStatefullなサーバ • Volume機能 – 複数コンテナでホスト側ディレクトリを共有 – ハードウェアに関する細かい調整などはコンテナ からはできないので注意 – データの初期化のタイミングにも注意
  • 14. Vagrantとの関係 • Vagrantでも似たようなことできるよね? – Vagrantの方が「領域」が広い • Dockerは「Dockerが動く環境」は用意してくれないので、Vagrantで Dockerが動くイメージを起動してその上でDockerコンテナを立ち 上げる • これをやるDocker ProvisionerがVagrant 1.4で実装 • 複数クラウド環境でのインテグレーションはVagrantの領域 – Vagrant自身もDockerコンテナと同じ方向性に進みつつあ る(Vagrant Cloud) • Box imageを共有
  • 15. クラウドとの関係 • Dockerコンテナの抽象化による恩恵 – いわゆるIaaSとPaaSの中間で、事業者毎の癖を吸収 ※ コンテナをpushすると動くという意味ではPaaS寄り • スケールアウトとの親和性 – コンテナ化によりStatelessを担保 • メトリクスに基づいたリソース管理に注力 – 1にも2にもモニタリング、そして適切なサイジング – クリック一発で新構成にデプロイ!! – あわせて知りたい:クラスタ管理ツール(Serf等)
  • 16. DevOpsの理念に向けて • Productionと同じものが手元で動く! – Devは環境毎の構成の違いを怖がらずに済む – Opsは構成変更をプログラムと同じコンテキストで 管理し、CIも回せる ※ Infrastructure as Codeによる最大の恩恵 – もはやあらゆる「特権」はお互いに消失 • そして継続的デリバリーの実現へ
  • 17. 備考 • 図は公式サイトより引用 – https://www.docker.io