自作仮想化基盤 n0stack の紹介 ぱろっく 法政大学 h-otter 電気通信大学 hnron 日本工学院八王子専門学校 kyontan 電気通信大学

自作仮想化基盤

「n0stack」の紹介

ぱろっく

hnron

h-otter

kyontan

法政大学

日本工学院八王子専門学校

電気通信大学

電気通信大学

-

ContainerSIG (Special Interest Group)

-

But...

- No

- No

- No

Jail

Attention!

-

ContainerSIG (Special Interest Group)

-

But...

- We use

Attention!

自己紹介 (@hnron)

-

日本工学院八王子専門学校

-

ITスペシャリスト科 4年

-

ICTSC (第3-6回 参加) (第7-9回 運営)

-

自宅ラック勢

-

OpenStack

-

自宅にBGPフルルートが来てたり

自己紹介 (@h-otter)

-

電気通信大学 総合情報学科 ３年

セキュリティコース

-

ICTSC運営 (第6 ~ 9回)

-

アルバイト @

-

自宅ラック勢

-

openstack on k8s

自己紹介 (ぱろっく)

-

@porisuteru

-

法政大学 理工学部 ４年

知的情報処理研究室

-

ICTSC運営委員（第5 - 9回）

-

アルバイト @

-

インターン @

-

機械学習

✖️セキュリティを研究

-

@sukukyon

-

https://monora.me

-

電気通信大学 情報理工学部 3年

-

元 ICTSC 運営委員 (第5 - 8回)

-

アルバイト @ &

-

就活中 (?)

自己紹介 (@kyontan)

自宅サーバ群 (FreeBSD, CoreOS, ...)

ICTトラブルシューティングコンテスト

-

通称 ICTSC

(ICT Trouble Shooting Contest)

-

https://icttoracon.net

-

学生によるインフラ技術を中心に出題される

トラブルシューティング大会

開発の動機

-

これまでは

CloudStack

や

OpenStack

を用いていた

-

CloudStack

はネットワークの構造等の自由度が低く、

ICTSC に用いるのが難しかった

-

OpenStack

は比較的自由度が高かったが、ICTSC で使う際に

毎回特殊な構築の仕方を取る必要があった

-

どちらを用いた場合でも、学習コストや不具合が発生した時の

デバッグのコストがとても高かった

-

クラウドを理解するためにクラウドを作ってみる

全体の構成

-

各コンポーネントやエージェントを分割して開発

-

リソースをそれぞれ抽象化するエージェントを作る

-

IaaSとしてコンポーネントをまとめる

-

Compute, Network, Volume の依存は比較的大きい

-

ex. Nova と Neutron と Cinder

インターフェイス (OpenStack)

-

VMを作るには…

-

Neutron でネットワークを作って

-

Neutron でサブネット・ポートを作って

-

Nova で VM を立てて…

-

Cinder でディスクをつくって

-

いろいろアタッチして…

-

Heat…？ Murano…?

インターフェイス (Kubernetes)

-

サービスを提供するには…

-

PersistentVolumeつくって

-

Deploymentを作って

-

Service作って

-

いろいろ制約を追加して

…

-

いろいろタグでアタッチして…

インターフェイス (n0core)

-

VMを作るには…

-

procedure という

1つのリクエストを投げるだけ

-

リソースの依存関係を解決

-

効率的なスケジューリング

- resource: vm

name: hello_vm

power_state: started

attachments:

- resource: volume

size: 10G

- resource: port

network:

type: vlan

vlan_id: 10

subnets:

- cidr: 10.0.1.0/24

-

RESTful API

-

全ては HTTP でやる

-

デバッグのしやすさを重視

-

疎結合

-

agent 同士の依存を減らす

-

マイクロサービスに近い

-

agent は比較的密結合である

-

破綻

Architecture (0.1)

-

MQ を導入

-

到達性を重視

-

容易にリトライが可能

-

Scheduler / Conductor

-

agent 間の調整 / 管理

-

データフローを一方向に

Architecture (0.2)

Architecture (0.2)

-

API Gateway

-

HTTP / MQ の変換

-

n0auth, n0image

メッセージの流れ

-

Scheduler が

必要な agent へ命令

メッセージの流れ

-

エラーがあれば

Conductor → Scheduler で

再スケジューリング

Architecture (0.2)

-

依存関係があると

……

-

Scheduler

→ Agent

→ Conductor

→ Scheduler

→ Agent

→ ...

-

依存関係があると

……

-

Scheduler

→ Agent

→ Conductor

→ Scheduler

→ Agent

→ ...

必要ないのでは?

Architecture (0.2)

全体の構成 (Latest)

依存関係の通知を

Agent から直接 Agent へ

-

VM に必要なディスク

... ポート

-

ポート

... ネットワーク

全体の構成 (Latest)

依存関係の通知を

Agent から直接 Agent へ

-

VM に必要なディスク

... ポート

-

ポート

... ネットワーク

n0core

- Core Component

Messaging

-

全てのメッセージは N0stackMessage である

-

Protobuf はそれ自身の型情報を持たない

N0stackMessage

Request

Procedure

Notification

Simple

Notification

Create

VM

Requests..

Create

Network

Delete

VM

Pulsar

-

Yahoo! が日米で開発した MQ (メッセージングキュー)

-

レイテンシの低さがウリ

-

メッセージは ZooKeeper / BookKeeper で伝達/保持

-

(acknowledgement を返すまでメッセージを保持できる)

-

今は Apache Incubator の配下で開発続行中

-

n0stack の MQ として採用

-

MQ の扱いになれておらず色々苦労中

Messaging

-

Protobuf (Protocol buffer) 3 を全体で採用

-

agent 間でのスキーマの統一

-

文字列/数値等の最低限の型は保証できる

-

列挙型もある

-

Protobuf 3 では全てのフィールドが optional (なくてもよい)

-

API Gateway

-

クライアント (WebUI, CLI) からのリクエストのルーティング

-

Authentication, Authorization

-

Kong, Traefik などを使いたい (未検証)

-

未着手

n0gateway

api

Clients

MQ

api

-

HTTP - MQ の橋渡し

YAML, JSON, ...

Protobuf

scheduler

-

ホストのリソースを元に

VMのスケジューリング

-

filter / weight

-

APIから送られてくる

procedureの分割

-

各コンポーネントへ

リソースの作成リクエストを送る

networker

-

外部ネットワークから

VMへの疎通を確保

-

n0stack側から外部の

router/switch を操作

-

NAPALM

-

BGPで外部のrouterに

VMのIPを/32で広報

-

GoBGP

porter

-

VMのnetworkを抽象化

-

ブリッジの作成 &

DHCP による IPアドレスの割当

-

複数のタイプに対応

-

flat

-

vlan

-

...

volumer

-

VMイメージ等の管理

-

リソースプールの作成

-

作成

-

削除

-

ダウンロード

-

マイグレーション

compute

-

VMの管理

-

作成

-

起動

-

停止

-

複製

-

デバイス追加

-

スペック変更

-

マイグレーション

compute

-

ハイパーバイザにKVMを使用

-

libvirtを用いてKVMを管理

libvirt

-

RedHat が主体となって開発している OSS

-

KVM や Xen などのハイパーバイザを管理する抽象化ライブラリ

-

C / Python / Java などから API を利用可能

libvirt を使う理由

-

将来的に様々なハイパーバイザに対応させやすい

-

Linux Containers (LXC) もサポートしている

進捗

着手し始めた部分

-

Scheduler

-

Compute

-

Volumer

-

Porter

-

Networker

: Procedure 設計

: ほぼ完成

: Attach 以外ほぼ完成

: MQと結合以外は完成

: gobgp 検証中

-

0.1 Release (Soon)

-

色が濃い部分の基本動作

-

(0.2, ...)

-

1.0: 全体の完成

-

ICTSC9 (2018/3/3, 4)

-

導入判断は 2017/12

😂

-

間に合わせたい

Schedule

様々な形でのサポートを

お願いします!! 🙏

Docker on Heroku

ךכׄ׭倯

HerokuծDocker ؎ً٦آ׾؟ه٦ز׃׋׏ג״

[email protected]

​

Forward-Looking Statements

​

Statement under the Private Securities Litigation Reform Act of 1995:

​

This presentation may contain forward-looking statements that involve risks, uncertainties, and assumptions. If any such uncertainties materialize or if any of the assumptions proves incorrect, the results of salesforce.com, inc. could differ materially from the results expressed or implied by the forward-looking statements we make. All statements other than statements of historical fact could be deemed forward-looking, including any projections of product or service availability, subscriber growth, earnings, revenues, or other financial items and any statements regarding strategies or plans of management for future operations, statements of belief, any statements concerning new, planned, or upgraded services or technology developments and customer contracts or use of our services.

​

The risks and uncertainties referred to above include – but are not limited to – risks associated with developing and delivering new functionality for our service, new products and services, our new business model, our past operating losses, possible fluctuations in our operating results and rate of growth, interruptions or delays in our Web hosting, breach of our security measures, the outcome of any litigation, risks associated with completed and any possible mergers and acquisitions, the immature market in which we operate, our relatively limited operating history, our ability to expand, retain, and motivate our employees and manage our growth, new releases of our service and successful customer deployment, our limited history reselling non-salesforce.com products, and utilization and selling to larger enterprise customers. Further information on potential factors that could affect the financial results of salesforce.com, inc. is included in our annual report on Form 10-K for the most recent fiscal year and in our quarterly report on Form 10-Q for the most recent fiscal quarter. These documents and others containing important disclosures are available on the SEC Filings section of the Investor Information section of our Web site.

​

Any unreleased services or features referenced in this or other presentations, press releases or public statements are not currently available and may not be delivered on time or at all. Customers who purchase our services should make the purchase decisions based upon features that are currently available. Salesforce.com, inc. assumes no obligation and does not intend to update these forward-looking statements.

自 己 紹 介

꣚ 鿇 䃨 (Takashi Abe)

Platform Specialist

(@

sho7650

)

،فٔؒٝآص،

à

HWؒٝآص،

à

؎ٝؿٓؒٝآص،

à

،٦ؗذؙزⰯIT؝ٝ؟ٕ

à

植耵

Platform as a Service

Ꟛ涪罏ח״׷ծꟚ涪罏ך׋׭ךفٓحزؿؓ٦ي

ىسٕؐؑ، DBMS OS ⟎䟝⻉ ؟٦غ٦ أزٖ٦آ طحزٙ٦ؙ 倵鏣 ،فٔ؛٦ءّٝ

ؔٝفٖىأ

،فٔ؛٦ءّٝ ىسٕؐؑ، DBMS OS ⟎䟝⻉ ؟٦غ٦ أزٖ٦آ طحزٙ٦ؙ 倵鏣

IaaS

(Infrastructure as a Service) ،فٔ؛٦ءّٝ ىسٕؐؑ، DBMS OS ⟎䟝⻉ ؟٦غ٦ أزٖ٦آ طحزٙ٦ؙ 倵鏣

SaaS

(Software as a Service) ،فٔꟚ涪/؟٦ؽأ䲿⣘罏盖椚 ؙٓؐسكٝت٦盖椚 ،فٔ؛٦ءّٝ ىسٕؐؑ، DBMS OS ⟎䟝⻉ ؟٦غ٦ أزٖ٦آ طحزٙ٦ؙ 倵鏣

PaaS

(Platform as a Service)

΍ 24儗꟦/365傈ך

ؚٗ٦غٕז麊欽⡤ⵖ

Ύ 㣐鋉垷؎ٝؿٓ麊欽ך

鞢㺡זشٖحآ襳琎

Ώ 鋉垷ך⾱椚׾崞ַ׃׋

㼎䘔٥㼎瘻פך䫎项

ΐ 珩⫴㹋籐ךⰕꟚ

➭ؙٓؐسكٝت٦ך IaaS׾ⵃ欽

،فٔךٍؗػءذ؍׾㺁僒ח䭁䓸דֹ׷

圓䧭銲稆

铡僇

䭁䓸倯岀

Dyno

⡲䧭׃׋فؚٗٓي׾

⹛ַׅ؝ٝذش

䎂遤珩⫴ׅ׷Dynoך侧

׾㟓װׅ

Data

ر٦ة׾盖椚٥⥂盖ׅ

׷걄㚖

״׶㣐㺁ꆀ٥넝䚍腉ז

فٓٝחر٦ة׾獳׃

ⴖ׶剏ִ׷

Add-ons

⤑ⵃז鷄⸇堣腉纇

ؙٔحؙװ؝وٝسד

堣腉׾鷄⸇׃橆㞮㢌侧

׾鏣㹀ׅ׷

Payments Email SMS Search Analytics Monitoring Logging Ruby Node.js Java Python PHP Scala Clojure Postgres Redis Kafka

ת׆椚鍑ׅ׷ Heroku ך圓䧭銲稆ה䭁䓸ך➬倯

׉׿ז知⽃ח䭁䓸דֹ׷׮ךזך

ֿ׸׵ך؝ٝإفزח⽯׃

鏣鎘Ꟛ涪ׁ׸׋،فٔז׵

The Twelve Factor App

و؎ؙٗ؟٦ؽأ

竰竲涸זꟚ涪→رفٗ؎ך㹋遤ח䕵甧אCI/CD堣腉׾䲿⣘

갪湡

铡僇

غ٦آّٝ盖椚

•

Git / Githubהך䓼⸂ז鸬䵿٥窟さ

ㅷ颵׾넝׭׷Ꟛ涪

فٗإأ彊䬿

•

Pipeline堣腉ח״׶ٖؽُ٦ >

أذ٦آؚٝ > 劤殢 ׉׸׊׸ך

橆㞮׾أي٦ؤח獳遤

•

荈⹛ذأز׮㹋倵〳腉

橆㞮醱醡

•

Fork؝وٝسדծ珩⫴橆㞮ךؙٗ٦

ٝ׾㺁僒ח⡲䧭

ؒٝة٦فٓ؎ؤ欽鷿ח׮㼎䘔דֹ׷堣腉/؟٦ؽأ׾䲿⣘

項⽬

説明

Private Spaces

•

Dyno

_{やDataなど、Herokuのアプリ実⾏環境をネット}

ワーク的に分離された環境に構築

•

⽇本国内のデータセンター利⽤も可能

エンタープライズ

サポート

•

技術的な質問やトラブル時のサポートチケットに対して、

重要度に応じた応答時間のSLAを提供

•

⽇本語でのサポート対応を提供

•

導⼊時のアーキテクチャデザインやAdd-on選定といった

ご相談に⽇本⼈技術者が対応

Heroku Connect • Salesforce

のオブジェクトとの双⽅向データ同期機能を

提供

Private Spaces Heroku Connect Postgres Heroku ؔـآؙؑز Salesforce

Container Registry & Runtime

​

Docker ׾ Heroku פرفٗ؎ׅ׷׋׭ך勴⟝

1. Heroku ،ؕؐٝز׾䭯׏גְ׷ֿה

2. Heroku CLI ؝وٝسָⵃ欽〳腉זֿה

3. docker ؝وٝسָⵃ欽〳腉זֿה

buildpack

_{ではなく、docker イメージでランタイムや}

ミドルウェアを開発者が準備できるので、これまで

docker

_{を利⽤していた開発者でも容易にデプロイが!}

Heroku פ Docker ،فٔ׾رفٗ؎ׅ׷♧菙涸ז崧׸

​

Heroku פ،فٔ׾رفٗ؎ׅ׷倯岀הקה׿וずׄ!!

起動確認

デプロイ

アドオン追加

Heroku

_{アプリ追加}

Docker

_{アプリ準備}

アプリ開発 git clone アプリ準備 heroku create データベース ログ出⼒ 監視ツール ファイル保管 などなど

:

container:push heroku logs

رفٗ؎ׅ׷׋׭ךⰧ⡤涸ז؝وٝس

​

ⱄرفٗ؎ׅ׷㜥さכ “heroku container:push” ׅ׷׌ֽ

※https://blog.heroku.com/introducing_heroku_docker_release_build_deploy_heroku_apps_with_docker

heroku login

heroku container:login

起動確認

デプロイ

アドオン追加

Heroku

_{アプリ追加}

事前準備

heroku create

heroku addons:create

heroku container:push

heroku open

heroku

アプリの作成と

アドオン追加は、⼀度の

実⾏でOK

Heroku

のアドオンも

Docker

_{から利⽤可能}

Dockerfile חֶֽ׷ծ׮׹׮׹ךⵖ秈✲갪

•

$PORT 橆㞮㢌侧ד Listen ׅ׷ֿה

•

Network link כ劢؟ه٦ز

•

Default ך working directory כ ‘/’ ծ㢌刿ׅ׷㜥さכ ‘WORKDIR’ ׾鏣㹀

•

‘CMD’ ךإحزָ䗳갭կENTRYPOINT כؔفءّٝկ

•

‘VOLUME’ ‘EXPOSE’ ‘STOPSIGNAL’ ‘SHELL’ ‘HEALTHCHECK’ כ劢؟ه٦ز

׉ך➭ծHeroku ה׃גך岣䠐✲갪

•

Dyno

כծ24儗꟦+α ד荈⹛涸ח⹧䩛חⱄ饯⹛ׁ׸תׅ

•

إُؗٔذ؍ػحثָծ剑㣐 24儗꟦ד黝欽ׁ׸׷ֿה׾爙׃גְתׅ

•

ؿ؋؎ٕ׾宕竲涸ח⥂盖ׅ׷ֿהװծإحءّٝ䞔㜠׾笝䭯דֹזֻז׶תַׅ׵ծر٦ة٥ؿ؋؎ٕ٥إحءّٝ

䞔㜠זו׾笝䭯׃׋ְ㜥さכծر٦ةك٦أװ㢩鿇ؔـآؙؑزأزٖ٦آזודծ宕竲⻉׃ת׃׳ֲ

•

ؚٗ׮⥂盖ׁ׸תׇ׿կ䗳銲ד֮׸לծ،سؔٝזודؚٗ׾鷌鼘٥麊欽׃ת׃׳ֲ

•

Web ،ؙإأכ 30猱ד䓼ⵖ涸חⴖ倖ׁ׸תׅ

•

⢽ִלغحثⳢ椚זוծⳢ椚ח儗꟦ךַַ׷׮ךכծꬊず劍Ⳣ椚ה׃גWorker Dyno דⳢ椚ׇׁ״ֲ

•

،فٔ؛٦ءّٝꟚ涪חֶֽ׷⾱椚⾱⵱כծTwelve Factor App(

https://12factor.net/ja/)

ח䖞׏גְ׷

ךדծ莆㄂ָ֮׷Ꟛ涪罏ך倯כծוֲ׊׉׍׵׮׀鋮ֻ׌ְׁ

​

Heroku דכծ㸜Ⰻ䚍װ♶庠ך✲䡾ח⪒ִג棆׃ְⵖꣲָ֮׶תׅ

詳しくはこちらへどうぞ!!

DEMO

​

Japan Heroku User Group

פ⿫⸇׃״ֲ

​

次のステップへ...Trailhead

Heroku Enterpriseの基礎

Heroku Enterpriseをいつ

どのように使⽤するかに

ついての基礎を学習します

SalesforceとHerokuの

インテグレーション

Herokuのアプリケーションを

Salesforceに統合するための

パターンと⽅法を学びます

https://trailhead.salesforce.com/ja

Appendix

​

Heroku 䞔㜠׾Ⰵ䩛ׅ׷

•

Heroku

׾ⵃ欽ׅ׷ח֮׋׏גך✲⵸彊⪒։؟؎ٝ،حفֶ״ןHeroku CLIך؎ٝأز٦ٕ

•

Ꟛ涪罏ぢֽ Heroku 䞔㜠ך♧如ا٦أ –

Heroku Dev Center

•

չHerokuדכׄ׭׷ث٦يꟚ涪ה麊欽պ鸬鯹♧鋮

•

ׁ֭ Heroku ׾כׄ׭״ֲ ։أة٦زؖ؎س

(Heroku Getting Started

傈劤铂晛)

•

Node.js Ꟛ涪罏ך׋׭ך Heroku ⰅꟌ

•

Ruby Ꟛ涪罏ך׋׭ך HerokuⰅꟌ

•

װ׸׷ Heroku - Java ،فٔ؛٦ءّٝꟚ涪箟

•

PHP Ꟛ涪罏ך׋׭ך HerokuⰅꟌ

•

Python Ꟛ涪罏ך׋׭ך HerokuⰅꟌ

•

Heroku

ד㹋騧ׅ׷ CI/CD