CoreOS入門

.....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
.....
.
....
.
....
.
CoreOS 入門
May 31, 2014

.....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
.....
.
....
.
....
.
自己紹介
• Yutaka Matsubara
• Abby CTO
• twiter: @mopemope
• github: @mopemope
Abby 社員募集中です

.....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
.....
.
....
.
....
.
宣伝
Docker の薄い本を書きました

.....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
.....
.
....
.
....
.

.....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
.....
.
....
.
....
.
CoreOS とは
• Alex Polvi が立ち上げた CoreOS Inc が開発
• 分散システムを前提に設計されたLinux Distribution
▶ Google などを参考に
▶ アドバイザーには Greg KH

.....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
.....
.
....
.
....
.
オフィスの様子
http://www.wired.com/2013/08/coreos-the-new-linux/

.....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
.....
.
....
.
....
.
CoreOS の特徴

.....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
.....
.
....
.
....
.
CoreOS の設計
クラスタ + コンテナ

.....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
.....
.
....
.
....
.
CoreOS の特徴
• 小さくかつ堅牢なOSコア
• 安全なアップデート (update_engine, omaha)
• Docker Ready (docker)
• クラスタを標準でサポート (etcd)
• 分散システムをサポート (fleet)

.....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
.....
.
....
.
....
.
コア
• セキュリティ、一貫性、信頼性を重視した設計
• 新しい Kernel を積極的に採用
• モダンな Linux らしく systemd を採用
• コンテナが動作する事を踏まえて最小のオーバーヘッド
• 多くのプラットフォームで動作する
▶ 各クラウドサービス, 物理マシン(BareMetal)

.....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
.....
.
....
.
....
.
バージョンについて
バージョンはCoreOS初版からの日数
• CoreOS: 324.2.0
• Kernel: 3.14.4
• btrfs, ext4
• Docker: 0.11.1
• etcd: 0.3.0
• fleet: 0.3.2

.....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
.....
.
....
.
....
.
セキュリティ、一貫性、信頼性
• デフォルトでブートするとログインすら不可能
▶ ssh のみログイン可能
• パッケージマネージャーが存在しない
• root partition が書き込み不可能
▶ /etc など一部は可能
▶ ユーザーデータは外部ストレージ

.....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
.....
.
....
.
....
.
安全なアップデート
• update_engine を提供
▶ alpha, beta の 2 channel
• アップデートはroot parttionを載せ替える
▶ 個別のパッケージを管理からの開放
▶ ２つのroot partition
• update元イメージは署名入りで検証を行う

.....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
.....
.
....
.
....
.
アップデート
update_engine[22503]: start size part contents
update_engine[22503]: 2492416 2097152 4 Label: ”USR-B”
update_engine[22503]: Type: Alias for coreos-rootfs
update_engine[22503]: UUID: E03DD35C-7C2D-4A47-B3FE-27F15780A57C
update_engine[22503]: Attr: priority=2 tries=1 successful=0
update_engine[22503]: COREOS_RELEASE_VERSION=282.0.0
update_engine[22503]: Setup USR-B (/dev/vda4) for next boot.

.....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
.....
.
....
.
....
.
Docker
• アプリケーションは基本docker上で起動
▶ ホストOSとの分離による管理コスト低減
• ポータビリティの確保
▶ どのホストでも問題なく動作
• オーケストレーション（コンテナ間連携）にetcdを使う

.....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
.....
.
....
.
....
.
クラスタ
• etcd によって実現
▶ 耐障害性
▶ その他のツールの基盤
• コンセンサスアルゴリズムにRaftを採用
• ユーザーデータを保持可能
▶ 設定などを同期

.....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
.....
.
....
.
....
.
分散システム
• fleet = etcd + systemd + job scheduling
• 複数ホストへサービスを配備
▶ 管理コスト低減
• 耐障害性
▶ 障害を検知し、別ホストへサービスをふりかえる
• ログはsystemd-journaldと連携

.....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
.....
.
....
.
....
.
構成要素

.....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
.....
.
....
.
....
.
構成要素
主要構成要素は以下
• coreos-cloudinit
• etcd
• fleet
• locksmith
ライブラリ依存を最小限に抑えるためgoで書かれている

.....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
.....
.
....
.
....
.
CoreOS-CloudInit

.....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
.....
.
....
.
....
.
CoreOS-CloudInit
書き込み不可能なCoreOSを初期化、カスタマイズする仕組み
• クラウド環境での一括初期化
▶ cloud-config.yml のサポート
• ユーザーによるカスタマイズ
▶ サービスの追加など
• 外部デバイスからの読み込み
▶ config-driveのサポート
▶ OpenStack, LibVirt

.....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
.....
.
....
.
....
.
主な設定可能項目
• etcd の設定
• service の自動起動、停止、無効化
▶ 新しくserviceも追加可能
• ssh キーの設定
• ユーザーの追加、設定
• 任意のファイルの作成
▶ Network設定
▶ システム設定
▶ 環境変数設定

.....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
.....
.
....
.
....
.
例
#cloud-config
coreos:
etcd:
discovery: https://discovery.etcd.io/cc3fad77be13cbde64409073e1175eff
addr: $private_ipv4:4001
peer-addr: $private_ipv4:7001
bind-addr: 0.0.0.0
peer-heartbeat-interval: 100
peer-election-timeout: 1000
units:
- command: start
name: etcd.service
- command: start
name: fleet.service
- command: start
name: docker.service

.....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
.....
.
....
.
....
.
例
users:
- name: core
coreos-ssh-import-github: mopemope
write_files:
- path: /etc/fleet/fleet.conf
content: |
agent_ttl=”120s”

.....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
.....
.
....
.
....
.
Etcd

.....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
.....
.
....
.
....
.
Etcd
クラスタの基盤となる耐障害性のある分散KVS
• HTTP API(JSON) での操作
▶ CASのサポート
▶ Waitによる変更監視サポート
• 高速に動作
• SSL による認証
• Raft Protocol
• Cluster Discovery のサポート

.....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
.....
.
....
.
....
.
HTTP API
Setting the value of a key
$ etcdctl --debug set /message ”Hello World”
Cluster-Peers: http://xxxxxxxxx:4001
Curl-Example: curl -X PUT http://xxxxxxx:4001/v2/keys/message -d value=Hello W
Hello World
{
”action”: ”set”,
”node”: {
”createdIndex”: 2,
”key”: ”/message”,
”modifiedIndex”: 2,
”value”: ”Hello world”
}
}

.....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
.....
.
....
.
....
.
HTTP API
Get the value of a key
Support recursive and sorted
$ etcdctl --debug get --sort --recursive /queue
Cluster-Peers: http://xxxxxxxx:4001
Curl-Example: curl -X GET http://xxxxxxxxxx:4001/v2/keys/queue?recursive=true
Hello World

.....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
.....
.
....
.
....
.
HTTP API
{
”action”: ”get”,
”node”: {
”dir”: true,
”key”: ”/queue”,
”nodes”: [
{
”key”: ”/queue/2”,
”value”: ”Job1”
},
{
”key”: ”/queue/3”,

.....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
.....
.
....
.
....
.
Raft
ノード間のコンセンサスをとるアルゴリズム
スタンフォード大学の Diego Ongaro、 John Ousterhoutが作成

.....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
.....
.
....
.
....
.
Raft
民主的(Vote)で合理的なアルゴリズム
• リーダーの選出
• ログのレプリケーション
• 設定の同期
• 実用的、合理的
http://thesecretlivesofdata.com/raft/

.....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
.....
.
....
.
....
.
Leader Election
Raft では各ノードはいずれかの役割を行う
• Leader
▶ 最新の値を持つ
• Follower
▶ Leaderに従う
• Candidate
▶ リーダーが欠如した際の時期リーダー候補者

.....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
.....
.
....
.
....
.
Election Flow
投票によってリーダーを決める
1. 各自 Followeからのスタート、Leaderからのheartbeatを待つ
2. 届かない場合、Leader不在とみなし、Candidateへ
3. 選挙開始に伴いTermを+1する
4. CandidateになったノードはFollowerに投票リクエストを投げる
5. Follwerは投票リクエストを受け取り、未投票であれば投票を行う
6. Candidateはノードの過半数の投票を得られればLeaderに昇格
7. 他のノードが既に過半数を得ていればFollowerへ
8. 過半数に満たないなど場合は再選挙 3.へ戻る

.....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
.....
.
....
.
....
.
Term
Term (期間・任期)を導入
• Leader が安定していればそのまま
▶ 大何代総長みたいなもの
• Leader が不安定
▶ 選挙になると代が+1
• 先代のLeaderの復帰
▶ 代が変わっているのでFolloweに降格

.....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
.....
.
....
.
....
.
Log Replication
2 Phase Commit
LogにはIndexが振られておりそれを見て古いか判断
1. Leaderへ値を通知
2. 各Followerへ値を送る
3. Followerは成功した旨をLeaderへ伝える
4. Leaderは各Followerへコミットメッセージを送る

.....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
.....
.
....
.
....
.
Etcd の現状
• Raft は大きなクラスタ組むのに適していない
▶ 適切なサイズは 5 - 9
▶ Stanby Mode
• Leaderのheartbeatがことごとくtimeout
▶ デフォルトで50ms毎にheartbeat
▶ peer-election-timeoutの調整
▶ heartbeat-intervalの調整
• Discoveryで失敗した場合の復旧
▶ 任意のノードをマニュアルで削除(etcd 0.4)

.....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
.....
.
....
.
....
.
Stanby Mode
Etcd 0.4からサポート
• クラスタサイズの設定
▶ 最大activeノード数を設定 (9)
▶ 溢れたノードはStanby Modeへ
• Stanby ノード
▶ アクセスは全てLeaderノードへリダイレクト
▶ Stanbyでも一定時間ごとにLeaderと設定を同期(5秒）
• Followerへの昇格
▶ activeノードに空きができるとFollowerへ
▶ 昇格時は再度同期

.....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
.....
.
....
.
....
.
Fleet

.....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
.....
.
....
.
....
.
Fleet
SystemdとEtcdを利用した分散システムツール
低レベルのオーケストレーションツールの位置づけ
• コンテナをクラスタにデプロイ
• コンテナを指定マシンにデプロイ
▶ 特定のコンテナを同じマシンにデプロイ
▶ metadaにマッチングしたマシンにデプロイ
• 同マシンにデプロイされないよう禁止
• コンテナの障害を検出し、他のマシンへ自動で再デプロイ
• コンテナ以外でもOK
• ssh トンネリングからの操作

.....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
.....
.
....
.
....
.
Fleet
Engine と Agentに別れる
• Engine
▶ Job Scheduling
▶ AgentへJobをお願い
• Agent
▶ Jobの実行判断
▶ 実際のJobを実行
▶ D-Busからイベントを監視
▶ StateをEngineに送信

.....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
.....
.
....
.
....
.
Job Schedule Flow

.....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
.....
.
....
.
....
.
Fleet with Systemd
FleetはSystemdのUnitを対象マシンへ配布
• Service TypeのUnitとして使用
• mount, path, timerのUnitもサポート
• 障害を検出するとUnitファイルごと削除
▶ motdにて通知

.....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
.....
.
....
.
....
.
Fleet 拡張
[X-Fleet] セクションによる独自拡張
• X-ConditionMachineID
▶ 指定したMachineIDにデプロイ
• X-ConditionMachineMetadata
▶ 指定したmetadataにマッチしたマシンにデプロイ
• X-ConditionMachineOf
▶ 指定したサービスがデプロイされているマシンにデプロイ
• X-Conflicts
▶ 同じサービスが同マシンにデプロイされるのを禁ずる

.....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
.....
.
....
.
....
.
Unit File 例
[Unit]
Description=Graphite Server
After=docker.service
Requires=docker.service
[Service]
TimeoutStartSec=20m
ExecStartPre=/usr/bin/docker pull mopemope/graphite-docker
ExecStartPre=-/usr/bin/docker rm ”graphite-server”
ExecStart=/usr/bin/docker run --rm --name ”graphite-server”
-a stdout -a stderr -p 80:81 -p 81:80 -p 2003:2003 ”mopemope/graphite-docker”
ExecReload=-/usr/bin/docker stop ”graphite-server”
ExecReload=-/usr/bin/docker rm ”graphite-server”
ExecStop=-/usr/bin/docker stop ”graphite-server”
[X-Fleet]
X-ConditionMachineID=359e258ac888444b8722b723c730a91a
X-Conflicts=graphite.*.service

.....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
.....
.
....
.
....
.
Fleet の現状
• Fleet Agent Heartbeat Timeout
▶ etcdの問題
▶ agent_ttlの調整
• Job Schduling
▶ 優先度がない（早いモノ順）
• Job 登録のセキュリテイ
▶ 誰でもデプロイできる
▶ 証明書はこれから

.....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
.....
.
....
.
....
.
Locksmith

.....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
.....
.
....
.
....
.
locksmith
クラスタ上のマシンのRebootを管理する
• 自動更新で一度に全てのマシン落ちないようにする
• update_engineのイベントを監視
• semaphore方式でロックをかける
• よくpanicを起こしている

.....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
.....
.
....
.
....
.
DEMO

.....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
.....
.
....
.
....
.
今後の課題

.....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
.....
.
....
.
....
.
CoreOSの今後の課題
• 安定性
▶ 各構成要素の安定
• クラスタサイズ
▶ Stanby Modeでどれくらいまで耐えれるか?
• fleet などのセキュリティ
▶ unit に証明書がない（実装予定）
• 高レベルのオーケストレーション
▶ コンテナ間をより簡単に連携
▶ 総合的なツール

.....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
.....
.
....
.
....
.
運用にあたっての課題
クラスタ前提での設計
• クラスタ設計
▶ スペック、数、ストレージ容量
▶ クラスタ内におくもの
▶ クラスタ外におくもの
• オーケストレーション
▶ 高レベルのオーケストレーションツール
• システム監視
▶ メトリクス収集
▶ ログ収集
▶ アラート

.....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
.....
.
....
.
....
.
運用するにあたっての課題
Docker前提の設計
• 外部ホスト連携
▶ confd
• 永続化データの保存先
▶ 外部ストレージ
• ディスク使用帯域の制御
▶ blkio
▶ btrfs quota ぐらい？

.....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
.....
.
....
.
....
.
Q&A

CoreOS入門

More Related Content

Featured (20)

CoreOS入門