狠狠撸

.....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
....
.
....
.
.....
.
....
.
.....
.
....
.
....
.
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

狠狠撸

颁辞谤别翱厂入门

More Related Content

颁辞谤别翱厂入门