[レポート]「第11回 クラウドごった煮(コンテナ勉強会)」に参加してきた #cloudmix

docker
97件のシェア(ちょっぴり話題の記事)

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

2015年3月28日(土)に開催された、「第11回 クラウドごった煮(コンテナ勉強会)」に参加してきました!

場所は産業技術大学院大学

IMG_1094

Tweetは以下にまとめました。

レポート

本レポートは一参加者としての私の視点であり、全ての文責は私にあります。

"Docker is NOT Container." by @enakai00さん

Dockerを使うとアプリケーションの配信がすごく楽になる
 インフラ、OS設定周りのことをいちいち気にせず、スマホのアプリのように使える
Dockerの説明はコンテナの解説から入ってることが多い
2011年、dotCloudがパブリックPaaSサービスを提供開始
 PaaSのコンポーネントとしてDockerを作成
Dockerを作ったよ、という話のウケが良かったのでオープンソースで公開
Docker, Inc.に社名を変更してPaaSサービスは止めちゃった
 ビジネスのメインをDockerに切り替え
Dockerがオープンソース化されたタイミングでRedHatが食いついた
なんのためにDockerを作ったのか?
 PaaSの課題...環境のカスタマイズがしにくい
  使いたいフレームワークがないとかライブラリのバージョンが違うとか
  本当に欲しい環境が手に入らない
 課題を解決するためにDockerを開発
  環境を丸ごと詰め込んだイメージを作って、いろんな環境を自由に立ち上げられるように
Dockerの基本的な機能とは?
 Dockerfile→buildしてイメージ作成、イメージの中に全て(OS、ライブラリ、フレームワーク、e.t.c.)入ってる
  →pushしてDocker hubにUpload
  →pull or runして環境をダウンロード、コンテナですぐ実行
 コンテナじゃなくてもできる、頑張ればVMwareでも。
 やりたいことを実現するために一番手っ取り早くオーバーヘッドが少ないのがたまたまコンテナだった
 コンテナより良いものができたら乗り換えるんじゃないか、コンテナが目的じゃないんだから
Dockerの用途→アプリケーション開発が一番多いと思われる
 開発環境をコンテナで簡単に配布できる。いちいちPCをセットアップする必要がない。
 CIサーバにもDockerで環境を入れておけば、同じ環境で実行できる
 環境をDocker化することでインフラのバージョン管理もできる
  開発者全員の環境を変更することなく新しいDockerイメージを作って配布するだけ
   開発者は毎朝docker pullすれば常に最新の開発環境で開発できる
 本番への適用
  Googleのような大規模環境だとコンテナの恩恵は非常に大きい
  サーバ2,3台の小規模案件では?もちろんある。
   開発環境で試験した、確実に動く完成したアプリケーションをDockerイメージに固める
   そのDockerイメージをそのまま本番環境にもっていけばシステム部分の差異が出ない
   手作業を排して安全に確実に本番環境にデプロイできる
  Immutable Infrastructureの実現
   設定を変えない、変えたくなったら新しい環境を作りテストしOKなものをデプロイする
 変更の影響範囲をどうやって小さくするのか?その答えがmicroservice
  機能単位、小さい単位でDockerコンテナを作り、変更した機能だけコンテナを入れ替える
Dockerの一元管理→Kubernetes
 元々はGoogleが社内で使っていたサービスがベース、オープンソースで公開され共同開発
 RHEL7.1に最初からKubernetesが入っている

Dockerイメージ管理の内部構造 by @enakai00さん

RHEL7、CentOS7、AtomicHostではDockerイメージの保存にDevice Mapper Thin-Provisioning(dm-thin)を使っている
Device Mapper→ブロックデバイスにソフトウェアラッパーを被せて論理デバイスを作る仕組み
データ用デバイスとメタデータ用デバイスを用意し、dm-thinをかぶせると、データデバイスに複数の論理デバイスを作れる
docker infoコマンド→Data fileとMetadata fileが見れる
 RHEL7だと実態はloopbackデバイス(losetupで見れる)
 Atomic Hostだと生デバイスを使っているので早い
dm-thinだとスナップショットがたくさん取れる
 Dockerはスナップショットをたくさん作る
 dm-thinでは変更点だけ新たな書き込みを行う
 イメージの親子関係はDocker側で管理される
Dockerイメージからのファイルの取り出し方
 docker exportでイメージを丸ごとtarで固めて取り出す
 docker importすると丸ごとイメージ作成→ディスク使用効率が悪い
 docker saveではイメージの親子関係を考えて、イメージごとにtarで固めて、さらにそれをtarで固めて取り出す
 docker saveだとベースイメージと差分イメージがわかるのでdocker loadする場合差分だけ書き込むことでディスク使用効率が良い
Docker Hubはsave形式。pushではベースイメージpushされず差分だけがpushされている。

ニフティクラウドCoreOS対応について by @meryo2000さん

ニフティクラウド→IaaSサービス
C4SAというPaaSサービス(コンテナ提供型)もある
ニフティクラウドでCoreOSを提供始めました
 CoreOS→元々VMwareで動かなかった
  vmware tools依存コマンドがなかった、もろもろ動かない
 ニフティクラウドのエンジニアがもろもろ対応
  CoreOSにニフティクラウド用ドキュメントを提供した
  coreos-cloudinitに対応
 CoreOSイメージを簡単に起動できるようになった
 CoreOSで本番サービスを稼働させるためには?勇気と根気が必要...

IBM Containers by @tokidaさん

IBM Containersとは
 IBMとDockerが提携、IBMがDockerを利用したコンテナサービスの名称
 IBM Bluemix上で提供されている
 IBM→米国IaaSベンダのSoftlayerを買収、SoftLayer上にIBMのPaaSサービスを実装
 Softlayer + CloudFoundry + IBM = Bluemix
 実行環境(ランタイム)とサービスが提供されている
  サービスがたくさんあるのが売り
  サービス→Dockerコンテナで動く
 IBM ContainersではDockerの実行環境とプライベートリポジトリを提供
 コンテナの制御→IBM Container Serviceが行う
  IBM Container Serviceを使うツールがIBM Container Extention(ICE)
  iceコマンド。ice --localでローカル制御、iceだけだとBluemix上のリポジトリを参照。
衒売はβ版として無料で利用可能、最大コンテナ数8個、グローバルIP2個、メモリ2GB。
ICE version2→オートスケールできるグループ機能と共有ボリューム機能が追加
IB Containers = Docker as a Serviceです

Atomic Host by @enakai00さん

Docker以外の機能を入れさせない、という仕様。yumがない。
Atomic Hostのバージョンアップは丸ごと。atomic host statusで確認、atomic host upgradeで実行。
rpm-ostreeという仕組みを使っている。gitに似てる。
/usrがread onlyなので書き込み出来ない。
/varは書き込み可能、書き込みが必要なものは全て/varに配置される。
監視ツールなどを入れたい場合は?
 監視ツールを入れたコンテナを立ち上げる
 Super Privileged Container
  コンテナからホストの中身が丸見えになる。これで監視ツールもコンテナで動く。
atomic runコマンド→Dockerfileに書いたLABEL RUNを実行する

Kubernetes and Google Container Engine by @kazunori_279さん

Docker、IBM、Microsoft、RedHatがGoogleのコンテナ管理フレームワークKubernetesにこぞって開発参加する理由
 商用UNIX時代からコンテナ的技術はあった
 Googleは10年前からコンテナで運用している(社内独自実装、CGroupsベース)
  Googleは1週間で20億個のコンテナを起動している
 FacebookもVMは使っていない。クラウドサービスの大半はVMを使ってないんじゃないか。
Googleは以前から社内技術をリリースしてきた、CGroupsとか
Kubernetes→Googleで使っているジョブスケジューラをベースに、オープンソースで一から作り始めた
キーコンセプト
 クラスタ、コンテナ
 サービスグループをPodという単位で定義
  Pod→密結合されたサービスの集まり
 レプリケーションコントローラがデプロイ
手続き型では無く宣言型、Configファイルで宣言したことを実行
サービスを定義しロードバランシングする
現在はまだ1.0になっていないが数カ月以内になるはず
Kubernetesはfluentdをログコレクタとして採用
Googleが提供するフルマネージドKubernetes
 →Google Container Engine(GKE,GCEだとCompute Engineとかぶるから)

Docker Machineを始めるには? by @zembutsuさん

Dockerがコンテナ統括管理(オーケストレーション)用ツールを開発中
MachineVagrantに似てる
Machineはまだβ版
コンテナを使うために仮想サーバをいちいち準備するのが面倒くさい
 それを簡単にしたのがboot2docker
Machineだとクラウド環境に仮想マシン+コンテナを一気に立ち上げることができる

Apache Mesos/MesosphereとDocker on Mesosの紹介 by 木内さん

Mesosの紹介
 2010年に開発開始、2011年USENIXにて発表
 クラスタ環境の管理ツール、ジョブスケジューラ
 10000ノードくらいまでスケールしても大丈夫なように設計されている
 ジョブスケジューラ→ジョブ定義ファイルに従って複数のコンピュータでジョブを実行していく
  スーパーコンピューター→ラックマウントサーバの集合体
  ジョブスケジューラがリソースが空いているコンピュータを探して実行させていく
 Mesosのフレームワーク
  サービスディスカバリー、ジョブスケジューラー、リソース管理
  Zookeeperでサービスの種類を拡張可能
 Mesosはクラスタのクラスタを構成できる
  サービスクラスタをさらにクラスタリング
 Dockerとの統合をサポート
  MesosジョブをDockerコンテナ上で実行
  Mesosophere
 Marathon→ジョブの継続実行を管理
 Chronos→ジョブの繰り返し実行を管理
 Mesos DNS→Mesosクラスタ内で実行されたサービスを名前解決できる、サービスディスカバリー
  課題→IPアドレスはわかるけどポートがわからない。コンテナにフォワードされるポート番号がわからない。
Mesos gearという商用パッケージがある
Docker on Mesos
 Mesosの中にアプリケーションクラスタを作る場合
  それぞれのアプリケーションを事前にスレーブにインストールする必要がある
 アプリケーションをDockerにすることで展開が簡単になる
 ジョブの実行タイミングの管理をMesosが行う
 Mesos Slavesは実行したいアプリケーションのDockerイメージをリポジトリから取得するだけ
 アプリケーションのバージョンもDockerイメージを差し替えるだけ
  バージョン管理はDockerのタグで行う
 MesosにおけるDockerジョブ定義→jsonファイルで指定
Mesosを使うとジョブを使ったDockerコンテナの管理が簡単

Apache Aurora+Mesos+Docker by @zembutsuさん

Twitter社のブログ記事:All about Apache Aurora
Apache Aurora
 Twitter社で2010年から開発
 v0.7からDocker対応
 Apacheのインキュベーションプロジェクトに入っている
Mesos→ジョブを抽象化してどのノードで動いても関係なくしてくれる
 Mesosマスターに指令を出せばうまいことやってくれる
Mesosの上で動くフレームワークがAurora
 Marathon、Chronosと比較して...開発言語がnava、JSON RESTが使えない
 コード管理ができる
 GUIの管理画面はまだいまいち
 Vagrantで簡単に試せる
 ジョブの実行→auroraコマンドで行う。実行状況はGUIで確認できる。

MesosのNW仮想化のDockerがOenVNetでコンテナ by @qb0C80aEさん

MesosとMarathonを拡張し、OpenVNetと連携させて、Dockerコンテナをマルチテナントで起動する
Mesosで立ち上げたDockerを仮想ネットワークでつなげる
DockerNetworkingのおさらい
 そもそもはシングルホスト、Linux Networkingに依存し、ポート単位でサービスをEXPOSE
 Kubernetesなどと一緒に使えるツール→flannelweave
 socketplane→最近Dockerが買収
OpenVNet
 株式会社あくしゅが開発しているオープンソースのネットワーク仮想化ソフトウェア
 Openflow 1.3とGREで分散エッジオーバーレイ
 似ているプロダクト→NSX、midonetOpen Contrrailなど
Dockerネットワーク→コンテナの後付けっぽい
 SDNのネットワーク技術を組み合わせたい
wakame-vdcがDocker対応したら良い

Rancher.ioを試してみる by @deep_tkknさん

Rancher.ioとは
 Dockerクラスタを管理するシステム
  Docker版のCloudStack、OpenStackみたいな
 Dockerホストの管理、コンテナ操作、オーバーレイネットワークも提供される
 同一ホストではボリューム共有可能
 リソース監視、プライベートレジストリの作成、アクセス制御
セットアップ
 docker runするだけ
 Rancherは全てDockerコンテナで構成される
良い点、セットアップが楽、WebUIやAPIで管理可能
悪い点、拡張性がない。プラグインなどもない。機能が足りない。開発中なので今後に期待。
今後実装→ボリュームのスナップショット、セキュリティグループ機能、SwarmやCOmposeへの対応
Rancherを使えば簡単にクラスタ管理システムが構築できる

Raspberry Pi上でDockerを動かす by @deep_tkknさん

x86用イメージは動かない
Docker Hubをrpiで検索してみるといろいろ出てくる

Monitoring Docker with Mackerel by @stanakaさん

 

 Dockerのモニタリング
  Dockerのモニタリング→cgorupの作法に従う
  コンテナ側からはホスト全体しか見えないので、コンテナ側から見たい場合は-vで取り込む
  ホスト側からのモニタリング→cgroupのレポートを利用
   /sys/fs/cgroup/
   ディシュトリビューションによって微妙に違うから面倒くさい
  CPU使用率(/sys/fs/cgroup/cpuacct/docker/コンテナID/cpuacct.stat)
  メモリ使用率(/sys/fs/cgroup/cpuacct/docker/コンテナID/memory.stat)
  cgroupの共通レポートもある(cgroup.procs)
 ホストとコンテナの関係
  ホスト1:コンテナn(開発環境、CI環境)かホスト1:コンテナ1(本番環境)
   1ホストで多数のコンテナを動かすとリソースプランニングが難しい
   プロダクション環境は1:1で動かすことが多いと思う
  1:nはホストのリソースを使い切る、開発用のコンテナだったりCIツールだったり
  1:1はリソース占有(fluentdのような関連ツールコンテナは上がるがアプリコンテナは1つ)
 MackerelでDockerを管理
  Docker Hubにmackerel-agentを置いてある
  コマンド一発でmackerel-agentが動く
   -vで/procや/sys/fsなどをいろいろ渡している
  コンテナ毎のCPU使用率やメモリ使用率など基本的なモニタリング項目を収集できる
  コンテナの中身の情報を収集
   --linkで他のDockerコンテナにリンクして情報収集
 Agentをコンテナで簡単に立てられるのはDockerの良いところ

Docker networking tools by @n_matsuiさん

現時点のDockerネットワーク
 普通のLinuxの仕組みで構成されている
 面倒なところ
  コンテナのIPアドレスを制御できない。
   コンテナを再作成するとIPアドレスが変わる。
  ホストOSの外部からコンテナのIPアドレスにはアクセスできない。
   基本的にはポートフォワードで対処。
 Ambassador Pattern→面倒臭い。コンテナ間の通信はできるけどホストOSの外部からはできない。
Dockerのネットワーキングツール
 複数ホスト接続、仮想ネットワーク作成、IPアドレス指定、外部からのコンテナ接続、セキュリティグループ
 coreos/flannel
  kubernetesと一緒に使われることが多い
  etcdに依存しているのでインストールと設定が面倒
  docker0のアドレスを書き換えるのでdockerコマンドがそのまま使える
 zettio/weave
  インストールが簡単、シェルスクリプトをダウンロードするだけ
  weaveがdockerコマンドをラップするのでdockerコマンドは使えない
 socketplane
  Dockerに買収されたのでそのうちdockerに取り込まれるかも
  Open vSwitchとConsulを活用、インストールも簡単
  L2であればマルチキャストでクラスタを自動構築してくれる
 Docker Swarm
  Docker謹製クラスタリングツール
 jpetazzo/pipework
  仮想ブリッジを作成し任意のIPアドレスをコンテナに割り当てる
  単一ホスト上で使うツール
 rancherio/rancher
  管理の一環でネットワーキングもできる
 ツールがいっぱいある→みんな悩んでるところ
coreos/flannel
 flanneldが起動すると仮想ブリッジのflannel0が作成される
 flanneldがコンテナからのパケットをカプセル化し、対抗ホストのflanneldに渡す
 etcdで仮想ネットワークの設定情報を共有する
 任意のアドレス指定はできない
zettio/weave
 weaveコンテナを作成するとweaveというブリッジが作成される
 weaveコマンドでDockerコンテナを作成するとweaveブリッジに繋がるインターフェースが追加される
 weaverがコンテナからのパケットをカプセル化して別のweaveに渡す
OpenVNet
 あくしゅ社が開発している仮想ネットワークツール
 L2はMACtoMACで通信可能(トンネル不要)、L3(別セグメント)ではGREでトンネル化

Dockerを改修したいんだけど一緒にやりませんか by @sparklegateさん

あくしゅ→wakameやOpenVNetを作っている会社
Docker→軽量IaaS、1台で動くシンプルさが良い
CLIからAPIを叩くとコンテナがすぐに立ち上がりすぐに消せる。お手軽。
 プログラマの思考を邪魔しない。
本番環境に適用するときに悩む。本番環境のための準備が必要。
 Dockerを複数のサーバに展開する方法。
 OpenStack→DockerをOpenStack Web APIでラップ→Docker CLIが使えない。
 Kubernetes→結局Docker CLIが一部使えなくなる。
  開発者視点だとDocker CLIを使いたい。
 OpenStackのHeat、Nova→OpenStackも本番稼動として扱う必要がある
 Swarm→Dockerホストの管理を考えないといけない。
Dockerにいろんなものを足すのはあんまり良くないのでは
Dockerが1台のコンピュータで運用できる状態に戻したい
 アイデア
  コンテナを仮想ネットワークで繋ぎ、複数のコンテナを一つのコンピュータに見せる
  libcontainerにドライバを追加、コンテナをリモートホスト上に起動し接続できるようにする
 実装
  wakame-vdc + OpenVNet
  libcontainerからIaaSを呼び出し、コンテナを分散し起動
  1台のコンピュータに見えればいつものDocker CLIで操作できる
これから先起こること
 これからのアプリケーションエンジニアはインフラの知識を持たずに作る人がどんどん増えていくる
  Dockerのようなツールが充実することで下回りを知らなくてもサービスが作れるようになる
 アプリケーションの開発環境と同じものを本番でも動くようにしてあげたい

さいごに

 非常に興味深い話がたくさんあって、刺激を受けてきました。主催者の皆さん、講演者の皆さん、ありがとうございました!

AWS Cloud Roadshow 2017 福岡