自作仮想化基盤...全体の構成 -...

自作仮想化基盤

「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

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

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

- 次回は第9回＠さくらインターネット株式会社大阪本社

開発の動機- これまでは CloudStackや OpenStackを用いていた

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

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

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

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

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

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

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

We introduce …

全体の構成

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

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

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

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

- ex. Nova と Neutron と Cinder

→ OpenStackやKubernetesの構造を参考にしながら粒度を調整

インターフェイス (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

- HTTP 依存部は外部へ

メッセージの流れ

- Scheduler が

必要な agent へ命令

Architecture (0.2)

メッセージの流れ

- エラーがあれば

Conductor → Scheduler で

再スケジューリング

Architecture (0.2)

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

全体の構成 (Latest)

Messaging

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

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

N0stackMessage

Request Procedure Notification

Simple

Notification

Create

VMRequests..

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

様々な形でのサポートを

お願いします!! 🙏

Thanks / Check it out!

Docker on Heroku Heroku Docker

tabe@salesforce.comTakashi Abe @ Platform Specialist

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.comproducts, 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 à

: Perfume/BABYMETAL/ /

Heroku

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

RubyNode.jsJavaPythonPHPScalaClojure

PostgresRedisKafka

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

PostgresHeroku Salesforce

Container Registry & RuntimeHeroku Docker Registry Heroku Docker !!

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

170以上!?

“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 から利⽤可能

‘heroku-docker’ “heroku docker”

Dockerfile

• $PORT Listen • Network link • Default working directory ‘/’ ‘WORKDIR’ • ‘CMD’ ENTRYPOINT • ‘VOLUME’ ‘EXPOSE’ ‘STOPSIGNAL’ ‘SHELL’ ‘HEALTHCHECK’

$PORT Web

Heroku

• Dyno 24 +α• 24•

•

• Web 30• Worker Dyno

• Twelve Factor App(https://12factor.net/ja/)

Heroku

詳しくはこちらへどうぞ!!https://devcenter.heroku.com/articles/limits

DEMO

Japan Heroku User Group https://herokujp.doorkeeper.jp/

次のステップへ...Trailhead

Heroku Enterpriseの基礎

Heroku Enterpriseをいつどのように使⽤するかに

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

SalesforceとHerokuのインテグレーション

HerokuのアプリケーションをSalesforceに統合するためのパターンと⽅法を学びます

https://trailhead.salesforce.com/ja

AppendixHeroku References

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