weblog of key_amb

主にIT関連の技術メモ

CoreOS Meetup Tokyo #1 に行ってきた #coreosjp

f:id:key_amb:20150410100858p:plain

4/9(木) に開催された CoreOS Meetup Tokyo #1 に行ってきました。

3時間の中でイントロ除いて発表が7つあり、かなり内容が濃かったです。

一番面白かったのは @kawamuray さんの Docker に CRIU を実装した発表でした。
CRIU はコンテナ界隈でも注目度が高い技術のようで、近い将来、この時デモで見たような機能が誰でも使えるようになるかと思うととても楽しみです。

また、Wantedly や pixiv で実際にプロダクション環境で運用している話も聞けたのは収穫でした。
コンテナ技術は運用ノウハウがまだ業界的に溜まっておらず、各社手探りでやっている印象を受けました。

一方で、@higebu さんの次のコメントが特に印象に残りました。

この辺りの技術の選定に関しては、OS を提供する側のクラウド事業者と OS を利用するサービス事業者で考え方が変わってきそうです。

以下、発表内容です。
資料は connpass にもまだ上がってないものもありますが、アップされたら更新するつもりです。

Introduction of CoreOS

@deeeet さん

※遅刻して後半部分しか聞いてません。

  • CoreOS の紹介
    • Motivation
      • かんたんに自動アップデートできる
      • セキュア
    • 機能
      • 最小限
      • コンテナベース
        • パッケージマネージャや言語ランタイムはない
      • クラスタリング => Data Center as a Computer
    • 技術
      • etcd, fleet, rkt, flannel
    • 使っている企業
      • DEIS, memsql, CloudFoundry
    • 最近の話題 ... TECTONIC

rkt

@mopemope さん
Abby CTO

  • rkt
    • App Container Runtime
    • App Container Spec の次の2つを実装
      • App Container Executor
      • Metadata Service
    • Pod サポート
  • App Container Manifest
    • コンテナの定義のようなものか
    • JSON
  • Docker との違い
    • Composable
    • Security
    • Image Distribution
    • Open ... 仕様が AppC の Spec として公開されている
  • アーキテクチャ
    • 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 さん

参考

OpenShift v3 on CoreOS

OpenShift v3 で Docker の PaaS を作る話

@jacopen さん

  • 自己紹介
  • Open Shift
  • DEMO
    • Web Console
      • できることは少ない
    • CLI からデプロイ
  • 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 クラスタ
  • デプロイ
  • ログ
  • 監視 => DataDog
  • etcd, fleet 使ってない
  • 自動アップデートオフ
    • 全台リブート困る
    • locksmith が必要
      • 何台同時にアップデートできるか制御できる
      • etcd が必要 <= 使ってない
    • 手動アップデートしてる
  • etcd, fleet 使わない上での CoreOS のメリット
    • ホストマシン構築タスクがほぼない
    • AMI 焼く必要すらない
    • セキュリティ対応が楽
      • blue-green で
    • 起動が速い
  • 遭遇した問題
    • CoreOS が EC2 でクラッシュ
    • CoreOS アップデート中に btrfs 起因で Disk Latency
  • CoreOS channel 選び
    • alpha は品質でない
      • アップデートが来る頻度
      • 致命的なアップデートも来る
    • stable で出た問題が alpha => beta の順で直る
    • stable が stable になるまで beta でいいんじゃないか
  • 解決したい問題

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

Docker + Checkpoint/Restore

Yuto Kawamura さん
3月まで東工大修士で Docker の研究をしていた。

  • CoreOS は関係ない
  • Checkpoint/Restore を使ってコンテナの起動を高速化
    • CRIU
    • プロセスのサブツリー, namespace, cgroup 等の状態のスナップショットを取ってシリアライズする技術
    • criu dump => 保存
    • criu restore => スナップショットから復元
    • VM のスナップショットみたいなことができる
  • 応用例 - Live migration
  • 今回 CRIU を使った目的
    • 起動が遅いサービスの起動の高速化
  • リソース効率の最大化
  • 問題点の1つ
    • アプリケーションによっては起動がとても遅い
  • 解決策
    • アプリケーションが起動した状態で Checkpoint 保存
    • どう判定するか?
      • TCP リスン開始したとき
  • Checkpoint/Restore 機能を Docker daemon に実装した
    • Docker の実行コマンドを CRIU 経由に差し替え
  • CRIU と Docker は相性がいい
  • DEMO
    • tomcat 起動
      • benchmark
        • SSD を使うと I/O の時間を削れた
    • 複数のコンテナを立ち上げるために
      • ipaddress とか process id とか変えないといけない
      • 大したオーバーヘッドではない
      • => docker restore --clone で量産
  • 今回やれなかったこと

Kubernetes on CoreOS

@IanMLewis さん

  • Compute as a Continuum
    • VM ... Flexible
    • Cluster
    • Platform ... Agile
  • Pods
  • Replication Controllers
    • Pod が落ちたときに再起動する
  • リソース管理
    • memory, cpu 使用効率を最適化
  • Service
    • Pod が動いているホストを意識しなくていい
  • アーキテクチャ
    • Master
      • apiserver
        • controller-manager
        • scheduler
        • register
    • Minion
      • kube-proxy ... NW をハンドリング
      • kubelet ... プロセス管理?
  • DEMO
    • GCE に CoreOS インスタンス起動
      • metadata にファイルを指定
    • kubectl.sh proxy 起動
    • container(pod)起動
    • instance (container ?) 増やす

CoreOSで運用する際に考えないといけないこと

@harukasan
pixiv

  • @harukasan
  • pixiv における CoreOS
    • Release 554 から使い始めた
    • IDCF クラウド
    • 1ノード1コンテナ
  • pixiv マンガ
  • 構成
    • IDCF
      • LB
      • App <= ★CoreOS
    • オンプレ
      • LB
      • RPC
  • デプロイ
    • 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 でいいんじゃ

参考