4/9(木) に開催された CoreOS Meetup Tokyo #1 に行ってきました。
3時間の中でイントロ除いて発表が7つあり、かなり内容が濃かったです。
一番面白かったのは @kawamuray さんの Docker に CRIU を実装した発表でした。
CRIU はコンテナ界隈でも注目度が高い技術のようで、近い将来、この時デモで見たような機能が誰でも使えるようになるかと思うととても楽しみです。
また、Wantedly や pixiv で実際にプロダクション環境で運用している話も聞けたのは収穫でした。
コンテナ技術は運用ノウハウがまだ業界的に溜まっておらず、各社手探りでやっている印象を受けました。
一方で、@higebu さんの次のコメントが特に印象に残りました。
バグは何にでも存在するからバグを恐れてたら何もできないんだよな #coreosjp
— Yuya Kusakabe (@higebu) 2015, 4月 9
この辺りの技術の選定に関しては、OS を提供する側のクラウド事業者と OS を利用するサービス事業者で考え方が変わってきそうです。
以下、発表内容です。
資料は connpass にもまだ上がってないものもありますが、アップされたら更新するつもりです。
Introduction of CoreOS
@deeeet さん
※遅刻して後半部分しか聞いてません。
- CoreOS の紹介
- Motivation
- かんたんに自動アップデートできる
- セキュア
- 機能
- 最小限
- コンテナベース
- パッケージマネージャや言語ランタイムはない
- クラスタリング => Data Center as a Computer
- 技術
- etcd, fleet, rkt, flannel
- 使っている企業
- DEIS, memsql, CloudFoundry
- 最近の話題 ... TECTONIC
- Motivation
rkt
@mopemope さん
Abby CTO
- rkt
- App Container Runtime
- App Container Spec の次の2つを実装
- App Container Executor
- Metadata Service
- Pod サポート
- App Container Manifest
- コンテナの定義のようなものか
- JSON
- Docker との違い
- アーキテクチャ
- network plugin は自力で差し替えることもできるらしい
- rkt commands
- trust ... 信頼するImageの取得先を追加
- fetch ... Image DL
- docker://〜 で docker image も取得できる
- prepare ... 起動直前まで持っていく
- list
- run ... 実行。prepare and run
- Private ネットワーク (静的割当てのみ)
- NAT
- Bridge
- MacVLAN ... dhcp には非対応
- 近々 IP VLAN に対応するらしい
- Port Forwarding ... 昨日サポートされた
- DEMO
CoreOS OEM on NIFTY Cloud
@higebu さん
- ニフティクラウドとは
- CoreOS の OEM とは
- CoreOS をいろんなプラットフォームで動かせる
- OEM = Original Equipment Manufacturer
- Community Supported <= CoreOS 公式サポートとは異なる
- 自分のプラットフォームで動かすための修正を pull-req => merge してもらう
- やりとりは全て GitHub 上で完結
- https://coreos.com/releases/#534.1.0 でリリースされた!
- CoreOS をいろんなプラットフォームで動かせる
- ニフティクラウドで CoreOS が使えるようになるまで
- https://github.com/coreos/ の各リポジトリを修正
- open-vm-tools を使う
- oem-niftycloud と niftycloud format の中身
- https://coreos.com/docs/running-coreos/cloud-providers/niftycloud/JA_JP/
- CoreOS 初の日本語ドキュメント
- CoreOS をビルドするときの Tips
参考
ちなみにCoreOSをビルドしたい人向けの情報は https://t.co/RGo2CfNDla にまとまっていて、自分ががんばっていた頃よりは充実してきています #coreosjp
— Yuya Kusakabe (@higebu) 2015, 4月 9
OpenShift v3 on CoreOS
OpenShift v3 で Docker の PaaS を作る話
@jacopen さん
- 自己紹介
- INGRESS
- Cloud Foundry
- Open Shift
- v3 ... Docker ベースでアーキテクチャを一新した
- DEMO
- Web Console
- できることは少ない
- CLI からデプロイ
- Web Console
- OpenShift の構成
- Docker
- kubernetes
- Project Atomic => 今回は CoreOS に置き換えた
- kubernetes
- k8s 自体が PaaS じゃないの?
- 足りない機能がある => OpenShift で補う
- ユーザ管理
- アプリケーションのライフサイクル管理
- Multi Tenant = 複数サービスで同一の筐体を共有する
- OpenShift k8s image deploys
- Image をコンテナに Deploy
- source-to-image https://github.com/openshift/source-to-image
- Routing
- Request のコンテナへの Routing
- デフォルトでは HAProxy が Pod で起動する
- => ELB や BigIP を使うことも
- GitHub WebHook 連携で source deploy
- 他にもいろんなトリガーが仕掛けられる
- まとめ
- OpenShift 今年夏ぐらいに正式リリース予定
- やり残したこと
- Multi node デプロイ
- openshift-sdn を CoreOS で動かす
- Fleet を活用して運用
参考
CoreOS 運用の所感
@spesnova さん
Wantedly で CoreOS を実運用している
Docker 特集 in WEB+DB PRESS vol.86
- 今の運用方法
- CoreOS EC2 上で動かしてる
- Nginx で画像をリサイズするコンテナのホストに
- 次は Elasticsearch クラスタで
- デプロイ
- 新しいEC2インスタンス
- cloud-config でコンテナ起動
- ELB 配下を blue-green
- VPC 内の EC2 上で CoreOS を動かす - Qiita
- ログ
- journal を全部 logentries という SaaS に送っている
- log - CoreOS 上の全てのログをリモートサーバへ送る - Qiita
- fluentd でもよさそう
- 監視 => DataDog
- etcd, fleet 使ってない
- 使うとダイナミックオーケストレーションになる
- fleet はリソース管理できない
- 使うとダイナミックオーケストレーションになる
- 自動アップデートオフ
- 全台リブート困る
- locksmith が必要
- 何台同時にアップデートできるか制御できる
- etcd が必要 <= 使ってない
- 手動アップデートしてる
- etcd, fleet 使わない上での CoreOS のメリット
- ホストマシン構築タスクがほぼない
- AMI 焼く必要すらない
- セキュリティ対応が楽
- blue-green で
- 起動が速い
- 遭遇した問題
- CoreOS が EC2 でクラッシュ
- CoreOS アップデート中に btrfs 起因で Disk Latency
- CoreOS channel 選び
- alpha は品質でない
- アップデートが来る頻度
- 致命的なアップデートも来る
- stable で出た問題が alpha => beta の順で直る
- stable が stable になるまで beta でいいんじゃないか
- alpha は品質でない
- 解決したい問題
- Dev が多い
- Dev/Ops
- Dev => containers
- Ops => platform
- ダイナミックオーケストレーションどうするか
Fleet について
- Overview
- Distributed systemd
- Depends on systemd and etcd
- Low-level scheduler
- Simple orchestration
- Job scheduling flow
- Job を Registry (etcd) に登録
- Engine が Job Unit を Agent に送信して実行させる
- Engine アルゴリズム
- "least-loaded" - 最も実行Jobが少ないAgentに割当て
- リソース管理はしない
- Unit States ... Job (service) の状態
- Cluster-level
- inactive => loaded => launched
- Cluster-level
Docker + Checkpoint/Restore
Yuto Kawamura さん
3月まで東工大修士で Docker の研究をしていた。
- CoreOS は関係ない
- Checkpoint/Restore を使ってコンテナの起動を高速化
- 応用例 - Live migration
- LXC で複数の実装例
- 今回 CRIU を使った目的
- 起動が遅いサービスの起動の高速化
- リソース効率の最大化
- 問題点の1つ
- アプリケーションによっては起動がとても遅い
- JVM とか
- アプリケーションによっては起動がとても遅い
- 解決策
- Checkpoint/Restore 機能を Docker daemon に実装した
- Docker の実行コマンドを CRIU 経由に差し替え
- CRIU と Docker は相性がいい
- DEMO
- 今回やれなかったこと
- CoreOS を使った Live Migration のデモ
- /usr が RO で、書き込む方法がわからなかった
- (参考) https://twitter.com/higebu/status/586140189451390976
- CoreOS を使った Live Migration のデモ
Kubernetes on CoreOS
@IanMLewis さん
- Compute as a Continuum
- Pods
- Replication Controllers
- Pod が落ちたときに再起動する
- リソース管理
- memory, cpu 使用効率を最適化
- Service
- Pod が動いているホストを意識しなくていい
- アーキテクチャ
- Master
- apiserver
- controller-manager
- scheduler
- register
- apiserver
- Minion
- kube-proxy ... NW をハンドリング
- kubelet ... プロセス管理?
- Master
- DEMO
- GCE に CoreOS インスタンス起動
- metadata にファイルを指定
- kubectl.sh proxy 起動
- container(pod)起動
- instance (container ?) 増やす
- GCE に CoreOS インスタンス起動
CoreOSで運用する際に考えないといけないこと
@harukasan
pixiv
- @harukasan
- pixiv における CoreOS
- Release 554 から使い始めた
- IDCF クラウド
- 1ノード1コンテナ
- pixiv マンガ
- Scala + Play
- 構成
- IDCF
- LB
- App <= ★CoreOS
- オンプレ
- LB
- RPC
- IDCF
- デプロイ
- fleet
- cloud-config で設定が流し込まれる
- ローリングアップデートできない
- 1台1台やってる
- モニタリング
- td-agent
- dd-agent
- なぜ CoreOS ?
- コンテナだけ必要 => CoreOS でいいんじゃ?
- 実現したいこと
- なるべく状態を気にしない
- コンテナ以外の状態を変えない
- なるべく状態を気にしない
- CoreOS に対する見解
- systemd がメイン
- パッケージ管理システムは要らない
- アプリケーションプロセスはコンテナに向いてる
- 1プロセス
- 依存ライブラリが多い
- etcd tips
- 最低でも4台
- 3台だと1台落ちるとスプリットブレインになるので、ローリングアップデートできない
- CoreOS を使う上で考えないといけないこと
- オーケストレーション
- デプロイ
- 監視
- コンテナ名をつけずにmackerelで監視してたらノード増えすぎてひどいことに
- 何を監視するか
- サービスレベル、ノードレベル、コンテナレベル
- ログ転送
- 障害対応
- 自動アップグレード
- locksmith
- fleet のバージョンが上がったときに管理ホスト側の fleetctl も上げないといけない
- ネットワーク
- セキュリティ
- CoreOS が見るのはホストOS だけ
- コンテナの脆弱性は別途ケアしないといけない
- まとめ
- 結局なんやかんや必要になる
- ほんとに Kubernetes 自分たちで運用するのか
- それ AMI でいいんじゃ