この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
2015年3月28日(土)に開催された、「第11回 クラウドごった煮（コンテナ勉強会）」に参加してきました！
場所は産業技術大学院大学。
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さん
RHEL Atomic Hostの（アドリブ）発表資料です！ http://t.co/TPBgy4UIma http://t.co/Hq4dC2K6Xw http://t.co/P5dbtPQOCf #cloudmix
— E. Nakai (@enakai00) March 28, 2015
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がコンテナ統括管理(オーケストレーション)用ツールを開発中 MachineはVagrantに似てる 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などと一緒に使えるツール→flannel、weave socketplane→最近Dockerが買収 OpenVNet 株式会社あくしゅが開発しているオープンソースのネットワーク仮想化ソフトウェア Openflow 1.3とGREで分散エッジオーバーレイ 似ているプロダクト→NSX、midonet、Open 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で検索してみるといろいろ出てくる
Raspberry Pi にDocker を入れるための色々を用意してくれているGithub のリポジトリ https://t.co/oCc0msPiqy #cloudmix
— Deep (@deep_tkkn) March 28, 2015
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のようなツールが充実することで下回りを知らなくてもサービスが作れるようになる アプリケーションの開発環境と同じものを本番でも動くようにしてあげたい
さいごに
非常に興味深い話がたくさんあって、刺激を受けてきました。主催者の皆さん、講演者の皆さん、ありがとうございました！
35
