Docker漬けの一日を共に〜Docker Meetup Tokyo #23 レポート〜 #dockertokyo
本日は、こちらのイベントに参加させていただきました。
Docker Meetup Tokyo #23 - connpass
参加人数は95人と大規模な勉強会なのですが、抽選倍率はさらに3倍程度あったようで大盛況。無事当選したことはなによりの喜び。ワッセロイ。
この記事では、本ミートアップの模様をお届けいたします。メインセッション３つ、LT枠5つというてんこ盛りノンストップ休憩なしというストロングスタイルの勉強会だったのですが、自分がよく知らない界隈、興味深い話が沢山聞けて物凄く楽しかったです。
訂正・補足事項などがあれば、濱田（@hamako9999）までメンションなりなんなりでご連絡いただければ、随時対応させていただきます。
それでは、皆さん、楽しんで行きましょう！
__ （祭） ∧ ∧ Y ( ﾟДﾟ) Φ[_ｿ__ｙ_l〉 Docker祭りﾀﾞ ﾜｯｼｮｲ |_|＿| し'´Ｊ
講演内容一覧
| 講演内容 | 発表者 |
|---|---|
| Docker Meetup Tokyo #23 - Zenko Open Source Multi-Cloud Data Controller | Laure Vergeron, R&D Engineer and Technology Evangelist @Scality |
| 機械学習デプロイを支えるコンテナ技術 | Chie Hayashida, Cookpad |
| KubeCon EU報告(ランタイム関連，イメージ関連) | Akihiro Suda, NTT |
| KubeCon報告とmicroscanner試してみた | @CS_Toku |
| Docker_Meetup_Tokyo_23_gVisor_network_traffic_benchmark | makocchi |
| 5分でわかる Capabilities と Privilege + KubeCon Recap | Masaya Aoyama |
| Dockerイメージのバージョン管理は GitのCommitHashよりもTreeでやると良い | Yuki Yoshida |
| KubeCon EU 2018でおもしろかったもの | Toshihiro Iwamoto |
講演資料はこちらにまとめられています。
Docker Meetup Tokyo #23 - 資料一覧 - connpass
Avoiding public cloud vendor lock-in: how Zenko, the multi-cloud data controller can help
「パブリッククラウドベンダーのロックインを避け、Zenkoによりマルチクラウドデータコントローラーを使いましょう！」
皆さん、最近マルチクラウドという単語を耳にすることも増えたかと思いますが、どういったイメージをお持ちでしょうか。代表的なユースケースを上げてみようかと思います。
- Content Distribution
- Compute Bursting
- Analytics
- Long-term Archival / cold storage
そういたユースケースに対して、Zenkoでは、マルチクラウドデータコントローラーを提供しています。
Zenko CloudServer - Open Source S3 Server written in Node.js
- Single Interface to any Cloud
- 単一のS3 APIを利用して、数多のクラウドに接続
- Allow reuse in the Cloud
- クラウドネィティブなフォーマットを維持
- Always know your data and where it is
- メタデータの検索機能
- Trigger actions based on data
- レプリケーションやロケーション変更を管理するデータワークフロー
一つのインターフェース（S3 APIベース）で、様々なクラウドへのインターフェースを利用可能。クラウドネイティブなフォーマットに対応し、APIで差分を吸収する。例えばDynamoDBへのアクセスなども同様のインターフェースでアクセス可能。
これらの特徴により、Zenkoはベンダーロックインを防ぎます。
Zenkoは、一つのエンドポイント、一つのAPI、一つのネームスペース、そして複数のクラウドネイティブフォーマットを提供します。
クライアントアプリケーションからのインターフェースはS3API形式に一本化されており、バックエンドは、独自サービス、AWSストレージ（S3、DynamoDB、Kinesis）、GCP、Microsoft Azureなどに対応しています。
Zenkoのその他の特徴
Zenko Orbit management UI
Multi-Cloud Data Management, Simplified - Zenko Orbit
専用のUIが提供されています。1TBまでのバックエンドデータの扱いが無料。エンドポイント、ネームスペース、ロケーション、レプリケーションわーっ区フロー、ハードウェアステータス等の管理が可能。
CloudServer Standalone
Zenko CloudServer - Open Source S3 Server written in Node.js
S3 APIを提供する。Dockerコンテナ。Node.jsで書かれたオープンソースプロダクト。AWSのS3APIのみで、複数種類かつ、パブリッククラウドでもオンプレミスのバックエンドデータサービス双方へアクセス可能。現在、世界中に100万のエンドポイントが存在している。
Zenko S3 API Support & Roadmap
現在は、Core S3 APIs、Adbanced S3 Apisに対応。2018年には、バケットライフサイクルや、メタデータ検索拡張にも対応予定。
Zenkommunity
デベロッパーコミュニティーの構築に注力している。コミュニティミートアップや、デベロッパーハッカソンなども実施。
濱田感想
最後に、動作デモをみることができました。基本的なセットアップはWebのGUIベースで実施可能。minicubeから、S3API（筆者には見慣れたAWS CLIベースのインターフェース）で、Windows Azure上にバケットが作成される体験はなかなか衝撃的でした。ストレージの種別が隠蔽されているのは、面白いですね。
細かな仕様の違いをどう吸収するのかはいろいろ興味がつきませんが、まずは、触ってみようと思います。
発表スライドの後半には、プロダクトのもっと詳細があるので、そちらを参考にしていただくと、よりZenkoのことを知ることができると思います。
Docker for Machine Learning（機械学習を支えるコンテナ技術）
講演者はクックパッドの、Chie Hayashidaさん。
PyConJPでPySparkについて発表したり、Web+DB Pressで機械学習系の記事を書いている。実験管理のOSSを作ったりしている。
今日お話する内容は、大きく以下の２点。
- 機械学習の発展とコンテナ技術
- コンテナ環境における機械学習のデプロイ
機械学習の活かし方
機械学習とは、「人間が自然に行っている学習能力と同様の機能をコンピュータで実現しようとする技術・手法」のことである。理論自体は1960年ぐらいの昔から存在したが、普及には2つのハードルがあった。
- 機械学習アルゴリズムの実現の難しさ
- アプリケーションとしての導入の難しさ
機械学習のプロセスは、ざっくり言うと、データの特徴を表す「モデル」をつくり、作ったモデルに対してデータを使って推論を行う。以前は、大量のデータと大規模な計算リソースが必要で、それだけの物理装置を用意することができなかった → 実用化が難しかった。
最近発展している背景には、実現するためのハードウェアやソフトウェアの進化があることが関係している。機械学習発展の背景には、それ以外にも以下の要素が絡んでいる。
- hadoop、Google Big query
- GPU（NVIDIA）
- 機械学習ライブラリの確率
- Arxivによる論文の公開
- GitHubによるソースコードの公開
これらにより、誰でも機械学習を実装できるようになった。
しかし、アプリケーションとしての導入の難しさは残る。モノリシックな環境において、機械学習導入は難しいものだった。各ロジックのインターフェースが複雑で、ソフトウェアスタックの違いを吸収するのが難しい。通常のWebアプリケーションとは、言語やライブラリが全然違う。
さらに、データサイエンティストにとって、サービス開発に必要な非機能要件の検討が難しい。作ったら、作りっぱなしになったり、運用要件の確率や可用性、冗長化の設計に慣れていなかったりする。そこに、コンテナ技術の進歩による機械学習のマイクロサービス化が進んできた。
- 独立したソフトウェアスタックによる、ロジックの分離
- リソースの分離
- 非機能要件を設定ファイルで管理
- 作業分担を明確化
- CD（Continuous Delivery）の導入
マイクロサービス的に機械学習アプリケーションを１つの独立したサービスとして提供可能になった。開発もデバッグも、依存関係が整理されるので、非常にやりやすくなった。
コンテナ技術により、今までの機械学習アプリケーション導入の難しさが解消されつつある。
とはいえ、アーキテクチャの複雑さの問題がなくなったわけではない。
アーキテクチャ検討例①「コンテナの分離」
モデルの違いにより必要なリソースタイプが異なる。例えば、データ処理はメモリを使うことが多く、推論はCPUやGPUを酷使する。ここは分けたほうがリソースコーリツが良い。
モデルの再利用を意識したコンテナの分け方がキモになる。
アーキテクチャ検討例②「スケーラビリティの設計」
コンテナの分離により、コンテナ毎のスケーラビリティの確保が可能
アーキテクチャ検討例③「コンテナ配置設計」
各ハードウェアリソースに対するコンテナの配置を物理的に考慮する必要あり。
アーキテクチャ検討例④「GPU環境へのデプロイの難しさ」
GPUはcgroupによるリソース管理の対象外なので、GPUへのデータ転送などが難しい。そのために、GPUリソース監視の仕組みの導入が必要であったり、GKEでもalphaクラスタでしか使えないものがある。推論においてはGPUが不要なケースも多いため、問題となりにくい。
アーキテクチャ検討例⑤「モデル再学習」
モデルの再学習にはGPU環境との連携が必要。流行語の変遷を追うためには、定期的に再学習を実施する必要あり。
Kubeflowについて
kubeflow/kubeflow: Machine Learning Toolkit for Kubernetes
- 中小規模の利用にはスペックオーバーな気がする
- tf.servingは便利で、それで十分かも
- 分散学習が必要な規模のプロジェクトは日本では多くない
- 実験環境とプロダクション環境の切り分けも必要
フルマネージドサービス
- SageMaker
- Cloud ML Engine
- Azure ML
かなり進化してきたので、便利に使える感触はあるが、まだまだ発展途上の感がある。
実証段階からDockerを利用する
研究開発部には所属しているが、プロダクトとしてデプロイすることを前提としている。そのために、プロダクトデプロイのためのコンテナも意識する必要がある。
nvidia-docker
NVIDIA/nvidia-docker: Build and run Docker containers leveraging NVIDIA GPUs
CookieCutter Docker Science
リサーチャーもDockerを利用可能となり、実験段階から環境を共通化し、実験内容の共有や、再現性の担保、デプロイの容易化に利用している。
まとめ
- コンテナ技術は機械学習デプロイに欠かせない存在になりつつある
- マイクロサービスにより全てが解決するわけではないが、サービスの堅牢性を高める手段として便利
- 実験時からデプロイを意識したコンテナ利用を行うことで効率性があがる
- 分散学習やGPUを用いた推論への対応、今後はマネージド・サービスにも期待したい
濱田感想
機械学習の文脈でのコンテナ活用について、全くイメージが沸かなかったのですが、機械学習の基礎の基礎から解説してもらったので、その界隈においてコンテナが必要とされる理由や使われ方が非常に良くわかり、腹落ちしたセッションでした。
足を踏み込んでいくと物凄い奥深く敷居が高いイメージが強い機械学習ですが、最近はパブリッククラウドベンダーのマネージドプラットフォームも多数出てきているので、コレを機に食わず嫌いにならないようにいろいろ試してみたいと思える、素敵なセッションでした。
KubeCon + CloudNativeCon EU 2018報告(ランタイム関連、イメージ関連)
講演者は、NTTソフトウェアイノベーションセンタの須田 瑛太さん。
KubeCon + CloudNativeCon EU 2018、に参加してきました。そこで自分的に気になったトピックを4つほど紹介します。
参加者4000名、日本からは50名ほど。どんどんDocker界隈が盛り上がっているのを肌で感じます。
トピックはこちら。
- Container Isolation at Scale(... and introducing gVisor)
- The Route To Rootless Containers
- Entitlements: Understandable Container Security Controls
- Building Images on Kubernates - Toward a first class aproach
Container Isolation at Scale(... and introducing gVisor)
概要：カーネルをコンテナから分離すること（gVisor）でセキュリティを強化した、OCIコンテナランタイムrunscを提案
- Linuxカーネルをユーザランドで再実装（Go）
- ptrace版とKVM版がある
- runcの代替として使える
- Meltdownを防ぐデモが展示されていた
嬉しいことは、CPUのセキュリティリスクからコンテナーが隔離される点など。
- 向いているもの
- 小さいコンテナー
- セットアップが早い
- 向いていないもの
- 信頼された実績のあるイメージ
- システムコールを頻繁に呼ぶもの
手元で試して見た限りでは、gVisorを利用すると、おおよそ7倍ぐらい処理が重たくなる感触。
The Route To Rootless Containers
概要：root権限無しでコンテナランタイムを動かすことで、セキュリティを強化する取り組み
- 課題1:複数ユーザーをコンテナーで利用する場合がある
- newuidmapを使用する
- 課題2:cgoupsを利用可能にする
- 予めrootでchownしておく
- 課題3:CoWファイルシステム
- Ubuntuならrootlessでoverlayfsが利用できる
Entitlements: Understandable Container Security Controls
概要：'docker run'の --privilegedや--cap-addなどのセキュリティ関連のフラグを簡潔に記述できるようにする取り組み
Imageを作る時に、Imageにサインする動作。Docker統合の準備はできているが、デザインが固まっていないため、まだPRはでていない。Kubernatesへの実装も容易されている。
Building Images on Kubernetes - Toward a first class aproach
概要：Kubernetes上でコンテナイメージをビルドする取り組み。
Kubernatesに関係するイメージビルドツールが登場している。是非一度触ってみて欲しい。
LT: KubeCon報告とmicroscanner試してみた
今日の「KubeCon報告とmicroscanner試してみた」の資料です。https://t.co/83z43ghBVr#dockertokyo
— とく (@CS_Toku) 2018年5月15日
気になった要素
- gVisor
- CSI
- Cilium
- セキュリティ系
- Kube-bench
- microscanner
Aqua Container Security - Docker, Kubernetes, OpenShift, Mesos
microscannerとは
aquasecurity/microscanner: Scan your container images for package vulnerabilities with Aqua Security
Aqua Securityuが出しているツール。コンテナイメージに対するセキュリティスキャンをしてくれる。Free版、SaaS版、PaaS版がある。Free版はパッケージスキャンのみ。今回は、Free版を試してみた。
- 登録してトークンを取得
- Dockerfileの最後にコマンドを追加
- 結果を確認
パッケージが古いほど、沢山脆弱性がでてくる。導入コストは低いので、とりあえずやっておいて損はないのでは？まずはFree版で試してみましょう！
microscannerはとりあえず入れてみるかhttps://t.co/LaOiWutdlR #dockertokyo
— Ｇ (@gee0awa) 2018年5月15日
LT: gVisor での Network Traffic の性能を比較してみた
gVisorを利用した場合のネットワークトラフィックについて、性能をためしてみた様子をお届けします。
install gVisor
gVisorの導入の仕方は簡単。Dockerで動かす場合は、runtimeを追加してあげればOK。
limitation of gVisor
- Dockerで動かすなら 17.09以上が必要
- Podの中に1つのコンテナしかサポートしてない
- 一部のsystem callが動かない
gVisor's Network Performance
iperf3を利用。比較のためにVM同士とruncも計測。実際に計測してみると、かなりネットワーク性能が落ちる。Sentryがpacketを処理するためにそこがネックになる。
まとめ
普通に使うとかなりNetwork性能は落ちるが、--network=hostを設定することで、ある程度はパフォーマンスを出すことができる。その他考慮点を頭に入れ、適切なユースケースで使うのが望ましい。
runsc (gVisor) は runc (Docker) と比較してコンテナ・ホスト間のネットワークパフォーマンスは相当落ちる。実は runsc は隔離のために自分自身の network stack を構成しているので、隔離性を犠牲にしてこれを無効化するとそれなりに改善する。 #dockertokyo
— チェシャ猫 (@y_taka_23) 2018年5月15日
gVisor はミドルウェアみたいなネットワーク含むシステムコール激しいのはかなり苦手で、1リクエストに対していくつか他のものを叩くみたいなユースケース向けって感じありますね#dockertokyo
— _ (@apstndb) 2018年5月15日
LT: 5分でわかるCapabilityとPrivilege
root権限と一口にいっても、rootの中にも複数の種類が割り当てられている。デフォルトのCapabilityではホスト名の変更は受け付けられない。その場合は、必要なCapabilitiesを渡してあげる必要がある。
歴史的に UID 0 = root は文字通り何でもできたけど、そこから特権を選択的に付与できるのが capability って感じでしたね#dockertokyo
— _ (@apstndb) 2018年5月15日
なるほど，Dockerコンテナ内のroot権限で動いているプロセスの権限を制限されていて（Capability），権限が不足する場合はdockerコマンドのオプション --add-capを使えば良い．--privilege=trueだとほぼすべての権限が与えられてしまう，と． #dockertokyo
— だーすー（Hiroshi Suda） (@suda_hiroshi) 2018年5月15日
LT: Dockerイメージのバージョン管理はGitのCommitHashよりもTreeでやると良い
- AWSのECRとECSを利用
- デプロイはTeffaform
- アプリはGo、Python、Javaなどいろいろ
- GitHubとDrone
- 開発はGitHub Flow
- デプロイにはGitLab Flow
開発の流れは以下の通り
- ECRを本番環境AWSアカウントに構築
- イメージは不要な更新により即、プロダクション環境に影響がある
- 開発環境からのスイッチロールでアクセスを制限することにより、ECRにアクセスする人を制限
- GitLab Flowにより、各環境（開発、ステージング、本番）用にブランチを作成
- デプロイ先環境とブランチを1対1で対応させることで、デプロイを直感的にわかりやすくしている
このフローをそのまま回すと、ECRにイメージが各環境ごとに複数作成されるためムダが多い。そのため、Treeを利用してイメージにタグを付けることで、ディレクトリ構成のファイル内容と同一のものは同じイメージを利用することで、ムダを省きデプロイフローをシンプル化することに成功した。
駄目だ駄目だと思いながらlatestタグ使ってしまっている勢なのでこの気に卒業したい#dockertokyo
— yokomotod (@yokomotod) 2018年5月15日
吉田さんのワークフローの話。昨年の #gitlabjp GitLab Meetup Tokyoでの話からかなり進化してる！！！ #dockertokyo
— Takuya Noguchi / tnir (@tn961ir) 2018年5月15日
楽しかったです。最後の懇親会も、Androidエンジニアはゲット出来ませんでしたが、色々な方とお話出来ました。管理者の方とSupershipの方々もありがとうございました！ #dockertokyo
— Yuki Yoshida (@yshd) 2018年5月15日
LT: KubeCon EU でおもしろかったもの (caicloudのunionpay事例, cilium)
Kubernetes on Supporting $8 Trillion Card Payments in Chine
- SSO
- 一回ログインすればk8sでもOpenStackでもつかえる
- マルチテナント
- ネットワーク
非常に面白いセッションだったので、ぜひ皆さんもググって参考にして欲しい。
Accelerating Envoy with the Linux Kernel
Cilium, kube-proxy の置き換えまでできるって話あるしちゃんと見てみたいところあるhttps://t.co/lVTsoE5OKw#dockertokyo
— _ (@apstndb) 2018年5月15日
参加レポートなど、まとめは、近日こちらで公開予定！！
Kubernetes もそうだけど、コンテナ全般に対する中国の食いつきすごいですよね。検索すると一番詳しい記事が中国語だったりするし。VM ベースのパブリッククラウドが制限されてたせいじゃないかと誰かが指摘していた記憶がある。 #dockertokyo
— チェシャ猫 (@y_taka_23) 2018年5月15日
中国のcaicloud?がやばい？？エンタープライズでSSO、マルチテナント、HA、NW帯域制御とか提供しちゃっているらしい？？！ #dockertokyo
— YoS (@17_YoSK) 2018年5月15日
まとめ「Docker界隈あつすぎやろ、これ」
ぶっちゃけ自分は、Dockerやコンテナ全般に対して知見が深いわけではないので、非常に楽しみにしていた勉強会でした。期待にそぐわず、セッション内容が多岐にわたっていて盛りだくさんで、各発表者の熱量もすごく、懇親会も含めてすごく楽しめた勉強会でした。
AWS界隈でも既に実績が豊富なECSから、東京リージョンが熱望されるFargate、GAが待ち遠しいEKSなど、今後のリリースロードマップが非常に豊富で、楽しみなところ。
アプリケーションホスティングの選択肢として完全に無視できなくなっているコンテナ界隈。今後もウォッチし続けていこうと思います。
たくさんの勉強をさせてもらって
懇親会で他社の色々な話を聞けて、消化できなかった謎も抱えつつ帰宅中。大変勉強になりました！！ありがとうございました#dockertokyo— endo-k (@endo__k) 2018年5月15日
#dockertokyo 今日も色々勉強になりました。補欠からの繰り上がりだけど参加できて良かったです。ありがとうございました！！
— kabukawa (@kabukawa) 2018年5月15日
#dockertokyo ピザとビール！！！ pic.twitter.com/tAbbgOUYWB
— kabukawa (@kabukawa) 2018年5月15日
それでは、今日はこのへんで。濱田（@hamako9999）でした。
![[レポート] インシデント発生に備えるための議論をする tabletop「Incident response tabletop: Supply chain」 #GHJ205-R #AWSreInvent](https://images.ctfassets.net/ct0aopd36mqt/3IQLlbdUkRvu7Q2LupRW2o/edff8982184ea7cc2d5efa2ddd2915f5/reinvent-2024-sessionreport-jp.jpg)
![[レポート]re:Invent 2024のEXPO会場で救急セットを作ったりして #GiveBack しよう #AWSreInvent #ACT126](https://devio2024-media.developers.io/image/upload/v1733389602/user-gen-eyecatch/myjtprkzjjcwvxmf8enu.png)
