Ubuntu Juju/MAAS・OpenStackを使った検証環境構築 - OpenStack最新情報セミナー 2016年3月

COPYRIGHT © 2016 MITSUBISHI ELECTRIC INFORMATION SYSTEMS CORPORATION ALL RIGHTS RESERVED 1COPYRIGHT © 2014 MITSUBISHI ELECTRIC INFORMATION SYSTEMS CORPORATION ALL RIGHTS RESERVEDCOPYRIGHT © 2015 MITSUBISHI ELECTRIC INFORMATION SYSTEMS CORPORATION ALL RIGHTS RESERVED
OpenStack 最新情報セミナー
2016-03-02
三菱電機インフォメーションシステムズ
吉川晃平
ご注意
• 本書の内容の一部又は全部を当社に断りなく、いかなる形でも転載又は複製することは、固くお断りします。
• 本文記載の社名、製品名、ロゴは各社の商標または登録商標です。
• OpenStack® のワードマークと OpenStack のロゴは、米国とその他の国における OpenStack Foundation の登録商標/サービス
マークまたは商標/サービスマークのいずれかであり、OpenStack Foundation の許諾の下に使用されています。

COPYRIGHT © 2016 MITSUBISHI ELECTRIC INFORMATION SYSTEMS CORPORATION ALL RIGHTS RESERVED 2
自己紹介
吉川晃平
(よしかわこうへい)発表者
• twitter @yosikawako
• 住処：神奈川県藤沢市
• 趣味：スキー
• 好きな食べ物：
ラーメンパスタから肉チーズに改宗
インフラ系
システムエンジニア経歴
• 海底ケーブルの監視GUI
• ISPのホームページ公開システム
• オンプレミスのWebポータル共通基盤
• OpenStack: 勉強中

MDIS 会社概要
三菱電機(株)
の情報システム
事業が分社化
し発足

拠点
鎌倉市(大船
駅)を技術拠点
に本社・支社を
全国配置

主な事業
高い技術力と豊かな発想で、社会に密着した多彩なソリューションを提供

MDISのOSS活用ソリューション
通信キャリア・サービスプロバイダー様向け、OSSを活用したシステムの導入支援。
http://www.mdis.co.jp/solution/oss/

COPYRIGHT © 2016 MITSUBISHI ELECTRIC INFORMATION SYSTEMS CORPORATION ALL RIGHTS RESERVED 77COPYRIGHT © 2015 MITSUBISHI ELECTRIC INFORMATION SYSTEMS CORPORATION ALL RIGHTS RESERVED
7
発表の概要

本日の内容
Canonical社が開発するサービスオーケストレーター「Juju」、
物理マシン構築ツール「MAAS」の紹介
事例１：社内にOpenStack®の講習やPoCを行うための環境を
つくる
事例２：Juju/MAASを使ったOpenStack環境の構築と運用
例
事例３：Juju環境をOpenStack上に構築し、
WebサービスをJuju on OpenStackで構築・管理

話題とする共用検証環境の概要
Over
Cloud
Under
Cloud
すべてのリソース
OpenStack
OpenStack B1
検証C
(OpenStackを
使わない検証)
環境A(メイン) 環境B(構築検証) 環境C
OpenStack B2
OpenStack B3
OpenStack B4
MAAS
Juju(under)
テナントA1 テナントA2 Juju用テナント
検証A1 検証A2 Juju(tenant)
低レベルでの環境分離とアクセス経路提供
Jujuを使った検
証
②Juju/MAAS
を使った
OpenStack
構築
③OpenStack上の
Juju利用
①OpenStack
構築講習
のための環境
構築

謝辞
本発表中の環境構築・検証には
日本仮想化技術株式会社様からの
多大なる技術支援・サポートをいただきました。
また、Ubuntu製品群に関する発表をすることを
Canonical様より快くご承諾いただきました。
感謝の意を表します。
発表内容はすべて弊社(MDIS)が独自に実施した構築・検証
に基づくMDISの見解です。

11

Canonicalのクラウドソリューション
汎用的な複数のソフトウェアの連携で
柔軟なクラウド・データセンター管理運用を実現
有償サポート(Ubuntu Advantage)に含まれる
Juju
• サービスのモ
デリングとデ
プロイ
• OSS
MAAS
• 物理マシン
のプロビジョ
ニング
• OSS
OpenStack
• クラウド基盤
• OSS
LandScape
• 運用管理
• 運用サービ
ス

Jujuとは？
迅速に
「モデリング(*)」「設定」「デプロイ」「管理」を
クラウド環境へ実現する
サービスオーケストレーションツール
画像出典：http://www.ubuntu.com/cloud/juju
(*) Model:公式ページではModelを「サービスの構成設計」のような用語として使っている。

Jujuでできること
検証済み手順の再
利用(Charm
Store)
サービスの迅速なデ
プロイ
スケールアウト/ダウ
ン
サービスの多量展開
クラウド
AWS AZURE OpenStack
オンプレミス
物理サーバー KVM 仮想マシン
VMWareESXi 仮想マ
シン
CharmStore Charm Service
Unit
Unit
Service
Unit
UnitCharm
Node
Node
Node
get deploy

MAASとは
データセンター
運用効率化
目的
物理サーバー
の自動化
役割
「データセンター運用効率化のための
物理サーバーの自動化ツール」

MAASでできること
マシン探索と
インベントリ化
電源On/Off
HDDイメージ
をデプロイ
タグ付けによる
グルーピング
物理サーバー KVM 仮想マシン VMWareESXi 仮想マシン
Manager
(ex.Juju)
discover
nodes
Physical Server
KVM VM
ESXi VM
deploy
power
Node
Node
Node
list
deploy
power
MAAS
Node
Inventory
HDD
image

Juju/MAASが威力を発揮する用途
https://jujucharms.com/openstack
OpenStack
https://jujucharms.com/big-data
BigData
テナントを効率的にデプロイ
CMSやWebサービスのバックエンド
OpenStackだけでなく
データセンター・クラウドサービス運用の効率化を目指している
多量のノード生成が必要なシステム。
よく似たサービスを何度もデプロイするような環境

18
Jujuのしくみ

サービス、ユニット、ノード
Jujuの構成単位の概念。抽象化されているので理解が必要。
サービス(Servie)
• Charmで定義される機能単位。
• JujuGUI上のアイコン=サービス
• サービスにユニットが登録されて初めて実際
のデプロイがはじまる。
• オブジェクト指向言語の「クラス」に近い
ユニット(Unit)
• サービスの実体。1つ以上の複数のユニット
で１つのサービスを構成する。
• 実装はノードそのものまたはノード内のLXC
コンテナ。ユニットをノードにデプロイすると
LXCコンテナが生成され、中でCharmに
記載されたサービス生成がはじまる。
• オブジェクト指向言語の「インスタンス」に近
い。
ノード(Node)/Machine
• サービスのデプロイ先となるサーバーの実体。
(仮想・物理は意識しない)
• 1ノード内に複数のユニットをコンテナとして
格納可能
• MAASの管理する「ノード」やOpenStack
の「インスタンス」と対応する。
• どのノードを利用するかはJujuが自動に決
める。（制約条件で特定のグループを指
定することは可能）
CharmStore Charm Service
Unit
Unit
Service
Unit
UnitCharm
Node
Node
Node
get deploy

サービスのデプロイ
新しいサービス"apache"をJuju上にデプロイするときの動作
$ juju deploy-service apache
１．CharmStoreのリポジトリからチャーム"apache"をダウンロードする
⇒Jujuにサービス"apache"が登録される
２．JujuがMAASに空きノードを問い合わせる
⇒MAASがjujuへ空きサーバーのノードid "1" を応答
３．JujuがMAASへノード"1"へのOSイメージのデプロイを指示
⇒ノード"1"のOSが起動する
４．Jujuがノード"1"へlxcコンテナを作り、その中でapacheのサービス
を有効化する
投入コマンドは
この１つだけ
あとでデモします

サービス間のリレーション構築
$ juju add-relation (サービス名1) (サービス名2)
例：novaとkeystoneを関連づける
$ juju add-relation nova-compute keystone
この１つだけ
Charmをつな
ぐ線がリレー
ションを表す
あとでデモします

複数Unitで構成されるサービス
あとで詳しく説明します

スケールアウト・スケールダウン
• スケールアウト: $ juju add-unit [-n 追加Unit数] (サービス名)
• スケールダウン: $ juju remove-unit (Unit名)
◆例：nova-compute用サーバーを3台追加
$ juju add-unit -n 3 nova-compute
JujuがMAASに"compute"タグのついた空きノード
を問い合わせる
JujuがMAASへOSイメージのデプロイを指示
JujuがノードへCharmを動かしnova-computeの
サービスを生成・有効化する
この１つだけ
あとで詳しく説明します
自動

Juju GUI 2.0
2016-01-25にJuju GUI 2.0リリース。デザインが大幅に変更
https://insights.ubuntu.com/2016/01/25/released-juju-gui-2-0/
# juju本体(Juju core)ではなく、GUIインターフェースのみ
Juju GUI 1.x
Juju GUI 2.0

25
MAASのしくみ

MAASとは？
Manager
(ex.Juju)
discover
nodes
KVM VM
ESXi VM
deploy
power
Physical Server
Node
Node
Node
list
deploy
power
MAAS
Node
Inventory
HDD
image
Physical Server
Node
Physical Server
Node
KVM VM
Node
ESXi VM
Node
CLI
GUI

MAAS GUI
GUIによる物理ノードの一元管理
物理マシン
仮想マシン

MAASのマシン登録シーケンス
参考:http://www.slideshare.net/VirtualTech-JP/openstack-45205975
User MAAS Machine
Ship,Power-on
PXE-boot
DHCP, Boot image
Power-on
PXE-boot
DHCP, Boot image
Discover H/W information
Discover power information
Power-off
Power-off
enlisting
commisioning
State:new
State:ready
Edit power type,tag,hostname etc…
inventory
MAAS GUIにマシーン
が現れる
デプロイ等に利用可能
な状態
iLo,iDRAC,ESXi,virsh
等へMAASが指示を出す

MAAS Ver1.9の新機能
MAAS1.9ではストレージやネットワーク周りの高度な設定を管理ノードへ行えるようになった。
（以下はリリースノート(http://maas.ubuntu.com/docs/changelog.html)より）
ストレージ
• LVM, Partitionのサポート
• LVM,RAID0,1,5,6設定ＵＩのサポート
• Partitioning, Bcache(LinuxのSSDキャッシュ機構) UIのサポート
ネットワーク
• ノードのネットワーク設定をサポート(以下)。
• Subnets
• fabrics
• VLAN interfaces
• bond interfaces
• interface names
• VLAN,bonding,Alias,Interface nameの設定サポート
• Subnetworrkを拡張し新たな設定をサポート。
Fabrics,Spaces,VLANs in fabrics,Subnets inSpaces
• Network設定UIのサポート

30
デモ
シナリオ:MAASによる
マシン自動探索と登録

デモ MAASによるマシン自動探索と登録
新しいマシンを作り結線と電源投入するとMAASインベントリに登録される
ＫＶＭ管理コンソールから、KVMマシンを作る。
•インストールメディアの場所：PXE,OSの種類=Linux,バージョン=Ubuntu14.04LTS
•CPU=1core,mem=2GB,HDD=20G
「インストール前に設定をカスタマイズ」にチェック
•「NIC→ソースデバイス」を「VMNETxx(br0)」に指定
•boot順をPXE,HDDに変更して「適用」
生成開始後、KVM管理コンソールを開きMAASの様子を確認する。
•起動後GUIのNodeにマシンが追加される(Commisioning -> Power Off -> new)を確認
MAAS GUI上でインベントリのマシン設定を編集する。
•Power>Power type:Virsh (virtual systems)
•Power address: qemu+ssh://(user)@(IP)/system , Power ID: KVMマシン名(nodevmN)
MAASがHW情報を収集しインベントリに表示するのを確認。
•Ready状態になる
•[Option] ホスト名=nodevmN,tag=kvm,nodevm
今回はkvmだが、
物理マシン、
VMWareもほぼ
同様
MAASが適当
にIPとマシン名
をつけている

VIDEOデモ：MAASによる自動探索

33

共用検証環境の概要
Over
Cloud
Under
Cloud
OpenStack
OpenStack B1
検証C
(OpenStackを
使わない検証)
OpenStack B2
OpenStack B3
OpenStack B4
MAAS
Juju(under)
Jujuを使った検
証
②Juju/MAAS
を使った
OpenStack
構築
③OpenStack上の
Juju利用
①OpenStack
構築講習
のための環境
構築

これからお話するところ＝①
Over
Cloud
Under
Cloud
OpenStack
OpenStack B1
検証C
(OpenStackを
使わない検証)
OpenStack B2
OpenStack B3
OpenStack B4
MAAS
Juju(under)
Jujuを使った検
証
②Juju/MAAS
を使った
OpenStack
構築
③OpenStack上の
Juju利用
①OpenStack
構築講習
のための環境
構築

環境上の位置づけ
Over
Cloud
Under
Cloud
環境(講習用)
低レベルでの環境分離とアクセス経路提供ココ

37
検証環境を作るための課題

解決したい課題
複数のPoCを干渉なく実施させるネットワーク構成
① 講習会場や自学先からセキュアにアクセスできるようにしたい
② ネットワーク的に複数のOpenStackを作ったり壊したりしたい
弊社内講習会場弊社検証機器講師
受講者
VPN
弊社

Compute Node
PoCテナントあたりの環境
Public network (Floating IP割当)
Controler
Node
Network
Node
em1 em1 em1
em2em2
em2
default GW
受講者VPN
OpenStack 管理用Network
テナント内Net (OvS)
Instance
Instance
Instance
em1
em2
※OpenStack Installation Guide for Ubuntu 14.04 kiloベース
( http://docs.openstack.org/kilo/install-guide/install/apt/content/index.html )
em1
em2
em1
em2

例:ハンズオンを開くとなると
default GW
受講者
VPN
グループ ①
グループ ②
グループ ③
グループ ④
グループ ⑤
グループ ⑥
グループ ⑦
グループ ⑧

例:ハンズオンをひらくとなると・・・
1受講グループあたり
① [Controller node]
(KVMでglance,nova,horizon,cinder,MQ,RDB格納)
② [Network node] (neutron)
③ [Compute node] (nova-compute )
×８グループ=２４サーバー必要！
※OpenStack Installation Guide for Ubuntu 14.04 kiloベース
( http://docs.openstack.org/kilo/install-guide/install/apt/content/index.html )

リソースたりない
• ハンズオンを開くにはサーバー台数が全く足りない
– （物理サーバー数台）
• 固定IPが1つしかない

43
トライしたこと
(解決策)

トライしたこと
① VMWare vSphere®でネストさせた仮想環境に講
習環境を詰め込んだ
② 講習会場-機器間にVPN経路を引いた

トライしたこと①仮想環境のネスト
• 検証に必要なサーバーをVMWare ESXi™上の仮想マシン
で提供(KVM on ESXi)
• シンプロビジョニング、オーバーコミットしまくり
• 当然スワップまみれ。性能は考慮しない。
物理サーバ数台+物理SW
VMWare ESXi 、仮想SW (tagged VLAN)
受講グループ1
仮想マシン 1
Controller node
KVM
nova
KVM
glanc
e
KVM
horiz
on
KVM
maria
DB
KVM
rabbit
MQ
KVM
swift
KVM
cinde
r
仮想マ
シン 2
Network
node
neutr
on
仮想マシン 3
Compute
node
KVM
insta
nce 1
KVM
insta
nce N
×８
仮想マ
シン x 3
node
x 3
vCente
r
Server
VMWare
で
用意
受講者
が
作る

トライしたこと②会場から環境へのアクセス
• 検証環境内からは(VPNを介さず)インターネット疎通
可能に
• 外部から検証環境へはVPN経由のみ許可
① 国外からのアクセス拒否
② ID/Password認証
③ SSL-VPN
④ ユーザーグループ毎に専用のネットワークスペース
VPNで許可
サーバー環境
外部サイト
(リポジトリ
等)
許可
拒否
講習会場

47
で、つくってみた
（構成）

ネットワークスタック
物理配線 (Ethernet)
VLAN (L2SW, VMWare仮想スイッチ)
GREトンネル
[Open vSwitch]
仮想ブリッジ
Tenant
Private
Tenant
Floting
OpenStack
(Kilo)
nodes
vCenter
Server
VPN GW
Internet
GW
RIP
Internet
◆Global IPが1個しかない。
⇒がんばってやりくりするしか

受講者へ提供するネットワーク
VLAN(L2SW, VMWare仮想スイッチ)
GREトンネル
[Open vSwitch]
仮想ブリッジ
Tenant
Private
Tenant
Floting
OpenStack
nodes
vCenter
Server
VPN GW
Internet
GW
受講者へ提供する環境
[仮想マシンx3,サブネットx2 ]/受講者
× 8 グループ
RIP
Internet
OpenStack
構築に専念！！
受講者x8grp

環境へのアクセス経路
GREトンネル
[Open vSwitch]
仮想ブリッジ
Tenant
Private
Tenant
Floting
OpenStack
nodes
vCenter
Server
VPN GW
Internet
GW
NAPT
VPN確立
IP・経路リース
NAT
RIP
Floating IP
Internet
 ログイン時のユーザーIDに応じて接続
先VLANを選択
 受講者のネットワークアドレスは重複
してもよいようにルーティングテーブル
分割
受講者x8grp
テキストどおりの
IPアドレス！
Tenant 1
Tenant 2
Tenant 3
Tenant 8
・・・

テナント内からインターネットへの経路
GREトンネル
[Open vSwitch]
仮想ブリッジ
Tenant
Private
Tenant
Floting
OpenStack
nodes
vCenter
Server
VPN GW
Internet
GW
NAPT
SNAT +
Route Domain
SNAT
RIP
Floating IP
Internet
テナント内からInternetへはVPNを
経由させず直接アクセスさせる。
テナント内サーバーからはdefaultGW
にアクセスしてるだけにみせる。
受講者
apt-get叩けないと
講習にならないからね

ルーティングテーブルの分割
• Route Domainという仕組みを使い、受講グループ
毎にルーティングテーブルを分割しました。
①受講グループ向け
GWの設定
②受講グループ・
Internet間のSNAT
グループ11 ID=1111グループ10 ID=1110
重複するアドレスを
Route Domain idで区別する
重複するネットワークから1つの
グローバルIPへSNATさせる

下回り完成
Over
Cloud
Under
Cloud
環境(講習用)
低レベルでの環境分離とVPNアクセス経路提供
OpenStack B1
OpenStack B2
OpenStack B3
OpenStack B4
独立した
ルートテーブル
独立した
独立した
独立した
ココ

54

これからお話するところ＝②
Over
Cloud
Under
Cloud
OpenStack
OpenStack B1
検証C
(OpenStackを
使わない検証)
OpenStack B2
OpenStack B3
OpenStack B4
MAAS
Juju(under)
Jujuを使った検
証
②Juju/MAAS
を使った
OpenStack
構築
③OpenStack上の
Juju利用
①OpenStack
構築講習
のための環境
構築

環境上の位置づけ
Over
Cloud
Under
Cloud
OpenStack
環境A(メイン)
MAAS
Juju(MAAS用)
API
ココ

OpenStack構築手順
詳しい手順は日本仮想化技術様公開資料
「Ubuntu Juju/MAASを使用した
OpenStack構築手順書」
http://enterprisecloud.jp/installguide-juju-openstack/
をご参照ください

Juju/MAASを用いた
OpenStack構築
Jujuを用いたOpenStack構築手順はすでに
発表事例がいくつかありますので・・・要所だけ。
構築の流れとトラブルシュート
構築後のComputeノード追加
Jujuで作ったOpenStack設定の変更

OpenStack構築の流れ
サービスデプロイまでは設定・手順必要。その後のノード追加・削除はほぼ全自動
１．MAASサーバーの構築
２．Jujuサーバーの構築とMAAS連携設定
３．OpenStack用物理マシン・仮想マシンの
設置・配線
４．JujuへOpenStackサービス群をデプロイ
サービス設
定が終わる
まではそれ
なりにハマ
る
MAAS：HWリブート・イメージデプロイを
繰り返すので時間かかる
Juju:MAAS連携で手こずる。サービスま
でくみあがれば、あとはラク
• サービス間のリレーション設定
• neutronネットワーク設定

Juju/MAASトラブルシュート
Jujuからのサービスデプロイに失敗するパターン
パターン１：Jujuに指示してもMAASのDeployがはじまらない
パターン２：MAASのデプロイが終わってもJujuがunitのデプロイをはじめない
パターン３：Juju,MAASへのオーダー投入が多すぎて失敗する
原因は
「juju-core,juju-bootstrap,maasの3サーバー間のタイミングプロブレム
（どこかで通信がタイムアウト）」
または
「juju-core,juju-bootstrap,maasのどこかに過去の失敗したインベントリ
の残骸が残っている」ケースが多い（経験則）

Juju/MAASトラブルシュート
対応策
1. "juju status"コマンドでデプロイの残骸を探しあれば削除する。
1. unit: juju remove-unit (unit名)
2. service: juju remove-service (service名)
3. node: juju remove-machine (node番号) --force
(nodeのlifeがdeadになることを確認する）
2. MAAS GUIでjujuから消したNodeをReleaseし、Ready状態へ戻す。
3. 各マシンの時刻がずれている場合はntpを設定し同期させる。
4. juju-core,juju-bootstrap,maasをリブートする。
5. 上記後、再度デプロイを実施する。

インスタンスのコンソールを表示するJuju設定
juju-coreで以下を実行(プロトコルにnovncを選ぶ場合)
$ juju set nova-cloud-controller console-access-protocol=novnc
(値はspice, xvpvnc, novnc, vncから指定)
以後起動するインスタンスはコンソール表示される。
(クライアントPCからcomputeノードの
名前解決できること)

インスタンスのコンソールを
表示するJuju設定
以後起動するインスタンスはコンソール表示される

Juju/MAASでOpenStack環境完成
Over
Cloud
Under
Cloud

65
シナリオ:Juju+MAASで
nova-computeをスケールアウト

Jujuでサービスをスケールアウト
作成済みのサービス"nova-compute"(OpenStackのコンピュートノード)へマシンを追加する
$ juju add-unit nova-compute
JujuがMAASへmachine割当とＯＳ生
成を依頼
MAAS GUIで1つのNodeがReadyから
Ready→Deploying→Deployedと変化
JujuがCharmに従い生成したMachineへ
リモート操作しnova computeを生成
OpenStackへnova-computeを登録
20-30分間かかる(OSの生成
からの場合)
MAASに割り振った特定タグの
マシンにデプロイすることも可能
•juju set-constraints tags=(タグ
名) (サービス名)
サービスに振られている
Constraintsの確認方法
•juju get-constraints (サービス名)

追加前のnova-compute
Unit=2つ

追加前のMAAS GUI。Tag=compute,Status=Deployedが2つ。Status=Readyが5つ

Juju でnova-computeサービスに対してadd-unitを実施

juju statusで状況確認
$ juju status nova-compute
Machine"70"として
nodevm3がアサインされた

Juju GUIに構築中Unit数がPendingとして表示される
MAAS GUIではMachineがStatus=Deployingになる

Jujuのデプロイシーケンス完了。
Juju GUIのPendingが消える。juju statusでagent-state=startedになる

さらにしばらく待つと、OpenStackに追加したマシンが現れる。
これですべて完了。

74

これからお話するところ＝③
Over
Cloud
Under
Cloud
OpenStack
OpenStack B1
検証C
(OpenStackを
使わない検証)
OpenStack B2
OpenStack B3
OpenStack B4
MAAS
Juju(under)
Jujuを使った検
証
②Juju/MAAS
を使った
OpenStack
構築
③OpenStack上の
Juju利用
①OpenStack
構築講習
のための環境
構築

76
OpenStack上にJuju環境を作る

Juju on OpenStackの位置づけ
Over
Cloud
Under
Cloud
OpenStack
環境A(メイン)
MAAS
Juju(MAAS用)
テナントA
Juju(tenant)
Jujuを使った
サービスデプロイ
API
テナントB
Juju(tenant)
Jujuを使った
API
dns dns
ココ

構成
private network
private-subnet
ext-net (Global)
juju-core
juju-bootstrap
juju-gui
dnsRouter
GW
OpenStack
Services
API
OpenStack上のプロジェクト"services"
Jujuで作る
Service
インスタンス起動

OpenStack上に
Juju環境をつくる手順
１．インスタンスにJuju-coreとapacheをインス
トール
２．Juju設定"enviroments.yaml"を編集
３．プライベート環境用metadataを生成し
Web公開する
４．juju bootstrapを実行しbootstrapサー
ビスを作る

Juju coreとapacheをインストール
# Juju coreとapacheをインストール
$ sudo add-apt-repository ppa:juju/stable
$ sudo apt-get update
$ sudo apt-get install juju-core apache2
# Jujuの設定ファイルを生成し編集
$ juju init -f
$ vi ~/.juju/environments.yaml

environments.yaml
environments:
default: openstack
openstack:
type: openstack
use-floating-ip: true
use-default-secgroup: false
network: ( Jujuを利用するOpenStackネットワークID )
tools-metadata-url: http://(juju-coreのIP)/stack/tools
image-metadata-url: http://(juju-coreのIP)/stack/images
auth-url: (keystone APIのURL)
tenant-name: services (⇒利用するOpenStackプロジェクト名)
region: RegionOne (⇒利用するOpenStackリージョン名)
auth-mode: userpass
username: (OpenStackプロジェクトのユーザー名)
password: (OpenStackプロジェクトのパスワード)
ここがmetadata

metadataを作り公開する
metadata=Jujuが使うクラウド環境のインスタンス情報を記述したカタログファイル。
AWS等Public Cloudのmetadataはあらかじめ用意されているが、
Private Cloudの場合Jujuが参照可能なURLに作る必要がある。
#Jujuが使うglance上にあるUbuntu ServerイメージのIDを控える
nova-cloud-contrller$ glance image-list
# juju-coreにログインする。
# juju-coreでOSイメージのmetadataを作る。
$ juju metadata generate-image -a amd64 ¥
-i (glance イメージのID) -r RegionOne -s trusty ¥
-d /opt/stack -u (KeystoneAPIのURL) -e openstack
# Juju toolsを記述したmetadataを作る
$ juju metadata generate-tools -d /opt/stack
# 作ったmetadataをDocumentRootへコピーする
$ sudo cp -R /opt/stack /var/www/html

テナント用Juju bootstrapと
GUIを作る
★bootstrap=Juju coreの指示でクラウド環境にMachineを作ったりUnitを
作ったりする実働サービス。ないとJujuは動かない。環境毎に生成する。
(AWS用、MAAS用、OpenStack用・・・)
juju-core$ juju bootstrap --metadata-source /opt/stack ¥
--upload-tools -v --show-log --debug
★Juju GUI= JujuのGUIサービス。なくてもJujuは動く。でも、ないとさびしい。
# juju-bootstrapを作ったmachine 0にjuju-guiをデプロイする。
juju-core$ juju deploy juju-gui --to 0
(OpenStack でjuju-guiをデプロイしたインスタンスのセキュリティグループに
443と80を許可する。)
# GUIにログインするためのID,パスワードを確認する
juju-core$ juju api-info user;juju api-info password password

84
本当ならこれでJujuが動く
はずだった・・・

残念な課題
Jujuで作ったOpenStack APIへ、
テナント内のJuju bootstrapから疎通しない
残念1:そのそもIP
Reachableにしてなかっ
た
残念2: Juju/MAASが
決めたFQDNをテナント
内から参照できない

残念な個所
Over
Cloud
Under
Cloud
OpenStack
環境A(メイン)
MAAS
Juju(MAAS用)
テナントA
Juju(tenant)
Jujuを使った
API
API
ココの通信と名前解決
×

対応1:
サービスエンドポイント用IPを公開する
★Cloudのover/underを完全分離したのがアダになった。
⇒エンドポイント各サーバにext-net(Global IP領域)のIPを追加する
以下はkeystoneサーバへ外部API用NIC追加の例
$ sudo vi /etc/network/interfaces
iface eth1 inet manual
auto pub-br1
iface pub-br1 inet static
bridge_ports eth1
address (ext-net用IP)
netmask (ネットマスク)
network (ネットワークアドレス)
broadcast (ブロードキャストアドレス)
$ shutdown -r now
(実施後にOpenStack dashboardのサーバ再起動を必要とするケースがあった
ので、dashboardにログインできることを確認しつつ各サーバにIPを追加していく)

対応2:テナント内にDNSサーバをたてる
★ JujuだけでなくJujuが生み出すNode(インスタンス)もIPではなく
(MAASが適当に決めた)FQDNでAPIアクセスしようとする。
(hosts編集じゃ逃げられない)
⇒今回はテナント内にunboundでローカルDNSを作成し
OpenStackサブネットのDNSとしてそのDNSサーバを設定した。
$ sudo apt-get install unbound
# unboundのACL定義を編集
$ sudo vi /etc/unbound/unbound.conf.d/server.conf
# ローカル環境用DNSエントリ定義を編集
$ sudo vi /etc/unbound/unbound.conf.d/local-data.conf
$ reboot
Juju利用するサブネットのDNSサーバに指定

対応2:テナント内にDNSサーバをたてる
◆unboundのACL定義
/etc/unbound/unbound.conf.d/server.conf
◆ローカル環境用DNSエントリ定義
/etc/unbound/unbound.conf.d/local-data.conf
server:
local-data: "dns-in.services. IN A XX.XX.0.123"
local-data: "vm7.maas. IN A XX.XX.0.10"
local-data: "cinder.maas. IN A XX.XX.0.13"
server:
interface: 0.0.0.0
access-control: 127.0.0.1/32 allow
access-control: (テナントが利用するNetwork Address)/16 allow

前向きな反省
★環境上の制約でUnder Cloud用(MAAS用)JujuとOver Cloud用
(テナント用)Jujuを分離せざるを得なかった。
(Jujuはマルチ環境対応してるのに)
⇒ テナントを管理する側のJujuと管理される側のJujuが一緒よりも分か
れてるほうが気持ちいい。テナント毎に分離できたほうが使いやすいダロウ？
★構築時のNW的制約でテナント内のJuju環境からOpenStackAPIを
たたくのに苦労した。
⇒ テナント内でJuju coreとDNSをいつも立てる手順にすればテナント権
限だけで自由にテナント内専用Jujuを構築できて便利ダロウ？
結論：だいたい望んだものができた

Juju on OpenStack完成
Over
Cloud
Under
Cloud
OpenStack
環境A(メイン)
MAAS
Juju(MAAS用)
テナントA
Juju(tenant)
Jujuを使った
API
テナントB
Juju(tenant)
Jujuを使った
API
dns dns

92
テナント内にJujuでサービスを構築する

Juju on OpenStackの位置づけ
Over
Cloud
Under
Cloud
OpenStack
環境A(メイン)
MAAS
Juju(MAAS用)
テナントA
Juju(tenant)
Jujuを使った
API
テナントB
Juju(tenant)
Jujuを使った
API
dns dns
ココ

94
シナリオ：Juju on OpenStackで
WordPressをデプロイ

デモ Juju でWordPressをデプロイ
MAAS管理下のマシンへWordPressをデプロイしアクセスする [所要時間30-40分]
$ juju deploy mysql
$ juju deploy wordpress
$ juju add-relation wordpress mysql
$ juju expose wordpress
http://(nodeのIP)へアクセスしwordpressを設定する。
• 実測でそれぞれ約10-20分かかる。
• デプロイしたマシンのＩＰに外部からア
クセス可能になる。
• IPはMAASのGUIから確認する。

VIDEOデモ：Jujuで
WordPressを構築

Juju でWordPressをデプロイ
完成

98

やったこと
Over
Cloud
Under
Cloud
OpenStack
環境A(メイン)
MAAS
Juju(MAAS用)
テナントA
Juju(tenant)
Jujuを使った
API
テナントB
Juju(tenant)
Jujuを使った
API
dns dns
ココ
ココ
ココ
ココ

やったこと
1. 社内にOpenStack®の講習やPoCを行うための環
境をつくりました。
2. Juju/MAASを使ってOpenStack環境を構築しま
した。
3. OpenStack上のプロジェクト内にJuju環境を構築
しました。
4. Juju on OpenStackを使ってプロジェクト内のサー
ビスをモデリング・デプロイしました。

101
なんでこんなことしてるの？

技術に垣根なし
OpenStack
KVM
VMW
are
VPN
DNS
OSSとかプロプラエタリとか
パブリックとかオンプレとかいっていられない
Juju
AWS
AZU
RE
Blue
Mix
MAAS
OCP
BMS

ワンストップから選択される専門家へ
• 提案から運用までロックインする「SI」は変化
• IT構築がなくなるわけではない。人やノウハウは必要
• 構築(Dev)と運用保守(Ops)で委託先分離できるように
• ロックできないから「専門家」になることが求められる
業務コンサル構築・教育運用サービス
◆従来：ワンストップ＝ロックイン
業務コンサル構築・教育運用サービス
◆これから：ロックフリー＝専門集団化
選択選択選択
ロックロック
専門化専門化専門化

クラウド活用ですべて社内で賄えるか
コスト：社員を維持するコスト
•有能な社員は本業に集中させたいはず
•不要になったらリリースしたいはず
技術：社員ですべての知見
を賄えるわけじゃない
•有能な社員は限られている
•専門性を社員で賄えない
調達：すべての製品を直接買っ
て面倒みるのか
従来(ワンストップ
SI)
最近(クラウド,自
動化が支援)
SIerに人員をオフ
ロード
クラウドサービス,
自動化にオフロー
ド＋社員が管理
SIerがＩＴ・業
務専門知識を提
供
クラウドサービス
（ナレッジ）を活
用
コンサル利用
＋社員が勉強
SIerが調達・保
守を代行
調達せずサービス
として利用
+社員が調達・保
守
クラウド（的なもの）が選択できるようになった。でも、社員の負担も増える

クラウド時代も私たちが皆様のお役に
たてることはいろいろありそうだ
よきパートナーになるための努力をし
これからもがんばってまいります
最新技術をキャッ
チする
PoC(Proof of
Concept)で
顧客業務要件へ
フィッティング
得意な領域を繰
り返し深く専門化
する
現場から湧き出る
PoCネタ募集！
ぜひお声掛けください

106

Ubuntu Juju/MAAS・OpenStackを使った検証環境構築 - OpenStack最新情報セミナー 2016年3月

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (6)

Similar to Ubuntu Juju/MAAS・OpenStackを使った検証環境構築 - OpenStack最新情報セミナー 2016年3月

Similar to Ubuntu Juju/MAAS・OpenStackを使った検証環境構築 - OpenStack最新情報セミナー 2016年3月 (20)

More from VirtualTech Japan Inc.

More from VirtualTech Japan Inc. (20)

Recently uploaded

Recently uploaded (9)

Ubuntu Juju/MAAS・OpenStackを使った検証環境構築 - OpenStack最新情報セミナー 2016年3月