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”: { ”createdIndex”: 2, ”dir”: true, ”key”: ”/queue”, ”modifiedIndex”: 2, ”nodes”: [ { ”createdIndex”: 2, ”key”: ”/queue/2”, ”modifiedIndex”: 2, ”value”: ”Job1” }, { ”createdIndex”: 3, ”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入門

by Yutaka Matsubara, Working at 株式会社Abby

on May 31, 2014

Statistics

Views

Actions

2 Embeds 38

Accessibility

Categories

Upload Details

Usage Rights

Report content

CoreOS入門 Presentation Transcript

https://twitter.com	52
http://dev.classmethod.jp	20