03/29(金) は「Cloud Native Meetup Tokyo #7 @Abema Towers」に参加してきました。
会場は サイバーエージェント さんの新しいビル、Abema Towersにあるセミナールーム。
まだできたてホヤホヤのビルで、夜景もきれいに見えました。ビルの完成記念興行的ななにかが行われていました(笑)
目次
Cloud Native Meetup Tokyo とは
イベントの概要から引用します。
Cloud Native に近しい技術や CNCF がホストするプロジェクトについて共有し合う会です！ 昨今はコンテナ関係のエコシステムが大量に増えてきましたが、それらの技術検証結果などを発表しあう場として利用していきたいと思っており、仲間を募集しております。
何故参加したか
今回で5回目の参加です。 1回目から4回目まではなんとか参加できていたのですが、5回目から抽選で外れることが続き、久しぶりの参加になります。
アジェンダ
| Time | Theme | Speaker |
|---|---|---|
| 19:00～19:05 | Opening | |
| 19:05～19:35 | Telepresence ではじめる k8s 時代の ローカル開発 |
Toshihiro Goto @_shiro16 (GMOペパボ) |
| 19:35～20:05 | Introduction to Consul Kubernetes Integration and Consul Connect |
Ryo Takaishi @r_takaishi (GMOペパボ) |
| 20:05～20:35 | 分散イメージレジストリの検討 〜Beiran & Dragonfly〜 |
安田 侑史 @yupeji (クリエーションライン株式会社) フルカン ムスタファ@furkanmustafa (Rainlab 株式会社) |
| 20:40～21:40 | 懇親会 & LT * 2 | Sponsored by CyberAgent |
内容
Telepresence ではじめる k8s 時代のローカル開発
Toshihiro Goto @_shiro16 (GMOペパボ) さん
telepresence とは
元々はDatawire社が開発してOSSにしたものが Cloud Native Computing Foundation にホストされるようになったらしい。
以下を可能にするソフトウェア
- 単一のサービスをリモートのKubernetesクラスタに接続しながら、そのサービスをローカルで実行すること
- そのサービスがクラスタ内の他のサービスに依存している場合でも、単一のサービスの迅速なローカル開発を行うこと
- ローカルの開発マシンをKubernetesクラスタの一部のように動作させること
telepresence なし
telepresence あり
解決できる問題
- image build -> push -> pod の image 更新の手間を省くことが可能になる
- リモートのKubernetesクラスタに接続しながら開発で可能になる
- ローカルから他のサービス(マイクロサービス的な他のサービスや DB)に接続が可能になる
- kubernetes のサービスの一部として機能するので、アクセスした際のネットワーク経路がほぼ同じになる
快適に開発ができる
telepresence の使い方
資料には以下の場合のコマンド例があります。
- ローカルで起動した server にアクセスを流す
- ローカルで起動した docker 上で起動している server にアクセスを流す
詳しくは以下を参照。 (資料に書かれていた https://www.telepresence.io/howto は404でページが無くなっていたみたいなので、ドキュメントへのリンクを貼っておきます)
telepresence の処理の流れ
資料に詳しく書かれているので読んでみてください。
取り敢えず試してみた人向け
GKE向けサンプル(developing-services-with-k8s.md に詳しい使い方が書かれています)
@_shiro16 さんの公開されている telepresence のサンプル
個人メモ：
- この動き、ありそうで無かった気がする。なかなか便利そう。
- kubernetesを使う案件があったら是非使ってみたい。
- @_shiro16 さんは以前Elasticsearchの勉強会で発表されていたのをお見かけしていたので、技術の幅が広いなぁと思いました。
- どうでもいいけど、Datawire社の各プロダクトのマスコットキャラ(ペンギン？)かわいくないですか？バッドばつ丸みたいじゃないですか？(興奮)
Introduction to Consul Kubernetes Integration and Consul Connect
Ryo Takaishi @r_takaishi (GMOペパボ) さん
Consulとは？
あらゆるランタイムプラットフォームとパブリックまたはプライベートクラウドにまたがってサービスを接続、保護、および構成するための分散型サービスメッシュ
- 接続性のためのService Discovery
- ヘルスチェック、DNS、HTTPインターフェース
- セキュリティのためのサービスセグメンテーション
- 安全なサービス間通信
- 実行時設定のためのサービス設定
- KVS、トランザクション、ウォッチ
アプリが死んでも app.service.consul が Consul Cluster 内の振り分けなどを自動的にやってくれる。
今回の発表の背景
- IaaS上にConsulクラスターを構築
- nginx → rails への通信などをconsul-templateで動的制御
- health-checkと組み合わせて、正常なノードだけぶら下げる
- service-to-serviceの際の名前解決にConsul DNSを使用
- IaaS上にKubernetesを構築して使おうとしている
- いきなり全て移行するのは大変だしリスク高
- 既存の環境とうまく連携したい
- → Kubernetes Integrationがあることを知り検証・利用
- → その過程でConnectについても検証
Consul Connect (Service Segmentation for security)
以下のような機能を提供
- Service Access Graph
- Sidecar Proxy
- Envoy Integration
- Certification Management
- Native App Integration
Sidecar Proxy は プラガブルになっていて、Envoy Integration 機能により Envoy を使うことも可能
Consul Connect まとめ
- Consul Connectを使うことで手軽にservice-to-serviceの暗号化や通信の制御を行うことが可能
- 既にConsulを使っている場合は試してみると良さそう
- Envoyを使う場合、機能を全て活用することはできないので注意が必要
Kubernetes Integration
- Consul ServerをKubernetes上で動かす
- Consul ClientをKubernetes上で動かす
- ConsulのServiceとKubernetesのServiceを同期する
- Consul Connect Sidecar ProxyのPodへのInjection
- GitHub - hashicorp/consul-k8s: First-class support for Consul and Kubernetes. Run Consul on Kubernetes, integrate Connect, sync services, and more.
- Service SyncやConnect Injectionを提供
- GitHub - hashicorp/consul-helm: Helm chart to install Consul and other associated components.
- Consul Server/Clientや上記のconsul-k8sをhelmで提供する
Consul ServerクラスターをKubernetes上で動かす
- 既にConsulで管理しているリソースがあると、それらも含めてConsulで管理できるので便利
サービスディスカバリの同期
- Kubernetes ServiceをConsul Serviceへ同期
- Consul ServiceをKubernetes Serviceへ同期
Kubernetes Integration まとめ
- Kubernetes上でConsulを動かす機能を提供
- ConsulとKubernetesで相互にサービスを同期可能
- Consul Connect Sidecar Proxyをinjectionする機能を提供
- 既存のConsulクラスターとKubernetesが並行稼働している場合、連携させることで便利になりそう
まとめとおまけ
GMO Pepabo sponsors CloudNative Days Fukuoka 2019!
個人メモ：
- Consul、名前は聞いたことあるけど知らないことが多かった。
- 既に導入しているところにとっては、連携機能は便利そう。
- トラブル発生時の原因切り分けとか、仕組みが複雑になると大変そうなイメージなので、そのあたりの話を聞いてみたい。
- ConsulとEnvoyについてはこんな文書をHashiCorpが出しているのでリンクを貼っておく。
分散イメージレジストリの検討 〜Beiran & Dragonfly〜
安田 侑史 @yupeji(クリエーションライン株式会社) さん
フルカン ムスタファ@ furkanmustafa(Rainlab 株式会社) さん
Consideration of Distributed Container Image Delivery - CodiMD
Docker イメージのダウンロードを分散ダウンロードできるようにして高速化できないか？というアプローチ。
- Bittorrent
- Dragonfly
- Kraken
- Beiran
分散ダウンロードの仕組み(Peer to Peer)
Bit torrent のようなものだと考えるとわかりやすい
https://tech.nikkeibp.co.jp/it/article/COLUMN/20080226/294799/
最近、相次いで同様の機能を提供するものが発表された。
- DragonFly
- Kraken
- Beiranは、ピアツーピアの一般的なパッケージ配布ツール
- それは現在、いくつかの小さなコンポーネントで構成されている
- beirand - Beiran Daemon
- beiran - CLI
- plugins
- docker
- kubernetes(+docker) - CRI ImageService
- 開発中のPlugins;
- containerd
- apt
- npm
- beiran インストール前
docker image pull python:3.7
- beiran インストール後
beiran docker image pull python:3.7
- Beiranは基本的にマシン間(最終的には、BitTorrentソフトウェアのように、信頼できないマシン間でさえも)でパッケージを共有することを可能にする単純なソフトウェア。
名前の由来
開発中のものを動作デモ。表記単位がB(バイト)なのはバグらしい(笑)
Roadmap
この後やりたいこと
個人メモ：
- Dockerのイメージが大きくてダウンロードに時間がかかるという問題に対して、サイズを減らす以外にこんなやり方が考えられているというのが面白い。
- 使っているのはいわゆるP2Pなので枯れた技術なんだけど、ネットワークを有効活用する意味でも期待。
- ただ、日本企業はプロキシが融通が利かなかったりP2P禁止！と息巻いていた時期があるので、普及するには時間がかかるのかもな、と思った。
LT1:Jibの話
Hayakawa Hiroshi(@hhiroshell) さん
Jib
Javaアプリケーション開発者にとって辛いこと
- Dockerfileを編集
- docker build / push
これを Jibが解決
個人メモ：
- IDEとかのサポートができるようになれば、Java開発者にとってはあまり覚えることを増やさなくても対応できるのはいいかも。
- 開発の流れをコンテナ周りの作業でぶった切らないように配慮されているところが開発者中心の考え方っぽくて好き。
- とはいえ、Dockerfile相当のことを書くことになるのは変わらないようなので、標準的な手順を覚えておいたほうが後々困らないのでは？という意味で個人的にはDockerfile覚えて書くのも悪くないと思った。
LT2:明日、業務で使える Scheduler Extender
チェシャ猫(@y_taka_23) さん
Scheduler Extender
- Webhook による処理を追加
- 指定した外部サーバと JSON をやり取り
- 拡張できるポイント䛿 4 つ
- Filter - Node の候補をさらに絞る
- Prioritize - Node のスコアリング関数を追加
- Preempt - 追い出される Pod の候補を絞る
- Bind - Pod と Node の紐づけを委譲
- 拡張点 1 : Filter
- Node のフィルタ条件を追加できる
- その Pod を載せたくない Node を選べる
- 拡張点 2 : Prioritize
- Node のスコアリング関数を追加できる
- スコアが大きい Node ほど選ばれやすい
- 拡張点 3 : Preempt
- Preempt の犠牲になる Pod を選択できる
- Pod は自由に指定できず、候補から選択
- Preempt Extender の重要性
- Preemption で殺されない Pod
- PodPriority だけでは制御できない
- 拡張点 4 : Bind
- Pod を Node に紐づける操作を委譲
- Node 上で時間のかかる前処理ができる
個人メモ：
- Scheduler Extender、先月の Kubernetes meetup tokyoでも触りの話を聞いたけど、わかりやすい説明で「俺にもできるかも」という気持ちにさせるのはさすがだと思った。
- 実際の現場で使う場面はありそうと思ったが、SESの現場にはそもそもKubernetesが採用されている可能性は低いので、当面は手元での勉強にとどまる可能性が大きい。
懇親会
懇親会、全体の写真や食べ物、飲み物の写真を取り忘れたので、自分の分を撮った写真を貼っておきます。
まとめ
こちらも久しぶりの参加でしたが、どの講演も新しいことを学ぶことができてとても参考になりました。 会場が広くなって、参加しやすくなったことは個人的にはとても嬉しかったです(最近抽選で漏れることが続いていたので)。
尚、名物(？)の名札については初めて参加した方も結構喜んでいる感じの話を耳にしたので、この試みは個人的に素敵だなぁと思います。 このツイートに主催者の想いがこもっていると思いますので貼っておきます。
この名札は皆さんが交流してもらえたらと作ってます。
— MasayaAoyama（青山 真也） (@amsy810) 2019年3月29日
結構話してる人多くて嬉しい。
（カッターで頑張ってるので最近裁断機の必要性を感じてます） https://t.co/gN04rJS8y7
また参加できればいいなと思います。 スピーカー、スタッフ、参加者の皆様、ありがとうございました！
